On Thu, Sep 22, 2016 at 11:02 AM, Oliver Neukum <oneukum@xxxxxxxx> wrote: > On Thu, 2016-09-22 at 10:50 +0300, Binyamin Sharet wrote: >> On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum <oneukum@xxxxxxxx> wrote: >> > On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote: >> >> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley <tvboxspy@xxxxxxxxx> wrote: >> >> > >> >> Malcolm, just to make it clear, this bug was not found with an >> >> actual device, but with emulation. >> > >> > It was quite peculiar a bug, though. Could you prepare a test kernel >> > without BPF? >> > >> > Regards >> > Oliver >> > >> > >> >> Oliver, >> >> If this question was directed to me, I will need some clarification >> of what is needed (and also - what's BPF?) > > BPF = Berkeley Packet Filter (a mechanism to filter packets going over a > socket) > > The oops you reproduced was in the BPF. That is rather generic code > without connection to the driver in question. That raises the question > whether you've accidentally triggered a generic bug. > To rule that out a rerun on a kernel compiled without CONFIG_BPF would > be useful. Or you could build an initrd with the BPF modules > blacklisted, so we are sure the test system does not use BPF. > > Regards > Oliver > > > Thanks Oliver, will do. -- Binyamin -- 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
