)]}'
{
  "commit": "6b4b78fed47e7380dfe9280b154e8b9bfcd4c86c",
  "tree": "9fbf5135f4ba87fc68681bcd8996d509cac6f9e9",
  "parents": [
    "49c61cca2b6591a28ffa4abb73c718091f569746"
  ],
  "author": {
    "name": "Matt Domsch",
    "email": "Matt_Domsch@dell.com",
    "time": "Fri Sep 29 15:23:23 2006 -0500"
  },
  "committer": {
    "name": "Greg Kroah-Hartman",
    "email": "gregkh@suse.de",
    "time": "Wed Oct 18 11:36:12 2006 -0700"
  },
  "message": "PCI: optionally sort device lists breadth-first\n\nProblem:\nNew Dell PowerEdge servers have 2 embedded ethernet ports, which are\nlabeled NIC1 and NIC2 on the chassis, in the BIOS setup screens, and\nin the printed documentation.  Assuming no other add-in ethernet ports\nin the system, Linux 2.4 kernels name these eth0 and eth1\nrespectively.  Many people have come to expect this naming.  Linux 2.6\nkernels name these eth1 and eth0 respectively (backwards from\nexpectations).  I also have reports that various Sun and HP servers\nhave similar behavior.\n\n\nRoot cause:\nLinux 2.4 kernels walk the pci_devices list, which happens to be\nsorted in breadth-first order (or pcbios_find_device order on i386,\nwhich most often is breadth-first also).  2.6 kernels have both the\npci_devices list and the pci_bus_type.klist_devices list, the latter\nis what is walked at driver load time to match the pci_id tables; this\nklist happens to be in depth-first order.\n\nOn systems where, for physical routing reasons, NIC1 appears on a\nlower bus number than NIC2, but NIC2\u0027s bridge is discovered first in\nthe depth-first ordering, NIC2 will be discovered before NIC1.  If the\nlist were sorted breadth-first, NIC1 would be discovered before NIC2.\n\nA PowerEdge 1955 system has the following topology which easily\nexhibits the difference between depth-first and breadth-first device\nlists.\n\n-[0000:00]-+-00.0  Intel Corporation 5000P Chipset Memory Controller Hub\n           +-02.0-[0000:03-08]--+-00.0-[0000:04-07]--+-00.0-[0000:05-06]----00.0-[0000:06]----00.0  Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC2, 2.4 kernel name eth1, 2.6 kernel name eth0)\n           +-1c.0-[0000:01-02]----00.0-[0000:02]----00.0  Broadcom Corporation NetXtreme II BCM5708S Gigabit Ethernet (labeled NIC1, 2.4 kernel name eth0, 2.6 kernel name eth1)\n\n\nOther factors, such as device driver load order and the presence of\nPCI slots at various points in the bus hierarchy further complicate\nthis problem; I\u0027m not trying to solve those here, just restore the\ndevice order, and thus basic behavior, that 2.4 kernels had.\n\n\nSolution:\n\nThe solution can come in multiple steps.\n\nSuggested fix #1: kernel\nPatch below optionally sorts the two device lists into breadth-first\nordering to maintain compatibility with 2.4 kernels.  It adds two new\ncommand line options:\n  pci\u003dbfsort\n  pci\u003dnobfsort\nto force the sort order, or not, as you wish.  It also adds DMI checks\nfor the specific Dell systems which exhibit \"backwards\" ordering, to\nmake them \"right\".\n\n\nSuggested fix #2: udev rules from userland\nMany people also have the expectation that embedded NICs are always\ndiscovered before add-in NICs (which this patch does not try to do).\nUsing the PCI IRQ Routing Table provided by system BIOS, it\u0027s easy to\ndetermine which PCI devices are embedded, or if add-in, which PCI slot\nthey\u0027re in.  I\u0027m working on a tool that would allow udev to name\nethernet devices in ascending embedded, slot 1 .. slot N order,\nsubsort by PCI bus/dev/fn breadth-first.  It\u0027ll be possible to use it\nindependent of udev as well for those distributions that don\u0027t use\nudev in their installers.\n\nSuggested fix #3: system board routing rules\nOne can constrain the system board layout to put NIC1 ahead of NIC2\nregardless of breadth-first or depth-first discovery order.  This adds\na significant level of complexity to board routing, and may not be\npossible in all instances (witness the above systems from several\nmajor manufacturers).  I don\u0027t want to encourage this particular train\nof thought too far, at the expense of not doing #1 or #2 above.\n\n\nFeedback appreciated.  Patch tested on a Dell PowerEdge 1955 blade\nwith 2.6.18.\n\nYou\u0027ll also note I took some liberty and temporarily break the klist\nabstraction to simplify and speed up the sort algorithm.  I think\nthat\u0027s both safe and appropriate in this instance.\n\n\nSigned-off-by: Matt Domsch \u003cMatt_Domsch@dell.com\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\n\n\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ff571f9298e0530bb38d3ffdaabea01f1b4aec17",
      "old_mode": 33188,
      "old_path": "Documentation/kernel-parameters.txt",
      "new_id": "dd00fd556a60abad15662319d5c46fd0f166b26a",
      "new_mode": 33188,
      "new_path": "Documentation/kernel-parameters.txt"
    },
    {
      "type": "modify",
      "old_id": "68bce194e688a1903480425b3db8dc37802127f0",
      "old_mode": 33188,
      "old_path": "arch/i386/pci/common.c",
      "new_id": "6d5ace845e445b2eca6a25452e100e380e0467b4",
      "new_mode": 33188,
      "new_path": "arch/i386/pci/common.c"
    },
    {
      "type": "modify",
      "old_id": "1814f74569c63efd415bdfa4393a9471107a3742",
      "old_mode": 33188,
      "old_path": "arch/i386/pci/pci.h",
      "new_id": "ad065cebd7b9e1d94fb665c147d01cc90f36412d",
      "new_mode": 33188,
      "new_path": "arch/i386/pci/pci.h"
    },
    {
      "type": "modify",
      "old_id": "a3b0a5eb5054fefcc0e76e72b838fac1146fd310",
      "old_mode": 33188,
      "old_path": "drivers/pci/probe.c",
      "new_id": "e159d6604494acd62a617efcca0b6a3b26a8d4d4",
      "new_mode": 33188,
      "new_path": "drivers/pci/probe.c"
    },
    {
      "type": "modify",
      "old_id": "09bf88fc80c5fa7a48d97472ec647566cbeedb0a",
      "old_mode": 33188,
      "old_path": "include/linux/pci.h",
      "new_id": "4689e2a699c001b797db97888f183be3b9dd396c",
      "new_mode": 33188,
      "new_path": "include/linux/pci.h"
    }
  ]
}