Bug 1936171 - kernel panic during boot on 5.11.3-50.fc33.x86_64
Summary: kernel panic during boot on 5.11.3-50.fc33.x86_64
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 33
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-07 10:26 UTC by Freddy Willemsen
Modified: 2021-03-29 21:26 UTC (History)
24 users (show)

Fixed In Version: kernel-5.11.9-300.fc34 kernel-5.11.9-200.fc33 kernel-5.11.10-100.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-26 00:16:43 UTC
Type: Bug


Attachments (Terms of Use)
requested journalctl. (112.08 KB, text/plain)
2021-03-07 10:26 UTC, Freddy Willemsen
no flags Details
journalctl of working 5.10 boot (102 bytes, text/plain)
2021-03-07 10:28 UTC, Freddy Willemsen
no flags Details
rdsosreport of booot using rd.break=cleanup (1.75 MB, text/plain)
2021-03-07 10:29 UTC, Freddy Willemsen
no flags Details
journalctl of booot using rd.break=cleanup (94.72 KB, text/plain)
2021-03-07 10:29 UTC, Freddy Willemsen
no flags Details
dmesg dell 7710 (101.28 KB, text/plain)
2021-03-18 21:03 UTC, Chris Murphy
no flags Details
dmesg during modprobe dell_wmi_sysman (113.92 KB, text/plain)
2021-03-21 00:07 UTC, Freddy Willemsen
no flags Details

Description Freddy Willemsen 2021-03-07 10:26:08 UTC
Created attachment 1761251 [details]
requested journalctl.

1. Please describe the problem:
On my main laptop (Dell Latitude E5570, BIOS 1.23.3 since april 2020) kernel-5.11 panics during boot. A Latitude 5480, Latitude E5510 and some old Asus laptop boot just fine. I am using a cleanly installed Fedora 33 on XFS.
After a day of debugging (disabling SMT, disabling Wifi, disabling ethernet, disabling audio, etc) I managed to boot using acpi=off. Tried acpi_osi=Windows, acpi=ht, pci=noacpi, acpi=noirq, pnpacpi=off, noapci, nolapic , acpi=strict as well, none of them work, only acpi=off boots (though giving me a single core computer without SMT).

2. What is the Version-Release number of the kernel:
Currently 5.11.3-50.fc33.x86_64. I recompiled all fc34 5.11 kernels as well, same issue.

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
All 5.11 kernels exhibit this behaviour. All 5.10 kernels work fine. I even tried 5.12 (kernel-rawhide-nodebug) and that one works as well.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Boot with any 5.11 kernel.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
No, kernel-5.12.0-0.rc1.162.fc35.x86_64 boots fine.

6. Are you running any modules that not shipped with directly Fedora's kernel?:
Tried with and without, no change.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Comment 1 Freddy Willemsen 2021-03-07 10:28:02 UTC
Created attachment 1761252 [details]
journalctl of working 5.10 boot

Comment 2 Freddy Willemsen 2021-03-07 10:29:01 UTC
Created attachment 1761253 [details]
rdsosreport of booot using rd.break=cleanup

Comment 3 Freddy Willemsen 2021-03-07 10:29:37 UTC
Created attachment 1761254 [details]
journalctl of booot using rd.break=cleanup

Comment 4 Freddy Willemsen 2021-03-07 10:36:14 UTC
Used rd.break up to cleanup to figure out where the panic occurs. It seems to appear right after the the rd phase, during the sysinit.target.

Tried using 'acpi.debug_layer=0x2 acpi.debug_level=0xffffffff' as well but CONFIG_ACPI_DEBUG is not set.

I can not really figure out why every bit of hardware works just fine, except for my main laptop, which serves me well for over 4 years now.

Comment 5 Freddy Willemsen 2021-03-07 10:43:50 UTC
Not sure if it is relevant, but I copied the root disk to an external USB drive. Then booting 5.11 on my Dell E5570 it panics, using the same disk on a Dell 5480 it works just fine.

