On Thu, 10 Nov 2016, Corinna Vinschen wrote:
On Nov 8 11:33, Alexander Duyck wrote:
...
quoted
The question I would have is what is reading the device when it is in
this state. The watchdog and any other functions that would read the
device should be disabled.
One possibility could be a race between a call to igb_close and the
igb_suspend function. We have seen some of those pop up recently on
ixgbe and it looks like igb has the same bug. We should probably be
using the rtnl_lock to guarantee that netif_device_detach and the call
to __igb_close are completed before igb_close could possibly be called
by the network stack.
Do you have a pointer to the related ixgbe patch, by any chance?
...
quoted
The thing is that a suspended device should not be accessed at all.
If we are accessing it while it is suspended then that is a bug. If
you could throw a WARN_ON call in igb_rd32 to capture where this is
being triggered that might be useful.
quoted
- Otherwise assume it's actually a surprise removal. In theory that
should somehow trigger a device removal sequence, kind of like
calling igb_remove, no?
Well a read of the MMIO region while suspended is more of a surprise
read since there shouldn't be anything going on. We need to isolate
where that read is coming from and fix it.
That would be ideal, but the problem couldn't be reproduced yet apart
from at a customer's customer site. It's not clear yet if we can access
the machine for further testing.
Here's the initial patch for igb I have, but it's on hold awaiting more
changes in ixgbe regarding AER.
--
Hisashi T Fujinaka - htodd@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee