Bug 13546
| Summary: | Too-verbose output from PCI probe at bootup | ||
|---|---|---|---|
| Product: | Base System | Reporter: | parag <parag> |
| Component: | kern | Assignee: | Stefan Eßer <se> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 3.2-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
Following up to my easlier bug-report (kern/13546), I looked over the PCI code in STABLE and CURRENT more closely. The CURRENT code does not display this messaage because the code is no longer there! CURRENT probes for and attaches PCI bridges as bus/devices and STABLE does not. In pci/pci.c, the STABLE version uses the "bushigh" return value from pci_probebus() to determine the next PCI bus number to probe. My guess is that the 4xPPRO box I've got lies and always returns one more bus to probe for this code. CURRENT's pci/pci.c however doesn't use this "bushigh" information from pci_add_children(), and indeed doesn't use its return value at all. (The code determining bushigh can be deleted and pci_add_children should return "void".) It seems to detect the bridge chip and attach that as a device and then probes under it. STABLE doesn't seem to do this and its code is scattered with XXX througout. So I think my earlier patch for simply wrapping the "Probing PCI bus" message with an "if (bootverbose)" is the right solution/workaround for systems like mine. Not that it's a big deal - it's easy enough for me to patch by hand - but I thought that others may be similarly afflicted. -- Parag Patel Here's a better fix. Turns out that this 4xPPro box has two "Orion"
chips in it, and the code that picks off the number of subordinate buses
returns 255 for whatever reason. The fix is copied from the
fixbushigh_450nx() routine into the fixbushigh_orion() routine, which
appears to have the same problem.
The fix could be made generic and moved out of both bushigh routines if
there are no systems out there with 255 subordinate buses. The magic
number 255 may mean different things to different chipsets so I settled
for this Orion-specific fix.
-- Parag Patel
*** /sys/pci/pcisupport.c Sat Sep 4 04:02:49 1999
- --- pcisupport.c Wed Sep 8 12:03:00 1999
***************
*** 129,134 ****
- --- 129,149 ----
{
tag->secondarybus = pci_cfgread(tag, 0x4a, 1);
tag->subordinatebus = pci_cfgread(tag, 0x4b, 1);
+
+ if (tag->subordinatebus == 255) {
+ printf("fixbushigh_orion: bogus highest PCI bus %d",
+ tag->subordinatebus);
+ #ifdef NBUS
+ tag->subordinatebus = NBUS - 2;
+ #else
+ tag->subordinatebus = 10;
+ #endif
+ printf(", reduced to %d\n", tag->subordinatebus);
+ }
+
+ if (bootverbose)
+ printf("fixbushigh_orion: subordinatebus is %d\n",
+ tag->subordinatebus);
}
static void
Responsible Changed From-To: freebsd-bugs->se Stefan, you commited the code in pci.c which the first of the two patches deals with. Can you please have a look at this and close this PR if you do not think it is worth fixing in RELENG_3. It is already fixed in RELENG_4 and HEAD according to the originator. State Changed From-To: open->closed RELENG_3 is now a dormant branch. The submitter reports that RELENG_4 and later branches do not have this bug. |
The PCI probe code is much too verbose when it probes for PCI busses that do not exist. On this system, I get this message: Probing for devices on PCI bus 2 Probing for devices on PCI bus 3 ... Probing for devices on PCI bus 255 about 255 times. I'm not sure why it's so chatty, and CURRENT does not display all these messages. My fix below simply puts the verbose messages under "bootverbose", so the messages can still be displayed if one boots "-v" but not otherwise. Fix: *************** ! printf("Probing for devices on PCI bus %d:\n", bus); newbushigh = pci_probebus(bus); if (bushigh < newbushigh) --- 547,555 ---- while (bus <= bushigh) { int newbushigh; ! if (bootverbose) ! printf("Probing for devices on PCI bus %d:\n", bus); ! newbushigh = pci_probebus(bus); if (bushigh < newbushigh)--Om5PrX1hCbeiJhy67revBRNxEO2KSTPuIhB3NeY3YuWLNoDI Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" *** 547,553 **** while (bus <= bushigh) { int newbushigh; How-To-Repeat: Simply boot the kernel on a similar machine.