Comment 6 Freddy Willemsen 2021-03-10 10:56:49 UTC
Both kernel-5.11.4-50.fc33 and kernel-5.11.5-50.fc33 exhibit the exact same behavior, no change there.

Comment 7 Freddy Willemsen 2021-03-17 22:51:38 UTC
no changes for kernel-5.11.7-200.fc33, still panics on boot. 
kernel-5.12.0-0.rc3.170.fc35.x86_64 from kernel-rawhide-nodebug does work in general (not thoroughly tested).

Comment 8 ryanpg 2021-03-18 20:16:06 UTC
I had the same issue on a Dell Inc. Precision 7710 and kernel 5.11.3-300.fc34.x86_64. It was resolved with 5.12.0-0.rc3.20210318git6417f03132a6.171.fc35.x86_64 which boots fine

Comment 9 Chris Murphy 2021-03-18 21:03:54 UTC
Created attachment 1764477 [details]
dmesg dell 7710

Goes with c8.

In common with original report:

[    5.718740] kernel: dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.4)
[    5.718967] kernel: stack segment: 0000 [#1] SMP PTI
[    5.718970] kernel: CPU: 6 PID: 651 Comm: systemd-udevd Not tainted 5.11.6-300.fc34.x86_64 #1
[    5.718972] kernel: Hardware name: Dell Inc. Precision 7710/01KDY8, BIOS 1.21.3 08/04/2020
[    5.718974] kernel: RIP: 0010:kobject_put+0x19/0x1d0
[    5.718977] kernel: Code: c7 c7 40 df d2 b6 e8 46 c3 fe ff eb d6 0f 1f 40 00 48 85 ff 0f 84 b4 00 00 00 41 56 41 55 41 54 55 48 89 fd 53 bb ff ff ff ff <f6> 45 3c 01 0f 84 80 00 00 00 48 8d 7d 38 89 d8 f0 0f c1 45 38 83
[    5.718979] kernel: RSP: 0018:ffffabaa00443da8 EFLAGS: 00010282
[    5.718981] kernel: RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 0000000000000000
[    5.718983] kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: d53e78a8f6bc94ea
[    5.718984] kernel: RBP: d53e78a8f6bc94ea R08: 0000000000000001 R09: 0000000000000000
[    5.718985] kernel: R10: ffff8c9ec2a28400 R11: 0000000000000001 R12: d53e78a8f6bc94ea
[    5.718986] kernel: R13: 000055cdab559fe6 R14: 00007f06dbd2032c R15: ffffabaa00443e88
[    5.718988] kernel: FS:  00007f06dafbfb40(0000) GS:ffff8ca23dd80000(0000) knlGS:0000000000000000
[    5.718989] kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    5.718991] kernel: CR2: 000055cdab555b28 CR3: 0000000106734001 CR4: 00000000003706e0
[    5.718992] kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    5.718993] kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    5.718995] kernel: Call Trace:
[    5.718997] kernel:  kset_unregister+0x25/0x40
[    5.718999] kernel:  ? 0xffffffffc07bb000
[    5.719001] kernel:  sysman_init+0x20a/0x1000 [dell_wmi_sysman]
[    5.719006] kernel:  do_one_initcall+0x44/0x1d0
[    5.719009] kernel:  ? do_init_module+0x23/0x270
[    5.719012] kernel:  ? kmem_cache_alloc_trace+0xef/0x1e0
[    5.719015] kernel:  do_init_module+0x5c/0x270
[    5.719017] kernel:  __do_sys_init_module+0x11d/0x180
[    5.719019] kernel:  do_syscall_64+0x33/0x40
[    5.719023] kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[    5.719025] kernel: RIP: 0033:0x7f06dbbcd44e

Offhand I'm not seeing what might be fixing it in 5.12...

Looks related to this:
https://bugzilla.kernel.org/show_bug.cgi?id=211895

Comment 10 Freddy Willemsen 2021-03-19 14:05:59 UTC
I tried the proposed patch from the bug report at kernel.org to no avail. As suggested there, adding 'modprobe.blacklist=dell_wmi_sysman' to the boot options makes kernel-5.11.7-200.fc33 bootable.

