<kazinsal>
I only realized this because they're having a big sale
<kazinsal>
buy two or more books or ebooks and use the discount code BOOKSGIVING at checkout for 55% off your subtotal
<kazinsal>
boss told me yesterday we needed more Azure certs so I went to the microsoft press store to see what the cost of Azure cert books was like and saw that
<kazinsal>
thought, heck, why not
sm2n has quit [Ping timeout: 265 seconds]
sm2n has joined #osdev
sprock has joined #osdev
AmyMalik is now known as MelMalik
sdfgsdfg has joined #osdev
<sonny>
I'll probably get it
sdfgsdfg has quit [Quit: ZzzZ]
sonny has quit [Quit: Client closed]
lumo_e has joined #osdev
lumo_e has quit [Quit: Quit]
Oli has quit [Quit: leaving]
sdfgsdfg has joined #osdev
zaquest has quit [Remote host closed the connection]
<klange>
Time to go through all my source files and clean them up in preparation for 2.0...
<klange>
Gotta make sure everything is updated to the javadoc-style leading comments, remove all the vim hints (why are there new files from after I fully switched to bim that still have those?), make sure everything has an approprate copyright notice...
[itchyjunk] has joined #osdev
ns12 has quit [Quit: bye]
<Ameisen>
geist: both compilers
<Ameisen>
(Was at in-laws)
<Ameisen>
mind that it is dependent on coroutines (which isn't solid in either compiler yet) and a third-party lib to provide the generator class
ElectronApps has joined #osdev
sonny has joined #osdev
c2a1 has joined #osdev
sonny has quit [Ping timeout: 256 seconds]
<geist>
yah i had a ton of people at my place all day
the_lanetly_052_ has joined #osdev
amazigh has joined #osdev
<amazigh>
hello, what emulator do you recommend do get into osdev?
<klange>
all of them
<amazigh>
I was looking for a small machine emulator, like 8bit thing, but none has network support.
<kazinsal>
qemu to rapidly test builds, VMware to test enterprise virtualization, real hardware to test performance
<klange>
I wouldn't get into osdev by targetting small embedded machines - most of them were never intended to run anything akin to an operating system
<amazigh>
I go the qemu route, then amd64 arch for the CPU is the way to go?
<klange>
x86-64 is definitely top of _my_ list of suggestions, and I spend most of my time with QEMU
<amazigh>
I am really a newbie, hence I struggle to find something to start with, any help?
<klange>
wiki.osdev.org
<amazigh>
I mean what task can I do to get started?
* amazigh
looking at the wiki
<klange>
There's whole articles there about things to do to get started.
<moon-child>
amazigh: ohai
<kazinsal>
we really at some point ought to refresh some of the beginner tutorials. maybe once I do the whole "64-bit kernel rewrite" thing I'll spend some time on that
<kazinsal>
there's still some atrocities in the "getting started" department
<klange>
Personal opinions: 1) Target x86-64 to start. There's so much more community documentation than for anything else. Aarch64 and RiscV are cool things, but the references just aren't there.
<kazinsal>
And the physical presence of platforms you can osdev on.
<klange>
2) Don't write a bootloader. At least to start. There's now several viable boot environments you can use to get up and running and bootloaders are just an exercise in legacy cruft.
<kazinsal>
thank you for the reminder that I need to find a bootloader that'll do 64-bit ELFs over TFTP
<geist>
okay, so time to write a bootloader!
<kazinsal>
ha!
<geist>
somewhere i still have a NE2000 card that has a load off tftp rom in it
<geist>
was kinda nice
<geist>
no idea where it came from
<klange>
If you slap a multiboot1-with-aout-kludge header in it, there's a PXE multiboot loader that should work.
<klange>
Though, uh, you'll need a longmode bootstrap.
<kazinsal>
yeah, right now I have GRUB doing the PXE boot
<geist>
amazigh: yah what klange said. 8 bit is a bit low, hard to build much of a complex modern system with it, though you can but you'll be fighting assembly and whatnot more than anything esle
<klange>
GRUB will also happily load 64-bit ELFs as multiboot2 correctly, though again - need a longmode bootstrap as it still will put you in protected.
<geist>
but, say 32bit cortex-m class ARM stuff you can do a proper preemptive OS on if you want
<moon-child>
kazinsal: I think filling in the gaps might be more valuable. I feel like a _lot_ of people say 'I finished barebones; now what?'
the_lanetly_052_ has quit [Ping timeout: 260 seconds]
<klange>
3) "What emulator should I use?" All of them. Run your OS in everything you can get your hands on. I even test my OS in Bochs _which takes several minutes to boot it_. QEMU, VirtualBox, VMWare Workstation - use 'em all.
<amazigh>
ok got that
<geist>
though to be fair when just getting started out having a single emulator is pretty useful
<geist>
yes yes you shoudl run it on everything yes, but that's a bit of a tall ask for someone just getting started
<geist>
also presumes you're on x86 where there *are* multiple emulators
<klange>
It's been a looong time since it was relevant to me, but I recall Bochs has very good tools for the super low level early debugging.
<geist>
for most other arches there are a lot less options
<geist>
though i guess you did recommend x86-64
<klange>
qemu would be the best universal choice, I imagine
<amazigh>
The wiki sounds great (I was told osdev wiki was not great..)
<amazigh>
Someone recommended me to read on bsd kernel code, instead.
<amazigh>
(sorry for the noise!)
<klange>
Reading code for a large project is not a great way to learn. And I say that as someone whose primarily goal with my project is to have a large project for people to read to learn...
<amazigh>
Anyway, going through OS from 0 to 1.
<amazigh>
(the book)
<amazigh>
moon-child: hey
NeoCron has quit [Ping timeout: 260 seconds]
[itchyjunk] has quit [Remote host closed the connection]
vdamewood has quit [Quit: Life beckons]
the_lanetly_052_ has joined #osdev
gorgonical_ has joined #osdev
<gorgonical_>
For the life of me can't figure out why linux won't take an interrupt on arm64. All my understanding of the arm virtual interrupt system says it should be
<gorgonical_>
But it doesn't
<gorgonical_>
:(
<gorgonical_>
Is there anything I should be checking? The hypervisor marks hcr_el2.vi, and hcr_el2.imo is on, so it should be delivering them. Linux for it's part doesn't have interrupts masked but I never get a message showing that it took the interrupt and the hypervisor still shows it as pending
xenos1984 has quit [Quit: Leaving.]
gorgonical_ has quit [Quit: WeeChat 2.9]
<geist>
hmm, what class of interrupt is it?
xenos1984 has joined #osdev
nyah has joined #osdev
xenos1984 has quit [Quit: Leaving.]
PraiseIdleness has joined #osdev
PraiseIdleness has quit [Client Quit]
sdfgsdfg has joined #osdev
xenos1984 has joined #osdev
GeDaMo has joined #osdev
givemeyourpies has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<j`ey>
gog: you said you know about ELF right? I have an elf sym.. but im not sure how I find the code associated with that?
<j`ey>
st_value as an offset from the section its in?
<klange>
What kind of ELF do you have?
<j`ey>
elf64
<klange>
I mean what kind of object is
<j`ey>
oh, currently Im messing around with a .o, elf 64 relocatable
<j`ey>
although the plan is to eventually work on an executable
<klange>
Every symbol has an st_shndx with the section it belongs to. If that is an actual section and not UNDEF or something implementation-specific, then st_value should be added to the relevant section's sh_addr.
<j`ey>
and that's the offset in the elf file?
<klange>
Eh, depends.
<klange>
Actually I should say "absolutely not".
<klange>
sh_offset is the offset into the file
<j`ey>
:D
<klange>
sh_addr you are supposed to fill in with the actual address
<klange>
And similarly you are supposed to put the final symbol address into st_value for the symbols.
<j`ey>
I'm not trying to load this to run it, I'm trying to do some analysis
<j`ey>
on the machine code
<klange>
If you have a NOBITS section, then sh_addr (and sh_offset) should be unset and you need to allocate space for them
<klange>
Ah, well, have you ever tried to look at an object file with, say, objdump?
<klange>
And noticed that all sorts of stuff looks weird and sometimes outright wrong?
<j`ey>
whys that?
<klange>
You kinda need to perform relocations for some code to make any sense or it'll all be meaningless zeros or sometimes offsets (though x86-64 you tend to get zeros - x86-32 tended to have values in the code because you'd get more relocations that use "value currently there")
<klange>
x86-64 output, at least from binutils, prefers relocations with addends where the values come with the relocations rather than being in the place where the relocation goes
<j`ey>
hmm
<j`ey>
I didnt consider having to apply relocation
<j`ey>
well I can get an instruction out now, that's cool
<bslsk05>
github.com: toaruos/module.c at v1.14.1 · klange/toaruos · GitHub
<j`ey>
will have a look, t
<j`ey>
y
<j`ey>
I can print out all the insts of a function/symbol now
mctpyt has quit [Ping timeout: 250 seconds]
<j`ey>
ah yes, clearly I need to relocate or something, all the branch instructions are 'bl 0'
<klange>
yep :D
<klange>
for stuff local to the object, section offset + symbol value should be fine
<klange>
for UNDEF (external stuff), I would just assign a random unique address
<klange>
and then Elf64 relocatable objects should only have a couple of different kinds of relocations and they're all pretty straightforward
<klange>
they're arch-dependent, so if you're doing arm they'll be different values than the x86-64 stuff, but probably still the same basic "write 32-bit value, write 64-bit value, write some value with offset from the address..."
<j`ey>
I think the Linux kernel only uses one, which is the write some value to some address
<klange>
I have no idea how they're controlling that, I've seen three types out of my object files
<j`ey>
only R_AARCH64_RELATIVE is handled
<klange>
oh, you know, it could be because _32 only shows up in debug sections, and _PC32 only shows up in eh_frames...
<bslsk05>
github.com: linux/head.S at master · torvalds/linux · GitHub
<klange>
I do see my actual text sections only have R_X86_64_64
zid has quit [Killed (NickServ (GHOST command used by zid`))]
_eryjus has joined #osdev
amine7 has joined #osdev
onering has joined #osdev
LostFrog has joined #osdev
m5zs7k_ has joined #osdev
brettgilio3 has joined #osdev
X-Scale` has joined #osdev
Piraty_ has joined #osdev
bradd_ has joined #osdev
z_is_stimky_ has joined #osdev
AndroUser2 has joined #osdev
sprocket has joined #osdev
JerryXia1 has joined #osdev
gog has quit [Ping timeout: 250 seconds]
brenns105 has joined #osdev
rorx_ has joined #osdev
Griwes_ has joined #osdev
HeTo_ has joined #osdev
smeso has quit [Killed (NickServ (GHOST command used by smeso_))]
smeso has joined #osdev
Griwes has quit [Ping timeout: 260 seconds]
c2a1 has quit [Ping timeout: 260 seconds]
gmodena has quit [Ping timeout: 260 seconds]
xenos1984 has quit [Ping timeout: 260 seconds]
sprock has quit [Ping timeout: 260 seconds]
X-Scale has quit [Ping timeout: 260 seconds]
bradd has quit [Ping timeout: 260 seconds]
nur has quit [Ping timeout: 260 seconds]
bauen1_ has quit [Ping timeout: 260 seconds]
Beato has quit [Ping timeout: 260 seconds]
hbag has quit [Ping timeout: 260 seconds]
Dreg has quit [Ping timeout: 260 seconds]
brettgilio has quit [Ping timeout: 260 seconds]
Piraty has quit [Ping timeout: 260 seconds]
HeTo has quit [Ping timeout: 260 seconds]
z_is_stimky has quit [Ping timeout: 260 seconds]
PapaFrog has quit [Ping timeout: 260 seconds]
air has quit [Ping timeout: 260 seconds]
eryjus has quit [Ping timeout: 260 seconds]
rorx has quit [Ping timeout: 260 seconds]
m5zs7k has quit [Ping timeout: 260 seconds]
amine has quit [Ping timeout: 260 seconds]
DanDan has quit [Ping timeout: 260 seconds]
Geertiebear has quit [Ping timeout: 260 seconds]
brenns10 has quit [Ping timeout: 260 seconds]
JerryXiao has quit [Ping timeout: 260 seconds]
brenns105 is now known as brenns10
amine7 is now known as amine
brettgilio3 is now known as brettgilio
m5zs7k_ is now known as m5zs7k
X-Scale` is now known as X-Scale
<klange>
Ah, there it goes, was wondering when that would happen.
HeTo_ is now known as HeTo
air has joined #osdev
xenos1984 has joined #osdev
xenos1984 has quit [Client Quit]
<j`ey>
oh, I see the virtual address values now, when I run my program on the executable (not just the .o)
<j`ey>
(and it crashes because im using st_value as an offset..)
<j`ey>
so now I need to understand how to get the file offset, instead of that virtual address
<j`ey>
oh, I think I can subtract the st_value from the sh_addr of the section its in
DanDan has joined #osdev
mctpyt has joined #osdev
stultusv has quit [Quit: WeeChat 3.0.1]
AndroUser2 is now known as c2a1
[itchyjunk] has joined #osdev
dennis95 has joined #osdev
Piraty_ is now known as Piraty
Vercas has quit [Remote host closed the connection]
xenos1984 has joined #osdev
tenshi has joined #osdev
Vercas has joined #osdev
gog has joined #osdev
sonny has joined #osdev
sonny has quit [Ping timeout: 256 seconds]
sprocket has quit [Ping timeout: 250 seconds]
sonny has joined #osdev
sonny has quit [Ping timeout: 256 seconds]
gog has quit [Quit: byee]
<j`ey>
sweet, I need to veryify it more, but it looks like my tool can, starting with a certain function, find all the functions that it transitively calls
zid has joined #osdev
<zid>
I ran my OS. It page faulted.
<zid>
My breakpoint on my page fault handler refuses to hit.
<zid>
I gave up
hussein has joined #osdev
ElectronApps has quit [Remote host closed the connection]
gog has joined #osdev
sonny has joined #osdev
gog has quit [Read error: Connection reset by peer]
gog` has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 256 seconds]
gog` has quit [Ping timeout: 260 seconds]
mctpyt has quit [Remote host closed the connection]
sprock has joined #osdev
<ornxka>
anyone used the CLINT register for qemu riscv64? whenever i set mtimecmp to (uint64_t)-1 it generates interrupts continuously
givemeyourpies has joined #osdev
xenos1984 has quit [Quit: Leaving.]
<ornxka>
when i set it to eg 0xCFFFFFFFFFFFFFFF, i dont get an interrupt, but for -1 i get things like info: timer interrupt: mtime=0x0000000000EF3BD0, mtimecmp=0xFFFFFFFFFFFFFFFF
_eryjus has quit [Remote host closed the connection]
eryjus has joined #osdev
gog has joined #osdev
Oli has joined #osdev
isaacwoods has joined #osdev
dennis95 has quit [Ping timeout: 245 seconds]
riv has joined #osdev
xenos1984 has joined #osdev
<riv>
will there be another qemu advent calendar?
rorx_ is now known as rorx
mctpyt has joined #osdev
gog` has joined #osdev
gog` has quit [Client Quit]
hbag has joined #osdev
Dreg has joined #osdev
sonny has quit [Quit: Client closed]
c2a1 has quit [Ping timeout: 250 seconds]
Griwes_ is now known as Griwes
mahmutov_ has joined #osdev
freakazoid343 has quit [Read error: Connection reset by peer]
<zid>
pf handler should be faulting, breakpoint is on it, instead I get a breakpoint for a fake SIGQUIT
<zid>
err pf handler should be *hit* by a fault
<clever>
zid: you can tell gdb to ignore signals and let the "signal handler" run as normal
<clever>
i often have to do that when debugging linux over jtag with a real arm code
<zid>
howhow
<zid>
qemu shouldn't be sending a 'signal' though :(
<clever>
check the gdb docs for normal signal handling
<clever>
and tell gdb to ignore the signal
<zid>
that's.. absolutely not what I want though
<zid>
qemu has turned the IRQ into a signal, somehow
<zid>
I didn't deliver any signals to gdb.. qemu did
<clever>
that happens even with real hardware
<clever>
openocd turns real irq's on a real arm core into a signal
<clever>
and its up to the gdb config to decide if the irq happens normally or gets caught
<zid>
so I need to 'pass' on it, so that my *kernel* sees the IRQ?
<clever>
yeah
<zid>
weird
<zid>
let's try pass SIGQUIT
<zid>
(gdb) pass SIGQUIT
<zid>
(gdb) c
<zid>
Program rec..
<zid>
nostop it too maybe?
<zid>
oh maybe I need *nopass*
<zid>
That makes nothing happen
sonny has joined #osdev
sonny has left #osdev [#osdev]
sprock has quit [Ping timeout: 260 seconds]
<zid>
no matter what I try, I get the signal, I just.. ignore it or not
vdamewood has joined #osdev
<zid>
I rolled back and I can definitely hit int_pf if I do it from kernel space, but for some reason qemu/gdb *cares deeply* about whether cs&3 = 3?
<zid>
yet I can't find anything in the source about sigquit or anything
vdamewood has quit [Ping timeout: 240 seconds]
sprock has joined #osdev
vdamewood has joined #osdev
<zid>
at least old builds work, I'll use it to write a decent pf handler and make it stay working as I reapply the new shit
<zid>
as I wanted that bp because my pf handler is shitty
LostFrog has quit [Ping timeout: 256 seconds]
sprock has quit [Ping timeout: 240 seconds]
<geist>
you can also try to debug it without breakpointing with just the -d int stuff
<geist>
usually thats enough (in my experience) to see what was going on
<zid>
yea I am getting e e 8, with vector 2 on the e
<zid>
but I can't get the error code which is the fault addr
brettgilio has quit [Ping timeout: 250 seconds]
<geist>
but -d int prints it
<geist>
also cr2 is the fault addr of a PF anyway, errcode is the reason (read/write, etc)
<zid>
it prints.. v, e, i, cpl, ip, pc, sp, cr2
<zid>
ah cr2
<zid>
that makes no sense, yay
<geist>
that cr2 has the pf address?
<zid>
no, -8 makes no sense :P
<geist>
ah double fault?
<zid>
maybe invalid stack pointer on a failed push to 0?
GeDaMo has quit [Remote host closed the connection]
<geist>
sure. the state of the cpu at the 8 is interesting. what does -d int say there?
<geist>
possible it's E, E (cant handle this), elevated to 8
<geist>
so may mean the state at the time the second E fired is really your problem
<zid>
yea the 0x8 doesn't actually print anything
<geist>
the 8 what? the output of qemu or your code?
<zid>
check_exception old: 0xe new 0x8
<zid>
then (qemu)
<zid>
rather than the register splat like normal
<geist>
i think that makes sense, because the 0xe is the real exception
<geist>
a double fault always happens just after a regular one
<geist>
so the second 0xe is where things are already bad
<zid>
I don't remember it delivering 0xe for 0x8 then a fake 0x8 before, but whatever
<geist>
no, the poitn is it *tries* to deliver the second 0xe and then it cant so it elevates it to a 0x8
<geist>
that's the definition of a double fault
<zid>
right, I don't remember it doing that though
<zid>
as in, printing it like this
<geist>
but you just said it did a 0xe 0xe 0x8
<geist>
so i'm saying go back to the second 0xe and see what the situation was
<zid>
same as the first onebut with v=8 instead of v=e, which is.. something the manual will tell me..
<zid>
reserved bit set?
<geist>
that's whats in the errc?
<zid>
oh e is 0, derp
<zid>
v is now 8, not e
<geist>
okay, i've lost track of whats going on here
<zid>
which means it's printing "new fault e" then printing a double fault
<zid>
instead of an e
<geist>
sound spretty close. also if it happens early enough in boot you can get a full trace if you're really interesting
<geist>
`-d exec,cpu,int`
<geist>
but that generates a firehouse
<geist>
firehose even
<geist>
(still haven't finished my coffee)
<zid>
nah, I'm not even really interested in the trace, I just wanted debugger control at that point so I could step all the reg saves and stuff
<zid>
because I remember the last time I touched this code, having to add rcx to the save list because I forgot before or something and then it was crashing
<zid>
and got nerdsniped by gdb not cooperating
<geist>
ah can't help you there, i never use source level debuggers
<geist>
i'm generally of the opiion that absolutely everything is already there right in front of you
<zid>
It's not vital that I get the breakpoint to hit
<geist>
and youre so close to figurung it out without fighting the debugger
<zid>
I just wanted it as my first action
<zid>
>and got nerdsniped by gdb not cooperating
<zid>
I could absolutely have just ignored gdb and figured it out :p
<geist>
okay
<zid>
kinda shitty if my debug environment is hosed though and breakpoints no longer work on kernel functions
<geist>
that's why i never assume they're available in the first place
<geist>
since by default they are not
<zid>
Thankfully they do work, at least in the general case
<zid>
just irqs are being funky
<zid>
like my pf handler isn't installed or interrupts are masked or something funky
<geist>
well i was just about to say honestly the most annoying part is if you want to do all of that absolutely properly you need to get super familiar with the .cfi directives
<geist>
and it's a huge mess that makes your asm code a huge mess
<zid>
It's actually a C function :P
<geist>
we have all of the zircon code cfied up and it really hurts it
<geist>
sure but you have asm, and you were just talking about how it may be the stack getting pushed
<geist>
side note: you are popping the error code from the first 0xe right? just making sure in case you forgot
<geist>
and/or *not* popping the error code on irqs and whatnot right?
<zid>
well I always end up back where I should at least
<geist>
usually that sort of thing is a straight drop to double faultsville
<zid>
if the stack were misaligned by a word cs and ip would get the wrong stuff
<geist>
yeah absolutely
<geist>
but that didn't really answer the question: did you make sure you're doing it properly on the right irqs?
<geist>
exceptions/irqs/etc
<zid>
This should be the only thing that ever fires
<zid>
and it should be the first fire, and breakpoint the first instruction inside it
<zid>
so ultimately, it doesn't matter, I'm not trying to debug the DF
<zid>
just why the PF handler either doesn't run, or doesn't get breakpointed
<geist>
sure but you said you had plain IRQs as well?
<geist>
okay, sounds like we're not on the same page. i will not be nerdsniped by this!
<zid>
yea, when I go to actually debug this, I will rip this usercode back down to a while(1);
<zid>
and set all its registers to a certain bitpattern
<zid>
make sure IRQs still fire (ping the machine)
<zid>
and then check none of the registers changed in usermode
jjuran has joined #osdev
<zid>
git apply is slow or hanging, not sure which :/
<geist>
your poor xeon is struggling
<zid>
definitely hung
<klange>
well this is an interesting email in my inbox... that I will wait until Monday to even think about replying to...
<sortie>
klange only answers boring emails on weekends like a champion
<zid>
that sounds like "an email"
<sortie>
When I joined $LC_CORP I underestimated how much of my jump would just be like in an office rpg reading exposition infodumps that don't really matter
<klange>
The email is from $LC_CORP
<gog>
stanley parable
<j`ey>
in whose environment are we evaluating $LC_CORP?
<klange>
sortie's
<kazinsal>
$LC_CORP is evaluated client-side
<sortie>
Sometimes $LC_CORP is $LC_SEARCH
<sortie>
A very large amount of working at $LC_CORP is $LC_SEARCH'ing how to do my job
<kazinsal>
I think that's the case for most computer touchin' jobs
<kazinsal>
though I also spend an awful lot of time $LC_SEARCH'ing how to do other peoples jobs for them
<sortie>
Recently I'm been getting into interviewing.. actually hired three people so far including one I was leaning no hire on
<kazinsal>
so what you're saying is if I need a green card, you're my in
<sortie>
Your G&L will be determined accurately and fairly.
<klange>
it has been three years since I have had... this experience
<zid>
I've now officially messed up my stashes and lost a fix to my irq handler
<zid>
and am definitely corrupting the user stack again
<klange>
That sounds like Tuesday. You are aware it's Friday/Saturday, right?
<zid>
sorry :(
<gog>
gotta push rbp on friday
<gog>
everybody's lookin for their stack frame
<zid>
I had to write it to [gs:8]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
sdfgsdfg has quit [Quit: ZzzZ]
mahmutov_ has quit [Ping timeout: 268 seconds]
justinfan123 has joined #osdev
<justinfan123>
hi, so i've been fighting with xhci on the rpi4 some more, and i get a usb port status change event, but commands on the command ring don't seem to work (never get a response). the controller asserts USBSTS.HSE (and pci status says a target abort occured) but i've got no clue what to do with this information now
<justinfan123>
oh oops i forgot to change my nick after messing with twitch's chat :^)
justinfan123 is now known as qookie
<qookie>
anyway, does anyone have any idea how i can actually debug what's wrong?
<zid>
that better be a bidoof
<klange>
bidoof bidoof bidoof is on fire
<kazinsal>
pk0: bidoof on fire
elderK has joined #osdev
sprock has joined #osdev
nmg has joined #osdev
nmg is now known as gorgonical_
<gorgonical_>
geist: what do you mean what class of interrupt? The hypervisor marks the VI bit in hcr_el2 and the Linux driver is supposed to make a hypercall to retrieve the intid. Linux is running at EL1
<gorgonical_>
Sorry for the long delay on the follow up lol
<geist>
ah was just curious if it was a PPI or SPI or whatnot
<geist>
may7be there's different mechanims there?
<gorgonical_>
I actually tested yesterday with a different kernel that I know works and it doesn't take the interrupt either. So maybe the qemu version doesn't correctly emulate this?
<geist>
no idea. since linux is involved there are so many more variables
<gorgonical_>
I've pored over the manual and afaict, if TGE is 0, IMO is 1, and VI is 1, then the Vm should take the interrupt
<gorgonical_>
But that's what I mean, since neither linux nor the lwk take the interrupt from the hypervisor
<j`ey>
lwk?
<gorgonical_>
lightweight kernel
<gorgonical_>
We use the Kitten kernel from sandia
<geist>
maybe it needs more pets?
pretty_dumm_guy has joined #osdev
Burgundy has joined #osdev
<geist>
today's silly kvetch: when i suspend my mint linux machine (cinnamon) it always mashes all the windows into the left monitor when i wake it up
<geist>
i'm sure there's some phase in restart where only one screen exists so it has to move them over
X-Scale has quit [Ping timeout: 250 seconds]
X-Scale` has joined #osdev
<kazinsal>
multi-monitor has been common for many years now yet no OS seems to be able to consistently get it right
<kazinsal>
multi-monitor RDP sessions continue to do weird things
<geist>
yah fwiw windows seems to do a pretty good job of remembering window and icon layout for different screen configs. so it may temporarily slam things around but it usually recovers
<geist>
i dont think cinnamon even tries, though it doesn't seem to screw with my desktop icons at least
<kazinsal>
yeah, my issue seems to usually be if I accidentally bump a cable or something and a monitor "disappears" for a split second
<kazinsal>
at least more often than not the one I bump is the one going to the monitor that is my dedicated chat clients monitor so I just have to drag IRC and discord and the like back over
<geist>
oh but i discovered a feature of chrome that is a game changer for me: you can name windows
<geist>
and, on cinnamon at least, it literally changes the name in the window bar
<geist>
you can also do it on windows and mac but since they dont display the name in the bar it isn't as helpful *except* you can find your named window in the menu
<kazinsal>
ooh, neat
X-Scale has joined #osdev
<geist>
i tend to keep 4 or 5 windows of various topics, sometimes spread across a bunch of virtual desktops
<geist>
so having a name so i can remember is fantastic
<geist>
like programming, osdev, 'main', etc
<j`ey>
ive been using tab groups for that
X-Scale` has quit [Ping timeout: 268 seconds]
<kazinsal>
oh excellent, irccloud has progressive web app support
<geist>
yah, my main problem being that tab groups dont move across virtual desktops and if you have more than one profile active it's still nice to see which one is which
<kazinsal>
previously I've just been running it in its own browser window fullscreened but that has the side effect of any link I click on being opened in the same window instead of my actual main browser window