Re: [linux-usb-devel] Re: [OOPS] Help needed for usb semaphore lock in 2.4.20-rc1 (since 2.4.13)
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 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.) Are there any special complications of moving things like this that I should be alert for? Duncan -- E-Mail: Duncan Haldane <[EMAIL PROTECTED]> Date: 15-Nov-2002 Time: 21:20:33 This message was sent by XFMail -- --- 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 lock in 2.4.20-rc1 (since 2.4.13)
Am Freitag, 15. November 2002 22:09 schrieb [EMAIL PROTECTED]: > > > 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? or adding usb_init() call in init/main.c as > previously suggested? Well, you have to be after pci and scsi. Beyond that I don't care. Simply do anything that works :-) Regards Oliver --- 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 lock in 2.4.20-rc1 (since 2.4.13)
> > > 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? or adding usb_init() call in init/main.c as previously suggested? I assume that the 2.4.x series will not see any big structural improvements to its init sequence, so even if this "hides" potential problems, it would be a reasonably safe workaround?. Duncan --- 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 lock in 2.4.20-rc1 (since 2.4.13)
> Date: Fri, 15 Nov 2002 14:38:05 -0500 (EST) > From: Duncan Haldane <[EMAIL PROTECTED]> > >| 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;) > But... such a Makefile change DOES fix it. 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. > I moved the position of drivers/media.o to after drivers/usb.o in the Makefile, > and the problem is gone. 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. -- Pete --- 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 lock in 2.4.20-rc1 (since 2.4.13)
> 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? Regards Oliver --- 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 lock in 2.4.20-rc1 (since 2.4.13)
On 15-Nov-2002 Randy.Dunlap wrote: > On Fri, 15 Nov 2002, Pete Zaitcev wrote: > >| > From: "Randy.Dunlap" <[EMAIL PROTECTED]> >| > Date: Fri, 15 Nov 2002 08:40:36 -0800 (PST) >| > This is the way it used to be many many moons ago. >| >| 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. 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. 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'm assuming moving parport drivers down the list to after usb wont break them, though. 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?) --- 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 > > -- > ~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 -- E-Mail: Duncan Haldane <[EMAIL PROTECTED]> Date: 15-Nov-2002 Time: 13:58:14 This message was sent by XFMail -- --- 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 lock in 2.4.20-rc1 (since 2.4.13)
On 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.
>
> 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.
To test this strategy, I've done this, and put an
"extern int __init usb_init(void);" (is the "static int _init usb_init(void);"
in drivers/usb/usb.c a conflict with this?)
declaration in include/linux/usb.h, included usb.h in init/main.c, etc, so it
compiles OK,
but the link step fails:
ld -m elf_i386 -T /usr/src/linux-2.4.20-rc1/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o
init/do_mounts.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o
fs/fs.o ipc/ipc.o \
drivers/parport/driver.o drivers/char/char.o drivers/block/block.o
drivers/misc/misc.o drivers/net/net.o drivers/media/media.o
drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o
drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o
drivers/video/video.o drivers/usb/usbdrv.o \
net/network.o \
/usr/src/linux-2.4.20-rc1/arch/i386/lib/lib.a
/usr/src/linux-2.4.20-rc1/lib/lib.a
/usr/src/linux-2.4.20-rc1/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
init/main.o: In function `do_basic_setup':
init/main.o(.text.init+0x80f): undefined reference to `usb_init'
make: *** [vmlinux] Error 1
--
but look in usbdrv.o, usb_init is there!!
$ grep usb_init drivers/usb/*.o
Binary file usbcore.o matches
Binary file usbdrv.o matches
Binary file usb.o matches
-drivers/usb/usb.c (unchanged)-
static int __init usb_init(void)
{
init_MUTEX(&usb_bus_list_lock);
usb_major_init();
usbdevfs_init();
usb_hub_init();
return 0;
}
---include/linux/usb.h
#endif /* CONFIG_USB_DEVICEFS */
extern int __init usb_init(void);
#endif /* __KERNEL__ */
#endif
init/main.c--
#ifdef CONFIG_USB
#include
#endif
ifdef CONFIG_TC
tc_init();
#endif
#ifdef CONFIG_USB
usb_init();
#endif
--
init/main.c already initializes , e.g., the zorro driver, and I can't see
anything that is done for zorro that I didnt now do for usb_init.What have I
overlooked?
Duncan
---
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 lock in 2.4.20-rc1 (since 2.4.13)
> From: "Randy.Dunlap" <[EMAIL PROTECTED]> > Date: Fri, 15 Nov 2002 08:40:36 -0800 (PST) > | > 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? > 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. 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'. -- Pete --- 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 lock in 2.4.20-rc1 (since 2.4.13)
> 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. Regards Oliver --- 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
