QCA9377 isn't being recognized sometimes

Bug #1757218 reported by Leonardo Müller on 2018-03-20
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Kai-Heng Feng
Bionic
Undecided
Unassigned
linux-oem (Ubuntu)
Undecided
Unassigned
Bionic
Undecided
Unassigned

Bug Description

=== SRU Justification ===
[Impact]
Qualcomm WiFi/Bluetooth may disappear after boot.

[Fix]
Disable USB2 LPM at shutdown phase, to prevent it from lingering in LPM
L1. Pull back the device to full power before shutdown imitates the
behavior on Windows.

[Test]
The affected user confimed it fixes the issue.
I can also confirm that
a) The power drain in S5 is much lower,
b) Both WiFi and Bluetooth are always present during reboot stress test.

[Regression Potential]
Low. Only a limited number of USB2 devices that support LPM.

=== Original Bug Report ===
Sometimes, the Wireless Network Card QCA9377 is not recognized on boot. This caused, on prior versions, a kernel panic at boot. With Bionic, the system boots but is unable to use wireless network. On dmesg there are messages like:

[ 2.680590] usb 1-7: new full-speed USB device number 7 using xhci_hcd
[ 2.808640] usb 1-7: device descriptor read/64, error -71
[ 3.044337] usb 1-7: device descriptor read/64, error -71
[ 3.280064] usb 1-7: new full-speed USB device number 8 using xhci_hcd
[ 3.408245] usb 1-7: device descriptor read/64, error -71
[ 3.644244] usb 1-7: device descriptor read/64, error -71
[ 3.752193] usb usb1-port7: attempt power cycle
[ 4.404591] usb 1-7: new full-speed USB device number 9 using xhci_hcd
[ 4.404904] usb 1-7: Device not responding to setup address.
[ 4.612478] usb 1-7: Device not responding to setup address.
[ 4.820588] usb 1-7: device not accepting address 9, error -71
[ 4.948591] usb 1-7: new full-speed USB device number 10 using xhci_hcd
[ 4.949109] usb 1-7: Device not responding to setup address.
[ 5.156893] usb 1-7: Device not responding to setup address.
[ 5.364589] usb 1-7: device not accepting address 10, error -71
[ 5.364655] usb usb1-port7: unable to enumerate USB device

And lspci and lsusb don't show the wireless network card. The alternative is to turn the system off. Reboot don't work and reboot to Windows 10 also don't. The system must be powered off to restore functionality. Then, on the next boot, it works properly.

However, after the system is turned off, it may cause the issue again. This is not 100% consistent, but mostly it cycles between powering off and powering on the notebook as:

Work -> Don't work -> Work -> Don't work

On Windows 10 this doesn't happen but when happens on Ubuntu, it's possible to reboot and see the status on Windows 10 too: on Device Manager it's shown a unidentified USB device at 1-7. Sometimes, on Windows 10's Network Devices it's shown, instead of the QCA9377, from four to six different devices with generic names and Bluetooth and/or Wireless don't work.

When turning Ubuntu off, there are messages that appears a few instants before the system is turned off:

Mar 18 18:27:26 usuario-Lenovo-ideapad-310-14ISK kernel: [14146.403388] ath10k_pci 0000:02:00.0: failed to install key for vdev 0 peer xx:xx:xx:xx:xx:xx: -110
Mar 18 18:27:26 usuario-Lenovo-ideapad-310-14ISK kernel: [14146.403399] wlp2s0: failed to remove key (0, xx:xx:xx:xx:xx:xx) from hardware (-110)

Generally, only the second message appears (but both are recorded on kern.log). The MAC adress is the one from the router, not from the wireless card.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-12-generic 4.15.0-12.13
ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7
Uname: Linux 4.15.0-12-generic x86_64
ApportVersion: 2.20.8-0ubuntu10
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: usuario 1364 F.... pulseaudio
 /dev/snd/seq: usuario 1258 F.... timidity
CurrentDesktop: XFCE
Date: Tue Mar 20 14:43:42 2018
HibernationDevice: RESUME=UUID=9f36068f-c6d6-4fd6-87d5-46f1f5247563
InstallationDate: Installed on 2017-06-13 (279 days ago)
InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
MachineType: LENOVO 80UG
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-12-generic.efi.signed root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-12-generic N/A
 linux-backports-modules-4.15.0-12-generic N/A
 linux-firmware 1.173
