From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 17:33:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2BCF83F9 for ; Thu, 21 Feb 2013 17:33:23 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by mx1.freebsd.org (Postfix) with ESMTP id 9C32E967 for ; Thu, 21 Feb 2013 17:33:22 +0000 (UTC) Received: from localhost ([109.223.1.180]) by mwinf5d51 with ME id 35ZD1l00y3t1atZ035ZEnW; Thu, 21 Feb 2013 18:33:14 +0100 Message-ID: <51265A58.4010600@orange.fr> Date: Thu, 21 Feb 2013 18:33:12 +0100 From: Claude Buisson User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: FreeBSD Current Subject: DVD/CD lost after r246713 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 17:33:23 -0000 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: 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: 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: 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: 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: at usbus0 ums0: 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 ) 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 (?!)