[Bug 13350] [Breezy] hangs at boot : unhappy with NIC

bugzilla-daemon at bugzilla.ubuntu.com bugzilla-daemon at bugzilla.ubuntu.com
Thu Aug 18 22:37:18 UTC 2005

Please do not reply to this email.  You can add comments at
Ubuntu | linux

ben.collins at ubuntu.com changed:

           What    |Removed                     |Added
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1

------- Additional Comments From ben.collins at ubuntu.com  2005-08-18 23:37 UTC -------
So the real bug here is that it takes 22s to get past 8139cp to 8139too. I know
that this type of chipset (8139X) only has one real PCI dev/vendor combination,
and that the only way to tell whether it is 8139, 8139c or 8139c+ is to check
the firmware. IOW, the driver has to be loaded. I suspect that hotplug is doing
the smart thing, and trying the 8139cp first (which is the desired driver when
you have a C+ capable card). The 8139too driver works for all models of the
card, even C+, but you just wont get the extra ring buffers and such.

So, here's what I need from you, since I don't have an 8139 card to test with.
Can you boot the machine, disable the network device, and unload the 8139too and
8139cp modules. Then, do just like hotplug does and load those modules
seperately like:

modprobe 8139cp
modprobe 8139too

Take note of the length of time it takes for modprobe to return. I don't know
how hotplug handles it when two modules match the same device. I'm wondering if
it has some sort of delay inbetween each one to give the kernel a chance to
detect it before loading the next one. I can't see anything in the driver itself
that would cause this delay. So, I expect the test above to simply return
quickly with no delays, which would confirm my theory.

Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

More information about the kernel-bugs mailing list