#Astral
1 messages · Page 27 of 1
interestingly it also skipped fd 4?
this might be some refcounting issue but where the refcounting is bad I have no idea
since on refcount = 0 the vnode gets set to null
flags too
it's kinda weird that the close of an unrelated fd affects it at all
or well not unrelated given that its the dirfd passed to openat but at that point it shouldn't depend on it in any way
yeah looking at the code theres nothing that immediatelly comes to my attention
wtf why is it not using fd 4
and the same slab is allocated for both the dirfd and the new file opened from it
oh wtf
thats
and its not coming from cleanfile
slab bug???
but I dont run into that which is so weird
can u print the slab allocations and frees
like in slab.c
that's probably going to be a ton of logs, will have to print to e9
its freed twice at some point
bruh wtf why is it not assert failing
oh I think I might have put that behind an ifdef
turns out that its a bug in dirfd_enter
static inline int dirfd_enter(char *path, int dirfd, file_t **file, vnode_t **dirnode) {
if (*path == '/') {
*dirnode = proc_get_root();
} else if (dirfd == AT_FDCWD) {
*dirnode = proc_get_cwd();
} else {
*file = fd_get(dirfd);
if (file == NULL) {
return EBADF;
}
*dirnode = (*file)->vnode;
if ((*dirnode)->type != V_TYPE_DIR) {
//fd_release(*file);
return ENOTDIR;
}
}
return 0;
}
``` that commented out line, at least as far as I can tell the usual functions that use dirfd_enter unconditionally call dirfd_leave if a node was returned even in the case of an error which does `fd_release(file)` so if its already released by dirfd_enter it does a release twice
btw i wrote this script (in c++) that parses logs similar to those allocation logs to check for discrepancies
might be helpful, just ping me I'll send source code
sorry that im not participating in the tech jargon here but does astral have loop devices
no
@grand shadow sorry for ping but if you have 2 minutes of free time could you check if commenting out the lines in ps2mouse.c which construct and queue a mouse packet reproduce the issue from yesterday for you? i kinda narrowed the crash down to that lol
Wtf crazy that this hasnt caused issues so far
I can do that in a bit
And that’s planned. Your point?
running a chromium binary linked against glibc?
yeah no our point was a glibc chromium
cuz steam linux client
Yeah that’s a yikes
Me when im retarded
this guy
I mean, how its grouped in the code probably does not help mich
noooo it does not lol
but it's all good, that was a good find
im just blind it is what it is🥀

loop devices as in disk or network?
there is a network loopback
but no disk loopback
why would you need a disk loopback
mounting partitions out of a image
actually i forgot i did use them and they are pretty usefull lmao
completely forgot
mount disk image i meant
no
at least I now know that xorg works on this libc
now idk what should I try to get running, ig I could try factorio (though it probably has the weird thing that's there on linux too on this libc where the save files are incompatible with the normal glibc version for some reason)
also unrelated to this it'd be nice to have a script to update the disk image instead of recreating it every time, ig I might make one
I never made one because I'm p sure that would need like root for mounting and that'd be kind of annoying
but if you figure something out I will merge it
also WTF how did you get the sidebar
yes it does need root for mouting the image, but honestly it's worth it
that does not work normally
idk it just worked lol
💀
guess its a linux sysdep unimplemented thing
I should look into it
having the sidebar would be epic
tbh I didn't even know there should be a side bar normally, I just assumed it was an update or smth
fvwm has a side bar normally it just doesnt work on astral
you know those two windows that appear on boot?
thats supposed to be the side bar

I think it might be an unimplemented epoll causing issues
how would it be any different on a different libc if that would be the case though?
do you expose epoll?
yes but all the epoll functions just return enosys
I guess printf debugging the sidebar might help
@prime juniper when you eventually do mlibc-linux, can you build fvwm3 as well?
Sure
I’ve confirmed the weekend to be available
So pending weather and the EOY post we can ball
helll yeah
I think it might actually just work (granted it takes like a ton of time to load, ig it might be better if the graphics would be forced to very low)
plus it needs /proc/self/exe symlink, I just created that manually
wtf real
factorio on astral
I guess I already fixed that weird bug that you hit on your mlibc shim attempt?
possibly, idr what that bug was about anymore
iirc it was a page fault
what was the xorg corruption btw
or was it just the file stuff
also even on windows space age takes an eternity to load for me I cant imagine it on astral 💀
the xorg stuff was at least partly a skill issue on my part as I forgot to install the xf86 drivers
oh lmao
5fps 💀
ig this might possibly be somewhat improved by building the libc in release mode (though the allocator there isn't the best in general, its not the worst but its not the best either)
also factorio is only using 1 render thread due to sched_getaffinity not being implemented
oh right that could be an issue
idk how much it affects the perf
I guess it might be a decent boost especially if qemu is given more actual cores
likely
although with the current vmm page fault code it might not be that big of an improvement
since paging in a writeable page means a shootdown
I need to add a fast path for that case
that doesn't involve 2 faults
I have the same exact issue too lmao
btw what is printing the stuff you type to the left of the screen? because its kinda annoying as it messes up any windows in there
to disable the console echoing stuff u need to use stty -iecho or whatever
I dont have something like linux which I think allows you to completely disable a vtty
so my startwm script just disabled echoing etc
ah
I need to stop procrastinating and actually sit down and finish the vmm page locking code for dmaing into userspace and also some more optimizations
but my brain wants to read voxel raytracing papers instead
i wonder how i should handle console keyboard input with the evdev implementation
i wanted to create a mux input device which just gives you all events queued to any device but i realized that won't work because there's some more state i'd have to somehow replicate, each device can expose ABS_* limits (for ABS_X, ABS_Y and stuff like that) so that won't work with a mux device
couldn't you make some kind of ioctl for that to query them for a device?
and store a device identifier in each packet so then the info can be queried either through the ioctl or got from a cache indexed by the identifier or smth
idk
that's not how evdev works
you can query limits for each type of event using an ioctl, yes
but they are per event type, not per event
so multiplexing events from multiple devices where they could have different limits wont work
ah, yeah I haven't looked into how evdev works at all it was just a random idea lol
¯_(ツ)_/¯
i am not gonna subject myself to reading linux source code
no, thank you
it was like 24fps with 2 threads (and getaffinity stubbed to return that) but then when I wanted to try it with 8 threads it took almost an hour to load and runs like shit (even worse than with 1 thread at least in the menu, it just froze when I tried to click a button)
💀
but tbh 24fps is pretty close to playable already
its not a huge stuttery mess like 5
there defo needs to be some smp work in astral to make it better
and drm drivers 
fun
steal the new frigg sharded allocator
how did you manage to port factorio?
well its not really porting its just running the unmodified linux build on a libc that is binary compatible with glibc enough for it to work
Factorio multithreads certain things, namely I know for a fact these are distinct threads:
- Power network
- Fluid simulation
- Machines
But IIRC there's slightly more
Looks like transport belts and trains are also distinct threads
interesting, I just knew about the render threads because there is an option for it
I think that's the limit of threads it spins up. I said threads here but what I really meant was more like in parallel.
They didn't go into very specific detail of how they start the threads themselves, but there's a decent chance this is a thread pool situation.
what happens if you run on one cpu
you can still have multiple threads on one cpu
but it won't help, and will probably hurt performance if your workload is compute bound
@carmine swallow do you expose/implement shmget/fstatfs on your libc?
I am looking at the fvwm3 logs and trying to see if it really isn't an unimplemented thing
because like, maybe it would shm to communicate the living processes to the sidebar or w/e
they are enosys too, I didn't implement any new sysdeps that you didn't have in mlibc
except yesterday I implemented sched_yield because it was spamming it when loading factorio but that's not related to the fvwm thing
hmmmm
weeeird
disabling shm didn't help so like blegh I really will have to dive into the source
btw, do you plan on eventually upstreaming that kernel work?
Yes I can make a pr with that + the AT_BASE stuff + whatever else there was
based
@grand shadow https://github.com/Mathewnd/Astral/blob/79466293b76d273e2d410a9a6da1fe6605b31dcb/kernel-src/io/pci.c#L131
aren't PCI register accesses supposed to be 4-aligned?
iirc as long as you don't cross a 4 byte boundary you're fine
alright
i'm pretty sure the access has to be naturally aligned
so 16-bit accesses need to have lsb clear in the address
i'll stay 4-aligned just in case
4 aligned is the safe bet but yeah this works too
how the heck did you open this file, skip all of the functions that do the reading and come to the conclusion that it does unaligned accesses?
pci_read16 literally aligns it before reading
😭
lmaoooo
Even I forgot that it does that and I wrote the fucking code
☠️
Nobody remembers every single line they write
especially since most of them got replaced by corpo code lol
Been super busy lately so almost no work on this damn
RIP
400 stars on github gg
Contrags!
@grand shadow i got this while booting ur shit
on qemu
i used the images on ur site
and the qemu command in the pinned message
gl
it faults right after printing:
kernel_init: running routine arch_early
ill just build it myself bleh
there were some issues with monkuous' xsave detection code that iirc I have since then fixed
so that could be it
DISTROTYPE=minimal make```
this is the command to build a minimal distro right
indeed
amazing
though iirc it now by default builds a minimal image and only builds the full image on a make disk
which I mean you probably should boot it from disk anyways
so yeah just DISTROTYPE=minimal make all disk
then to run make run-disk-kvm
I: Checking Release signature
E: Invalid Release signature (key id 0E98404D386FA1D9)
🥀
maybe my jinx version is too old or something
don't have the energy to update it and go through every single package to fix any issues that appear
oh well
but thats still super weird considering a few weeks ago iretq managed to build it just fine
lemme do a fresh git clone and see if I get teh same issue
trolled
use a real distro other than debian
so this problem is literally just because im using debian
that and my outdated jinx probably
I mean I think u could maybe update the snapshot in jinx directly
ill just rename my keyring file for a second
change the debian_snapshot="" variable in jinx
change it to that?
fix ur shit pls, doesnt work
talk is cheap send patches