SourcePackage: linux
UpgradeStatus: Upgraded to bionic on 2017-10-20 (151 days ago)
dmi.bios.date: 07/10/2017
dmi.bios.vendor: LENOVO
dmi.bios.version: 0XCN43WW
dmi.board.asset.tag: NO Asset Tag
dmi.board.name: Toronto 4A2
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40679 WIN
dmi.chassis.asset.tag: NO Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Lenovo ideapad 310-14ISK
dmi.modalias: dmi:bvnLENOVO:bvr0XCN43WW:bd07/10/2017:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK:
dmi.product.family: IDEAPAD
dmi.product.name: 80UG
dmi.product.version: Lenovo ideapad 310-14ISK
dmi.sys.vendor: LENOVO

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Joseph Salisbury (jsalisbury) wrote :

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.16 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.16-rc6

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete

The behavior appears to be much better with the kernel version 4.16-rc6. However, I think this is not 100% solved, as the following error is still (but now rarely) happening when disconnecting from a network:

[ 5934.740004] ath10k_pci 0000:02:00.0: failed to install key for vdev 0 peer xx:xx:xx:xx:xx:xx: -110
[ 5934.740010] wlp2s0: failed to remove key (0, xx:xx:xx:xx:xx:xx) from hardware (-110)

With that MAC address being from the router. I believe this error, when happening on shutdown or reboot, is the source of the problem, as when that messages are not shown (apparently) the error doesn't happens.

Kai-Heng Feng (kaihengfeng) wrote :

usb 1-7 is the Bluetooth of the wireless module.

Can you attach the dmesg when this issue happens? I'd like to see what ath10k_pci complains.

This is the dmesg from when it failed yesterday.

Kai-Heng Feng (kaihengfeng) wrote :

Looks like the ath10k_pci device drops off the PCI bus completely. I guess you can't find the device in `lspci` when this happens.

Does the device re-appear if you rescan the PCI bus? i.e. `# echo 1 > /sys/bus/pci/rescan`.

tags: added: kernel-fixed-upstream
Changed in linux (Ubuntu):
status: Incomplete → Confirmed

This is not happening with the kernel 4.16-rc6, so I added the tag kernel-fixed-upstream.

I can no longer boot with the 4.15.0-12 kernel successfully when the error happens, it just freeze and I wait until the HD stops to shutdown it by keeping the power button pressed. I was lucky the system was able to boot and I could obtain some information from the error.

Definitively, with the kernel 4.15.0-12 (and previous versions), it has a pattern of:

Work -> Don't work -> Work -> Don't work

Frequently causing a freeze (kernel panic?). One curious thing I noticed is that it freezes always in the same line on the boot:

Started Load/Save Screen Backlight Brightness of backlight:intel_backlight.

I don't know why, but it's always on this line.

Kai-Heng Feng (kaihengfeng) wrote :

Does it also get fixed by latest upstream stable kernel?

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15.12/

With kernel version 4.15.12 the the problem is not fixed. It has the same behavior as 4.15.0-12.

Kai-Heng Feng (kaihengfeng) wrote :

Can you find the first v4.16-rc* that fixes this issue? We need to backport the fix to Bionic's kernel.

The first kernel fixed is 4.16-rc5.

Kai-Heng Feng (kaihengfeng) wrote :

It's hard to say which commit(s) fixes the issue, so the fastest way is to bisect locally.

You can still follow the steps [1], but instead of "bad good", use "old new":

$ git bisect start
$ git bisect old v4.16-rc4
$ git bisect new v4.16-rc5
$ make localmodconfig
$ make -j`nproc` deb-pkg
Install the newly built kernel.
If the issue still happens,
$ git bisect old
Otherwise,
$ git bisect new

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772/comments/19

Download full text (3.2 KiB)

Finally, after 10 kernels built, I've obtained the result. Here is the output:

