> 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@0xfc6ffc00 tf 0xfc6ffc80 irq 193
ata2: SATA max UDMA/100 mmio m1024@0xfc6ffc00 tf 0xfc6ffcc0 irq 193
ata3: SATA max UDMA/100 mmio m1024@0xfc6ffc00 tf 0xfc6ffe80 irq 193
ata4: SATA max UDMA/100 mmio m1024@0xfc6ffc00 tf 0xfc6ffec0 irq 193
<snip>
mark
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
