Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 174893

Summary: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5 - HP xw8400
Product: Red Hat Enterprise Linux 4 Reporter: Jeff Burke <jburke>
Component: kernelAssignee: Jim Paradis <jparadis>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.3CC: acpi-bugzilla, clasohm, jbaron, peterm, rajesh.shah
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-29 23:53:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Fix SHPC hotplug driver problem with missing _BBN none

Description Jeff Burke 2005-12-03 16:08:17 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
While booting the xw8400 hardware platform. The system reports errors in the /var/log/messages

kernel: ACPI: PCI interrupt 0000:1f:00.0[A] -> GSI 17 (level, low) -> IRQ 209
Nov 30 17:57:32 dhcp83-98 kernel: eth0: Tigon3 [partno(BCM95752) rev 6001 PHY(5752)] (PCIX:100MHz:32-bit) 10/100/100
0BaseT Ethernet 00:15:60:10:e2:86
kernel: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
kernel: ACPI: PCI interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 169
Nov 30 17:57:32 dhcp83-98 kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
Nov 30 17:57:32 dhcp83-98 kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
Nov 30 17:57:32 dhcp83-98 kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
kernel: hw_random: RNG not detected
 smartd[3419]: Device: /dev/sda, is SMART capable. Adding to "monitor" list. 
kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
 smartd[3419]: Device: /dev/sdb, opened 
kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
 smartd[3419]: Device /dev/sdb, SATA disks accessed via libata are not currently supported 
by smartmontools. When libata is given an ATA pass-thru ioctl() then an additional '-d libata' device type will be a
dded to smartmontools. 
kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
 smartd[3419]: Unable to register SCSI device /dev/sdb at line 2 of file /etc/smartd.conf 
kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
 smartd[3419]: Unable to register device /dev/sdb (no Directive -d removable). Exiting. 
kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
 smartd: smartd startup failed
kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5
kernel: shpchp: acpi_shpchprm:\_SB_.PCI0 evaluate _BBN fail=0x5
kernel: shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x5


Version-Release number of selected component (if applicable):
kernel-2.6.9-24.EL

How reproducible:
Always

Steps to Reproduce:
1.Install the 2.6.9-24.EL Kernel on the xw8300 hardware platform 
2.Examine the /var/log/messsages file

  

Actual Results:  acpi fail messages are in the /var/log/messages file.

Expected Results:  Normal boot operation should not result is failure messages in the /var/log/messages.

I am unsure if these messages cause adverse effesct to the operation of the system.

Additional info:
Comment 1 Len Brown 2006-01-18 09:22:42 UTC 
These messages are actually from the ACPI PCI Hot Plug Resource Manager.

Still an issue with a kernel newer than 2.6.9-24.EL?
Comment 2 Carsten Clasohm 2006-01-24 17:32:34 UTC 
We are seeing the same error messages on a HP ProLiant DL585 with RHEL4 U2, BIOS
version A01.
Comment 3 Rajesh Shah 2006-01-24 19:02:57 UTC 
The error messages are coming from the SHPC hotplug driver complaining about a 
missing ACPI _BBN method. This method tells it the starting bus number under a 
root bridge. The BIOS on these systems is likely not creating the _BBN method 
since there is a single root bridge in the system, in which case the bus 
number may be assumed to start from 0. 

Are these systems expected to support SHPC hotplug? If no, the messages can be 
ignored since the system doesn't support this capability anyway. If yes, there 
are 2 fix options: 1) have the BIOS create the _BBN method under the root 
bridge 2) make shpchp assume that a missing _BBN implies bus numbering starts 
at 0 (untested patch attached). This patch will break on systems that have 
multiple root bridges or on systems where bus number does not start at 0, but 
such systems are already at risk because the ACPI root bridge driver also 
assumes the same thing.
Comment 4 Rajesh Shah 2006-01-24 19:06:08 UTC 
Created attachment 123629 [details]
Fix SHPC hotplug driver problem with missing _BBN

If the BIOS for a system that supports SHPC hotplug capability does not support
the ACPI _BBN method, assume that bus numbering starts at 0.
Comment 5 Intel Linux ACPI Team 2006-03-21 21:17:01 UTC 
independent of hot plug, we found that enumerating PCI root busses
on some systems failed due to missing _BBN, and so we augmented
the use of _BBN with evaluation of _CRS on the PCI device, which
also can return a bus number.  Maybe the hot plug driver should
do this too.
Comment 6 Jeff Burke 2006-05-09 19:12:45 UTC 
With RHEL4 U4 beta kernel: 2.6.9-36.EL

hda_codec: Unknown model for ALC262, trying auto-probe from BIOS...
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
hw_random: RNG not detected
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
pciehp: acpi_pciehprm:\_SB_.PCI0 evaluate _BBN fail=0x5
pciehp: acpi_pciehprm:get_device PCI ROOT HID fail=0x5
Comment 10 Jim Paradis 2006-09-29 23:53:23 UTC 
The customer has closed this issue as NOTABUG, so I will close this bugzilla as
well.