Comment 11 Jared Dominguez 2021-03-19 21:30:21 UTC
Perry, can you take a look at this?

Comment 12 Hans de Goede 2021-03-19 22:04:36 UTC
> Perry, can you take a look at this?

Note a fix for this has been posted upstream, but as I mentioned during the review, the fix contains a bug and a new fixed version of the fix is necessary:

https://patchwork.kernel.org/project/platform-driver-x86/patch/20210218191723.20030-1-mario.limonciello@dell.com/#23988825

Comment 13 Perry Yuan (Dell) 2021-03-20 14:42:10 UTC
(In reply to Jared Dominguez from comment #11)
> Perry, can you take a look at this?

This was one sysman driver crash issue that has been fixed by the patch Hans mentioned.
Seeing from Comment 9 , this seems like is a new issue of sysman driver

Comment 14 Hans de Goede 2021-03-20 18:57:32 UTC
I've prepared and posted a set of patches which deal with various problems with error-exit path cleanups and general robustness of the dell-wmi-sysman driver:

https://lore.kernel.org/platform-driver-x86/20210320143429.76047-1-hdegoede@redhat.com/T/#t

Note it is not entirely clear to me what is going on here, so I'm not sure if these patches fix things but hopefully they will help.

I've started a Fedora kernel test-build with these patches added here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=64195453

Note this is still building ATM it should be done in about 2 hours.

See here for generic instructions for installing a kernel directly from koji (the Fedora build-system):
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Please give this kernel a test and let me know if it fixes things.

Perry, can you please test this test-build on hardware which actually supports the new WMI interfaces used by dell-wmi-sysman and checks that the dell-wmi-sysman still works correctly on that hardware?

###

What would also be helpful, independent of testing the patches, is if someone could boot a 5.11 kernel with dell-wmi-sysman blacklisted to avoid the problem.

And then:

1. Switch to a text-console
2. ssh into the machine and run dmesg -w
3. ssh into the machine a second time and run: "sudo modprobe dell_wmi_sysman dyndbg"

And then collect log info from the "dmesg -w" and in case there are log messages on the text-console which did not make it into the ssh dmesg -w output, make a picture of those.

Comment 15 Hans de Goede 2021-03-20 19:50:28 UTC
Note the scratch/test kernel-build has completed building now, if someone can give this a test on one of the machines where 5.11 does not work that would be great.

Perry, can you please test this test-build on hardware which actually supports the new WMI interfaces used by dell-wmi-sysman and checks that the dell-wmi-sysman still works correctly on that hardware?

Comment 16 Freddy Willemsen 2021-03-21 00:07:16 UTC
Created attachment 1764959 [details]
dmesg during modprobe dell_wmi_sysman

Comment 17 Freddy Willemsen 2021-03-21 00:08:17 UTC
Tried the scratch build on a Dell Latitude E5570 and it boots fine. dell_wmi_sysman is loaded after boot.

dmesg | grep -i wmi
[    2.724671] wmi_bus wmi_bus-PNP0C14:01: WQBC data block query control method not found
[    2.724813] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
[    2.743025] acpi PNP0C14:03: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
[    8.132832] input: Dell WMI hotkeys as /devices/platform/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input17
[   10.708045] Modules linked in: iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ccm des_generic libdes ip_set nf_tables nfnetlink cmac ip6table_filter bnep ip6_tables md4 iptable_filter uvcvideo vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) snd_usb_audio(+) videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common ee1004 videodev snd_usbmidi_lib snd_rawmidi btusb btrtl btbcm btintel bluetooth iTCO_wdt intel_pmc_bxt iTCO_vendor_support mei_wdt mei_hdcp mc sunrpc ppdev intel_rapl_msr ecdh_generic ecc dell_laptop dell_smm_hwmon snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp iwlmvm snd_hda_codec_realtek kvm_intel snd_soc_skl snd_hda_codec_generic ledtrig_audio snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match mac80211 snd_soc_acpi snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core snd_compress snd_pcm_dmaengine soundwire_cadence

