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-0004.sig>