IRC channel logs

<damo22>probably when gcc had that change that -fcommon was needed initially, someone hardcoded it into the make command?

<zamfofex>I’m running into a different issue now. When it tries to build the ‘glibc/hurd-headers’ package (which seems to be glibc’s headers cross‐built for the Hurd), it fails during ‘./configure’ while checking for Mach headers because ‘<mach/mach_types.h>’ includes GCC’s ‘<stdint.h>’, which in turn try to use ‘#include_next’, but it fails to find anything.

<zamfofex>Passing ‘CC=gcc -ffreestanding’ to ‘./configure’ fixes it, but it causes a different failure later on, still in ‘./configure’. I suppose a sensible solution might be to just remove the check with a patch, I think.

<youpi>Flavio's script doesn't seem to need such a thing

<youpi>you could probably raise the question on the list

<zamfofex>Seems like there was a fix in glibc in 8b8c768e3c701ed1993789bb46acb8a12c7a93df (and subsequently in 7685630b98ca2a3f5de86eadf130993e6cf998a0) that is not in 2.35 yet. I suppose I can manually patch that fix in for now.

<zamfofex>s/yet//

<zamfofex>Oh, I just realized that if I apply a patch to glibc, imma have to wait for, like, two whole days again for packages to build. 😭

<surpador>zamfofex: maybe you could use grafts for the patched glibc, at least until you get everything working? Might make the debug cycle shorter. I don't really have any experience with grafts but seems like they might be useful here.

<almuhs>damo22: any progress with apic or smp?

<almuhs>damo22: do you know if rumpdisk supports SATA CD/DVD reader?

<damo22>almuhs: it was my birthday, i didnt work on hurd though

<damo22>yes, rumpdisk supports cd/dvd

<almuhs>damo22: happy birthday:)

<almuhs>then the problem must be in the Debian GNU/Hurd installer. The installer only detects CD/DVD if this is IDE

<almuhs>the installer boots, but after start installation, is not able to detect CD/DVD devices to find the installation files

<youpi>the installer doesn't use rumpdisk by default yet, you have to pass the noide kernel parameter for that

<youpi>and noahci

<youpi>ah, no, noide implies noahci actually

<almuhs>the installer detects the SATA HDD, but not SATA CD/DVD

<almuhs>so I need a strange configuration using a SATA HDD with a IDE CD/DVD

<almuhs>but in real hardware is not usual this hardware

<youpi>again, that's because rumpdisk is not used yet

<youpi>and the kernel ahci driver indeed has troubles with SATA CD/DVD

<youpi>again, use the noide kernel parameter

<almuhs>then, the partition step are using gnumach's SATA drivers?

<youpi>unless you pass the noide kernel parameter, *yes*

<almuhs>ok, i will try noide parameter

<almuhs>where i put this parameter?

<youpi>see the grub help

<almuhs>this? https://www.gnu.org/software/grub/manual/grub/

<youpi>no, I mean the integrated help

<youpi>see the boot menu

<almuhs>ah, ok

<youpi>the shortcuts documented at the bottom

<almuhs>ok, i understand now

<almuhs>now it works in real hardware

<almuhs>my thinkpad r60e now detects the DVD

<almuhs>but now the partitioner doesn't detects my SATA HDD

<almuhs>youpi: are there any way to the partitioner can detect my HDD?

<youpi>by fixing rumpdisk?

<almuhs>if I install with gnumach's SATA drivers, rumpdisk detects my hdd during the boot

<almuhs>but rumpdisk by own doesn't detect my HDD during the installation

<almuhs>**by self

<youpi>also, did you take the latest installer image?

<almuhs>2022-10-29

<almuhs>are there any newer image?

<youpi>there's the daily build https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/

<youpi>I don't remember if rumpdisk was changed in between, though

<almuhs>does the daily build works?

<damo22>i dont know if ide + ahci can work simultaneously unless Pellescours fixed it

<youpi>the daily build is what it is: a daily build

<youpi>not tested

<youpi>so may or may not work

<youpi>if it doesn't work, then help is welcome to fix bugs

<almuhs>then i will test it in a VM

<almuhs>to avoid waste DVDs

<youpi>(you could also use a CD-R)

