eab13241a0
hwreport writes one folder to the first read-write FAT mount, or mounts the first USB stick that takes vfat itself and unmounts it afterwards: summary.txt (machine, firmware, CPU, memory, every PCI and USB device with its driver or "-- no driver"), dmesg.txt, lspci.txt in the shape of lspci -nnk -xxx, lsusb.txt, dmi.txt, memmap.txt, the ACPI tables as raw .dat files iasl -d reads, and copies of /proc. Serials, the UUID and the MSDM/SLIC tables (a Windows licence key) are left out. It reads /sys, which is new: sysfs at Linux's paths and in Linux's formats -- /sys/bus/pci/devices with uevent, config and resource, /sys/bus/usb/devices, /sys/firmware/acpi/tables, dmi/tables, memmap and efi, /sys/class/dmi/id. toybox's lspci and lsusb work unmodified against it. The USB core now keeps a table of attached devices for it. The machine's name comes from SMBIOS (kernel/dev/dmi.c). The UEFI loader hands over the entry point from the configuration table, the kernel falls back to the 0xF0000 scan, and the log gets Linux's "DMI:" line. Two bugs found on the way: - The loader handed over at most 40 memory-map entries, in firmware order. A laptop's UEFI map is 60-150 descriptors with RAM above 4 GB listed last, so that is what was dropped. The entries now have their own area at 0x31000 with room for 256, are sorted before merging, and the kernel's 32 usable regions keep the largest when there are more. - MemTotal and sysinfo's totalram were PHYSTOP, an address, which counts the PCI hole: a 6 GB machine reported 8. Now the usable RAM, summed. usb.ids moves to /usr/share/hwdata, where lsusb looks for it, and pci.ids joins it (`make pci-ids`, BSD-3-Clause like usb.ids). Checked under QEMU q35: the report written to a FAT32 stick, fsck.fat clean, DSDT.dat disassembled by iasl on the host, lspci -k and lsusb showing names, 6 GB of RAM seen as 6137 MB. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4
2.5 KiB
2.5 KiB
Reporting a machine
When SchOS half-works on a machine (no network, a dead touchpad, a disk it
cannot see), the fastest fix starts with a description of that machine.
hwreport writes one onto a USB stick that any other computer can read.
hwreport # onto a mounted FAT volume, or the first USB stick that mounts
hwreport /mnt # into a directory of your choosing
- Plug in a FAT32 USB stick. Nearly every stick comes formatted that way.
- Run
hwreport. It mounts the stick itself if nothing is mounted, writes a folder namedhwreport-YYYYMMDD-HHMMSS, syncs, and unmounts again. - Pull the stick out once it says so, and send the folder from another computer. Zip it first if your mail or chat client prefers one file.
It also prints summary.txt on the screen. On a machine where even the USB
port is not working, a photo of that screen is the next best thing.
What is in the folder
| file | what it is |
|---|---|
summary.txt |
machine, firmware, CPU, memory, and every PCI and USB device with the driver that claimed it, or -- no driver |
dmesg.txt |
the kernel log from this boot (and earlier ones, if a crash left them in memory) |
lspci.txt |
each PCI device the way lspci -nnk -xxx shows it: IDs, subsystem, driver, IRQ, the first 256 bytes of config space |
lsusb.txt |
each USB device and its uevent |
dmi.txt |
the SMBIOS identity: vendor, model, board, BIOS version |
memmap.txt |
the firmware's memory map |
acpi/*.dat |
every ACPI table, byte for byte; iasl -d DSDT.dat disassembles one |
acpi/tables.txt |
the table list with lengths and OEM IDs |
proc/*.txt |
/proc files: interrupts, devices, partitions, mounts and more |
The file names and formats are Linux's, so a report taken here can be compared
with lspci, acpidump and dmesg output taken under Linux on the same
machine.
What is left out
- Serial numbers and the system UUID. The kernel does not publish them.
- The MSDM and SLIC ACPI tables. They hold the machine's Windows licence
key.
acpi/tables.txtlists them as left out.
Nothing else in the report identifies its owner. Read summary.txt before
sending it if you want to be sure.
Where the information comes from
All of it comes from /sys, laid out the way Linux lays it out (see
filesystem.md), plus /proc. The same
files are there to read by hand:
cat /sys/class/dmi/id/product_name
ls /sys/firmware/acpi/tables
lspci -nnk
lsusb