Hi Guys, Thanks for taking the time to respond. On 13 May 2011 18:28, Robert Pearce <rob@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 13 May 2011 17:33:07 +0100 you wrote: >> embedded platform running the 2.6.8.1 kernel > > Did you mean that? Or was it a typo and should say 2.6.38.1? If the > former then somebody will reply saying please use something slightly > approximating a modern kernel. Unfortunately it wasn't a typo, the following is the version info for our target: ~ # cat /proc/version Linux version 2.6.8.1-crus2.0.8 (nightbuilder@bob) (gcc version 3.4.3) #1 Fri May 13 00:06:25 BST 2011 Updating to a newer Kernel is something we have considered, but before attempting this we would like to have investigated the issue as much as possible. We obviously don't want to put in the effort if it turns out it was something else. I've also spent some time looking through the Kernel change logs from 2.6.8 and could not find any explicit fixes for this type of error. > When you say it happens on "various brands", do you mean it happens on > every stick you've tried, or only on some? If the latter, is there a > pattern? We haven't been able to reproduce the problem in our lab, we've only seen the corruption in a few log files sent from various customers. We did manage to get two of the usb disks that had some corrupt log files back from customers (customers tend to use their own disks), but have failed so far to reproduce the problem on those returned disks. The following is further info for each of those returned disks: DISK1 --------- ~ #dmesg usb 1-1: new full speed USB device using address 2 scsi0 : SCSI emulation for USB Mass Storage devices Vendor: Model: USB Flash Memory Rev: PMAP Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 7827456 512-byte hdwr sectors (4008 MB) sda: assuming Write Enabled sda: assuming drive cache: write through sda: sda1 Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 USB Mass Storage device found at 2 ~ # lsusb Bus 001 Device 002: ID 0930:6545 Toshiba Corp. Bus 001 Device 001: ID 0000:0000 --------- DISK2 --------- ~ #dmesg usb 1-1: new full speed USB device using address 4 scsi2 : SCSI emulation for USB Mass Storage devices Vendor: Generic Model: Flash Disk Rev: 8.07 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 8122368 512-byte hdwr sectors (4159 MB) sda: assuming Write Enabled sda: assuming drive cache: write through sda: sda1 Attached scsi removable disk sda at scsi2, channel 0, id 0, lun 0 USB Mass Storage device found at 4 ~ # lsusb Bus 001 Device 004: ID 058f:6387 Alcor Micro Corp. Bus 001 Device 001: ID 0000:0000 ----------- > Just as a random thought, does it happen if you substitute some other > USB mass-storage device like a hard drive? That would tell you whether > the slow write problem of flash drives is relevant (though your data > rate doesn't sound excessive). As soon as we can reproduce the corruption in the lab this would be a good experiment. On 13 May 2011 19:56, Greg KH <greg@xxxxxxxxx> wrote: > On Fri, May 13, 2011 at 05:33:07PM +0100, Donal Morrissey wrote: >> Hi All, >> We are having a problem with corruption of files on usb sticks for an >> embedded platform running the 2.6.8.1 kernel on a Cirrus EP9302 Arm9 >> processor. > > As was asked already, do you really mean that kernel version? I know of > no such release, and I'm the one responsible for doing the .y kernel > releases :) I don't know the origin of the kernel, I'm guessing it originally came from Cirrus Logic, since our Kernel build process applies a set of Cirrus kernel patches. Our linux-2.6.8.1/include/linux/version.h file contains: #define UTS_RELEASE "2.6.8.1-crus2.0.8" #define LINUX_VERSION_CODE 132616 > > What host controller are you using? > The EP9302 processor has 2 "Integrated Multi-Port USB 2.0 Full Speed Hosts with Transceivers... Fully compliant to the OHCI USB 2.0 Full Speed specification (12 Mbps)". >> We run logging that logs directly to a text file on a FAT32 usb stick. >> This logging is continuous (20MB of data per hour) and includes log >> messages from our user space applications and the kernel Ring Buffer. >> On very rare occasions we have found blocks of corrupt data within the >> logs files. > > Can you run usbmon at the same time to verify that the correct data was > written to the device from the host? Or do you have a usb monitor you > can use on the wire to watch for this as well? > > thanks, > > greg k-h > I'll look into getting usbmon enabled on our target, cheers. On 13 May 2011 22:49, Richard Ash <richard@xxxxxxxxxxxxxxxx> wrote: > On Fri, 2011-05-13 at 11:56 -0700, Greg KH wrote: >> > We run logging that logs directly to a text file on a FAT32 usb stick. >> > This logging is continuous (20MB of data per hour) and includes log >> > messages from our user space applications and the kernel Ring Buffer. >> > On very rare occasions we have found blocks of corrupt data within the >> > logs files. > > This sounds a lot like issues I have had with a bad batch of USB sticks > (don't know what manufacturer as they are branded advertising stock) > whose wear levelling appears to go bad, resulting in all sorts of random > re-mappings of data into other files. > > Do your corrupt files read the same if you copy them off multiple times? > I found that ours didn't, which pointed fairly strongly at a > hardware-level issue. We've ran extensive tests on the two returned USB sticks (which you can see from above are different brands): scanning the disks for errors and continuously writing using dd and reading back the data to verify and not found any problems with the disks. Thinking about it we only ran this test from a Linux PC, not on our embedded platform. I'll run this next week. That's a good question re reading the files multiple times. It's too late with the two sticks that were returned, but something we will try if we can get some more back. This wouldn't be such a major issue (as the logs are only used for debug), but there are several cases where the log corruption appears a few seconds before the system locks-up (i.e. needs to be power cycled in order to recover), which may be a side effect or just a coincidence. Cheers, Donal -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
