CentOS - Jan 2010 - How to map ata#.# numbers to /dev/sd numbers?

On my C5 machine (a Dell XPS420) I have a 500Gb disk on the internal SATA
controller.

I also have a SiI3132 dual-port multi-device eSATA card.  This is connected
to an external SATA array of disks.

Now occasionally I see something like this in my logs

ata7.01: exception Emask 0x0 SAct 0x0 SErr 0x0 a ction 0x0
ata7.01: irq_stat 0x00060002, device error via D 2H FIS
ata7.01: cmd 25/00:08:47:1c:92/00:00:6c:00:00/e0 tag 0 dma 4096 in
         res 51/40:00:4e:1c:92/00:00:6c:00:00/00 Emask 0x9 (media error)
ata7.01: status: { DRDY ERR }
ata7.01: error: { UNC }
ata7.01: configured for UDMA/100
ata7: EH complete

How do I tell what disk this is complaining about?  Is there a way
to determine what ata7.01 maps to in terms of /dev/sd# values?

/proc/scsi/scsi doesn't obviously match scsi# numbers to ata# numbers :-(

-- 

rgds
Stephen

Stephen Harris wrote:
> On my C5 machine (a Dell XPS420) I have a 500Gb disk on the internal SATA
> controller.
> 
> I also have a SiI3132 dual-port multi-device eSATA card.  This is connected
> to an external SATA array of disks.
> 
> Now occasionally I see something like this in my logs
> 
> ata7.01: exception Emask 0x0 SAct 0x0 SErr 0x0 a ction 0x0
> ata7.01: irq_stat 0x00060002, device error via D 2H FIS
> ata7.01: cmd 25/00:08:47:1c:92/00:00:6c:00:00/e0 tag 0 dma 4096 in
>          res 51/40:00:4e:1c:92/00:00:6c:00:00/00 Emask 0x9 (media error)
> ata7.01: status: { DRDY ERR }
> ata7.01: error: { UNC }
> ata7.01: configured for UDMA/100
> ata7: EH complete
> 
> How do I tell what disk this is complaining about?  Is there a way
> to determine what ata7.01 maps to in terms of /dev/sd# values?
> 
> /proc/scsi/scsi doesn't obviously match scsi# numbers to ata# numbers
:-(
> 
Try looking in /dev/disk/

-- 
tkb

On Thursday 28 January 2010, Stephen Harris wrote:
...
> Now occasionally I see something like this in my logs
>
> ata7.01: exception Emask 0x0 SAct 0x0 SErr 0x0 a ction 0x0
...
> How do I tell what disk this is complaining about?  Is there a way
> to determine what ata7.01 maps to in terms of /dev/sd# values?
>
> /proc/scsi/scsi doesn't obviously match scsi# numbers to ata# numbers
:-(
This seems quite hard to do. The following hack will match scsi hosts to 
libata-driver + number:

 $ for d in $(ls -d /sys/class/scsi_host/host?); do echo "$d $(cat \
   $d/proc_name) $(cat $d/unique_id)" ; done
/sys/class/scsi_host/host0 ahci 1
/sys/class/scsi_host/host1 ahci 2
/sys/class/scsi_host/host2 ahci 3
/sys/class/scsi_host/host3 ahci 4
/sys/class/scsi_host/host4 ahci 5
/sys/class/scsi_host/host5 ahci 6

This does not get you all the way though, but unless you have several 
different libata-drivers ahci 1-6 above will match ata1-ata6 (read "dmesg |
less"...).

Once you know which scsi-host you're looking for the /dev/sdX name can be
had
from many sources (like the output of "lsscsi").

/Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.centos.org/pipermail/centos/attachments/20100128/ae09a7af/attachment-0001.sig>

> On Thursday 28 January 2010, Stephen Harris wrote:
> ...
>> Now occasionally I see something like this in my logs
>>
>> ata7.01: exception Emask 0x0 SAct 0x0 SErr 0x0 a ction 0x0
> ...
>> How do I tell what disk this is complaining about?  Is there a way
>> to determine what ata7.01 maps to in terms of /dev/sd# values?
>>
>> /proc/scsi/scsi doesn't obviously match scsi# numbers to ata#
numbers
>> :-(
>
> This seems quite hard to do. The following hack will match scsi hosts to
> libata-driver + number:
<snip>
Have you checked dmesg? For example,
<snip>
SCSI subsystem initialized
libata version 3.00 loaded.
sata_sil 0000:01:0b.0: version 2.3
ACPI: PCI Interrupt 0000:01:0b.0[A] -> GSI 17 (level, low) -> IRQ 193
scsi0 : sata_sil
scsi1 : sata_sil
scsi2 : sata_sil
scsi3 : sata_sil
ata1: SATA max UDMA/100 mmio m1024 at 0xfc6ffc00 tf 0xfc6ffc80 irq 193
ata2: SATA max UDMA/100 mmio m1024 at 0xfc6ffc00 tf 0xfc6ffcc0 irq 193
ata3: SATA max UDMA/100 mmio m1024 at 0xfc6ffc00 tf 0xfc6ffe80 irq 193
ata4: SATA max UDMA/100 mmio m1024 at 0xfc6ffc00 tf 0xfc6ffec0 irq 193
<snip>
        mark