LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Hardware (http://www.linuxquestions.org/questions/linux-hardware-18/)
-   -   Find device name for "ata5" (http://www.linuxquestions.org/questions/linux-hardware-18/find-device-name-for-ata5-882229/)

MasterOfTheWind 05-23-2011 06:15 AM

Find device name for "ata5"
 
Hi there!

This is probably a horrendously stupid question, but I need to find what device "ata5" is on my computer.

When booting my box today I noticed the following message in the dmesg log:

Code:

ata5: softreset failed (timeout)
Not sure what this is all about, but I would very much like to find which disk this message relates to - however, for the life of me I can't find out which block device it is.

Can anyone help me out?

cascade9 05-23-2011 11:53 AM

ATA-5 would be your HDD. (ATA-5 = Ultra DMA 3, 4 or UDMA66 or Ultra ATA/66)

serafean 05-23-2011 11:56 AM

Hi,

I used "dmesg | grep ata2" a couple days ago to figure out which HDD was on SATA 1. The relevant ouput was :
Code:

ata1.00: ATA-8: WDC WD3200BEVT-22ZCT0, 11.01A11, max UDMA/133
I thus knew it was my 320GB Western Digital. Another option would be to check which disk is connected to which port, but that can usually be overriden in the BIOS, so not necessarily correct.

Serafean

amani 05-23-2011 12:13 PM

don't bother about the message "ata5: softreset failed (timeout)".

if there is nothing more in the next line

MasterOfTheWind 05-23-2011 12:15 PM

Thank you both for your replies, however I am still stuck.

1) First of all, I have a total of 6 hard drives in my box. I know that the message refers to an attached hdd, my problem is finding out which one it is.

2) The major problem is that "ata5" is never mentioned in dmesg besides the following lines:

Code:

ata5: SATA max UDMA/100 host m128@0xe9004000 port 0xe9000000 irq 17

...snip...

ata5: softreset failed (timeout)
ata5: softreset failed (timeout)
ata5: softreset failed (timeout)
ata5: limiting SATA link speed to 1.5 Gbps
ata5: softreset failed (timeout)
ata5: reset failed, giving up

... and this does not give me any info on what ata5 refers to. Furthermore - all of my hard drives appear to be working fine. So I am at a loss here - no idea what's going on :S

MasterOfTheWind 05-23-2011 12:18 PM

Quote:

Originally Posted by amani (Post 4364765)
don't bother about the message "ata5: softreset failed (timeout)".

if there is nothing more in the next line

OK, thanks... however, it slows down the booting process rather considerably.

Do you know why this error message is shown? I guess it might be the kernel config or perhaps RAID-related; but I haven't updated my kernel prior to this occurring, neither do I have a RAID set up.

PTrenholme 05-23-2011 12:40 PM

Look in /var/log/messages for ATA5. (E.g: grep -i ata5 /var/log/messages or just search for all ATA references in there.)

(I'd show you an example, but I'm on an XP system right now . . .)

MasterOfTheWind 05-23-2011 12:49 PM

Quote:

Originally Posted by PTrenholme (Post 4364800)
Look in /var/log/messages for ATA5.

Thank you for your suggestion. The messages log contains a number of following lines repeatedly logged every 7 minutes or so:

Code:

ata5: hard resetting link
ata5: hard resetting link
ata5: hard resetting link
ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
ata5.00: configured for UDMA/100
ata5: EH complete

So still nothing...

PTrenholme 05-23-2011 01:47 PM

Ah, well, look where the messages start, where you should see something like this (where the ID is in bold-face type):
Code:

