Oliver Neukum <oneukum@xxxxxxx> writes:
> On Thursday 24 January 2013 13:47:40 Bjørn Mork wrote:
>> Oliver Neukum <oneukum@xxxxxxx> writes:
>> > On Thursday 24 January 2013 12:22:54 Bjørn Mork wrote:
>> >
>> >> Sorry for being daft, but how do I code the "20 among the last 30" part
>> >> there?
>> >
>> > Just by agreeing that you can live with false negatives but not false positives
>> >
>> > if (++counter > 30) {
>> > counter = bogus = 0;
>> > } else {
>> > if (is_bogus(packet)
>> > bogus++;
>> > if (bogus > counter/2)
>
> Should probably be something like bogus > counter/2 + 10
right
>> > throttle();
>> > }
>>
>> So, add two new counters to struct usbnet for this? That seems a little
>> overkill to me, but I don't see how else to implement anything like that.
>
> Memory is cheap.
OK
>> It is still not completely clear to me how the throttling/unthrottling
>> should be done. It tested with static counters (to avoid having to
>> rebuild everything for this test) and a new EVENT_RX_THROTTLE flag.
>> Still on top of my previous patch just for safety while testing, as I am
>> fed up of having to reboot all the time :-)
>>
>> Doing the flag test in rx_submit seems simpler than trying to track all
>> the places this is called. Still checking the dev->done.qlen to be able
>> to unthrottle.
>
> Ideally we would do some error handling. Does the device keep spewing
> zero packets for all eternity?
Yes. The only way to get rid of the bug once it has triggered seems to
be powering the device off/on. So unthrottling is not important for
this device. But I guess it will be for other devices with more
temporary problems.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
