On Fri, May 28, 2004 at 12:29:33AM +0200, Martin Diehl wrote:
> On Thu, 27 May 2004, Pete Zaitcev wrote:
>
> > On Thu, 27 May 2004 03:00:30 -0700
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > This is 2.4.26, sleeping in a timer handler.
> > >[...]
> > > Trace; c0112b2b <schedule_timeout+73/94>
> > > Trace; c0112a70 <process_timeout+0/48>
> > > Trace; c2801219 <[usbcore]usb_start_wait_urb+d5/17c>
> > > Trace; c2801321 <[usbcore]usb_internal_control_msg+61/74>
> > > Trace; c28013a4 <[usbcore]usb_control_msg+70/8c>
> > > Trace; c281f121 <[pl2303]set_control_lines+35/64>
> > > Trace; c2820039 <[pl2303]set_modem_info+ed/100>
> > > Trace; c2820260 <[pl2303]pl2303_ioctl+c0/120>
> > > Trace; c2819a70 <[usbserial]serial_ioctl+e4/108>
> > > Trace; c2845fcf <[irlan]irlan_close_data_channel+e3/118>
> > > Trace; c2848394 <[irlan]irlan_client_get_value_confirm+e8/104>
> > > Trace; c2833c77 <[irda]irda_task_kick+73/14c>
> > > Trace; c2833de4 <[irda]irda_task_timer_expired+0/2c>
> > > Trace; c2833e0b <[irda]irda_task_timer_expired+27/2c>
> > > Trace; c011c3f8 <timer_bh+278/388>
> > > Trace; c011942c <bh_action+1c/48>
> > > Trace; c0119359 <tasklet_hi_action+49/70>
> > > Trace; c011913c <do_softirq+4c/a0>
> > > Trace; c0108141 <do_IRQ+c5/d4>
> >
> > I don't think I'm at fault here. There's just no guarantee that ioctls
> > won't block. Jean has to do something about it, perhaps not closing
> > from timers and use irattach instead (just like slattach was used
> > in ancient UNIX).
>
> In this particular case where the path leads to ioctl you are right of
> course. However there are a lot more similar issues with this setup - f.e.
> tty_driver->write_room used to take a semaphore in usbserial. This is
> probably fixed with your recent changes but in 2.4 there are also issues
> with irtty sitting between netdev (txlock) and tty (BKL). So as pointed
> out by Jean, the situation with irda over usbserial is basically
> unsupported (read: unfixable) with 2.4. People should use 2.6 then.
By the way, I need to clear up a misconception. Serial speed
is not changed at irattach time. Speed is changed automatically by the
IrDA stack a various point in time. So, the slattach analogy is
pointless.
> Btw, Jean, I found this backtrace looks pretty suspicous because there's
> no way for irlan directly calling usbserial_ioctl without all the
> irttp+irlmp+irlap+irtty stuff between. It doesn't really matter, but I was
> wondering why irlan_close_data_channel wants to set modem lines in the
> first place - my understanding was this should be session layer operation
> just going over existing transport. But maybe this was also disconnecting
> the lap as a side effect. Anyway, no need to repeat your usual comment
> about irlan state... ;-)
And there is also no way irda_task_kick is going to call
IrLAN. Think about it, IrLAN is not using irda_task at
all. Furthermore, irlan_client_get_value_confirm() never calls
irlan_close_data_channel(), it does not make sense.
It's not the first time I see that happening, so that's why
I'm a bit cautious about saying that is what really happened. It looks
like the trace got the wrong module, I would expect irtty_change_speed
and __irtty_change_speed to be there.
Unfortunately, we can't always blam IrLAN ;-)
> Martin
Have fun...
Jean
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