<youpi>(but yes, better avoid burning something that doesn't work)

<damo22>how does your laptop have an ide cd/dvd drive?

<almuhs>no, this is the problem

<damo22>what drive does it have?

<almuhs>in a VM i can set IDE CD/DVD drive + SATA HDD, but in the laptop i can't

<almuhs>wait i go to check

<damo22>rumpdisk supports AHCI + SATA DVD

<almuhs>yes, but the installer doesn't enable rumpdisk by default

<damo22>no but you can force it to boot with "noide"

<almuhs>yes

<almuhs>in my R60e i put this, and detects the CD/DVD drive, but not the HDD

<almuhs>in my T410 doesn't detect anything

<damo22>hdd is wd0

<almuhs>yes, but not appears in partitioner list

<damo22>really you need to get yourself a USB <-> SATA cable

<almuhs>installing from a VM

<damo22>and install your hurd system onto the physical disk from a vm

<almuhs>but i want to use the installer, to test it

<damo22>the installer is useless if it doesnt work

<youpi>or just copy over an installed image

<damo22>for example, i plug my physical 2.5" disk into a usb caddy and boot qemu with /dev/sdd

<damo22>from linux

<almuhs>yes, i know what you refers

<almuhs>but i like to test installer

<damo22>then if i want to test on real hw i unplug the caddy and put the disk into the real pc

<almuhs>to test the user experience

<youpi>if the system doesn't work already, there's no use trying the installer

<youpi>first fix the system itself

<almuhs>ok

<youpi>and then we can check that the installer is fixed too

<damo22>youve already determined that the system does not work, why do you need to confirm the installer is bogus again and again

<youpi>the user experience itself can be tested in a VM, no need to bother with real hardware

<almuhs>tomorrow i will recover my HDD caddy and then I will install by VM

<damo22>almuhs: i highly recommend this, you can do more helpful work when you have an installed disk

<damo22>for example, you can backup individual binaries and compile changes to servers and try them out

<almuhs>yes, but we have to wait tomorrow. My caddy is at home and now i am in my office

<damo22>i dont mean right now, just whenever

<almuhs>i like to test it in real hardware because the real hardware is wilder than VM. In real hardware, manufacturers doesn't fully follow the standard specs for protocols, set their own IRQs... etc

<damo22>i dont know if the irq problem has been solved yet with acpi

<almuhs>remember the problem with ACPI shutdown, which have a different results depending of the machine

<damo22>i cant remember if its all hooked up

<damo22>i was working on libirqhelp

<damo22>almuhs: shutdown should be working on real hw

<youpi>almuhs: sure but the installer is not a case that is easy to investigate

<youpi>better just work on the system itself firsrt

<youpi>where you have gdb etc. at hand

<almuhs>yes, yes

<damo22>acpi translator queries the SLP states properly

<damo22>by walking the DSDT tree

<damo22>we dont have guessing SL5

<damo22>etc

<almuhs>i have to re-check shutdown. Some months ago, the acpi shutdown failed in T410 (infinite errors loop), hang in T60... etc

<damo22>i wouldnt bother with real hw for the moment, until we can get things working with qemu

<damo22>its not a good use of time

<damo22>i feel like one day i could plug the disk i have into my x230 and it would boot, but so what

<damo22>we're not ready for that with smp

<almuhs>but, when we will get boots in VM, the next step will be test in real hardware

<damo22>one day, yes

<damo22>but i need help with smp in qemu

<almuhs>yes

<damo22>we're close but not there yet

<almuhs>i have a qemu VM working

<almuhs>about ACPI shutdown, it continues failing in my T410

<damo22>"it works" doesnt mean much, we need -smp 8 to boot in qemu

<damo22>for example

<almuhs>yes, i have in the same step than you

<damo22>with --enable-ncpus=8 --enable-apic etc

<almuhs>--enable-ncpus=1 -enable-apic shows the connection timeout in console

<damo22>i fixed the timeout

<almuhs>but it's not in upstream yet

<damo22>check my patch to the mailing list

<almuhs>ok

<damo22>unmask irq 12

<almuhs>yes, i'm reading now

<almuhs>copy and git patch, it's not?

<damo22>we need to figure out why that particular irq blocks the console

<damo22>i dont really understand it

<damo22>but my patch works

<damo22>thats not enough to accept the patch

<damo22>just because it works

<almuhs>i remember an old bug which i had in old versions of Hurd, in which if you press mouse during booting, the mouse stack (or any similar) blocks the boot

<almuhs>i don't remember if locks the boot or the shutdown, but locked any related thing

<damo22>im not 100% sure its related to the mouse, but it seems to trigger one interrupt at boot and then nothing

<damo22>and stays masked

<damo22>but if you unmask it, everything works

<almuhs>i can test to disable mouse in hurd-console

<almuhs>to discard the problem is related with that

<damo22>maybe

<almuhs>mouse generated problems in other times

<almuhs>the last year i have a problem in which enabling mouse in hurd-console locks the tty

<almuhs>**i had

<damo22>we need to move the unmask_irq() calls into their respective driver

<damo22>so the driver itself should know what irq to unmask and do it, instead of calling unmask manually in model_dep.c

<damo22>check for #warning

<damo22>theres a compile time warning that reminds us to fix this

<damo22>its midnight, im turning into a pumpkin

<damo22>goodnight

<almuhs>good night

<almuhs>damo22: disabling mouse and mouse repeater, now we have keyboard in tty

<almuhs>must be a bug in this device

<almuhs>but now you can go sleep with a problem less

<almuhs>i simply put a # before mouse lines in /etc/default/hurd-console

<almuhs>i go to have lunch. I have a class at 4 PM

<Pellescours>for ahci + ide rump compile with both but I don't know if someone tested to boot with both at the same time

<luckyluke>About x86_64, any reason to not use syscall/sysret? Afaik sysenter/sysexit has (or had) compatibility issues between intel and amd

<youpi>no reason against anything :)

<youpi>it's open for whatever seems best

IRC channel logs

2023-02-21.log