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
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.
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.
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.
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
I haven't seen this problem again on fedora 11. Has it been fixed as part of the new drivers?
Probably. Closing per comment #5.