From: "H. J. Lu" <hjl@lucon.org>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: PCI device order problem
Date: Thu, 24 Oct 2002 17:18:34 -0700 [thread overview]
Message-ID: <20021024171834.A23109@lucon.org> (raw)
In-Reply-To: <3DB88CD1.5090204@pobox.com>; from jgarzik@pobox.com on Thu, Oct 24, 2002 at 08:14:09PM -0400
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.
next prev parent reply other threads:[~2002-10-25 0:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021024171834.A23109@lucon.org \
--to=hjl@lucon.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.