netdev
[Top] [All Lists]

Re: [vortex] can't unload module

To: David Fries <dfries@xxxxxxx>
Subject: Re: [vortex] can't unload module
From: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Sun, 24 Sep 2000 23:37:52 +1100
Cc: vortex@xxxxxxxxx, netdev@xxxxxxxxxxx
References: <20000921002752.A10927@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <39CB524E.2EB250E0@xxxxxxxxxx>, <39CB524E.2EB250E0@xxxxxxxxxx>; <20000922153900.A24813@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <39CCA283.74E63C9A@xxxxxxxxxx>, <39CCA283.74E63C9A@xxxxxxxxxx>; from andrewm@xxxxxxxxxx on Sat, Sep 23, 2000 at 11:30:59PM +1100 <20000924004617.A18466@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
David Fries wrote:
> 
> I've included my latest patch.

It's possible that the NIC is getting into the upload-stalled state when
it shouldn't. So the "unneeded"

        outw(UpUnstall, ioaddr + EL3_CMD);

is bringing it back to life.  This could be caused by incorrect data
transferred during a bus mastering read.  You could try putting the
above statement into somewhere like boomerang_start_xmit() to give it a
kick occasionally. <subliminal_message>New
motherboard</subliminal_message>.

You can test the upStalled state of the NIC in bit 13 of `inl(ioaddr +
UpPktStatus)'

> /* it doesn't like this
> entry--;
> vp->cur_rx--;
> */

That will sometimes cause `entry' to take the value -1.  Your kernel
will be destroyed secretly and fatally.

> I would assume that would mean motherboard or network card that gets
> along with the motherboard.

Yup.

David, I suggest we cut the Cc:'s from now on - it looks like were not
making progress on the unregister_netdevice problem.

<Prev in Thread] Current Thread [Next in Thread>