minimum_cmd_size is only used for read_write commands, not for others like MODE_SENSE_6 and friends.
Nick > > As in, try a 6 byte command, and if that fails try a 10 byte command > > instead? > > As in, if it fails to reset, then > > sc->softc->minimum_cmd_size = 10; > printf( "auto-quirking mumble foo\n"); > > It would let most of the existing quirks table go away, but > would require additional retries. The cool thing is that it > would all happen in the error path, so, other than increasing > the number of retries to cause it to engage by itself without > having to try the disklabel 3 times, which is also failure > mode stuff, it adds no overhead to working devices, and makes > non-working ones work with the overhead they have to have > anyway. > > > > Unfortunately although I'm maintaining USB in -current, I don't have a > > complete in depth understanding of the code yet. :( I'm mainly trying > > to fix my problems by taking from NetBSD. > > I took a look at the code. I have to say it's opaque. It > makes a better door than a window. ;-). > > I haven't figured out how to turn a struct umass_softc * into > a struct da_softc *, or I would have given you an ugly little > patch against an older version of FreeBSD to try. 8-p. > > I think someone with one of these things, or with a quirky > one with the DA_Q_NO_6_BYTE removed from the quirks table, > is going to have to set CAM_DEBUG on big-time, and then > see where the reset error falls out, add a static fail > counter to that place in the code, and then if it fails > and the fail counter >= 3 (for example), reset the minimum > command size to 10. > > That should "just work". > > If the reset is retried enough times, you could get rid of > the quirks entries that existed solely for this quirk; I > think that a > > 6 byte commands not supported: changing to 10 byte commands > > message on the console is probably acceptable "noise" in > trade for getting rid of it, and supporting future devices > with the same problem, without needing to "quirk" them. > > I think DA_Q_NO_SYNC_CACHE might be handleable the same > way, which would get rid of all the quirk entries, and > maybe the need for a quirk table at all (it looks like > the daclose/dadump/dashutdown sync code could be static'ed > and shared, as well). > > Maybe this is a CAM-specific thing, and shouldn't be > handled in the USB code at all (you won't know until > you see a quirked device failure with the CAM debug, or > you write the CAM code to tape and run it through your > dental fillings or otherwise load it into your head). > > -- Terry > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hardware" in the body of the message > -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED] http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
