Understanding dmesg output error: ata1.00: speed down requested but no transfer mode left

L1P0 · 08-02-2021, 02:52 AM

PC Details:
> Dell Precision 390n
> CentOS 4.6
> Kernel version: 2.6.9-67.ELhugemem
> WD Green SSD WDS120G2G0A

Background:
Original disk installed was a HDD. I upgraded to SSD last 2 months ago. Suddenly, the PC encountered weird issue.
I cannot open new shell terminal. So I decided to reboo. During bootup, after the message: Redhat nash version 4.2.1.13 starting..
I encountered these messages:

Code:

ata1.00: failed to set xfermode (err_mask=0x101)
ata1: port failed to respond (30 secs, Status 0x80)

Then those messages repeated, then encountered many errors:

Code:

*** An error occured during the file system check
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance (or type Control-D to continue)

If I perform ctrl-D, it just reboots right away. If I input the root password, I go to a prompt: (Repair filesystem) 1#
I think this is equivalent to single user mode. I can browse my local files, but cannot modify/write.
Then the dmesg command output shows repeated messages like this:

Code:

ata1.00: speed down requested but no transfer mode left
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: (irq_stat 0x40000001)
ata1.00: cmd c5/00:08:d9:9b:a7/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 out
         res 51/04:08:d9:9b:a7/00:00:00:00:00/e0 Emask 0x1 (device error)
ata1.00: configured for PIO0
ata1: EH complete
SCSI device sda: drive cache: write back
ata1.00: speed down requested but no transfer mode left
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: (irq_stat 0x40000001)
ata1.00: cmd c5/00:08:d9:9b:a7/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 out
         res 51/04:08:d9:9b:a7/00:00:00:00:00/e0 Emask 0x1 (device error)
ata1.00: configured for PIO0
ata1: EH complete
...
...Then it just repeats the same block of messages
...
SCSI device sda: 234455040 512-byte hdwr sectors (120041 MB)
ata1.00: speed down requested but no transfer mode left
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: (irq_stat 0x40000001)
ata1.00: cmd c5/00:08:d9:9b:a7/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 out
         res 51/04:08:d9:9b:a7/00:00:00:00:00/e0 Emask 0x1 (device error)
ata1.00: configured for PIO0
SCSI error : <0 0 0 0> return code = 0x8000002
Invalid sda: sense key No Sense
end_request: I/O error, dev sda, sector 10984409
ata1: EH complete
ata1.00: speed down requested but no transfer mode left
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: (irq_stat 0x40000001)
ata1.00: cmd c5/00:18:f1:9f:a7/00:00:00:00:00/e0 tag 0 cdb 0x0 data 12288 out
         res 51/04:18:f1:9f:a7/00:00:00:00:00/e0 Emask 0x1 (device error)
ata1.00: configured for PIO0
ata1: EH complete
...
...
...
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
inserting floppy driver for 2.6.9-67.ELhugemem
floppy0: no floppy controllers found
tg3.c:v3.77 (May 31, 2007)
ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 17 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:05:00.0 to 64
divert: allocating divert_blk for eth0
...
...
...

I tried to go to BIOS, the link speed detected is 3.0Gbps. I enabled the SMART Reporting Logging,
When I try to bootup, I have these messages:

Code:

NOTICE – Drive 0: Serial ATA, SATA-0
Hard Drive SELF MONITORING SYSTEM has reported
That a parameter has exceeded its normal operating range.
Dell recommends that you back up your data regularly.

I'm not good at Linux, but my theory is that the system has requested the SSD to speed down, but somehow failed to do it. And because of this, the pc is not booting up normally. I cannot go the desktop GUI, X server cannot start. I can only brows via CLI environment.
I'd appreciate you guys if you help me understand what might happened and if you can share possible fix for this.. Thank you!

business_kid · 08-02-2021, 07:20 AM

You're dmesg outputs are very concise, which gives no context really for knowing what the box was thionking. I'd ask for a few more lines before and after (If relevant). Obviously if it's rabbiting on about the mouse or something, it's not relevant.

It would be good to know why X doesn't start. Xorg.0.log is the file to find, often in /var/log. It's always the error near the end, but give a little context.

mrmazda · 08-02-2021, 07:14 PM

Is / mounted RW? I have to guess not. X won't start if / isn't writable. I also have to guess there's some low level functionality in that WD SSD's firmware that isn't supported by your ancient kernel and SATA support system.

L1P0 · 08-03-2021, 10:01 PM

Quote:

Originally Posted by business_kid

You're dmesg outputs are very concise, which gives no context really for knowing what the box was thionking. I'd ask for a few more lines before and after (If relevant). Obviously if it's rabbiting on about the mouse or something, it's not relevant.

It would be good to know why X doesn't start. Xorg.0.log is the file to find, often in /var/log. It's always the error near the end, but give a little context.

