<bslsk05>
pastebin.com: class Rectangle: def __init__(self, length, width, color="red"): s - Pastebin.com
<Skyz>
It's not really osdev yet but I'm starting to plan my first software dev project
trufas has quit [Ping timeout: 252 seconds]
trufas has joined #osdev
<doug16k>
TSC doesn't really have an interrupt, but performance counters do, and you can count cycles, so you could irq on tsc. also, some lapics can do "deadline" irq, which fires timer on TSC. I wouldn't touch deadline though, there are errata
<doug16k>
no point when you can just use the timer itself, just translate units from tsc freq to lapic freq
freakazoid333 has quit [Read error: Connection reset by peer]
colona has joined #osdev
gog has quit [Ping timeout: 255 seconds]
Skyz has quit [Quit: Client closed]
mahmutov has quit [Ping timeout: 272 seconds]
ElectronApps has joined #osdev
heat has quit [Ping timeout: 255 seconds]
<geist>
doug16k: hmm, what kinda errata are you talking about re: tsc deadline?
<geist>
curious since we use it in fuchsia, but of course could just be not hitting hardare with errata
MarchHare has quit [Ping timeout: 255 seconds]
MarchHare has joined #osdev
sts-q has quit [Ping timeout: 255 seconds]
isaacwoods has quit [Quit: WeeChat 3.2]
<doug16k>
4th gen (haswell) errata HSM70 APIC Timer Might Not Signal an Interrupt While in TSC-Deadline Mode - If the APIC timer is in TSC-deadline mode and is armed when a timed MWAIT
<doug16k>
instruction is executed, the timer expiration might not cause an interrupt.
sts-q has joined #osdev
<doug16k>
says bios can contain a workaround so maybe microcode fix
freakazoid333 has joined #osdev
smeso has quit [Quit: smeso]
smeso has joined #osdev
<klange>
Thinking about keyboard layout stuff, as I'm looking at USB and also trying to do more with my laptop that (for reasons entirely unrelated to me living in Japan) has a JIS keyboard.
<klange>
Currently I expose raw scancodes to userspace, configure PS/2 for scancode set 1 via translation, and I have a library shared by the two raw UIs (the VGA terminal and the compositor) that does the translation to an event stream.
<klange>
And that works okay and it's flexible insofar as I can patch the lib to add new key mappings, but it's not a great interface for having generic layout definitions.
<klange>
This is the one area of historic precedence in X11 I'm considerably more unfamiliar with compared to all the other windowing stuff.
<klange>
I also don't know anything about how Linux deals with this stuff from the evdev side...
<moon-child>
I like sdl's distinction of 'keycodes' and 'scancodes'
nyah has quit [Ping timeout: 276 seconds]
<moon-child>
it also distinguishes keypresses from text input. So along one channel you get shift down,d down; along another channel you get shift down,e down; and along the third channel you get "E"
<moon-child>
last bit being abstracted properly (and maybe pluggable) enables more complex ime, xcompose, ...
<klange>
I separate text from keycodes, but I dumbed on the text and it's just a single char - can synthesize multiple events to write UTF-8 strings, but it's sketchy.
<geist>
hmm tangentally got me thinking: does rust have any SDL bindings
<moon-child>
I would do: event contains a layout enumerator, scancode, keycode. If you recognise a layout, you can do something with its scancode; keycode is completely generic. For text translation, can register a hook for given (layout,scancode) pair or keycode; hook can consume as many events as it wants and produces a string of arbitrary length
<moon-child>
(scancode hook is more specific than keycode, lets you do something generic but override it in a specific case)
<moon-child>
important point is that text translation is a separate step _because_ the relationship of keypresses:text length is not 1:1
<klange>
I am keen on implementing a Japanese IME now that I have a TrueType renderer again.
<moon-child>
no good ja bitmaps?
<klange>
I didn't have a general bitmap font support previously, only my SDF renderer and making a Japanese font set for that was infeasible.
<klange>
I would have needed to extend that system for general Unicode support, do some glyph mapping stuff, etc. and it was not worth the investment.
<moon-child>
ahh
<klange>
The TrueType renderer was very much worth my time and it has gone very well. It has been a very good year for feature work in Toaru.
<klange>
One other design mistake I should address is that there is no timestamp data in my input events.
<bslsk05>
andryblack/fontbuilder - Bitmap font generator (89 forks/393 stargazers/MIT)
<doug16k>
basically uses freetype to render everything to an alpha atlas
<doug16k>
I probably didn't turn on japanese
<doug16k>
that's trying hard bitmap font render :D
<doug16k>
on gpu it's amazing
<doug16k>
can just blast all text on the screen in one instanced quad render
<klange>
Rectpacking and embedded kerning data would have been next steps for the SDF renderer if I hadn't decided to ditch it for legit TrueType.
<klange>
SDF is a great approach... on a GPU, where it allows for all the fast arbitrary scaling and can be banged out in a pixel shader.
<doug16k>
yeah
<doug16k>
I never even went that fancy. most gpu text has been debug stuff and console
<doug16k>
fixed size
<doug16k>
cool though that there is an algorithm to scale bitmap data nicely
<doug16k>
bitmap-of-geometry data
<klange>
What's really cool is the actual rendering pass is about as simple as a regular bitmap, which is why I was able to get a library together for it really quickly and make it compact.
<klange>
Oh, wow, I didn't really look at it before but it seems my silly little rotated sprite renderer is a lot faster in x86-64... gcc probably compiling it to something way slicker.
<doug16k>
yeah x86_64 autovectorizer is pretty good
<doug16k>
if you want to crank that up, add -ftree-vectorize
<doug16k>
O3 adds it automatically
<doug16k>
it will go nuts on all float stuff
<doug16k>
and vectorize integer stuff
<doug16k>
if you mtune it to a reasonably modern cpu, it will assume the unaligned sse mov are awesome no penalty and will vectorize more
<doug16k>
restrict buffers allow vectorization, it guarantees no overlaps
<doug16k>
if it vectorized overlap, it would be incorrect
<moon-child>
could also check overlap, vectorize anyway if they're different enough or fall back
<doug16k>
unaligned one isn't slower anymore, since a long time
<moon-child>
like memmove~ish
<doug16k>
yeah but doubling the code size ruins the score and it decides not to expand it so much
<doug16k>
if O3 it might be that greedy
<moon-child>
yeah
ElectronApps has quit [Remote host closed the connection]
<doug16k>
you can set the parameters on how much it is allowed to do that
ElectronApps has joined #osdev
<doug16k>
I wonder if the original -mtune=i386 is there. it goes absolutely nuts inlining, assuming no cache, so might as well expand code with impunity
<doug16k>
I mean march=
<doug16k>
on O3 I mean
<moon-child>
ha
<doug16k>
it worked, that was faster :D
<doug16k>
it let the codegen really handle the register allocation without being clobbered to nothing every call
<doug16k>
8 is barely enough
<doug16k>
omitting frame pointer is awesome on i386
<doug16k>
on 486, suddenly it is hideous to go nuts inlining, because it has a 4K cache of 16 byte lines, and it runs very much faster on cache hit
<moon-child>
_4k_ cache?
<moon-child>
that's it??
<moon-child>
my
<doug16k>
that's amazing though
<doug16k>
it helped very much
<geist>
yah 386 had 0 bytes cache
<moon-child>
I mean--yeah, I'm sure it makes a world of difference, but still--wow
<doug16k>
ya, fill burst was 4 32-bit cycles, 16 byte line :D
<geist>
came out of an era when memory was generally faster than the cpu itself
<geist>
so cache would have been silly
<geist>
but by mid 80s DRAM was more and more of a thing and you'd start getting latencies to select col/rows and whatnot
<geist>
so by the time you got to 1990 or so lots of stuff had cache on it, 486 was when x86 got it. 68030 for example had iirc 256 bytes of cache
<geist>
of coruse nothing kept a system from having external cache
<doug16k>
pentium made the caching huge in comparison
<doug16k>
16 or 32k, but 64 bit data bus, so 4x8 burst = 32 byte line
<doug16k>
ddr is what makes it 64 byte line now
<doug16k>
"D"DR5 is QDR isn't it?
<doug16k>
I'm going to be so mad if it is QDR and called "DDR" 5
<geist>
i dunno i'm too busy watching some seriously filthy funk by the fearless flyers
<bslsk05>
'THE FEARLESS FLYERS /// Colonel Panic' by Vulf (00:02:37)
<doug16k>
wake me up when it's octuple data rate
<doug16k>
at 10GHz
<doug16k>
shouldn't be hard to handle sync of 64 wide bus of those :P
<doug16k>
how close together to you think we can get the bits along the wire?
vinleod is now known as vdamewood
<doug16k>
16 bits per clock edge will be fun times for memory marketing. sexdecuple data rate
<doug16k>
hahahaha, 24 is quattuorvigintuple
<doug16k>
it's a little endian word
<doug16k>
vig is 20 quat is 4
<doug16k>
I think :D
<doug16k>
almost matches french
<moon-child>
quatrevingtdixneuf
trufas has quit [Ping timeout: 255 seconds]
trufas has joined #osdev
<doug16k>
by the time we have sexdecuple data rate, it'll be cancelled out by font rendering that generates the font based on a real-time world simulator that recreates all the world history which led to the design of today's fonts
<doug16k>
you can make hitler win and see what happens to the fonts
<moon-child>
lol
<moon-child>
there is cool stuff with rendering text directly on gpu
<moon-child>
not sdfs, real curves
tacco has joined #osdev
immibis has quit [Remote host closed the connection]
archenoth has joined #osdev
Oshawott has quit [Ping timeout: 272 seconds]
tacco has quit []
scaleww has joined #osdev
GeDaMo has joined #osdev
Arthuria has joined #osdev
ElectronApps has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
sortie has joined #osdev
dormito has quit [Ping timeout: 255 seconds]
<klange>
I... do not know why I just spent a bunch of time switching out all of the compositor animation stuff in my OS to use a single transformed renderer, but, uh, it can combine animations with rotations like it was doing with cairo, so that's nice I guess
<klange>
Also lazy window resizing with the stretchy texture works with rotation again, so I guess that's kinda nice. Now if only I opened menus with the right positioning and rotation...
janemba has quit [Ping timeout: 240 seconds]
janemba has joined #osdev
* sortie
shows up for the weekly protest with a sign “Wobbly windows”
<klange>
Hm, much like Cairo my transformation matrices are affine, and that makes wobbles awkward.
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
isaacwoods has joined #osdev
wolfshappen has joined #osdev
smarton has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
smarton has joined #osdev
<sortie>
I just remembered what affine transformations actually are
<sortie>
klange, awesome video
<clever>
heh, thats something the 2d-accel on the rpi cant do!
<clever>
have to bring in the 3d core to get such effects
wolfshappen has quit [Quit: later]
wolfshappen has joined #osdev
iorem has joined #osdev
<klange>
For everyone else, affine tranformations are ones in which parallel lines remain parallel: Rotation (around arbitrary points), scaling (independently in the x and y directions), skewing, and translation are all affine.
<klange>
They're a step above linear transformations, which includes rotation around a fixed origin, and a step below perspective transformations.
<klange>
Linear transformations are meh, perspective transformations require considerably more matrix math.
<klange>
Also I went in and replaced a bunch of methods with this transformation approach, so the independent rotate and scale functions now just apply the correct matrix.
<klange>
Cuts down on duplicated code. There's still the unscaled, unrotated fast-path option as well.
<klange>
And I fixed some bad math in my old rounded rectangle renderer so now the far left and right sides are nicely blended.
<clever>
klange: what are linear transformations then?
<bslsk05>
en.wikipedia.org: Transformation matrix - Wikipedia
<clever>
klange: all i see is unreadable formulas!
<klange>
In 2-dimensional space, linear transformations are ones that can be applied with a 2×2 matrix, or represented in formulas as x' = a * x + b * y, y' = c * x + d * y with some values of a,b,c,d.
<clever>
but what are the limitations/capabilities of the transformation?
<klange>
This turns out to be rotation, scaling, shearing, and reflection... about a fixed origin point.
<clever>
ahh, so its still more powerful then the 2d system on the rpi
<clever>
the rpi 2d accel, cant do rotation or shearing
<klange>
The key thing is that with affine transformations you can do all of these things _around arbitrary and changing origins_.
<klange>
With linear transformations you need to apply them separately and then reposition everything for a new origin.
dennis95 has joined #osdev
<clever>
in its default state, the 2d accel of the rpi can only do alpha blending and xy offsets for the whole layer
<clever>
so i can give a list of images with alpha, and an xy to render each to, and they get drawn at 1:1 scale
<klange>
If all you have is translation, you don't really have any transformations :)
<clever>
the next layer that can be turned on, is x-scale and y-scale, which can shrink/stretch a given axis
<klange>
But yeah, that's about right for a bit blitter: fast alpha blitting.
<clever>
shearing would be tricky to get right, you have to change the translation on every h-sync irq
<clever>
and it could only shear on one axis
<clever>
axis flips are also trivial, it just changes from an increment to a decrement
<clever>
90 degree rotation, requires an extra stage, where it writes the image back to ram
<clever>
for anything more advanced, you have to throw in the 3d core and shaders
<clever>
when the 3d core comes into play, (even in 2d mode), you give it XY coords on the screen, and UV coords on the input texture
<clever>
it will then interpolate new UV coords, for every pixel of the poly
z_is_stimky_ has quit [Read error: Connection reset by peer]
<clever>
and then do texture lookups, and interpolate a color from a 2x2 pixel area
z_is_stimky has joined #osdev
<clever>
and that can then give you rotation and stretching of any triangular shape
<clever>
klange: at that point, do you even need the math of an affine transformations?
<klange>
When you have 3D and can map from a point to its UV on an arbitrary quad, you're beyond affine.
<clever>
yeah, thats kinda what i was thinking
<klange>
I use the affine transformations to calculate the UVs in software and then use a bilinear interpolation to get the pixel color.
<klange>
The bilinear interpolator is the slowest part, but it's that or nearest-neighbor and... oof.
<clever>
maybe bilinear interpolation is what i was thinking of when i said the 2x2 thing?
* clever
checks docs
<clever>
yeah, it is
<clever>
the texture lookup on the rpi's 3d core supports both bilinear and nearest pixel
<clever>
and even trilinear, when you have multiple LOD's
<clever>
my understanding, is that bilinear is basically just a weighted average?
<clever>
so if i ask for a pixel at say 1.0 , 1.75
<clever>
then it picks the 2x2 pixel group arround that coord, and then does a weighted avg, 1 part this, 3 parts that
<bslsk05>
en.wikipedia.org: Bilinear interpolation - Wikipedia
<klange>
It's generally the "good enough" smooth 2D scaling approach, beyond which you can sacrifice speed for visual quality.
<klange>
Bicubic is one such "visually better, but more expensive" approach.
<clever>
and i'm guessing trilinear, is just doing a 3d version of that, where one face of the cube comes from a higher res texture, and the reverse face is a lower res texture
<clever>
so it doesnt snap between qualities as you get closer
<klange>
yep
<klange>
And as you might guess, there is also tricubic.
<clever>
but i dont see any cubic ones listed on the rpi
ahalaney has joined #osdev
<clever>
though, you could probably implement them in a shader, if you cared more about quality then fps
<clever>
just use floor/ciel, and do 4/8 pixel lookups
<clever>
the v3d has 2 magnification filters, bilinear and nearest pixel
<clever>
and 6 minification filters, bilinear LOD0, nearest LOD0, nearest LOD, bilinear from the nearest pixel in 2 near LOD's, full billinear fom a single nearest LOD, and trilinear from the 2 nearest LOD's
<klange>
When you have every pixel running on, effectively, its own core dedicated to the task... things get a lot easier.
<clever>
the v3d cheats a bit there
<clever>
i think each core is a 16 wide vector unit
<clever>
but the docs and api treat it like 16 independant cores, for the most part
<clever>
and the hw will then schedule 16 pixels on the same core, with the same shader
<clever>
the difference only comes into play when you add conditionals, which have an extra "any lane" or "all lanes" part of the condition
<graphitemaster>
There's techniques to do bilinear filtering much cheaper than your usual weighted average
<clever>
graphitemaster: i'm fuzzy on exactly how its implemented, because its fully hw accelerated on the v3d
<clever>
you just pick a mode and give it a floating point UV, and it spits back a 32bit RGBA answer
<graphitemaster>
For starters, it's unnecessary to convert to floating point to do your weighted average, you can actually do bilinear interpolation completely on your rgba8 data
<graphitemaster>
It's actually quite easy.
<graphitemaster>
Most hardware interpolation is just some shifts and adds.
<graphitemaster>
But made fast in the hardware
<graphitemaster>
With baked kernel / microcode.
<clever>
and its hard to RE this part, because it involves a ram read (with caching)
janemba has quit [Read error: Connection reset by peer]
janemba has joined #osdev
<graphitemaster>
GPUs don't actually store data in the format you use on computers, they use a block-linear texture format that is morton-order encoded because then interpolation of neighboring samples no longer is four separate (in the case of bilinear) reads from different places
<graphitemaster>
They're a single read of four samples all next to each other contiguously stored.
<clever>
graphitemaster: the v3d texture format uses a weird zig-zagging pattern, one sec
<graphitemaster>
Yeah that's a z-order curve encoding (morton usually)
<graphitemaster>
Every GPU does that, it's not that novel.
<graphitemaster>
I mean to me it isn't since I know how this works. I guess for someone new to it it may seem like a clever trick but it's pretty much like the norm in these circles.
<graphitemaster>
Yeah that's just ETC encoding actually.
<clever>
i think the main reazon for that whacky layout, is so that pixels in each direction (up/down mainly) are "nearby"
<clever>
and to improve the cache hit rate
<graphitemaster>
Exactly, it's also necessary for tiled rasterization to even work too.
<graphitemaster>
Which is important on mobile.
<graphitemaster>
Since you have such little memory.
Matt|home has joined #osdev
<graphitemaster>
Anyways if you want really quick interpolation but not nearest neighbor, what's better than a weighted average is usually just a dumb box filter which is almost indistinguishable from bilinear but much more efficient.
<clever>
vc4_txp.c: * If TFORMAT and 32-bit, limit is 1920 for 32-bit and 3840 to 16-bit
<clever>
vc4_txp.c:/* If TFORMAT is set, generates LT instead of T format. */
IRCMonkey has joined #osdev
<clever>
vc4_txp.c:# define TXP_TFORMAT BIT(5)
mcs51 has quit [Quit: WeeChat 3.0]
<clever>
ok, this is something new to me....
<clever>
ah, maybe this is how that worked
<clever>
graphitemaster: the 2d subsystem on the rpi, will basically just take a dumb list of bitmaps, with xscale/yscale, xoff/yoff, optional flips, and then alpha blend things together
<clever>
but it operates on a scanline basis
<graphitemaster>
Yeah it's not a real GPU. It's a hardware blitter and blender basically.
<clever>
yeah
<graphitemaster>
Real GPUs require execution pipelines for running vector and floating point kernels.
<graphitemaster>
i.e shaders.
<clever>
some sources claimed that 2d subsystem had t-format support
<clever>
but i think its only supported on the "transposer"
<clever>
the "transposer" appears to support t-format input/output, and 90 degree rotations, but must write back to ram
<clever>
so that will convert things to a linear format, for the main thing to blit out
<clever>
graphitemaster: the shaders and such, are in a seperate peripheral, which is also in its own power domain, so you can turn it off when idle
<clever>
something i should probably try next, is getting 3d working, baremetal
<sortie>
I built a local kernel with symbols, and found out where the pointer to the realtime clock is, derefenced that, and turns out.. it's still updating!
<sortie>
This VM has become totally unresponsive, not reacting to keyboard input, network, or anything, and is stuck in the idle loop. But at least the hardware timer is still firing.
<bslsk05>
'New JTMOS New Millenium Kernel/OS Multitasking Windows GUI Demo (Thanks to OSDEV.org and #c-64)' by Jari Tuominen (00:05:32)
<sortie>
kazinsal, absolutely!
<vai>
it has a silly 4 Mb memory limit because of linear addressing :) and its memory allocation sucks, because if you overwrite an area, it cant fix it up itself with memory protections
<vai>
I have now fixed it a great deal :)
<sortie>
kazinsal, although, uh, manually computing the offsets of stuff in kernel structures for debugging is, uh, annoying
<vai>
next demo will be much better
<sortie>
vai, you made this 20 years ago?
<vai>
sortie: yeah sort of when Google began
<sortie>
Oh wow :)
<vai>
Google is also 20 years old
<vai>
imagine that
<vai>
kiddies
<sortie>
I've only been osdeving for 10 years and only been a googler for 6 years
<vai>
sortie: :)
<vai>
adding locks to the OS takes time
<vai>
time consumpting task
<vai>
sortie: so, you have a private stack for each interrupt handler? or you resume using the previous thread's stack for it? :-O
<kazinsal>
sortie: oh, yeah, that's a pain. I need to eventually sit down and write some kind of system to pull apart structures in memory. In the event of a full system crash the primary CPU goes "oh no" and enters a polling I/O kernel debugger if DEVELOPMENT_BUILD is defined so as long as I can get a serial console I can debug a crashed machine more or less
<Skyz>
Vai nice OS
<sortie>
vai: My operating system is <https://sortix.org>. Each thread has a kernel stack that is used for interrupts
<bslsk05>
sortix.org: The Sortix Operating System
<vai>
sortie: if the current threads stack overruns - it will cause a page fault exception
<vai>
Skyz: I promise it ran more smoothly on VMWARE 32-bit host
<vai>
back then
<vai>
VMware workstation
<sortie>
kazinsal: I think i can just use indexof :)
<vai>
sortie: I would have my MMX166 right here besides me, if it only did not decomission, aka break, completely
<vai>
Celeron 433 MHz, Athlon 700 MHz, Athlon XP 1200 MHz, and Celeron 1600 MHz (if I recall right: a 1600 MHz one)
<vai>
Commodore 128 keyboard was full of pizza, and it fried on me fixing it, so I dumped it
<vai>
sometimes I keep rebooting this ELiteBook clone almost 5 times a day - Ubuntu 20 ! sounds familiar?
<vai>
sortie: theres a strange bug in my kernel at the moment which might suddendly crash it without no reason
<vai>
after idle time
<vai>
probably could find it on serial console debug log file
mcs51 has joined #osdev
<sortie>
vai, same. My OS crashed after 5 days of uptime as a server
<sortie>
It's frozen, but still a little bit alive, so remotely attached a qemu debugger and trying to figure out what's going on
<vai>
sortie: can you do a guard dog for it to make it automatically reboot? no?
ahalaney has quit [Remote host closed the connection]
<sortie>
vai, yep! I already did that. Today I want to fix the bug
<Skyz>
sortie, do you recommend the journey of starting a hobby os?
<bslsk05>
twitter: <sortiecat> Thread: After 6 years of #osdev experience, here are my recommendations for trying out making your own Operating System from scratch: https://pbs.twimg.com/media/DIQ30yBWsAE3k7M.jpg
<sortie>
Skyz, osdev can totally be worthwhile but it totally depends on your goals
mahmutov has quit [Ping timeout: 258 seconds]
<sortie>
Do you have a rough idea of what you would like from osdev? Learning? Experience? Profit? A nice project to get a job? Fun coding? A university project? etc.
<sortie>
I personally really enjoy the work, having full understanding of everything that's going on in an OS, difficult problems to solve now and then, learning lots of technology like networking, making my kind of system
* mjg
is digging into networking starting tomorrow
<Skyz>
Learning mostly, I wanted to get a nice job at the end
<mjg>
i have bad news for you man
<mjg>
osdev is a terrible way to land a job
<mjg>
you should probably focus on learning rust instead
<j`ey>
heh
<Skyz>
Well, somehow I wanted to reimplement an OS, but I'm just gonna do it as a hobby
<Skyz>
I'm sure webdev is better for getting a job
<j`ey>
can we not go over this again?
<Skyz>
we can
<j`ey>
we have the ame conversation every time
<j`ey>
*same
<Skyz>
I just would be satisfied getting through some tutorials eventually
<sortie>
mjg, it did work for me
<sortie>
Skyz, well, sounds like you know your motivations
<bslsk05>
wiki.osdev.org: Bare Bones - OSDev Wiki
<sortie>
Let us know if you need help?
<sortie>
And check in with us afterwards maybe?
<Skyz>
I'll do it but I'm not gonna put a timeline on it
sm2n has quit [Ping timeout: 272 seconds]
dzwdz has quit [Ping timeout: 250 seconds]
Skyz has quit [Quit: Client closed]
dzwdz has joined #osdev
<vai>
sortie: I miss the 3.5" 1.44M floppies
Skyz has joined #osdev
Burgundy has left #osdev [#osdev]
<sortie>
BOOM
<sortie>
I figured out why my OS frooze, it's a good old fashioned deadlock that happened to hit the interrupt worker thread
<sortie>
sys_ppoll: Locks the wakeup lock, and locks the poll channel (to register on it)
<kazinsal>
:toot:
<sortie>
PollChannel::Signal: Locks the channel, and locks the wakeup lock to wake up the wakeup condition variable
<sortie>
Good old fashioned cyclical dependency
<sortie>
What could happen was that a TCP packet got delivered while sys_ppoll was still registering, probably required waiting twice on the same FD actually, and then the circular locking could happen
<sortie>
geist, I actually managed to debug this over qemu vnc monitor, at least once I got kernel symbols
MarchHare has quit [Ping timeout: 255 seconds]
<sortie>
Gonna bring up my IRC network tomorrow once I have a fresh overnight volatile build
<sortie>
With the fix :)
<sortie>
I wonder what uptime I can reach now
myon98 has quit [Ping timeout: 245 seconds]
freakazoid333 has quit [Read error: Connection reset by peer]
<sortie>
I wonder if I can hack up something that tracks each of what kind of mutex each mutex is, i.e. the line it's allocated at as a proxy to aggregate multiple instances, and then keeping track for each type of mutex, whenever a mutex of that type, what mutex types the current thread has already locked
<sortie>
Then using that matrix to determine if a cyclical order has been observed
<sortie>
Naively it's a O(N²) bitmap but that's probably not a big deal at all for my kernel where N is probably small enough, and easy to do it more efficiently if that's aproblem
<heat>
are you slowly creating lockdep?
<heat>
that sounds very lockdep
Skyz has quit [Ping timeout: 246 seconds]
<sortie>
Yeah I figure there's lots of existing theory and tools for this
<sortie>
I'm sure whatever quick thing I hack up basically boils down to an existing scientific paper
MarchHare has joined #osdev
vin has left #osdev [WeeChat 2.8]
mcs51 has quit [Quit: WeeChat 3.0]
vin has joined #osdev
srjek|home has joined #osdev
cookie is now known as ckie
<vin>
Off topic: do you peek at IRC while working on a problem? or do you only visit it when you seek help or want to discuss something you aren't sure about/interesting? In smaller words, does interruptions take away your flow, if so how do you manage it?
dzwdz has quit [Ping timeout: 255 seconds]
<heat>
yes I do peek, yes they take away my flow, I don't
dzwdz has joined #osdev
<heat>
it's just time wasting really
<vin>
yea I have come to realize, I am not focusing on problems for long contigious hours like I used to.
<geist>
sometimes i essentially use irc as a way to break my thinking up and get interested in something again
<geist>
but yah it totallh breaks up the flow so i have to generally be better at stopping it