IRC channel logs

<Pellescours>morning

<gnu_srs>(18:00:36) gnu_srs: When booting in recovery mode shouldn't you get a single-user shell requesting the root password to continue?

<damo22>FIXED smp boot

<damo22>with irq 19

<ZhaoM>morning

<damo22>theres nothing wrong with rump, it was irq related

<damo22>[ 1.5900050] wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), NCQ (31 tags)

<damo22>youpi: my acpi changes coming soon will break gnumach UP without --enable-apic, can we turn that on by default?

<damo22>the problem is, theres no way for userspace to know if the APIC is being used or not

<damo22>so it doesnt know whether to add 16 (ISA_IRQS) to the irq number or not

<damo22>or do you want me to remap them inside gnumach when the irq request is made?

<damo22>actually if its a pci irq, it is referring to an APIC irq

<damo22>from ACPI, so there is no need to remap, its always referring to an APIC

<damo22>so we need to turn on --enable-apic

<damo22>if we are using acpi translator

<damo22>irq handler [26]: new delivery port f59b9da0 entry f5779f00

<damo22>../linux/dev/arch/i386/kernel/irq.c:230: install_user_intr_handler: Assertion `i

<damo22>rq < NINTR' failed.Debugger invoked: assertion failure

<damo22>with my v2 changes, it boots on both my AMD boards but not intel

<damo22>it finds IRQ 11 but times out on identify wd0

<damo22>building rump with RUMP_LOCKS_UP=yes

<damo22>we already run rump with RUMP_NCPU=1

<damo22>so this should make it even more stable

<gfleury>morning

<damo22>evenin

<damo22>RUMP_LOCKS_UP=yes made no apparent difference

<gfleury>damo22: with your last patch v2 full boot rump on hw with smp

<damo22>:D

<damo22>im sending a few more patches in

<gfleury>It's was a question never test it sorry:) but that great you managed to do it.

<damo22>yes it works with my HP T620 with coreboot

<damo22>its a thin client with 2 cores

<damo22>it has AMD fam16h APU and unusual AHCI chipset

<damo22>unfortunately netdde is hanging

<damo22>solid_black: where is roundup() defined?

<damo22>do you mean round_page () ?

<gfleury>great

<gfleury>disable netdde for now to test rump + smp

<damo22>its a bit difficult to test on that box because there is no network access, i need to upgrade packages

<damo22>but it boots at least

<azert>damo22: congrats \o/

<azert>if there is no network card, you might be able to get networking using ppp over serial

<azert> https://tldp.org/HOWTO/PPP-HOWTO/direct.html

<azert>should be similar on the hurd

<solid_black>I meant roundup from <sys/param.h> (see man roundup)

<solid_black>round_page from Mach works as well, except it's not going to work on aarch64

<solid_black>but maybe that's something for me to fix

<azert>solid_black: I was thinking looking at damo22 code that on device tree based architectures the whole acpi needs to be replaced by something else. And was wondering if it wouldn’t be best to define a common api or keep it as something for the user to figure out

<solid_black>so IIRC there are aarch64 systems that use acpi too, mainly large servers

<solid_black>but I don't have nearly enough understanding of damo22's work (other than "he makes SMP work in more cases") to have an opinion on your question

<azert>me neither, I have the feel that as the thing are, it would be up to the user to set up the right servers and the right protocols, while it could be transparent

<azert>I kind of like that is up to the user

<azert>but it would be harder to setup for sure..

<damo22>acpi is pure garbage, but it is necessary on x86

<damo22>in some cases, its the only place you can get configuration information about what is present on the system

<damo22>because even linux doesnt have drivers for some things, they are baked into the acpi tables

<damo22>the part i implemented yesterday and today was a bugfix that should have been done in the first place, but it was difficult to write

<homo>I heard that with acpi some vendor binary code must be loaded into kernel, isn't that a security hazard?

<damo22>the acpi tables contains ASL compiled into AML binary format and this is usually written by bios vendor

<damo22>its loaded into kernel memory yes i think

<damo22>but not on hurd

<damo22>monolithic kernels usually read the tables and parse them in kernel, and then execute the binary methods via acpica

<damo22>you can dump the tables from memory on any machine, and then use "iasl -d" to decompile them back into readable ASL form

<damo22>thats what i did for mine so i could see some examples of what i was trying to parse

<damo22>and actually i found one of my machines has a broken acpi method

<youpi>damo22: by "breaking gnumach", you mean the irq.c assertion? see my change in gnumach about it, we should have prevented NINTR through a proper error long ago already

<damo22>youpi: i think v2 is compatible with UP

<homo>damo22 btw, I heard that openbsd doesn't use acpica, instead they have their own implementation, is that any suitable for hurd?

<damo22>i booted qemu with v2 on my older kernel and it works fine

<damo22>homo: i dont know i havent looked into it

<damo22>it probably makes sense to use the reference implementation as it is known to work and is maintained

<homo>I guess their version is for those who completely distrust anything from intel

<homo>still, efi and acpi are hard to avoid even on arm :(

<damo22>i distrust UEFI

<damo22>i dont use it on any of my machines

<homo>isn't bios nowadays an emulation running on top of uefi?

<damo22>not mine :D

<damo22>i use coreboot + seabios

<homo>lucky

<damo22>its not an accident that i only use hardware from circa 2013

<damo22>but when i actually need to upgrade, i dont know what i will get

<damo22>youpi: but also, --enable-apic is probably necessary to run acpi translator right?

<homo>well, same with me, currently I suffer overheating because I refuse proprietary amdgpu firmware and something related to acpi is broken as system becomes frozen after resuming it from suspend

<damo22>youpi: because the acpi_get_pci_number() function is referring to APIC pins (?)

<homo>I am fed up with x86, I want to escape to arm or riscv

<damo22>s/pci/irq

<youpi>damo22: I don't know

<damo22>i can test UP without --enable-apic but i think it might break

<damo22>../configure --enable-kdb --enable-ncpus=1 --disable-apic

<damo22>booted

<damo22>surprising

<damo22>i didnt see any calls to my new code though in acpi

<damo22>it connected to irq 10 and i got intnull(15) but it booted

<damo22>youpi: at some point we are going to need to make a transition off PIC interrupt controller because all the new code expects APIC to exist

<damo22>"(08:00:19 PM) homo: I am fed up with x86, I want to escape to arm or riscv" me too but i dont want a proprietary bios

<homo>what about guix's support for pinebook pro?

<damo22>guix isnt a bios

<azert>damo22: out of curiosity, what is still broken on the intel machine?

<homo>but guix offers bios package, no?

<homo>I don't know what u-boot is, but I noticed it mentioned in guix

<homo>and there is u-boot package for pinebook

<Pellescours>u-boot, a bootloader maybe?

<Pellescours>a bootloader for arm, according to guix package

<homo>ah, so they don't boot with grub there...

<damo22>azert: i dont know, it finds IRQ 11 and then fails to identify the disk, which is the same error i got when it was the wrong IRQ

<damo22>but im not getting intnull(x)

<damo22>homo: u-boot is a separate package yes, its a kind of bios for embedded machines

<azert>u-boot is not really a bios, it is a bootloader based on the device tree

<azert>the device tree is something comparable to a bios

<azert>although it is in encoded a standard transparent and flexible format

<solid_black>?? a device tree is passive, it's not code

<azert>yes

<solid_black>as in it describes, it doesn't run

<solid_black>unlike bios

<azert>not all software are encodable in a tree

<azert>but many are

<azert>bios is an ancient ibm thing I’m not even considering it

<azert>my point was that u-boot replaces grub, not a bios

<azert>It cannot boot FreeDOS!

<azert>It can boot the Hurd on the other hand

<solid_black>:)

<solid_black>well I'm not sure it "replaces" grub or bios or anything

<solid_black>it's a bootloader

<solid_black>it can load things

<solid_black>but a typical arm system is booted through many complicated steps

<solid_black>that may include all of proprietary blobs, u-boot, grub

<azert>I think we don’t want the proprietary blobs, we should try to get rid of them

<solid_black>whereas when booting aarch64 mach on qemu, we don't have any of those, qemu just directly loads mach into memory

<azert>I think grub is dispensable, while u-boot can replace it on real hardware

<azert>btw there is u-boot also for x86

<homo>and let me guess, riscv situation is not better

<solid_black>i've no idea about risc-v

<azert>risc-v can use u-boot

<homo>I mean is it possible to remove all blobs from riscv

<azert>yes, I think it is possible to remove all blobs from aarch64 too

<azert>for my experience, u-boot is superior to grub. Grub is a complex bootloader conceived to boot Linux alongside windows on a broad range of platforms, which is something very useless, and then to provide boot options for recovery. U-boot instead is almost a low level operating system that can manipulate the device tree and do much more

<azert>For instance, u-boot can even run wget

<azert>you can write and read from memory using u-boot. This is of course very useful but cannot be done in grub

<azert>interesting discussion: https://lore.kernel.org/lkml/20230606204522.GA1142773@bhelgaas/T/

<azert>related to what has been just sent by damo22 on the mailing list

<azert>apparently it is an issue also on linux

<azert>seems like it is not an issue on x86

<azert>in any case, if I understand correctly, seems like linux reconfigures the pci bus

<youpi>sneek: later tell azert grub also supports http. It can very probably also read/write memory

<sneek>Okay.

<youpi>damo22: do we have known cases where apic poses problem?

<damo22>youpi: no, i think it used to be partially unusable but ive been running with apic for quite some time with no issues

<damo22>the only remaining issue involving the apic is some of my old hardware does not probe disk with rump but it now probes the controller instead of skipping it

<damo22>but im not sure if this is a bug rumpdisk or acpi

<damo22>i havent tested old linux drivers with apic though, as i always compile my gnumach --disable-linux-groups

IRC channel logs

2024-12-28.log