kern/54982: data corruption with usb umass da msdosfs digital camera 5.1-CURRENT

Jan-Espen Pettersen sigsegv at leakingmemory.org
Mon Jul 28 08:10:20 PDT 2003


>Number:         54982
>Category:       kern
>Synopsis:       data corruption with usb umass da msdosfs digital camera 5.1-CURRENT
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 28 08:10:18 PDT 2003
>Closed-Date:
>Last-Modified:
>Originator:     Jan-Espen Pettersen
>Release:        FreeBSD 5.1-CURRENT i386
>Organization:
>Environment:
System: FreeBSD endeavour.localnet.radiotube.org 5.1-CURRENT FreeBSD 5.1-CURRENT #19: Thu Jul 24 18:04:14 CEST 2003 sigsegv at endeavour.sky.dom:/usr/obj/usr/src/FreeBSD-CURRENT/sys/ENDEAVOUR i386
nForce2 chipset, aBit NF7-M motherboard, no known hardware problems, no known memory problems.
FSB, PCI, CPU, are overclocked, but seems to work without problems. No problem running 'make buildworld'
>Description:
The commits at 2003/07/15 15:42:37 PDT and 2003/07/15 16:12:54 PDT introduced
a data corruption problem with the USB, umass, da system. I was able to retrieve
valid jpeg images from the msdos filesystem on the device before the first of
the two commits, without any problems. umass was unusable after the fisrt commit.
After the second commit I was able to mount th efilesystem, but the files were corrupted.
I ktraced 'cat < phto001.jpg' the image seemed to contain data which probably came from
uninitialized memory (parts of the files were just zeros, and other parts were cvs
output lines (I would guess it was previously free'ed data from cvs, ttyp?, etc)).
                                                                                               
Going back to sources just before the first commit did always fix the problem.
                                                                                               
The problem does exist on both usb0 and usb1
                                                                                               
cvs-src mailinglist URLs:
http://lists.freebsd.org/pipermail/cvs-src/2003-July/007150.html
http://lists.freebsd.org/pipermail/cvs-src/2003-July/007153.html
                                                                                               
A workaround is to use sources older than 2003/07/15 15:42:37 PDT.
                                                                                               
ohci0: <OHCI (generic) USB controller> mem 0xef003000-0xef003fff irq 12 at device 2.0 on pci0
usb0: OHCI version 1.0, legacy support
usb0: <OHCI (generic) USB controller> on ohci0
usb0: USB revision 1.0
uhub0: (0x10de) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1: <OHCI (generic) USB controller> mem 0xef004000-0xef004fff irq 10 at device 2.1 on pci0
usb1: OHCI version 1.0, legacy support
usb1: <OHCI (generic) USB controller> on ohci1
usb1: USB revision 1.0
uhub1: (0x10de) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
                                                                                               
umass0: DSC DIGITAL CAMERA USB, rev 1.00/1.00, addr 2
umass0: 8070i (ATAPI) over CBI; quirks = 0x0000
umass0:0:0:-1: Attached to scbus0
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <IDIGAT L ACEMAR .100> Removable Direct Access SCSI-0 device
da0: 1.000MB/s transfers
da0: 122MB (250880 512 byte sectors: 64H 32S/T 122C)
                                                                                               

	
>How-To-Repeat:
Insert an usb digital camera, mount it, and try to read files from it.
	
>Fix:
I don't know yet.
	


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list