Hi:
The UHCI driver only cleans up removed QH/TD/URB entries in the interrupt
routine. This means that if the interrupts aren't working for whatever
reason (in my case it's a bug in suspend/resume), these entries will never
be cleaned up. This can easily cause deadlocks if you unlink an URB and
Hi Vince, I'm not sure, but it looks like a bug in the USB core.
I was kind of expecting this :) My patch causes devio.c to hold
a reference to the usb_device maybe long after the device has
been disconnected. This is supposed to be OK, but from your
Oops it looks like some part of the hcd was fi
DEAR SIR.
PLEASE I AM A BOY OF 25 YEARS AND I AM LOOKING FOR INVESTMENT OPPORTUNITY.
I INTENDED TO INVEST THE SUM OF TWENTY MILLION UNITED STATES DOLLARS INHERITED BY MY
LATE FATHER.I AM FROM ZIMBABWE.BUT I AM LIVING IN THE NETHERLANDS (EUROPE) AT THE
MOMENT FOR MORE INFORMATION REACH ME ON MY N
Hi Dave,
On Monday 08 December 2003 05:59, David Brownell wrote:
> Duncan Sands wrote:
> > This just came up in devio.c: the "synchronous" call to usb_unlink_urb
> > was returning immediately with -EBUSY (probably because the core
> > just nuked the urbs) even though the completion handlers hadn't
Hi Alan,
> In my opinion these semantics are insufficient. Certainly they are
> not appropriate for the way usb_unlink_urb() is actually used in many
> drivers. A very hasty survey of source files in drivers/usb/class
> showns that most synchronous unlinkers require these semantics
> instead: Re
Hi Dave,
> Drivers now could easily get those cleanup semantics with something
> much smaller than your patch (though hcd_unlink_urb should still
> get rid of that splice logic!):
>
>static inline void urb_begone(struct urb *urb)
>{
>while (usb_unlink_urb (urb) == -EBUSY) {
>
> better to be explicit I think: provide a routine for halting the endpoint
> (I guess this exists already). Then people who resubmit in the completion
> handler can do:
>
> halt the endpoint (all submissions to the endpoint will fail).
> unlink the urb (synchronously)
> restart the endpoint
>
[EMAIL PROTECTED] wrote:
On the one hand, I have never seen SCSI error recovery do something useful.
On the other hand, in this case, it is mostly our fault.
If we return errors with the meaning "don't retry, that is meaningless"
that would stop the SCSI layer from doing its nonsense.
I tried your
Dear list,
I would like to quickly drop in this patch against the vanilla linux
2.4.23 source tree which enabled the use of a Pentax Optio 330/430 RS
digital camera as a mass storage device for me.
I've been using this patch for quite some time now with a Pentax Optio
430 RS and it has never give
My own sources have somewhere at the top of datafab.c the comment
/*
* Commands: 8 bytes
* Three commands are known:
*
* Identify: 00 01 00 00 00 a0 ec 01
* (with b0 instead of a0 for LUN 1).
*
* Read: 00 nn xx xx xx ex 20 01
* (with f0 instead of e0 for LUN 1;
* nn: sector c
please also post the decoded USB audio descriptor, using lsusb
Tom
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything fro
Hi,
and thanks for the reply :-)
> please also post the decoded USB audio descriptor, using lsusb
>
> Tom
>
here it is
svetljo
[EMAIL PROTECTED] SPECS]# lsusb -s 001:003 -vv
Bus 001 Device 003: ID 06f8:c000
cannot get string descriptor 1, error = Broken pipe(32)
Device Descriptor:
Thanks.
> bNrChannels 6
Hm, the OSS driver doesn't really support more than 2 channels, as the
OSS API is more or less stereo only.
ALSA should be better suited for this, but I don't know too much about
their USB driver...
Tom
-
> Thanks.
>
> > bNrChannels 6
>
> Hm, the OSS driver doesn't really support more than 2 channels, as the
> OSS API is more or less stereo only.
ok, but it has two interfaces - 2ch & 6ch, or am i wrong
and it's supposed to work on Mac(without driver)
as a stereo device(writte
Phew, this is a really complex topic. Multiple LUNs at multiple levels :(
[EMAIL PROTECTED] wrote:
My own sources have somewhere at the top of datafab.c the comment
/*
* Commands: 8 bytes
* Three commands are known:
*
* Identify: 00 01 00 00 00 a0 ec 01
* (with b0 instead of a0 for LUN 1
On Mon, 8 Dec 2003, Eduard Hasenleithner wrote:
> I have a more fundamental question: Why do we need lun detection? The
> datafab reader is already presented to the OS as a two lun device
> (sda/sdb). In this case the user can decide which lun to use. Or is your
> datafab device different with
On Mon, 8 Dec 2003, Christian Strauf wrote:
> Dear list,
>
> I would like to quickly drop in this patch against the vanilla linux
> 2.4.23 source tree which enabled the use of a Pentax Optio 330/430 RS
> digital camera as a mass storage device for me.
>
> I've been using this patch for quite som
On Mon, 8 Dec 2003, Herbert Xu wrote:
> Hi:
>
> The UHCI driver only cleans up removed QH/TD/URB entries in the interrupt
> routine. This means that if the interrupts aren't working for whatever
> reason (in my case it's a bug in suspend/resume), these entries will never
> be cleaned up. This c
Duncan Sands wrote:
Hi Vince, I'm not sure, but it looks like a bug in the USB core.
I was kind of expecting this :) My patch causes devio.c to hold
a reference to the usb_device maybe long after the device has
been disconnected. This is supposed to be OK, but from your
... no, that's not suppose
Hi Alan,
> Does your patch work if you leave out the FIX_INQUIRY flag or is that flag
> necessary? Also, do you get any messages in your kernel log about
I need to test what happens if I leave out the FIX_INQUIRY flag. If I
set this to "0", what will the consequences be in the worst case? Will
On Monday 08 December 2003 17:03, David Brownell wrote:
> Duncan Sands wrote:
> > Hi Vince, I'm not sure, but it looks like a bug in the USB core.
> > I was kind of expecting this :) My patch causes devio.c to hold
> > a reference to the usb_device maybe long after the device has
> > been disconne
On Sun, 7 Dec 2003, Mathias Gug wrote:
>
>
>
> >From: Alan Stern <[EMAIL PROTECTED]>
> >Okay, that clears it up!
> >
> >The only difference is the removal of the parentheses around the ep
> >parameter in the macro texts. Perusal of the kernel code shows that this
> >will make a difference in o
On Mon, 8 Dec 2003, Christian Strauf wrote:
> Hi Alan,
>
> > Does your patch work if you leave out the FIX_INQUIRY flag or is that flag
> > necessary? Also, do you get any messages in your kernel log about
> I need to test what happens if I leave out the FIX_INQUIRY flag. If I
> set this to "0
On Mon, 8 Dec 2003, Duncan Sands wrote:
> On Monday 08 December 2003 17:03, David Brownell wrote:
> > Duncan Sands wrote:
> > > Hi Vince, I'm not sure, but it looks like a bug in the USB core.
> > > I was kind of expecting this :) My patch causes devio.c to hold
> > > a reference to the usb_devic
Duncan Sands wrote:
static inline void urb_begone(struct urb *urb)
{
while (usb_unlink_urb (urb) == -EBUSY) {
set_current_state (TASK_UNINTERRUPTIBLE);
schedule_timeout (HZ/100);
}
}
why not have usb_unlink_urb (sync) do this?
That'd work, and could finally b
better to be explicit I think: provide a routine for halting the endpoint
(I guess this exists already). Then people who resubmit in the completion
handler can do:
halt the endpoint (all submissions to the endpoint will fail).
unlink the urb (synchronously)
restart the endpoint
Not all endpoints
Dear list:
I'm not entirely certain, but I think I've a bug or two to report. At this
point, my USB device is under development and should imitate a USB mouse.
Problem 1)
When it is plugged into a Windows box, it works as expected, but when I
plug it into a Linux box it doesn't seem to finish g
Am Montag, 8. Dezember 2003 17:49 schrieb David Brownell:
> > better to be explicit I think: provide a routine for halting the endpoint
> > (I guess this exists already). Then people who resubmit in the completion
> > handler can do:
> >
> > halt the endpoint (all submissions to the endpoint will
As I am the original person who posted the patch, I would like to use
this opertunity to fix a few things. I have looked at the windows driver
.inf, and according to it, we should have the following: -
UNUSUAL_DEV( 0x0a17, 0x0004, 0x, 0x,
"Pentax",
"USB DI
Alan Stern wrote:
On Mon, 8 Dec 2003, Christian Strauf wrote:
Hi Alan,
Does your patch work if you leave out the FIX_INQUIRY flag or is that flag
necessary? Also, do you get any messages in your kernel log about
I need to test what happens if I leave out the FIX_INQUIRY flag. If I
set this t
... hold
a reference to the usb_device maybe long after the device has
been disconnected. This is supposed to be OK, but from your
... no, that's not supposed to be OK. Returning from disconnect()
means that a device driver is no longer referencing the interface
the driver bound to, or ep0.
Wel
Both your issues seem to be buggy-device issues, not a UHCI issues.
Or are you also reporting that OHCI and EHCI work fine with it?
However, when I change the configuration value to 0x01, there is no problem
with either system. I've noticed the code for the error message "config 0
descriptor??" i
On Sun, 7 Dec 2003, Duncan Sands wrote:
> This just came up in devio.c: the "synchronous" call to usb_unlink_urb
> was returning immediately with -EBUSY (probably because the core
> just nuked the urbs) even though the completion handlers hadn't
> finished. The code assumed (of course - doesn't e
On Monday 08 December 2003 17:31, Alan Stern wrote:
> On Mon, 8 Dec 2003, Duncan Sands wrote:
> > On Monday 08 December 2003 17:03, David Brownell wrote:
> > > Duncan Sands wrote:
> > > > Hi Vince, I'm not sure, but it looks like a bug in the USB core.
> > > > I was kind of expecting this :) My pa
On Mon, Dec 08, 2003, Herbert Xu <[EMAIL PROTECTED]> wrote:
> The UHCI driver only cleans up removed QH/TD/URB entries in the interrupt
> routine. This means that if the interrupts aren't working for whatever
> reason (in my case it's a bug in suspend/resume), these entries will never
> be cleaned
> On Sun, 7 Dec 2003, Oliver Neukum wrote:
>
> > More than that. New submissions of that URB must fail, or the newly
> > submitted URB unlinked, if the completion handler has won the race.
>
> My patch does this (submissions made before the synchronous unlink returns
> will fail).
I've change
On Mon, 8 Dec 2003, Ethan Mattor wrote:
> Problem 2)
> The amount of returned descriptor is a bit touchy. As far as I can tell, by
> the USB specification, when the host asks for 'x' number of bytes through
> the wLength field, the device is expected to return a payload of 'x' of
> bytes during t
I don't have a card reader and know almost nothing about how they work.
But following this thread has inspired a question: What happens to the lun
mapping when there are two slots in the reader and _both_ slots have a
card inserted?
The mapping does not depend on the presence of m
On Mon, 8 Dec 2003, Duncan Sands wrote:
> Hi Alan, this is for usbfs, not a normal driver. Recall that I want to replace
> use of ps->devsem with ps->dev->serialize.
Maybe you shouldn't do that. Other drivers maintain their own data
structure separately from the struct usb_device and with its
On Mon, Dec 08, 2003 at 02:15:38PM +0100, [EMAIL PROTECTED] wrote:
> > I have a more fundamental question: Why do we need lun detection?
>
> You wrote
>
> info->lun = srb->device->lun;
>
> and maybe that would work. These are two very different animals
> in principle, but maybe it is true
On Mon, Dec 08, 2003 at 01:38:52PM -0500, Jimmie Mayfield wrote:
> An unwanted side effect of this code, as you've noted, was that for
> single slot CF readers, the LUN code ends up detecting phantom devices.
> That is, the device would respond successfully to an identify device query
> regardless
On Mon, 8 Dec 2003, Oliver Neukum wrote:
> > My patch does this (submissions made before the synchronous unlink returns
> > will fail).
>
> I've changed my mind on this. Outright failure is a change of semantics.
> It is not needed. Simply set a flag in this case and return success.
> After the
On Sat, 6 Dec 2003, Bruno GRIEDER wrote:
> Hi Alan,
>
> Thanks for your reply. I have been unavailable most of last week, but
> here is the information requested.
>
> First, I discovered that the issue of having no endpoints listed in 2.6
> test9 only happened when I plugged the device after boo
On Monday 08 December 2003 11:41, Duncan Sands wrote:
> Sure, but it is my impression (based on nothing at all, like all the best
> opinions) that the situation is like this:
>
> Number of places that wrongly rely on usb_unlink_urb (sync) behaving
> the way Alan suggested it should: lots.
>
> Numb
Hi Alan,
> But usbfs may suffer from complications as a result of its unorthodox
> approach to device ownership.
Yes, you have put your finger on it.
> > Currently ps->dev is set to NULL in
> > the devio.c usbfs disconnect method (if some interface is claimed) or in
> > inode.c on device discon
> Pete, I tested your backport + this change above on 2.4.23 and it works
> well on my HP psc 2110.
> I did have to apply part of the patch by hand, so I rediffed it against
> 2.4.23. Patch is below.
OK, either way is good. However, I don't understand why it
didn't apply for you. I tried this wa
Customers keep complaining that usb-storage is unusable in 2.4,
so I looked at it and WOA! Very simple things, like running
dd if=/dev/sda of=/dev/null bs=8k and then unplugging the
flash cause oopses and lockups; once those are fixed, storage
can get offline forever. Ugh.
2.6 looks much saner, bu
Hi, I wrote an email directly to "greg at kroah.com" because he's the
author of the pl2303 driver but I think I could have some help here too
about an issue with the pl2303 driver.
if I connect a usb-serial adapter to my laptop, and I connect to this
adapter an external serial modem, everything
On Mon, Dec 08, 2003 at 01:04:39PM -0500, Johannes Erdfelt wrote:
>
> I'll echo what Alan said and say the real fix here is fixing the
> suspend/resume case.
I agree completely. However, it would be nice to have a safety net
when things go wrong. In particular, being able to remove the uhci-hcd
Number of places that would break if Alan's semantics were implemented:
little.
I'll disagree. Which is why I've pointed out two distinct
fixes, both safer:
- Retry on -EBUSY (needed for any non-disconnect paths)
- Add uhci_endpoint_disable (only helps disconnect paths)
The problem is that "Al
Most unlinks are done at disconnect, and clearly they have to
be synchronous and there is no sense of failure or retry.
But I won't wait until 2.7
Adding uhci_endpoint_disconnect() will resolve the disconnect()
path issue.
In fact, once that's added, drivers could even start to get
rid of all urb
Alan Stern responding to David Brownell:
But did any kernel ever guarantee those semantics? I don't think so.
Certainly 2.6 never did, and neither OHCI nor EHCI on 2.4 does...
I agree, they didn't. However, that lack didn't prevent driver authors
from _assuming_ that they did.
Sure, but I can't
But if usbcore were to get changed, why not change it
to have a usb_urb_begone() call that MUST (eventually)
be used for all synchronous unlinks? That's a better
long-term approach IMO.
I like that idea. In fact, why not make usb_unlink_urb() be purely async?
Eventually, yes -- getting rid o
On Mon, 8 Dec 2003, Duncan Sands wrote:
> > If you would keep the ps->devsem lock, would there be any problem in
> > setting ps->dev to NULL to indicate disconnection?
>
> You can't keep the ps->devsem lock and use ps->dev->serialize, because it
> leads to deadlock.
How so? Remember that I am a
On Tue, 9 Dec 2003, Herbert Xu wrote:
> On Mon, Dec 08, 2003 at 01:04:39PM -0500, Johannes Erdfelt wrote:
> >
> > I'll echo what Alan said and say the real fix here is fixing the
> > suspend/resume case.
>
> I agree completely. However, it would be nice to have a safety net
> when things go wro
On Mon, 8 Dec 2003, David Brownell wrote:
>
> > Most unlinks are done at disconnect, and clearly they have to
> > be synchronous and there is no sense of failure or retry.
> >
> > But I won't wait until 2.7
>
> Adding uhci_endpoint_disconnect() will resolve the disconnect()
> path issue.
>
> I
Jamie Lokier wrote:
Alan Stern wrote:
Sorry, my question wasn't clear. What I'm trying to understand is,
after you had done
echo 0 >.../bConfigurationValue
why was any code calling usb_reset_device? And exactly which code was
calling usb_reset_device?
USBDEVFS_RESET.
Seems to me that usb_ph
> > You can't keep the ps->devsem lock and use ps->dev->serialize, because it
> > leads to deadlock.
>
> How so? Remember that I am almost totally unfamiliar with the details of
> the usbfs code. Are you saying there are places where the driver holds
> one lock and needs to acquire the other and
Adding uhci_endpoint_disconnect() will resolve the disconnect()
path issue.
In fact, once that's added, drivers could even start to get
rid of all urb unlink calls in their disconnect() logic,
enabling that "fire and forget" model.
Remember the non-hcd drivers. Do they implement disable_endpoin
This is becoming more complex than I expected...
In the following, please don't think that I'm trying to defend the
strategy I suggested earlier. I don't care very much what solution ends
up being adopted; I just want to make people aware of the scope and nature
of the problem.
Part of the di
Am Montag, 8. Dezember 2003 20:07 schrieb Alan Stern:
> On Mon, 8 Dec 2003, Oliver Neukum wrote:
>
> > > My patch does this (submissions made before the synchronous unlink returns
> > > will fail).
> >
> > I've changed my mind on this. Outright failure is a change of semantics.
> > It is not nee
On Mon, 8 Dec 2003, David Brownell wrote:
> I'll be shocked if that name survives too ... ;)
> Maybe "usb_stop_urb()" would be better.
Or usb_wait_for_urb().
> Re implementation, I'll continue to lobby for simplicity.
> Polling doesn't bother me much, since it should only be
> called once.
It's
On Tue, Dec 09, 2003 at 08:02:07AM +1100, herbert wrote:
>
> Sorry about that. Can you please comment on the following patch which
> no longer frees the QHs and TDs outside of the interrupt routine.
I guess this patch has the same problems as the last since the TDs
might still be active. But if
On Mon, Dec 08, 2003 at 04:37:26PM -0500, Alan Stern wrote:
>
> That's supposed to work right now. However, there may be a problem with
> the uhci_stop() routine. While I haven't checked this in detail, it
> appears that the first calls to uhci_free_pending_qhs() and
> uhci_free_pending_tds()
Hello,
I have adapted Alcatel Speedtouch USB Linux driver to work with several
ADSL USB modems. I'd like know your conclusion about timeout problems.
Please, you see this thread:
https://sourceforge.net/forum/forum.php?thread_id=952503&forum_id=287227
Solution for kernel 2.4.23 from an user:
"I
To solve USB timeout problems with new kernels (2.4.22, 2.4.23 and others):
Edit "./include/linux/usb.h"
Change "usb_settoggle" definition.
Change this:
static inline void usb_settoggle(struct usb_device *dev,
unsigned int ep,
unsigned int out,
int bit)
{
dev->toggle[out] &= ~(1 << ep);
dev->to
Hello all,
I'm digging through the USB mass storage code and am pretty confused.
Previously we used a Sony AIT-1 tape drive via SCSI. However, we
recently acquired a new model that supports either firewire / USB.
Neither works (I think for the same reason). I realize that most people
do not have
On Mon, 8 Dec 2003, Duncan Sands wrote:
> > > You can't keep the ps->devsem lock and use ps->dev->serialize, because it
> > > leads to deadlock.
> >
> > How so? Remember that I am almost totally unfamiliar with the details of
> > the usbfs code. Are you saying there are places where the driver h
Hi!
Sorry to bother you, probably someone asked about it before, but there
is no search on sf.net, so I don't know...
Does anyone know how to setup root partition on usb-storage device.
There is a patch mentioned on linux-usb.sourceforge.net:
http://www.lammerts.org/software/kernelpatches/usb-s
On Mon, 08 Dec 2003 23:02:32 + Tomasz Mloduchowski <[EMAIL PROTECTED]> wrote:
| Hi!
|
| Sorry to bother you, probably someone asked about it before, but there
| is no search on sf.net, so I don't know...
|
| Does anyone know how to setup root partition on usb-storage device.
|
| There is a
Herbert Xu wrote:
The problem here is the khubd is stuck in usb_set_address() waiting
for the URB to complete, but it never finishes because the UHCI driver
isn't getting any interrupts.
OHCI could have the same problem.
EHCI doesn't, since it's had a timer interrupt ever since it
first needed on
On Mon, Dec 08, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> Herbert Xu wrote:
>
> > The problem here is the khubd is stuck in usb_set_address() waiting
> > for the URB to complete, but it never finishes because the UHCI driver
> > isn't getting any interrupts.
>
> OHCI could have the same p
I've been trying to find a USB 802.11 wireless device, for use with
Linux. I'm having a little difficulties figuring out which models will
work with standard Linux source, which models require a patch, which
models have binary only modules, and which models require windoze.
If anybody has any goo
I've thought that OHCI could detect this "IRQs are broken"
problem earlier. I suspect UHCI could use the same kind of
fix that came to mind: as the HCD starts, enable an IRQ
for SOF, and wait a couple milliseconds to make sure it
had a chance to arrive. If it came -- continue. Else,
report IRQ
On Mon, Dec 08, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>I've thought that OHCI could detect this "IRQs are broken"
> >>problem earlier. I suspect UHCI could use the same kind of
> >>fix that came to mind: as the HCD starts, enable an IRQ
> >>for SOF, and wait a couple milliseconds
> > I'd expect that Herbert was getting the "Unlink after no-IRQ? ..."
> > message from hcd_unlink_urb() ... I added that a while back, and
I don't get that error because the interrupts stopped working after a
suspend/resume. Since the saw_irq flag isn't reset during a
suspend/resume that message
On Mon, 8 Dec 2003 12:52:30 -0800 "Randy.Dunlap" <[EMAIL PROTECTED]> wrote:
| Customers keep complaining that usb-storage is unusable in 2.4,
| so I looked at it and WOA! Very simple things, like running
| dd if=/dev/sda of=/dev/null bs=8k and then unplugging the
| flash cause oopses and lockups;
How to cancel given URBs (that may be submitted earlier) so that I can be
sure that after a certain point the USB subsystem will not access them
again (to call usb_free_urb())?
The first try would be to call usb_unlink_urb() (synchronously), but this
checks for -EINPROGRESS and fails if the urb st
78 matches
Mail list logo
