IRC channel logs


back to list of logs

<damo22>youpi: can we assume the HPET exists for now on ACPI platforms?
<damo22>the PIT one shot code is broken anyway
<damo22>we dont use the pit_*delay functions anywhere else
<damo22>except for smp init
<ram_man>Can you use hurd as your daily driver?
<zamfofex>ram_man: From my experience with it (not a lot) just barely not.
<zamfofex>But for me, I want a working browser. There is Ladybird, but it’s still not quite good enough. If you don’t need a browser, then you might be able to use it as your daily driver.
<ram_man>Okay, thanks.
<solid_black>hi all
<anatoly>solid_black: heya!
<solid_black>sooo, I fixed an issue about apk(1)
<solid_black>in how they stored errors inside pointers, which didn't quite work with Hurd's choice of errno numeric values out of the box
<solid_black>and now abuild kind of works
<solid_black>except it currently has nothing to build, since there's no network so it cannot fetch sources
<anatoly>solid_black: I thought it's working
<anatoly>abuild is working
<damo22>solid_black: why would i get error in kmem_cache_alloc_from_slab where bufptr is NULL ?
<solid_black>ACTION looks
<damo22>during boot with smp when there is a lot of contention
<damo22>it fails the assert
<solid_black>hm, is there any sort of locking at all around slab->first_free?
<solid_black>"The cache must be locked before calling this function.", right
<damo22>yes the function is called with the cache locked
<solid_black>what's your call stack?
<damo22>bit difficult to get the call stack
<solid_black>can I repro it with qemu?
<damo22>well, you could try booting my smp branch zam/fix-ioapic
<damo22>with -smp 2
<damo22>you would need to compile with apic and ncpus>1
<damo22>and --disable-linux-groups
<damo22>it seems my patches have changed smp behaviour, it might actually work if we fix these remaining contention issues
<damo22>i used to get slow boot, now i get fast boot but it crashes before i get a shell
<damo22>im rebuilding with kdb
<youpi>damo22: I don't know froim which models hpet is availabkle?
<solid_black>damo22: please remind me where that repo is?
<damo22> kmem_cache_alloc(c10b8b00,f540c5d8,0)+0xdf
<damo22> fp_load(f64ce988,f5bb9e38,4b,14)+0xcd
<damo22> fpnoextflt(f67f49a0,f64c1060,ffdc20,0,ffdc58)+0x14
<damo22> user_trap(f64c1060)+0xd5
<damo22> >>>>> No coprocessor (7) at 0x810e420 <<<<<
<damo22>youpi: since 2005
<youpi>damo22: then yes, let's just assume it's there
<damo22>youpi: as far as ai can tell, pre HPET means no SMP
<damo22>eg, Pentium 4
<youpi>pentium 4 had hyper-threading
<youpi>also, remember there were smp systems with multiple sockets and no multicore or hyperthread
<youpi>there even were 486 smp :)
<youpi>but yes, no smp pre 2005 should be fine enough for us
<youpi>we just need to safely back to no-smp
<damo22>its not set in stone, we can add PIT support later if we need t
<damo22>but i think what we have now is working
<damo22>removing the existing PIT one shot is good because it does not work
<damo22>i tried to make it work, it would count to ten at different speeds
<damo22>both in qemu and on hw
<damo22>maybe i was doing something wrong, but its not worth fixing right now
<damo22>solid_black: argh, i forgot to force push to that branch
<damo22>i just pushed my latest code
<solid_black>ack, rebuilt
<damo22>im thinking that fpu commit recently may have been borked
<damo22>im trying to rebuild with it reverted
<damo22>>>>>> No coprocessor (7) at 0x810e420 <<<<< what does this mean
<damo22>fpu bug?
<solid_black>I'm actually getting an ext2fs crash on the second CPU
<youpi>for the time being, I'd advise binding all essential tasks on cpu0
<youpi>to skip their race issues
<damo22> chmod: changing permissions of '/dev/shm': Read-only file system
<damo22> Kernel Page fault trap, eip 0xc10500b9, code 0, cr2 244
<damo22> kernel: Page fault (14), code=0
<damo22> Stopped at cause_ast_check+0x9: pushl 0x244(%eax)
<damo22>something fishy with this commit * f8d0f98e fpu: Fix cpuid feature detection
<damo22>when i revert it, my errors regarding invalid fpu state go away
<solid_black>so ext2fs now failes to open hd0, which makes sense since you told me to build without Linux drivers
<solid_black>can I still enable hd drivers?
<Pellescours>solid_black: use rumpdisks (wd disks)
<Pellescours>hd drivers are not smp safe
<solid_black>they're not?
<Pellescours>maybe they were in linux but I don't think the integration to hurd keep that safely. better assule it's not
<solid_black>with rumpdisk/noide, things boot somewhat, and hang after "Activaing swap... failed"
<solid_black>I'm not seeing any task die though, nor the assertion failure
<solid_black>both CPUs are in machine_idle
<etno>damo22: the FPU patch (cpuid thingy) changes the cpuid location where the capability bits are read from. I am pretty sure that we were reading in the wrong place (was leading to an undef-instr trap on my pentium). The underlying logic was supposedly not changed, but fixing the feature bits may have uncovered something else ?
<etno>damo22: is the fpu state issue reproducible on qemu ?
<etno>Would fpu_module_init() have to be called by each processor?
<youpi>it sure needs so
<youpi>but note that fp_default_state doesn't need to be initialized several times
<youpi>only clear_ts() and fninit() need so
<damo22>etno: yes, qemu also shows the invalid fpu state messag