channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=19&m=5&d=26
01:57:47 <doug16k> that was weird. I saw the message about myself quitting, remote host closed the connection. actually I didn't
01:58:42 <doug16k> that's illogical enough to make one ill
02:00:31 <doug16k> why is irc so spammy with errors? TCP connections aren't that bad!
02:01:37 <Mutabah> IRC just shows the errors that show up with long-lived TCP connections on some ISPs
02:02:03 <doug16k> what are the ISPs doing that disrupt TCP so much? changing their IP crazy often?
02:02:37 <doug16k> TCP should be immune to them power cycling their entire router rack every 2 seconds
02:02:58 <doug16k> perf will go down the tubes but it would work
02:02:59 <Mutabah> Some will inject RSTs I think
02:03:14 <doug16k> wow
02:03:22 <Mutabah> The Uni I went to would do that to idle TCP connections (ones with no traffic for ~5 mins)
02:03:42 <doug16k> and TCP keepalives don't even count?
02:03:47 <elderK> Mutabah: Same here
02:03:48 <Mutabah> Not sure
02:04:11 <doug16k> it could be nasty a bit and not allow TCP keepalives
02:04:31 <doug16k> any half decent network code can handle an endless stream of problems and retries/reconnects/errors/etc
02:04:41 <elderK> My Uni would do weird stuff. Say you are downloading a lecture PDF. Say it's around 20M. You can download smaller ones, fine, around 4M. But larger ones? About three quarters of the way through, the rate would just plummet. Down to like, a couple bytes a second, less. Eventually, it'd stall.
02:04:49 <elderK> So, you'd try again. And the same thing would happen.
02:04:50 <Mutabah> I suspect it was the stateful firewall cleaning up tracked connections
02:04:54 <elderK> I'd complain and they'd never fix it
02:07:11 <elderK> Also, Happy Sunday all :)
02:13:54 <doug16k> I'm considering changing my syscall return code to be like this -> https://gist.github.com/doug65536/2930ed93d42dad2f5ab17362f704d685#file-syscall-s-L100
02:14:54 <doug16k> so I can be careless with the FPU when interrupted in kernel mode, then just guarantee wiped fpu before returning from syscall
02:16:01 <doug16k> the vzeroall gets patched with a call to soft_vzeroall that does pxor then 15 movaps if the cpu doesn't have AVX
02:16:42 <doug16k> oops! missed insn_fixup before vzeroall there
02:18:47 <doug16k> insn_fixup adds an entry to a table by emitting a pointer to that place in the code to a special section which is used to build an array of instructions that might need fixing up based on cpu capabilities/vulnerabilities
02:19:12 <doug16k> array of pointers to instructions that might need fixing
02:20:11 <doug16k> emms should wipe the x87 stack, then 8 fldz should be the fastest possible way to clear the 8 x87 register values, then emms to empty x87 stack again, interleaved with clearing SSE and clearing call clobbered registers
02:21:05 <doug16k> maybe this is the wrong place though. maybe that clearing operation should be lifted out and invoked by context switch code only when it might actually leak over the FPU to another process
02:25:43 <doug16k> oops, that code is broken, it uses gs after swapped
02:28:26 <doug16k> updated
02:31:09 <doug16k> now that I am guaranteeing so much zeroing at thread start and returning from syscalls, the registers look funny sometimes, most of the time all of the caller preserved registers are zero
02:32:29 <doug16k> at thread start, everything is zero except rip, rsp, rdi, and largely stays surprisingly close to that
02:34:11 <doug16k> once or twice I looked at registers and thought for a moment "what? did this cpu reset or someth... oh, it's just almost all zero registers and fine..."
02:40:11 <doug16k> I'm hoping that keeping the FPU cleared will maximize init optimization and minimize the cost of having FPU context switching enabled for user programs by default by making the init optimization happen as much as possible. if gcc does a smattering of avx somewhere autovectorized, it won't end up with that linkering in the AVX state with upper half powered up whole time, for nothing, sooner or later they will do a syscall and I will return with cleared AVX
02:40:11 <doug16k> and upper half will power down and context size will be minimized
02:41:51 <doug16k> with those bazillion vector ALUs off it can probably turbo a bit harder
02:50:03 <clever> something i heard recently, is that if you dont `return 0;` from `main()`, it will leak whatever EAX is set to, as the exit code (which does make sense)
02:50:17 <clever> which can potentially be security sensitive, depending on what it happens to do last
02:59:12 <elderK> clever: C or C++?
02:59:25 <elderK> I believe they differ slightly here.
03:00:10 <clever> elderK: plain c i think
03:00:37 <clever> more, that main() needs c linkage, so glibc can call into both c and c++ progs?
03:02:44 <elderK> Not sure. I believe you can omit return WHATEVER in C++ main. In that case, it defaults to return 0.
03:03:05 <clever> ah
03:03:08 <elderK> Don't quote me though, definitely check up on that.
03:03:18 <clever> i tend to -Wall when doing c(++) and fix warnings like that
03:04:34 <elderK> See here
03:04:35 <elderK> https://en.cppreference.com/w/c/language/main_function
03:04:39 <elderK> this is for C, so I am mistaken.
03:05:04 <elderK> Explanation 3)
03:05:47 <clever> `the termination status returned to the host environment is undefined` appears to be the part i was mentioning
03:05:51 <clever> "undefined" as in, whatever eax happened to contain last
03:06:43 <doug16k> -Werror=return-type is very good
03:07:03 <doug16k> it is asinine for the language to allow a non-void function to have codepaths that don't have a return statement
03:07:25 <clever> ive been doing a lot of haskell lately, and it refuses to allow that
03:07:57 <doug16k> Werror=return-type makes it an error to fail to return something
03:08:17 <clever> yeah, similar to -Werror making all warnings errors, and -Wall just turning on all warnings
03:08:55 <clever> haskell has a shit-ton more warnings then you normally want, so -Wall doesnt even turn them all on!
03:09:03 <clever> you need -Weverything to get everything
03:09:11 <doug16k> same with C++
03:09:25 <doug16k> have you seen clang's Weverything? it is way too picky
03:09:26 <clever> ah, wasnt aware that -Weverything had even shown up in c++
03:10:20 <doug16k> oh Weverything is a "hold my beer, I can make this thing complain about everything" on clang
03:10:32 <clever> same in ghc
03:11:05 <clever> Could not specialise imported function ‘aeson-1.4.2.0:Data.Aeson.Types.FromJSON.$fFromTaggedObjectarityM1_$cparseFromTaggedObject’
03:13:02 <clever> ‘Buildkite.API’ has been inferred as unsafe!
03:46:43 <doug16k> clever, gcc guarantees return value from main -> https://godbolt.org/z/CICDZQ
03:46:52 <doug16k> I thought the standard said it has to handle missing return in main
03:48:43 <elderK> Me too.
03:48:45 <elderK> It does in C99
03:48:52 <doug16k> note 4 here: https://en.cppreference.com/w/cpp/language/main_function
03:50:33 <doug16k> still could be needed though on older toolchains or compatibility with more dumbass compilers
03:52:12 <elderK> Aye. My source was the same documentation from the C part of that site.
03:57:39 <doug16k> are the comments on the right correct here -> https://wiki.osdev.org/Exceptions#Error_code
03:57:48 <doug16k> why can't a code fetch fault without XD?
03:58:14 <doug16k> I think the I bit comment is wrong
04:20:48 <doug16k> elderK, ah sorry, I didn't see the C one that says it only is guaranteed since C99
04:20:50 <doug16k> good to know
04:22:29 <doug16k> I wonder how much shouting and arguing that caused. people mad because it is C, you should HAVE to do EVERYTHING yourself. no exceptions
04:24:17 <doug16k> ruined their compiler's chance to have a branch to a ud2 or infinite loop when you forget return
06:46:33 <adu> I just figured out how to implement inb/outb!
06:46:43 <adu> in Rust even
07:15:38 <Mutabah> Nice
07:35:20 <doug16k> very strange. if I try to look at info pic in windows 7 vm, nothing is output
07:35:38 <doug16k> info pic in qemu monitor
11:41:22 <doug16k> hey neat, the multiboot, cpu init, outputting success/fail result, and power off test harness I made for a BMI bug got adopted into a qemu test for system instructions: https://github.com/qemu/qemu/blob/e4770dd95a59584a8d077f3f57c2356791dec870/tests/tcg/i386/system/boot.S
11:41:58 <zid> cool I guess
11:44:52 <doug16k> I am very happy to see more testing in qemu
11:45:25 <doug16k> it's a miracle it still works with the low amount of tests in tcg
11:47:01 <doug16k> they made TCG multthreaded SMP with hardly any tests (considering). nearly impossible feat
11:47:24 <zid> Rip, the ram I wanted sold out
11:47:35 <zid> I blame you doug for not buying me it fast enough
11:47:55 <doug16k> I did take too long ya
11:49:48 <bcos_> zid: Can't you just import a bucket load of RAM from China?
11:50:30 <zid> I.. was trying to? :P
11:50:37 <bcos_> :-)
11:50:40 <zid> and by bucket load I meant 4
11:50:47 <zid> 4 rams
11:51:13 <bcos_> Should get some ewes too
11:51:34 <zid> bcos_: I'm afraid we're evicting you from this universe
11:51:43 <bcos_> :-)
12:15:03 <doug16k> you should get the max the motherboard supports the day you get the motherboard
12:15:31 <doug16k> maxed out desktop is about right amount of ram for good dev machine
12:16:36 <doug16k> need 4GB per SMT thread ideally
12:16:51 <doug16k> absolute minimum I mean
12:16:59 <zid> well if you had bought me that ram I'd have it
12:17:11 <zid> So basically the blame lies solely on you
12:18:57 <doug16k> that's why I have 64GB. it's enough to have 4GB per job with -j16
12:19:42 <doug16k> 32 thread CPU would need 128GB
12:20:41 <zid> Yea I only have 8T so 32GB is enough
12:20:57 <doug16k> nice
12:21:09 <zid> and I'm not sure there are many 16GB dimms in order for me to go to 16
12:23:38 <doug16k> my machine is 4 16GB dimms
12:23:47 <zid> ddr4 though?
12:23:49 <doug16k> ya
12:23:56 <doug16k> DDR4-2400 ECC
12:24:03 <zid> yea, 800MHz+ ddr3 16GB ecc sounds expensive
12:24:24 <zid> That 8GB was cheap as hell though
12:24:27 <zid> £10 a dimm
12:26:07 <doug16k> why expensive? people would be making it cheap to get rid of it before it is too late
12:26:20 <zid> old good ram retains a lot of value honestly
12:26:28 <zid> Try getting low timing ddr2
12:26:41 <zid> or some high capacity core rope :P
12:27:31 <zid> https://www.ebay.co.uk/itm/128GB-8x16GB-PC3-12800R-DDR3-1600MHz-ECC-Reg-Server-Memory-RAM-Upgrade-Kit/323734968611?hash=item4b601b9923:g:9u4AAOSwfchciRF4
12:27:33 <zid> £40 a dimm
12:28:09 <doug16k> ok, $140. that's nothing
12:28:26 <zid> 4x the price lol
12:28:34 <doug16k> my ram was almost $1k
12:28:54 <zid> Oh hey I found 64GB for £115
12:28:57 <zid> You buying me it?
12:29:26 * bcos_ wonders how much one of Intel's 512 GiB DDR4 sticks are worth
12:30:28 <doug16k> intel still making bulletproof and practically infallible motherboards?
12:31:25 <doug16k> afaik they all work until you don't want it anymore because you are replacing it with a newer one, and you take it out 100% perfect
12:31:43 <zid> I've only ever had gigabyte boards die
01:14:08 <moondeck> hai
03:02:53 <lowarago> I am planning on writing an USB driver in C that should make reprogramming firmware possible on hardware device that I will also build. The hardware device will use flash memory as storage device, which makes it possible to reprogram it. The device will have USB port which will be connected with a Windows/Mac machine and then via software update the firnware via USB. I hope I was clear what I am trying to achieve.
03:03:22 <lowarago> The question I have is: How difficult the task is and where should I start?
03:03:52 <clever> lowarago: in general, i see that kind of thing done over the USB HID protocol
03:04:02 <clever> or serial, or DFU
03:04:20 <clever> USB HID/serial are special,in that you dont need custom kernel drivers
03:04:27 <bcos_> lowarago: How many years are you going to spent re-inventing a USB flash stick you can buy for $5 at walmart?
03:04:55 <lowarago> clever: I will check the protocols you mentioned. Thanks.
03:04:58 <clever> sometimes, people even emulate usb mass-storage, and then emulate a fat32 inside that
03:05:10 <clever> and if you try to copy a .bin file over, it will flash itself
03:05:58 <lowarago> bcos_: I am not trying to reinvent USB flash stick, but instead I will work on a device that is not meant to be used as a mass storage device, instead it is something more advanced. The flash storage is only a small part that will contain the actual program.
03:07:44 <lowarago> When I make updates to a firmware, I want to be able to quickly update it on device via USB
03:09:08 <clever> i think arduino typically do it over serial, but more modern usb devices might use usb directly
03:10:05 <lowarago> Arduino does do it over Serial COM port, but I want to go with direct USB Connection.
03:10:49 <clever> you can still emulate that usb serial
03:11:16 <lowarago> clever: How?
03:11:19 <bcos_> What kind of device is it? Most USB devices don't have any ROM to begin with (just a driver for each OS for each architecture)
03:11:48 <clever> lowarago: any micro-controller doing usb, can emulate almost any usb device, including serial
03:12:16 <lowarago> bcos_: Let's say it is a remote control device that should have firmware on it and frequent updates.
03:13:11 <bcos_> lowarago: So, it's for developing rootkits for people that disable UEFI secure boot?
03:13:59 <clever> https://www.microchip.com/wwwproducts/en/ATmega32u4 http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf
03:14:25 <clever> lowarago: page 256, usb controller
03:16:43 <zid> I read the backlog very quickly, but did someone just asked how to encapsulate serial over u *s* b?
03:16:56 <clever> lowarago: https://github.com/PaulStoffregen/cores/blob/master/teensy3/usb_serial.c
03:17:08 <clever> lowarago: and here is firmware for serial over usb
03:17:10 <clever> zid: yes
03:17:19 * zid boggles
03:18:47 <aalm> cdc ftw.
03:20:21 <aalm> lowarago, there's shitloads of usb-bootloaders/flashers on ie. github
03:21:34 <lowarago> I am a newbie to this stuff. I never wrote a single driver before, but it seems that I will have to for this one. I will save all your messages and read more on them later.
03:21:58 <aalm> no, you don't necessarily need a driver.
03:23:49 <lowarago> I once worked with a .dll file that does this for me. From my C# code I could just select a specific PIN in hexadecimal value and call a function like Device.UpdateFirmware(0x7000, byte_data_arr); and if the device is connected via USB it burns a new firmware on it.
03:24:08 <aalm> i'd say your issues will be on the mcu side, so pick that one more carefully.
03:24:43 <lowarago> But, for this project, I will have to make my own .dll for Windows and another library for Mac OS
03:24:51 <bcos_> ?
03:25:11 <aalm> you can have that, or just usb msc and writing the firmware there writes over on flash..
03:25:47 <bcos_> At least 3 for windows (32-bit 80x86, 64-bit 80x86, ARM) plus another 12345 drivers for all the other operating systems on all the other systems
03:26:07 <bcos_> (including things like MIPS tablets and ...)
03:26:12 <zid> Is there a 'generic' usb device that is memory backed? Rather than serial or HID or whatever, memory bus writes.
03:26:24 <zid> for reading/dumping proms or whatever
03:27:32 <bcos_> zid: No, there can't be
03:28:08 <zid> Can't?
03:28:34 <bcos_> (no USB device has any access to memory bus - everything goes through USB controller)
03:28:38 <zid> Yes
03:28:41 <zid> that's not what I meant
03:29:01 <zid> cpu -> usb controller -> usb cable -> usb controller -> prom controller -> prom
03:29:03 <aalm> usb mass storage, then?
03:29:08 <zid> sort of yea
03:29:21 <zid> but presumably that uses ATA or some other wonky command set
03:29:31 <zid> I guess you'd just use usb mass storage in the end
03:29:47 <bcos_> It's a subset of SCSI command set, with some extensions, I think
03:29:51 <zid> way easier to pretend to be mass storage than get everybody to standardize on something byte-wise rather than sector-wise
03:31:26 <bcos_> Not sure flash can work as "byte addressable" - the overhead of wear levelling would be insane
03:32:25 <bcos_> (which makes me wonder how Intel's Optane works internally - "64-byte block size" wouldn't be fun either)
03:33:10 <zid> bcos_: Not all proms are flash
03:33:29 <zid> optane is phase change crap afaik
03:33:42 <bcos_> Optane still has wear levelling
03:33:44 <zid> give it a voltage and the crystal structure changes a bit
03:33:59 <zid> probably completely different wear levelling / sector size / layering blah blah requirements to nand
03:35:14 <lowarago> clever: Thanks for mentioning USB HID Protocol. Actually the dll I was using for this stuff, has "HID" as a part of it's name. So I will probably go with that, since I know it will work and no driver development is required.
03:35:50 <zid> "Hold left for bit 0, hold right for bit 1, press 'start' to write to the address on X square triangle and circle"
03:37:26 <aalm> heh
03:38:37 <bcos_> Input devices have outputs (e.g. keyboard LEDs)
03:39:21 <bcos_> ..although it's strange that "human interface device" is primarily limited to "input from human"
03:39:31 <zid> ..no it isn't
03:39:33 <zid> bcos stop being weird
03:39:53 <zid> You're thinking of a robot interface device
03:39:58 <bcos_> Video and audio is an interface to a human too!
03:41:04 <zid> https://xkcd.com/2150/
03:49:00 <zid> bcos_: I have a hole in my pci-e device numbers, how rude :(
03:49:53 <bcos_> Most numbers have a hole in them though - can't use the digits 4, 6, 8 or 0.
03:49:53 <zid> I have a 0, 1, 2 then a 31 function 0, 31 function 1, 31 function 2
03:50:02 <zid> how many holes does 0 have, 1 or 2?
03:50:11 <aalm> .theo
03:50:12 <glenda> Shrug.
03:50:16 <aalm> 0 - 1
03:50:23 <bcos_> 0 has an intra-hole and an extra-hole
03:50:51 <zid> What about a nadirhole and zenithhole?
03:52:48 <bcos_> zid: I'd assume device 31 isn't a PCI device but part of CPU (memory controller, quickpath link, ...)
04:05:26 <zid> ICH9M LPC interface controller, 6 port sata controller, SMbus controller
04:05:31 <zid> says pci-ids.ucw.cz
04:05:50 <zid> ISA bridge
04:05:56 <zid> sata, smbus
04:08:22 <bcos_> Built into CPU?
04:09:03 <zid> It's the northbridge
04:09:26 <zid> southbridge? one of em
04:09:31 <zid> ICH9R
04:38:32 <zid> I mean, I assume the answer is just 'scan fucking everything' but I'm surprised not to have found a post on the forum about enumerating pci-e
04:41:19 <zid> Pretty provably just can't stop after the first 0xFFFF device because of my gap
04:42:55 <zid> How many devices per bus is it, 32?
04:43:09 <zid> bus<<20 | device<<15 | function<<12 would suggest so at least
04:43:22 <bcos_> Yes
04:44:04 <zid> and my mcfg says it's bus 0 through 255 on this entry, wonder if that shouldn't be bus 0 to 0
04:44:13 <zid> there's nothing on 1-254
04:44:29 <zid> and the table doesn't have to cover the entire range, there's a lenth field
04:45:02 <zid> going to have to map another 8160 pages for no reason other than a fast and loose field in qemu's table
04:45:20 <zid> although maybe hotplug devices could appear in there? idk
04:46:53 <bcos_> cold-plug devices could also appear there
04:47:19 <zid> Right but I happen to know there aren't any there, so the fact it claims those bus numbers just means extra useless work for me, is my point
04:50:00 <bcos_> Just use the olde 0xCF8 thing to figure out if a page should/shouldn't be mapped..
04:50:51 <bcos_> (like "if( 0xCF8/0xCFC IO port says there's a device/function) { map the device/function's thingy in the whatsit }
04:51:09 <zid> I'm doing it pure mmio cus I've not done that yet so why not
06:33:45 <zid> https://cdn.discordapp.com/attachments/417023075348119556/582275111537606668/unknown.png I got distracted playing rocket league but I finally put the 5 minutes of work in
06:36:40 <zid> I just probe all 8192 entries
09:07:55 <isaacwoods> sigh, compiled the latest QEMU and they've broken the serial output
09:08:14 <isaacwoods> it's now a tiny window like the default VGA output
09:11:48 <zid> isaacwoods: sure the default just didn't change?
09:12:03 <zid> -serial blah.txt or -serial vga or whatever idk
09:14:44 <isaacwoods> not sure, I've upgraded by 2 major versions so can't be bothered to look through the changelogs
09:14:49 <isaacwoods> I mean the tab in the GUI
09:15:07 <zid> I've never used it with a gui, I always -monitor stdio
09:15:08 <isaacwoods> used to be a sensible layout that filled the whole window, now it's 25 lines
09:33:41 <adu> isaacwoods: are you talking about qemu or virt-manager
09:35:36 <isaacwoods> adu: I'm executing `qemu-system-x86_64` so i can only assume qemu
09:54:45 <elderK> Hey doug16k, your physmap construction.
09:54:57 <elderK> How did you learn that the BIOS gives you such bogus data?
09:55:13 <elderK> Did you find that on real hardware? Or did you just invent troublesome test data and made sure to deal with that?
10:30:19 <keegans> i've got a multiboot boot system set up , trying to handle keyboard interrupts & initialize the GDT , the code is here :
10:30:20 <keegans> https://godbolt.org/z/uJh74m
10:30:33 <keegans> i'd expect that the print statements is called in the keyboard handler but it's not ?
10:31:03 <keegans> any ideas ? there also some strange things where godbolt online emits an lgdt but my code emits an lgdtd or lgdtdl , with the suffix , very weird
10:31:09 <keegans> my compiler options are there as well. any help is appreciated
10:31:19 <zid> I'm having a seizure :P
10:31:40 <zid> well your vga_print is currently commented out
10:31:49 <zid> did you verify things installed correctly in qemu or something
10:34:54 <doug16k> keegans, what is line 115 doing?
10:35:05 <doug16k> you don't just slap both PIC's every time
10:35:57 <doug16k> you only touch second pic if it is irq 8 thru irq 15, and in that case you do 1st one too because they are chained off irq 2
10:36:34 <zid> doug16k: Oh, how do you ACK the APIC? If you need to anyway.
10:36:50 <doug16k> zid, write 0 to a special write-only register
10:36:56 <doug16k> LAPIC register
10:36:56 <zid> ah okay
10:37:02 <zid> mmio?
10:37:06 <zid> or a msr?
10:37:16 <doug16k> x2apic is msr, xapic is mmio
10:37:42 <doug16k> the list of registers looks almost identical, slight differences
10:37:53 <elderK> Right. Time for me to catch a bus between cities :) Checking out an apartment. I'll see you guys in nine hours :)
10:38:02 <doug16k> you can take a register and calculate the offset for msr or mmio. different scale but works
10:38:12 <doug16k> take a register number*
10:38:33 <doug16k> elderK, safe trip!
10:40:35 <doug16k> elderK, I saw the order was funny and read warnings that it is very stupid and bad sometimes - some bioses are so stupid that they have overlaps
10:41:06 <doug16k> i.e. inaccessible range overlaps free memory
10:41:40 <doug16k> I wish I didn't need all that scary code for carving up memory ranges
10:43:23 <doug16k> I'm considering considering all EFI memory lost too
10:43:45 <doug16k> it is common for garbage firmware to keep using the memory after exitbootservices
10:45:34 <doug16k> maybe if operating systems told the user more loudly about idiocy in the firmware or hardware implementation, someone at the manufacturer would care, and we wouldn't have a market full of asinine implementations
10:56:15 <keegans> zid: which interrupt is the ps/2 keyboard ? i am running this in qemu
10:56:25 <doug16k> IRQ 1
10:57:17 <keegans> ok , yeah so i am not sure why this isn't work hmm
10:57:32 <keegans> " 1005da: 0f 01 5d f6 lidtl -10(%ebp)" but seems extremely sketchy
11:00:32 <doug16k> can you show "info registers" from qemu monitor?
11:01:26 <doug16k> and show output of "x /3hx $ebp-10" please
11:02:29 <doug16k> should look like <limit> <baselow> <basehi>
11:02:48 <keegans> i just printed https://wiki.osdev.org/Inline_Assembly/Examples#Enabled.3F and it prints 0
11:03:18 <keegans> so are interrupts not even enabled ??
11:03:33 <doug16k> that only disables hardware IRQs
11:03:46 <doug16k> saying it disables "interrupts" is a huge misleading stretch
11:03:53 <doug16k> it disables external interrupts
11:03:55 <keegans> what is disabling what ?
11:04:00 <keegans> that says it just returns the status
11:04:13 <doug16k> that returns true if IRQs can interrupt execution
11:04:18 <keegans> ah
11:04:22 <doug16k> returns false if IRQ is ignored and cpu keeps going
11:04:46 <doug16k> you need to unmask IRQs to get IRQ1 to run your IRQ1 handler
11:06:28 <keegans> where would you like me to place the gdb break though
11:06:33 <keegans> for the info registers you're looking for
11:06:41 <doug16k> the lidt blows up?
11:07:16 <doug16k> I'd break before that lidt, look at the instruction, and I'd dump the memory operand and see what limit baselo basehi is getting loaded
11:07:52 <doug16k> step over it, check info registers. see if IDT = the expected things
11:08:23 <doug16k> oh
11:08:45 <doug16k> one common issue people have. if you are only handling one IRQ, you need to mask all the other IRQs on the PIC
11:09:08 <doug16k> what will happen when another IRQ is signalled? nothing good if IDT entry isn't right
11:09:25 <doug16k> even if you point it to an empty iret function, still no good, you'd have to EOI it too
11:09:40 <doug16k> best mask all except IRQs you can actually handle
11:11:01 <keegans> ok so my debugger is just completely broken
11:11:15 <keegans> when i load the boot.elf using `file`, then i get `Remote 'g' packet reply is too long (expected 308 bytes, got 608 bytes):`
11:11:27 <keegans> starting qemu with `-s -S /dev/zero`
11:11:39 <zid> reaaaaly old/new version of qemu or gdb respectively?
11:11:58 <keegans> GNU gdb (GDB) 8.2.1 and version
11:12:04 <keegans> *QEMU emulator version 4.0.0
11:12:09 <zid> both really new then
11:12:13 <keegans> yeah
11:12:16 <doug16k> wrong architecture
11:12:28 <zid> gdb -m32? :P
11:12:31 <keegans> oh i am running qemu-system-x86_64
11:12:41 <keegans> but gdb loads a i386 file
11:12:46 <doug16k> in there you can: set architecture i386 or i386:x86-64
11:12:47 <keegans> should i be running qemu-system-i386 ?
11:12:51 <doug16k> yes, really a hyphen
11:13:05 <keegans> ah
11:13:08 <doug16k> is it 32 bit code? definitely i386
11:13:37 <doug16k> gdb simply breaks if the size of the register file changes, so x86_64 emulator workaround is to keep it full sized
11:14:00 <keegans> ah
11:14:12 <keegans> ok i am running i386 qemu now w/ gdb and it connected and has the file loaded properly, nice
11:14:15 <zid> debugging a 32bit cpu vs debugging a 64bit cpu with some bits disabled :P
11:14:41 <keegans> you're also saying that I should be only have 2 idt entries ? 0 and 1 (for the keyboard )
11:14:49 <zid> you should have all of them
11:14:51 <zid> with default handlers
11:14:53 <doug16k> not I am not saying that
11:14:53 <keegans> when i had 256 i had a default handler
11:15:06 <keegans> the default handler just `port_byte_out(0x20, 0x20);`
11:15:07 <doug16k> no I am not*
11:15:08 <zid> they may need to ack spurious irqs, else you'll wedge the pic
11:15:37 <doug16k> where do you rebase the PICs to? which vectors
11:16:14 <doug16k> nowhere right? you should not leave them in the horrible DOS compatible config
11:16:30 <zid> you don't want to confuse page faults with modems? pfft
11:16:34 <doug16k> they overlap interrupts reserved for exceptions by default
11:16:55 <keegans> does multiboot not handle that ?
11:17:04 <zid> setting up the pic? no
11:17:19 <zid> did you set a flag for it and fill out a structure? then it probably didn't do it :P
11:17:39 <doug16k> keegans, in qemu monitor, run this command: info pic
11:18:02 <keegans> apologies , what is the qemu monitor
11:18:11 <keegans> the compat_monitor0 ?
11:18:15 <doug16k> ya
11:18:27 <keegans> how do i scroll in this lol
11:18:36 <doug16k> ctrl pgup/pgdown maybe?
11:18:45 <zid> -monitor stdio
11:18:46 <doug16k> or shift, or something
11:19:02 <doug16k> ya or -monitor stdio the actual behaviour varies depending on how qemu was built
11:19:12 <doug16k> behaviour of that window I mean
11:19:17 <zid> https://cdn.discordapp.com/attachments/417023075348119556/582346957750665216/unknown.png Here's mine, did I do it wrong also doug? :p
11:19:33 <doug16k> that is fine
11:19:44 <doug16k> base 0x20 is >= 0x20
11:19:49 <zid> I did get an IRQ once!
11:20:45 <zid> I need to rewrite my ethernet driver for mmio now that I actually do it
11:20:48 <doug16k> is IMR inverted though?
11:20:50 <keegans> k let me upload
11:21:06 <zid> I don't even remember what IMR is, interrupt mask reg?
11:21:17 <doug16k> ya
11:21:18 <zid> It should be pit and keyboard masked for me, I think
11:21:18 <keegans> https://imgur.com/OGhzHKy.png
11:21:32 <keegans> also yeah i fixed the debugger so that's good to go
11:21:49 <zid> so you have 8 irqs at 8 and 8 at 70?
11:21:51 <zid> that's odd
11:22:12 <doug16k> zid, really? you keep getting timer irqs and keyboard irqs?
11:22:23 <zid> No I don't, they're masked, I hope :D
11:22:44 <doug16k> yes your masks are inverted exactly. 1 means masked, 0 means unmasked
11:22:53 <zid> Perfect
11:23:01 <zid> IRQ 1 and 2 masked is precisely what I wanted
11:23:20 <zid> 0 and 1? whatever
11:23:26 <doug16k> and all others enabled? seems like that wouldn't be what you wanted, but ok
11:23:38 <doug16k> masked = can't be received
11:24:18 <zid> doug16k: I bascically added the interrupt code so that I could enable interrupts for my ethernet controller driver, but hitting 'enter' in grub would cause an IRQ at boot, which wasn't handled / being ACK'd
11:24:22 <zid> same for the PIT
11:24:28 <zid> so I just masked them while I got IRQs working
11:24:49 <doug16k> ok then, so an unusual config for special situation. gotcha
11:24:51 <zid> I've not needed to unmask them so that code hasn't changed
11:25:16 <zid> I'll eventually get around to doing APIC and scheduling and stuff and it'll change :P
11:25:51 <doug16k> keegans, you have your interrupts where DOS expects them
11:26:15 <zid> My plan was never to do anything with a keyboard, as I don't fancy having my input stolen, the plan is to run a webserver or something over ethernet instead
11:26:26 <doug16k> keyboard will be in vector 9 of the IDT
11:26:29 <zid> should let me run 'ab' as a stress test for the scheduler etc instead of trying to type really quickly :P
11:27:11 <keegans> doug16k: so that means i need the extra pic2 eoi , yeah ?
11:27:13 <zid> plus I don't have to do a UI or terminal emulator or anything, just spit out some basic html forms for debug screens etc
11:27:26 <zid> keegans: Interrupt 9
11:27:27 <doug16k> keegans, no
11:27:30 <zid> not IRQ
11:27:43 <doug16k> keegans, see irq_base in that screenshot?
11:27:54 <keegans> yeah
11:27:54 <zid> Your IRQs go 70, 71, 72, 73, 73, 74, 75, 76, 9, 10, 11, 12, 13, 14, 15
11:28:06 <zid> Which I pointed out when you posted your picture
11:28:16 <zid> and is probably not what you want (especially as 9 10 11 etc clash with exceptions)
11:28:20 <zid> which doug mentioned
11:28:23 <doug16k> zid, upside down. screenshot shows pic1 first then pic0
11:28:34 <zid> ah okay 9 10 11.. 70 71 72.. :)
11:28:48 <doug16k> 8 9 ...
11:28:53 <zid> 8 9 A techincally? :P
11:28:54 <zid> math is hard
11:28:55 <doug16k> IRQ0 == vector 8
11:29:07 <keegans> ok i see so i should be using interrupt 9
11:29:11 <keegans> yet that doesnt seem to fix the issue
11:29:14 <zid> Except you shouldn't
11:29:17 <keegans> it still doesn't print to vga when i hit a key
11:29:23 <zid> because that's also an exception handler interrupt for the cpu
11:29:40 <doug16k> the way that is configured ya. in general you should reprogram the PICs to be outside the 0x00-0x1F range
11:29:45 <keegans> how can i re-map my PICs
11:29:50 <zid> well you already remapped one of them..
11:29:59 <keegans> oh shit
11:30:01 <doug16k> 8 and 70 is DOS
11:30:02 <keegans> i see
11:31:19 <doug16k> something like this https://github.com/doug65536/dgos/blob/master/kernel/arch/x86_64/cpu/legacy_pic.cc#L28
11:31:44 <zid> https://github.com/zid/boros/blob/master/interrupt.c#L67 Mine's a lot simpler :P
11:31:58 <zid> also nice typo zid
11:32:44 <keegans> also as a side note , i am correctly loading the gdt , yeah ?
11:32:58 <keegans> (as in the godbolt i sent earlier )
11:34:08 <doug16k> keegans, looks like it would work
11:34:29 <keegans> just out of curosity , how would you check
11:34:43 <keegans> like is it possible to verify in my debugger
11:34:50 <keegans> i guess i could store the gdt in a variable
11:34:55 <keegans> then check to ensure the structure is correct
11:34:56 <doug16k> in qemu monitor you can do info registers
11:35:02 <zid> I think I tested mine in bochs with 'info gdt', but info registers should show you your GDT base reg
11:35:10 <zid> and you could dump the memory it points to and interpret it
11:35:14 <doug16k> look at GDT=
11:35:51 <doug16k> take that base and do x /40hx thataddress to dump gdt
11:36:19 <zid> doug16k: When are you adding qemu patches for things like info gdt and 'page' from bochs? :)
11:36:40 <doug16k> should eh?
11:36:47 <keegans> ok so i just remapped the pics to 32 like zid
11:36:51 <keegans> then i tried it and it didnt work
11:36:57 <keegans> then i saw that zid enables interrupts with sti
11:36:59 <keegans> so i did that as well
11:37:04 <keegans> then i hit a key and int printed int 33
11:37:08 <keegans> but subsequent presses do nothing
11:37:14 <zid> you're not acking right then
11:37:27 <zid> or you disabled interrupts again somewhere
11:37:30 <doug16k> out 0x20 to 0x20 only
11:37:55 <keegans> yeah that's what i've got w/ port_byte_out(0x20, 0x20);
11:38:00 <zid> did you iret
11:38:01 <zid> or ret
11:38:13 <doug16k> ok get it froze up like that, then in qemu monitor do: info pic
11:38:19 <zid> ooh yea
11:38:30 <doug16k> it will tell you whether you didn't EOI it
11:38:36 <zid> Mine are enabled there mainly just so that any pending IRQs get triggered there while the defualt no_op handlers are installed. Otherwise I tend to get a wedged keyboard IRQ from hitting 'enter' in grub etc.
11:38:37 <doug16k> ISR = in service register
11:39:25 <keegans> isr=00
11:39:50 <doug16k> you read the scancode right?
11:39:58 <keegans> lol
11:40:00 <keegans> no i dont
11:40:02 <keegans> oops
11:40:03 <doug16k> lol
11:40:09 <zid> keyboard actually cares if it's read from?
11:40:13 <doug16k> yes
11:40:22 <doug16k> it won't assert another interrupt until then
11:40:33 <zid> I figured it'd be like, edge triggered and you just read from the single latched scancode, til
11:41:09 <doug16k> more like rising edge in "have a byte in there" signal is irq. stays high until you take it out and cause another rising edge
11:41:29 <zid> yea I didn't think it'd stay high I guess, makes sense that it does though.
11:41:32 <keegans> ayy very nice
11:41:35 <zid> Hadn't really considered how the keyboard would work
11:41:37 <keegans> yeah i had to read then now it works
11:41:47 <keegans> thanks for your help !
11:41:48 <zid> and you're not longer confusing keyboards with exceptions :p
11:41:51 <zid> no*
11:41:55 <keegans> yeah that is certainly good
11:43:21 <keegans> so in my default interrupt handler (which is 0-255) i have `port_byte_out(0x20, 0x20);` to ACK the interrupt
11:43:33 <keegans> but i remember it was mentioned you also need to ack the slave input for certain interrupts
11:43:42 <zid> You need the double ack on the chained pic, check my master ack vs slave ack thing
11:43:43 <keegans> i don't really understand this , is it covered on the wiki ?
11:44:12 <zid> oh I have a typo on 62 should be 40, nice
11:44:23 <doug16k> keegans, if it is IRQ8-IRQ15 then you need to EOI PIC1 and PIC0
11:44:42 <keegans> zid: :D
11:44:51 <zid> They're literally chained, the 2nd pic just delivers an IRQ2
11:44:54 <keegans> doug16k: ok, got it , nice
11:45:01 <zid> or whatever you chain it off
11:45:13 <doug16k> it's hardwired to irq2
11:45:20 <doug16k> unless you have a soldering iron...
11:45:35 <zid> I mean, physically
11:45:42 <doug16k> and a machine so old it isn't buried on layer 7 of an ASIC :P
11:45:53 <zid> They're two of the same chip, with one output connected to one input on another (also yea, if we're talking machines that nobody owns)
11:46:44 <doug16k> ya the PIC is pretty cool. you can do that with all 8 of the inputs and have 64 IRQs
11:46:48 <keegans> https://github.com/zid/boros/blob/master/interrupt.c#L34 is that supposed to be "cli;hlt"
11:46:51 <doug16k> if you are building a board I mean
11:46:58 <keegans> or are you defining a label called cli then making it hlt
11:47:10 <zid> almost certainly yea
11:47:12 <zid> :D
11:47:18 <zid> I apparently wrote that file while asleep
11:47:23 <zid> we've noticed three typos so far
11:47:26 <doug16k> hlt isnt guaranteed not to wake up. need a jmp
11:48:23 <zid> what's the syntax for that in gas
11:48:31 <zid> jmp $ or jmp . or jmp -2 or what
11:48:46 <doug16k> 0:cli\njmp 0b
11:48:51 <doug16k> oops
11:48:54 <doug16k> hlt in there :D
11:48:57 <zid> kk
11:49:16 <zid> that builds, good enough
11:49:18 <doug16k> can 0: the hlt since IF won't set itself, but NMI could wake hlt
11:50:05 <zid> Not that I expect qemu does SMI stuff which is what you'd expect might wake it
11:50:28 <doug16k> SMI is special, it can crawl back into a hlt without the OS noticing
11:50:40 <zid> I was literally just thinking about that, nice
11:50:40 <doug16k> it is optimized for malicious use of course
11:51:05 <bcos_> If you're offlining; disable paging, disable caches in CR0 and give it some WBINVD
11:51:05 <zid> "I wonder if SMI can re-enter the h- <doug.."
11:51:23 <doug16k> I hope the US military likes the SMI feature that intel was so kind to add
11:51:26 <zid> I'm just trying to get the message to stay onscreen for long enough that I see it bcos :P
11:51:43 <zid> doug16k: I like it for thermal management, at least
11:52:04 <zid> Nice to know that if my machine crashes in an infinite loop it isn't going to catch fire because nobody is watching the sensors anymore
11:53:45 <doug16k> ya, because motherboard manufacturer is too cheap to put a 4 cent microcontroller there to do utterly mindless things like asserting STPCLK or whatever in emergencies
11:54:13 <doug16k> cheaper to copy paste some SMI shit that saves 4 cents but uses the 125W cpu to do it instead
11:54:13 <zid> Well I don't even mean for emergencies, it's nice that it's done transparently
11:54:32 <zid> if the cpu itself did it you'd have to configure a bunch of behaviors in your cpu, instead of in your firmware for how much cooling etc you wanted
11:54:57 <zid> I don't want to be drawing fanspeed graphs into an MSR :P
11:58:05 <bcos_> Didn't Intel add a bunch of power measurement stuff recently?
11:58:11 <bcos_> ..in MSRs
11:58:26 <doug16k> RAPL stuff?
11:58:30 <bcos_> Yes
11:58:39 <zid> cool, can haver even cleverer SMIs then :P
11:58:41 <doug16k> ya I see lots about that in intel manual
11:58:55 * bcos_ was thinking it'd be nice to track that stuff, and figure out how much power/heat each process is responsible for
11:59:19 <doug16k> yes. ryzen has an msr that counts Coulombs too
11:59:54 <zid> how much charge can you store in a ryzen?