Hi,
My Ethernet board (Intel(R) PRO/1000) "doesn't seems" to work any more
with this kernel, but all is ok with kernel 2.6.18-rc6-mm1.
A bisection search show this patch:
gregkh-pci-pci-sort-device-lists-breadth-first.patch
as being the faulty one...
But after reading the content of this patch, I understood that the order
of the ethernet boards had changed. In fact, I have four ethernet
boards and now, my eth0 does not point on the same card...
So all is now ok by changing my cable to the right board.
But is this really the expected behavior ?
--
Pierre Peiffer
On Fri, Sep 15, 2006 at 12:21:57PM +0200, Pierre Peiffer wrote:
> Hi,
>
> My Ethernet board (Intel(R) PRO/1000) "doesn't seems" to work any more
> with this kernel, but all is ok with kernel 2.6.18-rc6-mm1.
>
> A bisection search show this patch:
> gregkh-pci-pci-sort-device-lists-breadth-first.patch
> as being the faulty one...
>
> But after reading the content of this patch, I understood that the order
> of the ethernet boards had changed. In fact, I have four ethernet
> boards and now, my eth0 does not point on the same card...
> So all is now ok by changing my cable to the right board.
>
> But is this really the expected behavior ?
Yes, it's expected, but no, I agree it would be nice to not break
existing setups.
Care to send me an output of 'lspci -tv' and dmidecode (the first 80
or so lines)?
I think I'll redo this patch to keep the 2.6 depth-first sort order as
default, with command line options "pci=bfsort" and "pci=nobfsort" to
force it one way or the other, and DMI table entries for Dell's newest
systems that should default to bfsort.
Pierre, thank you for you report and your time to do the bisect. I
apologize for any inconvenience this caused you.
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-[0000:00]-+-00.0 Intel Corporation E7501 Memory Controller Hub
+-00.1 Intel Corporation E7500/E7501 Host RASUM Controller
+-03.0-[0000:02-04]--+-1c.0 Intel Corporation 82870P2 P64H2 I/OxAPIC
| +-1d.0-[0000:04]----02.0 Intel Corporation 82544EI Gigabit Ethernet Controller (Copper)
| +-1e.0 Intel Corporation 82870P2 P64H2 I/OxAPIC
| \-1f.0-[0000:03]--+-02.0 Intel Corporation 82544EI Gigabit Ethernet Controller (Copper)
| \-03.0 Adaptec AIC-7901A U320
+-03.1 Intel Corporation E7500/E7501 Hub Interface C RASUM Controller
+-1d.0 Intel Corporation 82801CA/CAM USB (Hub #1)
+-1d.1 Intel Corporation 82801CA/CAM USB (Hub #2)
+-1e.0-[0000:01]--+-03.0 Intel Corporation 82557/8/9 [Ethernet Pro 100]
| +-04.0 Intel Corporation 82540EM Gigabit Ethernet Controller
| \-0c.0 ATI Technologies Inc Rage XL
+-1f.0 Intel Corporation 82801CA LPC Interface Controller
+-1f.1 Intel Corporation 82801CA Ultra ATA Storage Controller
\-1f.3 Intel Corporation 82801CA/CAM SMBus Controller
On Fri, Sep 15, 2006 at 12:21:57PM +0200, Pierre Peiffer wrote:
> Hi,
>
> My Ethernet board (Intel(R) PRO/1000) "doesn't seems" to work any more
> with this kernel, but all is ok with kernel 2.6.18-rc6-mm1.
>
> A bisection search show this patch:
> gregkh-pci-pci-sort-device-lists-breadth-first.patch
> as being the faulty one...
>
> But after reading the content of this patch, I understood that the order
> of the ethernet boards had changed. In fact, I have four ethernet
> boards and now, my eth0 does not point on the same card...
> So all is now ok by changing my cable to the right board.
>
> But is this really the expected behavior ?
Yes. You should use a persistent name for your network devices to
prevent this from happening.
That being said, I think we need to reverse the order of this patch,
keeping the current scheme as default, and allowing it to be overridden
on the command line for those few machines where it matters to be
compatible with the old, 2.4 ordering scheme.
Matt, care to rework the patch in this manner?
thanks,
greg k-h
On Fri, Sep 15, 2006 at 03:29:54AM -0700, Greg KH wrote:
> That being said, I think we need to reverse the order of this patch,
> keeping the current scheme as default, and allowing it to be overridden
> on the command line for those few machines where it matters to be
> compatible with the old, 2.4 ordering scheme.
>
> Matt, care to rework the patch in this manner?
Greg, Andrew,
I'd really like to rework this patch in a different direction. As
such, please drop the patch:
gregkh-pci-pci-sort-device-lists-breadth-first.patch
from your trees, and I'll provide a new one next week.
Breadth-first vs depth-first is really only part of the problem. More
fundamental is the expectation that embedded devices get discovered
before add-in devices in physical slots. From there, breadth-first vs
depth-first is interesting again. I'd like to sort the list to put
the embedded devices first, subsort those breadth-first, then list the
add-in devices in ascending slot number order, subsort breadth-first.
I'll default this sorting routine off, enabled/disabled via a command
line option, and enabled by default for some systems based on DMI
strings.
arch/i386/pci/irq.c already has the PCI IRQ Routing Table available,
from which we can get embedded vs slotN information. It's not
currently being used in this manner, so I'm massaging that.
How does this sound?
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com