On Tue, 20 Mar 2012, Stojsavljevic, Zoran wrote: > > > Greg, > > > > > > I looked into the fs/sysfs/file.c, this was the obvious thing to do. > > > > > > But the BUG_ON macro there does not say to me anything meaningful: > > > > > > BUG_ON(!kobj || !kobj->sd || !attr); in sysfs_create_file(). > > > > You could add a printk at that point to see which of the three things is equal to NULL. > > > > Alan Stern > > Applied your advice (BTW, the NULL pointer case should be incorporated in BUG_ON macro, don't you think). I don't know what you mean. The BUG_ON already tests for three possible NULL pointers. > Very strange things are happening. Here is part of System.map (the closest region): > > c17a4fb8 d dev_attr_a_hnp_support > c17a4fc8 d dev_attr_a_alt_hnp_support > c17a4fe0 d udc_driver > c17a5040 d memory > c17a5360 d max_udc_ops > c17a53a0 d max_ep_ops > c17a53e0 d max_device > c17a54d0 d max_resources > c17a5500 d serio_bus > c17a5538 d serio_event_list > > The break/oooops occurs at: > kobj=0xc17a506c, kobj->sd = NULL, attr = 0xf817a914 > It is referenced somewhere in the memory. > The closest address from kernel symbol table is memory: 0xc17a5040 > > Some pointer went dangling around (with address udc_driver), probably!? It looks like your UDC's probe routine forgot to call device_register(&gadget->dev) before passing the gadget structure to usb_add_gadget_udc(). Can you post the source to your probe routine? Alan Stern -- 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
