Hi David, On Sep 7 17:00, David Miller wrote: > From: Corinna Vinschen <vinsc...@redhat.com> > Date: Mon, 7 Sep 2015 11:29:49 +0200 > > > Still wondering though. Given that the driver never failed before if > > the counter values couldn't be updated, and given that these counter > > values only have statistical relevance, why should this suddenly result > > in a fatal failure at open time? > > Failing to allocate such a small buffer means we have much deeper issues > at hand. A GFP_KERNEL allocation of this size really should not fail.
I'm not talking about the allocation. I agree with you on that score. What I'm talking about is the situation where the NIC hardware fails to reset or update its own counters for whatever reason. Apparently the mechanism is supposed to be performed within a given timeframe. The code sets some registers and then waits for a flag bit to be set to 0. For that it utilizes a busy loop checking the flag bit up to 1000 times with a delay of about 10 us. The error condition is that the flag bit hasn't been set to 0 when the loop exits, after roughly 10ms, and *this* part does not constitute a fatal error which breaks the operation of the NIC. So, from my perspective a timeout while trying to wait for updated counter values from the NIC at @ndo_open time should not be treated as fatal. Corinna
pgpk7BRl5wT6Y.pgp
Description: PGP signature
