On Tue, 2008-01-29 at 03:46 +0300, Michael Tokarev wrote:Actually, it's the order in which the probe functions run, which is typically related to the order in which they are loaded. You can blacklist one driver and get the other instead. Nah. Random build ordering as it always has been - two different builds would end up with modules in a different order on disk, hence depmod would generate a different ordering. This will be fixed shortly with the Modules.order bits, but you will still need to blacklist one of the drivers (unless you're lucky and 8139too comes first), until there is proper support for dynamic rebinding and udev rules to do that. Nah. It's a "bug" insomuch as we don't handle multiple matching aliases very well, and it's becoming more common, so we probably should :) Jon. --
| monstr | [PATCH 27/56] microblaze_v2: support for a.out |
| Andrew Morton | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| mdew . | Re: [patch] CFS scheduler, v4 |
| Gabriel C | Re: 2.6.21-mm1 |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Willy Tarreau | Re: [PATCH] tcp: splice as many packets as possible at once |
| Linus Torvalds | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