May 23 13:43:19 Trenholme kernel: [    3.651671] ata3: PATA max UDMA/100 cmd 0xa400 ctl 0xa800 bmdma 0xb400 irq 17
May 23 13:43:19 Trenholme kernel: [    3.850558] ata3.00: ATAPI: DVD-RW IDE1004, VER 0045, max UDMA/66
May 23 13:43:19 Trenholme kernel: [    3.850856] ata3.01: ATA-7: Maxtor 6Y250P0, YAR41BW0, max UDMA/133
May 23 13:43:19 Trenholme kernel: [    3.850865] ata3.01: 490234752 sectors, multi 16: LBA48
May 23 13:43:19 Trenholme kernel: [    3.858193] ata3.00: configured for UDMA/66
May 23 13:43:19 Trenholme kernel: [    3.865846] ata3.01: configured for UDMA/100
May 23 13:43:19 Trenholme kernel: [    4.039718] ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
May 23 13:43:19 Trenholme kernel: [    4.039778] ata3.01: BMDMA stat 0x14
May 23 13:43:19 Trenholme kernel: [    4.039826] ata3.01: failed command: READ DMA EXT
May 23 13:43:19 Trenholme kernel: [    4.039880] ata3.01: cmd 25/00:08:98:a7:ac/00:00:14:00:00/f0 tag 0 dma 4096 in
May 23 13:43:19 Trenholme kernel: [    4.040091] ata3.01: status: { DRDY ERR }
May 23 13:43:19 Trenholme kernel: [    4.040143] ata3.01: error: { ICRC ABRT }
May 23 13:43:19 Trenholme kernel: [    4.040224] ata3: soft resetting link

That is, my "bad" disk is a type ATA-7 Maxtor HD, serial number 6Y259P0. (In my case, that drive is in an old "hot swap" box that mangles newer ATA commands, so I see this stuff every time I boot the system. I'm going to replace the hot-swap box when I can afford it, so it won't be soon.)

<edit>
By the way, note the line preceding the one I highlighted. That tells me that my problem drive is the "slave" drive (ATA3.01) on the third PATA cable, where my DVD drive is in the "master" slot (ATA3.00) of that cable. So your ATA5.00 drive should be in the "master" slot of your fifth drive cable. (If you have SATA cables, that might be your fifth drive. My system is a decade old, and SATA drives weren't available when I built it.)
</edit>

MasterOfTheWind 05-23-2011 02:04 PM

Ladies and gents, I have been able to pin down the problem. After what I can see my backup drive has silently died. It stays unmounted by default - that is why I had the impression that all drives are working.

@PTrenholme: Nope, nothing. The only thing I did with the snippet from my messages log was to trim off the beginning of the line - indicating date and hostname (for safety reasons). I know it is very strange that no identifiers were printed anywhere - but that is perhaps because the hdd is so kaput that it is unable to identify itself properly? Otherwise I do not have any good explanation for this behavior - all my other hard drives identify themselves correctly.

MasterOfTheWind 05-23-2011 02:15 PM

Everyone, thanks for the help! It's really appreciated!

ectospasm 02-05-2013 01:10 AM

Script to determine ataN...
 
This script will only work if you've booted relatively recently (and it's geared towards Debian; it writes the ataN information to /var/log/kern.log). If you have logrotate enabled there's a chance the relevant information has been rotated out, so be wary. You might have to change kern.log to messages depending on your distro of choice. As I said this works for me on Debian sid (or would have, if the relevant bits hadn't been rotated into oblivion ;-):

Code:

#!/bin/bash                                                                                 
                                                                                             
