Re: BUG: unable to handle kernel paging request in usb_match_id()

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Fri, Aug 17, 2012 at 10:00:46AM +0800, Fengguang Wu wrote:
> On Sun, Aug 05, 2012 at 09:58:26AM -0700, Greg KH wrote:
> > On Sun, Aug 05, 2012 at 10:59:38AM +0800, Fengguang Wu wrote:
> > > Hi all,
> > > 
> > > This line triggers an oops in kvm boot test:
> > > 
> > > usb_match_id():
> > > ==>      748         for (; id->idVendor || id->idProduct || id->bDeviceClass ||
> > >          749                id->bInterfaceClass || id->driver_info; id++) {
> > >          750                 if (usb_match_one_id(interface, id))
> > >          751                         return id;
> > >          752         }
> > > 
> > > It's an old bug and happens also in linux 3.0. It's very reproducible
> > > for the attached config. I can send the initrd (yocto-minimal-i386.cgz)
> > > on your request in private email.
> > 
> > Odds are a driver without a terminating NULL for the device id list is
> > causing this to fail.
> > 
> > What devices are in the system and what drivers are trying to be bound?
> 
> The last match is for: drivers/usb/misc/emi62.c
> 
> Located down by Tianyu's debug patch:
> 
> [    2.206708] usb_device_match: device 1-1:1.0, driver cytherm
> [    2.207627] usb_device_match: device 1-1:1.0, driver emi62 - firmware loader
> [    2.208769] BUG: unable to handle kernel paging request at c1f7478e
> [    2.209726] IP: [<c14ac1c0>] usb_match_id+0x5b/0xcd
> 
> > --- a/drivers/usb/core/driver.c
> > +++ b/drivers/usb/core/driver.c
> > @@ -778,7 +778,8 @@ static int usb_device_match(struct device *dev, struct device_driver *drv)
> >
> >                 intf = to_usb_interface(dev);
> >                 usb_drv = to_usb_driver(drv);
> > -
> > +
> > +               pr_info("%s: device %s, driver %s \n", dev_name(dev), drv->name);
> >                 id = usb_match_id(intf, usb_drv->id_table);
> >                 if (id)
> >                         return 1;

Odd that it takes so long after you call that function for it to fail.

And that driver has a proper termination, so we aren't walking off the
end of the list, so it must be in the probe function itself.

Care to add some more debugging for that driver?

Also, I don't see the dev_info() message from the driver itself, in the
probe function, so it must not be getting called properly.

Something weird is happening...

greg k-h