Oliver Neukum <[email protected]> writes: > On Thursday 24 January 2013 13:47:40 Bjørn Mork wrote: >> Oliver Neukum <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
