Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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
share|improve this question
add comment

2 Answers 2

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)
share|improve this answer
    
How do you disable SMART for a specific device, then? How else do you solve this problem? –  Neil Jan 3 '11 at 5:26
    
Disable udev rules for smart in:/lib/udev/rules.d/80-udisks.rules –  user8233 Jan 3 '11 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 '11 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 '11 at 12:41
    
I think some low level libata debugging is needed... Are there some connections to ocz with this problem? –  user8233 Jan 23 '11 at 12:49
show 1 more comment

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

Launchpad bug 445852

Launchpad bug 574462

share|improve this answer
    
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 '11 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 '11 at 21:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.