In arch/i386/kernel/pci-pc.c, there are
/*
* Sort the device list according to PCI BIOS. Nasty hack, but since some
* fool forgot to define the `correct' device order in the PCI BIOS specs
* and we want to be (possibly bug-to-bug ;-]) compatible with older kernels
* which used BIOS ordering, we are bound to do this...
*/
static void __devinit pcibios_sort(void)
The problem is on my MB:
00:00.0 Host bridge: Intel Corp. e7500 [Plumas] DRAM Controller (rev 03)
00:00.1 Class ff00: Intel Corp. e7500 [Plumas] DRAM Controller Error Reporting ( rev 03)
00:03.0 PCI bridge: Intel Corp. e7500 [Plumas] HI_C Virtual PCI Bridge (F0) (rev 03)
00:03.1 Class ff00: Intel Corp. e7500 [Plumas] HI_C Virtual PCI Bridge (F1) (rev 03)
00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 42)
00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02)
00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02)
01:0c.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
03:07.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
03:07.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
03:08.0 RAID bus controller: 3ware Inc 3ware 7000-series ATA-RAID (rev 01)
Eth1 becomes:
03:07.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
and eth0 becomes:
03:07.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
Is that a good idea to have an option to sort the PCI device by PCI bus and
slot numbers?
H.J.
H. J. Lu wrote:
>In arch/i386/kernel/pci-pc.c, there are
>
>/*
> * Sort the device list according to PCI BIOS. Nasty hack, but since some
> * fool forgot to define the `correct' device order in the PCI BIOS specs
> * and we want to be (possibly bug-to-bug ;-]) compatible with older kernels
> * which used BIOS ordering, we are bound to do this...
> */
>
>static void __devinit pcibios_sort(void)
>
>The problem is on my MB:
>
>00:00.0 Host bridge: Intel Corp. e7500 [Plumas] DRAM Controller (rev 03)
>00:00.1 Class ff00: Intel Corp. e7500 [Plumas] DRAM Controller Error Reporting ( rev 03)
>00:03.0 PCI bridge: Intel Corp. e7500 [Plumas] HI_C Virtual PCI Bridge (F0) (rev 03)
>00:03.1 Class ff00: Intel Corp. e7500 [Plumas] HI_C Virtual PCI Bridge (F1) (rev 03)
>00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
>00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
>00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 42)
>00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02)
>00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02)
>00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02)
>01:0c.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
>02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
>02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
>02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
>02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
>03:07.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
>03:07.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
>03:08.0 RAID bus controller: 3ware Inc 3ware 7000-series ATA-RAID (rev 01)
>
>Eth1 becomes:
>03:07.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
>
>and eth0 becomes:
>03:07.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
>
>Is that a good idea to have an option to sort the PCI device by PCI bus and
>slot numbers?
>
>
Without answering your specific question, but addressing $subject, what
problem is caused by the PCI device order you see?
You can use ETHTOOL_GDRVINFO to get the PCI bus info for an ethernet
interface, so you know at all times what device is associated with what
PCI device. And among other ways you are notified of device
addition/removal by the execution of /sbin/hotplug for each ethernet
interface.
Jeff
On Thu, Oct 24, 2002 at 07:49:41PM -0400, Jeff Garzik wrote:
> H. J. Lu wrote:
>
> >In arch/i386/kernel/pci-pc.c, there are
> >
> >/*
> > * Sort the device list according to PCI BIOS. Nasty hack, but since some
> > * fool forgot to define the `correct' device order in the PCI BIOS specs
> > * and we want to be (possibly bug-to-bug ;-]) compatible with older kernels
> > * which used BIOS ordering, we are bound to do this...
> > */
> >
> >static void __devinit pcibios_sort(void)
> >
> >The problem is on my MB:
> >
> >00:00.0 Host bridge: Intel Corp. e7500 [Plumas] DRAM Controller (rev 03)
> >00:00.1 Class ff00: Intel Corp. e7500 [Plumas] DRAM Controller Error Reporting ( rev 03)
> >00:03.0 PCI bridge: Intel Corp. e7500 [Plumas] HI_C Virtual PCI Bridge (F0) (rev 03)
> >00:03.1 Class ff00: Intel Corp. e7500 [Plumas] HI_C Virtual PCI Bridge (F1) (rev 03)
> >00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
> >00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
> >00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 42)
> >00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02)
> >00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02)
> >00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02)
> >01:0c.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
> >02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
> >02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
> >02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
> >02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
> >03:07.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
> >03:07.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
> >03:08.0 RAID bus controller: 3ware Inc 3ware 7000-series ATA-RAID (rev 01)
> >
> >Eth1 becomes:
> >03:07.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
> >
> >and eth0 becomes:
> >03:07.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
> >
> >Is that a good idea to have an option to sort the PCI device by PCI bus and
> >slot numbers?
> >
> >
>
> Without answering your specific question, but addressing $subject, what
> problem is caused by the PCI device order you see?
It is different from the hardware documentation. The hardware manual says
it has 2 NICs, NIC 1 (03:07.0) and NIC2 (03:07.1), which makes senses
to me. NIC 1 is a special one which supports IPMI over LAN. Since we
only use one NIC now, we'd like to use NIC 1 and call it eth0.
H.J.
H. J. Lu wrote:
>On Thu, Oct 24, 2002 at 07:49:41PM -0400, Jeff Garzik wrote:
>
>
>>H. J. Lu wrote:
>>
>>
>>
>>>In arch/i386/kernel/pci-pc.c, there are
>>>
>>>/*
>>>* Sort the device list according to PCI BIOS. Nasty hack, but since some
>>>* fool forgot to define the `correct' device order in the PCI BIOS specs
>>>* and we want to be (possibly bug-to-bug ;-]) compatible with older kernels
>>>* which used BIOS ordering, we are bound to do this...
>>>*/
>>>
>>>static void __devinit pcibios_sort(void)
>>>
>>>The problem is on my MB:
>>>
>>>00:00.0 Host bridge: Intel Corp. e7500 [Plumas] DRAM Controller (rev 03)
>>>00:00.1 Class ff00: Intel Corp. e7500 [Plumas] DRAM Controller Error Reporting ( rev 03)
>>>00:03.0 PCI bridge: Intel Corp. e7500 [Plumas] HI_C Virtual PCI Bridge (F0) (rev 03)
>>>00:03.1 Class ff00: Intel Corp. e7500 [Plumas] HI_C Virtual PCI Bridge (F1) (rev 03)
>>>00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
>>>00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
>>>00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 42)
>>>00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02)
>>>00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02)
>>>00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02)
>>>01:0c.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
>>>02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
>>>02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
>>>02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
>>>02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
>>>03:07.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
>>>03:07.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
>>>03:08.0 RAID bus controller: 3ware Inc 3ware 7000-series ATA-RAID (rev 01)
>>>
>>>Eth1 becomes:
>>>03:07.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
>>>
>>>and eth0 becomes:
>>>03:07.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
>>>
>>>Is that a good idea to have an option to sort the PCI device by PCI bus and
>>>slot numbers?
>>>
>>>
>>>
>>>
>>Without answering your specific question, but addressing $subject, what
>>problem is caused by the PCI device order you see?
>>
>>
>
>It is different from the hardware documentation. The hardware manual says
>it has 2 NICs, NIC 1 (03:07.0) and NIC2 (03:07.1), which makes senses
>to me. NIC 1 is a special one which supports IPMI over LAN. Since we
>only use one NIC now, we'd like to use NIC 1 and call it eth0.
>
>
Well, overall, depending on ordering is error-prone (as you see). I
would suggest migrating to a less-fragile scheme. nameif and ethtool
together should get you exactly the device you need... (though I wonder
why simply using eth1 is so awful, if this situation is constant...)
Jeff
I've heard some grumbling about this with specific motherboards and 82546
LOMs. While I understand what's happening, and that using nameif to manage
this is the correct answer, I am a bit surprised that function 1 would be
placed on the global PCI device list before function 0 for a multi-function
device.
-- Chris Leech
> >>Without answering your specific question, but addressing $subject,
> >>what
> >>problem is caused by the PCI device order you see?
> >>
> >>
> >
> >It is different from the hardware documentation. The hardware manual
> >says it has 2 NICs, NIC 1 (03:07.0) and NIC2 (03:07.1), which makes
> >senses to me. NIC 1 is a special one which supports IPMI over LAN.
> >Since we only use one NIC now, we'd like to use NIC 1 and
> call it eth0.
> >
> >
>
> Well, overall, depending on ordering is error-prone (as you see). I
> would suggest migrating to a less-fragile scheme. nameif and ethtool
> together should get you exactly the device you need...
> (though I wonder
> why simply using eth1 is so awful, if this situation is constant...)
>
> Jeff
On Thu, Oct 24, 2002 at 08:14:09PM -0400, Jeff Garzik wrote:
> H. J. Lu wrote:
>
> >On Thu, Oct 24, 2002 at 07:49:41PM -0400, Jeff Garzik wrote:
> >
> >
> >>H. J. Lu wrote:
> >>
> >>
> >>
> >>>In arch/i386/kernel/pci-pc.c, there are
> >>>
> >>>/*
> >>>* Sort the device list according to PCI BIOS. Nasty hack, but since some
> >>>* fool forgot to define the `correct' device order in the PCI BIOS specs
> >>>* and we want to be (possibly bug-to-bug ;-]) compatible with older kernels
> >>>* which used BIOS ordering, we are bound to do this...
> >>>*/
> >>>
> >>>static void __devinit pcibios_sort(void)
> >>>
> >>>The problem is on my MB:
> >>>
> >>>00:00.0 Host bridge: Intel Corp. e7500 [Plumas] DRAM Controller (rev 03)
> >>>00:00.1 Class ff00: Intel Corp. e7500 [Plumas] DRAM Controller Error Reporting ( rev 03)
> >>>00:03.0 PCI bridge: Intel Corp. e7500 [Plumas] HI_C Virtual PCI Bridge (F0) (rev 03)
> >>>00:03.1 Class ff00: Intel Corp. e7500 [Plumas] HI_C Virtual PCI Bridge (F1) (rev 03)
> >>>00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
> >>>00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub (rev 02)
> >>>00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 42)
> >>>00:1f.0 ISA bridge: Intel Corp. 82801CA ISA Bridge (LPC) (rev 02)
> >>>00:1f.1 IDE interface: Intel Corp. 82801CA IDE U100 (rev 02)
> >>>00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02)
> >>>01:0c.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
> >>>02:1c.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
> >>>02:1d.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
> >>>02:1e.0 PIC: Intel Corp. 82870P2 P64H2 I/OxAPIC (rev 03)
> >>>02:1f.0 PCI bridge: Intel Corp. 82870P2 P64H2 Hub PCI Bridge (rev 03)
> >>>03:07.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
> >>>03:07.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
> >>>03:08.0 RAID bus controller: 3ware Inc 3ware 7000-series ATA-RAID (rev 01)
> >>>
> >>>Eth1 becomes:
> >>>03:07.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
> >>>
> >>>and eth0 becomes:
> >>>03:07.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (rev 01)
> >>>
> >>>Is that a good idea to have an option to sort the PCI device by PCI bus and
> >>>slot numbers?
> >>>
> >>>
> >>>
> >>>
> >>Without answering your specific question, but addressing $subject, what
> >>problem is caused by the PCI device order you see?
> >>
> >>
> >
> >It is different from the hardware documentation. The hardware manual says
> >it has 2 NICs, NIC 1 (03:07.0) and NIC2 (03:07.1), which makes senses
> >to me. NIC 1 is a special one which supports IPMI over LAN. Since we
> >only use one NIC now, we'd like to use NIC 1 and call it eth0.
> >
> >
>
> Well, overall, depending on ordering is error-prone (as you see). I
> would suggest migrating to a less-fragile scheme. nameif and ethtool
> together should get you exactly the device you need... (though I wonder
> why simply using eth1 is so awful, if this situation is constant...)
We can use eth1. It is just very confusing since Linux and hardware
manual don't agree which one is the first NIC. Also, when we upgrade
the BIOS, the BIOS order may change. As for other schemes, we don't want
to change every software which access ethX.
H.J.
If you're that concerned about possible ordering changes due to future BIOS
upgrades, I'd suggest setting up an /etc/mactab and using nameif to control
interface naming from userspace.
-- Chris Leech
> -----Original Message-----
> From: H. J. Lu [mailto:[email protected]]
> We can use eth1. It is just very confusing since Linux and
> hardware manual don't agree which one is the first NIC. Also,
> when we upgrade the BIOS, the BIOS order may change. As for
> other schemes, we don't want to change every software which
> access ethX.
On Thu, Oct 24, 2002 at 05:21:10PM -0700, Leech, Christopher wrote:
> I've heard some grumbling about this with specific motherboards and 82546
> LOMs. While I understand what's happening, and that using nameif to manage
> this is the correct answer, I am a bit surprised that function 1 would be
> placed on the global PCI device list before function 0 for a multi-function
> device.
>
You can tell it from the BIOS, which lists 0339 before 0338 by default.
H.J.
On Thu, Oct 24, 2002 at 05:25:01PM -0700, Leech, Christopher wrote:
>
> If you're that concerned about possible ordering changes due to future BIOS
> upgrades, I'd suggest setting up an /etc/mactab and using nameif to control
> interface naming from userspace.
>
That is not enough. I use PXE to install RedHat. The RedHat 7.3 installer only
deals with ethX.
H.J.
On Fri, 2002-10-25 at 00:56, H. J. Lu wrote:
> It is different from the hardware documentation. The hardware manual says
> it has 2 NICs, NIC 1 (03:07.0) and NIC2 (03:07.1), which makes senses
> to me. NIC 1 is a special one which supports IPMI over LAN. Since we
> only use one NIC now, we'd like to use NIC 1 and call it eth0.
SIOCSIFNAME ioctl. You can call them "haddock" and "chips" if you really
want, or swap the eth%d names about. RH 8.0 allows you to bind an
interface to a mac address too
On Fri, Oct 25, 2002 at 11:00:31AM +0100, Alan Cox wrote:
> On Fri, 2002-10-25 at 00:56, H. J. Lu wrote:
> > It is different from the hardware documentation. The hardware manual says
> > it has 2 NICs, NIC 1 (03:07.0) and NIC2 (03:07.1), which makes senses
> > to me. NIC 1 is a special one which supports IPMI over LAN. Since we
> > only use one NIC now, we'd like to use NIC 1 and call it eth0.
>
> SIOCSIFNAME ioctl. You can call them "haddock" and "chips" if you really
> want, or swap the eth%d names about. RH 8.0 allows you to bind an
> interface to a mac address too
>
It doesn't help RedHat installer over network.
H.J.
Here is a patch to add an option to sort the PCI device by bus, slot
and function.
H.J.
Well, WRT your implementation, the function you add is dead code if your
new config variable is not set, which is not desireable at all.
WRT the overall idea, I would prefer to see what Linus and Martin Mares
(and Ivan K) thought about it, before merging it. The x86 PCI code is
very touchy, and your patch has the potential to change driver probe
order for little gain.
Jeff
On Sat, Oct 26, 2002 at 05:12:51PM -0400, Jeff Garzik wrote:
> Well, WRT your implementation, the function you add is dead code if your
> new config variable is not set, which is not desireable at all.
I am not sure if I understand what you were trying to say. If
CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set, you should be able to
pass "pci=bussort" to kernel to sort the PCI device by bus, slot and
function. Did I miss something?
>
> WRT the overall idea, I would prefer to see what Linus and Martin Mares
> (and Ivan K) thought about it, before merging it. The x86 PCI code is
> very touchy, and your patch has the potential to change driver probe
> order for little gain.
>
The whole purpose of my patch is to change PCI driver probe order in
such a way that is BIOS independent.
H.J.
H. J. Lu wrote:
>On Sat, Oct 26, 2002 at 05:12:51PM -0400, Jeff Garzik wrote:
>
>
>>Well, WRT your implementation, the function you add is dead code if your
>>new config variable is not set, which is not desireable at all.
>>
>>
>
>I am not sure if I understand what you were trying to say. If
>CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set, you should be able to
>pass "pci=bussort" to kernel to sort the PCI device by bus, slot and
>function. Did I miss something?
>
>
The sorting function you add should be covered by the ifdef you add.
>>WRT the overall idea, I would prefer to see what Linus and Martin Mares
>>(and Ivan K) thought about it, before merging it. The x86 PCI code is
>>very touchy, and your patch has the potential to change driver probe
>>order for little gain.
>>
>>
>>
>
>The whole purpose of my patch is to change PCI driver probe order in
>such a way that is BIOS independent.
>
>
The purpose is irrelevant to the effect on existing drivers and systems
-- which is unknown. Making the probe order independent of BIOS
ordering may very well break drivers and systems that are dependent on
BIOS ordering. IOW what looks nice on your system could _likely_ suck
for others. That's what I meant by "x86 PCI code is very touchy."
Jeff
On Sat, Oct 26, 2002 at 05:34:57PM -0400, Jeff Garzik wrote:
> H. J. Lu wrote:
>
> >On Sat, Oct 26, 2002 at 05:12:51PM -0400, Jeff Garzik wrote:
> >
> >
> >>Well, WRT your implementation, the function you add is dead code if your
> >>new config variable is not set, which is not desireable at all.
> >>
> >>
> >
> >I am not sure if I understand what you were trying to say. If
> >CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set, you should be able to
> >pass "pci=bussort" to kernel to sort the PCI device by bus, slot and
> >function. Did I miss something?
> >
> >
> The sorting function you add should be covered by the ifdef you add.
Have you tried? If I did that, the kernel wouldn't even compile. As I
said, when CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC isn't defined, my sorting
function is still available, just not called by default.
>
> >>WRT the overall idea, I would prefer to see what Linus and Martin Mares
> >>(and Ivan K) thought about it, before merging it. The x86 PCI code is
> >>very touchy, and your patch has the potential to change driver probe
> >>order for little gain.
> >>
> >>
> >>
> >
> >The whole purpose of my patch is to change PCI driver probe order in
> >such a way that is BIOS independent.
> >
> >
>
> The purpose is irrelevant to the effect on existing drivers and systems
> -- which is unknown. Making the probe order independent of BIOS
> ordering may very well break drivers and systems that are dependent on
> BIOS ordering. IOW what looks nice on your system could _likely_ suck
> for others. That's what I meant by "x86 PCI code is very touchy."
That is why CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is off by default and
even if it is on, you can still override it by passing "pci=nosort"
or "pci=nobussort" to kernel.
H.J.
H. J. Lu wrote:
>On Sat, Oct 26, 2002 at 05:34:57PM -0400, Jeff Garzik wrote:
>
>
>>H. J. Lu wrote:
>>
>>
>>
>>>On Sat, Oct 26, 2002 at 05:12:51PM -0400, Jeff Garzik wrote:
>>>
>>>
>>>
>>>
>>>>Well, WRT your implementation, the function you add is dead code if your
>>>>new config variable is not set, which is not desireable at all.
>>>>
>>>>
>>>>
>>>>
>>>I am not sure if I understand what you were trying to say. If
>>>CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set, you should be able to
>>>pass "pci=bussort" to kernel to sort the PCI device by bus, slot and
>>>function. Did I miss something?
>>>
>>>
>>>
>>>
>>The sorting function you add should be covered by the ifdef you add.
>>
>>
>
>Have you tried? If I did that, the kernel wouldn't even compile. As I
>said, when CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC isn't defined, my sorting
>function is still available, just not called by default.
>
Which is the entire problem. The kernel compiles and builds just fine
right now, without your function.
If it is "just not called by default" then it clearly can be removed at
compile time when a certain CONFIG_xxx is not defined.
>>>>WRT the overall idea, I would prefer to see what Linus and Martin Mares
>>>>(and Ivan K) thought about it, before merging it. The x86 PCI code is
>>>>very touchy, and your patch has the potential to change driver probe
>>>>order for little gain.
>>>>
>>>>
>>>>
>>>The whole purpose of my patch is to change PCI driver probe order in
>>>such a way that is BIOS independent.
>>>
>>>
>>>
>>The purpose is irrelevant to the effect on existing drivers and systems
>>-- which is unknown. Making the probe order independent of BIOS
>>ordering may very well break drivers and systems that are dependent on
>>BIOS ordering. IOW what looks nice on your system could _likely_ suck
>>for others. That's what I meant by "x86 PCI code is very touchy."
>>
>>
>
>That is why CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is off by default and
>even if it is on, you can still override it by passing "pci=nosort"
>or "pci=nobussort" to kernel.
>
>
Sigh. Repeating, the kernel is still bloated by your sorting function
if CONFIG_PCI_SORT_BY_BUS_SLOT is not defined. The function should go
away if CONFIG_PCI_SORT_BY_BUS_SLOT is not defined.
Jeff
On Sat, Oct 26, 2002 at 06:04:00PM -0400, Jeff Garzik wrote:
> Which is the entire problem. The kernel compiles and builds just fine
> right now, without your function.
>
Without my patch or my function? My patched file has
if ((pci_probe & PCI_BUS_SORT) && !(pci_probe & PCI_NO_SORT))
pci_sort_by_bus_slot_func();
#ifdef CONFIG_PCI_BIOS
else if ((pci_probe & PCI_BIOS_SORT) && !(pci_probe & PCI_NO_SORT))
pcibios_sort();
#endif
That is pci_sort_by_bus_slot_func () will be called if PCI_BUS_SORT is
set. It is independent of whether CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is
set or not, which sets PCI_BUS_SORT. If pci_sort_by_bus_slot_func is
not defined when CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set. How can
kernel compile?
> If it is "just not called by default" then it clearly can be removed at
> compile time when a certain CONFIG_xxx is not defined.
It is controlled by PCI_BUS_SORT, not CONFIG_xxx.
>
>
> >>>>WRT the overall idea, I would prefer to see what Linus and Martin Mares
> >>>>(and Ivan K) thought about it, before merging it. The x86 PCI code is
> >>>>very touchy, and your patch has the potential to change driver probe
> >>>>order for little gain.
> >>>>
> >>>>
> >>>>
> >>>The whole purpose of my patch is to change PCI driver probe order in
> >>>such a way that is BIOS independent.
> >>>
> >>>
> >>>
> >>The purpose is irrelevant to the effect on existing drivers and systems
> >>-- which is unknown. Making the probe order independent of BIOS
> >>ordering may very well break drivers and systems that are dependent on
> >>BIOS ordering. IOW what looks nice on your system could _likely_ suck
> >>for others. That's what I meant by "x86 PCI code is very touchy."
> >>
> >>
> >
> >That is why CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is off by default and
> >even if it is on, you can still override it by passing "pci=nosort"
> >or "pci=nobussort" to kernel.
> >
> >
>
> Sigh. Repeating, the kernel is still bloated by your sorting function
> if CONFIG_PCI_SORT_BY_BUS_SLOT is not defined. The function should go
> away if CONFIG_PCI_SORT_BY_BUS_SLOT is not defined.
I added pci=nobussort since it might not be safe for all MBs. Then I
added "pci=bussort". I have no problem taking out "pci=bussort". If you
don't want "pci=bussort", please say so. I can provide a new patch which
won't define pci_sort_by_bus_slot_func if CONFIG_PCI_SORT_BY_BUS_SLOT
is not set and won't have "pci=bussort" either.
H.J.
H. J. Lu wrote:
>On Sat, Oct 26, 2002 at 06:04:00PM -0400, Jeff Garzik wrote:
>
>
>>Which is the entire problem. The kernel compiles and builds just fine
>>right now, without your function.
>>
>>
>>
>
>Without my patch or my function? My patched file has
>
> if ((pci_probe & PCI_BUS_SORT) && !(pci_probe & PCI_NO_SORT))
> pci_sort_by_bus_slot_func();
>#ifdef CONFIG_PCI_BIOS
> else if ((pci_probe & PCI_BIOS_SORT) && !(pci_probe & PCI_NO_SORT))
> pcibios_sort();
>#endif
>
>That is pci_sort_by_bus_slot_func () will be called if PCI_BUS_SORT is
>set. It is independent of whether CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is
>set or not, which sets PCI_BUS_SORT. If pci_sort_by_bus_slot_func is
>not defined when CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set. How can
>kernel compile?
>
I am obviously not being understood / not communicating myself clearly.
Your patch unconditionally adds a new function.
Don't do that. Wrap it in an ifdef, like you propose below.
>I added pci=nobussort since it might not be safe for all MBs. Then I
>added "pci=bussort". I have no problem taking out "pci=bussort". If you
>don't want "pci=bussort", please say so. I can provide a new patch which
>won't define pci_sort_by_bus_slot_func if CONFIG_PCI_SORT_BY_BUS_SLOT
>is not set and won't have "pci=bussort" either.
>
>
You're still missing the point here too.
Your patch has the potential to suddenly make systems unbootable, to
suddenly reverse people's ethX interface numbering, etc. No command
line options in the world will save lkml from being deluged by tons of
"my system doesn't network anymore" bug reports.
The basic point is "let's proceed with caution, and test test test
before applying this patch."
Jeff
On Sat, Oct 26, 2002 at 06:29:23PM -0400, Jeff Garzik wrote:
>
> >I added pci=nobussort since it might not be safe for all MBs. Then I
> >added "pci=bussort". I have no problem taking out "pci=bussort". If you
> >don't want "pci=bussort", please say so. I can provide a new patch which
> >won't define pci_sort_by_bus_slot_func if CONFIG_PCI_SORT_BY_BUS_SLOT
> >is not set and won't have "pci=bussort" either.
> >
> >
>
> You're still missing the point here too.
>
> Your patch has the potential to suddenly make systems unbootable, to
> suddenly reverse people's ethX interface numbering, etc. No command
That is the whole purpose of my patch. But you will only get it when
you set CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC.
> line options in the world will save lkml from being deluged by tons of
> "my system doesn't network anymore" bug reports.
You will only get it when you set CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC on
purpose by hand.
>
> The basic point is "let's proceed with caution, and test test test
> before applying this patch."
Please state clearly what you have in mind. First you were
saying you didn't like pci_sort_by_bus_slot_func defined when
CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC wass not set. Now you were
saying my patch was dangerous. Please make up your mind.
H.J.
H. J. Lu wrote:
>>The basic point is "let's proceed with caution, and test test test
>>before applying this patch."
>>
>>
>
>Please state clearly what you have in mind. First you were
>saying you didn't like pci_sort_by_bus_slot_func defined when
>CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC wass not set. Now you were
>saying my patch was dangerous. Please make up your mind.
>
>
In my first reply, I clearly separated implementation issues from
commentary on the overall idea. Aside from that, I don't see much value
in further repeating what I've already said.
Jeff
On Sat, 2002-10-26 at 23:58, Jeff Garzik wrote:
> In my first reply, I clearly separated implementation issues from
> commentary on the overall idea. Aside from that, I don't see much value
> in further repeating what I've already said.
Its pretty pointless code but since its done at boot time, just marking
it __init ought to be quite sufficient.
On Sat, Oct 26, 2002 at 06:58:49PM -0400, Jeff Garzik wrote:
> H. J. Lu wrote:
>
> >>The basic point is "let's proceed with caution, and test test test
> >>before applying this patch."
> >>
> >>
> >
> >Please state clearly what you have in mind. First you were
> >saying you didn't like pci_sort_by_bus_slot_func defined when
> >CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC wass not set. Now you were
> >saying my patch was dangerous. Please make up your mind.
> >
> >
>
> In my first reply, I clearly separated implementation issues from
> commentary on the overall idea. Aside from that, I don't see much value
> in further repeating what I've already said.
>
Here is an alternative patch, which won't define pci_sort_by_bus_slot_func
if CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC is not set.
H.J.
s/__devinit/__init/ and the implementation looks ok to me
Jeff Garzik wrote:
> s/__devinit/__init/ and the implementation looks ok to me
...except if your patch can be called in hotplug paths...
On Sun, 2002-10-27 at 01:05, Jeff Garzik wrote:
> Jeff Garzik wrote:
>
> > s/__devinit/__init/ and the implementation looks ok to me
>
>
>
> ...except if your patch can be called in hotplug paths...
We can't go around re-sorting the PCI devices. The pci lists are not
locked sanely as it is
On Sat, Oct 26, 2002 at 08:05:13PM -0400, Jeff Garzik wrote:
> Jeff Garzik wrote:
>
> > s/__devinit/__init/ and the implementation looks ok to me
>
>
>
> ...except if your patch can be called in hotplug paths...
There are plenty of __devini in arch/i386/kernel/pci-pc.c. I will leave
mine alone.
H.J.
On Sat, Oct 26, 2002 at 05:25:26PM -0700, H. J. Lu wrote:
> On Sat, Oct 26, 2002 at 08:05:13PM -0400, Jeff Garzik wrote:
> > Jeff Garzik wrote:
> >
> > > s/__devinit/__init/ and the implementation looks ok to me
> >
> >
> >
> > ...except if your patch can be called in hotplug paths...
>
> There are plenty of __devini in arch/i386/kernel/pci-pc.c. I will leave
> mine alone.
That is because those functions can be called in PCI hotplug paths,
since yours is only called during init, it should be marked as such.
thanks,
greg k-h
On Sun, Oct 27, 2002 at 09:42:49AM -0800, Greg KH wrote:
> On Sat, Oct 26, 2002 at 05:25:26PM -0700, H. J. Lu wrote:
> > On Sat, Oct 26, 2002 at 08:05:13PM -0400, Jeff Garzik wrote:
> > > Jeff Garzik wrote:
> > >
> > > > s/__devinit/__init/ and the implementation looks ok to me
> > >
> > >
> > >
> > > ...except if your patch can be called in hotplug paths...
> >
> > There are plenty of __devini in arch/i386/kernel/pci-pc.c. I will leave
> > mine alone.
>
> That is because those functions can be called in PCI hotplug paths,
> since yours is only called during init, it should be marked as such.
>
Are you telling me that pcibios_sort will be called by PCI hotplug?
H.J.
H. J. Lu wrote:
>On Sun, Oct 27, 2002 at 09:42:49AM -0800, Greg KH wrote:
>
>
>>On Sat, Oct 26, 2002 at 05:25:26PM -0700, H. J. Lu wrote:
>>
>>
>>>On Sat, Oct 26, 2002 at 08:05:13PM -0400, Jeff Garzik wrote:
>>>
>>>
>>>>Jeff Garzik wrote:
>>>>
>>>>
>>>>
>>>>>s/__devinit/__init/ and the implementation looks ok to me
>>>>>
>>>>>
>>>>
>>>>...except if your patch can be called in hotplug paths...
>>>>
>>>>
>>>There are plenty of __devini in arch/i386/kernel/pci-pc.c. I will leave
>>>mine alone.
>>>
>>>
>>That is because those functions can be called in PCI hotplug paths,
>>since yours is only called during init, it should be marked as such.
>>
>>
>>
>
>Are you telling me that pcibios_sort will be called by PCI hotplug?
>
>
no, he's saying __init is correct, as Alan and I said.
Jeff