<mpetch>
_ngn I noticed that in my build I can reproduce your problem. I haven't investigated the how but I think the reason you are having issues is that the TSS address in the TSS GDT entry is encoded incorrectly. As a result you end up pointing at a bogus address for the GDT.. I believe the issue is in your gdt_tss_set macro. that is improperly using
<mpetch>
array indexing.
troseman has quit [Client Quit]
<zid`>
ooh do you have a binary?
<mpetch>
They provided a Github repo. Was able to build from that.
<zid`>
sounds like a no, rip
<mpetch>
Bogus TSS address in the GDT ends up providing them with garbage for RSP0 when the ring transition occurs.
<_ngn>
mpetch: but then how do the kernel interrupts work?
<zid`>
ring0 to ring0 doesn't need to touch the tss
<heat>
kernel interrupts dont look at RSP0
<zid`>
tss is only for finding a valid rsp while in ring3
<_ngn>
ill try to set a random address as the TSS lets see
<mpetch>
Because there are no ring transitions in that case
<bslsk05>
github.com: sdx/kernel/inc/boot/gdt.h at 2fda75232dac82adbc5925832b893c40a72281b9 · mpetch/sdx · GitHub
<_ngn>
oh
<_ngn>
okay ill check the encoding then
<zid`>
which is why it's "rsp0" you're filling out
<zid`>
because it's the rsp used for ring0 if you need to switch to it
<_ngn>
i thought maybe it checks the tss anyway
<_ngn>
zid`: i would dm you the image but you didnt respond
<heat>
casts incorporated
<_ngn>
i assume you have dms closed or smthng
<zid`>
yea this isn't twitter
<heat>
@zid` @nikolar kernal programming
<zid`>
why would you need to pm a link to a binary though?
<heat>
uint64_t serial; // file serial (unique)
<heat>
did you mean: inode number
<zid`>
try it
<heat>
oh ngn implemented fat32 as their first fs
<heat>
yeah that explains the brain damage
* kof673
stares at dcc ghost
<_ngn>
heat: "An inode is denoted by the phrase "file serial number", defined as a per-file system unique identifier for a file." (read it here https://en.wikipedia.org/wiki/Inode)
<heat>
why are you looking at posix for technical guidance?
<heat>
posix stat still returns... st_ino
<_ngn>
idk i was struggling with my implementation
<_ngn>
so i looked up how others do it
<heat>
just call it an inode number, thats how others do it
<_ngn>
im not tryna be posix compatible or anything obv
<heat>
dont be stupidly vague
<_ngn>
alr
<heat>
reminds me of sun or microsoft code just beating around the bush
<_ngn>
i thought the inode number used as a index for a list to find inodes
<heat>
inode? hmmm, vnode. the v stands for virg-
<heat>
hm?
<zid`>
if it's an int it should be inodei
<nikolar>
heat: KRNL
thinkpol has quit [Remote host closed the connection]
<nikolar>
(what did i miss)
<mpetch>
_ngn those << operators in the gdt_set_tss macro look like they should be >>
<heat>
@nikolar we're on twitter now
<nikolar>
ah sorry
<heat>
@nikolar not on X, dont be racist
<nikolar>
@heat: KRNL
thinkpol has joined #osdev
<zid`>
Yea we're on twitter, not X, so you're not allowed to say the stuff you normally say heat
<zid`>
there's a content policy on twitter
<_ngn>
mpetch: im actually stupid i see
<_ngn>
i was filling the entry with zeros
<heat>
better warn nikolar
<heat>
the least racist serb > most racist KKK member
troseman has joined #osdev
<zid`>
100% true
troseman has quit [Client Quit]
<_ngn>
mpetch: thank you so much that was it
<zid`>
did anyone keep a timer
<zid`>
for how long it took for you to dump the right bytes of your tss and show that they were infact, not right? :P
<nikolar>
hey i am not racist online
<nikolar>
just in person
<_ngn>
no that was right
<_ngn>
it was the gdt entry
<zid`>
yes, the gdt entry *is* the tss
<nikolar>
are we still debuggin this stuff
<zid`>
nah mpetch eventually dumped it as zero, then looked at the code and noticed the shifts were backwards
<heat>
the gdt entry is not the tss
<zid`>
yes it is
<heat>
the gdt entry points to the tss, the tss is its own struct
<zid`>
it's just a union with a gate/task/whatever
<zid`>
it's a gdt entry
<_ngn>
zid`: thank you as well and sorry for wasting your time with the stupid hex formatting
<zid`>
kek, to be fair, you were dumping the wrong thing the entire time :P
<zid`>
I think, depends if they were the same zeros or not
<zid`>
gdt_set_tss_entry(&e[5], &tss); /* TSS */ Explain this heat?
<zid`>
why is it in gdt
<heat>
notice the &tss
<mpetch>
There is a GDT descriptor for the TSS that points at the actually TSS structure.
<mpetch>
actual
<zid`>
yea there's another level of indirection in there
goliath has quit [Quit: SIGSEGV]
mpetch has quit [Quit: Client closed]
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
mpetch has joined #osdev
troseman has joined #osdev
<mpetch>
_ngn I noticed in the qemu log that your TSS was not the correct size. Without an IO bitmap the size should be 0x68 (limit is 0x68-1=0x67) but yours was 0x70 (limit 0x6f). I noticed in the `struct tss` that `reserved1` and `reserved2` are both `uint64_t`. Combined they should be a single `uint64_t`. Could also fix it by making both `reserved1` and
<mpetch>
`reserved2` a `uint32_t` . Since you aren't using an IO bitmap (yet) you should set `io_bitmap_offset` to something higher than what you set the TSS limit to. You could easily do this with `im_tss.io_bitmap_offset = sizeof(struct tss);` in `im_init`
troseman has quit [Client Quit]
<mpetch>
I didn't go looking at the cause but after fixing your TSS issue I started getting `v=0d e=0000 i=0 cpl=3 IP=001b:00010102464c457f` . I think it is interesting to note that the IP(RIP) address contains the ELF header in it.
msv has joined #osdev
<geist>
yah you use LTR to load it
<geist>
and then it'll cache a pointer to the current TSS
<geist>
side note if you're fiddling with qemu, breaking into the console and using `info registers` is *highly* useful for this sort of stuff
<geist>
since it dumps the full state of the cpu plus all the shadow registers
<geist>
though sounds like you're already qemuified
<geist>
yeah, according to some quora post `compl` should equal ~ but that may be via some header thing, like whatever that standard is that defines and/or/not/etc
<bslsk05>
github.com: Creating + writing to a file + stat() in quick succession returns bad st_blocks · Issue #13991 · openzfs/zfs · GitHub
<nikolar>
so zil has two meanings
<nikolar>
one is the write cache as i said earlier
<nikolar>
the other is the in ram cache to group writes
<heat>
i would expect this to be in disk
<heat>
unless fsync() is a lie
<heat>
in which case LOL ZFS LOL
<nikolar>
i don't think fsync is a lie
<nikolar>
but don't most filesystems lie about fsync anyway
<heat>
no?
<heat>
ext4 even waits for the journal
<heat>
(in some capacity)
<heat>
ext4 even fsyncs when you e.g overwrite a file with a rename
<heat>
implicitly
<heat>
i dont see how fsync cant be a lie if I fsync and it says "yessir there you go" but everything is in RAM, which is not the explanation i had wayyyyyyyyyy back
<nikolar>
zil has two meanings and i haven't read closely enough to tell you
<nikolar>
so no clue
<Ermine>
seems like artix website is banned in russia
<nikolar>
oh yeah i think someone mentioned that a while ago
<nikolar>
more like russia is banned from accessing the website because our host blocks them
<Ermine>
well, hosts which geoban usually give 403, not time out
<nikolar>
i might be misremembering it, but that's what i think is going on
<Ermine>
it might be also that your host has enabled ESNI, which authorities here are also trying to block
<nikolar>
esni?
<Ermine>
encrypted SNI
<Ermine>
a tls thingie
<nikolar>
oh maybe
<the_oz>
ZIL and actual write is two writes, whether ZIL hits or not is an eventually, but it's usual to expect ZIL to hit
<the_oz>
whether it happens or not on ZFS on Linux is whatever they're doing over there
<the_oz>
so they're talking about fsync on the second hit when only first hit has happened/not happened