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=osdev2&y=21&m=11&d=24
00:00:00 <klange> the funny thing is modern hardware also generally supports the traditional PIC just fine, too, leaving IOAPIC as a terrible thing in the middle to ignore
00:00:00 <klange> in this case, firmware just didn't assign legacy IRQs to anything, which makes sense
00:04:00 <kazinsal> did you just have to poke some IRQ numbers into the PCI config space to get stuff going?
00:05:00 <klange> I don't know because I don't have enough code for any of the present devices to get them to generate IRQs in order to confirm if that works.
00:05:00 <kazinsal> ahhh
00:15:00 <klange> I might just frob the right bits to get the xhci controller to scream at me just to see if it goes where I want it
00:15:00 <klange> I have two environments that I should be able to test that on
00:16:00 <klange> amusingly, my ThinkPad has a different issue; firmware has assigned IRQs, but its xhci controller is on a hotpluggable card and firmware did _not_ assign BAR space, so I have to walk the bridges to find available space...
00:41:00 <geist> kazinsal: re SMT pairs i think that's encoded in the standard MADT table, i think
00:41:00 <geist> but if not that you can tell pretty easily with some lightly vendor specific CPUID stuff
00:41:00 <kazinsal> ah neat
00:41:00 <kazinsal> I'm always pleasantly surprised when there's something encoded in ACPI that isn't a trip to the depths of hell and back to get useful information from
00:45:00 <geist> hmm, guess it's not in the MADT
00:45:00 <geist> that table really just has a list of cpus
00:45:00 <geist> and their APIC id
03:34:00 <rustyy> TIL that TLBs may have multiple levels
04:27:00 <pounce> rustyy: yea they gotta pretty much
08:46:00 <kazinsal> reading an ethernet card datasheet from 1988 because I have this horrible idea that involves my operating system and a (simulated) PDP-11...
08:52:00 <sortie> :D
08:57:00 <kazinsal> oh neat, this thing is just an AMD LANCE, a 68k, and a slab of static RAM on a Unibus card
08:59:00 <klange> just spent some time improving my terminal emulators with deferred rendering, finally
08:59:00 <klange> not fully asynchronous, but output processing is now significantly less dependent on rendering speed
09:02:00 <moon-child> presumably not this deferred rendering https://en.wikipedia.org/wiki/Deferred_shading ?
09:02:00 <bslsk05> en.wikipedia.org: Deferred shading - Wikipedia
09:02:00 <klange> No, deferred in the very general sense of "why do now what you can put off 'til later"
09:03:00 <klange> previously: receive character, draw character
09:03:00 <moon-child> fwiw xterm will deliberately cap text output speed vs rendering for 'correctness' unless you pass -j
09:03:00 <klange> now: receive character, update a buffer; some time later: check where that buffer differs from the known screen state and redraw where necessary
09:03:00 <moon-child> hardware simulation (process things in a queue) vs video game ethos (sample potentially-continuous state at some interval)
09:05:00 <klange> I think that abstraction is inaccurate for this. It's more like simulating a teletype vs. simulating a character generator
09:05:00 <klange> teletype: smashes the paper as it receives each character; character generator: you update a buffer, I'll draw the letters when I have time (eg. when the electron beam is in the right place)
09:06:00 <moon-child> fair enough
09:06:00 <moon-child> but, well, the character generator is basically sampling the state of the letters at the refresh rate, no?
09:07:00 <moon-child> I guess everything digital reduces to sampling at some level
09:07:00 <moon-child> so maybe that's not a very interesting statement
09:07:00 * gog samples moon-child
09:09:00 <sortie> klange, neat
09:09:00 <sortie> I did try making my kernel console redraw in the background and it sped things up massively that it could 'skip frames'
09:09:00 <sortie> Unfortunately it also can make it unresponsive because now there's buffering which can be significant
09:10:00 <sortie> E.g. if you cat a long file, ^C might take a good moment to react and stop it
09:10:00 <klange> now to look into why the panel starts burning CPU when I type at a prompt... [I know why, my prompt text has the title update sequence, my line editor spits it out every time it draws anything, and no one from the terminal emulator to the compositor to the panel is dropping the duplicate window title update message...]
09:10:00 <moon-child> sortie: make the thing the terminal state manager suspendable, and make sure to redraw at 60hz or w/e
09:11:00 <moon-child> or, say, run for n steps before redrawing, w/e
09:11:00 <sortie> Not sure if your suggestion is helpful
09:11:00 <klange> I've found it's more down to buffer size than anything to do with redraw speed.
09:11:00 <sortie> But certainly will think about it when I actually have time to dedicate to the problem
09:12:00 <sortie> Yeah, buffer size
09:13:00 <klange> if the sun suddenly went dark, it would still be bright on earth for 8 minutes
09:14:00 <klange> buffer size is like light-distance, even if you killed the process it was already 'putting out light' that is now 'in transit'
09:17:00 <klange> If you want a fun ^C anecdote, at one point in trying to make a single-threaded terminal I ran into an issue where ^C could deadlock the tty - if the buffer was full, it would block the write of the '^C' characters from within the terminal process, which is what would have read the buffer and unblocked it... oops
09:18:00 <sortie> Yup it's tricky stuff
09:18:00 <klange> I solved this in two ways... for one, I sort of gave up and just made input processing threaded (this also just helped make pasting from a clipboard not be terrible...) and I made the tty layer just, uh, skip that bit if the buffer is full.
15:14:00 <jjuran> kazinsal: Wait, an ethernet card with a 68k chip?
15:16:00 <Oli> I would salvage it.
15:18:00 <Oli> An oddly expensive choice for a Ethernet card processor nowadays, to me: I wonder if it is an old Ethernet card.
15:19:00 <jjuran> The datasheet is from 1998.
15:30:00 <Oli> Thank you for mentioning about: I am reading the article on the web page that the next hyperlink leads at: https://en.wikipedia.org/wiki/Microcontroller#Volume_and_cost and got hinted by, that microcontrollers are way cheaper than I thought they were.
15:30:00 <bslsk05> en.wikipedia.org: Microcontroller - Wikipedia
17:54:00 <GeDaMo> Oli: https://hackaday.com/2019/04/26/making-a-three-cent-microcontroller-useful/
17:54:00 <bslsk05> hackaday.com: Making A Three Cent Microcontroller Useful | Hackaday
18:46:00 <Oli> Thank you for sharing about, GeDaMo! I am currently reading about!
19:10:00 <corecode> Oli: what did you think they cost?
20:05:00 <geist> kazinsal: interesting. it was unibus so was it expecting to be some sort of network coprocessor?
20:07:00 <j`ey> finally figured out why my linux kernel VM wasnt booting with virtio-pci, something is messed up with the MSI-X interrupt emulation
20:07:00 <j`ey> switching off MSI-X (falls back to INTx I guess?) lets it boot properl
20:07:00 <geist> huh that's interesting. what is the VMM it's running under?
20:07:00 <geist> or is this your own?
20:08:00 <j`ey> Im using kvmtool
20:08:00 <geist> are you sure it's not falling back to MSI vs MSI-X?
20:09:00 <geist> probably back to ioapic ints
20:09:00 <j`ey> this is arm, so no ioapic
20:09:00 <j`ey> (right? ioapic is an x86 thing?)
20:09:00 <geist> ah okay. GIC then
20:10:00 <geist> which GIC do you have selected? MSI works differently between gicv2 and gicv3
20:10:00 <geist> not entirely sure you can do MSI-X at all on gicv2
20:11:00 <j`ey> I was using gicv3 with ITS, after turning off ITS (so just gicv3) it worked
20:11:00 <j`ey> I haven't looked into exactly what ITS is, but apparently it's what enables MSI-like things
20:13:00 <geist> yeah, that's exactly right
20:13:00 <geist> the ITS is a secondary table that with gicv3 you route the MSIs through
20:14:00 <geist> iirc you basically configure the individual device to send a MSI to effectively an index into the table, and the table is what routes thigns to the right cpu. so it's kinda nice in that you can redirect stuff without needing to fiddle with the device's config
20:15:00 <j`ey> I'll have to do some digging as to why it's actually broken, but at least I made some progress. I was stuck on this for 2 days
20:17:00 <geist> fun time!
20:17:00 <geist> actually reinds me, i need to write a gicv3 driver for LK
20:18:00 <geist> most simple arm socs only still use gicv2 since it's simpler, but the big limitation is it only can handle up to 8 cores
20:18:00 <j`ey> is gicv3 compatible with v2?
20:18:00 <geist> not really no. it's not a strict superset
20:18:00 <j`ey> oh shame
20:18:00 <geist> it's similar enough that if you squint it looks basically the same, but they expanded a lot of the features in v3, and more fundamentally the addressing works differently
20:19:00 <geist> v2 a lot of everything is 8 bit bitmaps
20:19:00 <geist> send an ipi? 8 bit bitmap. set the cpus to deliver this irq to? 8 bit bitmap, etc
20:19:00 <geist> v3 it's like unlimited number of cpus, and all the addressing uses the MPIDR style addressing that the cpu does
20:19:00 <geist> so it's more complicated at a fundamental level since a lot of those basic regisers had to be reformatted
20:20:00 <j`ey> and some kinda 'indirection' I guess
20:20:00 <geist> stuff like IPIs is generally an O(N) thing, sadly
20:21:00 <geist> but makes sense when you can have like 64k cpus you can't easily represent a target for things in one data structure
20:21:00 <geist> gic v4 and 4.1 i think are simple extensions though, so really gicv3 includes 4
20:22:00 <geist> oh also MSIs on v2 are very simple, basically much like an x86: send the MSI to the gic, the data field holds the cpu to deliver it to (or something along those lines)
20:22:00 <geist> but since there are only a max of 8 cores it's easy to encode it
20:23:00 <geist> gicv3 i think needs the ITS as an intermediate indirection if anything because the addressing modes of the target cpus on v3 is too big to fit in the MSI message
20:23:00 <j`ey> oh right
20:23:00 <j`ey> how big is the MSI message then usually?
20:23:00 <geist> i think it's by definition 32bits
20:24:00 <j`ey> oh ok
20:24:00 <geist> though you can also encode some of the data in the target address
20:24:00 <geist> so it's usually a combination of those two, like send MSI to this 4K page, bottom 12 bits are data, then 32bits of data
20:25:00 <j`ey> *nod*
20:25:00 <geist> looks like the osdev wiki has a pretty good overview of gicv2 and 3+
20:26:00 <geist> https://wiki.osdev.org/Generic_Interrupt_Controller_versions_3_and_4 and https://wiki.osdev.org/Generic_Interrrupt_Controller
20:26:00 <bslsk05> wiki.osdev.org: Generic Interrupt Controller versions 3 and 4 - OSDev Wiki
20:26:00 <bslsk05> wiki.osdev.org: Generic Interrupt Controller - OSDev Wiki
20:26:00 <j`ey> cool, will have a read in a bit
20:26:00 <geist> ah yeah it goes over the ITS and whatnot. it's very complicated. one of these things that doesn't make sense until the whole picture clicks
20:27:00 <geist> and i'm still pretty hazy about it. have not added MSI support for gicv3 to LK or zircon
20:27:00 <geist> like a lot of ARM stuff, GIC in particular, the docs are extremely dry with very little theory of operation
20:27:00 <geist> but really the GIC docs are some of the worst i've seen as far as that very complete but extremely hard to parse style they have
20:29:00 <j`ey> those eureka moments are nice though :D
20:30:00 <geist> yah exactky
20:30:00 <geist> this wiki page does a good job of at least mentioning how the group0 group1 stuff is supposed to work
20:31:00 <geist> that fouled me up for a long time when i was first picking this up
20:31:00 <geist> because the gic docs very much assume you have the full ARM ELx and virtualization stuff in mind as well as secure mode
20:31:00 <geist> since the GIC is fundamentally aware of secure more and virtualization (especially v4)
20:31:00 <geist> secure mode i mean
20:33:00 <j`ey> im mostly ok with ELx.. virtualisation is always a little tricky!
20:33:00 <geist> yah
20:33:00 <j`ey> especially with the NVHE / VHE stuff
20:33:00 <geist> also secure vs nonsecure mode took me a long time to latch, since i had to really see how it was actually used for it to make sense
20:35:00 <geist> anyway thanks for getting me to think about GIC, which will now be running through my head all day
20:35:00 <geist> woke up, drinking coffee, then immediately thinking about interrupt controllers.
20:35:00 <j`ey> sorry? :p
20:35:00 <geist> it's gonna be a good day :)
20:35:00 <geist> heh no, that's totally fine
20:35:00 <j`ey> geist: im working on stuff related to https://developer.arm.com/documentation/den0126/latest
20:35:00 <bslsk05> developer.arm.com: Documentation – Arm Developer
20:35:00 <geist> oooooh yeah
20:36:00 <geist> i should read up on the realm stuff so when someone asks me i know what i'm talking about
20:36:00 <zid> do the same for msi-x on amd64 for me
20:36:00 <j`ey> geist: :)
20:36:00 <zid> I didn't immediately get it from the intel manual, and I bet checking the linux source would be frustrating
20:37:00 <geist> zid: vs MSI or just MSI*?
20:37:00 <geist> vs MSI i dont think there's really anything in the intel manual about it, since that's mostly PCI level stuff
20:37:00 <zid> not vs anything
20:37:00 <geist> ah start with MSI then, MSI-X is kinda an additional layer, but mostly at the PCI side
20:38:00 <zid> I mean, the goal is "tell pci-e device something about msi-x, or maybe ask it about msi-x, and have it show up in an interrupt handler"
20:38:00 <geist> yah a lot of the -X part is just additional paperwork the bus driver has to do
20:38:00 <geist> at least that's my understanding. i haven't personally written a MSI or MSI-X driver, but have done some debugging with the zircon one
20:38:00 <zid> I *think* I recall from looking at it that you tell the device sort of what it should send you
20:39:00 <geist> yep it's the 'how you tell the device' part that differs in the two mechanism
20:39:00 <zid> and you match that to how you configure the cu
20:39:00 <zid> cpu
20:39:00 <geist> but the same thing happens: device delivers magic payload to magic address. the intel manual describes the payload
20:39:00 <zid> but I've not done either side before so making them meet without fiddling probably wasn't going to happen
20:40:00 <geist> wish doug16k was around, he really knew the shit out of this stuff too
20:40:00 <zid> I assume it's also sort of per-device too, because if knows about 14 different interrupts I need to tell it at least which bits to put the message into (which maybe I get as a payload in a single irq), or where to fill those bits in in the message to make them come as different IRQs, idk
20:41:00 <geist> much deeper into the PC platform side of stuff
20:41:00 <zid> but maybe that's standardized
20:41:00 <geist> zid: right. you configure the device basically with 'when you want to trigger interrupt, write X to address Y'
20:41:00 <geist> and the intel manual describes the X and Y, the PCI manual describes the how you talk to the device part
20:41:00 <geist> and MSI-X greatly expands on MSI configuration
20:42:00 <zid> I forget if the address Y was 'range of addresses that are an IRQ each' or 'single address where the payload describes the IRQ type'
20:42:00 <zid> need to do some reading :(
20:42:00 <zid> sadge
20:42:00 <geist> yah that's intel manual. i dunno it off the top of my head, but the address is roughly the local apic address
20:42:00 <zid> there was some huge table
20:42:00 <geist> but the payload is iirc split across the bottom N bits of the address and the 32bit field
20:42:00 <geist> yah lots of fields. about things like edge/level triggered, etc
20:43:00 <geist> and of course the 8 bit IRQ number
20:43:00 <geist> and some routing info, so you can target specific cpus. i forget how that works on x86, especially with a full 32bit x2apic
20:43:00 <zid> fixed 0FEE, 8bit destination ID, for distribution over processors, redirection hint.. blah blah
20:44:00 <geist> ah yeah
20:44:00 <geist> and then the payload mostly holds the irq info itself? irq #, edge/level/high/low?
20:44:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/913168258746708048/unknown.png and this giant mess of stuff I need to figure out how much I need to configure and how much to ignore
20:45:00 <geist> yah but that table is the apic hardware, not really the MSI thing
20:45:00 <zid> I still need to set the apic up though
20:45:00 <geist> though you're sending the MSI to the apic, the fields in the MSI record/address arent really registers in the apic
20:45:00 <geist> oh sure, yeah gotta at least implement a basic local apic driver
20:45:00 <geist> but it's pretty darn simple. most registesr you wont need to frob
20:46:00 <zid> still gotta read through it all though in case I do
20:46:00 <geist> honestly it's not much more complicated than a proper PIC driver
20:46:00 <geist> yah
20:46:00 <zid> nah PIC only has like 4 config words and 3 of them are "ignored if x86" :p
20:46:00 <geist> well thats why i say 'proper' driver
20:46:00 <geist> but frankly that's about how much you gotta frob the local apic
20:47:00 <geist> most local apic drivers the bulk of the code goes into the timer part of it
20:47:00 <zid> maybe ultimately, but I still have to read it
20:47:00 <zid> to figure out which bits are important to me and which aren't
20:47:00 <geist> which is really just along for the ride. it's logically a separate component, just also part of the loal apic
20:47:00 <geist> yah
20:48:00 <geist> never looked into it, but did the timer part of the local apic exist also with the original discrete ioapic? im guessing no, was probably bolted on when they moved a copy of the ioapic into the cpu (around pentium) and started calling it 'local apic'
20:48:00 <zid> LAPIC (not x2) has them in the register table, all I know
20:48:00 <zid> I'm not sure I've used an real ioapic
20:49:00 <geist> yep, you probably haven't real APICs haven't existed since about pentium, or at least much past them all getting integrated into the chipset
20:49:00 <zid> aside: I think it's kinda funny that the intel manuals still constantly refer to 'intel xeon' like it's a specific cpu range like a pentium 4, and not 'more than half the CPUs they've ever designed' at this point
20:50:00 <zid> and doesn't mean what it seems to mean at first
20:50:00 <zid> That was confusing, they *do* specifically mean, 'the cpu we called xeon that came out around the same time as pentium 4' when they say 'xeon'
20:51:00 <geist> yah i know. it's like they had a major reformatting at the time to start referring to things in real time and then promptly dropped it
20:51:00 <zid> 1. Not supported in the Pentium 4 and Intel Xeon processors.
20:51:00 <geist> i remember it, since i have docs from prior to that
20:51:00 <zid> this is *all over* the manual
20:51:00 <geist> yep
20:51:00 <zid> but I bet it's supported on my.. xeon processor
20:51:00 <zid> because they mean 'the one from 2002' and not 'every cpu since 2002'
20:51:00 <geist> it' like the docs are written in APPEND ONLY mode
20:51:00 <geist> so they dont seem to be interested in going back and actually removing old verbiage
20:52:00 <geist> and yeah this is a prime example where removing old stuff is not because old features are getting removed (which arent) but that referring to pentium 4 as a line in the sand is no longer useful
20:52:00 <geist> and it's not like P4 or original Xeon was that special, compared to all the things after it
20:52:00 <zid> just put a note at the top saying 'intel xeon refers to the P6 series of chips, not core, core2, i3, i5, i7, skylake, haswell, ivy bridge, ... based xeons' :P
20:53:00 <zid> where the list to the right is 800 models long
20:53:00 <geist> yah. i do wonder if the intent at the time was xeon was not intended to be a family but turned into it
20:53:00 <zid> yea from the manual, it definitely seems like they thought it'd just be 'some chip line'
20:53:00 <geist> as a marketing name that is. possible they at the time intended it to be a single cpu or cpu line
20:53:00 <zid> and they'd get a new 'server name' every time
20:53:00 <geist> right
20:54:00 <zid> Which *sorta* happened, but they all say xeon on the box
20:54:00 <zid> but now it's a knight's landing xeon, etc
20:54:00 <geist> and i guess they did the same thing a few years later when they released a core chip, then a core 2, then reused core as a generic family monkier
20:54:00 <zid> skylake-w xeon
20:54:00 <zid> sandy bridge-ep xeon
20:55:00 <Oli> corecode: A dollar per unit, as the very least!
20:55:00 <geist> i do reember prior to xeon there wans't a large distinction. it was right around 2000 that both intel and AMD were starting to remove (or fuse off) SMP support (as in multiple cpus, since this was pre multicore) artificially
20:55:00 <geist> right around 2000, and the two vendors were starting to charge premiums for it
20:56:00 <geist> i distinctl remember taking an athlon XP around 2000 and intentionally breaking a trace so i could still use it as a athlon MP
20:56:00 <zid> Intel lost out in the present era for having done that, which is kinda funny
20:56:00 <geist> prior to that you simply bought an expensive ass motherboard and stuffed more than one cpu in it and it just worked, since most of the SMP machinery was on the cpu bus
20:56:00 <zid> They wanted you to buy expensive xeons starting with 2 or 4 or 8 to get multiprocessor machines
20:57:00 <zid> AMD just re-fused them into one chip and go "we have 16 memory channels lol"
20:57:00 <geist> yah. i still have a dual P3 500 slot 1 machine, about 1999
20:57:00 <gog> that form factor was cool
20:57:00 <zid> You can buy an intel machine with '16 memory channels' too, it just comes in 4 cpus
20:57:00 <zid> instead of 1 cpu with 4 dies
20:58:00 <geist> yah kinda is. it wasn't really particularly quiet, and though i never had the problem, apparently there were cases where the slotket cpu would fall out
20:58:00 <zid> I have a slot 1 cpu somewhere
20:58:00 <zid> I always wanted a sick dual socket purple motherboard in the p2/p3 era
20:59:00 <zid> (mainly because it was purple, I'd never seen purple silkscreen)
20:59:00 <geist> but yeah that machine is a real trooper. i keep it around because it's a fairly capable machine that still has a full array of pci and isa slots. so good for old cards, like SCSI, or whatnot
20:59:00 <zid> eisa? :)
20:59:00 <geist> i used to use it as kind aa baseline for benchmarks but it being 32bit it's becoming less and less useful
21:00:00 <geist> nah, eisa does not interest me. same as MCA
21:00:00 <geist> you basically need a server machine to ever find eisa
21:00:00 <kazinsal> yeah, you're getting a bit too esoteric to be useful if you're in the eisa zone
21:00:00 <zid> I've seen eisa a fair bit on youtube
21:01:00 <zid> the 'prosumer' retro gear they all use has eisa
21:01:00 <zid> because nobody wants the dirt cheap crap that rotted anyway
21:01:00 <zid> they want the expensive boards
21:01:00 <geist> kazinsal: so do tell re: the 68k + lance card you have
21:01:00 <kazinsal> oh, I don't *have* one, I was just reading the datasheet for it
21:01:00 <geist> i'm also putting off cleaning up prior to fam showing up later, so i need a distraction
21:01:00 <kazinsal> I had a late night terrible idea of porting my OS to PDP-11, see
21:01:00 <geist> ah but what was the purpose of the card in the first place? io processor?
21:02:00 <kazinsal> pre-ASIC era ethernet card
21:02:00 <geist> https://newos.org/toolchains/pdp11-aout-11.2.0-Linux-x86_64.tar.xz
21:02:00 <geist> just, you know, in case you needed a nudge
21:02:00 <kazinsal> the 68k handles the unibus transactions and the memory management as well as initialization for the LANCE
21:02:00 <zid> pci-x is one thing I've literally never seen anywhere
21:03:00 <geist> zid: servers and high end apple gear. my old g5 powermac had PCI-X
21:03:00 <zid> nobody cares about pci era servers
21:03:00 <zid> or apple. *dodges thrown shoes*
21:04:00 <geist> well, just sayin, that's where i've seen it. possible there were workstation boards at the time
21:04:00 <geist> but then the question is what cards were explicitly pci-x
21:04:00 <geist> also pci 64bit
21:04:00 <zid> that's why I'm saying I haven't seen it
21:04:00 <kazinsal> yeah, probably that prosumer type segment
21:04:00 <zid> because nobody gives a shit about pci era servers, they all went in the bin in the early 2000s
21:05:00 <geist> yah maybe some sort of video capture, or high end storage cards, some sort of RAID thing might exceed the standard 133MB/sec you'd get on plain pci 32bit 33mhz
21:05:00 <zid> people like dos era PCs to play commander keen on, and anything from 2007+ onwards is a 'normal' quad core desktop with pci-e
21:05:00 <zid> anything inbetween is pretty wastelandish
21:05:00 <geist> what i dont know is what sort of pci level busses things like alpha servers and sparc boxes got into
21:05:00 <kazinsal> you'd need PCI-X for quad port gigabit as well
21:06:00 <geist> presumably they had all kinds of bigass pci in those
21:06:00 <geist> and those things are very valuable right now
21:07:00 <kazinsal> the later ones had PCI-X I think
21:09:00 <geist> yah i suspect that's where most of that drive came from
21:17:00 <kingoffrance> that made me laugh "it' like the docs are written in APPEND ONLY mode" that comes up in other stuff too 1) have to explicitly cancel something 2) imply if new docs conflict with old, new docs win 3) imply if old docs conflict with new, old docs win 4) ... there are different "conflict resolution strategies" i suppose
21:20:00 <kingoffrance> thats likely why lawyers define things too, to "inline" them or "local" version
21:38:00 <geist> well it does also kinda mirror the x86 architecture too: very append only
21:38:00 <geist> which frankly is a lot of the complexity of ARM architecture: lots of optional, deprecated, will remove later, etc. so there are more axis to consider with features. whereas with x86 it's mostly 'do i need to ignore this old feature that is presumed to always be there'
21:39:00 <geist> ie, removing things does not always make it simpler, since removal generally involves phases of deprecation, etc
21:39:00 <zid> nod
21:39:00 <zid> plus x86's rampant backwards compat with that old stuff means your crap will at least.. work
21:40:00 <zid> I'm still using the PIC, the PIC just isn't in a real DIP anymore it's in the superio or cpu or whatever, it's a couple hundred gates nobody gives a shit about the costs of
21:41:00 <kazinsal> jesus, I posted a cursed startech PCIe card to twitter last night as a reply to some other cursed startech products and my phone has just been going off non stop with notifications
21:41:00 <zid> hah
21:41:00 <kazinsal> apparently "cursed startech products" is a popular genre
21:41:00 <zid> I own a startech pci-e to usb card
21:41:00 <kazinsal> this was a PCIe to 16x RS-232
21:41:00 <zid> *points* it's there
21:42:00 <zid> I got it because it had a very specific usb chip on it
21:42:00 <zid> VTL7127 or something I forget
21:43:00 <kazinsal> more wonderfully, it's a PCIe card with a PCIe to PCI bridge attached to a pair off PCI to ISA bridges each with a chip that has 8 UARTs in it
21:43:00 <zid> that.. actually makes sense, from a hw perspective
21:43:00 <zid> I bet it's a mess of memory mapping in software
21:43:00 <kazinsal> oh yeah, it is definitely a card made from the parts bin
21:44:00 <zid> I'd be surprised if a pci-e to 16x rs-232 chip existed!
21:44:00 <kazinsal> it also has a SATA power connector on it for the required current to drive sixteen RS-232 channels lol
21:44:00 <zid> 75W isn't enough? That's what you can draw from pci-e
21:46:00 <kazinsal> may also be a voltage thing
21:46:00 <zid> 5V should be enough for anyone
21:46:00 <kazinsal> oooooh right, 75W is only guaranteed in an x16 connector
21:46:00 <zid> ahh
21:47:00 <kazinsal> x1 connectors only get 10W
21:47:00 <zid> even though all the power pins are in the stub on the left, and the lanes are just 'everything after'?
21:47:00 <zid> that seems odd, but I guess it makes some sense
21:47:00 <kazinsal> 3A at 3.3V + 0.5A at 12V
21:47:00 <kazinsal> though you're capped at 10...
21:47:00 <kazinsal> so I guess you have to choose what you want
21:47:00 <zid> isn't that.. 16W
21:47:00 <zid> oh
21:48:00 <zid> I bet I could shunt mod my gpu to draw more than 75W from the slot and the mobo would be happy
21:48:00 <zid> especially if I didn't load the other slots
21:48:00 <kazinsal> yeah, spec says 10W combined but all cards can draw up to 10W of 3.3V and a x1 slot can also draw 0.5A of 12V
21:49:00 <zid> this board is kinda nutty in terms of features, I have a page in my bios about pci-e clocking
21:49:00 <zid> how sharp the edges are, overclock, etc
21:58:00 <zid> am I going mad or does intel just completely neglect to mention what the value of IA32_APIC_BASE is
21:59:00 <zid> oh I found it, that was hard to spot
21:59:00 <zid> Using the APIC global enable/disable flag in the IA32_APIC_BASE MSR (MSR address 1BH; see Figure 10-5):
22:00:00 <zid> On the like the 8th time it uses the term IA32_APIC_BASE
22:29:00 <klange> zid: the PIC is my friend and you wouldn't abandon a friend, would you?
22:30:00 <zid> depends, how much money does it have?
22:49:00 <geist> zid: yah FWIW, i *think* pretty much everything prefixed with IA32_* is a MSR address
22:49:00 <geist> i haven't checked, but presumably all the itanium ones share the same MSR namespace and were prefixed with IA64_
22:50:00 <geist> same way that itanium has the same cpuid scheme, etc
22:51:00 <geist> kazinsal: neat an actual card with a pci bridge. i think i have some sort of old PCI card with a bridge + OCHI and firewire
23:12:00 <zid> geist: I knew it was an MSR, I just couldn't find the address
23:12:00 <klange> Last night I thought I'd do a live update of my terminal on my laptop. I could do this by just downloading the binary over a local HTTP server, but I thought I'd have some fun, so I set up a reverse shell because I have a tool for that. Like backwards telnet.
23:12:00 <zid> it's referenced about 20 times, but the address is given once in some brackets and the constant isn't like 0x8000001B like a lot of MSRs so I looked over it
23:12:00 <klange> But then I realized it had a similar bug to the thing I described yesterday... if you paste into it, it'll lock up because it's single threaded and the write will block while waiting for the tty buffer to be read out...
23:13:00 <klange> So I spun my chair around to the actual laptop, opened up a local terminal, opened up bim, banged out some threading, rebuilt it, restarted it, and then I could paste the new terminal source into the remote shell...
23:17:00 <klange> (and then for good measure, I copied the edited source over to my desktop...)
23:18:00 <klange> you know what I need... I need a git port; sortie has one... or maybe in proper toaru style I need my own git porcelain
23:18:00 <geist> zid: ah yeah. iirc there's a big MSR list in one f the last appendicies, so it also tends to come up last in search
23:32:00 <zid> not in vol3 at least
23:55:00 <kazinsal> volume 4, chapter 2, section 1
23:55:00 <kazinsal> "Architectural MSRs"
23:55:00 <zid> can confirm 3 is not 4
23:56:00 <gog> lies