Messages in this thread |  | | From | (Alan Cox) | Subject | Re: 2.0.27 major problems #1 -- 3c59x driver. | Date | Thu, 13 Feb 1997 21:22:55 +0000 (GMT) |
| |
> A transmitter access conflict will _not_ cause your card to hang. If you > see that message then it means a problem has just been avoided. > > I suspect there is some other cause. I also think the comment about the > queue layer is incorrect - that mutex does come under contention under > high load.
The tac message can only occur when a packet is queued by the queue layer with dev->tbusy=0 and by the time it hits the device driver dev->tbusy=1.
That implies the following occurs
process: do_dev_queue_xmit dev->hard_start_xmit [interrupted]
timer_int: dev_tint() dev->hard_start_xmit [completes]
process .... dev->hard_start_xmit set_bit(dev->tbusy) tac bounce out
That doesn't leave a lot of suspect code around - probably the code that handles the 3c590 TX FIFO bug. There is definitely some suspect code in there because nothing protects an interrupt from interrupting the resetting code.
Possibly there should be a save_flags();cli()....;restore_flags() around the code bracketed by the if(dev->tbusy) in vortex_start_xmit() ?
Alan
|  |