Ben Hutchings <b...@decadent.org.uk> writes:
> On Mon, 2016-04-11 at 09:55 +0200, Bjørn Mork wrote:
>> Ben Hutchings <b...@decadent.org.uk> writes:
>> > 
>> > On Sun, 2016-04-10 at 11:15 -0700, Vagrant Cascadian wrote:
>> > > 
>> > > It works for the most part, but floods syslog with messages:
>> > > 
>> > > [501966.870273] net_ratelimit: 35702 callbacks suppressed
>> > > [501966.875438] smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
>> > > 
>> > > It seems to function ok, though I'm not sure if there's degraded
>> > > network performance...
>> > [...]
>> > 
>> > I understand network performance on all RPi models is poor due to lack
>> > of a built-in Ethernet MAC and the poor design of the USB interface.
>> > Also that message is a generic error message from the usbnet core and
>> > is not specific to the smsc95xx driver.
>> Yes, kevent 2 is "EVENT_RX_MEMORY", and this error affects any usbnet
>> based device under memory pressure.  The usbnet framework just doesn't
>> handle the case where GFP_KERNEL allocations fail. How could it? 
>
> What I don't understand, given this, is why Vagrant didn't report any
> OOM warnings.  (I wondered whether the __GFP_NOWARN flag was wrongly
> being added somewhere, but I don't see that.)

Maybe I'm wrong?  Looking at this again, I notice that rx_submit()
always will call usb_submit_urb(urb, GFP_ATOMIC) regardless of the input
mem_flags, because it's holding a spinlock when submitting the urb.  So
it doesn't necessarily help much that the urb and skb are allocated with
GFP_KERNEL.

Exactly what allocations usb_submit_urb() may end up with seems to be
depending on the host controller. So the error spam could very well be
caused by a problematic host controller.  At least partly.

>> The only viable "fix" I can see is by preallocating and recycling all
>> buffers instead of the repeated allocations done by usbnet now.  But
>> that's a major refactoring of usbnet.
>> 
>> The log message spam could of course be fixed, but the rate-limiting is
>> "good enough".
>
> How is anyone supposed to know what "kevent 2" is though?

By looking it up in include/linux/usb/usbnet.h :)

Yes, that could certainly be improved by translating the number back to
a readable description.  

> The drivers that support batching into large RX buffers should
> automatically fall back to smaller buffers if this happens, or whenever
> they're running on a small (for some definition of small) machine.  I
> understand that the dynamic fallback may be tricky though.

I don't think the smsc95xx use any large buffers.  Looks like it's an
ethernet packet + 12 bytes.  And usbnet limits the total rx queue to
60 * 1518 bytes.


Bjørn

Reply via email to