> I personally think that drivers need to synchronize such things
> internally. They are the only entity which knows when it's "OK"
> to do whatever the netpoll method does, and they are also the only
> entity which can properly synchronize such checks.
Thanks agreed. I am testing the following i
From: Jonathan Maxwell
Date: Tue, 11 Aug 2015 15:53:18 +1000
>> What if the carrier check passes, and then the chip reset starts on
>> another cpu? You'll have the same problem.
>
> Okay, let me see if I can come up with a better way to mitigate this.
I personally think that drivers need to sy
> What if the carrier check passes, and then the chip reset starts on
> another cpu? You'll have the same problem.
Okay, let me see if I can come up with a better way to mitigate this.
On Tue, Aug 11, 2015 at 2:22 PM, David Miller wrote:
> From: Jon Maxwell
> Date: Tue, 11 Aug 2015 11:32:26 +1
From: Jon Maxwell
Date: Tue, 11 Aug 2015 11:32:26 +1000
> We have seen a few crashes recently where a NIC is getting
> reset for some reason and then the driver or another module calls
> printk() which invokes netconsole. Netconsole then calls the
> adapter specific poll routine via netpoll which
We have seen a few crashes recently where a NIC is getting
reset for some reason and then the driver or another module calls
printk() which invokes netconsole. Netconsole then calls the
adapter specific poll routine via netpoll which crashes because
the adapter is resetting and its structures are
