3

I just got a new Mushkin 60gb SSD, and it's now my primary drive in the ata1 spot. I've been getting these failed command: IDENTIFY DEVICE errors which are preventing rebooting and shutdown.

Does anyone know what these could be caused by, or how to start troubleshooting?

Note: I just installed Fedora Core 14 and I did not get this same issue at all. The SSD seems to work fine.

I've tried these kernels in Ubuntu 10.04, with both giving the same error:

  • 2.6.32-22-generic
  • 2.6.31-17-generic

And this one in Fedora Core 14, which works fine:

  • 2.6.35.6-45.fc14.i686

There are some bug reports for Ubuntu and Fedora that mention this problem, and there doesn't seem to be a solution:

Here is a link to my entire dmesg from Ubuntu.

Here is a link to my entire dmesg from Fedora Core 14

And the relevant ata1.00 parts from the Ubuntu dmesg below:

[   59.804237] ata1: drained 256 bytes to clear DRQ.
[   59.804244] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[   59.804249] ata1.00: failed command: IDENTIFY DEVICE
[   59.804254] ata1.00: cmd ec/00:00:00:00:00/00:00:00:00:00/40 tag 0 pio 512 in
[   59.804256]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[   59.804258] ata1.00: status: { DRDY }
[   59.804264] ata1: hard resetting link
[   59.804266] ata1: nv: skipping hardreset on occupied port
[   60.272036] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   60.352193] ata1.00: configured for UDMA/133
[   60.352204] ata1: EH complete

2 Answers 2

1

Disabling s.m.a.r.t. helps, but it still occurs when the device isn't cleanly closed during shutdown. Tested with kernel 2.6.37-rc8-git1 ..

Scenarios that trigger this event are:

  1. fsck (not cleanly unmounted)
  2. flush cash ext (during shutdown)
  3. identify device(triggered by smart or fsck during startup)
6
  • How do you disable SMART for a specific device, then? How else do you solve this problem?
    – Neil
    Jan 3, 2011 at 5:26
  • Disable udev rules for smart in:/lib/udev/rules.d/80-udisks.rules
    – user8233
    Jan 3, 2011 at 20:56
  • You're correct on all of those three points. I disabled s.m.a.r.t. but the disk still stalls in those scenarios. Do you know how to fix this problem permanently? Windows doesn't have any problems at all...
    – Neil
    Jan 15, 2011 at 2:36
  • I have a work around for the reboot, so now for me it is possible to reboot the machine without timeouts occurring: Just change in /etc/init.d/reboot de shutdown command in: echo s >/proc/sysrq-trigger; echo u >/proc/sysrq-trigger; echo b >/proc/sysrq-trigger;
    – user8233
    Jan 23, 2011 at 12:41
  • I think some low level libata debugging is needed... Are there some connections to ocz with this problem?
    – user8233
    Jan 23, 2011 at 12:49
1

You'll find some answers in these two bug reports:

Launchpad bug 445852

Launchpad bug 574462

2
  • I disabled smart, and commented out the relevant lines in the mentioned files in /lib/udev/rules.d, which helped speed things up, but I still can't reboot and I still see the error in dmesg once during boot. I even dd'd my drive with to a bin file, then dd'd it with /dev/zero, then dd'd the bin file back to the drive, and that didn't change anything.
    – Neil
    Jan 15, 2011 at 3:56
  • what is the definitive answer in those bugs? Disabling s.m.a.r.t. helps, but doesn't solve the problem.
    – Neil
    Jan 24, 2011 at 21:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .