Re: Help troubleshooting...
In message: <86aazecl00@ds4.des.no> Dag-Erling_Smørgrav writes: : "M. Warner Losh" writes: : > Yes. Of course I have local modifications, but none in the usb stack. : > But I've also done a svn update from the top of the tree multiple : > times and this version number persists. : : Weird. r185338 was a commit to the old USB stack. Try to run : svnversion in sys/dev/usb, and in an unrelated directory such as : sys/conf. If there's a difference, run svn stat in sys/dev/usb and see : if anything unexpected shows up. % cd sys/dev/usb % svnversion 198411M % cd ../../conf % svnversion 198411M Some more digging down this line shows that there was a dangling merge conflict in sys/i386/conf/GENERIC Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
On Monday 26 October 2009 14:37:59 M. Warner Losh wrote: > In message: <86skd6cmm8@ds4.des.no> > > Dag-Erling_Smørgrav writes: > : "M. Warner Losh" writes: > : > FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: > : > Fri Oct 23 10:08:48 MDT 2009 > : > i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64 > : > > : > so it would have r197682 baked in (the first number in my rev string > : > is a mystery to me). > : > : It means you have an inconsistent tree. The first number is the oldest > : revision in your tree, the second is the newest, and the M means you > : have local modifications. > > Yes. Of course I have local modifications, but none in the usb stack. > But I've also done a svn update from the top of the tree multiple > times and this version number persists. > > : > Re another post: This is a 8GB flash, so I'm sure that there's enough > : > power. > : > : Non sequitur. Bigger chips draw more power. Is it plugged directly > : into the computer? If not, is it plugged into a powered hub? How many > : other devices are connected to the computer or hub? > Hi, > Not entirely. This flash has worked in this computer in the past > without issues (like a year ago when we were first integrating hpsusb > into the tree). Since then there has been at least one patch to improve performance in the EHCI driver. When the cat command stops, could you try to run: usbconfig -u XXX -a YYY dump_device_desc dump_curr_config_desc On that device. Is usbconfig able to extract the string descriptors in the device and config descriptor? Or do you get timeouts? Also check vmstat -i . > This flash is plugged directly into the computer. > This behavior is consistent across multiple ports on the computer (so > it isn't a bad port). While this doesn't prove it isn't a power > issue, the odds are stacked against it being one. If there were a way > to get the internal hub to tell me how much power it can deliver, and > for me to query the flash to see maximum current draws, we could see > if we're close to the edge or not... Usually the maximum current is given by the device descriptor, but it might now be the actual value. See usbconfig dump_device_desc. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
"M. Warner Losh" writes: > Yes. Of course I have local modifications, but none in the usb stack. > But I've also done a svn update from the top of the tree multiple > times and this version number persists. Weird. r185338 was a commit to the old USB stack. Try to run svnversion in sys/dev/usb, and in an unrelated directory such as sys/conf. If there's a difference, run svn stat in sys/dev/usb and see if anything unexpected shows up. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
In message: <86skd6cmm8@ds4.des.no> Dag-Erling_Smørgrav writes: : "M. Warner Losh" writes: : > FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct 23 10:08:48 MDT 2009 i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64 : > : > so it would have r197682 baked in (the first number in my rev string : > is a mystery to me). : : It means you have an inconsistent tree. The first number is the oldest : revision in your tree, the second is the newest, and the M means you : have local modifications. Yes. Of course I have local modifications, but none in the usb stack. But I've also done a svn update from the top of the tree multiple times and this version number persists. : > Re another post: This is a 8GB flash, so I'm sure that there's enough : > power. : : Non sequitur. Bigger chips draw more power. Is it plugged directly : into the computer? If not, is it plugged into a powered hub? How many : other devices are connected to the computer or hub? Not entirely. This flash has worked in this computer in the past without issues (like a year ago when we were first integrating hpsusb into the tree). This flash is plugged directly into the computer. This behavior is consistent across multiple ports on the computer (so it isn't a bad port). While this doesn't prove it isn't a power issue, the odds are stacked against it being one. If there were a way to get the internal hub to tell me how much power it can deliver, and for me to query the flash to see maximum current draws, we could see if we're close to the edge or not... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
"M. Warner Losh" writes: > FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri > Oct 23 10:08:48 MDT 2009 > i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64 > > so it would have r197682 baked in (the first number in my rev string > is a mystery to me). It means you have an inconsistent tree. The first number is the oldest revision in your tree, the second is the newest, and the M means you have local modifications. > Re another post: This is a 8GB flash, so I'm sure that there's enough > power. Non sequitur. Bigger chips draw more power. Is it plugged directly into the computer? If not, is it plugged into a powered hub? How many other devices are connected to the computer or hub? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
On Monday 26 October 2009 14:01:17 M. Warner Losh wrote: > In message: <200910261258.08135.hsela...@c2i.net> > > Hans Petter Selasky writes: > : On Monday 26 October 2009 12:48:16 M. Warner Losh wrote: > : > I know that the august 25th version failed badly when I tried to burn > : > DVDs from a USB drive to a USB attached DVD burner. This used to work > : > flawlessly. > : > : Hi, > : > : There has been a recent fix to the EHCI driver, which might affect Mass > : Storage when short transfers are used. > : > : Also someone else has pointed out that certain VIA chipsets have an IRQ > : "bug" requiring the need for a software callout to restart the EHCI > : interrupt handler. This is not yet patched, hence I don't know if this is > : a real issue. > : > : http://svn.freebsd.org/viewvc/base?view=revision&revision=197682 > : > : Is your code from after 1st of October? > > This code is from: > > FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri > Oct 23 10:08:48 MDT 2009 > i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64 > > so it would have r197682 baked in (the first number in my rev string > is a mystery to me). > > Re another post: This is a 8GB flash, so I'm sure that there's enough > power. > > Looking at the dmesg, this happend the second or third time I'd > plugged in this flash drive. > > Here's a partial dmesg for usb things: > > CPU: AMD Turion(tm) 64 Mobile Technology ML-37 (1994.21-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x20f42 Stepping = 2 > > Features=0x78bfbff,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x1 > real memory = 2147483648 (2048 MB) > avail memory = 2059546624 (1964 MB) > ACPI APIC Table: > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-23 on motherboard > ... > pcib2: at device 5.0 on pci0 > pci2: on pcib2 > ohci0: mem 0xc000-0xcfff irq 19 at > device 19.0 on pci0 Activate PA 0xc000 at VA 0xff00c000 > ohci0: [ITHREAD] > usbus0: on ohci0 > ohci1: mem 0xc0001000-0xc0001fff irq 19 at > device 19.1 on pci0 Activate PA 0xc0001000 at VA 0xff00c0001000 > ohci1: [ITHREAD] > usbus1: on ohci1 > ehci0: mem 0xc0002000-0xc0002fff irq 19 at > device 19.2 on pci0 Activate PA 0xc0002000 at VA 0xff00c0002000 > ehci0: [ITHREAD] > usbus2: EHCI version 1.0 > usbus2: on ehci0 > ... > Timecounter "TSC" frequency 1994209008 Hz quality 800 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 480Mbps High Speed USB v2.0 > Status is 0x3106 > ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire > Activate i/o 0x8014 > Activate i/o 0x8015 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ad0: 114473MB at ata0-master UDMA100 > GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). > uhub0: 4 ports with 4 removable, self powered > uhub1: 4 ports with 4 removable, self powered > ... > Root mount waiting for: usbus2 > uhub2: 8 ports with 8 removable, self powered > Root mount waiting for: usbus2 > Trying to mount root from ufs:/dev/ad0s2a > ugen0.2: at usbus0 > ubt0: 2> on usbus0 usb_alloc_device:1635: getting device descriptor at addr 2 > failed, USB_ERR_TIMEOUT! ugen2.2: at usbus2 > umass0: on usbus2 > umass0: SCSI over Bulk-Only; quirks = 0x > umass0:2:0:-1: Attached to scbus2 > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have > changed (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C) > ugen2.2: at usbus2 (disconnected) > umass0: at uhub2, port 6, addr 2 (disconnected) > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): Invalidating pack > g_vfs_done():da0s1[READ(offset=5298202624, length=65536)]error = 6 > g_vfs_done():da0s1[READ(offset=5298268160, length=65536)]error = 6 > g_vfs_done():da0s1[READ(offset=5298333696, length=65536)]error = 6 > g_vfs_done():da0s1[WRITE(offset=1976320, length=32768)]error = 6 > g_vfs_done():da0s1[READ(offset=5298137088, length=65536)]error = 6 > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0xa, scsi > status == 0x0 (da0:umass-sim0:0:0:0): removing device entry > ugen2.2: at usbus2 > can't re-use a leaf (%desc)! > can't re-use a leaf (%driver)! > can't re-use a leaf (%location)! > can't re-use a leaf (%pnpinfo)! > can't re-use a leaf (%parent)! > umass0: on usbus2 > umass0: SCSI over Bulk-Only; quirks = 0x > umass0:2:0:-1: Attached to
Re: Help troubleshooting...
In message: <200910261258.08135.hsela...@c2i.net> Hans Petter Selasky writes: : On Monday 26 October 2009 12:48:16 M. Warner Losh wrote: : > I know that the august 25th version failed badly when I tried to burn : > DVDs from a USB drive to a USB attached DVD burner. This used to work : > flawlessly. : : Hi, : : There has been a recent fix to the EHCI driver, which might affect Mass : Storage when short transfers are used. : : Also someone else has pointed out that certain VIA chipsets have an IRQ "bug" : requiring the need for a software callout to restart the EHCI interrupt : handler. This is not yet patched, hence I don't know if this is a real issue. : : http://svn.freebsd.org/viewvc/base?view=revision&revision=197682 : : Is your code from after 1st of October? This code is from: FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct 23 10:08:48 MDT 2009 i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64 so it would have r197682 baked in (the first number in my rev string is a mystery to me). Re another post: This is a 8GB flash, so I'm sure that there's enough power. Looking at the dmesg, this happend the second or third time I'd plugged in this flash drive. Here's a partial dmesg for usb things: CPU: AMD Turion(tm) 64 Mobile Technology ML-37 (1994.21-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f42 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 real memory = 2147483648 (2048 MB) avail memory = 2059546624 (1964 MB) ACPI APIC Table: MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard ... pcib2: at device 5.0 on pci0 pci2: on pcib2 ohci0: mem 0xc000-0xcfff irq 19 at device 19.0 on pci0 Activate PA 0xc000 at VA 0xff00c000 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xc0001000-0xc0001fff irq 19 at device 19.1 on pci0 Activate PA 0xc0001000 at VA 0xff00c0001000 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xc0002000-0xc0002fff irq 19 at device 19.2 on pci0 Activate PA 0xc0002000 at VA 0xff00c0002000 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ... Timecounter "TSC" frequency 1994209008 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 Status is 0x3106 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire Activate i/o 0x8014 Activate i/o 0x8015 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ad0: 114473MB at ata0-master UDMA100 GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). uhub0: 4 ports with 4 removable, self powered uhub1: 4 ports with 4 removable, self powered ... Root mount waiting for: usbus2 uhub2: 8 ports with 8 removable, self powered Root mount waiting for: usbus2 Trying to mount root from ufs:/dev/ad0s2a ugen0.2: at usbus0 ubt0: on usbus0 usb_alloc_device:1635: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x umass0:2:0:-1: Attached to scbus2 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C) ugen2.2: at usbus2 (disconnected) umass0: at uhub2, port 6, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): Invalidating pack g_vfs_done():da0s1[READ(offset=5298202624, length=65536)]error = 6 g_vfs_done():da0s1[READ(offset=5298268160, length=65536)]error = 6 g_vfs_done():da0s1[READ(offset=5298333696, length=65536)]error = 6 g_vfs_done():da0s1[WRITE(offset=1976320, length=32768)]error = 6 g_vfs_done():da0s1[READ(offset=5298137088, length=65536)]error = 6 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0xa, scsi status == 0x0 (da0:umass-sim0:0:0:0): removing device entry ugen2.2: at usbus2 can't re-use a leaf (%desc)! can't re-use a leaf (%driver)! can't re-use a leaf (%location)! can't re-use a leaf (%pnpinfo)! can't re-use a leaf (%parent)! umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x umass0:2:0:-1: Attached to scbus2 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C) ugen2.2: at usbus2 (disconnected) umass0: at uhub2, port 6, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): remov
Re: Help troubleshooting...
On Monday 26 October 2009 12:48:16 M. Warner Losh wrote: > In message: <200910260959.20772.hsela...@c2i.net> > > Hans Petter Selasky writes: > : On Monday 26 October 2009 01:05:03 n...@ever.sanda.gr.jp wrote: > : > M. Warner Losh wrote: > : > > I have a usb stick (8GB) on it. This stick has about 5GB of junk on > : > > it at this point. > : > > > : > > I tried to do 'cat * > /dev/null' recently, to measure how fast it > : > > goes. It got about 1GB into the drive and then I got device missing > : > > messages. > : > > > : > > So devfs thinks the device went missing: > : > > : > Warner-san, maybe it is caused by the hardware problem on the USB flash > : > memory. Some chip on the memory might have too much heat when you > : > access the memory at fast rate. Then it stops working. > : > : What happens if you read from two USB disks at the same time? > > I know that the august 25th version failed badly when I tried to burn > DVDs from a USB drive to a USB attached DVD burner. This used to work > flawlessly. > > : If the device went missing the USB HUB signalled that. This is maybe an > : indication that the USB firmware on the device crashed. Maybe this is due > : to heat, or unhandled race conditions when the load goes high. > > This same flash drive will do 20MB sustained on windows without a > glitch using similar commands. > > : Try using "dd" and vary the block size from 512 to 65536 bytes. Does it > : stop working with all block sizes over time? > > Once I get the message I posted, it is lights out for da0. No further > access to the drive works at all. > Make sure your driver has got sufficiently enough power, if powered over USB. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
On Monday 26 October 2009 12:48:16 M. Warner Losh wrote: > I know that the august 25th version failed badly when I tried to burn > DVDs from a USB drive to a USB attached DVD burner. This used to work > flawlessly. Hi, There has been a recent fix to the EHCI driver, which might affect Mass Storage when short transfers are used. Also someone else has pointed out that certain VIA chipsets have an IRQ "bug" requiring the need for a software callout to restart the EHCI interrupt handler. This is not yet patched, hence I don't know if this is a real issue. http://svn.freebsd.org/viewvc/base?view=revision&revision=197682 Is your code from after 1st of October? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
In message: <200910260959.20772.hsela...@c2i.net> Hans Petter Selasky writes: : On Monday 26 October 2009 01:05:03 n...@ever.sanda.gr.jp wrote: : > M. Warner Losh wrote: : > > I have a usb stick (8GB) on it. This stick has about 5GB of junk on : > > it at this point. : > > : > > I tried to do 'cat * > /dev/null' recently, to measure how fast it : > > goes. It got about 1GB into the drive and then I got device missing : > > messages. : > > : > > So devfs thinks the device went missing: : > : > Warner-san, maybe it is caused by the hardware problem on the USB flash : > memory. Some chip on the memory might have too much heat when you access : > the memory at fast rate. Then it stops working. : > : : What happens if you read from two USB disks at the same time? I know that the august 25th version failed badly when I tried to burn DVDs from a USB drive to a USB attached DVD burner. This used to work flawlessly. : If the device went missing the USB HUB signalled that. This is maybe an : indication that the USB firmware on the device crashed. Maybe this is due to : heat, or unhandled race conditions when the load goes high. This same flash drive will do 20MB sustained on windows without a glitch using similar commands. : Try using "dd" and vary the block size from 512 to 65536 bytes. Does it stop : working with all block sizes over time? Once I get the message I posted, it is lights out for da0. No further access to the drive works at all. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
But there was no indication the device went missing on the console. And it wasn't until I unplugged it that da0 detached. Usually in the past when it has started throwing errors the console was chatty about why. Warner On Oct 26, 2009, at 2:59 AM, Hans Petter Selasky wrote: On Monday 26 October 2009 01:05:03 n...@ever.sanda.gr.jp wrote: M. Warner Losh wrote: I have a usb stick (8GB) on it. This stick has about 5GB of junk on it at this point. I tried to do 'cat * > /dev/null' recently, to measure how fast it goes. It got about 1GB into the drive and then I got device missing messages. So devfs thinks the device went missing: Warner-san, maybe it is caused by the hardware problem on the USB flash memory. Some chip on the memory might have too much heat when you access the memory at fast rate. Then it stops working. What happens if you read from two USB disks at the same time? If the device went missing the USB HUB signalled that. This is maybe an indication that the USB firmware on the device crashed. Maybe this is due to heat, or unhandled race conditions when the load goes high. Try using "dd" and vary the block size from 512 to 65536 bytes. Does it stop working with all block sizes over time? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
On Monday 26 October 2009 01:05:03 n...@ever.sanda.gr.jp wrote: > M. Warner Losh wrote: > > I have a usb stick (8GB) on it. This stick has about 5GB of junk on > > it at this point. > > > > I tried to do 'cat * > /dev/null' recently, to measure how fast it > > goes. It got about 1GB into the drive and then I got device missing > > messages. > > > > So devfs thinks the device went missing: > > Warner-san, maybe it is caused by the hardware problem on the USB flash > memory. Some chip on the memory might have too much heat when you access > the memory at fast rate. Then it stops working. > What happens if you read from two USB disks at the same time? If the device went missing the USB HUB signalled that. This is maybe an indication that the USB firmware on the device crashed. Maybe this is due to heat, or unhandled race conditions when the load goes high. Try using "dd" and vary the block size from 512 to 65536 bytes. Does it stop working with all block sizes over time? --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
M. Warner Losh wrote: I have a usb stick (8GB) on it. This stick has about 5GB of junk on it at this point. I tried to do 'cat * > /dev/null' recently, to measure how fast it goes. It got about 1GB into the drive and then I got device missing messages. : So devfs thinks the device went missing: Warner-san, maybe it is caused by the hardware problem on the USB flash memory. Some chip on the memory might have too much heat when you access the memory at fast rate. Then it stops working. // Noriaki Mitsunaga ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help troubleshooting...
On Sun, Oct 25, 2009 at 01:34:37PM -0600, M. Warner Losh wrote:
> I have a usb stick (8GB) on it. This stick has about 5GB of junk on
> it at this point.
>
> I tried to do 'cat * > /dev/null' recently, to measure how fast it
> goes. It got about 1GB into the drive and then I got device missing
> messages.
>
> Here's the dmesg messages:
>
> # Plug it in
> da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
> da0: Removable Direct Access SCSI-0 device
> da0: 40.000MB/s transfers
> da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
> # mount it, etc
> # run the cat command
> Device da0s1 went missing before all of the data could be written to it;
> expect data loss.
> # get error messages
> # Remove the drive
> ugen2.2: at usbus2 (disconnected)
> umass0: at uhub2, port 1, addr 2 (disconnected)
> (da0:umass-sim0:0:0:0): lost device
> (da0:umass-sim0:0:0:0): removing device entry
>
> So devfs thinks the device went missing:
>
> static int
> devfs_fsync(struct vop_fsync_args *ap)
> {
> ...
> if (!vn_isdisk(ap->a_vp, &error)) {
> bo = &ap->a_vp->v_bufobj;
> de = ap->a_vp->v_data;
> if (error == ENXIO && bo->bo_dirty.bv_cnt > 0) {
> printf("Device %s went missing before all of the data "
> "could be written to it; expect data loss.\n",
> de->de_dirent->d_name);
> ...
>
> So it thinks that it isn't a disk. vn_isdisk is return ENXIO because
> either vp->v_rdev == NULL or the v_rdev->si_devsw == NULL.
si_devsw is cleared in kern_conf.c:destroy_devl, line 835.
I think USB subsystem called either destroy_dev() or destroy_dev_sched().
>
> So how the heck can that happen without other warnings? It appears
> the only place it is set like this is in devfs_reclaim. But I'm
> having trouble tracking down where *THAT* is called.
Reclaim might be called if devfs mount point is forcibly unmounted
special vnode from which you used to mount pendrive.
>
> This is with the following system:
>
> FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri
> Oct 23 10:08:48 MDT 2009
> i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64
>
> Warner
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
pgpMv9RPezLji.pgp
Description: PGP signature
Help troubleshooting...
I have a usb stick (8GB) on it. This stick has about 5GB of junk on
it at this point.
I tried to do 'cat * > /dev/null' recently, to measure how fast it
goes. It got about 1GB into the drive and then I got device missing
messages.
Here's the dmesg messages:
# Plug it in
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0: Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
# mount it, etc
# run the cat command
Device da0s1 went missing before all of the data could be written to it; expect
data loss.
# get error messages
# Remove the drive
ugen2.2: at usbus2 (disconnected)
umass0: at uhub2, port 1, addr 2 (disconnected)
(da0:umass-sim0:0:0:0): lost device
(da0:umass-sim0:0:0:0): removing device entry
So devfs thinks the device went missing:
static int
devfs_fsync(struct vop_fsync_args *ap)
{
...
if (!vn_isdisk(ap->a_vp, &error)) {
bo = &ap->a_vp->v_bufobj;
de = ap->a_vp->v_data;
if (error == ENXIO && bo->bo_dirty.bv_cnt > 0) {
printf("Device %s went missing before all of the data "
"could be written to it; expect data loss.\n",
de->de_dirent->d_name);
...
So it thinks that it isn't a disk. vn_isdisk is return ENXIO because
either vp->v_rdev == NULL or the v_rdev->si_devsw == NULL.
So how the heck can that happen without other warnings? It appears
the only place it is set like this is in devfs_reclaim. But I'm
having trouble tracking down where *THAT* is called.
This is with the following system:
FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct
23 10:08:48 MDT 2009
i...@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE amd64
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
