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

Gabriel Paubert (paubert@iram.es)
Wed, 24 Sep 1997 17:52:44 +0200 (METDST)


On Wed, 24 Sep 1997, Magnus Sjoegren wrote:

> Ok, I don't know if this is any help but I am adding additional info.
>
> The unknown pci device warning message at bootup sometimes display
> Warning : Unknown PCI device (eeff:ffff). Please read include/linux/pci.h
> instead of ^
> Warning : Unknown PCI device (efff:ffff). Please read include/linux/pci.h

So either your chipset has suffered, or your hardware is very broken.
It also finds that all devices have I/O at 0xeefffffc or 0xeffffffc,
that they are master and BIST capable and a lot of funny properties, does
it ?

> In simpler words, this will reduce the warning messages at bootup and
> simultaneously reduce the input of unknown devices in /proc/pci?

It should.
>
> As it is now I can only see unknown devices when viewing /proc/pci.
>

So you overflow the buffer when cat'ing /proc/pci, for sure.

> Im willing to give it a try.

Ok try that one, you may remove the preceding one:
=============================================================================
--- pci.c.orig Wed Sep 24 07:38:03 1997
+++ pci.c Wed Sep 24 15:18:42 1997
@@ -794,6 +794,11 @@
if (PCI_FUNC(devfn) == 0) {
pcibios_read_config_byte(bus->number, devfn,
PCI_HEADER_TYPE, &hdr_type);
+ if (hdr_type &0x7f>2) {
+ printk("Warning : unknown header type %d, probable HW problem,\n device %d on bus %d not registered in /proc/pci!\n",
+ hdr_type, bus->number, PCI_SLOT(devfn));
+ continue;
+ }
} else if (!(hdr_type & 0x80)) {
/* not a multi-function device */
continue;
==============================================================================

Note that it is not yet the correct way, but it should give you a decent
/proc/pci.
I think the best thing to do would be to:
1) find the processor to pci bridge device/function number (this one must
be on bus 0).
2) before attempting to read the vendor/device id of any device:
a) clear the status bits in the bridge
b) perform the configuration space read
c) read the status bits of the bridge, any master abort means device not
present.

However this is complicated by the fact that when on buses > 0, you should
perform steps 2)a) and 2)c) on the PCI<->PCI bridge controlling this bus.
I am too lazy to write it now and it would add bloat.

Gabriel.