IRC channel logs

<damo22>jbgg: lapic_timer_val is being updated every timer interrupt, but im not sure if that is being used as the real timer... it wraps around when it overflows

<damo22>i wasnt sure how to implement the lapic timer, i just made it update a counter

<damo22>the pit timer is disabled afaik

<damo22>see ioapic.c

<damo22>it probably needs to be tied into mach's timer somehow

***Mete-- is now known as Mete-

<damo22>jbgg: actually, the lapic timer is configured to interrupt at 100Hz, coincidentally but should be set to "HZ" not 100: https://github.com/AlmuHS/GNUMach_SMP/blob/smp_stage2/i386/i386at/ioapic.c#L182

<damo22>so it should actually be working

<luckyluke>jbgg: did you check on which cpu the fault happens? could it be that it happens on the second cpu, which is not added to the scheduler (so current_thread() is not initialized there) but still has interrupts enabled?

<damo22>i think libpciaccess fails because we are using both methods, the x86 method succeeds, but then rumpdisk calls pciaccess with hurd method but STILL the /servers/bus/pci cannot be used, it needs to use the device_open(pci) ?

<Pellescours>probably yes, isn't libpciaccess fallback to device_open if fs cannot be used ?

<damo22>yes but Joan reads from _SERVERS_BUS_PCI in all cases within the map range function

<damo22>i need to make the root port available

<damo22>and just use that

<youpi>note: "fs cannot be used" is possibly a difficult thing to do at bootstrap

<youpi>better try device_open first

<damo22>it works

<damo22>!!!

<damo22>i have a patch for libpciaccess that fixes it

<damo22>bedtime

<jbgg>damo22: thanks, i will check the lapic timer

<jbgg>luckyluke: in theory the second cpu is halted, and the gdb break is in the master cpu

<jbgg>I have checked it again, and the gdb information just previously of the page fault gives weird information about arguments variables of the thread_quantum_update function, for instance mycpu=7 ¿?

<jbgg>I will check it depper

<Pellescours>jbgg: If you do start the VM with only one core, is the page fault happen too? If yes that can make it easier to debug, if no, it will bring an information

***roptat is now known as Guest3438

<arashatt>hi everyone

<arashatt>I'm from Iran.

<Pellescours>hi arashatt

<Mete->hello

***Guest3438 is now known as roptat

<arashatt>I love gnu

<arashatt>But I'm a procrastinator

<curiosa>how come that if i do # mig /usr/include/i386-gnu/hurd/ioctls.defs

<curiosa>I get the following:

<curiosa>"/usr/include/i386-gnu/bits/ioctls.h", line 103: syntax error

<curiosa>"/usr/include/i386-gnu/bits/ioctls.h", line 111: syntax error

IRC channel logs

2022-02-14.log