Bug 473689 - x crashes after ata2 reset
Summary: x crashes after ata2 reset
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810
Version: 10
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-30 00:47 UTC by shmuel siegel
Modified: 2018-04-11 13:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-06 08:37:58 UTC
Type: ---


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

Description shmuel siegel 2008-11-30 00:47:30 UTC
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-02 00:13:09 UTC
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 19:39:57 UTC
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 14:39:04 UTC
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-17 03:03:56 UTC
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-12 03:23:46 UTC
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 08:37:58 UTC
Probably.

Closing per comment #5.


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