<mrvn>
clever: first rule of rec0overing a damaged FS: make a copy
<clever>
mrvn: yep, and i was operating on that copy in a read-only manner at nearly all steps
<mrvn>
clever: I like to make a snapshot (of the copy) and work on the snapshot.
<clever>
i did use qemu-img to create a qcow2 snapshot of it
<clever>
and then ran a debug build of qemu against that
<clever>
so i could modify zfs and attempt to debug the corruption
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<clever>
qemu was mainly to limit the state loss every time the kernel null-pointered
<clever>
mrvn: i also discovered that my build of memtest is faulty, for the second time
<clever>
switching to another build, stops it from hanging hard
<clever>
but now all 4 sticks pass memtest fully, even when ran for 4+ hours
<clever>
plan b, is to just remove half the ram, and keep using the system
<CompanionCube>
faulty memtest is very :(
<clever>
the last time memtest was faulty, it was reporting false positives at a fixed addr
<mrvn>
memtest rarely detects errors unless your ram is totaly screwed. sequential access without any other load is far less taxing than normal operations.
<clever>
at first i trusted it, and moved to another machine
<clever>
then it was dead there too
<clever>
then things got freaky, when a laptop from a totally different cpu generation, had the same fault....
<clever>
it shared nothing in common (other then the memtest build) and had the identical fault, lol
<clever>
mrvn: that would imply memtest is defective, and should be doing random access
<clever>
and i'm fairly certain i saw random in one of its tests
<mrvn>
clever: add a hair dryer to heat the ram and noisy magnetic fields
<heat>
sup fuckers
<clever>
mrvn: ehh, simpler to just go back to using half the ram for a week, and see if its happy or not
simpl_e has joined #osdev
<mrvn>
clever: removing and inserting the ram might remove oxidation from contacts and fix the problem :)
<clever>
mrvn: already done that a dozen times, while trying to memtest which stick was causing memtest to hang
<mrvn>
memtest hanging sounds like the problem is in the memory region memtest gets loaded into
<clever>
switching to a different memtest build entirely got rid of the hanging
<clever>
which implies the build was bad, and all of that stick swapping was a waste of time
<mrvn>
or now the bad bit is in some code that's not critical or padding.
<clever>
but the test should have covered that region
gog` has quit [Ping timeout: 252 seconds]
<clever>
which implies that there is no faults that memtest can find
<mrvn>
only if the test pattern produces the error
<mrvn>
maybe it only flips when you only read the region over and over
<clever>
except reads on dram are destructive, and it has to refresh it every time you close the row
<mrvn>
How big is memtest nowadays? Does it fit inot L3 cache?
<clever>
*looks*
<mrvn>
.oO(and does it checksum itself?)
<clever>
oh, and one problem with the last build i grabbed, its an efi binary
<clever>
and in efi mode, it cant do SMP tests at all
<geist>
if it's a very specific line that's failing memtest you can mark it out in grub or whatnot (assuming you're using linux)
<mrvn>
32bit or 64bit?
<clever>
but it still teases you by leaving them in the menu :P
smach has joined #osdev
<geist>
i have one 64k block on one of my machines marked out and it seems to be okay
<geist>
obviously i wont trust it to anything serious but it seems to be a well behaved bad stick
<clever>
geist: the efi build of memtest never found any faults, after 4+ hours of searching
<geist>
there are multiple ones now, and iirc the old memtset86 just got revived
<clever>
mrvn: all of them 1.3 to 1.4mb
<clever>
geist: i wound up on the comercial memtest site by accident, and used that one last
<geist>
and it found it?
X-Scale` has joined #osdev
<clever>
V10 is efi only, and they say to use V5 if you want non-efi support
<clever>
V10 of the comercial build found nothing
<geist>
and something did eventually?
<clever>
the legacy build of memtest that nixos ships, locks up solid
<clever>
at the same address, no matter what stick is being tested
X-Scale has quit [Ping timeout: 248 seconds]
X-Scale` is now known as X-Scale
<clever>
but i am observing effects like this: {"active":false,"audible":false,"autoDiscardable":tvue
<clever>
the 0x04 bit was set in the middle of a json true, in a 5mb blob
<geist>
TIL that on bash at least `ctrl-x *` expands the current glob
<clever>
oh, neat
<mrvn>
in zsh it's just <tab>
<geist>
yeah the function is `glob-expand-word`
<geist>
so you can find if something is bound to it with `bind -p`
<clever>
oh, that leads into something i do with a lot of games
<geist>
it had never occurred to me that there was a way to do it and then suddenly came to be that surely there is
<clever>
immediately go into the keybind setup, and read it all
<clever>
but now i can do the same to bash, lol, just `bind -p`
<geist>
heh same, i immediatley go in and find Invert-Y axis
<clever>
some games do that for you in the tutorial
<geist>
one nice feature playstation has is it saves it per account and most games auto pick that up
<mrvn>
"�": self-insert
<mrvn>
"�": self-insert
<mrvn>
"�": self-insert
<mrvn>
that's a lot of strange bindings
<clever>
geist: oh, you have a concusion, can you follow my finger
<geist>
heh
<mrvn>
looks like it reports everything not bound as self-insert
<clever>
and then it asks you if you want to invert y, and try again
<geist>
mrvn: yeah may be basically 'insert the character into the command line'
<geist>
which kinda makes sense
<mrvn>
geist: that's how I read it too
<clever>
geist: ive also seen one game, that ends the tutorial with an unbeatable mini-boss, and uses how long you last to tune the difficulty level
<geist>
so that's an obvious way to screw up someone. unbind enter key or something on bash
<mrvn>
geist: bind backspace to return :))
<geist>
haha
<clever>
rebind all the keys so it acts like dvorak
<mrvn>
clever: why would you need to rebind anything for that?
<clever>
mrvn: to mess with people
<mrvn>
no, I mean the keyboard already is dvorak
<clever>
it acts like qwerty in one window, but dvorak in another
<clever>
then it will act like an even more scrambled dvorak :P
<geist>
yeah could be a way to type dvorak on a qwerty keyboard, at least in the shell
<mrvn>
clever: bind every key to something that changes some key
<clever>
mrvn: oh, ive done that in teamspeak before, lol
<geist>
heh can you build a Enigma out of it
<clever>
it supports multiple hotkey profiles, and a hotkey can be bound to change hotkey profiles
<clever>
so you can create a kind of menu system with it
<clever>
to navigate with fewer buttons
<mrvn>
clever: no, too predictable. Make it swap every key with the one before
<clever>
but there is no audible feedback, so you need to navigate it blind
<heat>
>i immediatley go in and find Invert-Y axis
<heat>
are you sure you're a human?
<clever>
heat: moving the mouse up should turn the camera up!
<clever>
any game that doesnt do that, is just wrong
<heat>
amen
<heat>
EXCEPT on planes
<geist>
invert y for lyfe!
<geist>
shooters are just little planes
<clever>
heat: ive got a proper flight yoke :P
<mrvn>
heat: what about space ships?
<heat>
space ships are just alien planes
<geist>
do you *not* make little plane sounds when you play doom?
<geist>
i thought everyone did
<klys>
invertyuop
<mrvn>
geist: no, but everyone makes pew pew pew sounds firing lasers in space.
thinkpol has quit [Remote host closed the connection]
<geist>
of course
<heat>
do you also invert X?
<heat>
or is your mind only wired backwards on the Y axis?
<geist>
y
<geist>
it's just plane stuff. i play enough flight sims, or st least did, that it's all wired the same for me
<klys>
aoeuinvert
<geist>
if it's fps in any sort of way, then invert y
thinkpol has joined #osdev
<clever>
that reminds me of a weird story
<geist>
so that there's not a disconnect between fps and flight sims
<clever>
i had a joystick hooked up to my pc for some gaming, and when i was done it went on the floor and stayed there for weeks
<geist>
since to me fundamentally it's the same neural pathway
<clever>
one day the computer crashed in a weird way, and the joystick began jumping around
<clever>
i didnt even know it had force feedback, lol
<mrvn>
force feedback?
<clever>
mrvn: surprise force feedback, i didnt know it even had that
<mrvn>
now you have to figure out how do do it again
tacco has quit [Remote host closed the connection]
<geist>
i've never heard of anyone reversing X but i could imagine if you reversed both there could be a reasonable mental model that you're basically driving a telescope or whatnot
<geist>
ie, you push it left to look to the right, etc
<geist>
like it's a little weird, but i could see that making some sort of sense
<clever>
geist: or just hold the controller upsidedown
<geist>
oh that's true. not sure that's feasuble much with newer controllers, but in the snes era i've heard of folks doing that
<clever>
thatll invert both axis
<clever>
i meant more the telescope controller
<clever>
mine only had 4 working buttons
<mrvn>
put the stick in a vice and use the base as a food pedal.
<geist>
oh i as tinkign if you wanted to hold the controller upside down legitimately, yo umight tell the game to reverse the axis to correct it
<mrvn>
or if you have a heads up display with the image mirrored so everything is x invertged
<geist>
i guess the real question which is where it all originates from is precisley when/where did it become standard for airplane control yokes to work the way they do
<geist>
ie, pulling back raising the elevator to try to point up, etc
<clever>
there is a guy on YT that converted a 2 eye HUD, into a 1 eye HUD
<clever>
and it was a major pain in the ass
<geist>
i'm sure it's way back because i dont think there's a fundamentl reason for it, except that'st probably just how the control linkages were wired up
<mrvn>
geist: because the wires weren't crossed
<clever>
its constantly polling temp sensors on both displays, to shut off if it overheats
<clever>
because the oled dies permanently at some temp
<mrvn>
oh wait, no, they have to be crossed
<clever>
but if you unplug one display, it errors, and just turns off entirely
<clever>
but he then found, if you just short the i2c bus from both eyes together, it works perfectly fine
<geist>
yeah dunno. maybe because you get more strength out of pulling towards you and it's more common in mechanically linked airplaes to pull 'up' like that?
<geist>
though i guess that's not necessarily true, pushing away on the stick is also fairly good strength wise, i guess
<mrvn>
geist: strength is probably the reason I would say.
<bslsk05>
www.reddit.com: ELI5 - Why do airplane yokes have inverted control? : explainlikeimfive
<mrvn>
the movement of the plane also doesn't increase the push/pull on the stick so it's not feeding itself.
<geist>
well, in the aerly days, when this was getting standardized, it might very well
<geist>
as in it's mechanical linkage, so the control surfaces would definitely give you direct feedback
<clever>
mrvn: that reminds me of an episode of the expanse, when the ship engine was running so hard, the pilot couldnt lift his arm to hit the kill switch
<mrvn>
geist: you can connect the wires as an = or X. easy to reverse Y mechanical.
<\Test_User>
the feedback on the mechanical linkages will just push it back to center no matter which way you pushed it, nothing to care about how the yoke is held
<mrvn>
clever: exactly. You don't want that.
<clever>
geist: i think mrvn meant, the g forces of the plane turning, causing you to pull the controls in the reverse direction, and that oscilates out of control
<clever>
or worse, pulling in the same direction, amplifying it
<geist>
\Test_User: or at least to whatever the most neutral (ie, least amount of pressure on the control surfaces) is for that surface
<\Test_User>
yeah
<geist>
if you were in a flat spin or something it might end up slamming all over the place
<mrvn>
But it really feels natural on a plane. Think of having a little plane model at the top of the stick. When you pull it back the nose of the model airplane goes up. So does the real one.
<geist>
yeah thats the first comment in the reddit. makes sense to me
<heat>
invert X gang
<geist>
so i'm sold. anyway, long story short that's why i invert Y. i think of the mouse as being a little joystick because i used to and still do play flight sims
<geist>
and used to fly a lot of model airplanes
<mrvn>
In a helicopter you have a bar you have to pull up to change the tilt of the rotor. The more you pull it up the more the lift increases and the helicopter goes up. same thing.
<heat>
crazy idea: switch X and Y
<geist>
yah the collective. also you twist it
<mrvn>
geist: why is that inverting y? Your screen has Y inverted.
<geist>
eh?
<heat>
make the mouse/joystick Y axis control the X axis, and vice-versa
<mrvn>
geist: ask any mathematician which direction Y positive goes
<geist>
that's their problem, not mine
<\Test_User>
heat: turn the joystick sideways and go back to using it
<geist>
coordinate systems of the graphics are an implementation detail
<mrvn>
geist: implemting the math goes all screwy if you mix up left and right handed coordinate systems. All the examples will be wrong.
<clever>
ive gotten stride mixed up before, the hardware expects it in bytes, but some data structures store it in pixels
<mrvn>
clever: does RPi support a paletted or 16bit mode?
<clever>
bit 31-30: palette size. 0=1bpp. 1=2bpp. 2=4bpp. 3=8bpp
<clever>
correction, not the full range
<mrvn>
So no 16bpp plaette
<mrvn>
palette_table is fixed to 256 entries too
<clever>
yeah, 16bit is just 4444, 555, 5551, or 565, no 16bit palette
<clever>
palette size limits it to being 1/4/16/256
<clever>
bits 11-0: palette base address in context memory
<clever>
bit 26: palette order 1= Pixels are ordered left-to-right as LSB to MSB, 0 = Pixels are ordered left to right as MSB to LSB
<clever>
i think those limits, are to ensure a pixel doesnt span multiple bytes
<clever>
> Yes, context memory (for display list) is embedded SRAM. It can do one pixel per cycle for palettised formats (compared to 4 pixels per cycle for unscaled, and 2 pixels per cycle scaled).
<clever>
so, you load a description of every image into the display list sram
<clever>
each image has its own xywh and image format
<clever>
and you also load the palette itself into that display list sram
<clever>
the hardware then dynamically composes it into some internal FIFO ram, racing the (virtual) electron beam
<clever>
h-flip just inverts the draw order on the internal FIFO
<clever>
v-flip causes it to addr -= stride; rather then +=
<clever>
so you must give it the address of the last line in the image
GreaseMonkey has quit [Read error: Software caused connection abort]
Gooberpatrol66 has joined #osdev
smach has quit [Remote host closed the connection]
smach has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
smach has quit [Quit: No Ping reply in 180 seconds.]
heat has quit [Remote host closed the connection]
heat has joined #osdev
smach has joined #osdev
bslsk05 has quit [Read error: Software caused connection abort]
GreaseMonkey has joined #osdev
srjek|home has quit [Ping timeout: 248 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
[itchyjunk] has quit [Read error: Connection reset by peer]
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #osdev
xenos1984 has joined #osdev
vdamewood has joined #osdev
heat has quit [Ping timeout: 246 seconds]
<geist>
huh my ryzen 5x says it supports INVPCID but not PCID
<geist>
i guess that's feasible because you can still use the 'flush everything' feature of the instruction
<geist>
would let you invalidate all or all + global without doing any CR3 or CR4 shenanigans i guess
carbonfiber has quit [Quit: Connection closed for inactivity]
Burgundy has joined #osdev
<kazinsal>
tonight's beer: okanagan spring brewery
<kazinsal>
first up a pale ale that... is really more of an amber
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
eroux has joined #osdev
hmmmm has joined #osdev
bgs has joined #osdev
bgs has quit [Remote host closed the connection]
smach has quit []
scoobydoo has quit [Read error: Connection reset by peer]
netbsduser` has quit [Remote host closed the connection]
netbsduser` has joined #osdev
scoobydoo has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
nyah has joined #osdev
gildasio1 has quit [Remote host closed the connection]
gildasio1 has joined #osdev
scoobydoob has joined #osdev
scoobydoo has quit [Ping timeout: 252 seconds]
scoobydoob is now known as scoobydoo
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
GeDaMo has joined #osdev
wand has quit [Ping timeout: 255 seconds]
wand has joined #osdev
lkurusa has joined #osdev
mrvn has joined #osdev
nyah has quit [Ping timeout: 252 seconds]
zaquest has quit [Remote host closed the connection]
smach has joined #osdev
nyah has joined #osdev
Burgundy has quit [Ping timeout: 246 seconds]
lkurusa has quit [Ping timeout: 252 seconds]
zaquest has joined #osdev
Ali_A has joined #osdev
smach has quit [Read error: Connection reset by peer]
IRChatter8 has joined #osdev
Piraty_ has joined #osdev
IRChatter has quit [Quit: Ping timeout (120 seconds)]
IRChatter8 is now known as IRChatter
dude12312414 has joined #osdev
yuiyukihira has quit [*.net *.split]
kof123 has quit [*.net *.split]
ThinkT510 has quit [*.net *.split]
knusbaum has quit [*.net *.split]
wgrant has quit [*.net *.split]
fluix has quit [*.net *.split]
graphitemaster has quit [*.net *.split]
raggi has quit [*.net *.split]
alexander has quit [*.net *.split]
hl has quit [*.net *.split]
Piraty has quit [*.net *.split]
hl has joined #osdev
srjek|home has joined #osdev
netbsduser` has quit [Quit: Leaving]
kof123 has joined #osdev
wgrant has joined #osdev
knusbaum has joined #osdev
yuiyukihira has joined #osdev
alexander has joined #osdev
graphitemaster has joined #osdev
raggi has joined #osdev
fluix has joined #osdev
ThinkT510 has joined #osdev
zaquest has quit [Ping timeout: 252 seconds]
netbsduser has joined #osdev
zaquest has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
weinholt has quit [Ping timeout: 248 seconds]
wand has quit [Ping timeout: 255 seconds]
gildasio1 has quit [Ping timeout: 255 seconds]
wand has joined #osdev
gildasio1 has joined #osdev
Compy has joined #osdev
catern has quit [Ping timeout: 255 seconds]
eau has quit [Ping timeout: 248 seconds]
mrvn has quit [Ping timeout: 268 seconds]
heat has joined #osdev
wand has quit [Remote host closed the connection]
wand has joined #osdev
orthoplex64 has quit [Ping timeout: 240 seconds]
wand_ has joined #osdev
wand has quit [Ping timeout: 255 seconds]
Jari-- has quit [Remote host closed the connection]
bgs has joined #osdev
orthoplex64 has joined #osdev
Ali_A has quit [Quit: Client closed]
bslsk05 has joined #osdev
wootehfoot has joined #osdev
weinholt has joined #osdev
romzx has quit [Read error: Connection reset by peer]
xenos1984 has quit [Ping timeout: 246 seconds]
dude12312414 has joined #osdev
xenos1984 has joined #osdev
romzx has joined #osdev
<heat>
on x86 shl + shr: "[...] all other IA-32 processors (starting with the Intel 286 processor) do mask the shift count to 5 bits, resulting in a maximum count of 31."
<heat>
shl %eax, $32 -> shl %rax, $0
<heat>
erm, shl %eax, $0
<heat>
i probably got the opcode argument ordering wrong, don't care
<zid>
which is fine cus C says >32 shifts are UB anyway so how could you possibly find out that information
gog has joined #osdev
<zid>
It's so coold today wtf heat
<gog>
heat broke
<zid>
*prime95*
<zid>
CPU barely getting warm shit, forgot I undervolted it
<heat>
new cpus should also follow C UB
<heat>
null deref? blows up
<GeDaMo>
Is your CPU also your heater? :P
<heat>
its a xeon so definitely
<zid>
it used to be
<zid>
then I undervolted it
<heat>
now it's a shitty i3
<zid>
oh apparently it's still using 180W, just took a while for the cooler to heat p