Hi,
when connecting an Digi Acceleport adapter to my Alpha, i get a warning in
the dmesg. minicom works (at least until you try to change communication
parameters), but when exiting, it will hang unkillable in "D" state.
Earlier kernels had serious issues with the OHCI host adapter being used
her
On Friday 10 January 2003 00:28, Oliver Neukum wrote:
> > static void __exit udsl_usb_cleanup (void)
> > {
> > - /* killing threads */
> > - udsl_atm_sar_stop ();
> > usb_deregister (&udsl_usb_driver);
>
> Not quite. You need to make sure that no tasklet is running.
Hi Oliver, thanks for
Am Freitag, 10. Januar 2003 11:29 schrieb Duncan Sands:
> On Friday 10 January 2003 00:28, Oliver Neukum wrote:
> > > static void __exit udsl_usb_cleanup (void)
> > > {
> > > - /* killing threads */
> > > - udsl_atm_sar_stop ();
> > > usb_deregister (&udsl_usb_driver);
> >
> > Not quite. You ne
On Friday 10 January 2003 12:01, Oliver Neukum wrote:
> > Hi Oliver, thanks for looking the patch over. I thought about this issue
> > and came to the conclusion that the tasklet cannot be running. The
> > reason is as follows: the tasklet is only scheduled in the completion
> > handler udsl_usb_
speedtouch: struct sk_buff_head has a spinlock built in, so no need for our own.
speedtouch.c | 50 +++---
1 files changed, 11 insertions(+), 39 deletions(-)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/
Hi,
On Thu, Jan 09, 2003 at 03:50:55PM -0800, Greg KH wrote:
> On Thu, Jan 09, 2003 at 11:56:22PM +0100, Henning Meier-Geinitz wrote:
> > Hi,
> >
> > On Thu, Jan 09, 2003 at 11:26:47PM +0100, Henning Meier-Geinitz wrote:
> > > As the kernel scanner driver doesn't call any function that resets the
> I am afraid I do not agree. Your reasoning is correct only on UP.
> If the code in question runs on another CPU, you are in trouble.
It all depends on the semantics of usb_unlink_urb. Consider the
patch below. Is this any better? Maybe not: if usb_unlink_urb
returns before the completion hand
Title: »çÀºÇà»ç
Am Freitag, 10. Januar 2003 13:21 schrieb Duncan Sands:
> > I am afraid I do not agree. Your reasoning is correct only on UP.
> > If the code in question runs on another CPU, you are in trouble.
>
> It all depends on the semantics of usb_unlink_urb. Consider the
> patch below. Is this any better?
On Friday 10 January 2003 14:55, Oliver Neukum wrote:
> Am Freitag, 10. Januar 2003 13:21 schrieb Duncan Sands:
> > > I am afraid I do not agree. Your reasoning is correct only on UP.
> > > If the code in question runs on another CPU, you are in trouble.
> >
> > It all depends on the semantics of u
Last year I wrote half a dozen drivers for various USB card readers.
Some don't work anymore with 2.5.recent.
I just investigated one. The reason it stopped working is the
sd_read_cache_type()
call added in 2.5.41. (With that call removed it works again.)
Will look a bit more at the details late
[EMAIL PROTECTED] said:
> Will look a bit more at the details later. For now a question: this
> call does a MODE_SENSE with the DBD (disable block descriptors) bit
> set. Is there a reason for that? Wouldn't the same code work in the
> same way without that bit?
The reason was just least line of
On Fri, Jan 10, 2003 at 09:05:06AM +0100, Jochen Friedrich wrote:
>
> device class tty: adding driver usb-serial:Digi USB
> drivers/usb/serial/usb-serial.c: USB Serial support registered for Digi USB
> Badness in kobject_register at lib/kobject.c:129
> fc0025e6fe28 0004 fc8
On Fri, Jan 10, 2003 at 09:35:20AM -0800, Greg KH wrote:
>
> Hm, I just duplicated this here on my box, by loading the driver, I'll
> take a look at it...
Ah, I forgot to change the .name fields on this driver, sorry. Here's a
patch that fixes the problem for me, please let me know if it works f
Hi,
I have tried my high-speed iso driver under 2.5.52 and 54, and it
doesn't work. The completion routine gets called, but no data arriving.
Fields of completed urb are: status: 0, error_count: 0. When I submit
completed urb again (in completion routine), system hangs and urbs are
submited fo
Hi,
this is the first one. Basically GFP_ATOMIC in interrupt and proper error
handling in write. This is the simple stuff to motivate myself.
Greg, please apply.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to r
Hi,
this fixes the read method by use of a temporary buffer.
This needs testing.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
Title: ´ç÷Ȯ·ü 100¹è up, °¡°Ý ÃÖ´ë 45% DOWN. ¹é¯º¹±Ç ź»ý!!!
Hi Greg,
> Ah, I forgot to change the .name fields on this driver, sorry. Here's a
> patch that fixes the problem for me, please let me know if it works for
> you or not.
Thanks! This fixed the oops message.
However, the hang on close still remains:
Last message from debug=1:
drivers/usb/se
On Fri, Jan 10, 2003 at 08:59:45PM +0100, Jochen Friedrich wrote:
> Hi Greg,
>
> > Ah, I forgot to change the .name fields on this driver, sorry. Here's a
> > patch that fixes the problem for me, please let me know if it works for
> > you or not.
>
> Thanks! This fixed the oops message.
Great,
Hi Greg,
> Bleah. What really needs to happen is to convert to using the serial
> core, which should fix a lot of things. The main thing holding that
> back is just time, I don't have it right now :(
For now, i fixed the problem by disabling the tty_wait_until_sent stuff:
= digi_acceleport
RE: cache
Yes, at least a synchronize, but can we always know (in time) if the medium
has been removed? We may not always get an eject request, right?
I think write-back cache is inherently unsafe in general, but I guess we
have to allow unsafe things like that for non-production use.
Andy
Hi Oliver, I decided to see how other drivers deal with this usb_unlink_urb
issue. The first thing I looked was devio.c. And guess what, it looks like
it assumes that the completion handler has completed by the time
usb_unlink_urb finishes:
static void destroy_async (struct dev_state *ps, struct
Am Freitag, 10. Januar 2003 22:16 schrieb Duncan Sands:
> Hi Oliver, I decided to see how other drivers deal with this usb_unlink_urb
> issue. The first thing I looked was devio.c. And guess what, it looks
> like it assumes that the completion handler has completed by the time
> usb_unlink_urb fi
Hi,
this is the obvious fix. Greg, please apply.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
===
Hi,
the counter has to decremented if the URB cannot be submitted.
Greg, please apply.
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
=
On Fri, Jan 10, 2003 at 11:10:58PM +0100, Oliver Neukum wrote:
>
> That are good, or bad depending on viewpoint.
> IIRC we had this discussion already, possibly several times. Has the general
> consensus changed ? It seems that the old objections about freeing the
> URB from the completion handler
On Fri, Jan 10, 2003 at 09:30:22PM +0100, Jochen Friedrich wrote:
> Hi Greg,
>
> > Bleah. What really needs to happen is to convert to using the serial
> > core, which should fix a lot of things. The main thing holding that
> > back is just time, I don't have it right now :(
>
> For now, i fixe
Oliver Neukum wrote:
Am Freitag, 10. Januar 2003 22:16 schrieb Duncan Sands:
Hi Oliver, I decided to see how other drivers deal with this usb_unlink_urb
issue. The first thing I looked was devio.c. And guess what, it looks
like it assumes that the completion handler has completed by the time
u
Hello
Does anyone knows wether the usb2xchange Adapter from Adaptec works
with linux ( maybe with storage driver ) ?
Or is somebody using it already ?
Thanks
Henning
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM
Am Samstag, 11. Januar 2003 00:02 schrieb Greg KH:
> On Fri, Jan 10, 2003 at 11:10:58PM +0100, Oliver Neukum wrote:
> > That are good, or bad depending on viewpoint.
> > IIRC we had this discussion already, possibly several times. Has the
> > general consensus changed ? It seems that the old object
Michal Sojka wrote:
Hi,
I have tried my high-speed iso driver under 2.5.52 and 54, and it
doesn't work. The completion routine gets called, but no data arriving.
Fields of completed urb are: status: 0, error_count: 0. When I submit
And urb->iso_frame_desc[i].{status,actual_length} = ... ?
Re
> Unlinking is tricky, and my understanding of the current rules are:
>
> - For a successful synchronous unlink, the completion handler did fire
>before the unlink call returned. Easily proven for HCDs that go through
>the "hcd.c" logic (*), otherwise you have to take it on faith. (And
>
Oliver Neukum wrote:
Now for something related.
From usb_submit_urb():
if (!(op = dev->bus->op) || !op->submit_urb)
return -ENODEV;
urb->status = -EINPROGRESS;
<--- here begins the window
urb->actual_length = 0;
urb->bandwidth = 0;
What happens if usb_unlink_urb() is called right th
From: "Jochen Friedrich" <[EMAIL PROTECTED]>
> For now, i fixed the problem by disabling the tty_wait_until_sent stuff:
Teach me to read the whole thread first. :-)
..Stu
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition
From: "Jochen Friedrich" <[EMAIL PROTECTED]>
> serial_close downs &port->sem, then calls digi_close.
> digi_close calls tty_wait_until_sent.
> tty_wait_until_sent calls serial_chars_in_buffer.
> serial_chars_in_buffer tries to down &port->sem again, and here it hangs.
I reported this one a while a
Hi,
this code from hcd.c:
retval = hcd->driver->urb_dequeue (hcd, urb);
/* hcds shouldn't really fail these calls, but... */
if (retval) {
dev_dbg (sys, "dequeue %p --> %d\n", urb, retval);
if (!(urb-
Oliver Neukum wrote:
retval = hcd->driver->urb_dequeue (hcd, urb);
/* hcds shouldn't really fail these calls, but... */
if (retval) {
...
}
is deeply racy. It can change the context under a running completion handler.
I'd suggest that you declare urb_dequeue void and remove it.
May
38 matches
Mail list logo
