<damo22>youpi: i had a dream and i think i figured out the bug with rump in my dream <damo22>i got a stacktrace, it seems to be aborting when waiting for a semaphore <damo22>my theory is, it got the wrong interrupt, ran a schedule, and never unscheduled() <AlmuHS>finally, I've just send the patches for the first stage of SMP ***Server sets mode: +nt
<damo22>Seems to hang waiting for the irq->sema <damo22>#2 0x08159a8c in __pthread_block_intr (thread=0x83394d0) <damo22> at ../sysdeps/mach/htl/pt-block.c:46 <damo22>#3 0x08159959 in __sem_timedwait_internal (sem=0x833bb30, timeout=0x0) <damo22> at ../sysdeps/htl/sem-timedwait.c:60 <damo22>#4 0x081597fa in __sem_wait (sem=0x833bb30) at ../sysdeps/htl/sem-wait.c:28 <damo22>#5 0x08100e16 in rumpcomp_pci_irq_establish () <damo22>youpi: rump seems to panic when doclock() is called <damo22>i need to find out what rumpuser_component_schedule() and rumpuser_component_unschedule() are for exactly <youpi>I remember your trace speaking about errno 22 <youpi>is doclock perhaps just calling clock functions with invalid numbers? <damo22>doclock() takes no parameters, but maybe its related to the PRNG not being initialised? <damo22>do we have clock_nanosleep in -lrt ? <youpi>but it'll reject calls with invalid parameters <damo22>hmm maybe i havent seen this before because the time taken to init the irq is longer now, and the timer wrapped or something and invalidated the sleep <AlmuHS>has anyone tested my smp patches? this patches might shows by screen a list of processors and IOAPIC, with the APIC ID of each ***pavlushka_ is now known as pavlushka