Hi Alan, > What was wrong with the registration logic and how did it crash your > kernel? In your patch I see two changes:
The driver registration logic was producing the kernel to get NULL pointer references. > You moved the code that registers the LUN devices into > fsg_bind(). This change looks correct; although there is > a comment stating that the gadget doesn't get registered > until after fsg_bind() returns, that comment is wrong. My guest is that the code may have race conditions if the registration is done on the init function instead of fsg_bind. We probably have a hardware configuration that was the first on trigger the race condition. This change avoid the race condition option, and also makes the code a bit smaller. > You added this line: > gadget->dev.driver = &fsg_driver.driver; > That is both wrong and unnecessary; it's the controller > driver's responsibility to change gadget->dev, not the > gadget driver's responsibility. The gadget driver is not > supposed to touch anything inside the struct usb_gadget. I don't know quite good who is suppose to touch what yet... If you remove that line and try to load the g_file_storage without parameters it give us: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c1cec000 [00000000] *pgd=02bfb011, *pte=00000000, *ppte=00000000 Internal error: Oops: 7 [#1] CPU: 0 pc : [<bf00a5e4>] lr : [<c00a8ff8>] Tainted: P sp : c17d5f20 ip : c17d5f08 fp : c17d5f50 r10: 00000000 r9 : c1bec000 r8 : bf0022f4 r7 : 000000bc r6 : c019dd64 r5 : c019dd40 r4 : 00000000 r3 : 00000000 r2 : bf00234c r1 : 00000013 r0 : bf0083e8 Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user Control: 5317F Table: 02CEC000 DAC: 00000015 Process insmod (pid: 37, stack limit = 0xc17d40fc) Stack: (0xc17d5f20 to 0xc17d6000) 5f20: 00000000 bf0022d8 c1bec000 bf0022d8 00000000 c0120f64 c001a8e4 c17d4000 5f40: 00000002 c17d5f6c c17d5f54 bf001af4 bf00a0e0 c1bec000 00000000 00000000 5f60: c17d5f84 c17d5f70 bf00a798 bf001a80 c0120f7c bf0086a0 c17d5fa4 c17d5f88 5f80: c003c9d0 bf00a770 00000003 00000000 00000100 00000080 00000000 c17d5fa8 5fa0: c001a760 c003c844 00000000 00000100 00900080 40067000 00009088 0004a4d0 5fc0: 00000003 00000000 00000100 befffe84 0004a500 00000000 00000002 00000000 5fe0: 4004b7c4 befffdc0 0001371c 4004b7d4 20000010 00900080 00000000 00000000 Backtrace: Function entered at [<bf00a0d0>] from [<bf001af4>] Function entered at [<bf001a70>] from [<bf00a798>] r6 = 00000000 r5 = 00000000 r4 = C1BEC000 Function entered at [<bf00a760>] from [<c003c9d0>] r5 = BF0086A0 r4 = C0120F7C Function entered at [<c003c834>] from [<c001a760>] r7 = 00000080 r6 = 00000100 r5 = 00000000 r4 = 00000003 Code: e5992000 e59f00fc e592308c e2822074 (e5931000) SIGSEGV Which in better human language means that the ERROR macro is expanded to xprintk macro which turns into: dev_printk(level, %(f)->gadget->dev, fmt, ## args) and since fsg->gadget->dev is not defined (yet?) this produces the NULL pointer. Did you have other idea about how to solve this? When is the driver struct registered in the device struct? Could be another race condition trigger by our hardware? > I'm pleased that it works well. Is there some reason you added these > changes instead of using the test version? (..) > support the features those devices have. Most of them don't have > removable media (card readers being the major exception). We use the g_file_storage primary for several card readers, however we also like to preserve the small footprint. That's the reason we make that changes. ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
