Andrew Morton wrote:
Jeff Garzik <jgarzik@pobox.com> wrote:All you have to do is ask. I apologize, I thought the comments were sufficiently specific
Andrew Morton wrote:
Neil Horman <nhorman@redhat.com> wrote:unsufficient for what?
and it fixes the oops that olympic driver encounters when it gets a lobe fault.
I've tested it, with good results.
The above is relevant, but is quite insufficient.
- What oops does it fix?
- How does it fix it?
For me? The patch makes a significant number of unrelated and non-trivial changes and they are wholly undescribed.
Apart from the time wastage, this practise results in lower code quality. We want to hear what the programmer thinks the patch does so we're in a
better position to confirm that it does indeed do that.
It fixes an oops that results when a lobe fault is detected. The oops occurs because a lobe fault triggers an interrupt which is handled in the current version of the driver by effectively shutting down the card, and freeing its requisite irq. The former is fine, the latter is not, as its illegal to free an irq from within an interrupt context. I've fixed this bug by removing the call to free_irq from the interrupt handler (specifically the chunk around line 964 fixes that). While I was in there I noticed that there were several other conditions in the interrupt handler that contained the same condition, so I made the same fix there. I re-added. I also modified the contents of olympic_freemem (the chunk around line 898 to correct a misuse of a pointer after it requisite memory has been free in the case the the adapter is re-initalized after a fault to prevent that oops. And then I clean up the interrupt handler to simply use olympic_freemem from the close routine since the ring buffer doesn't need to be freed until the driver is closed. In addition to these changes I added a call to olympic init in olympic_open and reset the spinlock so the adapter can be reset and rejoin the ring without needing to rmmod/insmod the module. Lastly I cleaned up the wait queue code so that the close routine didn't have to wait 60 seconds to close the adapter if a fatal fault has closed the adapter.
Let me know if you need anything else
BTW, while were talking about it, was description in my vlan tag patch for the ns83820 enough, or should I add more there as well?
Neil
-- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. *nhorman@redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html