Is there way to get filename for specific LBA?

perryh at perryh at
Wed Aug 31 23:25:21 UTC 2011

Ross <basarevych at> wrote:

> >> Aug 31 05:13:24 da kernel: ad6: WARNING - READ_DMA UDMA ICRC
> >> error (retrying request) LBA=107491647
> > ...
> > What does
> >
> > ??egrep 'ad[0-9]|ata' /var/run/dmesg.boot
> >
> > report?
> atapci0: <Intel ICH7 SATA300 controller> port
> 0x20b8-0x20bf,0x20cc-0x20cf,0x20b0-0x20b7,0x20c8-0x20cb,0x20a0-0x20af
> mem 0xe0284000-0xe02843ff irq 19 at device 31.2 on pci0
> atapci0: [ITHREAD]
> ata2: <ATA channel 0> on atapci0
> ata2: [ITHREAD]
> ata3: <ATA channel 1> on atapci0
> ata3: [ITHREAD]
> ad4: 238475MB <Seagate ST9250315AS 0001SDM1> at ata2-master UDMA100 SATA
> ad6: 476940MB <Seagate ST9500325AS 0001SDM1> at ata3-master UDMA100 SATA
> Trying to mount root from ufs:/dev/ad6s1a

Different hardware than mine, so my w/a may not help.

If it's only happened the one time, you may want to just write it
off as a glitch.  If it happens frequently, or you start getting
unrecovered failures, you could _try_

  atacontrol mode ad6 UDMA66

Slowing down the transfer rate may make it more tolerant of
electrical noise, bad cabling, etc.  This approach worked for
me, but on a PATA (not SATA) port and using a different type
of controller (a VIA 6421).

> smartd also reports this:
> Aug 31 10:41:04 da smartd[886]: Device: /dev/ad6, Failed SMART
> usage Attribute: 184 End-to-End_Error.
> I found this explanation:
> So disk is dying? Or is it cable. I have no physical access to
> the server at the moment.

I'll leave the SMART analysis to those who are familiar with it :)

More information about the freebsd-questions mailing list