> 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 ?
Yes.
I/O at 0xfffffffc.
>
> > In simpler words, this will reduce the warning messages at bootup and
> > simultaneously reduce the input of unknown devices in /proc/pci?
>
> It should.
[snip]
> Ok try that one, you may remove the preceding one:
Missing something here. The warning messages are still there along with an
equal amount of the new messages supplied with the patch.
The overflow is back.
> >
> > 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.
>
Yup.
>
> 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.
>
I appreciate you taking the time trying to help. I wonder if it's worth
continueing with such a thing. The machine is working ok except for the
annoying bootup warnings, the input in /proc/pci and the overflow when
viewing /proc/pci. I think the best (if any) solution would be in the
direction we have tried so far (trying to reduce the bogus messages).
Magnus