Description of problem: When I try to get my laptop (Dell d610) out of sleep mode. The machine does not return too it's previous state. After logging in the box with ssh, a lot of commands do not work anymore. They return input/output errors. Further below you will see what errors i'll get. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. buy dell d610 laptop and install f7 on it :) 2. put machine to sleep mode and try to get back from sleep 3. Actual results: Machine is useless and needs a hard reboot Expected results: Resume my sudoku session Additional info: The dmesg is being spammed by the following messages. ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata1.00: (BMDMA stat 0x5) ata1.00: cmd c8/00:08:0b:64:f8/00:00:00:00:00/e1 tag 0 cdb 0x0 data 4096 in res 51/04:08:0b:64:f8/00:00:00:00:00/e1 Emask 0x1 (device error) ata1.00: ata_hpa_resize 1: sectors = 78140160, hpa_sectors = 78140160 ata1.00: ata_hpa_resize 1: sectors = 78140160, hpa_sectors = 78140160 ata1.00: configured for UDMA/33 Some hardware info: ata1.00: ata_hpa_resize 1: sectors = 78140160, hpa_sectors = 78140160 ata1.00: ATA-6: TOSHIBA MK4026GAX, PA102D, max UDMA/100 ata1.00: 78140160 sectors, multi 8: LBA ata1.00: applying bridge limits ata1.00: ata_hpa_resize 1: sectors = 78140160, hpa_sectors = 78140160 ata1.00: configured for UDMA/100
Also I can confirm that this problem is in the 2.6.21-1.3228 kernel
Same happen to me on a Nvidia board using kernel 2.6.21-1.3228.fc7 short after access mounted partitions, have to use latest FC6 kernel for now. Jun 15 22:35:49 host kernel: pata_amd 0000:00:09.0: version 0.2.8 Jun 15 22:35:49 host kernel: PCI: Setting latency timer of device 0000:00:09.0 to 64 Jun 15 22:35:50 host kernel: ata1: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 Jun 15 22:35:50 host kernel: ata2: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 Jun 15 22:35:51 host kernel: scsi0 : pata_amd Jun 15 22:21:01 host kernel: ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jun 15 22:21:01 host kernel: ata2.01: cmd e7/00:00:00:00:00/00:00:00:00:00/b0 tag 0 cdb 0x1e data 0 Jun 15 22:21:01 host kernel: res 51/04:00:46:ff:7d/00:00:00:00:00/b0 Emask 0x1 (device error) Jun 15 22:21:01 host kernel: ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jun 15 22:21:01 host kernel: ata1.01: cmd e7/00:00:00:00:00/00:00:00:00:00/b0 tag 0 cdb 0x0 data 0 Jun 15 22:21:01 host kernel: res 51/04:08:df:02:01/00:00:00:00:00/b0 Emask 0x1 (device error) Jun 15 22:21:01 host kernel: ata2.01: ata_hpa_resize 1: sectors = 16514064, hpa_sectors = 0 Jun 15 22:21:01 host kernel: ata1.01: ata_hpa_resize 1: sectors = 16514064, hpa_sectors = 0 Jun 15 22:21:01 host kernel: ata1.00: ata_hpa_resize 1: sectors = 30033360, hpa_sectors = 30033360 Jun 15 22:21:01 host kernel: ata1.00: configured for UDMA/33 Jun 15 22:21:01 host kernel: ata1.01: ata_hpa_resize 1: sectors = 16514064, hpa_sectors = 0 Jun 15 22:21:01 host kernel: ata1.01: configured for UDMA/33 Jun 15 22:21:01 host kernel: ata1: EH complete
I'm unsure if it's really a libata problem after all. Today I found something out, which makes me think the problem is not libata problem. I think it's in the resume function ... I noticed that this problem is ONLY caused when you have a password set on the hard disc (dell security feature). Normally when the machine comes out of sleep mode (for example in windows). You will get a dell bios screen asking for the password after that the machine is waking up. Linux does not know about this and tries to read to the harddisc which is still locked ofcourse.
My system is a PC, so the similar error message also appears on non-laptops.
Hello folks, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. There hasn't been much activity on this bug for a while. Could you tell me if you are still having problems with the latest kernel? If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged. Cheers Chris
As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug.