On Maw, 2004-09-28 at 16:46, Sam King wrote:
> serial_unthrottle is not an issue because it is called as the result
> of system calls, where as serial_throttle is called when the tty
> driver buffer is full. As we have seen, calls to serial_throttle can
> occur from an interrupt handler when the d
Hi Pete,
> > I found a bug where the io_ti.c driver calls schedule while in an
> > interrupt. The problem stems from usbserial.c allowing a
> > serial_throttle call proceed while in an interrupt, which results in
> > sending a urb to clear the CTS bit of the usb serial port, and thus a
> > call t
Hi Pete,
Below is an updated patch with the proper spacing (I hope). It should
address the semaphore down issue brought up by Al and it will provide
a fix for the io_ti.c driver until Al's version is merged in.
Should I provide a patch against 2.4.27 instead of the 2.4.21-20.EL
version I am usin
On Mon, Sep 20, 2004 at 03:39:19AM -0500, Al Borchers wrote:
> The problem that Sam found is that throttle can be called in interrupts,
> and io_ti throttle calls usb_control_msg to drop RTS, but that sleeps.
>
> However, it is simply not necessary for io_ti throttle to explicitly
> drop RTS. The
Hi Al,
> Another potential problem is that usbserial throttle can also sleep
> when it calls down(). You will have to fix that some other way.
My previous patch should take care of this for the 2.4 version of
usbserial.c, that is part of the reason I implemented the fix there
rather than in io_t
Pete Zaitcev wrote:
Al Borchers did explain why sending X-OFF in the driver was
appropriate once upon a time.
I don't remember talking about this and couldn't find it in a
quick google--can you point me to it?
but perhaps you would wish to preserve that technique after you
examined his message in t
On Tue, 14 Sep 2004 14:36:57 -0400 (EDT)
Sam King <[EMAIL PROTECTED]> wrote:
> Here is an updated patch that should work. It is similar to the
> previous patch except for a one line mistake correction from my
> previous post. [...]
It's a more or less ok patch, except that you disregarded my
req
Hi Pete,
That is an interesting point. I am far from a usb serial expert, but
it looks like this is not a problem because usbserial.c already
handles writes that might happen during an interrupt. Would a better
solution to the original bug be to queue serial_read calls rather than
the serial_thr
On Tue, 14 Sep 2004 10:58:48 -0400 (EDT)
Sam King <[EMAIL PROTECTED]> wrote:
> I found a bug where the io_ti.c driver calls schedule while in an
> interrupt. The problem stems from usbserial.c allowing a
> serial_throttle call proceed while in an interrupt, which results in
> sending a urb to cle
Sam King wrote:
I found a bug where the io_ti.c driver calls schedule while in an
interrupt. The problem stems from usbserial.c allowing a
serial_throttle call proceed while in an interrupt, which results in
sending a urb to clear the CTS bit of the usb serial port, and thus a
call to schedule.
Th
Here is an updated patch that should work. It is similar to the
previous patch except for a one line mistake correction from my
previous post.
--Sam
-
Sam King
Ph.D. Student
Computer Science Department
University of Michigan, Ann Arbor
--- /usr/src/linux-2.4/driv
After looking more into the problem, it appears that my previous patch
did not actually fix the problem. I will post again when I have a new
patch, any ideas are welcome.
--Sam
-
Sam King
Ph.D. Student
Computer Science Department
University of Michigan, Ann Arbor
Hello,
I found a bug where the io_ti.c driver calls schedule while in an
interrupt. The problem stems from usbserial.c allowing a
serial_throttle call proceed while in an interrupt, which results in
sending a urb to clear the CTS bit of the usb serial port, and thus a
call to schedule.
To work a
13 matches
Mail list logo
