IRC channel logs

<damo22>trace/tu

<damo22>Debugger(...)+0x15

<damo22>Panic(...)+0x10f

<damo22>kernel_trap(ffffffffdc2e0e78)+0x25c

<damo22>>>>>> Page fault (14) for 4000000036 at 0x4000000036 <<<<<

<damo22>(gdb) display/i $pc

<damo22>1: x/i $pc

<damo22>=> 0xffffffffdc2e3e78: add %cl,-0x23d2(%rdx)

<damo22>(gdb) p $rdx

<damo22>$1 = 1

<damo22>seems like it is trying to dereference memory address 0x1

<damo22>but its in userspace

<damo22>mm it must be in kernel to get a trap_from_kernel

<damo22>i think its a kernel thread running from memory?

<youpi>the instruction looks odd

<youpi>the offset -0x23d2 is suspicious

<youpi>is that $pc really inside a function?

<damo22>no

<damo22>it does not resolve in kernel

<damo22>does all kernel code run from 0xffffffff8100000 onwards? this address 0xffffffffdc2e3e78 seems allocated

<damo22>is it possible that a kernel thread has execution from a ffffffffdc..... address?

<youpi>it could be a function trampoline, but I don't think gnumach uses a lot of them

<youpi>e.G. when you pass a function to an iterator, and the function is a nested function that accesses parameters of the upper function

<youpi>in that case gcc pushes code on the stack to be executed

<youpi>so you'd execute code from the stack

<damo22>ok

<youpi>but otherwise, executing from dcsomething looks odd

<damo22>that is what i though

<damo22>t

<damo22>db{0}> whatis 0xffffffffdc2e3e78

<damo22>inside $map0 of $task0 gnumach

<damo22> entry 0xffffffffdf052ed8: object=0x0, offset=0x0

<damo22>phys 5c2e3e78, page ffffffffe3cce1a0

<damo22>-smp 1 with 64b+SMP works

<damo22>maybe while executing from the stack gnumach confused which stack its on?

<youpi>again, I don't think gnumach really uses that

<youpi>and no, that wouldn't confuse about what stack is used

<youpi>the stack doesn't care that $pc point into it

<youpi>also, whatis supports stacks,

<youpi>so since it didn't print about it, it's not inside a stack

<youpi>it really looks like calling an odd pointer

<damo22>ok

<damo22>so kernel is calling some non-kernel pointer

<damo22>and explodes

<youpi>no, 0xffffffffdc2e3e78 is a kernel pointer

<youpi>and then when the cpu tries to execute the code there, it does nonsense

<damo22>ok

<damo22>i mean not a pointer that has kernel code in it

<damo22>#0 0xffffffff8101787d in hpclock_read_counter () at ../i386/i386/apic.c:493

<damo22>#1 0xffffffff81056498 in softclock () at ../kern/mach_clock.c:358

<damo22>#2 0xffffffff81057648 in timeout (fcn=0xfffffffff0a4a020, param=0xffffffffdc2b9910, interval=-2130353000) at ../kern/mach_clock.c:732

<damo22>#3 0xffffffff8107ac1d in _Xi386_io_perm_modify (InHeadP=0xffffffff81013000, OutHeadP=0xfffffffff0a4a000) at i386/i386/mach_i386.server.c:431

<damo22>...

<damo22>but the other cpus have i386_exception code 14 subcode 0

<damo22>db{3}> whatis 0xffffffffdc2e3e78

<damo22>inside $map0 of $task0 gnumach

<damo22> entry 0xffffffffdf052ed8: object=0x0, offset=0x0

<damo22>In $task0 gnumach

<damo22> on stack of $thread0.2

<damo22>idle/1 (ffffffffdc2e7900) R......

<damo22>Processor #1 active stack

<damo22>phys 5c2e3e78, page ffffffffe3cce1a0

<damo22>it is in the stack

<damo22>db{3}> show thread $task0.2

<damo22>task 0(ffffffffdc2ead70): thread 2idle/1 (ffffffffdc2e7900) R......

<damo22>its the idle thread

<damo22>i tried compiling idle_thread_continue with attribute optimize -O0

<damo22>didnt help

<damo22>the address it fails on is even the same with the tests, 0x4000000036

<damo22>that address ends up in CR2

<damo22>hmm https://code.zammit.org/damo22/gnumach-sv/actions/runs/55/jobs/26/attempt/1#jobstep-2-1676

<damo22>slightly different offset

<nexussfan>Debian guide on bootstrapping OpenJDK https://wiki.debian.org/PortsDocs/BootstrappingOpenJDK

<nexussfan>Maybe we could use this to get openjdk 8+ to work

<damo22>i am collaborating with gnu_andrew, he said he has a icedtea/jdk7 source repo that i can patch directly

<nexussfan>Oh, okay

<damo22>the story is, jdk7 is very difficult to bootstrap without icedtea

<damo22>basically icedtea pulls out all the dependencies that are needed to build the tools and builds them using gcj

<damo22>then bootstraps jdk7

<damo22>once we have that, we can compile 8 etc

<damo22>i think they must have done a mammoth amount of java patching back in the day

<damo22>i tried all kinds of old debian tarballs etc, but is a nightmare to patch source because they are all nested tarballs of jdk

<damo22>this repo will be the ideal solution, the original source repo they used to use to generate diffs i think

<damo22>when i get the link, i will fork it, and try to upstream patches back to them

<damo22>but if we really want to upstream java, we have to target 27

<damo22>:\

<damo22>it crashes on the AP while running cpu_launch_first_thread

<damo22>Load_context

