IRC channel logs

<damo22>WOOOT 115200 7N1

<damo22>console works if you assume 7 data bits

<damo22>start pci-arbiter: pci acpi rumpdisk [ intnull(7)

<damo22>[ 1.0200050] vendor 1022 product 7801 (SATA mass storage, AHCI 1.0, revision 0x40) at pci0 dev 17 function 0 not configured

<damo22>ext2fs: part:2:device:wd0: No such device or address

<damo22>or with gnumach ahci:

<damo22>Probing PCI hardware.

<damo22>AHCI SATA 00:11.0 BAR 0xf0b6c000 IRQ 0

<damo22>ahci: 00:11.0: Can not get irq 0

<damo22>...

<damo22>start pci-arbiter: pci acpi ext2fs: part:2:device:sd0: Cannot allocate memory

<damo22>something about RAW flag assumes 7 data bits

<damo22>its probably wrong logic

<damo22> { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON_SATA,

<damo22> AHCI_PCI_QUIRK_FORCE },

<damo22> { PCI_VENDOR_AMD, PCI_PRODUCT_AMD_HUDSON_SATA_AHCI,

<damo22> AHCI_QUIRK_BADPMP }

<damo22>why isnt AHCI_PCI_QUIRK_FORCE used for the equivalent AHCI controller

<damo22>maybe that is why its not detecting it

<damo22>i386/i386at/com.c:#define IFLAGS (EVENP|ODDP|ECHO|CRMOD) <---- shouldnt that include | LITOUT ?

<youpi>oh, probably

<damo22>yeah i am just compiling librump with a patch and then i will try gnumach with that

<damo22>yep i have a fix for com port

<azert>damo22: congrats

<azert>I’ve been looking out of ignorance at the current landscape of virtualization techs. I’d say that while we are interested in using it to emulate os like Linux does, that’s really not where the industry is targeted and not what the gnu project probably would find themselves having a strategic interest

<damo22>what do you mean azert?

<azert>Virtualization is mostly used to separate firmwares in a secure way, even using separate ram

<azert>Basically closed source drivers running their own hardware

<azert>And Linux running on them without even knowing

<etno>I could read numerous times (while this can be discussed) that "Full virtualisation is the failure of OSes". Hurd definitely has built-in capabilities that would make virtualisation useless in most cases; for me :-)

<azert>I think the goal in the long run should be to expose all these hw feature and make them available to every user

<azert>could be done by embracing xen, maybe. Or l4.

<azert>youpi: how much work would it be to turn the Hurd in a xen dom0?

<azert>Was reading about virtualization techs and I’m afraid qemu/kvm is not a great solution

<damo22>azert: i thought hurd already has a xen port

<damo22>gnumach*

<azert>Yes, but is it dom0 or domU?

<youpi>it's domU

<youpi>it would need adding quite a few infrastructure things

<youpi>there's all the management ioctls and whatnot

<youpi>in terms of hardware implementation, it's mostly in xen itself so it's done

<youpi>also, the gnumach domU port is most probably not working now

<youpi>since things have been done without anybody testing it, afaik

<youpi>adding kvm support would probably be quite simpler

<youpi>since all the management is *not* going through the os

<azert>But maybe the xen management can be done by a server in userspace?

<azert>While for kvm you’ll end up with a poorman hyper visor compared to l4 or xen

<azert>How is kvm going to keep up with the industry progress like arm trustzone I cannot grasp

<azert>We are never going to have a car running the Hurd

<damo22>lets try to get a 64 bit system working before a car

<damo22>we dont even have serial console working correctly on real hw!

<damo22>[ 1.0200050] vendor 1022 product 7801 (SATA mass storage, AHCI 1.0, revision 0x40) at pci0 dev 17 function 0 not configured

<damo22>damn, a librump patch i made did not fix the problem

<azert>Fixing the gnumach domU support might help the arm developments of solid_black. There we don’t even have a console! And I think xen provides it

<youpi>sure the management can be done in userland, but that's still to be written & plumbed, that's what I mean :)

<youpi>the xen console will already be working on arm64 indeed

<youpi>I used the xen support to fix most 64bit issues in the early stage of porting

<youpi>I do agree that better fix what we are working on before investing into new areas

<youpi>we can test hurd from a linux host, that's not so much a concern

<youpi>and we'll much more easily get CI power from linux hosts than hurd hosts :)

<youpi>(kvm is still useful as hypervisor as in: it's very easy for users to set up, no need to reboot into a new hypervisor with all the grub changes and whatnot)

<gnucode>howdy friends!

<gnucode>well, since I couldn't get the crossinstall to boot (I couldn't find the right grub menuentry) I put my T410 in compatability mode, and tried running the debian installer again. I used the latest one. And that seems to be getting stuck on the formatting partitions section. It seemed like it detected the Hard drive. It let me manually set up the partitions. Though it did complain about /dev/hd2 has a bad file descriptor.

<gnucode>I guess I will burn an old Debian GNU/Hurd installer image, and I will try that.

<gnucode>if that fails, then I probably need to get a new SSD (or HDD) for this T410.

<gnucode>maybe I spoke too soon. It is trying to install packages...

<gnucode>The hurd installer is trying to install packages

<gnucode>frick... It's making me manually input a debian mirror...

<gnucode>and I don't know how to give it one...

<gnucode>Anyone know what mirror I should use?

<gnucode>ftp.us.debian.org

<gnucode>Then it's asking me for the "Debian archive mirror directory".

<youpi>you have a list

<youpi>but you can as well just not select a mirror, so as to just install the net inst

<youpi>i.e. what comes fro mthe cd

<gnucode>youpi: ok. I tried ignoring selecting a mirror.

<gnucode>Now it's asking me to insert the disk labeled "Debian GNU/Hurd sid _Sid_ - Unoffical hurd-i386 NETINST 20210812-09' in the drive.

<gnucode>Now it seems the installer is stuck in a loop. it wants me to insert the drive. But the NETINST is alreday in CD rom slot? Weird.

<gnucode>There doesn't seem to be a "go back button" Let me try to select a mirror again please.

<gnucode>I guess I have to hard shut off the machine.

<gnucode>When it was asking me for the mirror hostname I put in "deb.debian.org"

<gnucode>Then it asked for the directory name. I tried "debian" and "debian-ports"

<gnucode>Those didn't seem to work. :(

<gnucode>I can probably still install it, I just need to know the "directory name" for the mirror.

<gnucode>Well I'm probably out of time. I'll have to try to install with an older install CD later.

<gnucode>I did make some progress in porting netsurf. I'm not sure if my patches are good, but it does compile, and I've removed 2 or 3 references to PATH_MAX.

<gnucode>I'm heading out to work now.

<gnucode>howdy friends!

<youpi>gnucode: the directory is rather /debian-ports

<gnucode>hmmm.That might explain it.

<gnucode>and thanks!

<gnucode>It appears that the installer is working. It just moves slowly in various places.

<gnucode>Partitioning is taking 5 minutes or so. So the casual user might be confused.

<youpi>probably some disk driver or such is not behaving correctly

<youpi>like not actually using dma etc.

<gnucode>ok. That's freaking weird. I left my T410 alone for about 5 minutes. because it was moving slowly on the partitioning. Now it is installer packages. literally 6 hours ago it was telling me that I had to manually write out the mirror ulr.

<gnucode>url*.

<gnucode>Now it appears to be working. And I didn't do anything.

<gnucode>youpi: yeah. I should probably get rumpdisk set up properly.

IRC channel logs

2024-01-18.log