Date: Fri, 22 Feb 2013 10:21:45 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Claude Buisson <clbuisson@orange.fr> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: DVD/CD lost after r246713 Message-ID: <20130222082145.GJ2598@kib.kiev.ua> In-Reply-To: <51265A58.4010600@orange.fr> References: <51265A58.4010600@orange.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
--w8XPRyCD3+ebNMRa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 21, 2013 at 06:33:12PM +0100, Claude Buisson wrote: > Hi, >=20 > When trying to update a i386 system from r245422 to r246923, the DVD/CD d= evices > cd0/cd1 could no more be attached. >=20 > Here is a relevant part of a verbose dmaeg: >=20 > 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 u= sbus0 > ums0: 3 buttons and [XYZ] coordinates ID=3D0 > ata1: reset tp1 mask=3D03 ostat0=3Dd0 ostat1=3D50 > ata1: stat0=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata1: stat1=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata1: reset tp2 stat0=3D10 stat1=3D10 devices=3D0x30000 > (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=3D03 ostat0= =3D50 ostat1=3Dd0 > ata1: stat0=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata1: stat1=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata1: reset tp2 stat0=3D10 stat1=3D10 devices=3D0x30000 > (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 >=20 > First i tried some snapshots from allbsd.org, to verify that the same pro= blem > existed with independently generated systems, then I made a search to fin= d that > the "culprit" was: >=20 > Author: kib > Date: Tue Feb 12 16:57:20 2013 > New Revision: 246713 > URL: http://svnweb.freebsd.org/changeset/base/246713 >=20 > 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. >=20 > The cam changes unify the bus_dmamap_load* handling in cam drivers. >=20 > 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. >=20 > 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>) >=20 > I even tried to rebuild the system WITHOUT_CLANG, just to eliminate the > "compiler factor" (with r247000 applied of course). >=20 > If necessary I can send complete verbose dmesg at r245422 and r246923. >=20 > Thanks for your attention >=20 > CBu >=20 > P.S. GREAT THANKS to allbsd.org for this its very useful collection of wo= rking > memstick images ! but with the remark that the documented revision number= s 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. --w8XPRyCD3+ebNMRa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRJyqYAAoJEJDCuSvBvK1B1UcP/jN2AnlT8ByMYLLJSwo239q0 dHKRJoslV0Uoh7D0AVmB1bNQxeKd4/jDr7lUKWR2p8gCSsqJUd2FZFp39jkA6N41 ZO3on3U9bAqEp9HI+OUM8ayBdarQprrkmwEveyFqAxOdrIYrgGvYUkzrqJGJHs07 muR6Ou9Xwah08lp7npMOOnKIpzmeMfE050FMPkfRZBu2BCP14z8zsef0bIv9olDp GDlSnnXs4avmKU1eufeJuB1hena4D1thZ8hmRiAm4wz6vzRdX/VnGhqWgIRf1NHo O5QB+DkEUwQT/+xy2avd7FF3cZVFDzMH3+16uB76g7r1dfzTI8ZXo/Uz4E70B2K/ sU0L7caZd/uMU+pvSAmsy/XOLRLzcUoHCjTHXES7YEUtIwSHa/UBkaENDVeT1RC9 FHAXqTMu/bTl+CRg2iU9PxVpW6kFZDX+HN4VrNDfdmdu0CgO5n1ea7QX7MVBJrAA qfzHx0vnkIeN96F1QndO4NJ/0R62K2lwcj5I2p+VZxnc4ZK0VhqGZsUyBPrz2pIi 6Tn90tCVIKHShiyH4wc9e6Ra/mQYQRtT9Va4vC65qQUql76waH8lEtB5+AOGUH2L w7Mqe6WTe36RcRG2fu1HBj2Q9Gmzr7DXG+RM5lEnCvUCS0yA2aYAcct706KFqlto hfQ78z5RSeX0t1Tr88Ua =vqSv -----END PGP SIGNATURE----- --w8XPRyCD3+ebNMRa--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130222082145.GJ2598>