I have edited my original post to add more lines for dmesg output. I tried to look at the Xorg logfile, but it seems no useful indicators are there and also the last write time of the logfile was weeks ago. (BTW this PC is used in our workplace, and it normally runs continuously. When HDD was still installed, I have not encountered this kind of problem during that time.)

L1P0 · 08-03-2021, 10:18 PM

Quote:

Originally Posted by mrmazda

Is / mounted RW? I have to guess not. X won't start if / isn't writable. I also have to guess there's some low level functionality in that WD SSD's firmware that isn't supported by your ancient kernel and SATA support system.

Here's some of the output of mount command after booting to single user mode:

Code:

/dev/sda3 on / type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)

So the PC reports that / is mounted with read-write access. But when I try to create a file in my home directory or anywhere else locally (I am logged in as root here), the system returns an error:

Code:

touch: cannot touch 'foo' : Read-only file system
mkdir: cannot create directory 'foo' : Read-only file systemt

I cannot also modify existing files.

If there is a compatibility issue with WD SSD firmware, how come it ran normally for the last 2 months?

mrmazda · 08-03-2021, 11:55 PM

If you don't find a current Xorg.0.log in /var/log/, look for it ~/.local/share/xorg/.

mrmazda · 08-04-2021, 12:01 AM

When was your kernel last updated? Do you experience the same problems booting a previous kernel?

L1P0 · 08-04-2021, 12:19 AM

Quote:

Originally Posted by mrmazda

If you don't find a current Xorg.0.log in /var/log/, look for it ~/.local/share/xorg/.

Such folder does not exist in this PC. I also used locate command to find Xorg.0.log, only under /var/log directory they reside.

L1P0 · 08-04-2021, 12:21 AM

Quote:

Originally Posted by mrmazda

When was your kernel last updated? Do you experience the same problems booting a previous kernel?

It has never been updated. Everything that is running in the PC are defaults. This PC is never connected to internet.

mrmazda · 08-06-2021, 01:17 AM

You may have an SSD gone bad. Try smartctl -x /dev/sda to check for errors. You may need to run smartctl -t long /dev/sda and wait the designated time first.

Given the age of your OS, I suspect you'll attract little to no attention from anyone knowledgeable of any specifics of your OS to provide any better help.

kilgoretrout · 08-06-2021, 08:56 AM

I believe proper support for SSDs didn't exist before kernel 3.2. See:

https://wiki.debian.org/%20SSDOptimization%20

That old kernel of yours may not support trim operations which are essential for SSD maintenance. If you have the fstrim utility on your system, you can try running it and see if that helps:

Code:

# fstrim -a

L1P0 · 08-09-2021, 08:59 PM

Quote:

Originally Posted by kilgoretrout

I believe proper support for SSDs didn't exist before kernel 3.2. See:

https://wiki.debian.org/%20SSDOptimization%20

That old kernel of yours may not support trim operations which are essential for SSD maintenance. If you have the fstrim utility on your system, you can try running it and see if that helps:

Code:

# fstrim -a

Unfortunately, there's no fstrim utility here. Thanks for that link. That was helpful.

kilgoretrout · 08-12-2021, 05:34 PM

Quote:

Unfortunately, there's no fstrim utility here. Thanks for that link. That was helpful.

You could try booting from a recent linux livecd like knoppix, mount all linux filesystems on the SSD and then run fstrim. Note, linux partitions on the SSD must be mounted for fstrim -a to work.

Ser Olmy · 08-12-2021, 06:43 PM

Quote:

Originally Posted by L1P0

I tried to go to BIOS, the link speed detected is 3.0Gbps. I enabled the SMART Reporting Logging,
When I try to bootup, I have these messages:

Code:

NOTICE – Drive 0: Serial ATA, SATA-0
Hard Drive SELF MONITORING SYSTEM has reported
That a parameter has exceeded its normal operating range.
Dell recommends that you back up your data regularly.

That's a message directly from the SMART monitoring code in the BIOS.

Without more detailed information on which SMART parameters the BIOS is referring to, it's impossible to say definitely what the problem is. But the BIOS wouldn't print a warning like that for something trivial, so it's fair to assume that your hard drive is about to die, or that it may actually be dead already.

Quote:

Originally Posted by L1P0

I'm not good at Linux, but my theory is that the system has requested the SSD to speed down, but somehow failed to do it.

No, that has nothing to do with it. The drive itself is reporting that it has issues.

But the cause of the problem could be somewhat related to Linux. As another poster pointed out, you may have been running a Linux distribution without "trim" support. That's a terrible idea if you're using an SSD, and is likely to significantly shorten the life of the drive. But running "fstrim" now is unfortunately not going to solve anything.

Boot from a live distribution, run smartctl -a /dev/sda, and post the results.