Mailing List Archive

2.6.11-gentoo-r7: If USB core API (usbcore) is built-in, it conflicts with the rest of usb-dependent modules
Hi,

After some talk to gregkh, I've decided to send this message as it might
give some light regarding the breakage of the USB modules when usbcore
is built-in instead of compiled as module.

Modules that are breaking with CONFIG_USB=y :

- audio, bfusb, bcm203x, bpa10x, hci_usb, usblp, usb-midi, cdc_acm,
uhci-hcd, ohci-hcd, ehci-hcd, usb-storage...

For those, the core API symbols that follow are missing as of the
built-in selected option:

usbserial: Unknown symbol usb_alloc_urb
usbserial: Unknown symbol usb_free_urb
usbserial: Unknown symbol usb_register
usbserial: Unknown symbol usb_put_dev
usbserial: Unknown symbol usb_get_dev
usbserial: Unknown symbol usb_submit_urb
usbserial: Unknown symbol usb_match_id
usbserial: Unknown symbol usb_control_msg
usbserial: Unknown symbol usb_deregister
usbserial: Unknown symbol usb_kill_urb

The symbols are in the System map:

c02fd7b0 T usb_free_urb
c02fd7d0 T usb_get_urb
c02fd800 T usb_submit_urb
c02fdaa0 T usb_unlink_urb
c02fdb40 T usb_kill_urb
(...)

Greg suggested on fixing the Kconfig but I'm not sure if this a
Gentoo-only issue, or it's widely. Thus, if it needs to be fixed, let me
know and I'll get over it ASAP as it might be a blocking issue in
certain cases.

(It doesn't seem to be a good idea to let all the USB-related drivers
getting built-in)

Thanks in advance,
cheers.
--
Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
Re: 2.6.11-gentoo-r7: If USB core API (usbcore) is built-in, it conflicts with the rest of usb-dependent modules [ In reply to ]
On Wed, May 11, 2005 at 09:10:46PM +0200, Lorenzo Hernandez Garcia-Hierro wrote:
> Hi,
>
> After some talk to gregkh, I've decided to send this message as it might
> give some light regarding the breakage of the USB modules when usbcore
> is built-in instead of compiled as module.
>
> Modules that are breaking with CONFIG_USB=y :
>
> - audio, bfusb, bcm203x, bpa10x, hci_usb, usblp, usb-midi, cdc_acm,
> uhci-hcd, ohci-hcd, ehci-hcd, usb-storage...
>
> For those, the core API symbols that follow are missing as of the
> built-in selected option:

This should work just fine, care to attach your .config?

thanks,

greg k-h
--
gentoo-dev@gentoo.org mailing list
Re: 2.6.11-gentoo-r7: If USB core API (usbcore) is built-in, it conflicts with the rest of usb-dependent modules [ In reply to ]
El mié, 11-05-2005 a las 13:12 -0700, Greg KH escribió:
> On Wed, May 11, 2005 at 09:10:46PM +0200, Lorenzo Hernandez Garcia-Hierro wrote:
> > Hi,
> >
> > After some talk to gregkh, I've decided to send this message as it might
> > give some light regarding the breakage of the USB modules when usbcore
> > is built-in instead of compiled as module.
> >
> > Modules that are breaking with CONFIG_USB=y :
> >
> > - audio, bfusb, bcm203x, bpa10x, hci_usb, usblp, usb-midi, cdc_acm,
> > uhci-hcd, ohci-hcd, ehci-hcd, usb-storage...
> >
> > For those, the core API symbols that follow are missing as of the
> > built-in selected option:
>
> This should work just fine, care to attach your .config?

Attached is my .config for -hardened-r1 which is basically a gentoo
sources without fbsplash patch and some security-related patches
applied, from the Hardened Gentoo project.

This one takes CONFIG_USB=m but no host controller drivers nor class
drivers will be able to get registered (the case is getting even more
strange...):

kobject_register failed for usbcore (-17)
[<c02677bb>]
[<c016d041>]
[<c016e04f>]
[<c016e356>]
[<c0138227>]
[<c013007b>]
kobject_register failed for ehci_hcd (-17)
[<c02677bb>]
[<c016d041>]
[<c016e04f>]
[<c016e356>]
[<c0138227>]
[<c01979e1>]
[<c013823f>]

Some translated:

c0267760 T kobject_register
c02677c0 T kobject_set_name
(...)
c013823f t restore_all

Thanks in advance,
cheers.
--
Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
Re: 2.6.11-gentoo-r7: If USB core API (usbcore) is built-in, it conflicts with the rest of usb-dependent modules [ In reply to ]
On Wed, May 11, 2005 at 11:27:42PM +0200, Lorenzo Hernandez Garcia-Hierro wrote:
> El mi?, 11-05-2005 a las 13:12 -0700, Greg KH escribi?:
> > On Wed, May 11, 2005 at 09:10:46PM +0200, Lorenzo Hernandez Garcia-Hierro wrote:
> > > Hi,
> > >
> > > After some talk to gregkh, I've decided to send this message as it might
> > > give some light regarding the breakage of the USB modules when usbcore
> > > is built-in instead of compiled as module.
> > >
> > > Modules that are breaking with CONFIG_USB=y :
> > >
> > > - audio, bfusb, bcm203x, bpa10x, hci_usb, usblp, usb-midi, cdc_acm,
> > > uhci-hcd, ohci-hcd, ehci-hcd, usb-storage...
> > >
> > > For those, the core API symbols that follow are missing as of the
> > > built-in selected option:
> >
> > This should work just fine, care to attach your .config?
>
> Attached is my .config for -hardened-r1 which is basically a gentoo
> sources without fbsplash patch and some security-related patches
> applied, from the Hardened Gentoo project.
>
> This one takes CONFIG_USB=m but no host controller drivers nor class
> drivers will be able to get registered (the case is getting even more
> strange...):

