IRC channel logs


back to list of logs

<damo22>youpi: i had a dream and i think i figured out the bug with rump in my dream
<damo22>will test my theory after work
<damo22>i got a stacktrace, it seems to be aborting when waiting for a semaphore
<damo22>in rumpcomp_pci_irq_establish
<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>that's EINVAL
<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>we should have, yes
<damo22>i wonder if it works
<youpi>AFAIK it does
<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