IRC channel logs
2026-03-26.log
back to list of logs
<key69105>Hmm, it seems I can catch an interrupt very rarely, leading to hardclock(). So it's not zero interrupts as I thought after the first session. But max value of elapsed_ticks I saw while the calibration loop is running is 1, if not 0. <key69105>gnucode, thanks for looking at it anyway. <damo22>how did you observe the elapsed_ticks during the calibration loop? that is only supposed to count 10 ticks <damo22>that would be like observing 100ms of time as slow motion? <key69105>I naively break in the debugger and print the value. <damo22>i ask because there were some fixes recently <key69105>The build is from sid sources. I looked at the repo and saw some related change that got reverted few days later. <damo22>try building master branch and use that <damo22>or maybe there is an updated tag in debian since then <damo22>master from upstream savannah i mean <key69105>I can try master. In any case, the change is added and then fully reverted since the tag, just to be clear. <key69105>I guess I'll apply the reverted commit back, to see what happens. <damo22>if it doesnt work there, then theres a problem <key69105>Adding f41f8801fbbf back does not help, either. <damo22>which commit of master branch did you try? <key69105>I guess so, hence the revert... but what other thing could I try? I used last commit of master: b39457170d62. <damo22>i can push latest master there and do a CI test build <key69105>Maybe you missed some context up in the log. This is on bhyve and I guess that's pretty much untested, right? <gnucode>key69105: side note... you may be interested in our project proposal to turn GNU Mach into a userspace process...This would enable one to run the Hurd on pretty much any POSIX compatible OS I believe. <gnucode>also I just emailed in the Q1 Qoth for 2026. <damo22>gnumach is a kernel it doesnt run in userspace <gnucode>I think the goal of that port was to run Mach directly on top of an POSIX OS. <key69105>jrtc27: sorry for the ping but I recognize your nick and maybe you have some insights. Have you ever tried booting the debian images on bhyve. Any reason you can think of for the timer calibration problem I'm seeing? (see above) Thanks! <damo22>key69105: i think you need to check if your virtual machine has PIT emulation and APIC support <key69105>damo22: on the surface, it seems all if that is there, yeah. <nexussfan>> the Hurd's crash translator hanged when generating core files on amd64 <gnucode>well that's good news. I didn't mention the MESA port...would you like to mention that in a reply email ? <gnucode>or maybe link me to some patches, and I can mail something in. <nexussfan>yeah, you probably should mention the mesa port... opengl is a big thing <gnucode>send me a link to a code patch, and I'll modify the qoth. <gnucode>maybe send me a screenshot of classiccube ? <gnucode>nexussfan: did you port mesa to the Hurd? <gnucode>would you like me to write that "nexussfan ported Mesa to the Hurd?" Or would you like me to add in your name ? <gnucode>sobkas: do you want me to mention your name when I mention that Mesa was ported to the Hurd ? <nexussfan>i don't think we will have hardware accelerated gl for some time <nexussfan>although for some reason mesa is still FTBFS on debian/hurd <nexussfan>mesa build-depends on missing: - libdrm-dev:hurd-amd64 (>= 2.4.125-1) <gnucode>well, techically, I didn't said that it was ported to debian GNU/Hurd...just that it was ported to the Hurd. :) <sam_>(not yet merged, has pending review comments) <nexussfan>how does mesa/hurd work without libdrm ported then? <nexussfan>Or do you need to compile the patched libdrm first <nexussfan>gnucode: hopefully once it's in debian/hurd i can finally play Frozen-Bubble on the Hurd <gnucode>nexussfan: frozen bubble used to work on the Hurd I believe... <sam_>(minor update from earlier: grub module 'dependencies' in cfg were wrong, making progress now) <key69105>damo22: a breakpoint at interrupt() triggers about one minute into the calibration. Then, not anymore for the good while I let it run. This matches with elapsed_ticks never being greater than one. If I hack my way out of the loop (by setting done=1) I can see irq 4 triggering the breakpoint repeatedly (pci-arbiter related, according to the printed log so far), which suggests this is not a general interrupt <key69105>problem but one about the clock interrupt, right? Any hints about how to keep debugging this, anyone? <yang>azeem: are LinuxTags still being organized? <yang>I attended twice, but AFAIK those events have stopped after 2010... <azeem>they stopped around 2010 I think <yang>azeem: was that 2004 the Linuxtag in Berlin? <yang>Oh I think I've been in 2010 on the LinuxTag in Berlin <yang>But I've been in Berlin also in 2004, not on a Linuxtag though <azeem>it was in Wiesbaden at some point after that, I don't think I've ever been to one in Berlin <yang>I've been on the Wiessbaden one in 2007 <yang>Are there any photos from there? <azeem>either I didn't make some or I lost them <p4r4D0xum>Alicia: the second one, its wrong device name <p4r4D0xum>IDE uses hd0sN while rumpkernel uses wd0sN device file <p4r4D0xum>whats the device name used by your /etc/fstab? <Alicia>it's whatever the default in the 32bit Debian image is, but I don't think it gets that far. I'll try changing to wd in the gnumach line in grub <Alicia>I get the same with wd0 (except it says wd0 now) <diegonc>Alicia, maybe the error before is more important? it looks like a conflict of drivers <diegonc>or maybe it's usual printing. I haven't payed to much attention at the logs :/ <Alicia>yeah it's possible, though I get the same end error in IDE mode where it doesn't have that conflict (I think?) <Alicia>I don't know where to begin with trying to fix things like this beyond trying different device strings as workarounds. but would it be useful to keep a list of different hardware and whether or not Hurd works on it? (and some basic info about what happens, and who owns the device for testing future changes) <damo22>key69105: are you using a serial console to debug? <damo22>maybe there is some bug with the serial driver interrupt related that interferes with the clock <key69105>damo22: No serial. This is gdb to a tcp port of bhyve (kind of like qemu's -s way of attaching a debugger to the virtual machine). Nice tip, in any case! <almuhs>hi. I'm studying about how the translators are loaded, and I don't know the difference between reserve the port using task_get_bootstrap_port() + mach_port_allocate() ... and loading it using file_name_lookup() <almuhs>Could you explain more about this? <damo22>almuhs: i dont know the specifics, but you could read the source for file_name_lookup() maybe it uses a similar approach <almuhs>i don't find the definition of file_name_lookup() <rrq>is there documentation or header explaining devnode naming for hurd? <damo22>rrq: well, its up to the individual driver to decide on a node name, and rump has internal bsd nodes so i tried to make them consistent, but some of them had names that conflict with existing nodes in hurd so i renamed them <almuhs>it's not in hurd neither gnumach <rrq>yes especially physical devices seem to embed "interface type" in name prefix; would be nice with an overview table for that <damo22>it would be difficult to keep the table up to date <damo22>you can just showtrans the nodes to see what is attached <almuhs>shit, the savannah git repository is down <sam_>hurd support is all upstream now in glibc <rrq>yes would be fairly onerus to maintain, but would also be quite useful to have "system decision" behind it 
