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. 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... ;-) Martin ------------------------------------------------------- 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
