Bug 242752

Summary: Machine stops working after return (possible cause: libata)
Product: [Fedora] Fedora Reporter: Gerwin Krist <gerwinkrist>
Component: kernelAssignee: Jeff Garzik <jgarzik>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: high    
Version: 7CC: cebbert, chris.brown, davej, gerwin, graham, mads, pb, peterm
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-09 01:07:02 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 172490    

Description Gerwin Krist 2007-06-05 16:53:28 UTC
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

Comment 1 Gerwin Krist 2007-06-15 19:24:51 UTC
Also I can confirm that this problem is in the 2.6.21-1.3228 kernel

Comment 2 Peter Bieringer 2007-06-16 11:20:51 UTC
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


Comment 3 Gerwin Krist 2007-06-16 15:19:53 UTC
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.


Comment 4 Peter Bieringer 2007-06-16 15:37:06 UTC
My system is a PC, so the similar error message also appears on non-laptops.

Comment 5 Christopher Brown 2007-09-13 21:36:37 UTC
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

Comment 6 Christopher Brown 2008-01-09 01:07:02 UTC
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.