1fdb926974695d3dbc05a429bafa266fdd16510e is the first new commit
commit 1fdb926974695d3dbc05a429bafa266fdd16510e
Author: Hans de Goede <email address hidden>
Date: Tue Feb 20 09:06:18 2018 +0100

    Bluetooth: btusb: Use DMI matching for QCA reset_resume quirking

    Commit 61f5acea8737 ("Bluetooth: btusb: Restore QCA Rome suspend/resume fix
    with a "rewritten" version") applied the USB_QUIRK_RESET_RESUME to all QCA
    USB Bluetooth modules. But it turns out that the resume problems are not
    caused by the QCA Rome chipset, on most platforms it resumes fine. The
    resume problems are actually a platform problem (likely the platform
    cutting all power when suspended).

    The USB_QUIRK_RESET_RESUME quirk also disables runtime suspend, so by
    matching on usb-ids, we're causing all boards with these chips to use extra
    power, to fix resume problems which only happen on some boards.

    This commit fixes this by applying the quirk based on DMI matching instead
    of on usb-ids, so that we match the platform and not the chipset.

    Here is the /sys/kernel/debug/usb/devices for the Bluetooth module:

    T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#= 5 Spd=12 MxCh= 0
    D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0cf3 ProdID=e300 Rev= 0.01
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms

    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
    Fixes: 61f5acea8737 ("Bluetooth: btusb: Restore QCA Rome suspend/resume..")
    Cc: <email address hidden>
    Cc: Brian Norris <email address hidden>
    Cc: Kai-Heng Feng <email address hidden>
    Reported-and-tested-by: Kevin Fenzi <email address hidden>
    Signed-off-by: Hans de Goede <email address hidden>
    Signed-off-by: Marcel Holtmann <email address hidden>

:040000 040000 2930a43c59c0e767763843528fa8526d4e17b764 626944fe59...

Read more...

The kernel was updated today to version 4.15.0-13 and the commit "Bluetooth: btusb: Use DMI matching for QCA reset_resume quirking" was added. I have tested the notebook and now it is no longer failing to boot or booting without wireless and bluetooth.

The problem is fixed to me.

Thank you.

Kai-Heng Feng (kaihengfeng) wrote :

No problem. Does this somehow (magically) also fix the ethernet r8169 for you?

Don't mark this as fixed yet, it has just happened in a different way: it progressed further on boot until it froze at the a message like waiting for /dev/disk.

I, sincerely, don't know what to do now. This has never happened the kernels starting from 4.16.0-rc5. I have uploaded the bisect log.

And the Ethernet problem was not fixed. It's important to say that I have both a desktop and a notebook with this same Ethernet device (but different revision) and only the desktop has this problem:

Desktop:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)

Notebook:
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)

Download full text (3.2 KiB)

This is insane. I have reset that bisect and tried again using "fixed" and "broken" instead of "new" and "old" and, again, the bisect had the following:

