From: David Brownell <david-b@pacbell.net>
To: Jens Axboe <axboe@suse.de>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Nicolas Mailhot <Nicolas.Mailhot@laPoste.net>,
USB development list <linux-usb-devel@lists.sourceforge.net>,
linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] Re: [Bug 1412] Copy from USB1 CF/SM reader stalls, no actual content is read (only directory structure)
Date: Fri, 07 Nov 2003 10:56:48 -0800 [thread overview]
Message-ID: <3FABEAF0.9060000@pacbell.net> (raw)
In-Reply-To: <20031107082439.GB504@suse.de>
Jens Axboe wrote:
> No that looks alright, given you are allocating low memory pages. The
> devices can probably do full 32-bit dma I bet, though.
Typically ... most usb host controllers you'll see are on
PCI (OHCI, UHCI, EHCI) with no restrictions, and only some
EHCI controllers can do 64-bit DMA. That's all visible in
the the dma_mask for each interface in the device with the
mass storage support, usually still at its "32-bit dma is ok"
pci controller default.
But it seems that most current 2.6 DMA API implementations
have some problems in those areas. See for example:
http://marc.theaimsgroup.com/?l=linux-kernel&m=106746453218943&w=2
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=106789996221347&w=2
That second patch is a partial workaround for the first patch
presumably not getting applied before 2.6.0-final. Net result,
some systems with gobs of memory and no IOMMU may do needless
buffer copies during USB I/O.
Though a quick glance suggested to me that SCSI infrastructure
is consulting dma_mask directly, instead of using the DMA API
calls which do that. I'm not sure I'd trust it to be any
more correct, given GIGO ...
- Dave
prev parent reply other threads:[~2003-11-07 23:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1067633171.3886.1.camel@m70.net81-64-235.noos.fr>
2003-11-01 15:47 ` [Bug 1412] Copy from USB1 CF/SM reader stalls, no actual content is read (only directory structure) Alan Stern
2003-11-04 7:49 ` Jens Axboe
2003-11-04 17:33 ` Alan Stern
2003-11-05 8:40 ` Jens Axboe
2003-11-05 15:47 ` Alan Stern
2003-11-07 8:24 ` Jens Axboe
2003-11-07 8:50 ` Nicolas Mailhot
2003-11-07 9:09 ` Jens Axboe
2003-11-07 9:25 ` Nicolas Mailhot
2003-11-07 21:02 ` Nicolas Mailhot
2003-11-07 21:03 ` Nicolas Mailhot
2003-11-07 21:22 ` Jens Axboe
2003-11-07 15:48 ` Alan Stern
2003-11-07 21:22 ` Jens Axboe
2003-11-07 18:56 ` David Brownell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FABEAF0.9060000@pacbell.net \
--to=david-b@pacbell.net \
--cc=Nicolas.Mailhot@laPoste.net \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.