I need to eventually update jinx
mathewnd why doesnt my fvwm-root thing work i get no wallpaper 
is it just skill issue?
probably
it works for me
the only thing that doesn't work is the sidebar
but it worked in qwinci's libc
so I am inclined to think its something with mlibc
but I've never debugged it
other than like python what external dependencies did fvwm3 need
not including the libraries
it has been like almost 2 years no way I will remember that
damn
meanwhile xbstrap is still backwards compat to a 5 year+ old version 
obos-strap always works as long as you are using my exact build environment 
put it in a container 
someone I don't recognize opened a pr and caught a very interesting issue
it seems like the osdev wiki page for the madt is just wrong
it does seem that there was some issue with how I handled the apic nonetheless
so maybe once I finish looking into that maybe that is what was wrong with ps/2? 
since it does use the i/o apic
@analog berry though one thing I am not understanding, what should one do in the 00 case?
just have a table that maps irq -> mode?
ah wait nevermind I am stupid
use the default for the bus type like it says
could be
how were u even able to make it this far with this bug
I have no idea
I guess qemu just did not care and I didnt use any other ISA interrupts
yeah I only use it for like ps/2, the serial port and 32-bit hpet without msi
and acpi
I should probably fix that in the osdev wiki as well
there
anyways, if anyone whose ps/2 did not work before wants to try it again I would be thankful cc @fleet osprey @robust geyser
alright, but I won't be able to test on the Optiplex 755 that had the fucked up PS/2 emulation
that machine died 
will test it on the t14 gen 1 amd and the precision t1650 when I get home tho
Dang
not working on framework 13 :(
u have wiki articles?
I mean as in, MADT article
updated image with super early logging enabled + some nvme fix
as long as you prefix every sentence describing your OS with AI you will make billions
you don't even need to finish the sentence, when an investor reads the sentence their brain turns off after AI and they will give you millions
lol
he is missing one thing, make the ai generate the gdt at runtime
btw did you ever vibecoded something in astral
Astral is fully handwritten slop
```
$ gcc main.c
You have reached your daily Astral limit, how would you like to proceed?
[*] Learn about Astral Plus™ offers -- 3000 daily commands for just $9.99 if you buy within the next 3:24
[ ] Watch 2 minutes of ads to unlock an extra 100 Bash commands
[ ] Wait for your limit to reset
adopt a semi-proprietary model like Chromium vs Chrome, Code OSS vs VS Code, etc
Astralium (FOSS) vs Astral (proprietary)
Astralium is just a shitty kernel shell, Astral gives you a full OS

this idea has a lot of potential, what about some GCC patching:
```
$ gcc main.c
main.c: In function ‘main’:
main.c:2:9: error: implicit declaration of function ‘print’ [-Wimplicit-function-declaration]
2 | print("hello world");
| ^~~~~
While programming is a lot of fun, remembering the exact header that contains a specific standard library function can be exhausting.
That's where today's sponsor Brilliant.org comes in. Brilliant offers courses that make it easy to refresh your C knowledge. Sign up with code Astral to get 20% off in your first two months.
this is already a thing just not LLMs
i think linux has at least one scheduler based on a neural net lol
but it probably (hopefully?) doesn't evaluate that in the kernel, right?
We need llms for the max hype farming
Astralium is newlib, busybox, and tcc, astral is mlibc, gnu {core,find,diff}utils/bash, and gcc
nah, too complete
you can't let them unlock the "full" version 
technically with newlib, busybox, and tcc, you could (with enough pain and suffering) build your own copy of mlibc, all of the gnu stuff, and gcc
every copy of Astral is personalized
It generates a profile based on a quiz and automatically edits the kernel using ai to be more efficient to your use case
that’s so 2024. You need ✨ AI
port llama2.c or something of that calibre
kde
well astral is always one step ahead in ports
never underestimate mathew
yeah
i don't think bro is gonna port systemd
but tbf kde with openrc is possible
elogind exists, sadly
kde would be sick tho
but xfce is nice :^) and xorg, mathew likes that
when wayland
when mathew adds drm
when uDRM 
u need the kernel drm interface
@ marvin
didnt that project have like 5 commits and was ditched
lmao
yes
and that uDrivers thing
ahhhhrhehhshshs USB
uSB
micro serial bus 
new project #21378472987345928374
Were that true KDE would not run on FreeBSD (no logind and no true udev) but it does
I will simply port the windows wm 
astral copilot when
i3wm
download dotfiles from some github repos and post it to r/unixporn
steal it from ReactOS 
So much to do and so little {time,motivation} to do it
I need to get back on this
Last thing I was doing was a proper memory locking thing for dmaing directly into userspace without breaking posix fork semantics
just declare it UB if you try to fork while another thread is doing a read/write
So true
Everything is ub so the program should not expect any behaviour at all
There is a 3.33% chance a open() instead deletes the file
int two = 1 + 1 is now UB
may cause a triple fault
...I was serious
it should be UB to do a fork during read/write
port xfce4
That'd basically amount to: multi threaded programs cannot spawn new programs
which would be severely limiting
Do not spawn new programs while you are reading and writing
Or expect some writes from your parent to still go through as a child
UB doesn't have to mean "crash"
How do you ensure that w/o very heavy locking?
Or you could just implement this properly in the vmm. It's not particularly hard compared to the other challenges of a vmm
How do you "implement this properly"?
so the logic is, while you are performing a read(), reading from that data is UB, because you either have old data from before the read(), or actually new data. if you perform a write(), writing to the buffer during that is UB because the data written will either be old data or new data.
if you fork a process while reading, you'd be taking a snapshot of the data during a read.
if the read() happens to finish then you just have the new data.
if you start messing around with the buffer while the data is still being read in in the parent process you're probably doing something wrong even if you don't know it, since you're implicitly accessing another thread's state (the former thread that used to be in the parent but didn't come in with the child)
that's like if a thread poked and prodded into another thread while it's reading/writing, except only until the point of the extant read finishing, and only as long as you don't write to that memory, because otherwise CoW applies
doesn't a similar race exist with just normal anon memory that gets CoWed?
one thread is writing to a buffer while another forks
ah no i didn't read the context
ah, that's true but I believe that's not the issue that matheus was talking about (?)
the valid outcomes if a read() and fork() happens at the same time are:
- neither parent nor child have modified data
- parent has (partially) modified data, child has a copy of the old data
- both parent and child have (partially) modified data but the child has a private copy (either via CoW or an actual copy)
what's certainly forbidden is that the child first sees unmodified data and then modifications happening
no. the race happens after
my OS would probably be susceptible to this issue right now, since read/write operations take strong references to the pages backing the buffer
so as long as neither the parent nor child write to the memory they both see the new data
Managarm certainly implements this properly
by eagerly copying pages that are currently DMAd to
instead of using CoW for them
sure. I could do that. but in reality, what is the risk that this happens, and that this affects anything? whatever the child process sees it probably won't understand
chances are it'll be half-read data (parts of old data and parts of new data)
or the entirety of new data
or the entirety of old data
whatever it is, this state is "expected" during a read, and a thread probably isn't interested in reading from this buffer unless it's fully read
i think much more subtle things are possible
if the child can see DMA modifications happening after fork
for example:
- T1 fork()s
- T2 allocates memory location P and read(P)s
- the allocator page is processed by fork() before T2 has allocated (and hence location P is free in the child)
- the child allocates memory location P and uses it for something else
(malloc() itself is not async-signal-safe, but if you use your own allocator that doesn't need locks, this would be allowed by posix)
a less stupid example is if you DMA to the stack
- T1 fork()s
- T2 read()s to a buffer on T1's stack
- the child does something else with the same stack space (e.g., by returning from the current function)
the child doesn't allocate memory location P for something else because the page is pinned
the pages backing the buffer are pinned
so if you unmap that buffer and map something else, the same virtual address will have different memory and won't be affected by the ongoing "DMA"
at least that's how it works in my OS
well the buffer can already be allocated
if you mean that e.g. the buffer is malloc'd, then free'd, and then someone mallocs something on top, and the allocator didn't decide to unmap anything, then yeah, there is a problem
i'm sure that you can get into situation where some thread in the parent does read(P) and the child uses virtual address P for something else at the same time
uint32_t value = 0xcccccccc;
if (fork() == 0) {
assert(value == 0xcccccccc); // this must not fail, but with your scheme it can
_Exit(0);
}
int fd = open("/dev/zero", O_RDONLY);
read(fd, &value, sizeof(value));
close(fd);
the initializer for the value means that the stack page it occupies is allocated before the fork
if the read does dma (it wouldn't since it's /dev/zero but pretend it's some other file and it's using O_DIRECT) before the child gets to the assert, the child would see the new value
No, it can't
With my current scheme, read() pins the pages after the fork(), so the pages are eagerly copy-on-write-faulted
Meaning the address of value is already replaced with a new page by the time the actual "DMA" takes place.
You have to use two threads for this
And the fork has to happen during the actual read operation, but after the pages have been pinned
right
bro has been typing for 20 minutes 😭
okay revised example
#define BUFFER_SIZE 0x1000
static int can_read;
void *do_read(void *ptr) {
int fd = open(tmpnam(NULL), O_RDWR | O_CREAT | O_EXCL | O_DIRECT);
ftruncate(fd, BUFFER_SIZE);
while (!atomic_load(&can_read)) {
futex_wait(&can_read, 0);
}
read(fd, ptr, BUFFER_SIZE);
close(fd);
return NULL;
}
int main() {
uint8_t *ptr = mmap(NULL, BUFFER_SIZE * 2, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
pthread_t thread;
pthread_create(&thread, NULL, do_read, ptr);
memset(ptr, 0xcc, BUFFER_SIZE);
atomic_store(&can_read, 1);
futex_wake(&can_read);
while (atomic_load(&ptr[0]) == 0xcc) {
// spin until read has begun
}
if (fork() == 0) {
memcpy(ptr + BUFFER_SIZE, ptr, BUFFER_SIZE);
sleep(1);
assert(memcmp(ptr, ptr + BUFFER_SIZE, BUFFER_SIZE) == 0);
_Exit(0);
}
}
you try writing c code in discord on your phone
been there, done that
anyway with this code it's possible that the child starts execution before the read has finished
in this case the read will finish during the child's sleep call
with your scheme the two copies of the data in the child wouldn't be the same, since the bottom half of the buffer has the finished results of the read while the top half has the unfinished results that were copied before the read was done
@grand shadow why - 1 on the entry count?
https://github.com/Mathewnd/Astral/blob/152f1ef94a159faf4a5b6a01e45475f97fb6a8bf/kernel-src/io/block/nvme.c#L444
it's a 1-based count
aka a value of 0 means 1
huh
not that crazy
read the spec 💀
how cursed do you think it would be to use Astral as a test kernel/OS for lil?
I'm basically looking for something that I can quickly run in QEMU + real hw, that has a sane build system, and preferably can be netbooted
what would the advantage be over Managarm?
if it's trivially netbootable, convenience and having a second impl to check against
being monolithic is a big plus bc that would verify the capability to build it freestanding
why would it be more easy to netboot than Managarm?
the pain of managarm is not the netboot itself
well, my question is what the pain is lol
you won't run into ehci memes when you netboot
and astral doesn't have ehci anyway (?)
it have only xhci
update: astral will have a permanent install on a real machine starting next month so some of my development will now pivot to writing drivers for it
it'll be on an older amd64 machine at my uni
no way
nice, what dirvers do you still need?
ahci + rtl8169 (I think, waiting for a lspci -nn to confirm) + maybe xhci
indeed
10ec:8168
the first thing I'm gonna do is probably the nic, since it seems simpler
then ahci then maybe finishing the xhci work with iretq
the page cache rewrite being pushed once again but it is what it is
NICs are also generally the most useful devices
since if you have a NIC you can ssh in or transfer logs out etc
true
I have multiple r8169 devices if you want me to test it
lmfao osdev wiki
would be cool
I could send u a spec
Oh nice more datasheets to grab 
that may or may not work with your driver
ik it doesnt work with mine
and i used that same spec
ig I should've actually paid attention to the mac type specific init code
all haswell era hw
btw
https://github.com/Mathewnd/Astral/blob/152f1ef94a159faf4a5b6a01e45475f97fb6a8bf/kernel-src/io/block/nvme.c#L484
here you do - 1 too but the doc say it is zero-based. Is there something I don't understand?
zero based => value of 0 means 1, value of 1 means 2 etc?
NVMe 1.3d, 1.5 Conventions, p. 12
what is the osdev controller code doing bruh
it sets the 9346CR register while its completely unescessary
it does not write to these registers at all
also sets a reserved bit
trolled
which one
i need to make sure i dont accidentally do that
I cant believe u use osdev wiki as driver writing guide lmfao
I was using it to figure out where to begin I always cross referenced it with the specs
unless you want me to vibe code this 
also wtf why does qemu not support msi for this
thats just stupid
That might end up being more productive tbh
I really do not want to get into pci pin bullshit
but ig I might have to if I want to test thi sout
Its pretty easy since you already have uacpi anyway
time to learn how to do that with uacpi and how I am gonna abstract that away
probably just have each driver register a handler callback and have every pin have a list of callbacks
I guess it might be because it only supports the older model of it in general (though that wouldn't still prevent qemu from having a msi=on switch on the device like it does with eg. hda)
if I knew how the qemu codebase worked I would have honestly tried to implement it but I have no idea how to even begin there
See managarm source ig
(I just wanted to see how hard would it be to add msi support to it and turns out its not hard at all, I just looked at the hda driver and copied the msi code from there slightly modified to fit the rtl8139)
interesting
damn if I had rewritten the device driver handling this would've been so much easier
huh what
qemu doesnt have r8169... at all
r8139?
yeah
ic
welp
that was useless
I dont think any emulator implements it soooo
you'll test for me 
yea sure
fun fact my network stack was originally only ever tested on real hardware since no emulator did r8169 and it was the only nic I had for a while
but uh I would test it on my laptop but its ethernet port has ran out of hopes and dreams
(it used to run on hope and dreams but it ran out)
((maybe it needs to be filled with determination?))
cc @mild sentinel
@obsidian pivot my desktop uses the same Linux driver right?
Also I got another 4 hours of off forsaken sleep

So I should be able to test it
After I sleeep
i can't imagine that LLMs are good at driver writing
the sample set is small and the LLM can't really iterate to test it
unless you somehow hook it up to real hw
they'd just turn into copypaste engines (well, more than they already are)
with license and quality implications
yeah
at least its somewhat compatible with rtl8168, idk about the 8169 tho
the rtl8168 and rtl8169 are more similar to each other than they are to the r8139
afaik
at least in my driver there are like 3 small differences between the 8139/8168
granted there might be more regarding the phy setup (and probably is), that's something that I haven't properly done lol
well good news and bad news
yay! (and aww)
good news? apparently my desktop has an 8168
bad news?
I don't think I can pull an ethernet cable to my room dawg 💀

maybe if I buy a super long one
I have a bunch of PCs with Realtek 816x NICs that have cables run to them
do you have another device in your room that runs linux (and has an internet connection)
so if you need me to test stuff then sure, send it over
closest thing is a laptop with wsl
oh wait
I do have one
a laptop from 2004 with linux from scratch 🥀
that works
that I don't even know if it boots
it has an ethernet port and a wifi card right?
yeah
ok, then you can make a network bridge
networkmanager makes this super easy
you act as a router basically, and can either NAT or just plain forward the requests for the ethernet device
guess I gotta pull out the good old dell latidude 110l
smart honestly
its gonna make life much easier compared to having to send the iso over to other ppl
it was just by chance that I opened the windows device manager to look at what my NIC is
and saw that it literally matches 1:1 the vendor:id of the rtl8168
wonder if you can use windwos for that because I really really do not want to search for the charger of that laptop
apparently windows has something called ICS?
this comes with the benefit of being able to wireshark, which sounds nice
oh right
I need to buy a fkin usb stick
good thing theres a place selling them nearby
you can get powerline adapters
you can select two adapters, right click and select "bridge connections" in ncpa.cpl
not sure what kind of bridge it creates though, so if that matters to you then you should use linux lol
anyhow, I think I have all of the initialiaztion including phy stuff working
well not working
haven't tested
but its there
so I am writing the interrupt code and then I will hook it up and test
for testing you don't even need a bridge
okay so I think I have the whole driver written now
its not perfect but its probably enough for now
tomorrow I'll buy a usb stick and test it
I have pushed the code
or rather would have if my gh token hadn't expired
there
well today is carnival so all the stores are closed
testing will have to wait till tomorrow
if u want to I can send an iso
I can't even write to non nvme disk 🥀
maam your computer has virus
what vendor:id is your card btw, the driver is hardcoded to realtek:8168
how i check that on linux? sudo lspci -vvvv or some thing
iirc? the linux driver r8169 supports the RTL8111H and r8168?
here we go 10ec:8168
@mild sentinel @obsidian pivot pick the initrd option
does this include the cool minecraft port
the initrd does not
it only contains the bare minimum really
but if you can connect it to the internet I think you could xbps install everything
as long as you have enough ram for it 💀
32gb 
should be enough right
Okay rebooting into it now
Thank you REFIND for not making me go into my BIOS
@grand shadow how long is it expected for there to be a black screen with the initrd option?
will do
once im back home
let me send you the early boot logs
You do support AMD hardware right
how big is your screen btw
think so
1080p
wtf
I do have 3. Monitors tho?
One is vertical too
@grand shadow I do have an idea to make the PC speaker be able to output debugging logs if that could help 💀
this should have early boot logs enabled (flanterm set up the earlist thing possible)
czapek also had some issues with a black screen booting astral and it was something related to flanterm init, maybe I need to update flanterm or smth
I havent personally really tested in real HW in a long while so maybe there was some regression on all real hw boots
I also have an Intel laptop and another amd laptop I can test on
@grand shadow page fault
Looks like null derefrence
Also no stack trace 
Kernec
kerneç*
uh oh
that explains why the screen was black
gotta find out
its in pushlock.c
probably acquiring a pushlock on a slab which is not craeted somehow
I should really add a backtrace print to my panic function at some poin
This is why I test hardware before pushing any commit
Steal my super crappy implementation for now that is prone to panicing its self 
@grand shadow it is working on an Intel laptop it seems AND OH SHIT IT HAS THE SAME NIC
I saw the driver pop up
yo??
u'll have to reboot to get the nic to work again after plugging it in btw I don't really reset the phy and do autonegotiation on a link up irq
uhh plug it in, reboot, run netd rtl8169.0
or whatever the device node is called in /dev/
uhh does the node exist in /dev
It shows in ls
oh u don't need the /dev/
it'll append it to the path automatically
also crazy ps/2 works
can u send a pic of what its outputting to see if everything else is ok
also nice seems like the nvme driver also works
That’s all it said before hanging
oh it just locked up damn
And control C isn’t working
does a ctrl+C kill it or
Nope
oh we LOVE deadlocks
hmmm
It just can’t take the signal?
probably is just stuck somewhere
Shouldn’t the signal override that 
and that 00:00:00:00:00 is sus
Well clearly the driver is doing somthing
during the driver init does it like print the mac address properly?
maybe it doesnt have a preconfiured one or something
MATHEWND IS BEST KERBEL DEV
100% NOT HACKED ACCOUNT
How should I check
The bootlogs etc
it'll print the driver maybe just record a vid and see what it prints
I don't have a dmesglike ringbuffer yet
which is also another good idea to have probably
oh yeah to reboot can u do like
reboot
oh press the power button
Well it’s locked up
just to see if acpi is working
holy
And power button made it goto sigKILL before I just held power button
But the shutdown command worked earlier
oh thats working then
what does that even mean
send sigterm
send sigkill
sync
reboot
a paperclip and some bottle caps
The c has a diacritic ç
Gotta keep that in mind
true
Have an astral mirror on my git server 
I actually ended up having to mirror limine and flabterm
Because codeberg was crashing
So my friend couldn’t make the build system work 😭
codeberg and freedesktop.org on a downtime competition
TS is kinda funny
- the git history gonna be wiped once i686 is done and the repo fully cleaned up to standards by me anyways so

oh on mine its next to enter
so instead of accidentally terminating messages in \ i would get ç, but since i use the us layout mostly nowadays then yeah
Oh it page faulted this time @grand shadow
during uacpi init, spooky
try mammogram or pmos or obos
can't really make out the rip
This isn’t good @grand shadow
holy
yeah this and bad checksum tells me crazy memory corruption
how tf did this not happen on the first boot
Magic
It survived two boots
🤷♂️
let me see if reseting on qemu breaks things

make sure it doesnt clean the memory
I ran it with randomized limine memory some weeks ago and it worked fine
I better be getting extra pocket lint with my paper clips and and bottle caps for this
maybe a race condition or smth
or something that triggers with a specific amount of physical memory
tried with randomized memory again and it works
Yeah 🥀
gotta run it infinite times so that you test every possible value in every possible byte across the entire memory space

Do you have a specialy tessellated void to test this
nope
thats an AML_READ() in uacpi
🥀
does a cold boot give such problems?
It it a UACPI bug?
This was a cold boot
I doubit its a uacpi bug
🥀
It also is an HP laptop
nah highly doubt it
we need a mammogram boot test
Can you get me managarm ISO to test on here
I've always thought of it as HP = Hinge Problems, or Huge Problems
I'm gonna see if I can fix that first slab bug, maybe theres an allocator issue that I have not found
yeah
It’s many things at once
which is weird because this allocator works perfectly fine otherwise (ran stuff like meicnraft and wine)
#1217009725711847465 message
That will cost an extra napkin ontop of the paper clips pocket lint and bottle caps
how rich do u think the community is
You have enough to afford ram
had*
Well we can do a payment plan
also maybe my ram is a google drive swap partition 
unzip and dd
wdym
ah
why is the image 4gb exact
good question
is it a disk image?
yes
so it has R/W space etc?
i guess so
so yeah an astral bug
Wait let me try some extra boots
yeah give it a shot
if u wanna get rid of that assert you will have to comment out some code
Also the printing on here is much faster
but it doesnt matter much
Kernel mode setting for the nvidia GPU?
nah, it allocates from an irq handler
which was prohibited recently
so now it dies
Okay it did more stuff before failing there?
The terminal emulator I guess isn’t flanterm?
its sorta non deterministic when it will trigger the assert exactly since it depends on when the embedded controller irq comes in
Ahhh
probably
yeah its not flanterm
What do you use for the terminal
https://github.com/managarm/managarm/blob/a2692a7bb0e73ee37969168569f3864afa029925/kernel/thor/system/acpi/ec.cpp#L195 basically this code
Pragmatic microkernel-based OS with fully asynchronous I/O - managarm/managarm
how many cpus does this machine have?
causes the assert
It’s an Intel P/E core machine
Let me check in shitdows
I'm thinking it might be something related to it using huge slab sizes when the cpu counts passes a certian point so I just wanna confirm
I mean I saw it giving CPUids of like 40 somthing
CPU46
wait is that the same machine?
astral has race conditions 😱
probably because logging was disabled
I enabled logging
the desktop is the one which had that slab page fault right?
The desktop had page fault yeah
ah
and how many cores does it have
8c/16t
which bug
the slab init page fault
ah good
yes because obos boots on 100% of hw 
when in doubt disable smp
yeah its because theres enough cpus for it to become an indirect slab
which calls into the main allocator
oops!
thats fine, I gotta debug ts
managarm uses custom font rendering for the boot logging, idk if its maybe the fact that it draws the text of the lines scanline by scanline up to down (first drawing the first line of all chars of the line, then second etc)
I'll ping when I got a new iso
that's probably better for the cache than drawing individual characters fully
doesnt flanterm also have this otpimization
That way when it scrolls it manages to update faster?
yeah because WC works properly in this case
since the entire cache line is filled before eviction
And is the terminal a userspace server I presume?
i mean it runs before userspace so probably not
and its not really a full terminal as you can't type in it
I think somebody here said having a terminal emulator in the kernel would be against micro kernels for debugging logs 
Exactly like this is doing
well its just a text sink in this case
not a terminal per se
it would be hell to debug otherwise
Well yeah but it would have the same things except there isn’t a keyboard or such hooked into it 
perhaps
I think the solution is to just turn that alloc() into a cache of itself
astrole
casserole
I think it kinda does yeah, though as the actual fb putchar function is called through a function pointer it probably can't optimize stuff like the line byte offset calculation
true
Could LTO allow this?
if it can devirtualize the call but idk how easy that is
like its an optimization that exists for c++ virtual functions
@mild sentinel @obsidian pivot new iso with early slab crash (hopefully) fixed
cc @robust geyser since I think this also happened on your machine
I think this is also what caused that black screen
since the slab init can run before the term init as one does not depend on the other
I wonder whether I should test astral on an old samsung laptop that I have 
yes
I just noticed I never actually copy the mac address to the actual netdev struct
wooooops
want me to wait for that fix?
(or well its not really an actual laptop anymore as I removed the casing and screwed the mobo + screen to a piece of wood)
do so
its compiling its just a one liner
ok
should i test something too?
if u want
flashing rn
sorry got distracted
@grand shadow it boots on the laptop again but i forgor the ethernet
leme test desktop
@grand shadow
banger
Is that what it’s meant to do now
I have no idea why it is doing that, I guess I can add some debug prints
Does it do this on QEMU?
@grand shadow I don’t think it is even able to SIGKILL it
💀
It’s stuck
its crazy that ps2 works
It’s a QEMU bug then
traditionally you have at least a minimal debugger in the kernel and that can also provide a rudimentary console
did it blow up
damn
Skill issue?


