some USB devices. (Make sure to set xfer data length when we force
a short inquiry.)
Obtained from: NetBSD(sys/dev/usb/umass_scsipi.c rev.1.8)
Original idea from: Shingo WATANABE <nabe@nabechan.org>
descriptor request, which usbd_get_string_desc() uses to get the
length of a descriptor. One device for instance returns a full 8
byte long packet instead which confuses the rest of the stack and
leads to the USB port being reset. The fix is to instead request
two bytes, but not to complain if we only get one.
Submitted by: kan
MFC after: 3 days
Metricom Ricochet GS modem. Add them here.
# A new umodem appears to be needed to make the sanyo phone work, but that's
# more extensive and will come after coordination.
command in case this setting was not saved. Since bandwidth reclamation
(-current only) often results in bus activity continuing to the end
of every frame, most transfers would fail with IOERROR if this
setting is missed.
Reviewed by: n_hibma
MFC after: 1 week
not < the size of the device. This avoids geom complaints.
Fix a serious bug in the handling of the RS_NO_CLEAR_UA quirk. When we
go and insert the test-unit-ready command the umass_cam_quirk_cb() function
sets the status as if the READ_CAPACITY command suceeded when, in fact, it
did not. This leads to the CAM layer trying to use garbage in the return
buffer and panicing the system (or doing other bad things).
Add a quirk entry for MSYSTEMS DISK-ON-KEY, which is sold under the Sony
brand as a solid state disk-on-key usb device. This device requires
several quirks to work properly.
Note that the disk-on-key device will not work properly until CAM also
gets a quirk entry for it, which has been submitted to the CAM maintainer,
and you may have to temporarily uncomment the DELAY() as well. -current
does not properly wait for devices to power up so you may also have
to temporarily uncomment the DELAY(300000) to make your device work.
A solution must be found to that issue.
MFC after: 3 days
X-MFC note: the quirk support must MFCd before this patch can be
the dataphysend calculation could only possibly work if the virtual buffer
is also physically contiguous. Calculate dataphysend by calculating the
ending virtual address first, then converting to a physical address.
The second bug applies only to NetBSD and OpenBSD and involves the curlen
calculation in the two-contiguous-physical-pages case (which we don't support).
Also cleanup the use of the OHIC_PAGE() macro on dataphysend and add a panic
if len goes negative (meaning we lost the physical page translation
representing the end of the buffer).
IMHO the dataphysend is still bokered since it might be misrepresented
by shared userland page mappings. The whole section needs to be rewritten
to use the virtual address range.
MFC after: 3 days