Tried the scratch build on a Dell Latitude 5480 and it boots fine as well. dell_wmi_sysman is not loaded after boot.

dmesg | grep -i wmi
[    1.834480] wmi_bus wmi_bus-PNP0C14:01: WQBC data block query control method not found
[    5.521307] input: Dell WMI hotkeys as /devices/platform/PNP0C14:01/wmi_bus/wmi_bus-PNP0C14:01/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input11

Comment 18 Hans de Goede 2021-03-21 11:08:49 UTC
Freddy, thank you for the tests and for the dmesg which you've attached on the kernel bugzilla.

I think I have a good idea now of why the crash is happening,
but I do still have a few more questions:

1. Can you do (while running the patched kernel):

ls -lR /sys/class/firmware-attributes/dell-wmi-sysman/

On the system where the driver actually loads (E5570) and copy and paste the output here ?

I wonder if the driver actually does anything there, or if one of my patches is wrong causing an empty "firmware-attributes" device to show up there.

2. Can you, with the patched-kernel do a "sudo modprobe dell_wmi_sysman dyndbg" on the system where the driver does not load (5480) and then collect dmesg output after that ?

3. When you boot an unpatched kernel on the 5480, does lsmod show dell_wmi_sysman being loaded? I think it may simply never load on that devices because it does not have the WMI GUIDs which the driver binds to.

4. Can you do: "ls /sys/bus/wmi/devices/" on the 5480 and copy and paste the output here?

Comment 19 Freddy Willemsen 2021-03-21 11:44:13 UTC
Here is the requested info. Let me know if you need anything else.

1. Can you do (while running the patched kernel):

ls -lR /sys/class/firmware-attributes/dell-wmi-sysman/
/sys/class/firmware-attributes/dell-wmi-sysman/:
total 0
drwxr-xr-x. 2 root root    0 21 mrt 12:37 attributes
drwxr-xr-x. 4 root root    0 21 mrt 12:37 authentication
drwxr-xr-x. 2 root root    0 21 mrt 12:37 power
lrwxrwxrwx. 1 root root    0 21 mrt 12:34 subsystem -> ../../../../class/firmware-attributes
-rw-r--r--. 1 root root 4096 21 mrt 12:33 uevent

/sys/class/firmware-attributes/dell-wmi-sysman/attributes:
total 0
-r--r--r--. 1 root root 4096 21 mrt 12:37 pending_reboot
-rw-r--r--. 1 root root 4096 21 mrt 12:37 reset_bios

/sys/class/firmware-attributes/dell-wmi-sysman/authentication:
total 0
drwxr-xr-x. 2 root root 0 21 mrt 12:37 Admin
drwxr-xr-x. 2 root root 0 21 mrt 12:37 System

/sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin:
total 0
--w-------. 1 root root 4096 21 mrt 12:37 current_password
-r--r--r--. 1 root root 4096 21 mrt 12:37 is_enabled
-r--r--r--. 1 root root 4096 21 mrt 12:37 max_password_length
-r--r--r--. 1 root root 4096 21 mrt 12:37 mechanism
-r--r--r--. 1 root root 4096 21 mrt 12:37 min_password_length
--w-------. 1 root root 4096 21 mrt 12:37 new_password
-r--r--r--. 1 root root 4096 21 mrt 12:37 role

/sys/class/firmware-attributes/dell-wmi-sysman/authentication/System:
total 0
--w-------. 1 root root 4096 21 mrt 12:37 current_password
-r--r--r--. 1 root root 4096 21 mrt 12:37 is_enabled
-r--r--r--. 1 root root 4096 21 mrt 12:37 max_password_length
-r--r--r--. 1 root root 4096 21 mrt 12:37 mechanism
-r--r--r--. 1 root root 4096 21 mrt 12:37 min_password_length
--w-------. 1 root root 4096 21 mrt 12:37 new_password
-r--r--r--. 1 root root 4096 21 mrt 12:37 role

