Re: uhub_reattach_port:413: could not allocate new device!

On Friday 30 January 2009, Chris Ruiz wrote:
> On Jan 30, 2009, at 3:44 AM, Hans Petter Selasky wrote:
> > On Friday 30 January 2009, Chris Ruiz wrote:
> >> Jan 29 19:34:39 attack kernel: usb2_pc_common_mem_cb:429: Page offset
> >> was not preserved!
> >
> > Hi,
> >
> > First of all thanks for reporting!
> >
> > The issue you are experiencing is a known problem with busdma,
> > because you are
> > using a 64-bit platform.
> >
> > See "http://wiki.freebsd.org/USB" for a resolution.
>
> I manually applied the changes to r187913 by hand (I don't know how to
> generate patches from p4) and have successfully tested them.
>
> --
>
> new kernel:
>
> FreeBSD attack.young-alumni.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0
> r187913M: Fri Jan 30 05:35:09 CST 2009     root_at_attack.young-
> alumni.com:/usr/obj/usr/src/sys/FAILWHALE  amd64
>
> device messages:
>
> Jan 30 06:04:43 attack kernel: ugen3.3: <LG Electronics> at usbus3
> Jan 30 06:04:43 attack kernel: umass1: <LG Electronics USB Drive,
> class 0/0, rev
>   2.00/11.00, addr 3> on usbus3
> Jan 30 06:04:43 attack kernel: umass1:  SCSI over Bulk-Only; quirks =
> 0x0000
> Jan 30 06:04:44 attack kernel: umass1:2:1:-1: Attached to scbus2
> Jan 30 06:04:44 attack kernel: (probe0:umass-sim1:1:0:0): TEST UNIT
> READY. CDB: 0 0 0 0 0 0
> Jan 30 06:04:44 attack kernel: (probe0:umass-sim1:1:0:0): CAM Status:
> SCSI Status Error
> Jan 30 06:04:44 attack kernel: (probe0:umass-sim1:1:0:0): SCSI Status:
> Check Condition
> Jan 30 06:04:44 attack kernel: (probe0:umass-sim1:1:0:0): UNIT
> ATTENTION asc:28,0
> Jan 30 06:04:44 attack kernel: (probe0:umass-sim1:1:0:0): Not ready to
> ready change, medium may have changed
> Jan 30 06:04:44 attack kernel: (probe0:umass-sim1:1:0:0): Retrying
> Command (per Sense Data)
> Jan 30 06:04:44 attack kernel: da1 at umass-sim1 bus 1 target 0 lun 0
> Jan 30 06:04:44 attack kernel: da1: <LG USB Drive 1100> Removable
> Direct Access SCSI-0 device
> Jan 30 06:04:44 attack kernel: da1: 40.000MB/s transfers
> Jan 30 06:04:44 attack kernel: da1: 7743MB (15858688 512 byte sectors:
> 255H 63S/T 987C)
> Jan 30 06:04:45 attack kernel: GEOM_LABEL: Label for provider da1p1 is
> msdosfs/EFI.
> Jan 30 06:04:50 attack kernel: umass1: at ushub3, port 4, addr 3
> (disconnected)
> Jan 30 06:04:50 attack kernel: (da1:umass-sim1:1:0:0): lost device
> Jan 30 06:04:50 attack kernel: (da1:umass-sim1:1:0:0): removing device
> entry
> Jan 30 06:04:50 attack kernel: ugen3.3: <LG Electronics> at usbus3
> (disconnected)
> Jan 30 06:04:50 attack kernel: GEOM_LABEL: Label msdosfs/EFI removed.
>
> Jan 30 06:05:01 attack kernel: ugen3.4: <SanDisk Corporation> at usbus3
> Jan 30 06:05:01 attack kernel: umass2: <SanDisk Corporation Cruzer
> Mini, class 0/0, rev 2.00/0.20, addr 4> on usbus3
> Jan 30 06:05:01 attack kernel: umass2:  SCSI over Bulk-Only; quirks =
> 0x0000
> Jan 30 06:05:03 attack kernel: umass2:3:2:-1: Attached to scbus3
> Jan 30 06:05:03 attack kernel: da2 at umass-sim2 bus 2 target 0 lun 0
> Jan 30 06:05:03 attack kernel: da2: <SanDisk Cruzer Mini 0.2>
> Removable Direct Access SCSI-2 device
> Jan 30 06:05:03 attack kernel: da2: 40.000MB/s transfers
> Jan 30 06:05:03 attack kernel: da2: 122MB (250879 512 byte sectors:
> 64H 32S/T 122C)
> Jan 30 06:05:03 attack kernel: GEOM_LABEL: Label for provider da2s1a
> is ufs/usbboot.
> Jan 30 06:05:07 attack kernel: umass2: at ushub3, port 4, addr 4
> (disconnected)
> Jan 30 06:05:07 attack kernel: (da2:umass-sim2:2:0:0): lost device
> Jan 30 06:05:07 attack kernel: (da2:umass-sim2:2:0:0): removing device
> entry
> Jan 30 06:05:07 attack kernel: ugen3.4: <SanDisk Corporation> at
> usbus3 (disconnected)
> Jan 30 06:05:07 attack kernel: GEOM_LABEL: Label ufs/usbboot removed.
>
> --
>
> I'll keep testing throughout the day to make sure there aren't any
> gremlins lurking about.  Can this be committed soon if no problems
> come up?

Hi,

I think Warner M. Losh and Scott Long is working on this. Please sync with 
them. There has been a long off-list discussion going through all aspects of 
this patch.

--HPS