1fdb926974695d3dbc05a429bafa266fdd16510e is the first fixed commit
commit 1fdb926974695d3dbc05a429bafa266fdd16510e
Author: Hans de Goede <email address hidden>
Date: Tue Feb 20 09:06:18 2018 +0100

    Bluetooth: btusb: Use DMI matching for QCA reset_resume quirking

    Commit 61f5acea8737 ("Bluetooth: btusb: Restore QCA Rome suspend/resume fix
    with a "rewritten" version") applied the USB_QUIRK_RESET_RESUME to all QCA
    USB Bluetooth modules. But it turns out that the resume problems are not
    caused by the QCA Rome chipset, on most platforms it resumes fine. The
    resume problems are actually a platform problem (likely the platform
    cutting all power when suspended).

    The USB_QUIRK_RESET_RESUME quirk also disables runtime suspend, so by
    matching on usb-ids, we're causing all boards with these chips to use extra
    power, to fix resume problems which only happen on some boards.

    This commit fixes this by applying the quirk based on DMI matching instead
    of on usb-ids, so that we match the platform and not the chipset.

    Here is the /sys/kernel/debug/usb/devices for the Bluetooth module:

    T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#= 5 Spd=12 MxCh= 0
    D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
    P: Vendor=0cf3 ProdID=e300 Rev= 0.01
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
    I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
    I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
    I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
    E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms

    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
    Fixes: 61f5acea8737 ("Bluetooth: btusb: Restore QCA Rome suspend/resume..")
    Cc: <email address hidden>
    Cc: Brian Norris <email address hidden>
    Cc: Kai-Heng Feng <email address hidden>
    Reported-and-tested-by: Kevin Fenzi <email address hidden>
    Signed-off-by: Hans de Goede <email address hidden>
    Signed-off-by: Marcel Holtmann <marcel@holtm...

Read more...

The only thing I can think that is wrong is the configuration file of the kernels. They have some significant differences regarding Bluetooth.

This is comparing the 4.15.0-13 kernel with the mainline kernel.

Kai-Heng Feng (kaihengfeng) wrote :

Do you have this issue when using v4.16-rc7 with kernel parameter "btusb.enable_autosuspend=0"?

No, using this parameter when using the kernel v4.16-rc7 do not cause the issue.

Kai-Heng Feng (kaihengfeng) wrote :

Because the commit you bisected has been included since 4.15.12, which you said the issue is not fixed (comment #10).

That particular commit will be included in next Bionic kernel update.

So I guess now the bug is "waiting for /dev/disk"?

The bug is still the same. What happened was that the system froze at a different message in that particular try. Journalctl from a successful initialization showing the most common point of failure:

systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:intel_backlight...
systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:intel_backlight.
systemd[1]: Started Uncomplicated firewall.
systemd-udevd[400]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
systemd[1]: Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch.
systemd[1]: Starting Load/Save RF Kill Switch Status...

The messages after the one of intel backlight are the ones related with /dev/rfkill. This is why it freezes showing:

[ OK ]: Started Load/Save Screen Backlight Brightness of backlight:intel_backlight.

Probably the RF Kill has a serious enough failure when this bug happens that the entire system freezes.

This is funny, but the option btusb.enable_autosuspend=0 make the bug happen on v4.16-rc7. I'm seeing a pattern that, when I change the kernel version or a grub option, I can't just turn on and off the notebook twice (as it triggers normally), but thrice.

So, every time I change a configuration I have to turn the notebook on and off thrice to test.

The good new is that btusb.enable_autosuspend=0 triggers the bug.

And no v4.15 kernel from mainline is free from this bug.

This bug is biting me for a long time and was being very hard to find, but finally it is cornered.

Kai-Heng Feng (kaihengfeng) wrote :

Can you attach dmesg with "btusb.enable_autosuspend=0", and another dmesg without the parameter?

I am guessing that ath10k and btusb can't get probed at the same time.

Many tries were required until I could obtain a useful log. As it can be seen in the kernel command line, I had to add many debug options to obtain this.

This file is one with the failed boot, unfortunately the kernel panic message don't appear. Unlike the other file with the failure I uploaded before, on this one the boot failed. I was helped on #ubuntu+1 on how to add netconsole to initramfs, so I was able to obtain the first 7 seconds of the log.

Kai-Heng Feng (kaihengfeng) wrote :

Please try the kernel here:
https://people.canonical.com/~khfeng/lp1757218/

It adds your device to btusb_needs_reset_resume_table[].

Unfortunately, this kernel still has the same issue.

The parameter btusb.enable_autosuspend is decisive to define if the fixed kernels will work. Disabling it ("btusb.enable_autosuspend=0") makes the fixed kernels act like the broken ones. However, setting it in broken kernels ("btusb.enable_autosuspend=1") has no effect.

Kai-Heng Feng (kaihengfeng) wrote :

Sorry for the late reply for this issue. Does this issue also happen to cold boot? AFAICT, it only happens to reboot, right?

We probably need to reset the device before reboot.

The issues happens only on cold boot. In a pattern of:

Work -> Don't work -> Work

If the cold boot is successful, all reboots work. If the cold boot failed, all reboots fail.

Kai-Heng Feng (kaihengfeng) wrote :

Added a delay init quirk, let's see if this kernel works:
https://people.canonical.com/~khfeng/lp1757218/

This kernel version works, but I don't understand why testing a 4.17 version would be relevant on this case, as the first kernel fixed is 4.16-rc5 and, according to the checkout we've done before, the first good commit should be:

commit 1fdb926974695d3dbc05a429bafa266fdd16510e
Author: Hans de Goede <email address hidden>
Date: Tue Feb 20 09:06:18 2018 +0100

    Bluetooth: btusb: Use DMI matching for QCA reset_resume quirking

However, this commit alone have not solved the issue. Maybe because there were many Bluetooth related commits together with this one and the checkout was unable to detect this detail.

Kai-Heng Feng (kaihengfeng) wrote :

Forgot to mention you should test it with btusb.autosuspend=0

Ok, using btusb.autosuspend=0 with this kernel version worked. I tested to turn the notebook off and on 5 times and all times both Bluetooth and Wireless worked.

Kai-Heng Feng (kaihengfeng) wrote :

Bionic kernel with the delay quirk:

https://people.canonical.com/~khfeng/lp1757218-bionic/

This kernel did not work. On boot, the same messages that appeared with the other problematic kernels appear and the boot freezes.

Kai-Heng Feng (kaihengfeng) wrote :

Please try if this kernel works. May need to reboot twice because the fix is in shutdown path.

https://people.canonical.com/~khfeng/lp1757218-bionic/

I shutdown and turned on the computer using this kernel four times and in none the problem happened. With the default Bionic kernel the failure on boot would have happened twice.

Changed in linux (Ubuntu):
assignee: nobody → Kai-Heng Feng (kaihengfeng)
description: updated
AceLan Kao (acelankao) on 2019-06-10
Changed in linux-oem (Ubuntu):
status: New → Invalid
Changed in linux-oem (Ubuntu Bionic):
status: New → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.