<damo22>(*continuation)();

<damo22>youpi: in Load_context there is a comment /* XXX complete */. How do we know which registers to restore on x86_64?

<damo22>dont we need KSS_EDI and KSS_ESI ?

<youpi>it's the callee-saved registers, rdi/rsi are not part of that on x86_64

<youpi>from my 64b abi copy, it's indeed rbx, rbp, r12-15

<damo22>what about r10 and r11?

<youpi>they're caller-saved

<damo22>ah yes, rdi and rsi are args

<damo22>i have been running the debug-mach_port target in qemu

<damo22>it faults before it enters userspace

<damo22>the APs fault just as they Load_context

<damo22>but the BSP can be executing userspace at the same time

<damo22>maybe there is a race between processors that means something is not ready before userspace executes

<damo22>where is the entrypoint to userspace? is it somewhere in bootstrap_* ?

<youpi>damo22: see user_bootstrap()

<youpi>which calls thread_bootstrap_return

<damo22>youpi: in call_continuation, this line seems bogus pushq $0 /* Dummy return address */

<damo22>if it is pushing an arg to the stack it should be instead setting rdi = 0 ?

<jab>so I guess Lunduke mentioned that the Xorg people were going to revert lots of commits for political reasons and not technical ones. Phoronix covered it here: https://www.phoronix.com/news/X.Org-Server-On-Main This just makes me think that XLibre is the better X server.

<nexussfan>Freedesktop isn't focusing much on x11/xorg anyway, xlibre continues the xserver with active development

<jab>If it's true that the Xorg people removed code commits by one developer just "because he's somewhat conservative", that seems like some stupid engineering.

<nexussfan>Either way, you have to have a *really good excuse* if you want to revert that much code

<jab>nexussfan: I should take a look at how much code was removed.

<youpi>damo22: call_continuation is not pushing an arg, it's pushing a return address

<youpi>it's making it 0 to clearly say that it's a beginning of backtrace

<youpi>jab: it's not just politics. The code in question was already doubtful, and the directions that Xlibre takes are as well. The politics around that are more a symptom of the original divergence of what "good" means

<youpi>nexussfan: when you don't really know the intention of a maintainer, up to questioning them, yes you have a good reason to just scrap the contributions, to be sure not to leave something odd

<youpi>see the xz issue

<nexussfan>youpi: Possibly. But to me it's not surprising as freedesktop doesn't really like xorg anymore and mainly focuses on wayland

<nexussfan>Hopefully once I figure out why xlibre's kbd driver is broken I can add xlibre for hurd into my debian repo

<youpi>well, they do care about xorg enough to make sure to clean it of questionable contributions

<nexussfan>Depending on what you think is questionable

<nexussfan>But of course it's okay to be worried about security

<sobkas>Please don't romantize X, it was always bad starting with protocol and all that work to make it better also made it no longer X anymore

<nexussfan>X is not the best, but neither is Wayland. They each have their own advantages and disadvantages

<jab>youpi: you have the C expertise than I do (obviously). So if you say those commits are questionable, I will try to believe that that is probable. It does seem odd if those commits were bad...why did it take that long to remove them ? You may choose to run Xorg, and I'll probably choose to run Xlibre. I'm guessing we also have slightly different political views. And that's ok too. :) Different perspectives make life worth living.

<sobkas>But in X there is no longer much space to make it better without breaking protocol. while wayland have lots of space left for fixes

<jab>sobkas: I'm not romantize X. At least I'm certainly not trying to. If the Hurd supported wayland, then I would use wayland. 100%. When I'm on Linux, I use sway. Sway is the best open source desktop experience I've ever had.

<youpi>please don't bash on Xorg either... No it hasn't been "always bad starting with protocol"

<youpi>I see a lot of nonsense being said about it, such as synchronicity etc.

<youpi>sure it's not perfect, that's why people are setting up Wayland

<youpi>but a *lot* of smart stuff was defined at the time

<youpi>c

<youpi>EWIN

<sobkas>jab: >why did it take that long to remove them: I believe it was the case because there was active developer behind theme and whene he is no longer contributing, this code have no hope of being fixed

<sobkas>youpi: I might have been a bit harsh about X protocol, vast part of it is no longer used, and was replaced by for example dri and from security point of view it should do better, but after all it's very old and many things are hard/impossibkle to fix

<sobkas>The main problem with X is that it can't be fixed without breaking protocol itself

<nexussfan>True, but Wayland's protocols are also divided somewhat.

<gnu_srs2>so what's wrong with improving X and at the same time improve and redefine the worst problems with the protocol?

<sobkas>You have apps that already use existing X protocol and if there are non backward compatibile changes they will stop work

<nexussfan>there's already the Phoenix Xserver which will remove the stuff that "nobody uses", I think that's gonna backfire

<Gooberpatrol66>anyone tried running arcan on hurd?

<sobkas>I see Wayland more like toolkit of protocols than single protocol to use, it's very flexible, but also does it have a real "core"?

<nexussfan>Gooberpatrol66: Does it even work? If it requires DRM then probably not

<nexussfan>sobkas: https://wayland.app/protocols/wayland

<sobkas>nexussfan: https://wayland.freedesktop.org/docs/html/ch04.html

<sobkas>Not every compositor implements everything, for example in car enterteinment systems don't implement some extensions that are essential to DE

<nexussfan>True, but most compositors aren't even 50% implemented protocols https://absurdlysuspicious.github.io/wayland-protocols-table/

<sobkas>This flexibility have a cost of fragmentation, like opengl if there was no entity that enforces compatibility

IRC channel logs

2026-02-15.log