IRC channel 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

<damo22>hi

<anatoly>solid_black: heya!

<solid_black>hi!

<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

<damo22>bufctl*

<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>solid_black: https://git.zammit.org/gnumach-sv.git/log/?h=fix-ioapic

<solid_black>thanks

<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

<damo22> https://en.wikipedia.org/wiki/List_of_Intel_chipsets#9xx_chipsets_and_3/4_Series_chipsets

<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>cool

<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

<Pellescours>s/hurd/gnumach/

<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

<youpi>+set_ts();

<damo22>etno: yes, qemu also shows the invalid fpu state messag

IRC channel logs

2024-02-06.log