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