Re: ATA? related trouble with r300299

On Tue, May 24, 2016 at 00:15:25 +0300, Oleg V. Nauman wrote:
> On Monday 23 May 2016 17:11:34 Kenneth D. Merry wrote:
> > On Tue, May 24, 2016 at 00:05:49 +0300, Oleg V. Nauman wrote:
> > > On Monday 23 May 2016 16:53:55 Kenneth D. Merry wrote:
> > > > On Mon, May 23, 2016 at 23:21:32 +0300, Oleg V. Nauman wrote:
> > > > > On Monday 23 May 2016 15:25:39 Kenneth D. Merry 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
> > > > > > 
> > > > > > 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.
> > > > >  
> > > > >  I was able to boot after applying the patch ;
> > > > > 
> > > > > kern.cam.ada.0.quirks="0x04"
> > > > > was the quirk in effect. It is quirk for my Samsung HD200HJ KF100-06
> > > > > hard
> > > > > drive.
> > > > 
> > > > Okay.  Just so we can narrow it down a little more, can you try this:
> > > > 
> > > > First, let's try getting an ATA Log directory using the PIO version of
> > > > the
> > > > command:
> > > > 
> > > > camcontrol cmd ada0 -v -a "2f 0 0 0 0 0 0 0 0 0 1 0" -i 512 - |hd
> > > > 
> > > > If that works (you should get hexdump output), try the DMA version of
> > > > the
> > > > command:
> > > > 
> > > > camcontrol cmd ada0 -v -d -a "47 0 0 0 0 0 0 0 0 0 1 0" -i 512 - |hd
> > > 
> > > "Expecting a character pointer argument." error for both commands.
> > 
> > Did the double quotes make it onto the command line?  Both of those work
> > for me...
> 
>  Something went wrong from my side, sorry.
> Below is the output of commands:
> 
> root_at_desktop:~ # camcontrol cmd ada0 -v -a "2f 0 0 0 0 0 0 0 0 0 1 0" -i 512 - 
> |hd
> camcontrol: error sending command
> (pass1:ata2:0:0:0): READ_LOG_EXT. ACB: 2f 00 00 00 00 00 00 00 00 00 01 00
> (pass1:ata2:0:0:0): CAM status: ATA Status Error
> (pass1:ata2:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
> (pass1:ata2:0:0:0): RES: 51 04 00 00 00 00 00 00 00 01 00
> root_at_desktop:~ # camcontrol cmd ada0 -v -d -a "47 0 0 0 0 0 0 0 0 0 1 0" -i 
> 512 - |hd
> camcontrol: error sending command
> (pass1:ata2:0:0:0): READ_LOG_DMA_EXT. ACB: 47 00 00 00 00 00 00 00 00 00 01 00
> (pass1:ata2:0:0:0): CAM status: ATA Status Error
> (pass1:ata2:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT )
> (pass1:ata2:0:0:0): RES: 51 04 00 00 00 00 00 00 00 01 00

Okay, at least it consistently fails with both the PIO and DMA versions.
Looks like the drive claims to support READ LOG, but doesn't actually
support it.

Can you revert the previous patch, take the quirk out of loader.conf, and
try this patch?

https://people.freebsd.org/~ken/cam_smr_ada_patch.20160523.2.txt

It adds the model number for your drive into the ada(4) driver as a quirk.

Thanks,

Ken
-- 
Kenneth Merry
ken_at_FreeBSD.ORG