Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
Ben Hutchings <ben@decadent.org.uk> writes:
> On Mon, 2016-04-11 at 09:55 +0200, Bjørn Mork wrote:
>> Ben Hutchings <ben@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 to: