Some sort corruption of my Thermal Subsystem after suspend to ram
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
I got some reboot , halt problems and was hunting the issue and noticed these problems only occurred when I've suspend the box to ram , at least once.
I've tested 2.6.{24*,25,linus-git(before ACPI merge),x86-latest-git} and all got that problem.
Also on x86-latest-git I've tested with MTRR_SANITIZER on/off. It does not make any difference.
lspci output before s2r is :
..
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:8277]
Flags: fast devsel
Memory at fed08000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3
...
and after :
...
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev ff) (prog-if ff)
!!! Unknown header type 7f
...
dmesg | grep 00:1f.6
[21520.103062] PM: Writing back config space on device 0000:00:1f.6 at offset f (was ffffffff, writing 300) [21520.103066] PM: Writing back config space on device 0000:00:1f.6 at offset e (was ffffffff, writing 0) [21520.103070] PM: Writing back config space on device 0000:00:1f.6 at offset d (was ffffffff, writing 50) [21520.103074] PM: Writing back config space on device 0000:00:1f.6 at offset c (was ffffffff, writing 0) [21520.103078] PM: Writing back config space on device 0000:00:1f.6 at offset b (was ffffffff, writing 82771043) [21520.103083] PM: Writing back config space on device 0000:00:1f.6 at offset a (was ffffffff, writing 0) [21520.103087] PM: Writing back config space on device 0000:00:1f.6 at offset 9 (was ffffffff, writing 0) [21520.103091] PM: Writing back config space on device 0000:00:1f.6 at offset 8 (was ffffffff, writing 0) [21520.103095] PM: Writing back config space on device 0000:00:1f.6 at offset 7 (was ffffffff, writing 0) [21520.103099] PM: Writing back config space on device 0000:00:1f.6 at offset 6 (was ffffffff, writing 0) [21520.103103] PM: Writing back config space on device 0000:00:1f.6 at offset 5 (was ffffffff, writing 0) [21520.103107] PM: Writing back config space on device 0000:00:1f.6 at offset 4 (was ffffffff, writing fed08004) [21520.103111] PM: Writing back config space on device 0000:00:1f.6 at offset 3 (was ffffffff, writing 0) [21520.103115] PM: Writing back config space on device 0000:00:1f.6 at offset 2 (was ffffffff, writing 11800002) [21520.103119] PM: Writing back config space on device 0000:00:1f.6 at offset 1 (was ffffffff, writing 100002) [21520.103123] PM: Writing back config space on device 0000:00:1f.6 at offset 0 (was ffffffff, writing 29328086)
..
Please let me know if you need my config , dmesg or any other informations.
Best Regards,
Gabriel C
Quoted 6 lines · Gabriel C
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
Does this board contain an Attansic L1 NIC?
Quoted 66 lines
I got some reboot , halt problems and was hunting the issue and noticed these problems only occurred when I've suspend the box to ram , at least once.
I've tested 2.6.{24*,25,linus-git(before ACPI merge),x86-latest-git} and all got that problem.
Also on x86-latest-git I've tested with
MTRR_SANITIZERon/off. It does not make any difference.lspci output before s2r is :
..
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:8277]
Flags: fast devsel
Memory atfed08000(64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3...
and after :
...
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev ff) (prog-if ff)
!!! Unknown header type 7f...
dmesg | grep 00:1f.6
[21520.103062] PM: Writing back config space on device 0000:00:1f.6 at offset f (was ffffffff, writing 300) [21520.103066] PM: Writing back config space on device 0000:00:1f.6 at offset e (was ffffffff, writing 0) [21520.103070] PM: Writing back config space on device 0000:00:1f.6 at offset d (was ffffffff, writing 50) [21520.103074] PM: Writing back config space on device 0000:00:1f.6 at offset c (was ffffffff, writing 0) [21520.103078] PM: Writing back config space on device 0000:00:1f.6 at offset b (was ffffffff, writing 82771043) [21520.103083] PM: Writing back config space on device 0000:00:1f.6 at offset a (was ffffffff, writing 0) [21520.103087] PM: Writing back config space on device 0000:00:1f.6 at offset 9 (was ffffffff, writing 0) [21520.103091] PM: Writing back config space on device 0000:00:1f.6 at offset 8 (was ffffffff, writing 0) [21520.103095] PM: Writing back config space on device 0000:00:1f.6 at offset 7 (was ffffffff, writing 0) [21520.103099] PM: Writing back config space on device 0000:00:1f.6 at offset 6 (was ffffffff, writing 0) [21520.103103] PM: Writing back config space on device 0000:00:1f.6 at offset 5 (was ffffffff, writing 0) [21520.103107] PM: Writing back config space on device 0000:00:1f.6 at offset 4 (was ffffffff, writing fed08004) [21520.103111] PM: Writing back config space on device 0000:00:1f.6 at offset 3 (was ffffffff, writing 0) [21520.103115] PM: Writing back config space on device 0000:00:1f.6 at offset 2 (was ffffffff, writing 11800002) [21520.103119] PM: Writing back config space on device 0000:00:1f.6 at offset 1 (was ffffffff, writing 100002) [21520.103123] PM: Writing back config space on device 0000:00:1f.6 at offset 0 (was ffffffff, writing 29328086)..
Please let me know if you need my config , dmesg or any other informations.
Best Regards,
Gabriel C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Gabriel C
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
Does this board contain an Attansic L1 NIC?
Quoted 66 lines
I got some reboot , halt problems and was hunting the issue and noticed these problems only occurred when I've suspend the box to ram , at least once.
I've tested 2.6.{24*,25,linus-git(before ACPI merge),x86-latest-git} and all got that problem.
Also on x86-latest-git I've tested with
MTRR_SANITIZERon/off. It does not make any difference.lspci output before s2r is :
..
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:8277]
Flags: fast devsel
Memory atfed08000(64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3...
and after :
...
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev ff) (prog-if ff)
!!! Unknown header type 7f...
dmesg | grep 00:1f.6
[21520.103062] PM: Writing back config space on device 0000:00:1f.6 at offset f (was ffffffff, writing 300) [21520.103066] PM: Writing back config space on device 0000:00:1f.6 at offset e (was ffffffff, writing 0) [21520.103070] PM: Writing back config space on device 0000:00:1f.6 at offset d (was ffffffff, writing 50) [21520.103074] PM: Writing back config space on device 0000:00:1f.6 at offset c (was ffffffff, writing 0) [21520.103078] PM: Writing back config space on device 0000:00:1f.6 at offset b (was ffffffff, writing 82771043) [21520.103083] PM: Writing back config space on device 0000:00:1f.6 at offset a (was ffffffff, writing 0) [21520.103087] PM: Writing back config space on device 0000:00:1f.6 at offset 9 (was ffffffff, writing 0) [21520.103091] PM: Writing back config space on device 0000:00:1f.6 at offset 8 (was ffffffff, writing 0) [21520.103095] PM: Writing back config space on device 0000:00:1f.6 at offset 7 (was ffffffff, writing 0) [21520.103099] PM: Writing back config space on device 0000:00:1f.6 at offset 6 (was ffffffff, writing 0) [21520.103103] PM: Writing back config space on device 0000:00:1f.6 at offset 5 (was ffffffff, writing 0) [21520.103107] PM: Writing back config space on device 0000:00:1f.6 at offset 4 (was ffffffff, writing fed08004) [21520.103111] PM: Writing back config space on device 0000:00:1f.6 at offset 3 (was ffffffff, writing 0) [21520.103115] PM: Writing back config space on device 0000:00:1f.6 at offset 2 (was ffffffff, writing 11800002) [21520.103119] PM: Writing back config space on device 0000:00:1f.6 at offset 1 (was ffffffff, writing 100002) [21520.103123] PM: Writing back config space on device 0000:00:1f.6 at offset 0 (was ffffffff, writing 29328086)..
Please let me know if you need my config , dmesg or any other informations.
Best Regards,
Gabriel C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Jay Cliburn
Quoted 6 lines · Gabriel C
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
Does this board contain an Attansic L1 NIC?
No,
Intel 82566DM-2.
here full lspci output :
00:00.0 Host bridge [0600]: Intel Corporation 82Q35 Express DRAM Controller [8086:29b0] (rev 02)
00:02.0 VGA compatible controller [0300]: Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b2] (rev 02) 00:03.0 Communication controller [0780]: Intel Corporation 82Q35 Express MEI Controller [8086:29b4] (rev 02) 00:03.2 IDE interface [0101]: Intel Corporation 82Q35 Express PT IDER Controller [8086:29b6] (rev 02) 00:03.3 Serial controller [0700]: Intel Corporation 82Q35 Express Serial KT Controller [8086:29b7] (rev 02) 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DM-2 Gigabit Network Connection [8086:10bd] (rev 02) 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 02) 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 02) 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 02) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 02) 00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 [8086:2948] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 02) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 02) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 02) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 92)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801IO (ICH9DO) LPC Interface Controller [8086:2914] (rev 02) 00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller [8086:2922] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02) 00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02) 01:00.0 IDE interface [0101]: JMicron Technologies, Inc. JMB368 IDE controller [197b:2368]
03:02.0 FireWire (IEEE 1394) [0c00]: Agere Systems FW323 [11c1:5811] (rev 70)
Quoted 68 lines
Quoted 66 lines
I got some reboot , halt problems and was hunting the issue and noticed these problems only occurred when I've suspend the box to ram , at least once.
I've tested 2.6.{24*,25,linus-git(before ACPI merge),x86-latest-git} and all got that problem.
Also on x86-latest-git I've tested with
MTRR_SANITIZERon/off. It does not make any difference.lspci output before s2r is :
..
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:8277]
Flags: fast devsel
Memory atfed08000(64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3...
and after :
...
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev ff) (prog-if ff)
!!! Unknown header type 7f...
dmesg | grep 00:1f.6
[21520.103062] PM: Writing back config space on device 0000:00:1f.6 at offset f (was ffffffff, writing 300) [21520.103066] PM: Writing back config space on device 0000:00:1f.6 at offset e (was ffffffff, writing 0) [21520.103070] PM: Writing back config space on device 0000:00:1f.6 at offset d (was ffffffff, writing 50) [21520.103074] PM: Writing back config space on device 0000:00:1f.6 at offset c (was ffffffff, writing 0) [21520.103078] PM: Writing back config space on device 0000:00:1f.6 at offset b (was ffffffff, writing 82771043) [21520.103083] PM: Writing back config space on device 0000:00:1f.6 at offset a (was ffffffff, writing 0) [21520.103087] PM: Writing back config space on device 0000:00:1f.6 at offset 9 (was ffffffff, writing 0) [21520.103091] PM: Writing back config space on device 0000:00:1f.6 at offset 8 (was ffffffff, writing 0) [21520.103095] PM: Writing back config space on device 0000:00:1f.6 at offset 7 (was ffffffff, writing 0) [21520.103099] PM: Writing back config space on device 0000:00:1f.6 at offset 6 (was ffffffff, writing 0) [21520.103103] PM: Writing back config space on device 0000:00:1f.6 at offset 5 (was ffffffff, writing 0) [21520.103107] PM: Writing back config space on device 0000:00:1f.6 at offset 4 (was ffffffff, writing fed08004) [21520.103111] PM: Writing back config space on device 0000:00:1f.6 at offset 3 (was ffffffff, writing 0) [21520.103115] PM: Writing back config space on device 0000:00:1f.6 at offset 2 (was ffffffff, writing 11800002) [21520.103119] PM: Writing back config space on device 0000:00:1f.6 at offset 1 (was ffffffff, writing 100002) [21520.103123] PM: Writing back config space on device 0000:00:1f.6 at offset 0 (was ffffffff, writing 29328086)..
Please let me know if you need my config , dmesg or any other informations.
Best Regards,
Gabriel C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Jay Cliburn
Quoted 6 lines · Gabriel C
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
Does this board contain an Attansic L1 NIC?
No,
Intel 82566DM-2.
here full lspci output :
00:00.0 Host bridge [0600]: Intel Corporation 82Q35 Express DRAM Controller [8086:29b0] (rev 02)
00:02.0 VGA compatible controller [0300]: Intel Corporation 82Q35 Express Integrated Graphics Controller [8086:29b2] (rev 02) 00:03.0 Communication controller [0780]: Intel Corporation 82Q35 Express MEI Controller [8086:29b4] (rev 02) 00:03.2 IDE interface [0101]: Intel Corporation 82Q35 Express PT IDER Controller [8086:29b6] (rev 02) 00:03.3 Serial controller [0700]: Intel Corporation 82Q35 Express Serial KT Controller [8086:29b7] (rev 02) 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DM-2 Gigabit Network Connection [8086:10bd] (rev 02) 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 02) 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 02) 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 02) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 02) 00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 [8086:2948] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 02) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 02) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 02) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 92)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801IO (ICH9DO) LPC Interface Controller [8086:2914] (rev 02) 00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller [8086:2922] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02) 00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02) 01:00.0 IDE interface [0101]: JMicron Technologies, Inc. JMB368 IDE controller [197b:2368]
03:02.0 FireWire (IEEE 1394) [0c00]: Agere Systems FW323 [11c1:5811] (rev 70)
Quoted 68 lines
Quoted 66 lines
I got some reboot , halt problems and was hunting the issue and noticed these problems only occurred when I've suspend the box to ram , at least once.
I've tested 2.6.{24*,25,linus-git(before ACPI merge),x86-latest-git} and all got that problem.
Also on x86-latest-git I've tested with
MTRR_SANITIZERon/off. It does not make any difference.lspci output before s2r is :
..
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:8277]
Flags: fast devsel
Memory atfed08000(64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3...
and after :
...
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev ff) (prog-if ff)
!!! Unknown header type 7f...
dmesg | grep 00:1f.6
[21520.103062] PM: Writing back config space on device 0000:00:1f.6 at offset f (was ffffffff, writing 300) [21520.103066] PM: Writing back config space on device 0000:00:1f.6 at offset e (was ffffffff, writing 0) [21520.103070] PM: Writing back config space on device 0000:00:1f.6 at offset d (was ffffffff, writing 50) [21520.103074] PM: Writing back config space on device 0000:00:1f.6 at offset c (was ffffffff, writing 0) [21520.103078] PM: Writing back config space on device 0000:00:1f.6 at offset b (was ffffffff, writing 82771043) [21520.103083] PM: Writing back config space on device 0000:00:1f.6 at offset a (was ffffffff, writing 0) [21520.103087] PM: Writing back config space on device 0000:00:1f.6 at offset 9 (was ffffffff, writing 0) [21520.103091] PM: Writing back config space on device 0000:00:1f.6 at offset 8 (was ffffffff, writing 0) [21520.103095] PM: Writing back config space on device 0000:00:1f.6 at offset 7 (was ffffffff, writing 0) [21520.103099] PM: Writing back config space on device 0000:00:1f.6 at offset 6 (was ffffffff, writing 0) [21520.103103] PM: Writing back config space on device 0000:00:1f.6 at offset 5 (was ffffffff, writing 0) [21520.103107] PM: Writing back config space on device 0000:00:1f.6 at offset 4 (was ffffffff, writing fed08004) [21520.103111] PM: Writing back config space on device 0000:00:1f.6 at offset 3 (was ffffffff, writing 0) [21520.103115] PM: Writing back config space on device 0000:00:1f.6 at offset 2 (was ffffffff, writing 11800002) [21520.103119] PM: Writing back config space on device 0000:00:1f.6 at offset 1 (was ffffffff, writing 100002) [21520.103123] PM: Writing back config space on device 0000:00:1f.6 at offset 0 (was ffffffff, writing 29328086)..
Please let me know if you need my config , dmesg or any other informations.
Best Regards,
Gabriel C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Jay Cliburn
Quoted 6 lines · Gabriel C
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
Does this board contain an Attansic L1 NIC?
Belay that. I see it's an Intel NIC.
http://www.asus.com/products.aspx?modelmenu=2&model=1849&l1=3&l2=11&l3=571&l4=0
I should've looked first. Sorry for the noise.
Quoted 8 lines · Jay Cliburn
Quoted 5 lines · Gabriel C
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
Does this board contain an Attansic L1 NIC?
Belay that. I see it's an Intel NIC.
http://www.asus.com/products.aspx?modelmenu=2&model=1849&l1=3&l2=11&l3=571&l4=0
I should've looked first. Sorry for the noise.
The ICH9 apparently provides a pair of memory mapped on-die thermal sensors.
The sensors basically shut off your hardware if it gets too hot.
ICH9 exports the base address for the sensors via a PCI device -- D31:F6, aka Linux 00:1f.6
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device, and Linux's standard PCI config space restore.
My guess is that the BIOS is enabling the device on cold boot,
but not enabling it after resume from S3.
Is there a BIOS SETUP option that controls if the ICH9 thermal device is enabled or not?
-Len
Quoted 72 lines · Gabriel C
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
I got some reboot , halt problems and was hunting the issue and noticed these problems only occurred when I've suspend the box to ram , at least once.
I've tested 2.6.{24*,25,linus-git(before ACPI merge),x86-latest-git} and all got that problem.
Also on x86-latest-git I've tested with
MTRR_SANITIZERon/off. It does not make any difference.lspci output before s2r is :
..
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:8277]
Flags: fast devsel
Memory atfed08000(64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3...
and after :
...
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev ff) (prog-if ff)
!!! Unknown header type 7f...
dmesg | grep 00:1f.6
[21520.103062] PM: Writing back config space on device 0000:00:1f.6 at offset f (was ffffffff, writing 300) [21520.103066] PM: Writing back config space on device 0000:00:1f.6 at offset e (was ffffffff, writing 0) [21520.103070] PM: Writing back config space on device 0000:00:1f.6 at offset d (was ffffffff, writing 50) [21520.103074] PM: Writing back config space on device 0000:00:1f.6 at offset c (was ffffffff, writing 0) [21520.103078] PM: Writing back config space on device 0000:00:1f.6 at offset b (was ffffffff, writing 82771043) [21520.103083] PM: Writing back config space on device 0000:00:1f.6 at offset a (was ffffffff, writing 0) [21520.103087] PM: Writing back config space on device 0000:00:1f.6 at offset 9 (was ffffffff, writing 0) [21520.103091] PM: Writing back config space on device 0000:00:1f.6 at offset 8 (was ffffffff, writing 0) [21520.103095] PM: Writing back config space on device 0000:00:1f.6 at offset 7 (was ffffffff, writing 0) [21520.103099] PM: Writing back config space on device 0000:00:1f.6 at offset 6 (was ffffffff, writing 0) [21520.103103] PM: Writing back config space on device 0000:00:1f.6 at offset 5 (was ffffffff, writing 0) [21520.103107] PM: Writing back config space on device 0000:00:1f.6 at offset 4 (was ffffffff, writing fed08004) [21520.103111] PM: Writing back config space on device 0000:00:1f.6 at offset 3 (was ffffffff, writing 0) [21520.103115] PM: Writing back config space on device 0000:00:1f.6 at offset 2 (was ffffffff, writing 11800002) [21520.103119] PM: Writing back config space on device 0000:00:1f.6 at offset 1 (was ffffffff, writing 100002) [21520.103123] PM: Writing back config space on device 0000:00:1f.6 at offset 0 (was ffffffff, writing 29328086)..
Please let me know if you need my config , dmesg or any other informations.
Best Regards,
Gabriel C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
The ICH9 apparently provides a pair of memory mapped on-die thermal sensors.
The sensors basically shut off your hardware if it gets too hot.
ICH9 exports the base address for the sensors via a PCI device -- D31:F6, aka Linux 00:1f.6
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device, and Linux's standard PCI config space restore.
My guess is that the BIOS is enabling the device on cold boot,
but not enabling it after resume from S3.
Is there a BIOS SETUP option that controls if the ICH9 thermal device is enabled or not?
-Len
Quoted 72 lines · Gabriel C
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
I got some reboot , halt problems and was hunting the issue and noticed these problems only occurred when I've suspend the box to ram , at least once.
I've tested 2.6.{24*,25,linus-git(before ACPI merge),x86-latest-git} and all got that problem.
Also on x86-latest-git I've tested with
MTRR_SANITIZERon/off. It does not make any difference.lspci output before s2r is :
..
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:8277]
Flags: fast devsel
Memory atfed08000(64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3...
and after :
...
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev ff) (prog-if ff)
!!! Unknown header type 7f...
dmesg | grep 00:1f.6
[21520.103062] PM: Writing back config space on device 0000:00:1f.6 at offset f (was ffffffff, writing 300) [21520.103066] PM: Writing back config space on device 0000:00:1f.6 at offset e (was ffffffff, writing 0) [21520.103070] PM: Writing back config space on device 0000:00:1f.6 at offset d (was ffffffff, writing 50) [21520.103074] PM: Writing back config space on device 0000:00:1f.6 at offset c (was ffffffff, writing 0) [21520.103078] PM: Writing back config space on device 0000:00:1f.6 at offset b (was ffffffff, writing 82771043) [21520.103083] PM: Writing back config space on device 0000:00:1f.6 at offset a (was ffffffff, writing 0) [21520.103087] PM: Writing back config space on device 0000:00:1f.6 at offset 9 (was ffffffff, writing 0) [21520.103091] PM: Writing back config space on device 0000:00:1f.6 at offset 8 (was ffffffff, writing 0) [21520.103095] PM: Writing back config space on device 0000:00:1f.6 at offset 7 (was ffffffff, writing 0) [21520.103099] PM: Writing back config space on device 0000:00:1f.6 at offset 6 (was ffffffff, writing 0) [21520.103103] PM: Writing back config space on device 0000:00:1f.6 at offset 5 (was ffffffff, writing 0) [21520.103107] PM: Writing back config space on device 0000:00:1f.6 at offset 4 (was ffffffff, writing fed08004) [21520.103111] PM: Writing back config space on device 0000:00:1f.6 at offset 3 (was ffffffff, writing 0) [21520.103115] PM: Writing back config space on device 0000:00:1f.6 at offset 2 (was ffffffff, writing 11800002) [21520.103119] PM: Writing back config space on device 0000:00:1f.6 at offset 1 (was ffffffff, writing 100002) [21520.103123] PM: Writing back config space on device 0000:00:1f.6 at offset 0 (was ffffffff, writing 29328086)..
Please let me know if you need my config , dmesg or any other informations.
Best Regards,
Gabriel C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Len Brown
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device, and Linux's standard PCI config space restore.
Perhaps we should be more aggressive about restoring PCI config space if there's no driver bound to a device. The alternative in this case would seem to be to write a driver for this device that does nothing other than handle suspend/resume.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 4 lines · Len Brown
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device, and Linux's standard PCI config space restore.
Perhaps we should be more aggressive about restoring PCI config space if there's no driver bound to a device. The alternative in this case would seem to be to write a driver for this device that does nothing other than handle suspend/resume.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 11 lines · Matthew Garrett
Quoted 4 lines · Len Brown
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device, and Linux's standard PCI config space restore.Perhaps we should be more aggressive about restoring PCI config space if there's no driver bound to a device. The alternative in this case would seem to be to write a driver for this device that does nothing other than handle suspend/resume.
Well, we have default suspend/resume for PCI devices. They are called for devices that have no drivers bound to them and execute pci_restore_state()/pci_restore_state(), among other things. Isn't that sufficient?
Rafael
Quoted 11 lines · Matthew Garrett
Quoted 4 lines · Len Brown
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device, and Linux's standard PCI config space restore.Perhaps we should be more aggressive about restoring PCI config space if there's no driver bound to a device. The alternative in this case would seem to be to write a driver for this device that does nothing other than handle suspend/resume.
Well, we have default suspend/resume for PCI devices. They are called for devices that have no drivers bound to them and execute pci_restore_state()/pci_restore_state(), among other things. Isn't that sufficient?
Rafael
Quoted 10 lines · Rafael J. Wysocki
Quoted 4 lines · Matthew Garrett
Perhaps we should be more aggressive about restoring PCI config space if there's no driver bound to a device. The alternative in this case would seem to be to write a driver for this device that does nothing other than handle suspend/resume.
Well, we have default suspend/resume for PCI devices. They are called for devices that have no drivers bound to them and execute pci_restore_state()/pci_restore_state(), among other things. Isn't that sufficient?
That only saves the "standard" registers, not the rest of config space.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 10 lines · Rafael J. Wysocki
Quoted 4 lines · Matthew Garrett
Perhaps we should be more aggressive about restoring PCI config space if there's no driver bound to a device. The alternative in this case would seem to be to write a driver for this device that does nothing other than handle suspend/resume.
Well, we have default suspend/resume for PCI devices. They are called for devices that have no drivers bound to them and execute pci_restore_state()/pci_restore_state(), among other things. Isn't that sufficient?
That only saves the "standard" registers, not the rest of config space.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 7 lines · Matthew Garrett
Quoted 6 lines · Rafael J. Wysocki
Quoted 4 lines · Matthew Garrett
Perhaps we should be more aggressive about restoring PCI config space if there's no driver bound to a device. The alternative in this case would seem to be to write a driver for this device that does nothing other than handle suspend/resume.
Quoted 6 lines
Quoted 4 lines
Well, we have default suspend/resume for PCI devices. They are called for devices that have no drivers bound to them and execute pci_restore_state()/pci_restore_state(), among other things. Isn't that sufficient?
That only saves the "standard" registers, not the rest of config space.
Hm, in that case I'd probably opt for writing a special driver for this particular device.
Thanks,
Rafael
Quoted 7 lines · Matthew Garrett
Quoted 6 lines · Rafael J. Wysocki
Quoted 4 lines · Matthew Garrett
Perhaps we should be more aggressive about restoring PCI config space if there's no driver bound to a device. The alternative in this case would seem to be to write a driver for this device that does nothing other than handle suspend/resume.
Quoted 6 lines
Quoted 4 lines
Well, we have default suspend/resume for PCI devices. They are called for devices that have no drivers bound to them and execute pci_restore_state()/pci_restore_state(), among other things. Isn't that sufficient?
That only saves the "standard" registers, not the rest of config space.
Hm, in that case I'd probably opt for writing a special driver for this particular device.
Thanks,
Rafael
Quoted 6 lines · Len Brown
The ICH9 apparently provides a pair of memory mapped on-die thermal sensors.
The sensors basically shut off your hardware if it gets too hot.
ICH9 exports the base address for the sensors via a PCI device -- D31:F6, aka Linux 00:1f.6
Quoted 8 lines
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device, and Linux's standard PCI config space restore.My guess is that the BIOS is enabling the device on cold boot,
but not enabling it after resume from S3.
Is there a BIOS SETUP option that controls if the ICH9 thermal device is enabled or not?
I have some options for the ASUS HW monitoring things where I can set fan profile and see the speed of the fans but I cannot find something where I can enable/disable the whole thermal devices.
There is a option to ignore some fans but that is.
Quoted 82 lines
-Len
Quoted 72 lines · Gabriel C
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
I got some reboot , halt problems and was hunting the issue and noticed these problems only occurred when I've suspend the box to ram , at least once.
I've tested 2.6.{24*,25,linus-git(before ACPI merge),x86-latest-git} and all got that problem.
Also on x86-latest-git I've tested with
MTRR_SANITIZERon/off. It does not make any difference.lspci output before s2r is :
..
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:8277]
Flags: fast devsel
Memory atfed08000(64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3...
and after :
...
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev ff) (prog-if ff)
!!! Unknown header type 7f...
dmesg | grep 00:1f.6
[21520.103062] PM: Writing back config space on device 0000:00:1f.6 at offset f (was ffffffff, writing 300) [21520.103066] PM: Writing back config space on device 0000:00:1f.6 at offset e (was ffffffff, writing 0) [21520.103070] PM: Writing back config space on device 0000:00:1f.6 at offset d (was ffffffff, writing 50) [21520.103074] PM: Writing back config space on device 0000:00:1f.6 at offset c (was ffffffff, writing 0) [21520.103078] PM: Writing back config space on device 0000:00:1f.6 at offset b (was ffffffff, writing 82771043) [21520.103083] PM: Writing back config space on device 0000:00:1f.6 at offset a (was ffffffff, writing 0) [21520.103087] PM: Writing back config space on device 0000:00:1f.6 at offset 9 (was ffffffff, writing 0) [21520.103091] PM: Writing back config space on device 0000:00:1f.6 at offset 8 (was ffffffff, writing 0) [21520.103095] PM: Writing back config space on device 0000:00:1f.6 at offset 7 (was ffffffff, writing 0) [21520.103099] PM: Writing back config space on device 0000:00:1f.6 at offset 6 (was ffffffff, writing 0) [21520.103103] PM: Writing back config space on device 0000:00:1f.6 at offset 5 (was ffffffff, writing 0) [21520.103107] PM: Writing back config space on device 0000:00:1f.6 at offset 4 (was ffffffff, writing fed08004) [21520.103111] PM: Writing back config space on device 0000:00:1f.6 at offset 3 (was ffffffff, writing 0) [21520.103115] PM: Writing back config space on device 0000:00:1f.6 at offset 2 (was ffffffff, writing 11800002) [21520.103119] PM: Writing back config space on device 0000:00:1f.6 at offset 1 (was ffffffff, writing 100002) [21520.103123] PM: Writing back config space on device 0000:00:1f.6 at offset 0 (was ffffffff, writing 29328086)..
Please let me know if you need my config , dmesg or any other informations.
Best Regards,
Gabriel C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · Len Brown
The ICH9 apparently provides a pair of memory mapped on-die thermal sensors.
The sensors basically shut off your hardware if it gets too hot.
ICH9 exports the base address for the sensors via a PCI device -- D31:F6, aka Linux 00:1f.6
Quoted 8 lines
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device, and Linux's standard PCI config space restore.My guess is that the BIOS is enabling the device on cold boot,
but not enabling it after resume from S3.
Is there a BIOS SETUP option that controls if the ICH9 thermal device is enabled or not?
I have some options for the ASUS HW monitoring things where I can set fan profile and see the speed of the fans but I cannot find something where I can enable/disable the whole thermal devices.
There is a option to ignore some fans but that is.
Quoted 82 lines
-Len
Quoted 72 lines · Gabriel C
Hi all,
I thought I've found all issue with that new box but I was wrong ;)
On an ASUS P5E-VM DO , 4G RAM , Q9300 CPU after suspend to ram Thermal Subsystem gets corrupted in some way.
I got some reboot , halt problems and was hunting the issue and noticed these problems only occurred when I've suspend the box to ram , at least once.
I've tested 2.6.{24*,25,linus-git(before ACPI merge),x86-latest-git} and all got that problem.
Also on x86-latest-git I've tested with
MTRR_SANITIZERon/off. It does not make any difference.lspci output before s2r is :
..
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev 02)
Subsystem: ASUSTeK Computer Inc. Device [1043:8277]
Flags: fast devsel
Memory atfed08000(64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3...
and after :
...
00:1f.6 Signal processing controller [1180]: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem [8086:2932] (rev ff) (prog-if ff)
!!! Unknown header type 7f...
dmesg | grep 00:1f.6
[21520.103062] PM: Writing back config space on device 0000:00:1f.6 at offset f (was ffffffff, writing 300) [21520.103066] PM: Writing back config space on device 0000:00:1f.6 at offset e (was ffffffff, writing 0) [21520.103070] PM: Writing back config space on device 0000:00:1f.6 at offset d (was ffffffff, writing 50) [21520.103074] PM: Writing back config space on device 0000:00:1f.6 at offset c (was ffffffff, writing 0) [21520.103078] PM: Writing back config space on device 0000:00:1f.6 at offset b (was ffffffff, writing 82771043) [21520.103083] PM: Writing back config space on device 0000:00:1f.6 at offset a (was ffffffff, writing 0) [21520.103087] PM: Writing back config space on device 0000:00:1f.6 at offset 9 (was ffffffff, writing 0) [21520.103091] PM: Writing back config space on device 0000:00:1f.6 at offset 8 (was ffffffff, writing 0) [21520.103095] PM: Writing back config space on device 0000:00:1f.6 at offset 7 (was ffffffff, writing 0) [21520.103099] PM: Writing back config space on device 0000:00:1f.6 at offset 6 (was ffffffff, writing 0) [21520.103103] PM: Writing back config space on device 0000:00:1f.6 at offset 5 (was ffffffff, writing 0) [21520.103107] PM: Writing back config space on device 0000:00:1f.6 at offset 4 (was ffffffff, writing fed08004) [21520.103111] PM: Writing back config space on device 0000:00:1f.6 at offset 3 (was ffffffff, writing 0) [21520.103115] PM: Writing back config space on device 0000:00:1f.6 at offset 2 (was ffffffff, writing 11800002) [21520.103119] PM: Writing back config space on device 0000:00:1f.6 at offset 1 (was ffffffff, writing 100002) [21520.103123] PM: Writing back config space on device 0000:00:1f.6 at offset 0 (was ffffffff, writing 29328086)..
Please let me know if you need my config , dmesg or any other informations.
Best Regards,
Gabriel C
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi!
Quoted 3 lines
The ICH9 apparently provides a pair of memory mapped on-die thermal sensors.
The sensors basically shut off your hardware if it gets too hot.
Are the sensors driven by ACPI? Probably yes, otherwise they would be unable to shut down the system.
Quoted 9 lines
ICH9 exports the base address for the sensors via a PCI device -- D31:F6, aka Linux 00:1f.6
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device, and Linux's standard PCI config space restore.My guess is that the BIOS is enabling the device on cold boot, but not enabling it after resume from S3.
That sounds like a BIOS problem, right? If the piece of hardware is driven by BIOS, Linux can't be responsible for saving/restoring it.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 19 lines
Hi!
Quoted 4 lines
The ICH9 apparently provides a pair of memory mapped on-die thermal sensors.
The sensors basically shut off your hardware if it gets too hot.
Are the sensors driven by ACPI? Probably yes, otherwise they would be unable to shut down the system.
Quoted 9 lines
ICH9 exports the base address for the sensors via a PCI device -- D31:F6, aka Linux 00:1f.6
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device,
and Linux's standard PCI config space restore.
Quoted 5 lines
Quoted 2 lines
My guess is that the BIOS is enabling the device on cold boot, but not enabling it after resume from S3.
That sounds like a BIOS problem, right? If the piece of hardware is driven by BIOS, Linux can't be responsible for saving/restoring it.
I was having a similar problem on my old laptop. It seemed a lot more sensitive to the problem on later kernels.
What was actually happening is that the last time the laptop went in for repairs they did not seat the heat sink correctly. It slowly worked itself loose. After regreasing it with heat sink grease (not a heat sink pad, but actual silver grease) and reseating it and tightening it down, the machine worked fine. (I also found some nasty tool marks in the soft metal next to the heat sink that shows that whoever did it slipped at least once.)
Sometimes hardware problems increase slowly.
Quoted 19 lines
Hi!
Quoted 4 lines
The ICH9 apparently provides a pair of memory mapped on-die thermal sensors.
The sensors basically shut off your hardware if it gets too hot.
Are the sensors driven by ACPI? Probably yes, otherwise they would be unable to shut down the system.
Quoted 9 lines
ICH9 exports the base address for the sensors via a PCI device -- D31:F6, aka Linux 00:1f.6
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device,
and Linux's standard PCI config space restore.
Quoted 5 lines
Quoted 2 lines
My guess is that the BIOS is enabling the device on cold boot, but not enabling it after resume from S3.
That sounds like a BIOS problem, right? If the piece of hardware is driven by BIOS, Linux can't be responsible for saving/restoring it.
I was having a similar problem on my old laptop. It seemed a lot more sensitive to the problem on later kernels.
What was actually happening is that the last time the laptop went in for repairs they did not seat the heat sink correctly. It slowly worked itself loose. After regreasing it with heat sink grease (not a heat sink pad, but actual silver grease) and reseating it and tightening it down, the machine worked fine. (I also found some nasty tool marks in the soft metal next to the heat sink that shows that whoever did it slipped at least once.)
Sometimes hardware problems increase slowly.
Hi!
Quoted 3 lines
The ICH9 apparently provides a pair of memory mapped on-die thermal sensors.
The sensors basically shut off your hardware if it gets too hot.
Are the sensors driven by ACPI? Probably yes, otherwise they would be unable to shut down the system.
Quoted 9 lines
ICH9 exports the base address for the sensors via a PCI device -- D31:F6, aka Linux 00:1f.6
I'm not aware of a native Linux device driver that talks to this device (nor can I think of a useful purpose for such a driver)
So it seems what is in play here is any BIOS code that talks to this device, and Linux's standard PCI config space restore.My guess is that the BIOS is enabling the device on cold boot, but not enabling it after resume from S3.
That sounds like a BIOS problem, right? If the piece of hardware is driven by BIOS, Linux can't be responsible for saving/restoring it.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html