IRC channel logs
2025-07-12.log
back to list of logs
<diegonc>may I print to the console (stderr or fd 2) in afunction that is registered in glibc's _hurd_preinit_hook? <diegonc>for some reason the message is not displaying :( <damo22>youpi: irq change fixed smp, but now theres a new fault {cpu5} ../vm/vm_fault.c:709: vm_fault_page: Assertion `!must_be_resident' failed <damo22>only happens when there is a lot of cores active compiling <damo22>sneek: later tell solid_black my latest patch for irq nesting should fix a race causing a hang in smp, but it seems to have exposed a new vm bug, can you try gnumach smp with my latest patch and try compiling with multiple cores? you seem to understand the vm subsystem way more than i do, the error was: {cpu5} ../vm/vm_fault.c:709: vm_fault_page: Assertion `!must_be_resident' failed <damo22>youpi: demo@zamhurd:~$ sudo dd if=/dev/ud0 of=/dev/null bs=1M <damo22>112820224 bytes (113 MB, 108 MiB) copied, 9.04522 s, 12.5 MB/s <damo22>on real hw i get "ehci_sync_hc: timeout" <damo22>seems similar to the identify failed for rumpdisk <damo22>maybe the timeouts are only one hz clock tick and not enough time to register the interrupt? <damo22>so maybe we are losing interrupts <youpi>sneek: later tell diegonc better use mach_print <azert>damo22: is the timeout because of not receiving interrupts? <azert>Wouldn’t it be more likely that just no interrupt get delivered at all? Did you check that? Did you try to lengthen the timeout? <damo22>i think i have figured out something, i am testing <damo22>because there is lock per irq, we need to lock in eoi too per apic pin <damo22>my v2 2/2 patch needs another revision as per my mail to the list <damo22>ok no worries, i will rebase and send a new patch <damo22>youpi: if an irq is acked asynchronously at any time, how does taking the ioapic_lock protect against __enable_irq unmasking the irq when a previous eoi is taking place? <damo22>afaik the ioapic_lock is to protect concurrent access to the window access of the registers because its not atomic to r/w to the apic reg <damo22>ah youre right, that toggle_entry locks the ioapic_lock <damo22>ok, interesting, my last patch isnt required <youpi>damo22: yes but I need to make some tests first <sneek>diegonc, you have 1 message! <sneek>diegonc, youpi says: better use mach_print <diegonc>it seems getting the vm limits works under rpctrace but for some reason setting them doesn't :( <diegonc>hmm, looking at traced_spawn from rpctrace there is this piece of code: <diegonc>-------->8-------->8-------->8-------- <diegonc>/* Replace the task's kernel port with the wrapper. When this task calls <diegonc> `mach_task_self ()', it will get our wrapper send right instead of its <diegonc>err = mach_port_insert_right (mach_task_self (), task_wrapper, <diegonc> task_wrapper, MACH_MSG_TYPE_MAKE_SEND); <diegonc>-------->8-------->8-------->8-------- <diegonc>could it be that mach_task_self returning the wrapper instead of the real task port be an issue if the port is passed as an argument to an RPC instead of as a destination port? <diegonc>well, I don't think that's the problem. vm_wire_all has a similar prototype and works ok <diegonc>-------->8-------->8-------->8-------- <diegonc> 38<--44(pid8060)->proc_getprivports_request () = 0 60<--55(pid8060) 31<--62(pid8060) <diegonc>task9(pid8060)->mach_port_mod_refs (pn{ 20} 0 1) = 0 <diegonc> 60<--55(pid8060)->vm_set_size_limit ( task9(pid8060) 2147483648 2147483648) = 0 <diegonc>task9(pid8060)->mach_port_deallocate (pn{ 20}) = 0 <diegonc> 38<--44(pid8060)->proc_mark_exit_request (0 0) = 0 <diegonc>task9(pid8060)->task_terminate () = 0 <diegonc>-------->8-------->8-------->8-------- <diegonc>interesting, calling the RPC directly works (after updating gnumach.h and linking with libmachuser.a)