| 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@d-131-151-189-65.dynamic.umr.edu> <39CB524E.2EB250E0@uow.edu.au>, <39CB524E.2EB250E0@uow.edu.au>; <20000922153900.A24813@d-131-151-189-65.dynamic.umr.edu> <39CCA283.74E63C9A@uow.edu.au>, <39CCA283.74E63C9A@uow.edu.au>; from andrewm@uow.edu.au on Sat, Sep 23, 2000 at 11:30:59PM +1100 <20000924004617.A18466@d-131-151-189-65.dynamic.umr.edu> |
| 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> |
|---|---|---|
| ||
| Previous by Date: | scope id question, Arkadiusz Miskiewicz |
|---|---|
| Next by Date: | Archives of the Linux netdev mailing list, Andrew Morton |
| Previous by Thread: | Re: [vortex] can't unload module, David Fries |
| Next by Thread: | scope id question, Arkadiusz Miskiewicz |
| Indexes: | [Date] [Thread] [Top] [All Lists] |