an URQ_REQUEST when DMA segments are passed to usbd_start_transfer();
when the request doesn't include the optional data buffer the size of
the transfer (xfer->length) is 0, in which case usbd_transfer() won't
create a DMA map but call usbd_start_transfer() with no DMA segments.
With the previous change this could result in the bus_dmamap_sync()
implementation dereferencing the NULL-pointer passed as the DMA map
argument.
While at it fix what appears to be a typo in usbd_start_transfer();
in order to determine wheter usbd_start_transfer() was called with
DMA segments check whether the number of segments is > 0 rather than
the pointer to them being > 0.
OK'ed by: imp
I have been debugging the usb problems some more. Your were
right in your assumption (thanks for the pointer) about lack
of calls to bus_dmamap_sync(). In usbdi.c bus_dmamap_sync()
does get used for transfers that move data from PC to USB and
it is used for transfers that move data from USB to PC. But
someone forgot that control transfers consist of possibly two
data chunks : the request itself and optionally a buffer of
data that should be transfered to or from the USB device. On
requests to the control endpoint without additional data
bus_dmamap_sync() didn't get called. For some reason my first
tests with umass worked (due to enough cache poisening I
guess). The attached patch adds a call to bus_dmamap_sync()
to usbdi.c and now all devices I have tried work out of the
box. I have successfully transfered large files using the
if_axe driver and I have mounted several different umass
devices.
submitted by: Daan Vreeken
sponsored by: Vitsch Electronics
reviewed by: cognet@
the CAM_NEW_TRAN_CODE that has been in the tree for some years now.
This first step consists solely of adding to or correcting
CAM_NEW_TRAN_CODE pieces in the kernel source tree such
that a both a GENERIC (at least on i386) and a LINT build
with CAM_NEW_TRAN_CODE as an option will compile correctly
and run (at least with some the h/w I have).
After a short settle time, the other pieces (making
CAM_NEW_TRAN_CODE the default and updating libcam
and camcontrol) will be brought in.
This will be an incompatible change in that the size of structures
related to XPT_PATH_INQ and XPT_{GET,SET}_TRAN_SETTINGS change
in both size and content. However, basic system operation and
basic system utilities work well enough with this change.
Reviewed by: freebsd-scsi and specific stakeholders
: revision 1.27
: date: 2000/05/28 12:43:24; author: ache; state: Exp; lines: +3 -2
: Manipulate with AltGR Led (really CapsLock Led) only in K_XLATE mode, because
: all other modes not set ALKED flag and it means that CapsLock always turned
: off for them.
: Real bug example is X11 which never turn on CapsLock with Russian keyboard.
:
: PR: 18651
: Submitted by: "Mike E. Matsnev" <mike@po.cs.msu.su>
MFC after: 3 days
tasks. Since the host controllers rely on tasks to process transfer
timeouts, if a synchronous transfer from a driver was invoked from
a task and timed out, it would never complete because the single
task thread was stuck performing the synchronous transfer so couldn't
process the timeout.
This affected the axe, udav and ural drivers.
Problem hardware provided by: guido
- Add entries in the uscanner.4 man page (along with missing 3500).
PR: usb/100957 [1], usb/100992 [2]
Submitted by: Jim Teresco <terescoj@teresco.org> [1],
Walter C. Pelissero <walter.pelissero@iesy.net> [2]
MFC after: 3 days
close and re-open the default pipe instead of relying on the host
controller driver to notice the changes. Remove the unreliable code
that attempted to update these fields while the pipe was active.
This fixes a case where the hardware could cache and continue to
use the old address, resulting in a "getting first desc failed"
error.
PR: usb/103167
The parallel LINT build sometimes broke if kernel-depend wasn't
fast enough in generating ukbdmap.h. If someone thinks this
option would still be useful for the module, a proper fix is
to add the code generating ukbdmap.h into modules/ukbd/Makefile
and backing this change out.
ioctls passing integer arguments should use the _IOWINT() macro.
This fixes a lot of ioctl's not working on sparc64, most notable
being keyboard/syscons ioctls.
Full ABI compatibility is provided, with the bonus of fixing the
handling of old ioctls on sparc64.
Reviewed by: bde (with contributions)
Tested by: emax, marius
MFC after: 1 week
s/device_ptr_t/device_t/g
No md5 changes in the .o's
# Note to the md5 tracking club: $FreeBSD$ changes md5 after every commit
# so you need to checkout -kk to get $FreeBSD$ instead of the actual value
# of the keyword.
required by arches like sparc64 (not yet implemented) and sun4v where there
are seperate IOMMU's for each PCI bus... For all other arches, it will
end up returning NULL, which makes it a no-op...
Convert a few drivers (the ones we've been working w/ on sun4v) to the
new convection... Eventually all drivers will need to replace the parent
tag of NULL, w/ bus_get_dma_tag(dev), though dev is usually different for
each driver, and will require hand inspection...
Reviewed by: scottl (earlier version)
This enables the scanner function on these devices to be detected
and probed by uscanner(4), but only when ulpt is not loaded.
PR: usb/92462
Submitted by: Friedrich Volkmann
MFC after: 30 days
is never taken since there aren't any 802.11a ural(4) sticks available
on the market.
PR: kern/99676
Submitted by: KIYOHARA Takashi
Reviewed by: damien
MFC after: 1 week
