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