Date: Wed, 28 Mar 2007 18:32:22 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Markus Henschel <m.henschel@bally-wulff.de> Cc: freebsd-usb@freebsd.org Subject: Re: usb/110855: ugen: interrupt in msgs are truncated when buffer is full Message-ID: <200703281832.22527.hselasky@c2i.net> In-Reply-To: <460A8D1C.7090604@bally-wulff.de> References: <200703271940.l2RJe90x058558@freefall.freebsd.org> <200703281628.30878.hselasky@c2i.net> <460A8D1C.7090604@bally-wulff.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703281832.22527.hselasky>