"Cyrille Chepelov (home)" wrote:
>
> On Tue, 16 May 2000, Petko Manolov wrote:
>
> > No, don't do this. If every network driver have kernel daemon to
> > restart itself... ;-)
>
> thus the (ugh!) :-)
>
> More seriously, it seems that most usb_* calls can't be used from
> interrupt context. Most sadly, we can't cancel urbs from interrupt
> context, since usb_cancel_urb() calls schedule(). Argh. So after learning
> the hard way than bh, tq and tasklets were different instance of rougly
> the same beast (from my point of view), with the property of having
> is_interrupt() returning !0, I figured out the only way I had within reach
> of my kernel skill set to do non-interrupt-kosher stuff was to do it in a
> thread.
This is mostly right, but i had problems even when call set_rx_mode()
which
is top half (with process context). My screen went wild of registers
dumps,
then lock hard (sysrq can't help).
The problem is that usb_control_msg() calls usb_start_wait_urb() which
calls add_wait_queue() which is legal only if we have process context.
> And, hey, having a working kpegasusd allows you to use top to see how bad
> the device works :-)
>
> (I'd really prefer it working without problems).
Me too ;-))
> > > I'm going to experiment further, by doing things like calling
> > > pegasus_reset_mac and pegasus_start_net in kpegasusd, but before I do
> > > that, I wanted to know whether someone has better ideas...
> >
> > I don't think this will work, but who knows... Anyway, i am curious
> > to hear about the results.
>
> Will report about that tomorrow.
>
> Are you currently doing anything (or planning to do) on EndPoint 3 ? I
> never saw anything printed from pegasus_irq's printk, but I need to check
> whether it ever gets called with urb->status==0. That would also allow for
> nicer error reporting... Besides, the spec is a bit mute about the chip's
> behaviour when its txfifo_full is set and no one reads it. Maybe this is
> the key of our problems ?
May be, and for now i think that only reseting MAC will do the job.
I'll use interrupt pipe when i start implementing PM stuff. Until now i
get RX/TX status at the end of the each rx/tx packet so i don't need
the status i can get from interrupt pipe.
best,
Petkan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]