Ubuntu
linux package

Iwlwifi regression after linux 4.19

Bug #1833588 reported by Valentin Crone
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Hello,
On my HP Omen 17", with an Intel Corporation Wireless 7265, now (Ubuntu 19.04) when the card go in suspend mode, the connection is lost.
The problem is the card automatically go to suspend mode when it's not used for X seconds, so I need to reconnect my computer to the AP each 30 - 40s.

I had never seen this bug before Ubuntu 19.04, the computer was previously on:
- Ubuntu 14.04
- Ubuntu 18.04

This seem to be the same problem as:
https://bugzilla.redhat.com/show_bug.cgi?id=1656233

And a fix seem to be released:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/pci/probe.c?id=10ecc818ea7319b5d0d2b4e1aa6a77323e776f76

Can you add this patch on the kernel package?

Thank you !

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: linux-image-5.0.0-17-generic 5.0.0-17.18
ProcVersionSignature: Ubuntu 5.0.0-17.18-generic 5.0.8
Uname: Linux 5.0.0-17-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC2: valentin 3816 F.... pulseaudio
 /dev/snd/controlC0: valentin 3816 F.... pulseaudio
 /dev/snd/controlC1: valentin 3816 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Thu Jun 20 18:53:56 2019
HibernationDevice: RESUME=none
InstallationDate: Installed on 2019-04-02 (78 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190326.2)
MachineType: HP OMEN by HP Laptop 17-an0xx
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-17-generic root=UUID=0e3bd72e-ceb3-4aa3-8c69-100b640d7787 ro quiet splash snd_hda_intel.single_cmd=1 osi_acpi=! "osi_acpi=Windows 2009" acpi_backlight=vendor vt.handoff=1
RelatedPackageVersions:
 linux-restricted-modules-5.0.0-17-generic N/A
 linux-backports-modules-5.0.0-17-generic N/A
 linux-firmware 1.178.1
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/09/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: F.18
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 8392
dmi.board.vendor: HP
dmi.board.version: 40.28
dmi.chassis.type: 10
dmi.chassis.vendor: HP
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF.18:bd11/09/2018:svnHP:pnOMENbyHPLaptop17-an0xx:pvr:rvnHP:rn8392:rvr40.28:cvnHP:ct10:cvrChassisVersion:
dmi.product.family: 103C_5335KV HP OMEN
dmi.product.name: OMEN by HP Laptop 17-an0xx
dmi.product.sku: 1RH63EA#ABF
dmi.sys.vendor: HP

Revision history for this message
Valentin Crone (va-crone) wrote :
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Does the issue happen without 'osi_acpi=! "osi_acpi=Windows 2009"'?

Revision history for this message
Valentin Crone (va-crone) wrote :

I can't boot my computer without osi_acpi=! osi_acpi="Windows 2009", and my computer freeze with a CPU Lock error blablabalbla #23 if I doesn't set "snd_hda_intel.single_cmd=1".

But, I always used theses options, even with Ubuntu 14.04 and 18.04, and I never had this issue.

Theses options: osi_acpi=! and osi_acpi="Windows 2009" are (misfortunately) required for the most of hybrid computers (intel graphics/nvidia, laptop) today, which is not user friendly to boot Ubuntu.
And, nouveau.run_pm=1 is required for the most of the same type of laptops to make them able to boot without the proprietary nvidia driver. And nouveau.run_pm=1 provide generally a very laggy screen, but when the installation is complete, you can install the nvidia driver and it's ok.

Revision history for this message
Valentin Crone (va-crone) wrote :

It seems I have the same problem with my Intel 7260 on a Dell Latitude E6540, I get some disconnections while my smartphone is always connected properly. Here I haven't the options osi_acpi=! and osi_acpi="Windows 2009" set, this computer is able to boot without any special manipulations with Ubuntu.

Revision history for this message
Valentin Crone (va-crone) wrote :

I dont know if it's related to the current bug, but with Ubuntu 19.04, on my Dell Laptop (quoted on the previous message), I have to switch off the wireless and the switch on approximately each 30 - 60mins to make it able to stay connected to the wireless. Without this, at a time, the connexion is lost, and you can refresh for wireless, nothing is found.

This is in dmesg:

10333.767993] pci_bus 0000:02: Allocating resources
[10333.768022] pci_bus 0000:03: Allocating resources
[10333.768067] pci_bus 0000:04: Allocating resources
[10333.768088] pci_bus 0000:05: Allocating resources
[10333.768110] pci_bus 0000:06: Allocating resources
[10333.768131] pci_bus 0000:0e: Allocating resources
[10333.769245] acpi device:41: Cannot transition to power state D3hot for parent in (unknown)
[11907.580572] perf: interrupt took too long (3970 > 3931), lowering kernel.perf_event_max_sample_rate to 50250
// HERE MY WIRELESS DOESN'T WORK
[17905.231408] atkbd serio0: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0). // HERE I DISABLE THE WIRELESS WITH HARDWARE SWITCH
[17905.231413] atkbd serio0: Use 'setkeycodes e008 <keycode>' to make it known.
[17905.531437] usb 2-1.5: USB disconnect, device number 4
[17905.886507] iwlwifi 0000:03:00.0: RF_KILL bit toggled to disable radio.
[17905.886509] iwlwifi 0000:03:00.0: reporting RF_KILL (radio disabled)
[17905.892858] wlp3s0: deauthenticating from 4e:d9:e7:b9:60:55 by local choice (Reason: 3=DEAUTH_LEAVING)
[17910.412050] atkbd serio0: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0). // HERE I ENABLE THE WIRELESS WITH HARDWARE SWITCH
[17910.412052] atkbd serio0: Use 'setkeycodes e008 <keycode>' to make it known.
[17910.460159] iwlwifi 0000:03:00.0: RF_KILL bit toggled to enable radio.
[17910.460161] iwlwifi 0000:03:00.0: reporting RF_KILL (radio enabled)
[17910.747403] usb 2-1.5: new full-speed USB device number 5 using ehci-pci
[17910.857982] usb 2-1.5: New USB device found, idVendor=8087, idProduct=07dc, bcdDevice= 0.01
[17910.857987] usb 2-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[17910.874236] Bluetooth: hci0: read Intel version: 370710018002030d00
[17910.874324] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
[17911.093375] Bluetooth: hci0: Intel firmware patch completed and activated
// HERE MY WIRELESS WORKS AGAIN

It's very strange, because before Ubuntu 19.04 I never had to do this.... and with GNOME Shell it's a pain, because it's not easy to disconnect/reconnect to the wireless, when you are connected, even if nothing works, he consider that all is ok (except he put a "?" on the wireless icon), and you can't click to "disconnect" or "reconnect" on the AP List.
I precise that on Windows, or with my phone, there is no problems on the same AP.

It's very strange, but to post this message, I need to reconnect 3 or 5 times....while my phone has no problems...

Revision history for this message
Valentin Crone (va-crone) wrote :

After checking, this second problem is not related to the original bug, but with the AP.
Please, ignore my posts #5 and #6

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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