IRC channel logs

<gnucode>ThinkT510: gitea apparently supports the Alpine package registry. :)

<gnucode>solid_black wants to create a Alpine based Hurd distro, but he doesn't want Alpine in the name.

<gnucode>because Alpine is not helping in the effort. we don't want to imply that it is Alpine endorsed.

<damo22>well thats annoying, my patch did not fix gnumach crashing on t620

<gnucode>damo22: at least you are trying to fix real hardware

<damo22>we need more developers trying real hardware

<damo22>qemu cant emulate everything

<damo22>i have no clue why it crashes so early i get nothing on console because its before that

<damo22>it must be acpi related

<damo22> ACPI:a

<damo22> rsdp = c00f5b10; rsdp->rsdt_addr = 7ffe20ce

<damo22> rsdt = f90900ce; rsdt->length = 38 (n = 5)

<damo22> kernel page fault at 0000006c:

<damo22> Dump of i386_saved_state c109aec0:

<damo22> EAX c1022368 EBX c109af28 ECX 00000001 EDX c101ad78

<damo22> ESI 0000000e EDI 00000000 EBP 00000000 ESP 65666637

<damo22> CS 0008 SS 00f6 DS 0010 ES 0010 FS 0010 GS 0068

<damo22> v86: DS 00f6 ES 0106 FS 0000 GS 0000

<damo22> EIP c104eaf0 EFLAGS 00010046

<damo22> trapno 14: Page fault, error 00000000

<damo22> panic {cpu0} ../i386/i386/trap.c:227: kernel_trap: kernel thread accessed user space!

<damo22>it crashes trying to compute the checksum of the MADT table

<damo22>according to grub> lsacpi

<damo22>APIC 120B rev=1 chksum=0xed (valid) OEM=BOCHS BXPCAPIC OEMrev=00000001 BXPC�

<damo22>...

<damo22>LAPIC ACPI_ID=00 APIC_ID=00 Flags=00000001

<damo22>...

<damo22>IOAPIC ID=00 address=fec00000 GSI=00000000

<damo22>...

<damo22>LAPIC_NMI ACPI_ID=ff Flags=0000 lint=01

<damo22>so it crashes with RSDPv2

<damo22>LAPIC ACPI_ID=00 APIC_ID=00 Flags=00000001

<damo22>LAPIC ACPI_ID=01 APIC_ID=01 Flags=00000001

<damo22>IOAPIC ID=04 address=fec00000 GSI=00000000

<damo22>IOAPIC ID=05 address=fec20000 GSI=00000018

<damo22> LAPIC_NMI ACPI_ID=ff Flags=0005 lint=01

<solid_black>well hello friends :)

<solid_black>gnucode ThinkT510: see, I didn't even realize Forgejo was a supposedly better fork of Gitea

<solid_black>and I don't know about this nearly enough to make a judgement

<solid_black>looks like Forgejo has the Alpine registry feature too

<ThinkT510>they were concerned about gitea becoming for-profit and their use of non-free software, hence the fork

<damo22>i sent a message to the list to document what i am doing

<anatoly>solid_black: thanks for the link. Could that patch be simply a commit in hurd branch for now. Then simple rebase on top of master from time to time will keep things up-to-date

<solid_black>ThinkT510: it sounds like you have more understanding of this than we do, why don't you participate? :) are you already hosting a forgejo server by any change, or want to host one for this project? or perhaps you could help me and gnucode figure things out?

<solid_black>s/change/chance/

<solid_black>I'd really like this to be a community project rather than my project

<ThinkT510>I'm not a fan of Go and I don't have a forgejo server running. I was just aware of the fork when it became big news.

<solid_black>I'm not a fan of Go either :)

<solid_black>but, I see

<anatoly>Go is readable for those who haven't read a single page about it nor write a line of it :-)

<solid_black>anatoly: well yes, this is just a bunch of patches on top of upstream master; yes we should be able to rebase them -- I've already done that a bunch of times

<anatoly>Comparing to rust

<solid_black>anatoly: were you able to bootstrap it (my aports branch)?

<solid_black>do you have experience with alpine?

<anatoly>solid_black: not yet, I went through your commits 10 mins ago :-) I have experience with it as a user

<anatoly>I'll follow alpine's wiki and try to do it in a container

<anatoly>but tomorrow, bed time :-)

<solid_black>ok, cool

<solid_black>please let me know how it goes

<solid_black>and good night :)

