> 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