* PCI device order problem
@ 2002-10-24 23:39 H. J. Lu
2002-10-24 23:49 ` Jeff Garzik
0 siblings, 1 reply; 31+ messages in thread
From: H. J. Lu @ 2002-10-24 23:39 UTC (permalink / raw)
To: linux kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PCI device order problem
2002-10-24 23:39 PCI device order problem H. J. Lu
@ 2002-10-24 23:49 ` Jeff Garzik
2002-10-24 23:56 ` H. J. Lu
0 siblings, 1 reply; 31+ messages in thread
From: Jeff Garzik @ 2002-10-24 23:49 UTC (permalink / raw)
To: H. J. Lu; +Cc: linux kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: PCI device order problem
2002-10-24 23:49 ` Jeff Garzik
@ 2002-10-24 23:56 ` H. J. Lu
2002-10-25 0:14 ` Jeff Garzik
2002-10-25 10:00 ` Alan Cox
0 siblings, 2 replies; 31+ messages in thread
From: H. J. Lu @ 2002-10-24 23:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PCI device order problem
2002-10-24 23:56 ` H. J. Lu
@ 2002-10-25 0:14 ` Jeff Garzik
2002-10-25 0:18 ` H. J. Lu
2002-10-25 10:00 ` Alan Cox
1 sibling, 1 reply; 31+ messages in thread
From: Jeff Garzik @ 2002-10-25 0:14 UTC (permalink / raw)
To: H. J. Lu; +Cc: linux kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: PCI device order problem
2002-10-25 0:14 ` Jeff Garzik
@ 2002-10-25 0:18 ` H. J. Lu
0 siblings, 0 replies; 31+ messages in thread
From: H. J. Lu @ 2002-10-25 0:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PCI device order problem
2002-10-24 23:56 ` H. J. Lu
2002-10-25 0:14 ` Jeff Garzik
@ 2002-10-25 10:00 ` Alan Cox
2002-10-25 16:11 ` H. J. Lu
1 sibling, 1 reply; 31+ messages in thread
From: Alan Cox @ 2002-10-25 10:00 UTC (permalink / raw)
To: H. J. Lu; +Cc: Jeff Garzik, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PCI device order problem
2002-10-25 10:00 ` Alan Cox
@ 2002-10-25 16:11 ` H. J. Lu
2002-10-26 3:26 ` PATCH: Support PCI device sorting (Re: PCI device order problem) H. J. Lu
0 siblings, 1 reply; 31+ messages in thread
From: H. J. Lu @ 2002-10-25 16:11 UTC (permalink / raw)
To: Alan Cox; +Cc: Jeff Garzik, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-25 16:11 ` H. J. Lu
@ 2002-10-26 3:26 ` H. J. Lu
2002-10-26 21:12 ` Jeff Garzik
0 siblings, 1 reply; 31+ messages in thread
From: H. J. Lu @ 2002-10-26 3:26 UTC (permalink / raw)
To: Alan Cox; +Cc: Jeff Garzik, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 90 bytes --]
Here is a patch to add an option to sort the PCI device by bus, slot
and function.
H.J.
[-- Attachment #2: linux-2.4.18-pci-order.patch --]
[-- Type: text/plain, Size: 3295 bytes --]
--- linux/arch/i386/config.in.order Thu Oct 24 21:09:20 2002
+++ linux/arch/i386/config.in Fri Oct 25 16:34:13 2002
@@ -257,6 +257,7 @@ else
if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
define_bool CONFIG_PCI_DIRECT y
fi
+ bool ' Sort device by bus, slot, function' CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC
fi
fi
--- linux/arch/i386/kernel/pci-i386.h.order Sun Nov 11 10:09:32 2001
+++ linux/arch/i386/kernel/pci-i386.h Fri Oct 25 19:26:51 2002
@@ -21,6 +21,7 @@
#define PCI_ASSIGN_ROMS 0x1000
#define PCI_BIOS_IRQ_SCAN 0x2000
#define PCI_ASSIGN_ALL_BUSSES 0x4000
+#define PCI_BUS_SORT 0x8000
extern unsigned int pci_probe;
--- linux/arch/i386/kernel/pci-pc.c.order Thu Oct 24 21:09:20 2002
+++ linux/arch/i386/kernel/pci-pc.c Fri Oct 25 19:58:18 2002
@@ -19,7 +19,11 @@
#include "pci-i386.h"
+#ifdef CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC
+unsigned int pci_probe = PCI_PROBE_BIOS | PCI_BUS_SORT | PCI_PROBE_CONF1 | PCI_PROBE_CONF2;
+#else
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2;
+#endif
int pcibios_last_bus = -1;
struct pci_bus *pci_root_bus = NULL;
@@ -871,6 +875,53 @@ static struct pci_ops * __devinit pci_fi
return NULL;
}
+static void __devinit pci_sort_by_bus_slot_func(void)
+{
+ LIST_HEAD(sorted_devices);
+ struct list_head *ln;
+ struct pci_dev *dev, *d;
+ int n;
+ int s, slot;
+ int f, func;
+
+ printk(KERN_INFO "PCI: Sorting device list by bus, slot, function...\n");
+
+ /* Starting from bus 0, ... */
+ for (n=0; n <= pcibios_last_bus; n++) {
+ if (!pci_bus_exists(&pci_root_buses, n))
+ continue;
+
+ while (!list_empty(&pci_devices)) {
+ /* Find the lowest remaining PCI slot/function. */
+ slot = INT_MAX;
+ func = INT_MAX;
+ dev = NULL;
+ for (ln=pci_devices.next; ln != &pci_devices; ln=ln->next) {
+ d = pci_dev_g(ln);
+ s = PCI_SLOT(d->devfn);
+ f = PCI_FUNC(d->devfn);
+ if (d->bus->number == n
+ && (s < slot || (s == slot && f < func))) {
+ slot = s;
+ func = f;
+ dev = d;
+ }
+ }
+
+ if (dev) {
+ list_del(&dev->global_list);
+ list_add_tail(&dev->global_list, &sorted_devices);
+ }
+ else {
+ /* Stop if we don't find any devices on
+ this bus. */
+ break;
+ }
+ }
+ }
+ list_splice(&sorted_devices, &pci_devices);
+}
+
/*
* 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
@@ -1392,8 +1443,10 @@ void __init pcibios_init(void)
pcibios_resource_survey();
+ if ((pci_probe & PCI_BUS_SORT) && !(pci_probe & PCI_NO_SORT))
+ pci_sort_by_bus_slot_func();
#ifdef CONFIG_PCI_BIOS
- if ((pci_probe & PCI_BIOS_SORT) && !(pci_probe & PCI_NO_SORT))
+ else if ((pci_probe & PCI_BIOS_SORT) && !(pci_probe & PCI_NO_SORT))
pcibios_sort();
#endif
}
@@ -1404,6 +1457,17 @@ char * __devinit pcibios_setup(char *st
pci_probe = 0;
return NULL;
}
+#ifdef CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC
+ else if (!strcmp(str, "nobussort")) {
+ pci_probe &= ~PCI_BUS_SORT;
+ return NULL;
+ }
+#else
+ else if (!strcmp(str, "bussort")) {
+ pci_probe |= PCI_BUS_SORT;
+ return NULL;
+ }
+#endif
#ifdef CONFIG_PCI_BIOS
else if (!strcmp(str, "bios")) {
pci_probe = PCI_PROBE_BIOS;
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 3:26 ` PATCH: Support PCI device sorting (Re: PCI device order problem) H. J. Lu
@ 2002-10-26 21:12 ` Jeff Garzik
2002-10-26 21:27 ` H. J. Lu
0 siblings, 1 reply; 31+ messages in thread
From: Jeff Garzik @ 2002-10-26 21:12 UTC (permalink / raw)
To: H. J. Lu; +Cc: Alan Cox, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 21:12 ` Jeff Garzik
@ 2002-10-26 21:27 ` H. J. Lu
2002-10-26 21:34 ` Jeff Garzik
0 siblings, 1 reply; 31+ messages in thread
From: H. J. Lu @ 2002-10-26 21:27 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 21:27 ` H. J. Lu
@ 2002-10-26 21:34 ` Jeff Garzik
2002-10-26 21:44 ` H. J. Lu
0 siblings, 1 reply; 31+ messages in thread
From: Jeff Garzik @ 2002-10-26 21:34 UTC (permalink / raw)
To: H. J. Lu; +Cc: Alan Cox, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 21:34 ` Jeff Garzik
@ 2002-10-26 21:44 ` H. J. Lu
2002-10-26 22:04 ` Jeff Garzik
0 siblings, 1 reply; 31+ messages in thread
From: H. J. Lu @ 2002-10-26 21:44 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 21:44 ` H. J. Lu
@ 2002-10-26 22:04 ` Jeff Garzik
2002-10-26 22:20 ` H. J. Lu
0 siblings, 1 reply; 31+ messages in thread
From: Jeff Garzik @ 2002-10-26 22:04 UTC (permalink / raw)
To: H. J. Lu; +Cc: Alan Cox, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 22:04 ` Jeff Garzik
@ 2002-10-26 22:20 ` H. J. Lu
2002-10-26 22:29 ` Jeff Garzik
0 siblings, 1 reply; 31+ messages in thread
From: H. J. Lu @ 2002-10-26 22:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 22:20 ` H. J. Lu
@ 2002-10-26 22:29 ` Jeff Garzik
2002-10-26 22:53 ` H. J. Lu
0 siblings, 1 reply; 31+ messages in thread
From: Jeff Garzik @ 2002-10-26 22:29 UTC (permalink / raw)
To: H. J. Lu; +Cc: Alan Cox, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 22:29 ` Jeff Garzik
@ 2002-10-26 22:53 ` H. J. Lu
2002-10-26 22:58 ` Jeff Garzik
0 siblings, 1 reply; 31+ messages in thread
From: H. J. Lu @ 2002-10-26 22:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 22:53 ` H. J. Lu
@ 2002-10-26 22:58 ` Jeff Garzik
2002-10-26 23:45 ` Alan Cox
2002-10-26 23:53 ` H. J. Lu
0 siblings, 2 replies; 31+ messages in thread
From: Jeff Garzik @ 2002-10-26 22:58 UTC (permalink / raw)
To: H. J. Lu; +Cc: Alan Cox, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 22:58 ` Jeff Garzik
@ 2002-10-26 23:45 ` Alan Cox
2002-10-26 23:53 ` H. J. Lu
1 sibling, 0 replies; 31+ messages in thread
From: Alan Cox @ 2002-10-26 23:45 UTC (permalink / raw)
To: Jeff Garzik; +Cc: H. J. Lu, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 22:58 ` Jeff Garzik
2002-10-26 23:45 ` Alan Cox
@ 2002-10-26 23:53 ` H. J. Lu
2002-10-26 23:57 ` Jeff Garzik
1 sibling, 1 reply; 31+ messages in thread
From: H. J. Lu @ 2002-10-26 23:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]
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.
[-- Attachment #2: linux-2.4.18-pci-order-2.patch --]
[-- Type: text/plain, Size: 3224 bytes --]
--- linux/arch/i386/config.in.order Thu Oct 24 21:09:20 2002
+++ linux/arch/i386/config.in Fri Oct 25 16:34:13 2002
@@ -257,6 +257,7 @@ else
if [ "$CONFIG_PCI_GODIRECT" = "y" -o "$CONFIG_PCI_GOANY" = "y" ]; then
define_bool CONFIG_PCI_DIRECT y
fi
+ bool ' Sort device by bus, slot, function' CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC
fi
fi
--- linux/arch/i386/kernel/pci-i386.h.order Sun Nov 11 10:09:32 2001
+++ linux/arch/i386/kernel/pci-i386.h Fri Oct 25 19:26:51 2002
@@ -21,6 +21,7 @@
#define PCI_ASSIGN_ROMS 0x1000
#define PCI_BIOS_IRQ_SCAN 0x2000
#define PCI_ASSIGN_ALL_BUSSES 0x4000
+#define PCI_BUS_SORT 0x8000
extern unsigned int pci_probe;
--- linux/arch/i386/kernel/pci-pc.c.order Thu Oct 24 21:09:20 2002
+++ linux/arch/i386/kernel/pci-pc.c Sat Oct 26 16:14:00 2002
@@ -19,7 +19,11 @@
#include "pci-i386.h"
+#ifdef CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC
+unsigned int pci_probe = PCI_PROBE_BIOS | PCI_BUS_SORT | PCI_PROBE_CONF1 | PCI_PROBE_CONF2;
+#else
unsigned int pci_probe = PCI_PROBE_BIOS | PCI_PROBE_CONF1 | PCI_PROBE_CONF2;
+#endif
int pcibios_last_bus = -1;
struct pci_bus *pci_root_bus = NULL;
@@ -871,6 +875,55 @@ static struct pci_ops * __devinit pci_fi
return NULL;
}
+#ifdef CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC
+static void __devinit pci_sort_by_bus_slot_func(void)
+{
+ LIST_HEAD(sorted_devices);
+ struct list_head *ln;
+ struct pci_dev *dev, *d;
+ int n;
+ int s, slot;
+ int f, func;
+
+ printk(KERN_INFO "PCI: Sorting device list by bus, slot, function...\n");
+
+ /* Starting from bus 0, ... */
+ for (n=0; n <= pcibios_last_bus; n++) {
+ if (!pci_bus_exists(&pci_root_buses, n))
+ continue;
+
+ while (!list_empty(&pci_devices)) {
+ /* Find the lowest remaining PCI slot/function. */
+ slot = INT_MAX;
+ func = INT_MAX;
+ dev = NULL;
+ for (ln=pci_devices.next; ln != &pci_devices; ln=ln->next) {
+ d = pci_dev_g(ln);
+ s = PCI_SLOT(d->devfn);
+ f = PCI_FUNC(d->devfn);
+ if (d->bus->number == n
+ && (s < slot || (s == slot && f < func))) {
+ slot = s;
+ func = f;
+ dev = d;
+ }
+ }
+
+ if (dev) {
+ list_del(&dev->global_list);
+ list_add_tail(&dev->global_list, &sorted_devices);
+ }
+ else {
+ /* Stop if we don't find any devices on
+ this bus. */
+ break;
+ }
+ }
+ }
+ list_splice(&sorted_devices, &pci_devices);
+}
+#endif
+
/*
* 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
@@ -1392,6 +1445,11 @@ void __init pcibios_init(void)
pcibios_resource_survey();
+#ifdef CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC
+ if ((pci_probe & PCI_BUS_SORT) && !(pci_probe & PCI_NO_SORT))
+ pci_sort_by_bus_slot_func();
+ else
+#endif
#ifdef CONFIG_PCI_BIOS
if ((pci_probe & PCI_BIOS_SORT) && !(pci_probe & PCI_NO_SORT))
pcibios_sort();
@@ -1404,6 +1462,12 @@ char * __devinit pcibios_setup(char *st
pci_probe = 0;
return NULL;
}
+#ifdef CONFIG_PCI_SORT_BY_BUS_SLOT_FUNC
+ else if (!strcmp(str, "nobussort")) {
+ pci_probe &= ~PCI_BUS_SORT;
+ return NULL;
+ }
+#endif
#ifdef CONFIG_PCI_BIOS
else if (!strcmp(str, "bios")) {
pci_probe = PCI_PROBE_BIOS;
^ permalink raw reply [flat|nested] 31+ messages in thread* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 23:53 ` H. J. Lu
@ 2002-10-26 23:57 ` Jeff Garzik
2002-10-27 0:05 ` Jeff Garzik
0 siblings, 1 reply; 31+ messages in thread
From: Jeff Garzik @ 2002-10-26 23:57 UTC (permalink / raw)
To: H. J. Lu; +Cc: Alan Cox, Linux Kernel Mailing List
s/__devinit/__init/ and the implementation looks ok to me
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-26 23:57 ` Jeff Garzik
@ 2002-10-27 0:05 ` Jeff Garzik
2002-10-27 0:25 ` H. J. Lu
2002-10-27 0:30 ` Alan Cox
0 siblings, 2 replies; 31+ messages in thread
From: Jeff Garzik @ 2002-10-27 0:05 UTC (permalink / raw)
To: H. J. Lu; +Cc: Alan Cox, Linux Kernel Mailing List
Jeff Garzik wrote:
> s/__devinit/__init/ and the implementation looks ok to me
...except if your patch can be called in hotplug paths...
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-27 0:05 ` Jeff Garzik
@ 2002-10-27 0:25 ` H. J. Lu
2002-10-27 17:42 ` Greg KH
2002-10-27 0:30 ` Alan Cox
1 sibling, 1 reply; 31+ messages in thread
From: H. J. Lu @ 2002-10-27 0:25 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-27 0:25 ` H. J. Lu
@ 2002-10-27 17:42 ` Greg KH
2002-10-27 20:42 ` H. J. Lu
0 siblings, 1 reply; 31+ messages in thread
From: Greg KH @ 2002-10-27 17:42 UTC (permalink / raw)
To: H. J. Lu; +Cc: Jeff Garzik, Alan Cox, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-27 17:42 ` Greg KH
@ 2002-10-27 20:42 ` H. J. Lu
2002-10-28 0:26 ` Jeff Garzik
0 siblings, 1 reply; 31+ messages in thread
From: H. J. Lu @ 2002-10-27 20:42 UTC (permalink / raw)
To: Greg KH; +Cc: Jeff Garzik, Alan Cox, Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-27 20:42 ` H. J. Lu
@ 2002-10-28 0:26 ` Jeff Garzik
0 siblings, 0 replies; 31+ messages in thread
From: Jeff Garzik @ 2002-10-28 0:26 UTC (permalink / raw)
To: H. J. Lu; +Cc: Greg KH, Alan Cox, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PATCH: Support PCI device sorting (Re: PCI device order problem)
2002-10-27 0:05 ` Jeff Garzik
2002-10-27 0:25 ` H. J. Lu
@ 2002-10-27 0:30 ` Alan Cox
1 sibling, 0 replies; 31+ messages in thread
From: Alan Cox @ 2002-10-27 0:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: H. J. Lu, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: PCI device order problem
@ 2002-10-25 0:21 Leech, Christopher
2002-10-25 0:31 ` Jeff Garzik
2002-10-25 0:40 ` H. J. Lu
0 siblings, 2 replies; 31+ messages in thread
From: Leech, Christopher @ 2002-10-25 0:21 UTC (permalink / raw)
To: 'Jeff Garzik', H. J. Lu; +Cc: linux kernel
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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PCI device order problem
2002-10-25 0:21 PCI device order problem Leech, Christopher
@ 2002-10-25 0:31 ` Jeff Garzik
2002-10-25 0:40 ` H. J. Lu
1 sibling, 0 replies; 31+ messages in thread
From: Jeff Garzik @ 2002-10-25 0:31 UTC (permalink / raw)
To: Leech, Christopher; +Cc: H. J. Lu, linux kernel
There is also the pci=nosort kernel command line parameter.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: PCI device order problem
2002-10-25 0:21 PCI device order problem Leech, Christopher
2002-10-25 0:31 ` Jeff Garzik
@ 2002-10-25 0:40 ` H. J. Lu
1 sibling, 0 replies; 31+ messages in thread
From: H. J. Lu @ 2002-10-25 0:40 UTC (permalink / raw)
To: Leech, Christopher; +Cc: 'Jeff Garzik', linux kernel
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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: PCI device order problem
@ 2002-10-25 0:25 Leech, Christopher
2002-10-25 0:39 ` H. J. Lu
0 siblings, 1 reply; 31+ messages in thread
From: Leech, Christopher @ 2002-10-25 0:25 UTC (permalink / raw)
To: 'H. J. Lu', Jeff Garzik; +Cc: linux kernel
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:hjl@lucon.org]
> 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2002-10-28 0:20 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-24 23:39 PCI device order problem H. J. Lu
2002-10-24 23:49 ` Jeff Garzik
2002-10-24 23:56 ` H. J. Lu
2002-10-25 0:14 ` Jeff Garzik
2002-10-25 0:18 ` H. J. Lu
2002-10-25 10:00 ` Alan Cox
2002-10-25 16:11 ` H. J. Lu
2002-10-26 3:26 ` PATCH: Support PCI device sorting (Re: PCI device order problem) H. J. Lu
2002-10-26 21:12 ` Jeff Garzik
2002-10-26 21:27 ` H. J. Lu
2002-10-26 21:34 ` Jeff Garzik
2002-10-26 21:44 ` H. J. Lu
2002-10-26 22:04 ` Jeff Garzik
2002-10-26 22:20 ` H. J. Lu
2002-10-26 22:29 ` Jeff Garzik
2002-10-26 22:53 ` H. J. Lu
2002-10-26 22:58 ` Jeff Garzik
2002-10-26 23:45 ` Alan Cox
2002-10-26 23:53 ` H. J. Lu
2002-10-26 23:57 ` Jeff Garzik
2002-10-27 0:05 ` Jeff Garzik
2002-10-27 0:25 ` H. J. Lu
2002-10-27 17:42 ` Greg KH
2002-10-27 20:42 ` H. J. Lu
2002-10-28 0:26 ` Jeff Garzik
2002-10-27 0:30 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2002-10-25 0:21 PCI device order problem Leech, Christopher
2002-10-25 0:31 ` Jeff Garzik
2002-10-25 0:40 ` H. J. Lu
2002-10-25 0:25 Leech, Christopher
2002-10-25 0:39 ` H. J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).