Created attachment 282645 [details] Linux 5.1 messages (dmesg) On the Dell Precision 3630 tower with firmware 1.0.4 and 1.1.10, plugging in the USB C adapter Dell DA200, Linux 5.1 (and before) logs the errors below. ``` $ dmesg [ 94.265125] ACPI Error: No handler for Region [WST1] (00000000d6bc1741) [GenericSerialBus] (20190215/evregion-132) [ 94.265127] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20190215/exfldio-265) [ 94.265128] ACPI Error: Aborting method \_SB.PCI0.I2C0.PAS1 due to previous error (AE_NOT_EXIST) (20190215/psparse-531) [ 94.265131] ACPI Error: Aborting method \_GPE._L20 due to previous error (AE_NOT_EXIST) (20190215/psparse-531) [ 94.265133] ACPI Error: AE_NOT_EXIST, while evaluating GPE method [_L20] (20190215/evgpe-509) $ lsusb […] Bus 002 Device 005: ID 05e3:0617 Genesys Logic, Inc. […] ``` Is this a firmware issue? If so, could you please work with Dell to fix the firmware? Please find the full log attached.
These may help to guide it: * Other than the kernel spamming messages is there any other notable impact? Eg: Does the device work? * Do you have any other type C devices you can try? * You'll probably need to share ACPI tables for analysis.
Created attachment 282651 [details] Output of `acpidump`
This is
This seems like a gap in Linux. @mario, do you know what WST1 region is used for?
I'm also interested in this particular issue, as I'm facing the same ACPI Error messages as the OP. The only difference is that I have a Dell T40 (which basically is the same computer). I've encountered this issue on Centos/RHEL 8.x, Fedora 32, Ubuntu 18.04 LTS on the same device Dell PowerEdge T40. An yes, I'm also curious what region is WST1? Last login: Fri Aug 21 20:24:12 2020 secan@ubuntu:~$ sudo cat /etc/*lease [sudo] password for secan: DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.5 LTS" NAME="Ubuntu" VERSION="18.04.5 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.5 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic secan@ubuntu:~$ sudo dmesg | grep -iE "error|failed" [ 0.078772] ACPI Error: No handler for Region [WST1] ( (ptrval)) [GenericSerialBus] (20170831/evregion-166) [ 0.078772] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20170831/exfldio-299) [ 0.078772] ACPI Error: Method parse/execution failed \_SB.PCI0.I2C0.PAS1, AE_NOT_EXIST (20170831/psparse-550) [ 0.078772] ACPI Error: Method parse/execution failed \_GPE._L20, AE_NOT_EXIST (20170831/psparse-550) [ 0.821697] dpc 0000:00:1d.2:pcie010: DPC error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+ [ 0.830338] ERST: Error Record Serialization Table (ERST) support is initialized. [ 1.024707] RAS: Correctable Errors collector initialized. [ 1.970258] [drm] failed to retrieve link info, disabling eDP [ 3.718700] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro secan@ubuntu:~$
P.S. The issue is not encountered in Centos 7.x (kernel 3.10.x)
This seems to still be in the 5.9 kernel. (also, see link at bottom) Linux nyx 5.9.0-0.bpo.2-amd64 #1 SMP Debian 5.9.6-1~bpo10+1 (2020-11-19) x86_64 GNU/Linux System: Dell EMC Poweredge T40 BIOS: 1.4.0 (20 Nov 2020) [Thu Jan 7 21:21:19 2021] ACPI: Added _OSI(Module Device) [Thu Jan 7 21:21:19 2021] ACPI: Added _OSI(Processor Device) [Thu Jan 7 21:21:19 2021] ACPI: Added _OSI(3.0 _SCP Extensions) [Thu Jan 7 21:21:19 2021] ACPI: Added _OSI(Processor Aggregator Device) [Thu Jan 7 21:21:19 2021] ACPI: Added _OSI(Linux-Dell-Video) [Thu Jan 7 21:21:19 2021] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio) [Thu Jan 7 21:21:19 2021] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics) [Thu Jan 7 21:21:19 2021] ACPI: 9 ACPI AML tables successfully acquired and loaded [Thu Jan 7 21:21:19 2021] ACPI: Dynamic OEM Table Load: [Thu Jan 7 21:21:19 2021] ACPI: SSDT 0xFFFF907CC7790D00 0000F4 (v02 PmRef Cpu0Psd 00003000 INTL 20160527) [Thu Jan 7 21:21:19 2021] ACPI: \_SB_.PR00: _OSC native thermal LVT Acked [Thu Jan 7 21:21:19 2021] ACPI: Dynamic OEM Table Load: [Thu Jan 7 21:21:19 2021] ACPI: SSDT 0xFFFF907CC7DBC000 000400 (v02 PmRef Cpu0Cst 00003001 INTL 20160527) [Thu Jan 7 21:21:19 2021] ACPI: Dynamic OEM Table Load: [Thu Jan 7 21:21:19 2021] ACPI: SSDT 0xFFFF9083DFD80000 0006AA (v02 PmRef Cpu0Ist 00003000 INTL 20160527) [Thu Jan 7 21:21:19 2021] ACPI: Dynamic OEM Table Load: [Thu Jan 7 21:21:19 2021] ACPI: SSDT 0xFFFF9083DFE48600 000149 (v02 PmRef Cpu0Hwp 00003000 INTL 20160527) [Thu Jan 7 21:21:19 2021] ACPI: Dynamic OEM Table Load: [Thu Jan 7 21:21:19 2021] ACPI: SSDT 0xFFFF9083DFD83800 000724 (v02 PmRef HwpLvt 00003000 INTL 20160527) [Thu Jan 7 21:21:19 2021] ACPI: Dynamic OEM Table Load: [Thu Jan 7 21:21:19 2021] ACPI: SSDT 0xFFFF9083DFD84000 0005FC (v02 PmRef ApIst 00003000 INTL 20160527) [Thu Jan 7 21:21:19 2021] ACPI: Dynamic OEM Table Load: [Thu Jan 7 21:21:19 2021] ACPI: SSDT 0xFFFF907CC7DBC800 000317 (v02 PmRef ApHwp 00003000 INTL 20160527) [Thu Jan 7 21:21:19 2021] ACPI: Dynamic OEM Table Load: [Thu Jan 7 21:21:19 2021] ACPI: SSDT 0xFFFF907CC776E000 000AB0 (v02 PmRef ApPsd 00003000 INTL 20160527) [Thu Jan 7 21:21:19 2021] ACPI: Dynamic OEM Table Load: [Thu Jan 7 21:21:19 2021] ACPI: SSDT 0xFFFF907CC7DBC400 00030A (v02 PmRef ApCst 00003000 INTL 20160527) [Thu Jan 7 21:21:19 2021] ACPI: Interpreter enabled [Thu Jan 7 21:21:19 2021] ACPI: (supports S0 S5) [Thu Jan 7 21:21:19 2021] ACPI: Using IOAPIC for interrupt routing [Thu Jan 7 21:21:19 2021] HEST: Table parsing has been initialized. [Thu Jan 7 21:21:19 2021] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [Thu Jan 7 21:21:19 2021] ACPI: Enabled 11 GPEs in block 00 to 7F [Thu Jan 7 21:21:19 2021] ACPI Error: No handler for Region [WST1] (000000009223a336) [GenericSerialBus] (20200717/evregion-132) [Thu Jan 7 21:21:19 2021] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20200717/exfldio-265) [Thu Jan 7 21:21:19 2021] ACPI Error: Aborting method \_SB.PCI0.I2C0.PAS1 due to previous error (AE_NOT_EXIST) (20200717/psparse-531) [Thu Jan 7 21:21:19 2021] ACPI Error: Aborting method \_GPE._L20 due to previous error (AE_NOT_EXIST) (20200717/psparse-531) [Thu Jan 7 21:21:19 2021] ACPI Error: AE_NOT_EXIST, while evaluating GPE method [_L20] (20200717/evgpe-515) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [USBC] (on) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [V0PR] (on) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [V1PR] (on) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [V2PR] (on) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [WRST] (on) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [FN00] (off) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [FN01] (off) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [FN02] (off) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [FN03] (off) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [FN04] (off) [Thu Jan 7 21:21:19 2021] ACPI: Power Resource [PIN] (off) [Thu Jan 7 21:21:19 2021] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7e]) [Thu Jan 7 21:21:19 2021] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] NOTE: This may be related... see link https://www.dell.com/community/PowerEdge-Hardware-General/Linux-on-PowerEdge-T40-Kernel-threads-kacpi-notify-and-kacpid/m-p/7776179#M67503
The OperationRegion (WST1, GenericSerialBus, 0x1000, 0x0100) is under I2C0 device. Device (I2C0) { If ((SMD0 != One)) { Name (_HID, "INT34B2") // _HID: Hardware ID Method (_HRV, 0, NotSerialized) // _HRV: Hardware Revision { Return (LHRV (SB10)) } Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Return (LCRS (SMD0, SB00, SIR0)) } } If ((SMD0 == One)) { Name (_ADR, 0x00150000) // _ADR: Address Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method { If (PCIC (Arg0)) { Return (PCID (Arg0, Arg1, Arg2, Arg3)) } Return (Buffer (One) { 0x00 // . }) } } It seems that this device can be enumerated either as an ACPI device or as native PCI device, via a switch SMD0. So can you please attach the lspci output and see if it is enumerated as PCI device 00:15.0? if yes, please attach the lspci -vvx -s 00:15.0? if no, can you please check if there is /sys/bus/acpi/devices/INT34B2:0 device, and if there is any driver binding to it? Plus, please check your BIOS options and if there is anything related with switching between "ACPI enumeration mode" and "PCI enumeration mode".
@secan, as you have a different model, please file a separate bug and attach the acpidump.
@Zhang, as you've suggested, I've opened a new bug report with the requested output and acpidump: https://bugzilla.kernel.org/show_bug.cgi?id=213323
On Wed, 2021-06-02 at 20:47 -0700, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=203529 > > --- Comment #8 from Zhang Rui (rui.zhang@intel.com) --- > The > OperationRegion (WST1, GenericSerialBus, 0x1000, 0x0100) > is under I2C0 device. > --Code Sniped-- > > It seems that this device can be enumerated either as an ACPI device > or as > native PCI device, via a switch SMD0. > > So can you please attach the lspci output and see if it is enumerated > as PCI > device 00:15.0? if yes, please attach the lspci -vvx -s 00:15.0? > if no, can you please check if there is > /sys/bus/acpi/devices/INT34B2:0 device, > and if there is any driver binding to it? > > Plus, please check your BIOS options and if there is anything related > with > switching between "ACPI enumeration mode" and "PCI enumeration mode". > Here is the output from lspci: # lspci -vvx -s 00:15.0 00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH Serial IO I2C Controller (rev 10) Subsystem: Dell Cannon Lake PCH Serial IO I2C Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 22 Region 0: Memory at 4000118000 (64-bit, non-prefetchable) [size=4K] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1- ,D2-,D3hot-,D3cold-) Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Vendor Specific Information: Len=14 <?> Kernel driver in use: intel-lpss Kernel modules: intel_lpss_pci 00: 86 80 68 a3 06 01 10 00 10 00 80 0c 10 00 80 00 10: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 5b 09 30: 00 00 00 00 80 00 00 00 00 00 00 00 ff 01 00 00 A /sys/bus/acpi/devices/INT34B2:0 device does not exist. The folloing do exist though: INT34B0:00/ INT34B1:00/ INT34B3:00/ INT34B4:00/ INT34B5:00/ INT34B6:00/ INT34B7:00/ INT34B8:00/ INT34B9:00/ INT34BA:00/ INT34BC:00/ Neither the BIOS or manual have any setting regarding ACPI. -- john
(In reply to John Darrah from comment #11) > On Wed, 2021-06-02 at 20:47 -0700, bugzilla-daemon@bugzilla.kernel.org > wrote: ... > A /sys/bus/acpi/devices/INT34B2:0 device does not exist. > > The folloing do exist though: > INT34B0:00/ INT34B1:00/ INT34B3:00/ INT34B4:00/ INT34B5:00/ INT34B6:00/ > INT34B7:00/ INT34B8:00/ INT34B9:00/ INT34BA:00/ INT34BC:00/ I have sent a patch [1] to enable support of these (but see below, after PS). [1]: https://lore.kernel.org/lkml/20210603165128.46586-1-andriy.shevchenko@linux.intel.com/ P.S. It's not related directly to the issue here, but can you check if it makes any difference? (Usually we run `grep -H 15 /sys/bus/acpi/devices/*/status` to see what the devices are enumerated via ACPI by BIOS)
On Fri, 2021-06-04 at 07:57 -0700, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=203529 > > Andy Shevchenko (andy.shevchenko@gmail.com) changed: > > What |Removed |Added > ------------------------------------------------------------------- > --------- > CC| > |andy.shevchenko@gmail.com > > --- Comment #12 from Andy Shevchenko (andy.shevchenko@gmail.com) --- > (In reply to John Darrah from comment #11) > > On Wed, 2021-06-02 at 20:47 -0700, > > bugzilla-daemon@bugzilla.kernel.org > > wrote: > > ... > > > A /sys/bus/acpi/devices/INT34B2:0 device does not exist. > > > > The folloing do exist though: > > INT34B0:00/ INT34B1:00/ INT34B3:00/ INT34B4:00/ INT34B5:00/ > > INT34B6:00/ > > INT34B7:00/ INT34B8:00/ INT34B9:00/ INT34BA:00/ INT34BC:00/ > > I have sent a patch [1] to enable support of these (but see below, > after PS). > > [1]: > > https://lore.kernel.org/lkml/20210603165128.46586-1-andriy.shevchenko@linux.intel.com/ > > P.S. It's not related directly to the issue here, but can you check > if it makes > any difference? > > (Usually we run `grep -H 15 /sys/bus/acpi/devices/*/status` to see > what the > devices are enumerated via ACPI by BIOS) > Here is the output: # grep -H 15 /sys/bus/acpi/devices/*/status /sys/bus/acpi/devices/ACPI000C:00/status:15 /sys/bus/acpi/devices/INT33A1:00/status:15 /sys/bus/acpi/devices/INT340E:00/status:15 /sys/bus/acpi/devices/INT3F0D:00/status:15 /sys/bus/acpi/devices/LNXPOWER:00/status:15 /sys/bus/acpi/devices/PNP0103:00/status:15 /sys/bus/acpi/devices/PNP0501:00/status:15 /sys/bus/acpi/devices/PNP0B00:00/status:15 /sys/bus/acpi/devices/PNP0C0C:00/status:15 -- john
(In reply to John Darrah from comment #13) > On Fri, 2021-06-04 at 07:57 -0700, bugzilla-daemon@bugzilla.kernel.org > wrote: ... > > (Usually we run `grep -H 15 /sys/bus/acpi/devices/*/status` to see > > what the > > devices are enumerated via ACPI by BIOS) > > > Here is the output: > > # grep -H 15 /sys/bus/acpi/devices/*/status > > /sys/bus/acpi/devices/ACPI000C:00/status:15 > /sys/bus/acpi/devices/INT33A1:00/status:15 > /sys/bus/acpi/devices/INT340E:00/status:15 > /sys/bus/acpi/devices/INT3F0D:00/status:15 > /sys/bus/acpi/devices/LNXPOWER:00/status:15 > /sys/bus/acpi/devices/PNP0103:00/status:15 > /sys/bus/acpi/devices/PNP0501:00/status:15 > /sys/bus/acpi/devices/PNP0B00:00/status:15 > /sys/bus/acpi/devices/PNP0C0C:00/status:15 None of the INT34Bx device is enabled on your machine (my patch must have no effect on anything).
Hello, Same output on Dell PowerEdge T40: [root@vHost ~]# grep -H 15 /sys/bus/acpi/devices/*/status /sys/bus/acpi/devices/ACPI000C:00/status:15 /sys/bus/acpi/devices/INT0E0C:00/status:15 /sys/bus/acpi/devices/INT33A1:00/status:15 /sys/bus/acpi/devices/INT340E:00/status:15 /sys/bus/acpi/devices/INT3F0D:00/status:15 /sys/bus/acpi/devices/LNXPOWER:00/status:15 /sys/bus/acpi/devices/PNP0103:00/status:15 /sys/bus/acpi/devices/PNP0501:00/status:15 /sys/bus/acpi/devices/PNP0B00:00/status:15 /sys/bus/acpi/devices/PNP0C0C:00/status:15 [root@vHost ~]#
(In reply to Andy Shevchenko from comment #14) > (In reply to John Darrah from comment #13) > > On Fri, 2021-06-04 at 07:57 -0700, bugzilla-daemon@bugzilla.kernel.org > > wrote: > > ... > > > > (Usually we run `grep -H 15 /sys/bus/acpi/devices/*/status` to see > > > what the > > > devices are enumerated via ACPI by BIOS) > > > > > Here is the output: > > > > # grep -H 15 /sys/bus/acpi/devices/*/status > > > > /sys/bus/acpi/devices/ACPI000C:00/status:15 > > /sys/bus/acpi/devices/INT33A1:00/status:15 > > /sys/bus/acpi/devices/INT340E:00/status:15 > > /sys/bus/acpi/devices/INT3F0D:00/status:15 > > /sys/bus/acpi/devices/LNXPOWER:00/status:15 > > /sys/bus/acpi/devices/PNP0103:00/status:15 > > /sys/bus/acpi/devices/PNP0501:00/status:15 > > /sys/bus/acpi/devices/PNP0B00:00/status:15 > > /sys/bus/acpi/devices/PNP0C0C:00/status:15 > > None of the INT34Bx device is enabled on your machine (my patch must have no > effect on anything). Hi, Andy, thanks for the patch, can you be more specific about what the problem is? you're expecting bit5 to be set in this case?
Plus, the ACPI Errors are gone with Andy's patch, right? @secan, @ John Darrah @Paul Menzel
(In reply to Zhang Rui from comment #17) > Plus, the ACPI Errors are gone with Andy's patch, right? That’s from comment 12. > @secan, @ John Darrah @Paul Menzel Unfortunately, I do not have access to the device, as it’s in use by a user. It’d be great if somebody else could test it.
Hello, I'm willing and available to test the patch, just please show me (instruct me) how? :-)
(In reply to secan from comment #19) > I'm willing and available to test the patch, just please show me (instruct > me) how? :-) What distribution do you use?
RHEL 8.4
(In reply to secan from comment #19) > Hello, > > I'm willing and available to test the patch, just please show me (instruct > me) how? :-) If you are talking about patch from comment #12, read comment #14 before doing anything. Rui, please also read that. TL;DR: my patch must not have any effect.
Device (I2C0) Name (_HID, "INT34B2") // _HID: Hardware ID So the _STA of INT34B2 device does not return 15. please attach the output of grep . /sys/bus/acpi/devices/INT34*/status
Here you go mister: [root@vHost ~]# grep . /sys/bus/acpi/devices/INT34*/status /sys/bus/acpi/devices/INT340E:00/status:15 /sys/bus/acpi/devices/INT3420:00/status:0 /sys/bus/acpi/devices/INT3450:00/status:0 /sys/bus/acpi/devices/INT346F:00/status:0 /sys/bus/acpi/devices/INT346F:01/status:0 /sys/bus/acpi/devices/INT346F:02/status:0 /sys/bus/acpi/devices/INT346F:03/status:0 /sys/bus/acpi/devices/INT346F:04/status:0 /sys/bus/acpi/devices/INT346F:05/status:0 /sys/bus/acpi/devices/INT346F:06/status:0 /sys/bus/acpi/devices/INT346F:07/status:0 /sys/bus/acpi/devices/INT346F:08/status:0 /sys/bus/acpi/devices/INT3471:00/status:0 /sys/bus/acpi/devices/INT3474:00/status:0 /sys/bus/acpi/devices/INT34B0:00/status:0 /sys/bus/acpi/devices/INT34B1:00/status:0 /sys/bus/acpi/devices/INT34B3:00/status:0 /sys/bus/acpi/devices/INT34B4:00/status:0 /sys/bus/acpi/devices/INT34B5:00/status:0 /sys/bus/acpi/devices/INT34B6:00/status:0 /sys/bus/acpi/devices/INT34B7:00/status:0 /sys/bus/acpi/devices/INT34B8:00/status:0 /sys/bus/acpi/devices/INT34B9:00/status:0 /sys/bus/acpi/devices/INT34BA:00/status:0 /sys/bus/acpi/devices/INT34BC:00/status:0 [root@vHost ~]#
(In reply to secan from comment #21) > RHEL 8.4 I am never used RHEL. The guide on LinuxConfig.org [1] documents it for Fedora. Basically, clone the Linux source tree, $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git apply the patch from here, install the dependencies for the Linux kernel, and execute $ cp /boot/config… .config (tab complete to the running config) $ make oldconfig $ make localmodconfig # if your machine is slow only build loaded modules $ make -j$(nproc) binrpm-pkg Install the packages with yum(?). [1]: https://linuxconfig.org/how-to-compile-vanilla-linux-kernel-from-source-on-fedora
(In reply to Paul Menzel from comment #25) > (In reply to secan from comment #21) > > RHEL 8.4 > > I am never used RHEL. The guide on LinuxConfig.org [1] documents it for > Fedora. Basically, clone the Linux source tree, > > $ git clone > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > apply the patch from here, install the dependencies for the Linux kernel, > and execute > > $ cp /boot/config… .config (tab complete to the running config) > $ make oldconfig > $ make localmodconfig # if your machine is slow only build loaded modules > $ make -j$(nproc) binrpm-pkg > > Install the packages with yum(?). > > > [1]: > https://linuxconfig.org/how-to-compile-vanilla-linux-kernel-from-source-on- > fedora Thanks Paul, but as Andy stated, the patch provided by him won't help, as the devices are not even enumerated. Let's wait Zhang Rui's reply on the output requested from me.
If ((SMD0 != One)) { Name (_HID, "INT34B2") // _HID: Hardware ID Method (_HRV, 0, NotSerialized) // _HRV: Hardware Revision { Return (LHRV (SB10)) } Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Return (LCRS (SMD0, SB00, SIR0)) } } If ((SMD0 == One)) { Name (_ADR, 0x00150000) // _ADR: Address Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method { If (PCIC (Arg0)) { Return (PCID (Arg0, Arg1, Arg2, Arg3)) } Return (Buffer (One) { 0x00 // . }) } } So I think the device is enumerated as a PCI device. please attach the output of grep . /sys/bus/pci/devices/0000\:00\:15.0/firmware_node/*/path
On Mon, 2021-06-14 at 20:05 -0700, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=203529 > > --- Comment #27 from Zhang Rui (rui.zhang@intel.com) --- > If ((SMD0 != One)) > { > Name (_HID, "INT34B2") // _HID: Hardware ID > Method (_HRV, 0, NotSerialized) // _HRV: Hardware Revision > { > Return (LHRV (SB10)) > } > > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource > Settings > { > Return (LCRS (SMD0, SB00, SIR0)) > } > } > > If ((SMD0 == One)) > { > Name (_ADR, 0x00150000) // _ADR: Address > Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method > { > If (PCIC (Arg0)) > { > Return (PCID (Arg0, Arg1, Arg2, Arg3)) > } > > Return (Buffer (One) > { > 0x00 // > . > }) > } > } > > So I think the device is enumerated as a PCI device. > > please attach the output of > grep . /sys/bus/pci/devices/0000\:00\:15.0/firmware_node/*/path > Here's the output # grep . /sys/bus/pci/devices/0000\:00\:15.0/firmware_node/*/path /sys/bus/pci/devices/0000:00:15.0/firmware_node/INT3515:00/path:\_SB_.PCI0.I2C0.UCMX /sys/bus/pci/devices/0000:00:15.0/firmware_node/MAX34407:00/path:\_SB_.PCI0.I2C0.PA01 /sys/bus/pci/devices/0000:00:15.0/firmware_node/XXXX0000:00/path:\_SB_.PCI0.I2C0.TPD0 /sys/bus/pci/devices/0000:00:15.0/firmware_node/XXXX0000:01/path:\_SB_.PCI0.I2C0.TPL1 -- john
Hello, here's my output too: /sys/bus/pci/devices/0000:00:15.0/firmware_node/INT3515:00/path:\_SB_.PCI0.I2C0.UCMX /sys/bus/pci/devices/0000:00:15.0/firmware_node/MAX34407:00/path:\_SB_.PCI0.I2C0.PA01 /sys/bus/pci/devices/0000:00:15.0/firmware_node/XXXX0000:00/path:\_SB_.PCI0.I2C0.TPD0 /sys/bus/pci/devices/0000:00:15.0/firmware_node/XXXX0000:01/path:\_SB_.PCI0.I2C0.TPL1 BR, Cristian
But my guess is that the device is not enumerated at all: [root@vHost ~]# find /* | grep -i int34b2 [root@vHost ~]# BR, Cristian
Hi, Andy, I'm not quite familiar with how IC2 controller/devices are enumerated. But for the current problem, OperationRegion (WST1) is located under _SB.PCI0.I2C0, but all the firmware_nodes of the I2C0 device are _SB.PCI0.I2C0 child devices. I'm not sure what ACPI_COMPANION is, for pci device 00:15.0, and I'm not sure if this will make the current I2C code fail to install the address space handler for WST1, can you please clarify?
John and secan, please run "grep . /sys/bus/acpi/devices/*/path | grep I2C0", to find out which acpi device is the _SB.PCI0.I2C0 device. Say, if it is /sys/bus/acpi/devices/device:80, and then please attach the output of the below command, "ll /sys/bus/acpi/devices/device:80/" I just want to make clear how the ACPI glue code works.
*** Bug 213323 has been marked as a duplicate of this bug. ***
Hello Zhang, As requested, here's the output: grep . /sys/bus/acpi/devices/*/path | grep I2C0 /sys/bus/acpi/devices/device:81/path:\_SB_.PCI0.I2C0 /sys/bus/acpi/devices/INT3515:00/path:\_SB_.PCI0.I2C0.UCMX /sys/bus/acpi/devices/MAX34407:00/path:\_SB_.PCI0.I2C0.PA01 /sys/bus/acpi/devices/XXXX0000:00/path:\_SB_.PCI0.I2C0.TPD0 /sys/bus/acpi/devices/XXXX0000:01/path:\_SB_.PCI0.I2C0.TPL1 ll /sys/bus/acpi/devices/device:80/ total 0 -r--r--r--. 1 root root 4096 Jun 15 22:27 adr -r--r--r--. 1 root root 4096 Jun 15 22:26 path drwxr-xr-x. 2 root root 0 Jun 14 03:40 power drwxr-xr-x. 2 root root 0 Jun 14 03:40 power_resources_D0 drwxr-xr-x. 2 root root 0 Jun 14 03:40 power_resources_D3hot -r--r--r--. 1 root root 4096 Jun 15 22:27 power_state -r--r--r--. 1 root root 4096 Jun 15 22:27 real_power_state lrwxrwxrwx. 1 root root 0 Jun 14 05:23 subsystem -> ../../../../../../bus/acpi -rw-r--r--. 1 root root 4096 Jun 14 05:23 uevent BR, Cristian
ll /sys/bus/acpi/devices/device:81/ total 0 drwxr-xr-x. 3 root root 0 Jun 14 05:23 INT3515:00 drwxr-xr-x. 3 root root 0 Jun 14 05:23 MAX34407:00 drwxr-xr-x. 3 root root 0 Jun 14 05:23 XXXX0000:00 drwxr-xr-x. 3 root root 0 Jun 14 05:23 XXXX0000:01 -r--r--r--. 1 root root 4096 Jun 14 21:52 adr -r--r--r--. 1 root root 4096 Jun 14 21:52 path lrwxrwxrwx. 1 root root 0 Jun 14 21:52 physical_node -> ../../../../pci0000:00/0000:00:15.0 lrwxrwxrwx. 1 root root 0 Jun 14 21:52 physical_node1 -> ../../../../pci0000:00/0000:00:15.0/idma64.0 lrwxrwxrwx. 1 root root 0 Jun 14 21:52 physical_node2 -> ../../../../pci0000:00/0000:00:15.0/i2c_designware.0 lrwxrwxrwx. 1 root root 0 Jun 14 21:52 physical_node3 -> ../../../../pci0000:00/0000:00:15.0/i2c_designware.0/i2c-8 drwxr-xr-x. 2 root root 0 Jun 14 03:40 power -r--r--r--. 1 root root 4096 Jun 14 21:52 power_state lrwxrwxrwx. 1 root root 0 Jun 14 05:23 subsystem -> ../../../../../bus/acpi -rw-r--r--. 1 root root 4096 Jun 14 05:23 uevent drwxr-xr-x. 3 root root 0 Jun 14 05:23 wakeup BR, Cristian
(In reply to Zhang Rui from comment #31) > Hi, Andy, > I'm not quite familiar with how IC2 controller/devices are enumerated. > > But for the current problem, > > OperationRegion (WST1) is located under _SB.PCI0.I2C0, but all the > firmware_nodes of the I2C0 device are _SB.PCI0.I2C0 child devices. I'm not > sure what ACPI_COMPANION is, for pci device 00:15.0, and I'm not sure if > this will make the current I2C code fail to install the address space > handler for WST1, can you please clarify? ACPI Companion for 00:15.0 is the device which has _ADR 0x00150000. And according to ACPI tables it's \_SB.PCI0.I2C0. This represents physical device that has been split to two inside intel-lpss-pci.c (MFD driver for LPSS devices). The MFD driver shares firmware node of the parent device with its children (i.e. iDMA 64-bit and DesignWare I2C drivers). I2C core assigns address space handler in the case that it's an ACPI enumerated device or device which has an ACPI companion. So, you need to get sure that https://elixir.bootlin.com/linux/latest/source/drivers/i2c/i2c-core-acpi.c#L716 is called and called with correct parameters. Perhaps some ACPI debug option will print you this (I believe ACPICA and ACPI has that kind of options).
On Wed, 2021-06-16 at 00:13 -0700, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=203529 > > --- Comment #32 from Zhang Rui (rui.zhang@intel.com) --- > John and secan, > please run "grep . /sys/bus/acpi/devices/*/path | grep I2C0", to find > out which > acpi device is the _SB.PCI0.I2C0 device. Say, if it is > /sys/bus/acpi/devices/device:80, and then please attach the output of > the below > command, > > "ll /sys/bus/acpi/devices/device:80/" > > I just want to make clear how the ACPI glue code works. > Here you go: # grep . /sys/bus/acpi/devices/*/path | grep I2C0 /sys/bus/acpi/devices/device:81/path:\_SB_.PCI0.I2C0 /sys/bus/acpi/devices/INT3515:00/path:\_SB_.PCI0.I2C0.UCMX /sys/bus/acpi/devices/MAX34407:00/path:\_SB_.PCI0.I2C0.PA01 /sys/bus/acpi/devices/XXXX0000:00/path:\_SB_.PCI0.I2C0.TPD0 /sys/bus/acpi/devices/XXXX0000:01/path:\_SB_.PCI0.I2C0.TPL1 -- john
On Wed, 2021-06-16 at 00:13 -0700, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=203529 > > --- Comment #32 from Zhang Rui (rui.zhang@intel.com) --- > John and secan, > please run "grep . /sys/bus/acpi/devices/*/path | grep I2C0", to find > out which > acpi device is the _SB.PCI0.I2C0 device. Say, if it is > /sys/bus/acpi/devices/device:80, and then please attach the output of > the below > command, > > "ll /sys/bus/acpi/devices/device:80/" > > I just want to make clear how the ACPI glue code works. > I guess I should have read the whole email first... here's the 2ns try: # grep . /sys/bus/acpi/devices/*/path | grep I2C0 /sys/bus/acpi/devices/device:81/path:\_SB_.PCI0.I2C0 /sys/bus/acpi/devices/INT3515:00/path:\_SB_.PCI0.I2C0.UCMX /sys/bus/acpi/devices/MAX34407:00/path:\_SB_.PCI0.I2C0.PA01 /sys/bus/acpi/devices/XXXX0000:00/path:\_SB_.PCI0.I2C0.TPD0 /sys/bus/acpi/devices/XXXX0000:01/path:\_SB_.PCI0.I2C0.TPL1 # uname -a Linux nyx 5.10.0-0.bpo.5-amd64 #1 SMP Debian 5.10.24-1~bpo10+1 (2021-03-29) x86_64 GNU/Linux # ll /sys/bus/acpi/devices/device:81/ total 0 -r--r--r-- 1 root root 4096 Jun 14 20:36 adr drwxr-xr-x 3 root root 0 Jun 11 21:04 INT3515:00 drwxr-xr-x 3 root root 0 Jun 11 21:04 MAX34407:00 -r--r--r-- 1 root root 4096 Jun 14 20:36 path lrwxrwxrwx 1 root root 0 Jun 14 20:36 physical_node -> ../../../../pci0000:00/0000:00:15.0 lrwxrwxrwx 1 root root 0 Jun 14 20:36 physical_node1 -> ../../../../pci0000:00/0000:00:15.0/idma64.0 lrwxrwxrwx 1 root root 0 Jun 14 20:36 physical_node2 -> ../../../../pci0000:00/0000:00:15.0/i2c_designware.0 lrwxrwxrwx 1 root root 0 Jun 14 20:36 physical_node3 -> ../../../../pci0000:00/0000:00:15.0/i2c_designware.0/i2c-1 drwxr-xr-x 2 root root 0 Jun 14 20:36 power -r--r--r-- 1 root root 4096 Jun 14 20:36 power_state lrwxrwxrwx 1 root root 0 Jun 11 21:04 subsystem -> ../../../../../bus/acpi -rw-r--r-- 1 root root 4096 Jun 11 21:04 uevent drwxr-xr-x 3 root root 0 Jun 11 21:04 wakeup drwxr-xr-x 3 root root 0 Jun 11 21:04 XXXX0000:00 drwxr-xr-x 3 root root 0 Jun 11 21:04 XXXX0000:01 -- john
Created attachment 297409 [details] Debug patch for I²C ACPI handler Please, try to build kernel with the attached patch (v5.13-rc6 based will be okay) and `initcall_debug` added to the kernel command line. We will see if the handler is ever being attached to the I²C controllers.
I would definetly do that, it's just that this is above my skills level. Andy can you please instruct me how to do that? If I use kernel 4.18 is it doable? John Darrah, could you test the patch/workaround provided by Andy?
(In reply to secan from comment #40) > I would definetly do that, it's just that this is above my skills level. > Andy can you please instruct me how to do that? If I use kernel 4.18 is it > doable? John Darrah, could you test the patch/workaround provided by Andy? Pretty much it's explained in comment #25. On top of that: 1. https://unix.stackexchange.com/questions/115620/configuring-compiling-and-installing-a-custom-linux-kernel/ 2. https://kernelnewbies.org/FAQ 3. https://stackoverflow.com/questions/8865731/how-to-get-started-with-linux-kernel-development
Hello Andy, So this is what I did. Due to the fact that Redhat is very peculiar when it comes to patching, I went the kpatch way (the method that RH recommends). Unfortunately the patch provided by you wasn't helpful. The ACPI enumeration happens in the early boot, way earlier than the kpatch patch is applied. Even if I modprobe the kernel module (which contains your patch) the missing device/s is/are not identified. ############################# dmesg | grep -i error [ 0.150159] ACPI Error: No handler for Region [WST1] (00000000969d0118) [GenericSerialBus] (20200925/evregion-132) [ 0.150159] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20200925/exfldio-265) [ 0.150159] ACPI Error: Aborting method \_SB.PCI0.I2C0.PAS1 due to previous error (AE_NOT_EXIST) (20200925/psparse-531) [ 0.150159] ACPI Error: Aborting method \_GPE._L20 due to previous error (AE_NOT_EXIST) (20200925/psparse-531) [ 0.150159] ACPI Error: AE_NOT_EXIST, while evaluating GPE method [_L20] (20200925/evgpe-515) ############################# dmesg | grep -i patch [ 0.832940] Loaded X.509 cert 'Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b72e3852e2014c3a676fc8' [ 5.080815] kpatch_4_18_0_305_1_1: loading out-of-tree module taints kernel. [ 5.080816] kpatch_4_18_0_305_1_1: tainting kernel with TAINT_LIVEPATCH [ 5.089046] livepatch: enabling patch 'kpatch_4_18_0_305_1_1' [ 5.090621] livepatch: 'kpatch_4_18_0_305_1_1': starting patching transition [ 6.752031] livepatch: 'kpatch_4_18_0_305_1_1': patching complete [ 7.126082] livepatch_patch_c: module verification failed: signature and/or required key missing - tainting kernel [ 7.159381] livepatch: enabling patch 'livepatch_patch_c' [ 7.172030] livepatch: 'livepatch_patch_c': starting patching transition [ 8.736457] livepatch: 'livepatch_patch_c': patching complete ############################# lsmod | grep -i patch livepatch_patch_c 16384 1 kpatch_4_18_0_305_1_1 24576 1 ############################# lspci -vvx -s 00:15 00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH Serial IO I2C Controller #0 (rev 10) DeviceName: Onboard - Other Subsystem: Dell Device 095b Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 255 Region 0: Memory at 4000014000 (64-bit, non-prefetchable) [disabled] [size=4K] Capabilities: [80] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D3 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Vendor Specific Information: Len=14 <?> 00: 86 80 68 a3 00 01 10 00 10 00 80 0c 10 00 80 00 10: 04 40 01 00 40 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 28 10 5b 09 30: 00 00 00 00 80 00 00 00 00 00 00 00 ff 01 00 00 As I am new to all these kernel patching, it might also be that I didn't apply the patch as I should (I don't know) Any other hints/tips/tricks/workarounds/patches ? :)
(In reply to secan from comment #42) > So this is what I did. Due to the fact that Redhat is very peculiar when it > comes to patching, I went the kpatch way (the method that RH recommends). kpatch sounds to me the like incorrect method for testing most of the early boot / boot stage problems. You need to recompile the kernel. > Unfortunately the patch provided by you wasn't helpful. Not sure I understood this comment. The patch I shared is not going to fix anything, it's pure for debugging purposes to understand better the cause of the issue. > lspci -vvx -s 00:15 > > 00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH > Serial IO I2C Controller #0 (rev 10) > DeviceName: Onboard - Other > Subsystem: Dell Device 095b > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- > <MAbort- >SERR- <PERR- INTx- > Interrupt: pin A routed to IRQ 255 This line make me think about other causes. Can you boot your kernel with 'initcall_debug ignore_loglevel pci=earlydump' added to the kernel command line and attach the output of `dmesg`? > Any other hints/tips/tricks/workarounds/patches ? :)
Hello Andy, As requested, I've added the kernel boot flags, and attached the "dmesg" output.
Created attachment 297577 [details] dmesg log
(In reply to secan from comment #44) > Hello Andy, > > As requested, I've added the kernel boot flags, and attached the "dmesg" > output. Okay, in your case device seems to be disabled. Of course it won't have WST1 OpRegion attached. We probably need the output (with patch applied! You haven't done this yet, unfortunately) from working case in according to comment #11 by @John Darrah.
Hello Andy, I've managed to reconpile the server with the patch that you've provided me. I also switched distros from RHEL to Fedora 34 (to have a more recent kernel). The behaviour is the same. I also attached the dmesg as suggested.
Created attachment 297589 [details] dmesg1
Thanks! Now, you see there: [ 0.480354] ACPI: Enabled 11 GPEs in block 00 to 7F [ 0.480493] ACPI Error: No handler for Region [WST1] (00000000dfea9681) [GenericSerialBus] (20210105/evregion-130) [ 0.480493] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20210105/exfldio-261) [ 0.480493] ACPI Error: Aborting method \_SB.PCI0.I2C0.PAS1 due to previous error (AE_NOT_EXIST) (20210105/psparse-529) [ 0.480493] ACPI Error: Aborting method \_GPE._L20 due to previous error (AE_NOT_EXIST) (20210105/psparse-529) [ 0.480493] ACPI Error: AE_NOT_EXIST, while evaluating GPE method [_L20] (20210105/evgpe-511) followed be [ 2.013045] intel-lpss 0000:00:15.0: enabling device (0100 -> 0102) [ 2.017563] ACPI: \_SB_.PCI0.I2C0: i2c_acpi_install_space_handler: i2c-0 This is obviously due to ordering at the boot time. At the boot time the _L20 is in low state and hence tries to call the handler. We have 'acpi_mask_gpe=<N>', where <N> is number of GPE to mask at boot time, which may halp here. The initial bug report is about "plugging a USB Type C adapter in". Can you do the same and check if there is any error reported. Ideally this needs to be checked on the vanilla kernel (v5.13-rc7 as of today).
Hello Andy, So, you say that everything is working as it should, just that due to the boot order, acpi kicks that error? I've tried to boot with acpi_mask_gpe=511 but dmesg kicks me the same errors. When you N, in my particular case N is 511 (number of the GPE to be masked)?
It did work by adding acpi_mask_gpe=0x20, no more error messages related to acpi. Now, my question still stands, as "is/are the device/s recognized and fully functional"?
(In reply to secan from comment #51) > It did work by adding acpi_mask_gpe=0x20, no more error messages related to > acpi. > > Now, my question still stands, as "is/are the device/s recognized and fully > functional"? I don't know. But I think the methods actually do something which that command line parameter disabled. As written somewhere in the documentation you are supposed to unmask it via writing to sysfs file.
Isn’t this a design problem, Linux’ ACPI subsystem (or the firmware) should address? > acpi_mask_gpe= [HW,ACPI] > Due to the existence of _Lxx/_Exx, some GPEs > triggered > by unsupported hardware/firmware features can result > in > GPE floodings that cannot be automatically disabled > by > the GPE dispatcher. > This facility can be used to prevent such > uncontrolled > GPE floodings. > Format: <byte> The problem in the bug is not about flooding, is it?
(In reply to Paul Menzel from comment #53) > Isn’t this a design problem, Linux’ ACPI subsystem (or the firmware) should > address? > > > acpi_mask_gpe= [HW,ACPI] > > Due to the existence of _Lxx/_Exx, some GPEs > > triggered > > by unsupported hardware/firmware features can > result > > in > > GPE floodings that cannot be automatically disabled > > by > > the GPE dispatcher. > > This facility can be used to prevent such > > uncontrolled > > GPE floodings. > > Format: <byte> > > The problem in the bug is not about flooding, is it? I'm not sure. Scenario what I see is the following: 1. ACPI initializes GPE at the boot time quite early. 2. At that time there is no I²C host controller driver loaded and hence no ACPI space handler installed. 3. But GPE (_L20 to be precise) is active (sounds like flooding) and ACPI tries to execute the corresponding methods, but... see 2 above.
So the I²C host controller driver needs to be loaded earlier then?
(In reply to Paul Menzel from comment #55) > So the I²C host controller driver needs to be loaded earlier then? It's not possible (feasible).
Well, then Linux does have a design problem, doesn’t it? At least the log messages for the handler could be reworked, so no error level message is reported.
(In reply to Paul Menzel from comment #57) > Well, then Linux does have a design problem, doesn’t it? You may put it this way, of course... > At least the log messages for the handler could be reworked, so no error > level message is reported. I don't get what you are suggesting here. Hiding the logs doesn't cure the issue.
(In reply to Andy Shevchenko from comment #58) > (In reply to Paul Menzel from comment #57) > > Well, then Linux does have a design problem, doesn’t it? > > You may put it this way, of course... > > > At least the log messages for the handler could be reworked, so no error > > level message is reported. > > I don't get what you are suggesting here. Hiding the logs doesn't cure the > issue. If no handler is there – and that is totally valid/expected –, maybe it should be only information level as it’s not an error condition.
Reading my original post again, the USB-C adapter Dell DA200 was inserted after boot (90 s).
(In reply to Paul Menzel from comment #60) > Reading my original post again, the USB-C adapter Dell DA200 was inserted > after boot (90 s). Yeah, there are two cases when it appears at the boot time and at the connection time. The latter is really puzzling me because at that time we should have handler to be installed. Can you add a debug print to the kernel code as I mentioned in comment #36 and see when exactly the handler is installed if installed at all?
Created attachment 300001 [details] dmesg for 5.15.0-2-amd64 / Debian Here is a dmesg from a newer kernel: Linux nyx 5.15.0-2-amd64 #1 SMP Debian 5.15.5-1 (2021-11-26) x86_64 GNU/Linux -- john
(In reply to John Darrah from comment #62) > Created attachment 300001 [details] > dmesg for 5.15.0-2-amd64 / Debian It seems it lacks of any additional debug prints added into the code, so it's hardly useful, unfortunately. Either way it needs to be checked on top of v6.0-rc3 and Linux Next to be sure that the bug is still there.
An additional information from affected machines: https://www.reddit.com/r/Dell/comments/ii5oqd/dell_t40_acpi_error/ Not sure if it's helpful for USB Type-C case. We have now Linux kernel v6.1 released, which need to be confirmed that the bug is still there. Also it would be nice to know if there is a BIOS update available.
On Mon, 2022-12-12 at 07:39 -0800, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=203529 > > --- Comment #64 from Andy Shevchenko (andy.shevchenko@gmail.com) --- > An additional information from affected machines: > https://www.reddit.com/r/Dell/comments/ii5oqd/dell_t40_acpi_error/ > > Not sure if it's helpful for USB Type-C case. > > We have now Linux kernel v6.1 released, which need to be confirmed > that the bug > is still there. Also it would be nice to know if there is a BIOS > update > available. > The current Dell BIOS version is 1.9.0, which is the one currently loaded on my T40 machine. With kernel 6.0.10, the errors are still the same. I will try 6.1.x as soon as I can. -- john
So, any of you guys, have tried kernel 6.1.x. Is the error still present?
On Fri, 2023-06-23 at 03:46 -0700, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=203529 > > --- Comment #66 from secan (secancristi@gmail.com) --- > So, any of you guys, have tried kernel 6.1.x. Is the error still > present? > I am running 6.1.27 and the error it still present, although the error message has changed a little bit from the original error submitted. [Tue Jun 20 19:14:40 2023] ACPI Error: No handler for Region [WST1]((____ptrval____)) [GenericSerialBus] (20220331/evregion-130) [Tue Jun 20 19:14:40 2023] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20220331/exfldio-261) [Tue Jun 20 19:14:40 2023] ACPI Error: Aborting method \_SB.PCI0.I2C0.PAS1 due to previous error (AE_NOT_EXIST) (20220331/psparse-529) [Tue Jun 20 19:14:40 2023] ACPI Error: Aborting method \_GPE._L20 due to previous error (AE_NOT_EXIST) (20220331/psparse-529) [Tue Jun 20 19:14:40 2023] ACPI Error: AE_NOT_EXIST, while evaluating GPE method [_L20] (20220331/evgpe-511) -- john
I'm still trying to understand if these errors have any impact, or instead are just cosmetical
(In reply to secan from comment #68) > I'm still trying to understand if these errors have any impact, or instead > are just cosmetical At boot time where no dock is attached, it's just showing that platform state is inconsisten (so the GPE is active before it can be actually served in the OS, at least Linux). When the dock station is attached, then it might affect functioning (some) devices on it. I dunno. I have no schematics of the laptop, dock station and understanding how _L20 GPE is used on that platform. Maybe somebody from Dell can shed a light. In any case we have a problem somewhere (in the firmware and/or Linux) which is yet to be root caused.
Yes, but you see, we who have the Dell Poweredge T40, which is not a laptop and we do not use any usb-c device plugged in, we still receive the error message. Since we have opened this ticket, there were more then 6 BIOS updates released, and the issue is present in kernel 3.10.x, 4.19.x, 5.x and now in 6.1.x. Which is quite strange, this is a long runner. So, again, for us, who are using Dell PowerEdge T40, without any devices or peripherals plugged in the USB-C port, is this error and actual problem, or it's just a cosmetic issue in the log files (which can be solved with acpi_mask_gpe)?