Re: [linux-usb-devel] Re: [OOPS] Help needed for usb semaphore lockin 2.4.20-rc1 (since 2.4.13)
On Fri, 15 Nov 2002, Oliver Neukum wrote: | | Yes, I think you are right. | To test your idea, I moved the initialization | | init_MUTEX(usb_bus_list_lock); | | from usb_init() to just before the call to usb_scan_devices() | in usb_register() and the oops went away and cpia worked. | | | I see that in the working code prior to 2.4.13, usb_init() doesnt handle | any usb_bus_list_lock initialization. Hmmm. | | I believe that cpia_usb.c cannot be compiled into the kernel unless | usb is also compiled into the kernel. Is there any way to move the | initialization of cpia_usb to later in the boot sequence? | | Or put some #ifndef module ... #endif code that moves the lock | initialization to before the call to usb_scan devices, and tests whether it | is done so it is only initialized the first time usb_register is called? | | No, don't do complicated halfmeasures. | Add a call to usb_init to main.c::do_basic_setup if you compile usb into the kernel. Yes, I agree. I had a patch last night that moved the semaphore init, but then I realized that it was a bad idea. As Oliver says, the right patch is something like this in init/main.c: #ifdef CONFIG_USB extern usb_init(void); usb_init(); #endif and in drivers/usb/usb.c: #ifdef MODULE module_init(usb_init); #endif This is the way it used to be many many moons ago. -- ~Randy I read part of it all the way through. -- Samuel Goldwyn --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS] Help needed for usb semaphore lockin 2.4.20-rc1 (since 2.4.13)
On Fri, 15 Nov 2002, Duncan Haldane wrote: | | On 15-Nov-2002 Randy.Dunlap wrote: | On Fri, 15 Nov 2002, Pete Zaitcev wrote: | | | VERY many moons ago. Today, the same effect is accomplished by | | module_init() without #ifdef bracket. If the module is compiled | | into the kernel, do_initcalls does the call there. | | | | To make cpia initialize later than the USB, the proper configuration | | must be used, which prohibits CPIA being 'y' and USB core 'm'. | | It can be done without if, by using dep_tristate as appropriate. | | Also, the order in which cpia and usbcore are listed in the Makefile | | is significant, it determines the order in which do_initcalls | | calls them in case of them being 'y'. | | The case is both cpia and usb are 'y'. | cpia is being init-ed before usbcore. | Where's your patch/solution? 8;) | | As I said earlier (now deleted), controlling init order in 2.4 | is odd. In 2.5 it's much easier, but that doesn't matter for this | problem. Mucking around with order in Makefile isn't a good solution | IMO. | But... such a Makefile change DOES fix it. Yep, I didn't say it wouldn't work, it's just too much like makefile magic IMO. The next version of make might be different. :( But this is certainly a better solution than initializing the semaphore in a second place. | I see that the position of the cpia driver in | drivers/media/video is anomalous: it started out as a parport driver | and now supports both parport and usb devices. There used to be a separate cpia driver in drivers/usb/, but then they were merged. | I moved the position of drivers/media.o to after drivers/usb.o in the Makefile, | and the problem is gone. I would like to get something like this into | 2.4.20 as an immediate workaround, if at all possible. I guess to be less | invasive though, I should somehow remove cpia*.o from video.o and hence from | media.o, and create a cpiadrv.o so the | init position of other drivers in media.o is not messed with. I expect that it will be difficult to get this into 2.4.20-rc2++. There are other less-intrusive workarounds (like cpia as a module). IMO you should push this patch to 2.4.21-pre1 thru Greg KH or Alan Cox (?). | I'm assuming moving parport drivers down the list to after usb wont | break them, though. I hope not. | I guess it can be justified because cpia is a special case: are there any | other kernel drivers | that support both parport and usb that can be used as a model for | what to do? (maybe scanners?) Not that I know of. | --- MakefileSun Nov 10 11:35:09 2002 | +++ Makefile.usb_fixFri Nov 15 13:40:21 2002 | @@ -137,8 +137,7 @@ | DRIVERS-y += drivers/char/char.o \ | drivers/block/block.o \ | drivers/misc/misc.o \ | - drivers/net/net.o \ | - drivers/media/media.o | + drivers/net/net.o | DRIVERS-$(CONFIG_AGP) += drivers/char/agp/agp.o | DRIVERS-$(CONFIG_DRM_NEW) += drivers/char/drm/drm.o | DRIVERS-$(CONFIG_DRM_OLD) += drivers/char/drm-4.0/drm.o | @@ -179,6 +178,7 @@ | DRIVERS-$(CONFIG_HAMRADIO) += drivers/net/hamradio/hamradio.o | DRIVERS-$(CONFIG_TC) += drivers/tc/tc.a | DRIVERS-$(CONFIG_USB) += drivers/usb/usbdrv.o | +DRIVERS-y += drivers/media/media.o | DRIVERS-$(CONFIG_INPUT) += drivers/input/inputdrv.o | DRIVERS-$(CONFIG_HIL) += drivers/hil/hil.o | DRIVERS-$(CONFIG_I2O) += drivers/message/i2o/i2o.o Looks OK to me. -- ~Randy I read part of it all the way through. -- Samuel Goldwyn --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS] Help needed for usb semaphore lockin 2.4.20-rc1 (since 2.4.13)
On Fri, 15 Nov 2002 [EMAIL PROTECTED] wrote: | I'm assuming moving parport drivers down the list to after usb wont | break them, though. | | Can you compile uss720 into the kernel if you don't do that? | | | I'll test. | | But how about just moving DRIVERS +=/drivers/usb/usbdrv.o much higher up the Makefile | DRIVERS list? Looks like that would work. Can you add that to your testing? | or adding usb_init() call in init/main.c as previously suggested? That's the most deterministic solution, but not current or modern it seems. | I assume that the 2.4.x series will not see any big structural I expect that's correct. | improvements to its init sequence, so even if this hides | potential problems, it would be a reasonably safe workaround?. Sorry, I didn't quite understand. -- ~Randy --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS] Help needed for usb semaphore lockin 2.4.20-rc1 (since 2.4.13)
On Fri, 2002-11-15 at 19:56, Pete Zaitcev wrote: I wrote Randy and proposed to move cpia_usb.c over to the drivers/usb directory. The problem is that supporting dependencies between drivers/media and drivers/usb is fragile: someone can break them later as a side effect. That media is not right near the end is a quirk of history nothing more. It ought to be after usb --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS] Help needed for usb semaphore lockin 2.4.20-rc1 (since 2.4.13)
On 16 Nov 2002, Alan Cox wrote: | On Fri, 2002-11-15 at 19:56, Pete Zaitcev wrote: | I wrote Randy and proposed to move cpia_usb.c over to the | drivers/usb directory. The problem is that supporting | dependencies between drivers/media and drivers/usb is fragile: | someone can break them later as a side effect. | | That media is not right near the end is a quirk of history nothing more. | It ought to be after usb Great. Duncan, will you do that patch? -- ~Randy --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: [OOPS] Help needed for usb semaphore lockin 2.4.20-rc1 (since 2.4.13)
On Fri, 15 Nov 2002, Duncan Haldane wrote: | On 15-Nov-2002 Pete Zaitcev wrote: | | I wrote Randy and proposed to move cpia_usb.c over to the | drivers/usb directory. The problem is that supporting | dependencies between drivers/media and drivers/usb is fragile: | someone can break them later as a side effect. | | OK. I tested this and it seems to work fine with cpia_usb.o in | drivers/usb/usbdrv.o rather than /drivers/media/media.o | | One issue is the | # include cpia.h | in drivers/usb/cpia_usb.c | | now this has to be | #include ../media/video/cpia.h | | is this acceptable practice in the kernel source, or must It's been done before but it's undesirable. | I now also move drivers/media/video/cpia.h to (say) include/linux/cpia.h | (I would prefer not to completely split up the cpia d sources like this.) How about not splitting them up and all and just do like Alan suggested: move drivers/media.o to near the end of the list, after USB. Does that work (fix the problem)? | Are there any special complications of moving things like this that | I should be alert for? -- ~Randy --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