<anatoly>Sure, thanks!

<etno>o/ I found out why FPU was throwing an InvalidOpcode on my Dell machine. Now trying to make use of either gnumach's ahci driver or rumpdisk.

<etno>Appending "noahci" to gnumach's command-line still grabs the ahci device. And rumpdisk says "kernel is already driving a SATA device"

<damo22>try noide

<etno>With the kernel driver, setting ext2fs root to /dev/sd0s2 results in a "Gratuitous error"

<damo22>try "noide" and set root=part:2:device:wd0

<etno>ACTION is trying that

<azert>etno: I think it’s a very small bug in rumpdisk and rumpusbdisk. It’s when it check if it is driven by gnumach, it doesn’t check everything it’s less then ideal. You can also perhaps fix that

<etno>azert: when using "noide", I still can see that gnumach is initializing AHCI, and then printing the partition table.

<etno>damo22: unfortunately, noide doesn't seem to disable AHCI in my case. Then, I get: "ext2fs: part:2:device:wd0: No such device or address"

<etno>I could try to compile out AHCI in gnumach

<azert>etno: ok, probably I have no clue, but did you try both noide and noahci?

<etno>What would be the name of the /dev node if gnumach was used to drive the AHCI controller?

<youpi>sd*

<etno>For partition 2 of disk 1, would it be /dev/sd0s2 ?

<damo22>yes

<damo22>you can try compiling gnumach with --disable-linux-groups

<damo22>it should be fast to compile because it skips all the linux drivers

<damo22>i almost have a patch for ACPI >= v2.0

<etno>I added "--disable-ide", and now gnumach does not probe.

<etno>I now have a bunch of messages, among which, there is: "atabus0 at piixide0 channel 0"

<damo22>etno: you must have an IDE controller there too

<damo22>make sure your bios sets SATA mode to AHCI

<etno>It is in SATA mode currently, and there is a line "primary channel wired to native-PCI mode"

<damo22>SATA mode?

<damo22>it should be AHCI

<etno>It ends up with: "ext2fs: part:2:device:sd0: No such device or address"

<damo22>if youre using rumpdisk, the device is called wd*

<etno>damo22: yes, my bad, it is in AHCI

<etno>damo22: ':-O

<etno>Same player, try again :-D

<damo22>are you loading acpi boot server?

<damo22>pci-arbiter, acpi, rumpdisk, ext2fs, exec

<etno>I am using the grub config from Debian image of last June. It has acpi, pci-arbiter, rumpdisk, ext2fs and exec. In this order.

<damo22>pci must be first

<etno>Ah, let me try to swap. Last attempt said wd0 does not exist.

<damo22>because acpi accesses pci

<etno>ACTION is editing the grub config by hand and it takes time

<damo22>etno: what machine is this?

<damo22>try to get a photo of the boot screen if it fails

<etno>This is a Dell Inspiron 1750

<etno>Swapping pci-arbiter and ACPI resulted in the same message. ACPI is taking a lot of time, and has been since the beginning. Trying to get you pictures damo22

<damo22>etno: there are schematics available for your inspiron

<damo22>it has southbridge ich9m

<damo22>possibly gm45 chipset

<etno> https://pasteboard.co/UvtUoQ2NKWP8.jpg

<etno> https://pasteboard.co/dNP4tNCb3Hho.jpg

<damo22>etno: your pci device 31, function 2 is the SATA controller, but its in the wrong mode

<etno>There is a cd-rom drive. Could it be that the cd-rom is always in legacy mode while the hard drive is in AHCI?

<damo22>try unplugging the cdrom drive, it might be forcing non-ahci mode

<etno>In the BIOS, there is a toggle: legacy vs AHCI. The current value is on AHCI. Maybe I should search for BIOS updates

<damo22>etno: maybe the bios is confused, set legacy and reboot

<damo22>maybe its inverted

<damo22>sorry its late here, gtg

<etno>damo22: thanks a lot!

<etno>"wd0 at atabus0 drive 0" ohhhh

<damo22>:D

<damo22>is it using ahcisata0?

<damo22>or piixide0

<etno>I rebooted, because I had kept hd0

<etno>Waiting for acpi to start; takes about 1mn :-/

<etno>piixide0

<etno>"wd0 at atabus0 drive 0" is the last line at it stops there. I think we can resume later :)

<damo22>ok

<sneek>Yey! janneke is back!

IRC channel logs

2024-01-23.log