<ukky>
it is funny, 'dd' took one second to write 1.2 GiB ISO onto USB. And then 'sync' took 9 minutes to complete write operation. The whole file was cached in RAM, I guess.
<jaeger>
Yeah, I've seen that as well :)
dim_ is now known as dim44
groovy2shoes has joined #crux
DanDan_ is now known as DanDan
braewoods__ has quit [Read error: Connection reset by peer]
braewoods__ has joined #crux
lavaball has joined #crux
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
<lavaball>
do i need CONFIG_FUTEX if i run musl?
<tilman>
i think musl relies on futexes for multithreading
<SiFuh>
tilman: It does. FUTEX should be enabled. Certain user applications use it as well, such as polkitd.
guido_rokepo has joined #crux
<lavaball>
thanks a bunch.
<lavaball>
also isn't it nice, when you put together a kernel and everything works? well, the keyboard didn't but that's it. first time too. and i took out everything i didn't need.
<farkuhar>
lavaball: non-working keyboard can sometimes be attributed to buggy motherboard or USB controller, not to your kernel config. This one https://www.pckeyboard.com/page/product/MINI_M for example sometimes requires disconnecting and plugging back in, before I'm able to enter my login credentials on tty1.
<farkuhar>
But the drastic measure of disconnect/reconnect is only needed when the keyboard has to share a USB hub with another device. Usually I can get away with toggling NumLock on and off.
<lavaball>
farkuhar, you're a bit late. i had to enable ... what did i have to enable? i think some pci thing for the usb hub or something. anyway, all fine. i'm on my second kernel right now for the my single core atom box no ht.
<lavaball>
thanks though.
<farkuhar>
lavaball: I figured you managed to solve the problem already. I was just commenting that sometimes the kernel config is not at fault, and the hardware just doesn't play nicely together. In this channel I got some recommendations for boot parameters to try, but what ended up being most convenient was to let the keyboard have one USB hub all to itself.
<farkuhar>
and that workaround is only needed on my ASRock motherboard. The same keyboard happily coexists alongside other devices on one USB hub when plugged into a different computer.
jjasghar_ has quit [Quit: WeeChat 2.3]
jjasghar has joined #crux
jjasghar has quit [Changing host]
jjasghar has joined #crux
<lavaball>
i wouldn't mind all that if the hardware didn't also have backdoors. that's what i need work arounds for.
<lavaball>
then again makes any midigations unnecessary since the call is coming from inside the house anyway.
<lavaball>
mitigations.
guido_rokepo has quit [Quit: guido_rokepo]
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
aardo has joined #crux
ardo has quit [Ping timeout: 258 seconds]
<ukky>
jaeger: Tested your new ISO. VMD driver did the trick, now NVMe is accessible in UEFI boot. Thanks!
<ukky>
farkuhar: What are vendor and device IDs of your keyboard, which requires special treatment in ASRock MB?
<farkuhar>
ukky: Bus 001 Device 003: ID 17f6:0005 Unicomp, Inc. Mini M
<farkuhar>
I think Unicomp took some shortcuts when it switched suppliers for its USB controller. They were out of stock for a while because their previous supplier stopped shipping the needed part.
<farkuhar>
I'm surprised they tried to give the NumLock key a non-standard role, when designing around the tenkeyless layout. I think if they had left it alone, without trying to make up for the loss of a dedicated numpad, then the keyboard wouldn't require special tweaks to initialize.
lavaball has quit [Remote host closed the connection]
<ukky>
farkuhar: have to leave, will be back in about two hours
<cruxbot>
[contrib.git/3.7]: qemu-guest-agent: updated to version 8.1.0