Re: Unable to handle kernel NULL pointer... on cat /proc/pci

Gabriel Paubert (paubert@iram.es)
Thu, 25 Sep 1997 19:38:08 +0200 (METDST)


On Thu, 25 Sep 1997, Rogier Wolff wrote:

> I expect the 0xffffffff to be a "read of an non-driven bus". This usually
> turns out to lead to the value <all ones> however bit-errors are allowed:
> nobody drove the bus.

Nope, PCI does only have weak resistors to effectively use reflections for
full level switching (BTW: doing myself microwave hardware, I hate the
method, it saves on power but it's ugly). In the time between the address
phase and the master abort (5 clocks, 150 ns), these resistors do not
have time to pull up effectively the bus to a high level. The PCI HW
specifications require that on a read terminated with a master abort, the
master which is aborting returns all ones on the other side of the bridge
(whether host bridge, PCI to PCI bridges).

In other words, the resistors are only here to prevent the bus from
floating to undeterminate levels, or to oscillate at the local FM radio
frequency because this could increase current consumption and even
possibly damage chips.

> On the other hand, you're saying there is a well-defined error
> mechanism to detect non-present devices..... Maybe some chipsets don't
> consider it important to implement that for configuration space?

This is part of the PCI specification, performing master abort is
especially important on configuration cycles since you are never sure that
a device will answer. This will set a status bit (Received Master Abort)
in the status register of the master bridge. To perform this test properly
you should prevent access to PCI from all processors, because any access from
a driver to PCI can end with a master abort.

However, the guy who had the problem is now happy thanks to the following
patch which simply performs a sanity check on the header type register.
For now, only header type 0 and 1 are defined, but somebody had a docking
station bridge with header type 2, so any header type between 3 and 127 is
rejected as invalid with a warning at boot. I don't consider this patch as
the solution, but as a simple workaround for (very probably) flaky
hardware. Better solutions could be investigated for 2.1.x, not for 2.0.x.

Gabriel.
==============================================================================
--- linux-2.0.30/drivers/pci/pci.c.orig Wed Sep 24 07:38:03 1997
+++ linux-2.0.30/drivers/pci/pci.c Thu Sep 25 06:19:51 1997
@@ -794,6 +794,12 @@
if (PCI_FUNC(devfn) == 0) {
pcibios_read_config_byte(bus->number, devfn,
PCI_HEADER_TYPE, &hdr_type);
+ if ( (hdr_type&0x7f) > 2) {
+ hdr_type &= 0x7f;
+ printk("Warning : unknown header type %d, probable HW problem,\n device %d on bus %d not registered in /proc/pci!\n",
+ hdr_type, PCI_SLOT(devfn), bus->number);
+ continue;
+ }
} else if (!(hdr_type & 0x80)) {
/* not a multi-function device */
continue;
==============================================================================