Re: ATA? related trouble with r300299

As Oleg mentioned, that was due to the compatibility shims for the old ATA layer getting removed.  The only thing required to get those machines to boot would be to change /dev/ad* in /boot/loader.conf to the correct /dev/ada device.

Ken
— 
Ken Merry
ken_at_FreeBSD.ORG



> On May 24, 2016, at 12:42 AM, Olli Hauer <ohauer_at_gmx.de> wrote:
> 
> Not sure, but maybe related.
> I had 5 old ata systems running, doing ntp and dns cache (running since 5.0 lifted over time to 10.x) The systems showed no smart or any other defects. 
> Last year they began stop working with strange messages like adaX not found where in fstab still was ataX (back from 5.x) ...
> Meanwhile the systems are replaced and thrown away.
> If from interest i can look for old logs.
> 
> 
> On 23/05/2016, 21:25 "Kenneth D. Merry" <ken_at_FreeBSD.ORG> wrote:
> On Sat, May 21, 2016 at 09:30:35 +0300, Oleg V. Nauman wrote:
> >
> > I have faced the issue with fresh CURRENT stopped to boot on my old desktop
> > after update to r300299
> > Verbose boot shows the endless cycle of
> >
> > ata2: SATA reset: ports status=0x05
> > ata2: reset tp1 mask=03 ostat0=50 ostat1=50
> > ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > ata2: stat1=0x50 err=0x01 lsb=0x00 msb=0x00
> > ata2: reset tp2 stat0=50 stat1=50 devices=0x3
> > messages logged to console.
> >
> > Below is the relevant portion of ATA controller/devices probed/attached during
> > the boot:
> >
> > atapci0: <Intel ICH7 UDMA100 controller> port
> > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
> > ata0: <ATA channel> at channel 0 on atapci0
> > atapci1: <Intel ICH7 SATA300 controller> port 0xd080-0xd087, 0xd000-0xd003,
> > 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc80f irq 19 at device 31.2 on pci0
> > ata2: <ATA channel> at channel 0 on atapci1
> > ata3: <ATA channel> at channel 1 on atapci1
> > ada0 at ata2 bus 0 scbus1 target 0 lun 0
> > ada0: <SAMSUNG HD200HJ KF100-06> ATA-7 SATA 2.x device
> > ada1 at ata2 bus 0 scbus1 target 1 lun 0
> > ada1: <ST500DM002-1BC142 JC4B> ATA8-ACS SATA 3.x device
> > cd0 at ata0 bus 0 scbus0 target 0 lun 0
> > cd0: <_NEC DVD_RW ND-3570A 1.11> Removable CD-ROM SCSI device
> 
> I'm not entirely sure what is causing the problem with your system, but
> hopefully we can narrow it down a bit.
> 
> There is a bug that came in with my SMR changes in revision 300207 that
> broke the quirk functionality in the ada(4) driver. I don't think that is
> the problem you're seeing, though.
> 
> Can you try out this patch:
> 
> https://people.freebsd.org/~ken/cam_smr_ada_patch.20160523.1.txt <https://people.freebsd.org/~ken/cam_smr_ada_patch.20160523.1.txt>
> 
> In /boot/loader.conf, put the following:
> 
> kern.cam.ada.0.quirks="0x04"
> kern.cam.ada.1.quirks="0x04"
> 
> If you're able to boot with those quirk entries in the loader.conf, try
> taking one of them out, and reboot. If that works, try taking the other
> one out and reboot.
> 
> What I'm trying to figure out here is where the problem lies:
> 
> 1. The bug with the ada(4) driver (in where it loaded the quirks).
> 2. The extra probe steps in the ada(4) driver might be causing a problem
> with ada0 (Samsung drive).
> 3. The extra probe steps in the ada(4) driver might be causing a problem
> with ada1 (Seagate drive).
> 4. Something else.
> 
> So, if you can try the patch and try to eliminate a few possibilities, we
> may be able to narrow it down.
> 
> Thanks,
> 
> Ken
> --
> Kenneth Merry
> ken_at_FreeBSD.ORG
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>