Most recent kernel where this bug did *NOT* occur: did occur since S3 works on P35 Distribution: Gentoo 2006.1 Hardware Environment: Samsung P35 XVM 1600 III Software Environment: Problem Description: After doing the 2nd resume cycle after S3 dmesg shows this: 1st S3: pnp: Device 00:08 disabled. pnp: Device 00:06 disabled. 1st Resume: Both gets activated. 2nd S3: pnp: Device 00:08 disabled. pnp: Device 00:06 disabled. 2nd Resume: pnp: Evaluate _CRS failed pnp: Failed to activate device 00:06. pnp: Evaluate _CRS failed pnp: Failed to activate device 00:08. pnp: Device 00:09 does not support activation. pnp: Failed to activate device 00:0a. For every S3 & Resume again the last messages are there again. Also my irda (nsc_ircc) does not work anymore after second resume as the chip type is wrong now, at first boot its all ok. Steps to reproduce: Take a P35 and do two S3 & Resume Cycles. Happens all the time. kind regards Torsten
is this still a problem in 2.6.21-rc5? was it not a problem in any release before 2.6.20?
I'll try this evening 2.6.21-rc5. I cant tell - i dont know anymore when the radeon resume fixes were added to the kernel. Since that, the P35 did not wake up again so i cant tell. Tried S3 Resume with 2.6.19 or 2.6.20 again and it worked. Before that i didnt see this messages about _CRS errors, so i cant tell since which version it is broken - but i'll guess all versions are effected, if i find out in which version the radeonfb fix for the P35 appeared, i can test it. I'll report if the issue is still there in 2.6.21-rc5.
2.6.21-rc5 works - the _CRS error is gone, irda is working now after every resume. Only message left is: pnp: Failed to activate device 00:0a. Dont know which device that is, theres also no "disabled" message when suspending. thx.
Please try patches in comment#14 #13 and #15 in bug8286. /sys/bus/pnp/devices/00:0a/acpi_node links to the associated ACPI nodes of the pnp device. This may help you get more information.
Is this still an issue in Linux-2.6.22.stable or later?
Oh - i am sorry, i forgot to test the patches. Afaik its still an issue - i'll report this evening if i am right and what the patches above will tell about them.
Ok in .22 i'll only need to add glue.c.patch - this is what i got: id = PNP0f13 options: nothing resources: state = active irq 12 uevent: DRIVER=i8042 aux PHYSDEVBUS=pnp PHYSDEVDRIVER=i8042 aux acpi_node/path: _SB_.PCI0.LPCB.PS2M Hope this helps - whats wrong, or is all ok ...?
Can you attach the acpidump output? you can get acpidump tool from http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ So the left issue is pnp device 0a can't get active after resume. Can you tell me the output of 'cat /sys/bus/pnp/devices/00:0a/resources' before suspend? this will help me know if resources are wrong after resume.
before suspend: cat /sys/bus/pnp/devices/00\:0a/resources state = active irq 12
Created attachment 13543 [details] acpidump file Complete acpidump output.
Created attachment 13553 [details] patch to avoid error message The error message should be harmless, but attached patch should mask it too. please try.
Patch works, thx.
patch in comment #11 applied to acpi-test
shipped in Linux-2.6.24-git22 closed