Help troubleshooting...

[M. Warner Losh]

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: <HP v125w PMAP> 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: <HP> 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     imp@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE  amd64

Warner
_______________________________________________
freebsd-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[Kostik Belousov]

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: <HP v125w PMAP> 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: <HP> 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     imp@lighthouse:/cache/svn/head/sys/amd64/compile/LIGHTHOUSE  amd64
>
> Warner
> _______________________________________________
> freebsd-hackers@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[non-2]

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-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[Hans Petter Selasky]

On Monday 26 October 2009 01:05:03 non@... 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-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[M. Warner Losh]

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 <hselasky@...>  
wrote:

> On Monday 26 October 2009 01:05:03 non@... 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-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[M. Warner Losh]

In message: <200910260959.20772.hselasky@...>
            Hans Petter Selasky <hselasky@...> writes:
: On Monday 26 October 2009 01:05:03 non@... 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-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[Hans Petter Selasky]

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-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[Hans Petter Selasky]

On Monday 26 October 2009 12:48:16 M. Warner Losh wrote:

> In message: <200910260959.20772.hselasky@...>
>
>             Hans Petter Selasky <hselasky@...> writes:
> : On Monday 26 October 2009 01:05:03 non@... 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-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[M. Warner Losh]

In message: <200910261258.08135.hselasky@...>
            Hans Petter Selasky <hselasky@...> 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     imp@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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2>
  Features2=0x1<SSE3>
  AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
  AMD Features2=0x1<LAHF>
