<bslsk05>
mdasoh/simple_verilator - simple model for evaluating logic with verilator (0 forks/0 stargazers)
gog has joined #osdev
gog has quit [Client Quit]
CaCode- has quit [Ping timeout: 256 seconds]
the_lanetly_052 has joined #osdev
the_lanetly_052 has quit [Max SendQ exceeded]
the_lanetly_052 has joined #osdev
the_lanetly_052 has quit [Max SendQ exceeded]
the_lanetly_052 has joined #osdev
the_lanetly_052 has quit [Max SendQ exceeded]
eroux has joined #osdev
the_lanetly_052 has joined #osdev
[itchyjunk] has quit [Quit: Leaving]
heat has quit [Ping timeout: 250 seconds]
masoudd has joined #osdev
ss4 has joined #osdev
wootehfoot has quit [Ping timeout: 256 seconds]
mlombard has joined #osdev
puck has quit [Excess Flood]
puck has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
the_lanetly_052 has joined #osdev
CaCode has joined #osdev
CaCode_ has joined #osdev
CaCode has quit [Ping timeout: 272 seconds]
<kazinsal>
went to upgrade my one official Linux On The Desktop VM and got this. good work, Mint. https://i.imgur.com/aVJX6Jw.png
<kazinsal>
I'm not even sure where to go about starting to troubleshoot this but at least I took a snapshot before the upgrade
<klange>
mm, crispy gpu
<Mutabah>
I've seen that happen recently too... try software rendering as a fallback
<Mutabah>
(at least it'll allow you to dig into the issue)
<kazinsal>
yeah it looks like at some point the vmsvga drivers just utterly broke because switching the paravirtual graphics to BGA fixes it but obviously provides no acceleration
<CompanionCube>
there was once a mesa update which caused...a .colourful desktop momentarily
_eryjus has quit [Remote host closed the connection]
eryjus has joined #osdev
[itchyjunk] has joined #osdev
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
srjek has joined #osdev
blockhead has quit []
eroux has joined #osdev
sonny has joined #osdev
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
jjuran_ has joined #osdev
jjuran has quit [Ping timeout: 260 seconds]
jjuran_ is now known as jjuran
xenos1984 has quit [Ping timeout: 260 seconds]
<mrvn>
vin: Beware that flash also has an erasure size, which frequently is something like 64k. So while you can write 512b or 4k blocks you can only erase 64k chunks for reuse. If the disk runs out of space the firmware will have to copy partially used erasure blocks around to free one up for reuse.
<mrvn>
vin: or your driver for storage that is accessed at a low level.
xenos1984 has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
mahmutov has joined #osdev
ElectronApps has quit [Remote host closed the connection]
<j`ey>
I'm trying to run qemu-system-x86_64 (never run it before, only -aarch64) like so: qemu-system-x86_64 -hda debian.img -cdrom debian-testing-amd64-netinst.iso -boot d -m 512 -nographic
<j`ey>
I don't get any output.. is there something I'm missing/doing wrong?
<j`ey>
seems im on quite an old qemu (2.1, from 2017), but I assume that's fine
<gog>
idk what grub does to do output but if it's trying to draw it's own fonts you won't get any
the_lanetly_052_ has quit [Ping timeout: 272 seconds]
<gog>
OVMF will redirect ConOut to serial and print that
<j`ey>
so I probably should grab OVMF then..
<gog>
oh wait
<gog>
sorry i was assuming you were using UEFI
<gog>
uh, idk then, but whatever grub does for output isn't going to work with -nographic
<gog>
do you want a headless boot so you can ssh in or something?
<j`ey>
yeah
<gog>
there are packages for headless versions of qemu
<gog>
idk what your distro is
<j`ey>
Ubuntu
<gog>
apt-cache search qemu-headless ?
<gog>
although it might conflict with regular qemu
<j`ey>
no headless package
<j`ey>
-curses flashes up something from the bios, too quick for me to sea, but then it doens't show anything after that
<gog>
yeah i'm guessing grub draws to the framebuffer itself
<gog>
and in turn linux console does as well
<gog>
can you set the kernel parameters to force it to use serial output for the message stream?
<gog>
idk how one would do that via command line from the host though
<j`ey>
I tried to use '-append', but that's only available with -kernel
<mrvn>
console=tty0 console=ttyS0,115200 to get both
<gog>
yeah
<mrvn>
try -curses and -nographics
<j`ey>
together?
<j`ey>
i tried separately and together
wootehfoot has quit [Ping timeout: 256 seconds]
<mrvn>
and does any combination show something?
<j`ey>
nope
<j`ey>
well as i said curses shows the bios briefly, but thats it
<mrvn>
hmm, maybe I have something in my grub.cfg for serial output
<j`ey>
it just has '640 x 480 GGraphic Mode' in the middle of my screen with -curses
<kingoffrance>
hit ctrl-c
<kingoffrance>
also, how do you have an older qemu than me
<j`ey>
apparently that's what this old ubunut has
<mrvn>
yeah, you have to turn off the framebuffer
<j`ey>
maybe I should just build it from source..
<kingoffrance>
i just used -curses and hit ctrl-c and gives me a boot>
<kingoffrance>
*-display curses
<j`ey>
ctrl-c doesnt do anything for me :/
* j`ey
googling
<kingoffrance>
well i can reproduce it with ctrl-c <space> <enter> it goes: vga blank mode <bios stuff> 640 x 480 graphic mode (shown on terminal curses output)
<kingoffrance>
so really it gives an error first, but then a get boot: and i can "help" from there
<kingoffrance>
*then i
<j`ey>
no keys do anything for me
<kingoffrance>
i mean, it doesnt show anything until i wait for "640 x 480 graphic mode" to show up on curses, then <ctrl-c> <space> <enter> then i finally see an error and "boot:" prompt. this is qemu 3.1.0 and 2022 02 21 debian 12 (bookworm) netinst. i should mention i just found this by mashing
<kingoffrance>
so i dont claim that is correct
<kingoffrance>
really i was just hitting ctrl-c to close it lol
<j`ey>
heh
the_lanetly_052 has joined #osdev
<kingoffrance>
i also have a qemu 0.13.0 ..
<j`ey>
archlinux gets a bit further but then seems to hang
<j`ey>
ok no, it was just slow, it's printing systemd out now
Terlisimo has quit [Quit: Connection reset by beer]
rwb has joined #osdev
Terlisimo has joined #osdev
sonny has quit [Ping timeout: 272 seconds]
sonny has joined #osdev
dayimproper has quit [Ping timeout: 240 seconds]
X-Scale` has joined #osdev
dayimproper has joined #osdev
X-Scale has quit [Ping timeout: 272 seconds]
X-Scale` is now known as X-Scale
Matt|home has quit [Killed (NickServ (GHOST command used by matt|lib!~matt|lib@12.188.116.55))]
bauen1 has joined #osdev
<vin>
makes sense, mrvn
sonny has quit [Ping timeout: 256 seconds]
Matt|home has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
dennis95 has quit [Quit: Leaving]
<gog>
my memory manager rewrite is progressing
<gog>
no more ugly hack to get the struct page cache set up
<gog>
now it's a genius, elegant hack
sonny has joined #osdev
<jimbzy>
The best hacks are the ones that work when everything in your gut says they shouldn't.
<gog>
yes, this in particular solves an annoying potential issue where if there weren't enough contiguous free physical pages i wouldn't be able to make the page stack
<gog>
and not being able to track pages that are like MMIO or something way out of bounds of the end of physical memory
<mrvn>
gog: I totaly ignore physical contiguous
<gog>
mrvn: i still need large enough contiguous regions to load my boot images but those are rather small still
<gog>
i don't think it'll ever become an issue
<mrvn>
gog: why? load them into virtual memory?
<gog>
my loader isn't quite set up for that. in theory it's possible if i read them in a page at a time and switch from the UEFI mappings to the kernel ones and back
<gog>
and i was working on an experiment with that before but it didn't work and i didn't bother digging into why
<gog>
that might go on my TODO though
<mrvn>
gog: well, in the loader you have the memory map giving you a huge chunk of physical memory and you just use it up.