Well, can you duplicate this against a clean 2.6.12-rc4 or 2.6.11.8
kernel? I don't trust the hardened gentoo kernel patches at all...

thanks,

greg k-h
--
gentoo-dev@gentoo.org mailing list
Re: 2.6.11-gentoo-r7: If USB core API (usbcore) is built-in, it conflicts with the rest of usb-dependent modules [ In reply to ]
El mié, 11-05-2005 a las 14:44 -0700, Greg KH escribió:
> Well, can you duplicate this against a clean 2.6.12-rc4 or 2.6.11.8
> kernel? I don't trust the hardened gentoo kernel patches at all...

I've been testing the heck, and this is what we have right now (on
2.6.11-gentoo-r8, without any weird patch rather than Gentoo's ones
which have nothing t do with USB and the like, nor modify the ABI as
hardened-sources patch-set does):

We have the following input modules: psmouse, sermouse, usbhid: usbkbd,
usbmouse.

Also, all USB-related code is modularized, as you can see in the
attached .config .

The case:

we unload psmouse, hence ALPS touchpad (this is HP zv5045eu laptop, the
amazing world of almost-unsupported stuff ;) stops working.
immediately we load the usbmouse module which shouldn't be needed due to
usbhid, and we don't get the mouse working but at least, it shows up
without the "bad cable" error:

drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver

then we load psmouse again..., and we get:

drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
hub 4-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?

At this point, it's evident that psmouse and sermouse aren't able to
co-exist with usbhid or usbmouse (BTW, my host controllers are EHCI and
OHCI, no UHCI thingy).

The complete process:

usbcore: deregistering driver usbmouse
usbcore: deregistering driver usbhid
usbcore: deregistering driver hiddev
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
usbcore: registered new driver usbmouse
drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
ALPS Touchpad (Glidepoint) detected
Enabling hardware tapping
input: AlpsPS/2 ALPS TouchPad on isa0060/serio4
hub 4-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?

So, it's not a fault regarding my configuration or my hardware but a
problem regarding the way that input drivers get registered and more
important, how USB input devices register (well, I think psmouse should
get built-in, but I'm lost, I've lost the count on the times I have
plugged, unplugged, recompiled and compiled again, and this host won't
be able to suffer more plugging-unplugging insane fun).

I've been looking fr other people with the same issue and there are a
few, they're lucky that they have PS2 but this laptop has "obsoleted"
those nice ports.

The device works on a USB 1.1 host controller-powered machine running
hotplug, udev and more concretely Ubuntu Linux Hoary (from the last I
time I used it, that was before my CRT screen got out of business...),
so, It may concern USB 2.0 EHCI controller and the way it does or
doesn't the supportability for low-velocity USB 1.1 (but it works with
an HCI device which is based on the BlueFritz! chip, that is, bfusb
driver, and that's not USB 2.0).

I hope to get this fixed for all of the users who suffer the problem of
having 2.0 host controllers not working with USB mouses (among those
like me who rely on a weird ALPS touch-pad, with the risk of getting
those damn RSI).

Cheers and many thanks in advance.
PS: No, it's not "Tom's hardware" week here, even if it looks like that
to me. Just bad luck ;).
--
Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
Re: 2.6.11-gentoo-r7: If USB core API (usbcore) is built-in, it conflicts with the rest of usb-dependent modules [ In reply to ]
Lorenzo Hernandez Garcia-Hierro posted
<1115838647.25889.14.camel@localhost>, excerpted below, on Wed, 11 May
2005 21:10:46 +0200:

> After some talk to gregkh, I've decided to send this message as it might
> give some light regarding the breakage of the USB modules when usbcore is
> built-in instead of compiled as module.
>
> Modules that are breaking with CONFIG_USB=y :
>
> - audio, bfusb, bcm203x, bpa10x, hci_usb, usblp, usb-midi, cdc_acm,
> uhci-hcd, ohci-hcd, ehci-hcd, usb-storage...

> Greg suggested on fixing the Kconfig but I'm not sure if this a
> Gentoo-only issue, or it's widely. Thus, if it needs to be fixed, let me
> know and I'll get over it ASAP as it might be a blocking issue in certain
> cases.
>
> (It doesn't seem to be a good idea to let all the USB-related drivers
> getting built-in)

Is this the same issue that has USB failing to detect anything but the
hosts, when USB is built-in? I haven't had issues building the kernel,
but with USB built-in, only the USB host is detected, nothing actually
plugged into it. I thought my USB hardware was broken, and was prepared
to buy an add-on card before I used USB for anything non-optional, but
then the issue came up on the amd64 list, and someone mentioned that
building USB into the kernel would often cause this symptom, but it would
work just fine with the USB system modularized. Sure enough, it did.

I can confirm /that/ issue occurs on vanilla kernel.org kernels, and has
for some time (several 2.6.x versions, anyway), since I don't use gentoo
kernels, but rather download my kernel sources directly from kernel.org.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev@gentoo.org mailing list