usb/110855: ugen: interrupt in msgs are truncated when buffer is full

Hans Petter Selasky hselasky at c2i.net
Wed Mar 28 16:32:44 UTC 2007


On Wednesday 28 March 2007 17:43, Markus Henschel wrote:
> Hans Petter Selasky schrieb:
> > On Wednesday 28 March 2007 11:41, Markus Henschel wrote:
> >> Hans Petter Selasky schrieb:
> >>> The following reply was made to PR usb/110855; it has been noted by
> >>> GNATS.
> >>
> >> Hi,
> >
> > Could you edit /sys/dev/usb/umass.c
> >
> > Then lookup:
> >
> > usbd_delay_ms(uaa->device, 1000);
> >
> > Change it into:
> >
> > usbd_delay_ms(uaa->device, 5000);
> >
> > Then lookup in the function "umass_attach()":
> >
> > sc->sc_last_xfer_index = UMASS_T_BBB_COMMAND;
> >
> > and change it into:
> >
> > sc->sc_last_xfer_index = UMASS_T_BBB_RESET2;
> >
> > Compile a new kernel and see what happens when you plug the stick again.
> >
> > --HPS
>
> Hello again,
>
> the 1st stick is working now ("JetFlash Mass Storage Device") but the
> other stick that worked fine before ("LG USB DRIVE) has problems being
> detected now. The "main" device node /dev/da0 is created but not the
> node for the 1st partition /dev/da0s1, even after minutes. But when I
> try to mount /dev/da0 directly (which doesn't make sense) the command
> fails but suddenly /dev/da0s1 appears and is usable. Should I try to
>

This dmesg looks like it is from the old umass driver?

> decrease the delay again? Here is the dmesg output:
> > umass0: SCSI over Bulk-Only; quirks = 0x0000
> > umass0: Max Lun is 0
> > umass0:0:-1:-1:XPT_PATH_INQ:.
> > umass0:0:0:-1: Attached to scbus0
> > umass0: Attach finished
> > scbus0: scanning for umass0:0:0:-1
> > umass0:0:-1:-1:XPT_PATH_INQ:.
> > umass0:0:0:0:XPT_PATH_INQ:.
> > umass0:0:0:0:XPT_PATH_INQ:.
> > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b

<ZAP>

Can you revert the changes you made to "umass.c" ?

You can do this for example by copying "sys/dev/usb/umass.c" from the SVN repo 
to where you have your kernel sources.

Then edit "sys/dev/usb/umass.c" again.

Lookup the function "umass_t_bbb_status_callback()".

Right below the label "tr_transferred" you add like this:

tr_transferred:
	/* don't retry the status, but do a full reset if 
	 * there is something wrong with the CSW:
	 */
	sc->sc_status_try = 1; 

Compile a new kernel (or if you are smart, leave "device umass" out of the 
kernel config file and just recompile the "umass" module: sys/modules/umass)

What happens now?

--HPS


More information about the freebsd-usb mailing list