/sys/class/firmware-attributes/dell-wmi-sysman/power:
total 0
-rw-r--r--. 1 root root 4096 21 mrt 12:37 autosuspend_delay_ms
-rw-r--r--. 1 root root 4096 21 mrt 12:37 control
-r--r--r--. 1 root root 4096 21 mrt 12:37 runtime_active_time
-r--r--r--. 1 root root 4096 21 mrt 12:37 runtime_status
-r--r--r--. 1 root root 4096 21 mrt 12:37 runtime_suspended_time

2. Can you, with the patched-kernel do a "sudo modprobe dell_wmi_sysman dyndbg" on the system where the driver does not load (5480) and then collect dmesg output after that ?

modprobe: ERROR: could not insert 'dell_wmi_sysman': No such device

3. When you boot an unpatched kernel on the 5480, does lsmod show dell_wmi_sysman being loaded? I think it may simply never load on that devices because it does not have the WMI GUIDs which the driver binds to.

lsmod | grep -i dell
dell_rbtn              20480  0
dell_laptop            28672  0
ledtrig_audio          16384  2 snd_hda_codec_generic,dell_laptop
dell_smm_hwmon         24576  0
dell_wmi               20480  0
dell_smbios            32768  2 dell_wmi,dell_laptop
dcdbas                 20480  1 dell_smbios
dell_wmi_descriptor    20480  2 dell_wmi,dell_smbios
rfkill                 28672  8 bluetooth,dell_laptop,dell_rbtn,cfg80211
dell_smo8800           20480  0
sparse_keymap          16384  2 intel_hid,dell_wmi
video                  53248  3 dell_wmi,dell_laptop,i915
dell_wmi_sysman        49152  0
wmi                    36864  6 dell_wmi_sysman,intel_wmi_thunderbolt,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor

4. Can you do: "ls /sys/bus/wmi/devices/" on the 5480 and copy and paste the output here?

ls /sys/bus/wmi/devices/
05901221-D566-11D1-B2F0-00A0C9062910  8D9DDCBC-A997-11DA-B012-B622A1EF5492  A80593CE-A997-11DA-B012-B622A1EF5492
86CCFD48-205E-4A77-9C48-2021CBEDE341  9DBB5994-A997-11DA-B012-B622A1EF5492