real memory  = 2147483648 (2048 MB)
avail memory = 2059546624 (1964 MB)
ACPI APIC Table: <PTLTD   APIC  >
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0 <Version 2.1> irqs 0-23 on motherboard
...
pcib2: <ACPI PCI-PCI bridge> at device 5.0 on pci0
pci2: <ACPI PCI bus> on pcib2
ohci0: <ATI SB400 USB Controller> mem 0xc0000000-0xc0000fff irq 19 at device 19.0 on pci0
Activate PA 0xc0000000 at VA 0xffffff00c0000000
ohci0: [ITHREAD]
usbus0: <ATI SB400 USB Controller> on ohci0
ohci1: <ATI SB400 USB Controller> mem 0xc0001000-0xc0001fff irq 19 at device 19.1 on pci0
Activate PA 0xc0001000 at VA 0xffffff00c0001000
ohci1: [ITHREAD]
usbus1: <ATI SB400 USB Controller> on ohci1
ehci0: <ATI SB400 USB 2.0 controller> mem 0xc0002000-0xc0002fff irq 19 at device 19.2 on pci0
Activate PA 0xc0002000 at VA 0xffffff00c0002000
ehci0: [ITHREAD]
usbus2: EHCI version 1.0
usbus2: <ATI SB400 USB 2.0 controller> 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 0x30000106
ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire
Activate i/o 0x8014
Activate i/o 0x8015
ugen0.1: <ATI> at usbus0
uhub0: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <ATI> at usbus1
uhub1: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
ugen2.1: <ATI> at usbus2
uhub2: <ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
ad0: 114473MB <FUJITSU MHV2120AT PL 008300A1> 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: <Broadcom Corp> at usbus0
ubt0: <Broadcom Corp HP Integrated Module, class 224/1, rev 2.00/1.00, addr 2> on usbus0
usb_alloc_device:1635: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT!
ugen2.2: <HP> at usbus2
umass0: <HP v125w, class 0/0, rev 2.00/1.10, addr 2> on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x0000
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: <HP v125w PMAP> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
ugen2.2: <HP> 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: <HP> 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: <HP v125w, class 0/0, rev 2.00/1.10, addr 2> on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass0:2:0:-1: Attached to scbus2
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0: <HP v125w PMAP> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
ugen2.2: <HP> 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): removing device entry
ugen2.2: <HP> 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: <HP v125w, class 0/0, rev 2.00/1.10, addr 2> on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x0000
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: <HP v125w PMAP> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
ugen1.2: <HTC> at usbus1
ugen2.2: <HP> 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): Invalidating pack
g_vfs_done():da0s1[READ(offset=634398720, length=65536)]error = 6
g_vfs_done():da0s1[READ(offset=634464256, length=65536)]error = 6
g_vfs_done():da0s1[READ(offset=634529792, length=65536)]error = 6
g_vfs_done():da0s1[WRITE(offset=1976320, length=32768)]error = 6
g_vfs_done():da0s1[READ(offset=634333184, 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: <HP> 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: <HP v125w, class 0/0, rev 2.00/1.10, addr 2> on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass0:2:0:-1: Attached to scbus2
da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
da0: <HP v125w PMAP> Removable Direct Access SCSI-0 device
da0: 40.000MB/s transfers
da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
Device da0s1 went missing before all of the data could be written to it; expect data loss.
ugen2.2: <HP> 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
pcm0: <ATI IXP 400> mem 0xc0003400-0xc00034ff irq 17 at device 20.5 on pci0
Activate PA 0xc0003400 at VA 0xffffff00c0003400
pcm0: [ITHREAD]
pcm0: <Conexant CX20468-21 AC97 Codec>
ugen1.2: <HTC> at usbus1 (disconnected)
ugen1.2: <HTC> at usbus1
ugen1.2: <HTC> at usbus1 (disconnected)




_______________________________________________
freebsd-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[Hans Petter Selasky]

On Monday 26 October 2009 14:01:17 M. Warner Losh wrote:

> In message: <200910261258.08135.hselasky@...>
>
>             Hans Petter Selasky <hselasky@...> 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    
> imp@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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA
>,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> Features2=0x1<SSE3>
>   AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
>   AMD Features2=0x1<LAHF>
> real memory  = 2147483648 (2048 MB)
> avail memory = 2059546624 (1964 MB)
> ACPI APIC Table: <PTLTD   APIC  >
> MADT: Forcing active-low polarity and level trigger for SCI
> ioapic0 <Version 2.1> irqs 0-23 on motherboard
> ...
> pcib2: <ACPI PCI-PCI bridge> at device 5.0 on pci0
> pci2: <ACPI PCI bus> on pcib2
> ohci0: <ATI SB400 USB Controller> mem 0xc0000000-0xc0000fff irq 19 at
> device 19.0 on pci0 Activate PA 0xc0000000 at VA 0xffffff00c0000000
> ohci0: [ITHREAD]
> usbus0: <ATI SB400 USB Controller> on ohci0
> ohci1: <ATI SB400 USB Controller> mem 0xc0001000-0xc0001fff irq 19 at
> device 19.1 on pci0 Activate PA 0xc0001000 at VA 0xffffff00c0001000
> ohci1: [ITHREAD]
> usbus1: <ATI SB400 USB Controller> on ohci1
> ehci0: <ATI SB400 USB 2.0 controller> mem 0xc0002000-0xc0002fff irq 19 at
> device 19.2 on pci0 Activate PA 0xc0002000 at VA 0xffffff00c0002000
> ehci0: [ITHREAD]
> usbus2: EHCI version 1.0
> usbus2: <ATI SB400 USB 2.0 controller> 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 0x30000106
> ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire
> Activate i/o 0x8014
> Activate i/o 0x8015
> ugen0.1: <ATI> at usbus0
> uhub0: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
> ugen1.1: <ATI> at usbus1
> uhub1: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
> ugen2.1: <ATI> at usbus2
> uhub2: <ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
> ad0: 114473MB <FUJITSU MHV2120AT PL 008300A1> 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: <Broadcom Corp> at usbus0
> ubt0: <Broadcom Corp HP Integrated Module, class 224/1, rev 2.00/1.00, addr
> 2> on usbus0 usb_alloc_device:1635: getting device descriptor at addr 2
> failed, USB_ERR_TIMEOUT! ugen2.2: <HP> at usbus2
> umass0: <HP v125w, class 0/0, rev 2.00/1.10, addr 2> on usbus2
> umass0:  SCSI over Bulk-Only; quirks = 0x0000
> 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: <HP v125w PMAP> Removable Direct Access SCSI-0 device
> da0: 40.000MB/s transfers
> da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
> ugen2.2: <HP> 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: <HP> 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: <HP v125w, class 0/0, rev 2.00/1.10, addr 2> on usbus2
> umass0:  SCSI over Bulk-Only; quirks = 0x0000
> umass0:2:0:-1: Attached to scbus2
> da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
> da0: <HP v125w PMAP> Removable Direct Access SCSI-0 device
> da0: 40.000MB/s transfers
> da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
> ugen2.2: <HP> 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): removing device entry
> ugen2.2: <HP> 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: <HP v125w, class 0/0, rev 2.00/1.10, addr 2> on usbus2
> umass0:  SCSI over Bulk-Only; quirks = 0x0000
> 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: <HP v125w PMAP> Removable Direct Access SCSI-0 device
> da0: 40.000MB/s transfers
> da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
> ugen1.2: <HTC> at usbus1
> ugen2.2: <HP> 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): Invalidating pack
> g_vfs_done():da0s1[READ(offset=634398720, length=65536)]error = 6
> g_vfs_done():da0s1[READ(offset=634464256, length=65536)]error = 6
> g_vfs_done():da0s1[READ(offset=634529792, length=65536)]error = 6
> g_vfs_done():da0s1[WRITE(offset=1976320, length=32768)]error = 6
> g_vfs_done():da0s1[READ(offset=634333184, 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: <HP> 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: <HP v125w, class 0/0, rev 2.00/1.10, addr 2> on usbus2
> umass0:  SCSI over Bulk-Only; quirks = 0x0000
> umass0:2:0:-1: Attached to scbus2
> da0 at umass-sim0 bus 0 scbus2 target 0 lun 0
> da0: <HP v125w PMAP> Removable Direct Access SCSI-0 device
> da0: 40.000MB/s transfers
> da0: 7660MB (15687680 512 byte sectors: 255H 63S/T 976C)
> Device da0s1 went missing before all of the data could be written to it;
> expect data loss. ugen2.2: <HP> 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
> pcm0: <ATI IXP 400> mem 0xc0003400-0xc00034ff irq 17 at device 20.5 on pci0
> Activate PA 0xc0003400 at VA 0xffffff00c0003400
> pcm0: [ITHREAD]
> pcm0: <Conexant CX20468-21 AC97 Codec>
> ugen1.2: <HTC> at usbus1 (disconnected)
> ugen1.2: <HTC> at usbus1
> ugen1.2: <HTC> at usbus1 (disconnected)

Hi,

Just an experiment:

usbconfig -u 2 -a 2 suspend

Then try to access the device. Any difference?

--HPS
_______________________________________________
freebsd-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[Dag-Erling Smørgrav]

"M. Warner Losh" <imp@...> writes:
> FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct 23 10:08:48 MDT 2009     imp@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 - des@...
_______________________________________________
freebsd-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[M. Warner Losh]

In message: <86skd6cmm8.fsf@...>
            Dag-Erling_Smørgrav <des@...> writes:
: "M. Warner Losh" <imp@...> writes:
: > FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M: Fri Oct 23 10:08:48 MDT 2009     imp@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-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[Dag-Erling Smørgrav]

"M. Warner Losh" <imp@...> 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 - des@...
_______________________________________________
freebsd-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[Hans Petter Selasky]

On Monday 26 October 2009 14:37:59 M. Warner Losh wrote:

> In message: <86skd6cmm8.fsf@...>
>
>             Dag-Erling_Smørgrav <des@...> writes:
> : "M. Warner Losh" <imp@...> writes:
> : > FreeBSD lighthouse 9.0-CURRENT FreeBSD 9.0-CURRENT #41 r185338:198411M:
> : > Fri Oct 23 10:08:48 MDT 2009    
> : > imp@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-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."

[M. Warner Losh]

In message: <86aazecl00.fsf@...>
            Dag-Erling_Smørgrav <des@...> writes:
: "M. Warner Losh" <imp@...> 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-usb@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscribe@..."