Created attachment 254291 [details] dmesg On a Dell Latitude E5550 with the latest firmware (A14) and kernel version (4.9.8), I observe the following errors on boot: [ +0,028261] i801_smbus 0000:00:1f.3: PCI INT C: failed to register GSI [ +0,000003] i801_smbus 0000:00:1f.3: Failed to enable SMBus PCI device (-16) [ +0,001429] i801_smbus: probe of 0000:00:1f.3 failed with error -16 The corresponding device is 00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03) Subsystem: Dell Device 062c Flags: medium devsel, IRQ 255 Memory at f7340000 (64-bit, non-prefetchable) [size=256] I/O ports at f040 [size=32] Kernel modules: i2c_i801 dmesg output is attached.
Same on other models E7450 (mine), E5450 [1], 3340 (and also E6440). It's always PCI ID 00:1f.3 it seems. I have tracked this down to another device using the same IRQ. It appears dell_smo8800 (freefall sensor) is using same IRQ (gsi=18 in my case), and looking at the driver it cannot be shared (+ driver doesn't have any hardware set up, it. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1415950 [2] https://www.reddit.com/r/archlinux/comments/5nx448/i801_smbus_failed_error_help_debug_and_understand/
Just rmmod'ing dell_smo8800 doesn't fix it though. My hack to make it work was to patch acpi_register_gsi_ioapic() to skip it. With this, i801_smbus initialized correctly, and i2cdetect was able to use that i2c bus. +++ b/arch/x86/kernel/acpi/boot.c @@ -653,6 +653,12 @@ static int acpi_register_gsi_ioapic(struct device *dev, u32 gsi, int node; struct irq_alloc_info info; +#if 1 + if (dev == NULL && gsi == 18) { + // HACK to skip smo8800 + return -ENODEV; + } +#endif node = dev ? dev_to_node(dev) : NUMA_NO_NODE; trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1; polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1; I've tried investigating further what actually calls acpi_register_gsi_ioapic(NULL, 18, ...), by putting WARN() in there, and got this output: [ 0.504572] (NULL device *): XXX acpi_register_gsi_ioapic: gsi:18, trigger:0, polarity: 0; irq:18 [ 0.504653] acpi_register_gsi_ioapic [ 0.504657] ------------[ cut here ]------------ [ 0.504779] WARNING: CPU: 1 PID: 1 at arch/x86/kernel/acpi/boot.c:667 acpi_register_gsi_ioapic+0x1b0/0x1c0 [ 0.504862] Modules linked in: [ 0.504919] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc3+ #12 [ 0.504983] Hardware name: Dell Inc. Latitude E7450/0R1VJD, BIOS A17 08/01/2017 [ 0.505060] task: ffff9783d4a10040 task.stack: ffffae8080c98000 [ 0.505124] RIP: 0010:acpi_register_gsi_ioapic+0x1b0/0x1c0 [ 0.505185] RSP: 0000:ffffae8080c9b9b8 EFLAGS: 00010286 [ 0.505247] RAX: 0000000000000018 RBX: 0000000000000012 RCX: ffffffffa3a4b008 [ 0.505312] RDX: 0000000000000000 RSI: 0000000000000086 RDI: 0000000000000247 [ 0.505376] RBP: ffffae8080c9ba20 R08: 0000000000000018 R09: 00000000000004c4 [ 0.505441] R10: 0000000000000040 R11: 0000000000000018 R12: 0000000000000000 [ 0.505505] R13: 0000000000000012 R14: 0000000000000000 R15: 0000000000000000 [ 0.505570] FS: 0000000000000000(0000) GS:ffff9783de480000(0000) knlGS:0000000000000000 [ 0.505649] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.505711] CR2: 0000000000000000 CR3: 00000000d4609001 CR4: 00000000003606e0 [ 0.505776] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 0.505841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 0.505905] Call Trace: [ 0.505965] acpi_register_gsi+0xf/0x20 [ 0.506027] acpi_dev_get_irqresource.part.5+0x74/0x170 [ 0.506089] ? acpi_dev_resource_address_space+0x31/0x70 [ 0.506152] acpi_dev_resource_interrupt+0xbb/0xd0 [ 0.506213] acpi_dev_process_resource+0xf1/0x120 [ 0.506274] ? acpi_res_consumer_cb+0x110/0x110 [ 0.506336] acpi_walk_resource_buffer+0xc4/0x115 [ 0.506397] ? acpi_res_consumer_cb+0x110/0x110 [ 0.506457] acpi_walk_resources+0xfb/0x149 [ 0.506518] __acpi_dev_get_resources+0xb7/0xf0 [ 0.506579] ? set_debug_rodata+0x17/0x17 [ 0.506639] acpi_dev_get_resources+0x15/0x20 [ 0.506700] acpi_create_platform_device+0x9e/0x2d0 [ 0.506762] ? __pm_runtime_idle+0x55/0x80 [ 0.506822] ? __device_attach+0x63/0x160 [ 0.508002] ? set_debug_rodata+0x17/0x17 [ 0.508062] acpi_default_enumeration+0x2e/0x40 [ 0.508123] acpi_bus_attach+0x1d0/0x210 [ 0.508183] acpi_bus_attach+0x95/0x210 [ 0.508242] acpi_bus_attach+0x95/0x210 [ 0.508302] acpi_bus_attach+0x95/0x210 [ 0.508362] acpi_bus_scan+0x47/0x90 [ 0.508421] acpi_scan_init+0xe5/0x235 [ 0.508481] acpi_init+0x2f6/0x354 [ 0.508540] ? acpi_sleep_proc_init+0x2a/0x2a [ 0.508601] do_one_initcall+0x52/0x1a0 [ 0.508660] ? set_debug_rodata+0x17/0x17 [ 0.508720] kernel_init_freeable+0x16e/0x1f6 [ 0.508781] ? rest_init+0xb0/0xb0 [ 0.508840] kernel_init+0xe/0xfc [ 0.508899] ret_from_fork+0x25/0x30 [ 0.508957] Code: 00 44 89 e7 89 de 88 45 a6 e8 fd 7c 00 00 48 8d 7d a0 88 45 a7 e8 91 77 00 00 e9 44 ff ff ff 48 c7 c7 10 7b 60 a3 e8 31 07 09 00 <0f> ff e9 fa fe ff ff e8 e4 0c 03 00 0f 1f 40 00 0f 1f 44 00 00 [ 0.509092] ---[ end trace 3d2444d8893babd2 ]--- At this point I'm a bit stuck. ACPI platform device (smo8800) seems to be interfering with i2c-i801 bus master. I'm also confused by smo8800 driver using just the IRQ, no HW registers, not even to turn the IRQ on or off. Could that IRQ even be shared? Are there ways to remap it? (This all was tested on 4.14.0-rc3 from a week ago or so)
There's quite a long thread titled "[PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines", which should provide some background to smo8800 and smbus_i801: https://www.spinics.net/lists/linux-i2c/msg27779.html If I understood correctly smbus provides access to accelerometer, but IRQ is used only for freefall detection. Not sure why pcim_enable_device() fails in i2c-i801 driver, it appears to be a recent (or limited to some devices maybe?) issue, or they would have noticed it back then already.
Hi, Sorry for altering more than 2 years old thread, but I have the same problem on the same computer DELL E5550, firmware A21, kernel 4.19 and 5.2.4 - same problem on both. I have been searching forums, bug lists, but no good solution found yet. I have also tried to apply patch mentioned in here https://www.spinics.net/lists/linux-i2c/msg27779.html but it didn't help. I've tried it on 5.2.4 kernel. So, I was wondering if there is any good solution to this problem.
The i2c-i801 driver CAN use a shared IRQ. But the error messages suggest that the problem happens even before the i2c-i801 driver requests the IRQ. The error happens on pci_enable_device(). GSI are new to me, maybe the kernel doesn't allow sharing these? From the stack trace in comment #2, it seems that acpi_register_gsi_ioapic(NULL, 18, ...) is being called by the ACPI code at boot time, presumably based on ACPI table data provided by the BIOS. So I guess we will need to get ACPI table dumps from one of the affected laptops. Can someone affected please run acpidump, pack the generated files in a tarball and attach it to this bug? I'm also curious if whatever registered GSI 18 at boot time does show up in /proc/interrupts . Pali, I know you are somewhat familiar with the smo8800 driver - at least more than me. What do you think?
*** Bug 204511 has been marked as a duplicate of this bug. ***
I do not think this is a problem with dell_smo8800. dell_smo8800 driver just acquire one IRQ which signals when laptop falls (and propagate it to userspace). It does not do any initialization or any other logic. And I doubt that something else is interested and needs to acquire special IRQ for signaling laptop fall. That IRQ is not used for anything else. So this seems to be a problem either in linux ACPI implementation or some bogus data in ACPI DSDT tables. Or there may be resource conflict between i2c-i801 and definitions in ACPI tables. To debug this problem we really need dump of ACPI tables.
I will send ACPI dump later today from my E5550. I just wanted to add, that I have tried now on kernel 5.3-rc3 and problem is exactly the same. I saw, that code from commits mentioned in comment #1 are already implemented in kernel 5.3-rc3, but problem is still the same. Even though support for "Subsystem: Dell Wildcat Point-LP SMBus Controller [1028:062c]" was added. I have also tried to disable dell_smo8800 as stated in comment #2, but I've got different error during booting (stated below). Nevertheless freefall sensor was working and when I was physically turning laptop 90 degrees, screen view was also turning automatically. Also, I've got some settings in Gnome 3 available for turning display. Faults, mentioned above are here (module dell_smo8800 was blacklisted at the time): [ 2.665125] irq 18: nobody cared (try booting with the "irqpoll" option) ... [ 2.665215] handlers: [ 2.665221] [<0000000006acd5a6>] i801_isr [i2c_i801] [ 2.665222] Disabling IRQ #18 ... [ 15.246673] genirq: Flags mismatch irq 18. 00002001 (smo8800) vs. 00000080 (i801_smbus) [ 15.246701] smo8800 SMO8810:00: failed to request thread for IRQ 18: -16 [ 15.246761] smo8800: probe of SMO8810:00 failed with error -16
Created attachment 284235 [details] acpidump verbose output (with option -z)
Created attachment 284237 [details] Contents of /proc/interrupts
Small update to the case. I have install Linux Mint 19.2 with kernel 4.15.0-54 and I do not see any error messages in the dmesg output. Here is the only thing what I could find: [ 0.101176] pci 0000:00:1f.3: [8086:9ca2] type 00 class 0x0c0500 [ 0.101191] pci 0000:00:1f.3: reg 0x10: [mem 0xf7340000-0xf73400ff 64bit] [ 0.101207] pci 0000:00:1f.3: reg 0x20: [io 0xf040-0xf05f] Not really sure if it is working correctly or somehow error got ignored by the system. The only thing I have noticed is that view in the monitor is not turning when I turn laptop. It could be maybe connected to the fact that I use Cinnamon now, not Gnome 3 as before. I have also checked lsmod output and I can see that dell_smo8800 module is loaded: dell_smo8800 16384 0 Any ideas how to check if it is functioning or error is just hidden?
Here is another update. With the limited amount of information we have about this issue (currently only happening on Dell Latitude devices), it seems to be occuring because a driver is not supported in the Linux Kernel. If somebody takes a look at the performance on windows BEFORE installing native drivers onto the device, people notice that it is also sluggish. Many are commenting about this issue because it is severely holding back the performance of the CPU on these devices. 600 MHZ is not okay for a device that can be clocked significantly higher. Over oh the github there is a certain amount of information johnathan@sprungles:~/dell-bios-fan-control$ i8kfan speed-of-fan-n1 speed-of-fan-n2 -1 0 As seen here, the -1 value shows that one of the fans is not being read as existing. So... we are clearly missing a driver within the linux kernel.
Something else to note, the 0 is showing that the laptop supports zero span speeds, although the device itself does have fans.
If you use the following article's (https://mijorus.medium.com/thermal-tweaks-on-dell-laptops-running-linux-769c8c80022e) directions significantly improves performance. Until a patch is submitted, SELINUX will need to be set to either permissive or disabled. The fix works, but does discourage security.