On Tue, 16 May 2000, Petko Manolov wrote:
> Which kernel you're using? This happen often with older kernels and
> slow hardware.
2.3.99-pre7-pre7 with reiser 3.6.5, and 2.3.99-pre9.1 with classzone 28
and reiser 3.6.5.
(did try with -pre9.2 without classzone 28, for other reasons, same
problems.)
> This is because of kernel panic when i try to touch the hardware once
> the device is up and running. This should be fixed and i'll do this in
> the
> next driver release. I think i should play with the control URBs.
> > In order to compensate for this, I've modified pegasus.c to add a
> > kpegasusd daemon (ugh!), and experimented in that thread. For now, I nlink
>
> 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.
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).
> > 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 ?
-- Cyrille
------------------------------------------------------------------------------
Grumpf.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
