On Tue, 24 Jun 2003, Tomek Grzejszczyk wrote: > I'am trying to write driver for STIR4200 usb-irda bridge controller. I'am > not writing it from scratch but rather modify current irda-usb driver > from 2.4.20 kernel. Right now I'am testing what I've written but I've
I'm not sure whether this would be the best approach. From looking across the stir4200 datasheet I'm pretty sure it's completely different from irda-usb class. So I think all you can keep from irda-usb is some network and usb skeleton which might even be a sub-optimal thing to start from for this device - but it's your decision of course. The second thing I'd suggest is using the very latest 2.4 kernel, probably 2.4.22-pre2, in order to get all the recent important irda and usb fixes. Or maybe even better 2.5. > stucked. I get kernel panic and have no idea and little experience what > to do next. Its reproducable and looks like this: > > ---------------------- > Scheduling in interrupt > Bug at sched.c: 566! Ok, that one is easy: you are calling some sleeping function from interrupt context which is a bad idea (tm). > invalid operand: 0000 > CPU: 0 > EIP: 0010 [<c01acda9>] Not tainted > EFLAGS: 0010286 > Registers:... > Process swapper(pid:0, stacpage=c0143000) > Stack: ... > Call Trace: ... To identify where you call the culprit please get this call trace (you might want to use a serial terminal) and run it through ksymoops. > Code: ... > <0> Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing > ----------------------- > > The procedure is: > modprobe stir4200 (my module) > ifconfig irda0 up > irattach irda0 -s (no ir devices in range) > wait a while (1s) > > The line number in the beginning of panic message is 566 in 2.4.20-8 and > 564 in 2.4.21 kernel. I suspected I do something wrong in my driver so > I've gradually cut its functionality. Now it: > -responds to probe call from usb layer > -registers the new network device and responses to calls from network > layer to net_init and net_open (without much modification from irda-ubb > driver) > -calls netif_stop_queue in what once was irda_usb_hard_xmit and returns 0 > (nothing more) > -waits for network timeout and sometimes gets there but sometimes panic > is quicker Since you are not doing very much so far I think it might be the network timeout handler. It is called from a context where you can't sleep so my guesses are you are doing something bad there. But without looking at both the code and the calltrace it's just speculation. > It looks strange to me because now when my driver does nothing there is > small probability it would do something wrong. Especially when it does > nothing more the irda-usb driver would do. Now I'am out of ideas what I > can do more to fix the situation. Any suggestions are welcome. Have you seen the experimental driver for the stir4200 at Jeans Homepage? Maybe you could start with this one or cooperate with the other author to avoid having to start all over? Martin PS: I've added Jean and the irda-users to CC because you send another request there and I think the thread would be more appropriate there. ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