# 1. Get current uptime                                                                     
uptime=$(uptime | awk -F' '  '{ print $3" "$4 }' | sed s/,//)                               
                                                                                             
# 2. calculate boot date from uptime                                                         
date=$(date -d "$uptime ago" | awk '{print $2" "$3 }')                                       
                                                                                             
# Once we have the first two above, set up a rather elaborate pipeline                       
# 3.  Find info from boot date in kern.log (even gzipped, hence the zgrep)                   
# 4.  Find the ata relevant bits                                                             
# 5.  Strip out the extra stuff we don't need (first sed)                                   
# 6.  sort and strip out more stuff we don't need                                           
# 7.  Print out a list of ataN controller devices mapped to /dev devices (e.g. hda, sdb, etc.)       
zgrep "$date"  /var/log/kern.log*  | \                                                       
grep 'ata[0-9]\+.[0-9][0-9]: ATA'  | \                                                       
sed 's/^.*\] ata//' | \                                                                     
sort -n | sed 's/:.*//' | \                                                                 
awk ' { a="ata" $1; printf("%10s is /dev/sd%c\n", a, 96+NR); }'

That should give you output similar to the following:
Code:

ata1 is /dev/hda
ata3 is /dev/sda
ata4 is /dev/sdb
ata5 is /dev/sdc

Your output will differ, possibly greatly depending on how many ATA devices you have connected, and on the particular hardware controller specifics (firmware, kernel driver, etc.). Alas, this script isn't currently working for me because my uptime is roughly 31 days, and goes back to Jan 5. The earliest time I have in any of my kern.log files is Jan 6. Go figure.

PTrenholme 02-05-2013 09:25 PM

This is a rather old thread, but, for what it's worth, most modern distributions using udev will have this command:
Code:

$ ls -l /dev/disk/by-id | sort -k 11
total 0
lrwxrwxrwx. 1 root root 11 Feb  5 19:03 md-name-HP-p6710f:127 -> ../../md126
lrwxrwxrwx. 1 root root 11 Feb  5 19:03 md-uuid-31ae217a:e7564465:9e527f40:40dcd2b8 -> ../../md126
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 ata-ST31000528AS_6VPBQVS7 -> ../../sda
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 wwn-0x5000c50032d81e7f -> ../../sda
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 ata-ST31000528AS_6VPBQVS7-part1 -> ../../sda1
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 wwn-0x5000c50032d81e7f-part1 -> ../../sda1
lrwxrwxrwx. 1 root root 10 Feb  5 19:04 ata-ST31000528AS_6VPBQVS7-part2 -> ../../sda2
lrwxrwxrwx. 1 root root 10 Feb  5 19:04 wwn-0x5000c50032d81e7f-part2 -> ../../sda2
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 ata-ST31000528AS_6VPBQVS7-part3 -> ../../sda3
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 wwn-0x5000c50032d81e7f-part3 -> ../../sda3
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 ata-ST31000528AS_6VPBQVS7-part4 -> ../../sda4
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 wwn-0x5000c50032d81e7f-part4 -> ../../sda4
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 ata-ST31000528AS_6VPBQVS7-part5 -> ../../sda5
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 wwn-0x5000c50032d81e7f-part5 -> ../../sda5
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 ata-ST2000DL003-9VT166_5YD3C2FZ -> ../../sdb
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 wwn-0x5000c500385662bf -> ../../sdb
lrwxrwxrwx. 1 root root 10 Feb  5 19:04 ata-ST2000DL003-9VT166_5YD3C2FZ-part1 -> ../../sdb1
lrwxrwxrwx. 1 root root 10 Feb  5 19:04 wwn-0x5000c500385662bf-part1 -> ../../sdb1
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 ata-ST2000DL003-9VT166_5YD3C2FZ-part2 -> ../../sdb2
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 wwn-0x5000c500385662bf-part2 -> ../../sdb2
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 ata-ST2000DL003-9VT166_5YD3C2FZ-part3 -> ../../sdb3
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 wwn-0x5000c500385662bf-part3 -> ../../sdb3
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 ata-WDC_WD20EARX-00PASB0_WD-WMAZA8382941 -> ../../sdc
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 wwn-0x50014ee25c328225 -> ../../sdc
lrwxrwxrwx. 1 root root 10 Feb  5 19:04 ata-WDC_WD20EARX-00PASB0_WD-WMAZA8382941-part1 -> ../../sdc1
lrwxrwxrwx. 1 root root 10 Feb  5 19:04 wwn-0x50014ee25c328225-part1 -> ../../sdc1
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 ata-WDC_WD20EARX-00PASB0_WD-WMAZA8382941-part2 -> ../../sdc2
lrwxrwxrwx. 1 root root 10 Feb  5 19:03 wwn-0x50014ee25c328225-part2 -> ../../sdc2
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 usb-Generic-_SD_MMC_18E391066476-0:0 -> ../../sdd
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 usb-Generic-_Compact_Flash_18E391066476-0:1 -> ../../sde
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 usb-Generic-_SM_xD-Picture_18E391066476-0:2 -> ../../sdf
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 usb-Generic-_MS_MS-Pro_18E391066476-0:3 -> ../../sdg
lrwxrwxrwx. 1 root root  9 Feb  5 19:03 ata-hp_DVD_A_DH16ABLH_3L8108904593 -> ../../sr0

available. Of course, if - as the OP reported - your dive is inoperative to the point that the drirve is not available to the kernel, the kernel can tell you nothing about it.

ectospasm 02-06-2013 03:25 AM

Quote:

Originally Posted by PTrenholme (Post 4885189)
This is a rather old thread, but, for what it's worth, most modern distributions using udev will have this command:$ ls -l /dev/disk/by-id | sort -k 11...available. Of course, if - as the OP reported - your dive is inoperative to the point that the drirve is not available to the kernel, the kernel can tell you nothing about it.

But that still doesn't tell you what 'ata5' is... It just shows the ID of the disk if the kernel sees it. If it's in the log my method should find it, even if the kernel doesn't presently see the device.

affinityvision 02-06-2014 04:31 AM

Here's my script, based on a couple of posts above (this for current 7.3 Debian)
Code:

#!/bin/bash

# Show disk model/serial numbers
#
(
cd /dev/disk/by-id/
# ata
echo "ATA:"
ls -l ata* | sort -k 11|grep [a-z]$|awk '{print "\t"substr($NF,7,3)"\t"substr($9,5)}'
echo

# SCSI does not seem to add anything useful...
# scsi
#echo "SCSI:"
#ls -l scsi* | sort -k 11|grep [a-z]$|awk '{print "\t"substr($NF,7,3)"\t"substr($9,6)}'
#echo

# wwn
echo "WWN:"
ls -l wwn* | sort -k 11|grep [a-z]$|awk '{print "\t"substr($NF,7,3)"\t"substr($9,5)}'
echo
)


# 1. Get current uptime
uptime=$(uptime | awk -F' '  '{ print $3" "$4 }' | sed s/,//)
echo "Uptime: $uptime"

# 2. calculate boot date from uptime
date=""
date=$(date -d "$uptime ago" 2>/dev/null | awk '{print substr($3,1,3)" "$2 }')
# if the above assignment of date fails, then let's work it out from the
# current /var/log/kern.log file (uptime doesn't have a number of days...)
if [ -z $date ];
then
        date=$(grep "log source = /proc/kmsg started.$" /var/log/kern.log)
        date=${date:0:6}
fi

read -r aaaa bbbb <<< $(echo $date)
if [ ${#bbbb} -eq 1 ];then date="$aaaa  $bbbb";fi
echo "Date: \"$date\""
echo

kernfile=$(zgrep -l "^${date}.*log source = /proc/kmsg started.$" /var/log/kern.log*)
echo $kernfile
echo

aaa=$(zgrep "log source = /proc/kmsg started.$" $kernfile|tail -1);aaa=${aaa:0:10}


echo "NB: The following information is from BOOT time, it could be wrong now...."
echo
# Once we have the first two above, set up a rather elaborate pipeline
# 3.  Find info from boot date in kern.log (even gzipped, hence the zgrep)
# 4.  Find the ata relevant bits
# 5.  Strip out the extra stuff we don't need (first sed)
# 6.  sort and strip out more stuff we don't need
# 7.  Print out a list of ataN controller devices mapped to /dev devices (e.g. hda, sdb, etc.)
zgrep "^$aaa"  $kernfile  | \
grep 'ata[0-9]\+.[0-9][0-9]: ATA'  | \
sed 's/^.*\] ata//' | \
sort -n | sed 's/:.*//' | \
awk ' { a="ata" $1; printf("%10s is /dev/sd%c\n", a, 96+NR); }'

Edit: slight adjustment, if the machine was rebooted multiple times on the day, then take details from the last boot of the day ... also cater for date being between 1 and 9 of the month, still further refinement.


All times are GMT -5. The time now is 01:42 AM.