Am Freitag, 21. September 2001 02:27 schrieb Pavel Machek:
> Hi!
>
> > > > So it is a interface specific setting from the drivers point of view.
> > >
> > > Yes, USB has "interface" drivers more than "device" drivers;
> > > but control messaging is device-wide ... and if we view this
> > > as spec
Hi!
> > > So it is a interface specific setting from the drivers point of view.
> >
> > Yes, USB has "interface" drivers more than "device" drivers;
> > but control messaging is device-wide ... and if we view this
> > as special-casing to get safe USB-storage, I suspect we won't
> > be seeing man
> > > > I can imagine a device that includes both a usb-storage
> > > > interface, used for swapping/paging/etc, and other
> > > > interfaces (say, for audio/video I/O streams).
> >
> > ...
> >
> > A combination of mass storage and a video camera seems certainly possible.
> > IMHO we should not c
Hi!
> > > > Why? I think that either whole device needs GFP_NOIO or whole device
> > > > can live with GFP_KERNEL, but I can't imagine a device where aprt needs
> > > > GFP_NOIO and part does not...
> > >
> > > I can imagine a device that includes both a usb-storage
> > > interface, used for swa
Am Freitag, 21. September 2001 11:59 schrieb Pavel Machek:
> Hi!
>
> > > Why? I think that either whole device needs GFP_NOIO or whole device
> > > can live with GFP_KERNEL, but I can't imagine a device where aprt needs
> > > GFP_NOIO and part does not...
> >
> > I can imagine a device that includ
Hi!
> > Why? I think that either whole device needs GFP_NOIO or whole device can live
> > with GFP_KERNEL, but I can't imagine a device where aprt needs GFP_NOIO and
> > part does not...
>
> I can imagine a device that includes both a usb-storage
> interface, used for swapping/paging/etc, and ot
> > Long term I think per-request options here are essential.
> > Near term, flagging this at the device level may well be
> > the least invasive solution.
>
> Why? I think that either whole device needs GFP_NOIO or whole device can live
> with GFP_KERNEL, but I can't imagine a device where aprt
Hi!
> > These are usb_control_message() and usb_clear_halt(). I was thinking
> > of doing a version for block devices that uses NOIO. Thus compatibility is
> > maintained in 2.4 and in 2.5 we'd merge and add another parameter to the call.
>
> What did you think of Alan's notion of basically wr
David Brownell wrote:
>
> > Now the HCDs can use endpointnumber+direction(pipe) as
> > an index for the endpoint descriptor array and get all the
> > information about the endpoint from there.
>
> ... after updating control flow in some cases to make sure
> they don't separate the usb_device fro
David Brownell wrote:
>
> Roman,
>
> > There are a lot of things that are endpoint specific:
>
> (endpoint in a given config/altsetting ...)
>
> > e.g. maxpacketsize, toggle bit, startingpoint and intervall
> > of INTR transfers, queueingpoint for URBs,...
> > And all that information is sprea
Am Mittwoch, 19. September 2001 18:50 schrieb David Brownell:
> > So it is a interface specific setting from the drivers point of view.
>
> Yes, USB has "interface" drivers more than "device" drivers;
> but control messaging is device-wide ... and if we view this
> as special-casing to get safe US
Roman,
> There are a lot of things that are endpoint specific:
(endpoint in a given config/altsetting ...)
> e.g. maxpacketsize, toggle bit, startingpoint and intervall
> of INTR transfers, queueingpoint for URBs,...
> And all that information is spread around. Some bits are in the
> device str
> So it is a interface specific setting from the drivers point of view.
Yes, USB has "interface" drivers more than "device" drivers;
but control messaging is device-wide ... and if we view this
as special-casing to get safe USB-storage, I suspect we won't
be seeing many composite storage-plus-som
[..]
> > > Actually it should be an endpoint specific setting.
> >
> > Actually there is no connection to the endpoint from a driver point of
> > view. Any protocol to do data transmission for storage devices uses at
> > least two endpoints. During data transmission using any of these
> > endpoint
Oliver Neukum wrote:
>
> Am Mittwoch, 19. September 2001 12:05 schrieb Roman Weissgaerber:
> > Oliver Neukum wrote:
> > > > > These are usb_control_message() and usb_clear_halt(). I was thinking
> > > > > of doing a version for block devices that uses NOIO. Thus
> > > > > compatibility is maintai
Am Mittwoch, 19. September 2001 12:05 schrieb Roman Weissgaerber:
> Oliver Neukum wrote:
> > > > These are usb_control_message() and usb_clear_halt(). I was thinking
> > > > of doing a version for block devices that uses NOIO. Thus
> > > > compatibility is maintained in 2.4 and in 2.5 we'd merge a
Oliver Neukum wrote:
>
> > > These are usb_control_message() and usb_clear_halt(). I was thinking
> > > of doing a version for block devices that uses NOIO. Thus compatibility
> > > is maintained in 2.4 and in 2.5 we'd merge and add another parameter to
> > > the call.
> >
> > What did you think
Hi!
> At this point, I think the "best" answer is to say:
>
> Don't swap over USB for a 2.4.x kernel.
>
> I think this issue is better addressed in 2.5, for stability
> reasons.
Unfortunately, it would be also "do not write to disk over USB for
2.4". :-(.
> > These are usb_control_message() and usb_clear_halt(). I was thinking
> > of doing a version for block devices that uses NOIO. Thus compatibility
> > is maintained in 2.4 and in 2.5 we'd merge and add another parameter to
> > the call.
>
> What did you think of Alan's notion of basically wrappi
> > The pci_pool calls will need a tweak; they test for SLAB_KERNEL,
> > but SLAB_NOIO should work there too.
>
> Explain please.
The HCDs use the pci_pool_alloc() calls, which has substantially
improved their portability to non-x86 systems (with "interesting" PCI
DMA restrictions), but that was
Am Mittwoch, 19. September 2001 01:15 schrieb Matthew Dharm:
> At this point, I think the "best" answer is to say:
>
> Don't swap over USB for a 2.4.x kernel.
>
> I think this issue is better addressed in 2.5, for stability reasons.
Unfortunately this is not limited to swapping.
Functionall
At this point, I think the "best" answer is to say:
Don't swap over USB for a 2.4.x kernel.
I think this issue is better addressed in 2.5, for stability reasons.
Matt
On Tue, Sep 18, 2001 at 11:57:02PM +0200, Oliver Neukum wrote:
> Am Dienstag, 18. September 2001 18:59 schrieb Alan Cox
Am Dienstag, 18. September 2001 18:59 schrieb Alan Cox:
> > Some USB APIs will be trouble, since they don't pass an URB
> > or explicit mem_flags value down. Were you thinking of just
> > making it all use SLAB_NOIO? That might cause a few more
> > "out of memory" error reports in places it's no
Am Dienstag, 18. September 2001 18:06 schrieben Sie:
> > but a patch to add a flag to the usb core and the host controller drivers
> > is still needed. I'll have a look at it. I propose the flag to be called
> > URB_MEM_NOIO.
>
> As I understand it, that sounds appropriate. Basically, any place t
On Tue, Sep 18, 2001 at 12:28:09PM -0700, David Brownell wrote:
> Though I still wonder how this can work for non-storage
> devices, like the "swap-over-nfs" scenarios. At some
> point there will need to be a more general solution than
> a per-device option. Just not yet!
swap-over-nfs over a U
Though I still wonder how this can work for non-storage
devices, like the "swap-over-nfs" scenarios. At some
point there will need to be a more general solution than
a per-device option. Just not yet!
- Dave
___
[EMAIL PROTECTED]
To unsubscribe, us
iginal Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
To: "David Brownell" <[EMAIL PROTECTED]>
Cc: "Alan Cox" <[EMAIL PROTECTED]>; "Linux usb mailing list"
<[EMAIL PROTECTED]>
Sent: Tuesday, September 18, 2001 12:13 PM
Subject: Re
> How would tying it to devices work? Starting to swap onto a file
> would need to trigger that, also I/O to memory mapped files (yes?);
> and it'd nice to be able to clear such device flags later. I don't know
> what information the MM subsystem exports, or when it does so;
> though I suppose u
ng to
be having some issues anyway ... :)
- Dave
- Original Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
Sent: Tuesday, September 18, 2001 9:59 AM
Subject: Re: [linux-usb-devel] Re: usb-storage not suitable for swapping
> > Some USB APIs will be trouble, si
> Some USB APIs will be trouble, since they don't pass an URB
> or explicit mem_flags value down. Were you thinking of just
> making it all use SLAB_NOIO? That might cause a few more
> "out of memory" error reports in places it's not necessary (khubd
> as one example). But I'm not sure making u
> but a patch to add a flag to the usb core and the host controller drivers is
> still needed. I'll have a look at it. I propose the flag to be called
> URB_MEM_NOIO.
As I understand it, that sounds appropriate. Basically, any place that
usbcore or an hcd now uses GFP_KERNEL, if URB_MEM_NOIO
i
Am Montag, 17. September 2001 11:24 schrieb Pavel Machek:
> Hi!
>
> > Why is that? The USB 2.0 disks seem like bandwidth won't
> > be an issue. Is it the iffy error handling going through SCSI?
> >
> > > Suggestions for how to fix it?
> >
> > And precisely what is the issue -- is usb-storage ign
Hi!
> Why is that? The USB 2.0 disks seem like bandwidth won't
> be an issue. Is it the iffy error handling going through SCSI?
>
>
> > Suggestions for how to fix it?
>
> And precisely what is the issue -- is usb-storage ignoring
> information in the SCSI requests that blocking on memory
> i
Am Montag, 17. September 2001 03:41 schrieben Sie:
> On Mon, Sep 17, 2001 at 12:57:13AM +0200, Oliver Neukum wrote:
> > Well yes, but you can't assume it might not be disconnected.
> > Disconnecting is legal everywhen. AFAIK usb storage doesn't time out a
> > request, but waits for reconnection. Y
On Mon, Sep 17, 2001 at 12:57:13AM +0200, Oliver Neukum wrote:
> Well yes, but you can't assume it might not be disconnected. Disconnecting is
> legal everywhen. AFAIK usb storage doesn't time out a request, but waits for
> reconnection. You could have init stuck in state D.
Actually, to avoid
Am Montag, 17. September 2001 00:09 schrieben Sie:
> > > Hmm, added after 2.4.10pre2 ... :)
> >
> > Please explain.
> >
> > > Would you happen to have a pointer to more info about what
> > > this GFP_BUFFER flag is for
>
> "grep GFP_BUFFER include/linux/*.h" said nothing;
> doesn't have such a ma
Am Montag, 17. September 2001 00:20 schrieben Sie:
> > > > Not that I would recommend swapping over USB anyway
> > >
> > > Why is that? The USB 2.0 disks seem like bandwidth won't
> > > be an issue. Is it the iffy error handling going through SCSI?
> >
> > No, it's basically the same problem
> > > Would you happen to have a pointer to more info about what
> > > this GFP_BUFFER flag is for
>
> "grep GFP_BUFFER include/linux/*.h" said nothing;
> doesn't have such a mask. At least, in pre2.
It got split up somewhat
GFP_NOIO is what I think you want
_
Am Sonntag, 16. September 2001 23:37 schrieb Alan Cox:
> > Additional remark: You should use GFP_BUFFER, not ATOMIC.
> > And yes, you'd need such a flag. Provided the scsi layer passes the
> > information. AFAIK it doesn't.
>
> The scsi layer always assumes I/O might be involved in page outs.
May
> > > Not that I would recommend swapping over USB anyway
> >
> > Why is that? The USB 2.0 disks seem like bandwidth won't
> > be an issue. Is it the iffy error handling going through SCSI?
>
> No, it's basically the same problem as swapping over nfs.
> Sometimes not only GFP_ATOMIC is need
> > Hmm, added after 2.4.10pre2 ... :)
>
> Please explain.
>
> > Would you happen to have a pointer to more info about what
> > this GFP_BUFFER flag is for
"grep GFP_BUFFER include/linux/*.h" said nothing;
doesn't have such a mask. At least, in pre2.
> I have no exact pointer. It should be
Am Sonntag, 16. September 2001 23:44 schrieben Sie:
> Hmm, added after 2.4.10pre2 ... :)
Please explain.
> Would you happen to have a pointer to more info about what
> this GFP_BUFFER flag is for? It can't exactly know about
> DMA restrictions for specific PCI devices, which is a big
> deal for
> Additional remark: You should use GFP_BUFFER, not ATOMIC.
> And yes, you'd need such a flag. Provided the scsi layer passes the
> information. AFAIK it doesn't.
The scsi layer always assumes I/O might be involved in page outs.
Alan
___
[EMAIL PROT
Am Sonntag, 16. September 2001 03:38 schrieben Sie:
> > Not that I would recommend swapping over USB anyway
>
> Why is that? The USB 2.0 disks seem like bandwidth won't
> be an issue. Is it the iffy error handling going through SCSI?
No, it's basically the same problem as swapping over nfs.
> Seems to me that if GFP_KERNEL allocation is an issue,
> every (!) I/O request path is going to need to pass memory
> allocation flags down. That capability isn't in the usbcore
> API today (URBs). Do we need to add a new flag to
> tell host controller drivers to only use GFP_ATOMIC?
> (URB_M
> Not that I would recommend swapping over USB anyway
Why is that? The USB 2.0 disks seem like bandwidth won't
be an issue. Is it the iffy error handling going through SCSI?
> Suggestions for how to fix it?
And precisely what is the issue -- is usb-storage ignoring
information in the SCS
> I am not sure that the stack is necessaryly DMA-able on all architectures.
> How about a 64bit machine with more than 4GB of RAM ?
Stack is not DMAable on all platforms already, nor is virt_to_bus guaranteed
to give you sane answers on either the stack or static data
_
Am Sonntag, 16. September 2001 00:03 schrieben Sie:
> Actually, looking at this does the devrequest structure need to be
> allocated in DMA-able memory? Could I get away with it being on the stack?
>
> Yes, I know that stack-allocated memory is DMA-able _now_, but it won't be
> in the future.
devrequest needs to be DMA-able. Putting it on the stack will happen to
work for i386, but you shouldn't depend on it.
JE
On Sat, Sep 15, 2001, Matthew Dharm <[EMAIL PROTECTED]> wrote:
> Actually, looking at this does the devrequest structure need to be
> allocated in DMA-able memory? Could
Actually, looking at this does the devrequest structure need to be
allocated in DMA-able memory? Could I get away with it being on the stack?
Yes, I know that stack-allocated memory is DMA-able _now_, but it won't be
in the future. I already violate that rule in several key places, but I'd
Am Samstag, 15. September 2001 22:32 schrieben Sie:
> Um okay... I guess that's a problem.
>
> Not that I would recommend swapping over USB anyway
>
> Suggestions for how to fix it?
As this function blocks, could you not make the allocated memory part of the
device descriptor ?
Um okay... I guess that's a problem.
Not that I would recommend swapping over USB anyway
Suggestions for how to fix it?
Matt
On Sat, Sep 15, 2001 at 12:42:57AM +0200, Pavel Machek wrote:
> Hi!
>
> In usb_stor_control_msg, you are allocating memory with
> GFP_KERNEL. That means that us
52 matches
Mail list logo
