IRC channel logs

<youpi>that's not implemented yet

<Zopolis4>so if i'd need to use nonfree firmware to install regular debian then i wouldn't be able to install debian hurd?

<jab>Zopolis4: seems about right.

<Zopolis4>and platform support wont carry across from linux to hurd nessecarily so even if the debian wiki says it works fine without nonfree firmware that wont be the case on hurd, yeah?

<jab>The Hurd works on Intel only processors. :)

<Zopolis4>its running an i5-240M

<jab>Zopolis4: does it seem fairly stable to you?

<Zopolis4>wdym

<Zopolis4>ah-- turns out i was using a slightly older version, 2021-08-12, trying a new version now

<Zopolis4>no luck

<damo22>Zopolis4: are you installing it on native hardware or running it in qemu?

<Zopolis4>native hardware

<damo22>i wouldnt bother with that until more drivers are working

<Zopolis4>ah

<damo22>i tried on an x200 thinkpad, actually that works by chance

<damo22>but x230 does not work because the network card is not supported by netdde

<Zopolis4>im on t520 thinkpad

<Zopolis4>ill take a look at the drivers

<damo22>but you wont have any usb support

<Zopolis4>thatd explain several of the issues

<damo22>until we figure out how to use rumpusb

<damo22>all you have is disk and network access, and with VESA you can possibly run X

<damo22>at best

<damo22>corebooted thinkpads do not have VESA so you cant boot X yet

<Zopolis4>tbh id settle for an installation at this point

<Zopolis4>but with no usb support

<Zopolis4>and it looks like no dvd support

<damo22>i think ATAPI works

<damo22>you should have AHCI and ATAPI support via rumpdisk

<damo22>its just not ready for modern x86, i think it used to work fine on 486 machines etc but hardware is so difficult to initialise and drive now compared to back then

<damo22>it needs work

<damo22>but it boots fine in qemu

<luckyluke>I was thinking about adding some tracing to gnumach, e.g. to register all syscalls/ipc in a memory buffer and analyze/compare them offline. was there any similar work in the past?

<luckyluke>currently I print them to the console but it's not easy to analyze...

<youpi>there's debug_trace_buf

<luckyluke>that seems more targeted to kernel tracing. I was thinking more about tracing the user-space tasks, by registring all their interactions with the kernel (and between them)

<luckyluke>for example, I could compare a boot trace on a 32-bit kernel and compare it with a boot trace on a 64-bit kernel, to find out what fails in the second case

<youpi>I'm not sure how you'd be able to store them without just printing them on the console

<luckyluke>for the issue I have now, I think a buffer of some MB would be enough, it's in the order of thousands of ipc. I could even truncate the I/O ipc if they have big payloads

<youpi>sure but where would you store it to read it offline?

<jab>luckyluke: how does your approach differ from rpctrace?

<youpi>jab: in his 64bit environment he doesn't have a way to start rpctrace

<luckyluke>youpi: I can read it out with gdb

<youpi>ah :D

<luckyluke>jab: I can record every syscall enter/exit and not only ipc, although that would be possible with syscall emulation I suppose

<jab>luckyluke: that would be cool!

<luckyluke>But I want to record the whole system, not only one task

IRC channel logs

2022-08-10.log