<karenw>
From what I see in the qemu debug monitor, the ioapic looks configured, other than everything being masked. I guess the authority here is the ACPI table.
<zid`>
well if it's masked it's not going to deliver anything to your lapic, is my point
<zid`>
I assume it all starts masked so that you don't get double interrupts from everything before disabling the PIC
<karenw>
Yeah, limine would have configured it for e.g. keyboard input on the boot screen, then masked it all back off. If I was writing a bootloader this would be even harder I assume.
<zid`>
bios does all of this, and provides a record in thsoe MPT tables or whatever they're called
<gog>
MADT
<heat>
or the MP tables
<heat>
but yes MADT GOATED
<karenw>
Ah okay, so a lot of this I don't have to care about if it's guarenteed to be done by firmware.
<heat>
MADT GOTD
<gog>
a tricked out firmware table that's goated with the sauce
<karenw>
I just unmask them (and probabally route them somewhere other than all to vector 0)
<zid`>
sounds like a plan
<karenw>
And hopefully crash with an unhandled interrupt when I press any key. That's my short-term goal.
<karenw>
Should go "PANIC: Unhandled Interrupt 0x12" then halt and catch fire.
<karenw>
Or w.e. vector
<heat>
ok i don't know why you need the MADT
<heat>
why do you need the MADT?
<karenw>
I don't, I think
<heat>
you do need it for a variety of things
<zid`>
weirder the system the more you need it, but I don't think the base case needs it?
<karenw>
Okay, I don't need it *now*, I will need it late I'm sure
Gooberpatrol66 has quit [Quit: Konversation terminated!]
Gooberpatrol66 has joined #osdev
<heat>
you definitely need it to 1) do basic int routing 2) find all of the APICs/IOAPICs/x2APICs/whatever
<heat>
and there's a 3) but i forgot
<heat>
forgor actually
<heat>
oh 3) match IO APICs to GSI numbers
<heat>
1) also tells you the interrupt polarity of a bunch of them, which you really can't guess beforehand
<karenw>
But in my case, limine did that for me I think?
<heat>
i would highly recommend you dont trust what the bootloader did, ever
<heat>
bootloader writers never know what they're doing, firmware writers also never know what they're doing
<heat>
ACPI tables are _regularly incorrect_
<heat>
GRUB is _regularly buggy_
<heat>
you can't trust dankmemer69 to work on limine
<karenw>
I mean, if limine is wrong, I just ping the dev on discord. But yes.
<zid`>
smh domming your interrupts
<zid`>
some of us are M, heat
<heat>
what
netbsduser has quit [Ping timeout: 272 seconds]
raphaelsc has quit [Remote host closed the connection]
gog has quit [Quit: byee]
Burgundy has quit [Ping timeout: 265 seconds]
heat has quit [Ping timeout: 248 seconds]
Fingel has quit [Ping timeout: 252 seconds]
k_hachig has quit [Ping timeout: 272 seconds]
k_hachig_ has joined #osdev
karenw has quit [Ping timeout: 252 seconds]
imyxh has joined #osdev
<imyxh>
please do point me in the right direction if this is the wrong place, but i'm trying to debug a usb hdd enclosure i have and i'm noticing that it starts "usb disconnect"ing in dmesg. i opened wireshark and it seems everything goes fine (USB URB_BULK in and out) until at some point linux starts spamming GET_STATUS and SET_FEATURE requests on the USBHUB protocol, after which at some point the
<imyxh>
enclosure responds with URB_INTERRUPT with the -ENOENT URB_STATUS. what's going on here?
Gooberpatrol66 has quit [Ping timeout: 246 seconds]
<imyxh>
i'm mostly suspicious that this isn't actually a hw failure because it looks like reading and writing works fine until at some point linux decides to talk over USBHUB, after which it disconnects. so i'm wondering if this is some firmware issue or something of the like. one time i fixed an oscilloscope by reducing the size of the SCSI packets the kernel was sending, so i'm wondering if there's
<imyxh>
something similar i can do here
<zid`>
or maybe a higher level got upset and it bubbled 'down' the stack?
<zid`>
I guess that'd be in dmesg also though, hrmph
<zid`>
like, if it were a bad scsi command and then linux trying to reset the device or something
<zid`>
I don't know enough about usb mass storage to look at your pcap, so all I can do is guess
<imyxh>
yeah the first thing in dmesg is always usb disconnect, and then sd starts freaking out
Fingel has joined #osdev
Fingel has quit [Remote host closed the connection]
Fingel has joined #osdev
eluks has quit [Remote host closed the connection]
eluks has joined #osdev
k_hachig_ has quit [Quit: WeeChat 4.4.2]
vursc has joined #osdev
vursc has quit [Ping timeout: 265 seconds]
vursc has joined #osdev
vampiredamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Renfield has quit [Ping timeout: 248 seconds]
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpa1 has joined #osdev
Dead_Bush_Sanpa1 has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
goliath has joined #osdev
Arthuria has quit [Ping timeout: 252 seconds]
youcai has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
Fingel has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
gorgonical has quit [Ping timeout: 265 seconds]
kfv has joined #osdev
kfv has quit [Ping timeout: 272 seconds]
kfv has joined #osdev
kfv has quit [Read error: Connection reset by peer]
Brnocrist has quit [Ping timeout: 252 seconds]
<SystemPrompt>
nikolar: of course you can write an IOCTL_ENABLE_PINEPHONE_MODEM_AUDIO_TO_BLUETOOTH_CHIP but that's kind of like the power management stuff in the talk. It's not *really* integrated right. It *should* be done by grabbing a handle for the modem audio output and the Bluetooth audio input and telling the OS to join them together, which would also work for all possible combinations of audio streams, converting/copying data on the CPU if necessary and
<SystemPrompt>
bypassing it if possible
<SystemPrompt>
Ermine: it's a fully separate processor code intended to handle power management tasks. Pinephone Linux uses it for exactly that, by uploading some open source firmware someone wrote. It runs even when the main system is in standby, so you'd think it would be useful to run small amounts of application code there, e.g. keep TCP connections alive. But our programming model doesn't support that sort of thing generally.
<SystemPrompt>
imyxh: spinning disk? no separate power supply? It's liable to fail if the USB port can't supply enough power. Didn't look at the packet capture but the symptom is like the request timed out because the device didn't process it at all.
<imyxh>
SystemPrompt: spinning disk with external power supply. tried a second power supply too
spareproject has joined #osdev
<kof673>
eh, conway's law. just have to mandate all kernel devs must use pinephones :D
scaleww has joined #osdev
vursc has quit [Ping timeout: 272 seconds]
netbsduser has joined #osdev
Left_Turn has joined #osdev
Lucretia has quit [Quit: Konversation terminated!]
<zid`>
This game plans to unlock in approximately 1 hour
Lucretia has joined #osdev
Lucretia has quit [Client Quit]
Lucretia has joined #osdev
GeDaMo has joined #osdev
<SystemPrompt>
kof673: it's kind of against the linux design in general and in fact the design of all OSes, which is what the talk was getting at: the OS doesn't control the computer, and is confined to one corner of the computer - granted, the corner where most of the processing power is
<SystemPrompt>
but not the corner where most of the hardware capabilities are
spareproject has left #osdev [#osdev]
<SystemPrompt>
it isn't a system for operating a phone, it's just a system for scheduling the most powerful CPU cores and the biggest memory bank in a phone
<nikolar>
eh?
<zid`>
I wonder where the OS would 'live'
<SystemPrompt>
that job does need to be done, but we ignore whatever's possible in the rest of the hardware. Keeping TCP connections alive without waking up the main cores was the first thing I thought of.
<zid`>
if not the cpu
<nikolar>
that's the weirdest take on OSs i've heard in a while
<bslsk05>
'USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware' by USENIX (01:06:19)
<nikolar>
It's on my watchlist, don't worry
<zid`>
I'm also on a watchlist.
<nikolar>
But also, yeah, operating systems control computers on behalf of the userspace
<nikolar>
That's literally the whole purpose
<zid`>
infact, kernel is ran *from* userspace
<zid`>
not the other way around
<zid`>
It's just a blob of code that comes along with each process that the process can only jmp to if certain conditions are met
Burgundy has joined #osdev
<SystemPrompt>
nikolar: no they don't, that was the point of the keynote. "Operating systems" control a tiny fraction, a little corner of your computer. It's the corner that contains most of the processing power and most of the memory, though.
<SystemPrompt>
But not most of the hardware.
<zid`>
how do they not 'control the hardware'? And who does?
<SystemPrompt>
an example the speaker raised was power management. Linux isn't really in control of power management. It
<nikolar>
Well I don't know what the point of the keynote is but I'm pretty sure you're misinterpreting it
<SystemPrompt>
It sends messages to a different OS running on a different core, most of the time.
<nikolar>
It is, Linux can wake up your computer
<nikolar>
Or put it to sleep
<nikolar>
Etc
<SystemPrompt>
by telling the system management controller to put the computer to sleep
<nikolar>
Yes, that's what control is
<zid`>
Even if it's OSs all the way down, you're still calling it an OS, so you're still admitting an OS is the one controlling the hw, no matter how many 'hops' away it is (and it's only designed this way for power-saving)
<SystemPrompt>
the system management controller is constantly running some algorithm to control your processor clock speed, and the clock control options available to linux are very limited because they are just one input to the SMC OS's control algorithms
<nikolar>
And Linux can control all of that (mostly)
<SystemPrompt>
zid`: well in the talk he does say something like (paraphrased) "what is the OS? the OS is not Linux. Linux is a component of the OS but the real OS is all this (draws a big circle) and nobody designed it"
<zid`>
okay so he's just hand waing
<zid`>
waving
<SystemPrompt>
(draws a bunch of circles on an actual architectural diagram)
<nikolar>
I'm sure he had a point, and you missed it
<SystemPrompt>
go watch it and i'll see you in a nhour
<SystemPrompt>
well, don't have to watch. can just listen.
<nikolar>
Lol right
<SystemPrompt>
like most conference talks there's not a huge amount on the screen. some diagrams you might want to see at some points.
<nikolar>
Yes I'm aware, I've seen talks
<zid`>
I looked at some of those diagrams
<SystemPrompt>
why are programmers afraid of computers btw
<zid`>
see all those lines connecting all those other bits to the circled box? Yea.
<Ermine>
nikolar: seems like it's old and weird take about that oses should treat other programmable devices as equal to the cpu or something like that
<nikolar>
Ermine: yeah sounds like it
<zid`>
and all those other cpus are just completely ignored in this diagram too
<nikolar>
Too bad that's not how any of it works lol
<zid`>
I spotted at least 2 others
<Ermine>
nikolar: Academia innit
<nikolar>
Indeed
<zid`>
He's a CS professor apparently
<nikolar>
Guess it checks out them
<nikolar>
*then
<zid`>
research OS academic
<SystemPrompt>
zid`: this is literally lifted out of the data sheet of some SoC
<nikolar>
Yeah, and you control the whole soc
<nikolar>
What's your point
<zid`>
and then he's drawn a circle on it
<zid`>
and claimed only the red bit is what linux "controls"
<zid`>
which is patently false
<zid`>
by any metric
<SystemPrompt>
Ermine: not equal but like, not completely ignored and treated as black boxes, either
<SystemPrompt>
zid`: which of the other programmable parts of the computer run code that is part of the "operating system"?
<zid`>
I could make the same diagram inside an actual cpu, for lols, and make his red circle even smaller :p
<nikolar>
I mean if you ignore all of the rest of the soc, you don't have a functioning computer
<Ermine>
SystemPrompt: if linux sends something to that devices, than it's not ignored in the first place
<zid`>
SystemPrompt: Why would it need to 'run my code' to be under my control? 99.99% of my devices are 'dumb' and just react to mmio writes to change state, in silicon
<zid`>
but if only *linux* is allowed to do those mmio writes
<zid`>
whose control is it under, if not mine?
<Ermine>
If an OS ignores some piece of hardware, it just doesn't have a driver for it
<SystemPrompt>
zid`: well the example I thought of was keeping TCP connections alive while the system is in standby (on a battery-constrained mobile system). There are processors that are alive during standby, why not transfer this responsibility to them?
<nikolar>
But zid`, you don't control how the state changes in sillicon
<nikolar>
Therefore you don't control it at all
<nikolar>
Or something
<zid`>
SystemPrompt: You want.. linux to ship firmware for the tcp phy?
<zid`>
that's what you're suggesting, ultimately
<SystemPrompt>
zid`: which devices are those? hard drives, for example, do not respond to state changes in silicon. They have processors on them. They're also swappable parts, so you probably want it to remain this way, but still.
<zid`>
There's a chip doing tcp offload, but linux has to "control" it, by installing its own code 'into' it
<zid`>
(rather than sending it mmio writes)
<zid`>
SystemPrompt: who is 'controlling the hard drive' if not linux?
<SystemPrompt>
zid`: just inside the SoC. There's a controller that remains on during standby and has access to the NIC. Why can't it do that?
<SystemPrompt>
zid`: obviously the hard drive controller controls the hard drive
<kof673>
SystemPrompt, i don't disagree, just in the long run.....one either can target a specific hardware, or forced to lowest common denominator somewhat. i wouldn't say impossible to bridge the gap necessarily, but....e.g. a phone distro or kernel may specifically do better
<nikolar>
Because it would defeat the point of standby
<zid`>
see that's where like, basically everybody disagrees.
<nikolar>
Even that controller which is "active" in standby is doing a halt loop 99% of the time
<SystemPrompt>
kof673: indeed. This modular design is a good idea for modular general-purpose computers. I was looking at a PinePhone though, which is a fixed hardware platform. I notice that all versions of Linux for PinePhone upload a certain open source firmware to the power management controller, then treat power management as something Linux doesn't have much control over - despite the fact it can upload any code it wants.
<SystemPrompt>
Because that's the design of Linux.
<zid`>
Because
<zid`>
firmware needs compiling
<SystemPrompt>
The power management controller, from a Linux view, is a device that supports very few requests: sleep, wake, turn off, etc, not a general-purpose low-power processor, even though in reality it IS a general-purpose low-power processor that can do a lot more.
<Ermine>
Anyway, please write a proof of concept OS
<zid`>
if linux wants to change the firmware instead of message passing the firmware, in order to get work done
<zid`>
it'd have to recompile the firmware constantly
<SystemPrompt>
zid`: the same could be said about the main CPU cores
<zid`>
what
<SystemPrompt>
user space code can't run on the main CPU because user apps need recompiling!
<zid`>
what
<Ermine>
until then, it's either metaphysics or outright trolling
<SystemPrompt>
if linux wants to compile user apps to run on ARM64 instead of message passing to them, in order to get work done...
<zid`>
linux compiles nothing
<SystemPrompt>
i'm counter-trolling your troll argument
<zid`>
linux *does* message pass user applications
<zid`>
and *does not* compile them
<SystemPrompt>
why do you suppose that an app that wanted to run something on the power management controller wouldn't have pre-compiled that code
<zid`>
The same as the program it runs on the other chip.
<zid`>
It's identical.
Burgundy has quit [Ping timeout: 252 seconds]
<SystemPrompt>
why do you suppose linux would have the task of compiling it
<zid`>
physics?
<zid`>
There are these little wires that come out of the controller
<SystemPrompt>
do physics give linux the task of compiling code that runs on the main CPU core?
<zid`>
and the way you interact with the controller is via these little wires
<SystemPrompt>
if not: then why wwoudl physics give linux the task of compiling code that runs on the auxiliary CPU core?
<zid`>
If only anybody had said that
<SystemPrompt>
the main core also has wires coming out of it, you know
<zid`>
then you might be making sense
<zid`>
amazing, maybe those wires could be connected?
<zid`>
Then we'd have some kind of SYSTEM of chips
<nikolar>
This must be trolling right
<zid`>
either that or brain damage
<SystemPrompt>
yes, maybe there is some kind of connection between the main CPU core and the power management controller, which can be used to transfer code to it to run while the system is in standby
<zid`>
yes, it was literally the thing
<zid`>
you told us it did
<SystemPrompt>
maybe linux is unable to take full advantage of this capability
<zid`>
You then complained that it only did it once
<zid`>
so I explained why doing it twice would be fucking retarded
<SystemPrompt>
if I could only transfer code one time to the main core, that would be pretty retarded
<SystemPrompt>
if I could only transfer code one time to the auxiliary core, that would also be pretty retarded, but that is in fact the case, making it retarded
xenos1984 has quit [Read error: Connection reset by peer]
<SystemPrompt>
no, linux does not stop anyone loading more code on the main core
<zid`>
It *does not change at runtime*
<SystemPrompt>
there is this thing called user space where you can load more code. and also kernel modules.
<zid`>
yes, yes there is, now relate it to power management, please
<zid`>
Why would my power management chip need user-code running on it
<zid`>
I'm dying to hear it
<SystemPrompt>
to keep my IRC connection alive without draining the battery
<nikolar>
It would drain the battery though
<zid`>
that would not help and does not work that way
<nikolar>
Because it's doing things
<SystemPrompt>
not as much as keeping the whole system alive
<nikolar>
Instead of not doing things which it usually does
<zid`>
Power management chip is a *secure* environment for *changing voltages*
<SystemPrompt>
just write received messages into a memory buffer, respond with TCP acks,and respond to IRC PINGs. When the memory buffer is half full, wake up the main core to process it.
<SystemPrompt>
zid`: on the pinephone it's subordinate to the application processor cores
<zid`>
If you run user code on it, either you cook the chip accidentally, or someone cooks your chip on purpose, that's 100% of the exposed functionality for adding user code to it.
<zid`>
same for the hard drive, or any other device
<zid`>
Things are opaque and handled 'off-site' for a reason
<zid`>
Because it makes things both functional, and safe
<nikolar>
SystemPrompt: alright, what is my irc runs over a vpn
<nikolar>
How much processing power are you willing to burn
<SystemPrompt>
notice that I am talking about the power management *CPU core*, not the fixed-function power management chip, which for example handles battery charging while the device is fully off.
<zid`>
you said linux already controls that one
<zid`>
your ethos was that linux should control more
<zid`>
(and then pivoted to saying user-space should be ran on system devices)
<SystemPrompt>
there is nothing restricting this core to doing only power management. certain power management functions must be performed there, however, so a little firmware is used that bridges them to the main CPU.
<SystemPrompt>
what is a system device?
<zid`>
devices that make up the system
<SystemPrompt>
so like a CPU?
<zid`>
I have a question about your last question
<SystemPrompt>
is a CPU a device that makes up the system?
<zid`>
May I ask it?
<SystemPrompt>
nikolar: what do you mean, how much processing power am "I" "willing" to "burn"?
<SystemPrompt>
you just did ask your question
<zid`>
oh 100% trolling, bye
<zid`>
That was an easy test in the end, I expected him to be more wiley
<geist>
hmm?
<SystemPrompt>
nikolar: if you want to remain connected to IRC through a VPN, obviously VPN code, TCP code, and IRC code must run. Obviously that uses more battery than running only TCP code and IRC code. I don't see how that is any of my business.
<SystemPrompt>
are you suggesting there might be so much stuff to do that it might not fit in the low power standby processor? Then I suppose there will have to be a fallback path where the main processor does wake up to process packets.
<Ermine>
Again, show the code
<SystemPrompt>
geist: he's annoyed that I like this keynote about how operating systems should expand to cover more hardware, rather than just the main core complex and pretending the rest is a black box with black box firmware
<SystemPrompt>
(or she or they)
<geist>
well, there's what is maybe nice, and there's reality that's largely controlled by SoC vendors that like to keep stuff private
<geist>
but it's still potentially a nice idea, not discounting that (though i dunno what keynote you're talking about specifically)
<Ermine>
everyone is okay with whatever you like or dislike
<Ermine>
Everyone is arguing that this keynote's takes are inconsistent with how hardware works
<geist>
i can tell you as someone that works with socs like this it's a mess. usually a large pile of vendor specific stuff on the secondary control processors
<geist>
if you get source even working for a large company that's a bonus
<SystemPrompt>
and no one is saying it's not hard, just that it's the right direction
<geist>
thanks, i'll have to take alook tomorros since it's very late here
<SystemPrompt>
bslsk05 must be dead. 'USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware' by USENIX (01:06:19)
<SystemPrompt>
the only soc i looked at very much was the one in the pinephone, which i believe they chose because it's not locked down - linux has full access to all the secondary processors and "secure areas"
<SystemPrompt>
it has a half-broken alpha version of a risc-v which is intended to run power management firmware but has some connection to the main memory bus, so (possibly, in theory) it could run some lightweight keepalive stuff while the main core complex is in standby, allowing it to be in standby much more often and improving battery life
<SystemPrompt>
neither i, nor anyone i know of, has time to actually pursue that - it's just theory talk
xenos1984 has joined #osdev
<SystemPrompt>
Ermine: in what way is a talk about how OSes should be more consistent with hardware, inconsistent with hardware? is your "how hardware works" the ccNUMA model that he specifically calls out? (which is a pretty reasonable model to program servers btw, just not phones)
<SystemPrompt>
even though he calls out that servers aren't truly that simple either, i think it's reasonable to program servers that way since the focus on servers is on the compute, memory and I/O and those are a much larger fraction of the machine. On a phone you really have to do whole-system thinking to have a good battery life, which should be priority #2 (after making it work).
<Ermine>
in what way? zid`, nikolar and me have tried to answer this question, please see the logs.
Brnocrist has joined #osdev
<SystemPrompt>
you have tried to say that not all the hardware should be under the direct control of the OS. You haven't tried to say that hardware doesn't actually work that way.
<nikolar>
hardware doesn't actually work that way
<nikolar>
there
<SystemPrompt>
how not?
<SystemPrompt>
the architectural block diagram quoted earlier, what's wrong with it?
X-Scale has quit [Ping timeout: 256 seconds]
<nikolar>
the diagram is fine
<SystemPrompt>
so how does hardware actually work?
raphaelsc has joined #osdev
Arthuria has joined #osdev
<SystemPrompt>
nikolar: ^
Burgundy has joined #osdev
<nikolar>
The os tells hardware what to do
<SystemPrompt>
The question wasn't what Linux does. The question was how hardware works. I'm holding you accountable to this question now.
<SystemPrompt>
In fact, the question had nothing to do with OSes at all. How does hardware work?
<nikolar>
Do you have several years to cover that question
<SystemPrompt>
nikolar: It would suffice to explain how it differs from how I think hardware works.
<SystemPrompt>
You are the one who said "hardware doesn't actually work that way"
<nikolar>
> I'm holding you accountable to this question now.
<nikolar>
Excuse me?
<SystemPrompt>
You said it. You can explain what you meant by it.
bliminse has quit [Quit: leaving]
<SystemPrompt>
Or else you were full of shit.
<nikolar>
Nah I'm pretty sure that's you
<nikolar>
Anyway, go study computer architecture and come back once you're done
<SystemPrompt>
Any particular subset of computer architecture you think I should study to understand why hardware doesn't work like that? Give me some more specific pointers. And not in hex form.
<SystemPrompt>
okay, you are full of shit
Turn_Left has joined #osdev
<nikolar>
no, pretty sure that's you
Left_Turn has quit [Ping timeout: 264 seconds]
gorgonical has joined #osdev
<gorgonical>
I have a library, lib.a that has -ffunction-sections. The ldscript does .text : { *(.text.*) } : text to push them all into the same section. I /think/ this is interfering with gc somehow. Because all the symbols in the .text.._FOO_BAR_BAZ sections that are generated are getting collapsed. Does this sound correct?
<gorgonical>
If that were the case though why would we need a KEEP section?
<gorgonical>
s/section/command
bliminse has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 252 seconds]
kfv has joined #osdev
gorgonical has quit [Ping timeout: 264 seconds]
edr has joined #osdev
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
hwpplayer1 has joined #osdev
kfv has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kfv has joined #osdev
ptrc has quit [Ping timeout: 265 seconds]
SophiaNya has quit [Ping timeout: 265 seconds]
CompanionCube has quit [Remote host closed the connection]
nadja has quit [Read error: Connection reset by peer]
SophiaNya has joined #osdev
ptrc has joined #osdev
nadja has joined #osdev
CompanionCube has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
Matt|home has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 248 seconds]
goliath has quit [Quit: SIGSEGV]
craigo has joined #osdev
heat has joined #osdev
<heat>
nikolar, what the fuck was up with that guy
<heat>
jesus
<nikolar>
heat: i have no clue mate
kfv_ has joined #osdev
kfv has quit [Ping timeout: 245 seconds]
<Ermine>
It was HEATed discussion
<nikolar>
LEL
<heat>
no it was an ERMINEd discussion
<heat>
did this work
<nikolar>
it worked less than Ermine's joke
Gooberpatrol_66 has quit [Quit: Konversation terminated!]
Gooberpatrol_66 has joined #osdev
kfv_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
craigo has quit [Quit: Leaving]
kfv has joined #osdev
<Ermine>
heat: how much kernel is fucked up if some module triggers general protection exception
nur has joined #osdev
<heat>
which kernel
<Ermine>
linux
<heat>
in general the answer is "depends" but probably not much
<heat>
i would bet on dereferencing an uninitialized pointer
<heat>
with KASAN null pointer derefs can also show up as GPFs (but usually decoded in dmesg right below, by KASAN)
<Ermine>
0xdead000000000122
<heat>
iirc that's the list_head poison value
<heat>
yep, list poison value
<heat>
a list_head's ->prev is garbage
<heat>
if it's a patch you wrote i can take a quick look
<Ermine>
No, it's not a patch, it's vanilla kernel
<heat>
dump dmesg, thanks
<Ermine>
and it's bluetooth which faults
<Ermine>
I thought there's already a lot of destruction if I get GPEs
<heat>
no, a simple non-canonical address will do
<Ermine>
okay
chiselfuse has quit [Read error: Connection reset by peer]
<Ermine>
the core is that there's a usb dongle which supposedly has both wifi and bluetooth, but apparently you can't have both on usb 3 due to electromagnetic interference. But linux still tries to load btusb
goliath has joined #osdev
<heat>
the best part about GPFs is that you need a full x86 instruction decoder to find out what caused it
FreeFull has quit []
<Ermine>
don't waste your time on this one
<nikolar>
lol
<heat>
is this an OOT driver?
FreeFull has joined #osdev
<heat>
it looks (or feels) like there's a double unregister or maybe it's not even registered properly
hwpplayer1 has quit [Remote host closed the connection]
xenos1984 has quit [Ping timeout: 248 seconds]
Matt|home has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
Matt|home has joined #osdev
<the_oz>
into the mines we go
the_oz has quit [Ping timeout: 272 seconds]
gareppa has joined #osdev
_ngn has joined #osdev
_ngn has quit [Client Quit]
the_oz has joined #osdev
netbsduser has quit [Ping timeout: 265 seconds]
netbsduser has joined #osdev
xenos1984 has quit [Ping timeout: 272 seconds]
xenos1984 has joined #osdev
gog has joined #osdev
xal has quit [Quit: bye]
xal has joined #osdev
xal has quit [Client Quit]
xal has joined #osdev
Fingel has quit [Quit: Fingel]
Fingel has joined #osdev
Fingel has quit [Client Quit]
Fingel has joined #osdev
ngn has quit [Quit: disconnected]
tr_astra has quit [Ping timeout: 265 seconds]
_ngn has joined #osdev
gareppa has quit [Quit: WeeChat 4.1.1]
gog has quit [Quit: byee]
<kof673>
hmm...watched that usenix video...reminds me of a comic, where the joke is the last cpu that was fully understood and designed without using another computer to do so was in 1983 [do not recall details]...and not to tell people this, lest noone enter computer fields, and then we are all doomed
<kof673>
multiply this, or exponential even, because for this video, there is an entire system, or system of systems, not just one single cpu lol
<kof673>
i'll just say like the pike IIRC paper, he is using "system" in a holistic manner
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpai has joined #osdev
Dead_Bush_Sanpai has quit [Ping timeout: 260 seconds]
d5k has joined #osdev
d5k has quit [Quit: leaving]
Lucretia has quit [Remote host closed the connection]
Dead_Bush_Sanpai has joined #osdev
Lucretia has joined #osdev
* geist
is still pretty deep into Satisfactory
<geist>
but managed to get a decent nights sleep by making a rule of no Satisfactory after midnight