Most recent kernel where this bug did not occur: none? Distribution: Fedora Core 5 Hardware Environment: HP nw8000 Notebook (SMbus: 8086:24c3) Software Environment: Problem Description: Letting kernel load i2c_i801 causes s3 resume from mem to fail. Steps to reproduce: s3 resume works perfectly if I rename the module thus preventing it ever getting loaded, and doesn't work even if I boot to init=/bin/sh then insmod and rmmod it. I previously had the i2c_i801 compiled in and then the s3 resume never worked. Having merely loaded i2c_i801 causes it to jam hard before kernel ever gets started. Caps-lock, powerbutton, everything is dead, battery removal is the only option. That makes it awfully difficult for me to debug or send any relevant information. I've tried numerous kernels ranging from mid-2.6s to 2.6.16.11 and no change there. I even tried with the pec patch I saw on lkml (http://lkml.org/lkml/2006/4/19/68) but that seemed to have no impact. This was the key element for the bug 3599 atleast for us HP nw8000 users. I'm unable to test this on any other hardware that has acpi s3 support. I'll be glad to test patches or what ever needed. I just thought I'd let you know.
Please attach the output of "lspci -v" and "lspci -n -v".
lspci -v: 00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, fast devsel, latency 0 Memory at b0000000 (32-bit, prefetchable) [size=256M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00002000-00002fff Memory behind bridge: 90400000-904fffff Prefetchable memory behind bridge: 98000000-9fffffff 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 38c0 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) (prog-if 00 [UHCI]) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 38e0 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) (prog-if 00 [UHCI]) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 3c00 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03) (prog-if 20 [EHCI]) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, medium devsel, latency 0, IRQ 10 Memory at a0000000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=05, sec-latency=32 I/O behind bridge: 00004000-00005fff Memory behind bridge: 90000000-903fffff Prefetchable memory behind bridge: 50000000-56ffffff 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03) (prog-if 8a [Master SecP PriP]) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at 3c20 [size=16] Memory at 57000000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: medium devsel I/O ports at 1200 [size=32] 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 3000 [size=256] I/O ports at 3880 [size=64] Memory at a0100000 (32-bit, non-prefetchable) [size=512] Memory at a0180000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03) (prog-if 00 [Generic]) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 3400 [size=256] I/O ports at 3800 [size=128] Capabilities: [50] Power Management version 2 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company Unknown device 08a8 Flags: bus master, 66MHz, medium devsel, latency 255, IRQ 10 Memory at 98000000 (32-bit, prefetchable) [size=128M] I/O ports at 2000 [size=256] Memory at 90400000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at 90420000 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 02:04.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) Subsystem: Compaq Computer Corporation Unknown device 00e6 Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at 90080000 (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 02:06.0 CardBus bridge: O2 Micro, Inc. OZ711M3/MC3 4-in-1 MemoryCardBus Controller Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, stepping, slow devsel, latency 168, IRQ 10 Memory at 90180000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=03, subordinate=04, sec-latency=176 Memory window 0: 50000000-51fff000 (prefetchable) Memory window 1: 58000000-59fff000 I/O window 0: 00004000-000040ff I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 0001 02:06.1 CardBus bridge: O2 Micro, Inc. OZ711M3/MC3 4-in-1 MemoryCardBus Controller Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, stepping, slow devsel, latency 168, IRQ 10 Memory at 90200000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=05, subordinate=08, sec-latency=176 Memory window 0: 52000000-53fff000 (prefetchable) Memory window 1: 5a000000-5bfff000 I/O window 0: 00004800-000048ff I/O window 1: 00004c00-00004cff 16-bit legacy interface ports at 0001 02:06.2 System peripheral: O2 Micro, Inc. OZ711Mx 4-in-1 MemoryCardBus Accelerator Subsystem: Hewlett-Packard Company nc8000 laptop Flags: slow devsel, IRQ 10 [virtual] Memory at 90280000 (32-bit, non-prefetchable) [disabled] [size=4K] Capabilities: [a0] Power Management version 2 02:06.3 CardBus bridge: O2 Micro, Inc. OZ711M3/MC3 4-in-1 MemoryCardBus Controller Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, stepping, slow devsel, latency 168, IRQ 10 Memory at 90300000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=09, subordinate=0c, sec-latency=176 Memory window 0: 54000000-55fff000 (prefetchable) Memory window 1: 5c000000-5dfff000 I/O window 0: 00005000-000050ff I/O window 1: 00005400-000054ff 16-bit legacy interface ports at 0001 02:0d.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI]) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at 90380000 (32-bit, non-prefetchable) [size=2K] Memory at 90100000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 02:0e.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705M_2 Gigabit Ethernet (rev 03) Subsystem: Hewlett-Packard Company nc8000 laptop Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 Memory at 90000000 (64-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at 56000000 [disabled] [size=64K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable-
00:00.0 0600: 8086:3340 (rev 03) Subsystem: 103c:088c Flags: bus master, fast devsel, latency 0 Memory at b0000000 (32-bit, prefetchable) [size=256M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 2.0 00:01.0 0604: 8086:3341 (rev 03) Flags: bus master, 66MHz, fast devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00002000-00002fff Memory behind bridge: 90400000-904fffff Prefetchable memory behind bridge: 98000000-9fffffff 00:1d.0 0c03: 8086:24c2 (rev 03) Subsystem: 103c:088c Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 38c0 [size=32] 00:1d.1 0c03: 8086:24c4 (rev 03) Subsystem: 103c:088c Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 38e0 [size=32] 00:1d.2 0c03: 8086:24c7 (rev 03) Subsystem: 103c:088c Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 3c00 [size=32] 00:1d.7 0c03: 8086:24cd (rev 03) (prog-if 20) Subsystem: 103c:088c Flags: bus master, medium devsel, latency 0, IRQ 10 Memory at a0000000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 0604: 8086:2448 (rev 83) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=05, sec-latency=32 I/O behind bridge: 00004000-00005fff Memory behind bridge: 90000000-903fffff Prefetchable memory behind bridge: 50000000-56ffffff 00:1f.0 0601: 8086:24cc (rev 03) Flags: bus master, medium devsel, latency 0 00:1f.1 0101: 8086:24ca (rev 03) (prog-if 8a) Subsystem: 103c:088c Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at 3c20 [size=16] Memory at 57000000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 0c05: 8086:24c3 (rev 03) Subsystem: 103c:088c Flags: medium devsel I/O ports at 1200 [size=32] 00:1f.5 0401: 8086:24c5 (rev 03) Subsystem: 103c:088c Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 3000 [size=256] I/O ports at 3880 [size=64] Memory at a0100000 (32-bit, non-prefetchable) [size=512] Memory at a0180000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:1f.6 0703: 8086:24c6 (rev 03) Subsystem: 103c:088c Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 3400 [size=256] I/O ports at 3800 [size=128] Capabilities: [50] Power Management version 2 01:00.0 0300: 1002:4e50 Subsystem: 103c:08a8 Flags: bus master, 66MHz, medium devsel, latency 255, IRQ 10 Memory at 98000000 (32-bit, prefetchable) [size=128M] I/O ports at 2000 [size=256] Memory at 90400000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at 90420000 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 02:04.0 0200: 168c:0013 (rev 01) Subsystem: 0e11:00e6 Flags: bus master, medium devsel, latency 168, IRQ 11 Memory at 90080000 (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 02:06.0 0607: 1217:7223 Subsystem: 103c:088c Flags: bus master, stepping, slow devsel, latency 168, IRQ 10 Memory at 90180000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=03, subordinate=04, sec-latency=176 Memory window 0: 50000000-51fff000 (prefetchable) Memory window 1: 58000000-59fff000 I/O window 0: 00004000-000040ff I/O window 1: 00004400-000044ff 16-bit legacy interface ports at 0001 02:06.1 0607: 1217:7223 Subsystem: 103c:088c Flags: bus master, stepping, slow devsel, latency 168, IRQ 10 Memory at 90200000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=05, subordinate=08, sec-latency=176 Memory window 0: 52000000-53fff000 (prefetchable) Memory window 1: 5a000000-5bfff000 I/O window 0: 00004800-000048ff I/O window 1: 00004c00-00004cff 16-bit legacy interface ports at 0001 02:06.2 0880: 1217:7110 Subsystem: 103c:088c Flags: slow devsel, IRQ 10 [virtual] Memory at 90280000 (32-bit, non-prefetchable) [disabled] [size=4K] Capabilities: [a0] Power Management version 2 02:06.3 0607: 1217:7223 Subsystem: 103c:088c Flags: bus master, stepping, slow devsel, latency 168, IRQ 10 Memory at 90300000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=09, subordinate=0c, sec-latency=176 Memory window 0: 54000000-55fff000 (prefetchable) Memory window 1: 5c000000-5dfff000 I/O window 0: 00005000-000050ff I/O window 1: 00005400-000054ff 16-bit legacy interface ports at 0001 02:0d.0 0c00: 104c:8023 (prog-if 10) Subsystem: 103c:088c Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at 90380000 (32-bit, non-prefetchable) [size=2K] Memory at 90100000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 02:0e.0 0200: 14e4:165e (rev 03) Subsystem: 103c:088c Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 Memory at 90000000 (64-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at 56000000 [disabled] [size=64K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable-
The problem here is that the 82801DB SMBus master is not enabled at boot time. We enable it through a PCI quirk (as we do for a dozen other similar systems, most notably Asus ones.) Unfortunately, the device gets hidden again on suspend, and for suspend-to-ram, the PCI quirks are not replayed so the device isn't restored, causing the trouble you observed. As long as the kernel offers no possibility to replay PCI quirks on resume, the only option left is to _not_ unhide the 82801 SMBus master device if ACPI sleep states support is included in the kernel. A patch doing just that was merged in Linus' tree a few days ago, and it'll be backported to -stable (2.6.16.y) too. This means that you can either have suspend or SMBus, not both, sorry. http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ce007ea59729d627f62bb5fa8c1a81e25653a0ad I'm not too sure why unloading the i2c-i801 driver doesn't make suspend-to-ram work again. Maybe because we enabled the device when loading the driver, and don't stop it on unload. Did you see an "enabling SMBus device" message in the logs when loading i2c-i801? This is a side issue anyway. Thanks for reporting. Credit go to Carl-Daniel Hailfinger for explaining and fixing this issue.
I tried the fc5 kernel 2.6.16-1.2122 which includes the fix (from 2.6.16.17) and the vanilla 2.6.16.18 with i2c-i801 built as module in both of them. It did fix it for me, the suspend-to-ram works wether load i2c-i801 or not. (obviously the i2c-i801 bus is gone, but that was whole point here, eh) I didn't notice the SMBus note wether I used a bit earlier kernel or a newer one, not atleast in dmesg when I insmodded the i2c-i801 (and the i2c-core for deps).
So, ehm... what about the people for whom both SMBus and s3 resume used to work? Is there a kernel boot-up flag that I can use to enable SMBus again? N.B. I'm currently using kernel-2.6.16-1.2111_FC5 on an HP nc6000 laptop. I'll attach my 'lspci -v' output..
Created attachment 8629 [details] lspci -v output for kernel-2.6.16-1.2111_FC5 on an HP nc6000 laptop
Perhaps I should add that s3 suspend/resume works for me only *after* using swsuspend (hibernate) at least once.
Could you perhaps see what it is that swsuspend does (pm-hibernate in FC5) such that i2c and s3 both work? If I don't do pm-hibernate first, I get the same symptoms as the bug reporter. As to the "why is this a problem": I use the temperature sensor to throttle down my CPU on overheat, which it *always* does in summer when running @ 2GHz (fan just doesn't pull it on max speed). If I don't throttle it down, the system hard-locks at 99 degrees Celsius.
Dennis, your system should never reach 99 degrees in any regular use condition. If it does, that's a hardware problem, complain to the manufacturer. Also, you should use frequency scaling rather than throttling if you can, it's more efficient. I stick my own laptop to low frequency during the summer months to limit the heat it generates. It depends on the CPU you have in your laptop, but usually blocking the few highest frequencies is sufficient to keep the CPU cool. Assuming that your laptop returns an ACPI temperature (/proc/acpi/thermal_zone) you could use that, instead of lm_sensors, to trigger throttling if you really want to do that. I don't know anything about swsuspend, pm-hibernate etc. and I just don't have the time to investigate this. If someone provides a patch addressing the issue, fine with me, but as long as it doesn't happen, SMBus and suspend are mutually exclusive on this laptop subset.
Thanks, I've managed to work around the problem using ACPI. For the CPU "throttling" I use cpuspeed. I think it actually does scaling, so I've used the wrong term, sorry. cpuspeed actually uses ACPI thermal zones as trigger. I had an older gnome sensors-applet, which didn't support ACPI yet. The current version (1.6.3 for FC5) does support it.
Alan Cox posted a patch to LKML to enable PCI quirks at resume time. This would make it possible (and supposedly safe) to use suspend and sensors at the same time. http://lkml.org/lkml/2006/11/14/161 Anyone wants to test this?
I'll give it a shot as soon as I can. (in the middle of reporting another suspend issue regarding intel8x0 loosing speakers after suspend, which a regression in 19-rc3 broke, aswell as a patch that finally should fix the infamous fan not working after suspend).
Tommi, please note that Alan's fix is in 2.6.20 already.
Just tried 2.6.20.1 and no, it doesn't fix that. Actually now with that I again have to remove the i2c_i801 module to prevent it from getting loaded. Suggestions? Does lkml need a note? Reopen the bug? Add a config option for that by-passes that or what? I'll obiously be happy to test patches or be more verbose about all this.
Tommi, what exactly is your problem with 2.6.20.1? What are you doing, what happens, what did you expect?
Jean, sorry for being overly brief about this. The 2.6.20.1 again doesn't work with i2c_i801 exactly like it was last spring when I opened this bug (#1). Having even shown the i2c_i801 to the kernel causes the fact that my laptop doesn't even begin to start waking up from the suspend. Something that's worked ok (#5) ever since you disabled it in #4. But now that the Alan's new pci quirk patch is in, I'm guessing the same i2c_i801 has now been reenabled along with acpi sleep states and I'm again experiencing the exact same symptoms. For the record the 2.6.19.4 works just fine. I don't sharper bisection is necessary, since I'm guessing you know which changes I'm probably referring to.
Your assumptions are right: the quirk enabling the i2c-i801 device has been reenabled in 2.6.20, and there's nothing to bisect as we already know this is the reason why you are experiencing the problem again. Unfortunately I am absolutely not familiar with power management, so I don't know what the problem is exactly, even less how to fix it. I'll attach a patch you can try, just in case, but don't hope too much.
Created attachment 10559 [details] Attempt to let the i801 SMBus device resume properly
Jean, I understand and I'm absolutely not trying to bug you here for a resolution, I'm cool without the smbus and given that it's a laptop acpi S3 suspend we're talking about here, it's not that unlikely that it's a "hardware issue". I just thought I'd let you know about the regression and once this hits the distributors it's possible that other similar laptop owners may come in wondering what broke their suspend. And theoretically I'm inclined to think that this bug should probably be reopened, feel free to close it should you think it's better that way. Bear in mind that earlier by "showing the i801 to the kernel" I meant that even if I reboot with init=/bin/sh, insmod i2c_i801, rmmod i2c_i801, and try the suspend cycle it won't work. So it has little to do with the i2c_i801 _suspend and/or _resume functions. It seems that it's either something that the i2c_i801 module leaves in an awkward/running state even after having been removed, or just some anomalous side-effect with the acpi. I know far too little about the power management myself, too, be of much help here either. I'll see if I can find the time to give a go at trying to strip down the i2c_i801 functionality trying to find what is it that triggers this effect. (it's just that, it's not the most hillarious thing to test, given that a boot and a suspend cycle is involved and that the suspend hangs prior to ever actually reaching kernel (judging this from the way the leds flicker and when the ide and audio usually would kick in, i.e. a lot later and after the hdd led has turned off, so the resume hangs very early, being possibly and indication of the fact that it may not have even gotten suspended properly, eh?)).
I'm fine with you reopening this bug - the bug exists for sure. But be aware that I might not have the time to work on it. Your point about the problem occuring even if i2c-i801 has been unloaded before suspend is valid, my patch will never help there. Can you please attach the output of the following command right after boot (i2c-i801 must not have been loaded): lspci -s 00:1f.3 -xxx
Created attachment 10563 [details] "lspci -s 00:1f.3 -xxx" on a HP nw8000 after init=/bin/sh boot Jean, sure, I absolutely understand and I am fine with that. :) The attachment was made using init=/bin/sh on a 2.6.20.1 running lspci -s 00:1f.3 -xxx. It won't change even when system is fully running, but then when I load the i2c_i801 module the begining of 6th line changes from "40: 05 ..." into "40: 01 ...". And stays that way ("40: 01 ...") even after unloading the module. Hope that helps.
Great, that's more or less what I suspected. Patch to come.
Created attachment 10564 [details] Restore HSTCFG register on module unload Please apply this patch, then try removing the i2c-i801 driver before a suspend/resume cycle. I expect it to work. It happens that your BIOS leaves the SMBus in I2C mode after boot, presumably because there are SPD EEPROMs on your SMBus and the BIOS needs to read memory timing information from these. I think the BIOS expects the bus to be still in I2C mode when resuming from RAM, while loading the i2c-i801 driver forces it to SMBus mode. If it does work as intended, we can try to do something similar at suspend time so that you don't even have to unload the i2c-i801 driver.
Created attachment 10565 [details] Restore HSTCFG register on suspend/resume Jean, marvellous! That's it, I quickly also tried with the suspend/resume fuctions and as suspected, they work too. No module unlading necessary, lm_sensors running just fine after a successfull S3 suspend cycle and that's something that I have never seen on this laptop before. This bug can finally be closed, eh?
Created attachment 10576 [details] Restore HSTCFG register on module unload and on suspend Great :) It's easier than I thought it would be. It looks like the pci subsystem provides helpers to save and restore the device configuration for suspend/resume, we could use this to make the code shorter and possibly more robust. Can you please give a try to this new patch?
Jean, that works. I'll give another go with the current linus tree and ack that back in here as soon as possible.
Jean, sorry, but I can't confirm that for the 2.6.21-rc2 as it's now in such a state that it won't resume from suspend for me at all. With or without i2c. I'll bisect that tomorrow (as is being discussed in bug #7122), but that's another thing entirely and not related to i2c_i801 in any way, I think. But what I can do for you is confirm that the patch works and fixes 2.6.20.
Any news on this? If you can confirm that my latest patch fixes the problem on 2.6.21-rc with no unexpected side effect, I'd like to send it to Linus ASAP so the fix makes it into 2.6.21.
Jear, sorry, no news yet. The s2ram cycle has been busted since early-rc1. Haven't tried in a couple of days though. But I'll put some more effort for to it now and try to narrow down or bisect the breakage if I have to.
Ok, I can confirm that now. It works flawlessly on current linus head 2.6.21-rc4, or atleast as far as I can tell. The acpi is still somewhat borked. But the fan works allowing me to do numerous s2ram cycles with full lm_sensors using your patch. And without the patch the behaviour is what it was when this bug started.
Patch merged in 2.6.21-rc5.