Re: Thinkpad T60: 8 video cards detected (same), where 2 different cards expected

[Paul Dufresne]

I said:

In libpci_access-016/src/hurd_pci.c, there is enum_devices that I think may be a recursive scan of PCI devices

Looks like I was a bit wrong here.

Because the comment says it scan the filesystem... which I now presume is:

/servers/bus/pci

[domain:]bus:device.function

domain: /servers/bus/pci/0000 is not shown by lspci.

Like in qemu I have:

root@debian:/servers/bus/pci/0000/00/00/0# lspci

00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)

00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]

00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]

00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)

00:02.0 VGA compatible controller: Device 1234:1111 (rev 02)

The first value: 00 is the bus, and here there is just one.
There is 3 devices on bus 00:
-00 is 440FX
-01 is 82371 chip
-02 is VGA card
The 01 device on bus 00, has 3 functions:
-0 ISA bridge
-1 IDE interface
-3 Bridge

Like the bridge (bus:00, devices 01, function 3): would be on:

root@debian:/servers/bus/pci/0000/00/01/3# ls -lh

total 8.0K

-rw-rw---- 2 root root 256 Oct 26 12:16 config

root@debian:/servers/bus/pci/0000/00/01/3#

Seems all functions of devices have at least ths 256 bytes config.

But the can contains regions files, rom, each can be 16Mib long, so it can become a bit big.

My initial idea was to create a tar.gz file of the /servers/bus/pci/ directory as a kind of scanned "real" pci scan.

This kind of confirms the problem cannot be in this detection itself, because there cannot be four: /servers/bus/pci/0000/00/01/03 files.

I now believe the pci scan I was searching for is more in the:

libpci/libpciaccess-0.16/src/x86_pci.c:

/* Recursively scan bus number `bus' */

static error_t

pci_system_x86_scan_bus (uint8_t bus)

Which I am kind beginning to look at.

Sent using Zoho Mail

---- Le lun., 26 oct. 2020 11:14:25 -0400 Almudena Garcia <liberamenso10000@gmail.com> écrit ----

My T60 includes at least two USB devices, if I remember well. But Hurd doesn't support USB, and these are usually listed with lsusb which, obviously, doesn't exists on the Hurd

El lun., 26 oct. 2020 a las 15:58, Paul Dufresne (<dufresnep@zoho.com>) escribió:

---- Le lun., 26 oct. 2020 01:42:37 -0400 Damien Zammit <damien@zamaudio.com> écrit ----

On 26/10/20 10:56 am, Almudena Garcia wrote:
> This is my lspci -nn

I think it's a bug with the pci-arbiter listing some of your hardware four times using lspci.

Why would the pci-arbiter do such a weird thing?

I know it is new, if something not seen before does not work, then this must be the fault of the new thing.

But maybe so few people have tested on real hardware (by the way, this is not me who have this repeating devices... I did not test on real hardware yet),

that the enum_devices function of PCI can be broken.

In libpci_access-016/src/hurd_pci.c, there is enum_devices that I think may be a recursive scan of PCI devices... but then again it seems weird to me.

I try to compare that with:

https://wiki.osdev.org/PCI#Enumerating_PCI_Buses

... I don't seems to see that as equivalent...

and I am kind of tempted to try to do a brute force enumeration... I toy with many programming language, but never gone very deep... and I am unsure

I understand the code enough, or my abilities high enough... but maybe I will try. I am still unsure if it is really there the PCI bus scan is done.

I kind of doubtful the T60 from which the lspci was coming, had no USB devices. Even if Hurd does not support USB devices, it should in my opinion show

the USB devices, so it make me think PCI bus scan is broken.