Comment 20 Hans de Goede 2021-03-21 12:20:39 UTC
(In reply to Freddy Willemsen from comment #19)
> Here is the requested info. Let me know if you need anything else.

Thank you.

> 1. Can you do (while running the patched kernel):

<snip>

> /sys/class/firmware-attributes/dell-wmi-sysman/attributes:
> total 0
> -r--r--r--. 1 root root 4096 21 mrt 12:37 pending_reboot
> -rw-r--r--. 1 root root 4096 21 mrt 12:37 reset_bios

Ok, so this is as I expected, your BIOS seems to advertise the functionality to set BIOS settings from within the OS, but it does not list any actual settings to change (which is what triggered the crash before). Interestingly enough it does seem to allow changing the BIOS-passwords from within the OS.

I'm not sure if that is intentional on Dell's side or not. I'll discuss with Dell how to proceed with this bit of the issue.

I've dropped the patch which allows the driver to still load even though there are no "attributes" to set for now; and I'll submit a merge-req to get the other patches (which will still fix the crash) added to the Fedora 5.11 kernels, so that affected machines will boot again.

Comment 21 Freddy Willemsen 2021-03-21 12:30:37 UTC
No problem, glad to be of service. Thanks for all the efforts in squashing this bug.
Look forward to the patched 5.11 fedora kernels.

Comment 22 Hans de Goede 2021-03-21 18:58:18 UTC
Here is the merge-req for getting the fixes for this added to the Fedora 5.11 kernels:
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/978

Comment 23 Perry Yuan (Dell) 2021-03-22 05:33:06 UTC
(In reply to Hans de Goede from comment #14)
> I've prepared and posted a set of patches which deal with various problems
> with error-exit path cleanups and general robustness of the dell-wmi-sysman
> driver:
> 
> https://lore.kernel.org/platform-driver-x86/20210320143429.76047-1-
> hdegoede@redhat.com/T/#t
> 
> Note it is not entirely clear to me what is going on here, so I'm not sure
> if these patches fix things but hopefully they will help.
> 
> I've started a Fedora kernel test-build with these patches added here:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=64195453
> 
> Note this is still building ATM it should be done in about 2 hours.
> 
> See here for generic instructions for installing a kernel directly from koji
> (the Fedora build-system):
> https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
> 
> Please give this kernel a test and let me know if it fixes things.
> 
> Perry, can you please test this test-build on hardware which actually
> supports the new WMI interfaces used by dell-wmi-sysman and checks that the
> dell-wmi-sysman still works correctly on that hardware?
> 
> ###
> 
> What would also be helpful, independent of testing the patches, is if
> someone could boot a 5.11 kernel with dell-wmi-sysman blacklisted to avoid
> the problem.
> 
> And then:
> 
> 1. Switch to a text-console
> 2. ssh into the machine and run dmesg -w
> 3. ssh into the machine a second time and run: "sudo modprobe
> dell_wmi_sysman dyndbg"
> 
> And then collect log info from the "dmesg -w" and in case there are log
> messages on the text-console which did not make it into the ssh dmesg -w
> output, make a picture of those.

Hi Hans
I got one sample which support sysman feature and will do the testing On Monday today. 
Dell have a new BIOS fixing previous driver issue and I need to flash the BIOS then i can test your kernel.


Perry

Comment 24 Perry Yuan (Dell) 2021-03-22 05:35:44 UTC
Hans.
I saw you update your patch to V2.
Could you share the V2 test kernel koji link ?
I can help to test that version as well.

Comment 25 Hans de Goede 2021-03-22 09:38:01 UTC
(In reply to Perry Yuan (Dell) from comment #24)
> Hans.
> I saw you update your patch to V2.
> Could you share the V2 test kernel koji link ?
> I can help to test that version as well.

The biggest difference in v2 is that I dropped this patch:
https://patchwork.kernel.org/project/platform-driver-x86/patch/20210321121607.35717-1-hdegoede@redhat.com/

Because that patch needs more testing, the rest is the same as v1, so please test the v1 kernel which actually has that patch:
https://koji.fedoraproject.org/koji/taskinfo?taskID=64195453

Comment 26 Perry Yuan (Dell) 2021-03-22 11:08:20 UTC
Tested Hans V1 test kernel on Dell new Mobile platform which flashed with new BIOS
The sysman driver works well and no issue found on that kernel.


[root@localhost dell-wmi-sysman]# uname -r
5.11.7-300.bz1936171.fc34.x86_64


BIOS Information
        Vendor: Dell Inc.
        Version: 0.2.37
        Release Date: 03/10/2021
        ROM Size: 32 MB


[root@localhost dell-wmi-sysman]# ls attributes/
Absolute                 Camera                 FullScreenLogo           PasswordLock               SignOfLifeByDisplay        UefiBootPathSecurity
AdminSetupLockout        CapsuleFirmwareUpdate  GraphicSpecMode          PeakShiftBatteryThreshold  SignOfLifeByKbdBacklight   UefiNwStack
AdvancedMode             ChasIntrusion          HttpsBoot                PeakShiftCfg               SmartErrors                UnobtrusiveMode
AdvBatteryChargeCfg      ChassisIntrusionReset  HttpsBootMode            pending_reboot             SmmSecurityMitigation      UsbEmu
AllowBiosDowngrade       ClearDellRmtLog        HybridGraphics           PostMebxKey                SpeedShift                 UsbPortsExternal
AmtCap                   CpuCore                IntegratedAudio          PowerLogClear              Speedstep                  UsbPowerShare
Asset                    CStatesCtrl            IntelTME                 PowerOnLidOpen             StrongPassword             UsbProvision
AutoOn                   CustomChargeStart      InternalSpeaker          PowerWarn                  SupportAssistOSRecovery    VideoPowerOnlyPorts
AutoOnFri                CustomChargeStop       KbdBacklightTimeoutAc    PrimaryBattChargeCfg       SupportAssistSupportLevel  Virtualization
AutoOnHr                 DellCoreService        KbdBacklightTimeoutBatt  PwdDigitRqd                SvcTag                     VtForDirectIo
AutoOnMn                 DeviceHotkeyAccess     KeyboardIllumination     PwdLowerCaseRqd            TelemetryAccessLvl         WakeOnAc
AutoOnMon                DisUsb4Pcie            LogicProc                PwdMinLen                  ThermalLogClear            WakeOnDock
AutoOnSat                DRmt                   M2PcieSsd0               PwdSpecialCharRqd          ThermalManagement          WakeOnLan
AutoOnSun                DynTunML               M2PcieSsd1               PwdUpperCaseRqd            ThunderboltBoot            WarningsAndErr
AutoOnThur               EmbNic1                M2PcieSsd2               RemoteWipeInternalDrives   ThunderboltPorts           WirelessLan
AutoOnTue                EmbSataRaid            MacAddrPassThru          reset_bios                 ThunderboltPreboot         WirelessWwan
AutoOnWed                ExtPostTime            MasterPasswordLockout    SdCard                     TpmPpiClearOverride        WlanAutoSense
AutoOSRecoveryThreshold  Fastboot               MicMuteLed               SdCardBoot                 TpmSecurity                WwanAutoSense
BIOSConnect              FingerprintReader      Microphone               SdCardReadOnly             TrustExecution
BiosLogClear             FnLock                 Nfc                      SecureBoot                 TurboMode
BiosRcvrFrmHdd           FnLockMode             NonAdminPsidRevert       SecureBootMode             TypeCDockAudio
BlockSleep               ForceLpmAspmOff        NumLock                  SHA256                     TypeCDockLan
BluetoothDevice          FOTA                   PasswordBypass           SignOfLifeByAudio          TypeCDockOverride

Comment 27 Hans de Goede 2021-03-22 15:46:27 UTC
Perry, thank you for testing this. I'll send a pull-req to Linus with the fixes soon. Once those have landed I'll add a comment that the fixes are now upstream to bug 1941416.

Comment 28 Fedora Update System 2021-03-24 14:58:57 UTC
FEDORA-2021-e636ce53df has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e636ce53df

Comment 29 Freddy Willemsen 2021-03-24 15:13:00 UTC
kernel-5.11.9-200.fc33 contains the patches from Hans and solves the issue without the blacklist workaround, tested on a Dell Latitude E5570 and a Latitude 5480. A big thanks to everybody involved!
As far as I am concerned this one can be closed.

Comment 30 Fedora Update System 2021-03-25 01:23:55 UTC
FEDORA-2021-e636ce53df has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e636ce53df`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e636ce53df

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 31 Fedora Update System 2021-03-25 01:31:57 UTC
FEDORA-2021-68b0dd2373 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-68b0dd2373`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-68b0dd2373

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 32 Fedora Update System 2021-03-25 02:07:24 UTC
FEDORA-2021-25441d8137 has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-25441d8137`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-25441d8137

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 33 Alexandre Ducastaing 2021-03-25 10:11:38 UTC
Hi all!
My laptop Dell Vostro 1510 doesn't boot on kernel 5.11. kernel-5.11.9-200.fc33.x86_64 doesn't solve it.
BIOS Information
	Vendor: Dell Inc.
	Version: A15
	Release Date: 03/18/2009
	Address: 0xE5080
	Runtime Size: 110464 bytes
	ROM Size: 64 kB
Regards.

Comment 34 Fedora Update System 2021-03-26 00:16:43 UTC
FEDORA-2021-e636ce53df has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 35 Fedora Update System 2021-03-26 17:53:01 UTC
FEDORA-2021-68b0dd2373 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 36 Fedora Update System 2021-03-27 02:05:57 UTC
FEDORA-2021-9503fffad9 has been pushed to the Fedora 32 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-9503fffad9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-9503fffad9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 37 Fedora Update System 2021-03-29 01:11:54 UTC
FEDORA-2021-9503fffad9 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.