I first tried to write debian-sid-hurd-i386-DVD-1.iso on an USB key and boot it on my computer.
Well, I first realized mouse and keyboard were not working because Hurd does not hangle USB. So I changed my firmware configuration to show USB mouse and keyboard as PS/2 mouse and keyboard. It's then I think I got to the point where it did not found files on the media. Then again, I attributed it to not handling USB. So I burn the iso on a real DVD. Then I came with quite the same no media found message as on USB stick. Maybe this is related to inherited peripherals, linked I think to CSM mode of UEFI... Or maybe Hurd have no AHCI (read SATA) 'driver' yet? Anyway... I care a bit more about the lspci thing. So I was able to open a shell... well in graphic mode it seems keyboard stop working in there... So I rebooted in text install... and launched shell (busybox) and happy to see the keyboard working. I have observed that ls /servers loops showing nothing, but can be stop with Ctrl-C. I also observed in top line: (1* installer) 2 shell 3 shell 4- Log I try many key combines: Ctrl-Alt-F2, Alt-F2, Alt-2, Ctrl-2, etc... but seems I was not able to change terminal that way. I have seens that ls /servers/bus was indeed showing pci. ls /servers/bus/pci/0000: 00 00 00 02 04 This has put out my intuition that it was impossible to have more than one file with the same name! So I will reconstruct the devices seen by the pci/0000 directory: 00:00.0 00:02.0 00:14.0 00:16.0 00:17.0 00:1C.0 00:1C.6 02:00.0 04:00.0 And now the great moment, the devices as given by Linux lspci: paul@Bagotteville:~$ lspci -b 00:00.0 Host bridge: Intel Corporation 8th Gen Core 4-core Desktop Processor Host Bridge/DRAM Registers [Coffee Lake S] (rev 08) 00:02.0 VGA compatible controller: Intel Corporation 8th Gen Core Processor Gaussian Mixture Model 00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset Family USB 3.0 xHCI Controller 00:16.0 Communication controller: Intel Corporation 200 Series PCH CSME HECI #1 00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA controller [AHCI mode] 00:1c.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #5 (rev f0) 00:1c.6 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #7 (rev f0) 00:1c.7 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #8 (rev f0) 00:1d.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #11 (rev f0) 00:1f.0 ISA bridge: Intel Corporation Device a2ca 00:1f.2 Memory controller: Intel Corporation 200 Series/Z370 Chipset Family Power Management Controller 00:1f.3 Audio device: Intel Corporation 200 Series PCH HD Audio 00:1f.4 SMBus: Intel Corporation 200 Series/Z370 Chipset Family SMBus Controller 02:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) paul@Bagotteville:~$ Hum... clearly some device seems missing: 00.1c.7, 00:1d, 00:1f Ok... enough for now. Sent using https://www.zoho.com/mail/ ---- Le lun., 26 oct. 2020 14:27:26 -0400 Paul Dufresne <dufres...@zoho.com> écrit ---- 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 https://www.zoho.com/mail/ ---- Le lun., 26 oct. 2020 11:14:25 -0400 Almudena Garcia <mailto:liberamenso10...@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 (<mailto:dufres...@zoho.com>) escribió: ---- Le lun., 26 oct. 2020 01:42:37 -0400 Damien Zammit <mailto:dam...@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.
