Re: DVD/CD lost after r246713

On Thu, Feb 21, 2013 at 06:33:12PM +0100, Claude Buisson wrote:
> Hi,
> 
> When trying to update a i386 system from r245422 to r246923, the DVD/CD devices
> cd0/cd1 could no more be attached.
> 
> Here is a relevant part of a verbose dmaeg:
> 
> pass0 at ata0 bus 0 scbus0 target 0 lun 0
> pass0: <WDC WD3200AAJB-00J3A0 01.03E01> ATA-8 device
> pass0: Serial Number WD-WCAV2F115406
> pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
> pass1 at ata0 bus 0 scbus0 target 1 lun 0
> pass1: <WDC WD600BB-75CAA0 16.06V16> ATA-5 device
> pass1: Serial Number WD-WMA8F2128712
> pass1: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
> pass2 at ata1 bus 0 scbus1 target 0 lun 0
> pass2: <SAMSUNG DVD-ROM SD-616T F310> Removable CD-ROM SCSI-0 device
> pass2: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
> pass3 at ata1 bus 0 scbus1 target 1 lun 0
> pass3: <HL-DT-ST CD-RW GCE-8481B C102> Removable CD-ROM SCSI-0 device
> pass3: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
> TSC timecounter discards lower 1 bit(s)
> Timecounter "TSC-low" frequency 1196040076 Hz quality 800
> uhub0: 2 ports with 2 removable, self powered
> uhub1: 2 ports with 2 removable, self powered
> uhub2: 2 ports with 2 removable, self powered
> GEOM: new disk cd0
> GEOM: new disk cd1
> GEOM: new disk ada0
> GEOM: new disk ada1
> uhub3: 6 ports with 6 removable, self powered
> ugen0.2: <Logitech> at usbus0
> ums0: <Logitech Optical USB Mouse, class 0/0, rev 2.00/3.40, addr 2> on usbus0
> ums0: 3 buttons and [XYZ] coordinates ID=0
> ata1: reset tp1 mask=03 ostat0=d0 ostat1=50
> ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb
> ata1: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb
> ata1: reset tp2 stat0=10 stat1=10 devices=0x30000
> (cd0:ata1:0:0:0): got CAM status 0x50
> (cd0:ata1:0:0:0): fatal error, failed to attach to device
> (cd0:ata1:0:0:0): lost device, 4 refs
> Opened disk cd0 -> 6
> (cd0:ata1:0:0:0): removing device entryata1: reset tp1 mask=03 ostat0=50 ostat1=d0
> ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb
> ata1: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb
> ata1: reset tp2 stat0=10 stat1=10 devices=0x30000
> (cd1:ata1:0:1:0): got CAM status 0x50
> (cd1:ata1:0:1:0): fatal error, failed to attach to device
> (cd1:ata1:0:1:0): lost device, 4 refs
> Opened disk cd1 -> 6
> (cd1:ata1:0:1:0): removing device entry
> 
> First i tried some snapshots from allbsd.org, to verify that the same problem
> existed with independently generated systems, then I made a search to find that
> the "culprit" was:
> 
> Author: kib
> Date: Tue Feb 12 16:57:20 2013
> New Revision: 246713
> URL: http://svnweb.freebsd.org/changeset/base/246713
> 
> Log:
>    Reform the busdma API so that new types may be added without modifying
>    every architecture's busdma_machdep.c.  It is done by unifying the
>    bus_dmamap_load_buffer() routines so that they may be called from MI
>    code.  The MD busdma is then given a chance to do any final processing
>    in the complete() callback.
> 
>    The cam changes unify the bus_dmamap_load* handling in cam drivers.
> 
>    The arm and mips implementations are updated to track virtual
>    addresses for sync().  Previously this was done in a type specific
>    way.  Now it is done in a generic way by recording the list of
>    virtuals in the map.
> 
>    Submitted by:	jeff (sponsored by EMC/Isilon)
>    Reviewed by:	kan (previous version), scottl,
>    	mjacob (isp(4), no objections for target mode changes)
>    Discussed with:	     ian (arm changes)
>    Tested by:	marius (sparc64), mips (jmallet), isci(4) on x86 (jharris),
>    	amd64 (Fabian Keil <freebsd-listen at fabiankeil.de>)
> 
> I even tried to rebuild the system WITHOUT_CLANG, just to eliminate the
> "compiler factor" (with r247000 applied of course).
> 
> If necessary I can send complete verbose dmesg at r245422 and r246923.
> 
> Thanks for your attention
> 
> CBu
> 
> P.S. GREAT THANKS to allbsd.org for this its very useful collection of working
> memstick images ! but with the remark that the documented revision numbers seems
> to be inexacts: the 246711 snapshot exhibited this same problem (?!)

You need to provide the dmesg from r246713 and r246712 to compare.
The note that r246711 snapshot exhibited this same problem makes
me sceptical.