Messages in this thread | | | Date | Thu, 28 Jan 1999 03:08:31 -0600 (CST) | From | Shaun Wilson <> | Subject | Re: plip.c and transmit timeout madness |
| |
> > HS_TIMEOUT is the result of rebalancing enable/disable_irq() > stuff. When somebody (Andrea?) changed enable/disable_irq() semantics old > PLIP code broke. These days disable_irq();disable_irq();enable_irq(); > leaves IRQ *disabled*, not enabled as it used to do. Now, we need to > have equal amounts of eanble_irq() and disable_irq() on every loop. If
I see. I don't know teh status bits being read from the port:
c0 = inb(PAR_STATUS(dev)); if (c0 & 0x08) {
teh disable_irq() in that if block could be moved beyond teh second if block, that would remove the need to re enable_irq before return OK; in that mentioned if block.
If that is not a good thing then notice the break; That will put you outside of your while() block and back into the flow of the function with irq disabled. from there I count 3 places the function can exit with irq disabled. Whether or not it's changed. you could add enable_irq calls to all of those, but you're not 100% sure that irq is disabled either :) which may not be a good thing since when you get all the way down to case PLIP_PK_DONE: you'll find you have an enable_irq() call again. This would set the irq_desc[irq].depth count either properly or 'off by +one'
Of cours ethe current disable_irq() wouldn't catch that, it only checks that you're not off by -1.
Maybe since that function is teh problem area you should ensure at all return points that irq is eiterh enabled or diabled. We know that the state of irq is enabled at func entry (isn't it?) so why not keep a boolean value in that function to tell us when we should make sure this function ends with irq enabled rather than trying to build a catch-all case in another function that serves another purpose altogether.
And I don't intend to debate, I'm just attempting to help, since this will be running on my machine and I actually give a hoot how it's working.
Hmm. I'm goign to recompile plip.c from 2.1.125 and see how it would act without your fix, I think that might be what I'm still seeing, teh function can still return OK with irq disabled. (why the heck is he disabling it though?)
> Look for my posting on l-k ([PATCH] plip breakage (2.2.0-pre1)) > and comments in drivers/net/plip.c (line 382) for details. > Be *very* accurate with irq stuff - rules had been changed here.
This is what I get for going to California for a month. *sigh*
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |