This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 473689 - x crashes after ata2 reset
x crashes after ata2 reset
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
10
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-29 19:47 EST by shmuel siegel
Modified: 2009-09-06 04:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-06 04:37:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
the x log file indicating the crash of X (207.20 KB, text/plain)
2008-12-06 14:39 EST, shmuel siegel
no flags Details

  None (edit)
Description shmuel siegel 2008-11-29 19:47:30 EST
On my dell d620 laptop, all input and output ceases sometime after I get an ata2 reset. The system itself doesn't hang as I can log in through ssh. dmesg has the following log message
> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
>          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
> ata2.00: status: { DRDY ERR }
> ata2.00: qc timeout (cmd 0xa0)
> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
>          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
> ata2.00: status: { DRDY ERR }
> ata2: link is slow to respond, please be patient (ready=0)
> ata2: device not ready (errno=-16), forcing hardreset
> ata2: soft resetting link
> ata2.00: configured for UDMA/25
> ata2: EH complete
> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
>          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
> ata2.00: status: { DRDY ERR }
> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
>          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>          res 51/04:01:01:60:00/00:00:00:00:00/a0 Emask 0x1 (device error)
> ata2.00: status: { DRDY ERR }
> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
> ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
>          cdb 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
>          res 58/00:02:00:12:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
> ata2.00: status: { DRDY DRQ }
> ata2: soft resetting link
> ata2.00: configured for UDMA/25
> ata2: EH complete
Comment 1 Matěj Cepl 2008-12-01 19:13:09 EST
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf (if you have one) whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 shmuel siegel 2008-12-06 14:39:57 EST
Created attachment 326014 [details]
the x log file indicating the crash of X

Sorry for taking so long. I needed to wait for the problem to happen again. I don't have an xorg.conf file I don't need to recreate without it.

The problem has always occured when moving a card in freecell. The mouse cursor continues to work but can't click anything.
Comment 3 Timothy Murphy 2008-12-08 09:39:04 EST
Just a note to say I experience what I take to be the same bug.
It occurs just once some time (a couple of hours)
after re-starting from "Suspend to RAM"
on my Thinkpad T43.
It doesn't really worry me; I just re-boot.
Comment 4 Peter Hutterer 2008-12-16 22:03:56 EST
This is a graphics driver bug. From the log:

10: /lib/libc.so.6(ioctl+0x19) [0x5b0949]
11: /usr/lib/libdrm.so.2 [0x7e246cf]
12: /usr/lib/libdrm.so.2(drmCommandWrite+0x34) [0x7e24984]
13: /usr/lib/xorg/modules/drivers//intel_drv.so(I830Sync+0x135) [0x314ca5]
14: /usr/lib/xorg/modules/drivers//intel_drv.so [0x33e95a]
15: /usr/lib/xorg/modules//libexa.so(exaWaitSync+0x65) [0x3a4095]
16: /usr/lib/xorg/modules//libexa.so(ExaDoPrepareAccess+0x7e) [0x3a53ae]
17: /usr/lib/xorg/modules//libexa.so [0x3aa3b2]
18: /usr/lib/xorg/modules//libexa.so [0x3aa905]
19: /usr/lib/xorg/modules//libexa.so(exaDoMigration+0x652) [0x3ab0c2]
20: /usr/lib/xorg/modules//libexa.so [0x3ac74b]
21: /usr/lib/xorg/modules//libexa.so(exaComposite+0xd5a) [0x3ad92a]

The intel driver hogs the server, so input still comes in but is never processed or delivered to a client. Reassigning
Comment 5 shmuel siegel 2009-03-11 23:23:46 EDT
I haven't seen this problem again on fedora 11. Has it been fixed as part of the new drivers?
Comment 6 Vedran Miletić 2009-09-06 04:37:58 EDT
Probably.

Closing per comment #5.

Note You need to log in before you can comment on or make changes to this bug.