<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
<klange>
in this case, firmware just didn't assign legacy IRQs to anything, which makes sense
sdfgsdfg has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
sdfgsdfg has quit [Client Quit]
<kazinsal>
did you just have to poke some IRQ numbers into the PCI config space to get stuff going?
<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.
<kazinsal>
ahhh
bgs has quit [Ping timeout: 265 seconds]
bgs has joined #osdev
xenos1984 has joined #osdev
<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
<klange>
I have two environments that I should be able to test that on
<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...
<geist>
kazinsal: re SMT pairs i think that's encoded in the standard MADT table, i think
<geist>
but if not that you can tell pretty easily with some lightly vendor specific CPUID stuff
<kazinsal>
ah neat
<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
gioyik has quit [Ping timeout: 276 seconds]
<geist>
hmm, guess it's not in the MADT
<geist>
that table really just has a list of cpus
<geist>
and their APIC id
dutch has quit [Quit: WeeChat 3.3]
dutch has joined #osdev
gioyik has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
sprock has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
Brnocrist has quit [Ping timeout: 260 seconds]
gioyik has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
friedy10 has quit [Quit: WeeChat 3.2]
ahlk has quit [Remote host closed the connection]
gioyik has joined #osdev
ZetItUp has quit []
gioyik has quit [Ping timeout: 276 seconds]
ZetItUp has joined #osdev
mimmy has joined #osdev
Oli has joined #osdev
vdamewood has joined #osdev
vdamewood has quit [Ping timeout: 264 seconds]
vinleod has joined #osdev
gioyik has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
vinleod is now known as vdamewood
Brnocrist has joined #osdev
mimmy_ has joined #osdev
mimmy has quit [Ping timeout: 264 seconds]
Baobab has quit [Ping timeout: 264 seconds]
mimmy_ has quit [Ping timeout: 245 seconds]
mimmy_ has joined #osdev
[itchyjunk] has joined #osdev
gioyik has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
friedy10 has joined #osdev
mimmy_ has quit [Ping timeout: 245 seconds]
mimmy_ has joined #osdev
mimmy has joined #osdev
mimmy_ has quit [Ping timeout: 264 seconds]
<rustyy>
TIL that TLBs may have multiple levels
friedy10 has quit [Quit: WeeChat 3.2]
mimmy_ has joined #osdev
mimmy has quit [Ping timeout: 264 seconds]
mimmy has joined #osdev
mimmy_ has quit [Ping timeout: 264 seconds]
mimmy has quit [Quit: WeeChat 3.3]
<pounce>
rustyy: yea they gotta pretty much
gioyik has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
sdfgsdfg has joined #osdev
gioyik has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
gioyik has quit [Ping timeout: 276 seconds]
nyah has quit [Ping timeout: 264 seconds]
gioyik has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
[itchyjunk] has quit [Remote host closed the connection]
ElectronApps has joined #osdev
srjek|home has quit [Ping timeout: 264 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
gioyik has joined #osdev
zaquest has quit [Remote host closed the connection]
Oli has quit [Quit: leaving]
zaquest has joined #osdev
sdfgsdfg has joined #osdev
mctpyt has quit [Ping timeout: 245 seconds]
YuutaW has joined #osdev
xenos1984 has quit [Quit: Leaving.]
ns129 has joined #osdev
thaumavorio has quit [Ping timeout: 250 seconds]
ns12 has quit [Ping timeout: 250 seconds]
ns129 is now known as ns12
thaumavorio has joined #osdev
Beato has quit [Ping timeout: 240 seconds]
adachristine has joined #osdev
gog has quit [Quit: byee]
adachristine is now known as gog
sdfgsdfg has quit [Quit: ZzzZ]
<kazinsal>
reading an ethernet card datasheet from 1988 because I have this horrible idea that involves my operating system and a (simulated) PDP-11...
<sortie>
:D
lleo has joined #osdev
ElectronApps has quit [Remote host closed the connection]
<kazinsal>
oh neat, this thing is just an AMD LANCE, a 68k, and a slab of static RAM on a Unibus card
leo__ has joined #osdev
<klange>
just spent some time improving my terminal emulators with deferred rendering, finally
<klange>
not fully asynchronous, but output processing is now significantly less dependent on rendering speed
<bslsk05>
en.wikipedia.org: Deferred shading - Wikipedia
<klange>
No, deferred in the very general sense of "why do now what you can put off 'til later"
<klange>
previously: receive character, draw character
<moon-child>
fwiw xterm will deliberately cap text output speed vs rendering for 'correctness' unless you pass -j
<klange>
now: receive character, update a buffer; some time later: check where that buffer differs from the known screen state and redraw where necessary
<moon-child>
hardware simulation (process things in a queue) vs video game ethos (sample potentially-continuous state at some interval)
<klange>
I think that abstraction is inaccurate for this. It's more like simulating a teletype vs. simulating a character generator
<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)
mavhq has quit [Ping timeout: 260 seconds]
<moon-child>
fair enough
gog` has joined #osdev
<moon-child>
but, well, the character generator is basically sampling the state of the letters at the refresh rate, no?
<moon-child>
I guess everything digital reduces to sampling at some level
<moon-child>
so maybe that's not a very interesting statement
* gog
samples moon-child
gog` has quit [Client Quit]
<sortie>
klange, neat
<sortie>
I did try making my kernel console redraw in the background and it sped things up massively that it could 'skip frames'
<sortie>
Unfortunately it also can make it unresponsive because now there's buffering which can be significant
<sortie>
E.g. if you cat a long file, ^C might take a good moment to react and stop it
<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...]
<moon-child>
sortie: make the thing the terminal state manager suspendable, and make sure to redraw at 60hz or w/e
<moon-child>
or, say, run for n steps before redrawing, w/e
<sortie>
Not sure if your suggestion is helpful
<klange>
I've found it's more down to buffer size than anything to do with redraw speed.
<sortie>
But certainly will think about it when I actually have time to dedicate to the problem
sprock has quit [Ping timeout: 264 seconds]
scoobydoo has quit [Ping timeout: 260 seconds]
<sortie>
Yeah, buffer size
<klange>
if the sun suddenly went dark, it would still be bright on earth for 8 minutes
<klange>
buffer size is like light-distance, even if you killed the process it was already 'putting out light' that is now 'in transit'
<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
<sortie>
Yup it's tricky stuff
<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.
mavhq has joined #osdev
sprock has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
[itchyjunk] has joined #osdev
xenos1984 has joined #osdev
GeDaMo has joined #osdev
gioyik has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
PraiseIdleness has joined #osdev
givemeyourpies has quit [Quit: Going offline, see ya! (www.adiirc.com)]
leo__ has quit [Quit: Leaving]
ElectronApps has joined #osdev
lg has quit [Ping timeout: 265 seconds]
lg has joined #osdev
xenos1984 has quit [Ping timeout: 264 seconds]
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
PraiseIdleness has joined #osdev
the_lanetly_052 has joined #osdev
skipwich has quit [Read error: Connection reset by peer]
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
PraiseIdleness has joined #osdev
xenos1984 has joined #osdev
skipwich has joined #osdev
nyah has joined #osdev
pretty_dumm_guy has joined #osdev
chir4gm1 has joined #osdev
chir4gm1 has left #osdev [#osdev]
sdfgsdfg has quit [Quit: ZzzZ]
dude12312414 has joined #osdev
gioyik has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
PraiseIdleness has joined #osdev
vinleod has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
gioyik has joined #osdev
pg12 has quit [Ping timeout: 256 seconds]
sprock has quit [Ping timeout: 264 seconds]
pg12 has joined #osdev
Oli has joined #osdev
wgrant has quit [Ping timeout: 268 seconds]
srjek|home has joined #osdev
wgrant has joined #osdev
<jjuran>
kazinsal: Wait, an ethernet card with a 68k chip?
srjek|home has quit [Quit: Leaving]
<Oli>
I would salvage it.
<Oli>
An oddly expensive choice for a Ethernet card processor nowadays, to me: I wonder if it is an old Ethernet card.
<jjuran>
The datasheet is from 1998.
ElectronApps has quit [Remote host closed the connection]
<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.
<bslsk05>
en.wikipedia.org: Microcontroller - Wikipedia
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
PraiseIdleness has joined #osdev
mahmutov has joined #osdev
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
PraiseIdleness has joined #osdev
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 264 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
c2a1 has quit [Ping timeout: 264 seconds]
xenos1984 has quit [Quit: Leaving.]
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seds has quit [Ping timeout: 245 seconds]
seds has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
sm2n_ has joined #osdev
sprock has joined #osdev
ns124 has joined #osdev
wille5 has joined #osdev
the_lanetly_052 has joined #osdev
X-Scale` has joined #osdev
bauen1_ has joined #osdev
xenos1984 has joined #osdev
PraiseIdleness has joined #osdev
EtherNet_ has joined #osdev
vdamewood has joined #osdev
vinleod has quit [*.net *.split]
the_lanetly_052_ has quit [*.net *.split]
nyah has quit [*.net *.split]
[itchyjunk] has quit [*.net *.split]
ns12 has quit [*.net *.split]
zaquest has quit [*.net *.split]
bgs has quit [*.net *.split]
X-Scale has quit [*.net *.split]
bauen1 has quit [*.net *.split]
nohit has quit [*.net *.split]
EtherNet has quit [*.net *.split]
sm2n has quit [*.net *.split]
kingoffrance has quit [*.net *.split]
wille has quit [*.net *.split]
V has quit [*.net *.split]
lanodan has quit [*.net *.split]
wille5 is now known as wille
ns124 is now known as ns12
X-Scale` is now known as X-Scale
bgs has joined #osdev
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bslsk05>
hackaday.com: Making A Three Cent Microcontroller Useful | Hackaday
sprock has quit [Ping timeout: 265 seconds]
scoobydoo has joined #osdev
PraiseIdleness has joined #osdev
sprock has joined #osdev
PraiseIdleness has quit [Ping timeout: 256 seconds]
pg12 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 265 seconds]
<Oli>
Thank you for sharing about, GeDaMo! I am currently reading about!
sprock has quit [Ping timeout: 250 seconds]
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` has joined #osdev
X-Scale` is now known as X-Scale
<corecode>
Oli: what did you think they cost?
isaacwoods has joined #osdev
m3a has quit [Quit: leaving]
sprock has joined #osdev
particleflux_ has joined #osdev
particleflux has quit [Ping timeout: 265 seconds]
[itchyjunk] has quit [Read error: Connection reset by peer]
particleflux_ is now known as particleflux
wootehfoot has joined #osdev
<geist>
kazinsal: interesting. it was unibus so was it expecting to be some sort of network coprocessor?
<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
<j`ey>
switching off MSI-X (falls back to INTx I guess?) lets it boot properl
<geist>
huh that's interesting. what is the VMM it's running under?
<geist>
or is this your own?
<j`ey>
Im using kvmtool
<geist>
are you sure it's not falling back to MSI vs MSI-X?
<geist>
probably back to ioapic ints
<j`ey>
this is arm, so no ioapic
<j`ey>
(right? ioapic is an x86 thing?)
<geist>
ah okay. GIC then
<geist>
which GIC do you have selected? MSI works differently between gicv2 and gicv3
<geist>
not entirely sure you can do MSI-X at all on gicv2
<j`ey>
I was using gicv3 with ITS, after turning off ITS (so just gicv3) it worked
<j`ey>
I haven't looked into exactly what ITS is, but apparently it's what enables MSI-like things
<geist>
yeah, that's exactly right
<geist>
the ITS is a secondary table that with gicv3 you route the MSIs through
<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
<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
<geist>
fun time!
<geist>
actually reinds me, i need to write a gicv3 driver for LK
<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
<j`ey>
is gicv3 compatible with v2?
<geist>
not really no. it's not a strict superset
<j`ey>
oh shame
<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
<geist>
v2 a lot of everything is 8 bit bitmaps
<geist>
send an ipi? 8 bit bitmap. set the cpus to deliver this irq to? 8 bit bitmap, etc
<geist>
v3 it's like unlimited number of cpus, and all the addressing uses the MPIDR style addressing that the cpu does
<geist>
so it's more complicated at a fundamental level since a lot of those basic regisers had to be reformatted
<j`ey>
and some kinda 'indirection' I guess
<geist>
stuff like IPIs is generally an O(N) thing, sadly
<geist>
but makes sense when you can have like 64k cpus you can't easily represent a target for things in one data structure
<geist>
gic v4 and 4.1 i think are simple extensions though, so really gicv3 includes 4
<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)
<geist>
but since there are only a max of 8 cores it's easy to encode it
<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
<j`ey>
oh right
<j`ey>
how big is the MSI message then usually?
<geist>
i think it's by definition 32bits
<j`ey>
oh ok
<geist>
though you can also encode some of the data in the target address
<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
<j`ey>
*nod*
<geist>
looks like the osdev wiki has a pretty good overview of gicv2 and 3+
<bslsk05>
developer.arm.com: Documentation – Arm Developer
<geist>
oooooh yeah
<geist>
i should read up on the realm stuff so when someone asks me i know what i'm talking about
<zid>
do the same for msi-x on amd64 for me
<j`ey>
geist: :)
wootehfoot has quit [Quit: Leaving]
<zid>
I didn't immediately get it from the intel manual, and I bet checking the linux source would be frustrating
<geist>
zid: vs MSI or just MSI*?
<geist>
vs MSI i dont think there's really anything in the intel manual about it, since that's mostly PCI level stuff
<zid>
not vs anything
<geist>
ah start with MSI then, MSI-X is kinda an additional layer, but mostly at the PCI side
<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"
<geist>
yah a lot of the -X part is just additional paperwork the bus driver has to do
<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
<zid>
I *think* I recall from looking at it that you tell the device sort of what it should send you
<geist>
yep it's the 'how you tell the device' part that differs in the two mechanism
<zid>
and you match that to how you configure the cu
<zid>
cpu
<geist>
but the same thing happens: device delivers magic payload to magic address. the intel manual describes the payload
<zid>
but I've not done either side before so making them meet without fiddling probably wasn't going to happen
<geist>
wish doug16k was around, he really knew the shit out of this stuff too
<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
<geist>
much deeper into the PC platform side of stuff
<zid>
but maybe that's standardized
<geist>
zid: right. you configure the device basically with 'when you want to trigger interrupt, write X to address Y'
<geist>
and the intel manual describes the X and Y, the PCI manual describes the how you talk to the device part
<geist>
and MSI-X greatly expands on MSI configuration
<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'
<zid>
need to do some reading :(
<zid>
sadge
<geist>
yah that's intel manual. i dunno it off the top of my head, but the address is roughly the local apic address
<zid>
there was some huge table
<geist>
but the payload is iirc split across the bottom N bits of the address and the 32bit field
<geist>
yah lots of fields. about things like edge/level triggered, etc
ahlk has joined #osdev
<geist>
and of course the 8 bit IRQ number
m3a has joined #osdev
<geist>
and some routing info, so you can target specific cpus. i forget how that works on x86, especially with a full 32bit x2apic
<zid>
fixed 0FEE, 8bit destination ID, for distribution over processors, redirection hint.. blah blah
<geist>
ah yeah
<geist>
and then the payload mostly holds the irq info itself? irq #, edge/level/high/low?
<geist>
yah but that table is the apic hardware, not really the MSI thing
<zid>
I still need to set the apic up though
sprock has quit [Ping timeout: 256 seconds]
<geist>
though you're sending the MSI to the apic, the fields in the MSI record/address arent really registers in the apic
<geist>
oh sure, yeah gotta at least implement a basic local apic driver
<geist>
but it's pretty darn simple. most registesr you wont need to frob
<zid>
still gotta read through it all though in case I do
<geist>
honestly it's not much more complicated than a proper PIC driver
<geist>
yah
<zid>
nah PIC only has like 4 config words and 3 of them are "ignored if x86" :p
<geist>
well thats why i say 'proper' driver
<geist>
but frankly that's about how much you gotta frob the local apic
<geist>
most local apic drivers the bulk of the code goes into the timer part of it
<zid>
maybe ultimately, but I still have to read it
<zid>
to figure out which bits are important to me and which aren't
<geist>
which is really just along for the ride. it's logically a separate component, just also part of the loal apic
<geist>
yah
<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'
<zid>
LAPIC (not x2) has them in the register table, all I know
<zid>
I'm not sure I've used an real ioapic
<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
<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
<zid>
and doesn't mean what it seems to mean at first
<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'
<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
<zid>
1. Not supported in the Pentium 4 and Intel Xeon processors.
<geist>
i remember it, since i have docs from prior to that
<zid>
this is *all over* the manual
<geist>
yep
<zid>
but I bet it's supported on my.. xeon processor
<zid>
because they mean 'the one from 2002' and not 'every cpu since 2002'
<geist>
it' like the docs are written in APPEND ONLY mode
<geist>
so they dont seem to be interested in going back and actually removing old verbiage
<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
<geist>
and it's not like P4 or original Xeon was that special, compared to all the things after it
<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
<zid>
where the list to the right is 800 models long
<geist>
yah. i do wonder if the intent at the time was xeon was not intended to be a family but turned into it
<zid>
yea from the manual, it definitely seems like they thought it'd just be 'some chip line'
<geist>
as a marketing name that is. possible they at the time intended it to be a single cpu or cpu line
<zid>
and they'd get a new 'server name' every time
<geist>
right
<zid>
Which *sorta* happened, but they all say xeon on the box
<zid>
but now it's a knight's landing xeon, etc
<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
<zid>
skylake-w xeon
<zid>
sandy bridge-ep xeon
<Oli>
corecode: A dollar per unit, as the very least!
<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
<geist>
right around 2000, and the two vendors were starting to charge premiums for it
<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
freakazoid12345 has quit [Ping timeout: 245 seconds]
<zid>
Intel lost out in the present era for having done that, which is kinda funny
<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
<zid>
They wanted you to buy expensive xeons starting with 2 or 4 or 8 to get multiprocessor machines
<zid>
AMD just re-fused them into one chip and go "we have 16 memory channels lol"
<geist>
yah. i still have a dual P3 500 slot 1 machine, about 1999
<gog>
that form factor was cool
<zid>
You can buy an intel machine with '16 memory channels' too, it just comes in 4 cpus
<zid>
instead of 1 cpu with 4 dies
<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
<zid>
I have a slot 1 cpu somewhere
<zid>
I always wanted a sick dual socket purple motherboard in the p2/p3 era
<zid>
(mainly because it was purple, I'd never seen purple silkscreen)
<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
<zid>
eisa? :)
<geist>
i used to use it as kind aa baseline for benchmarks but it being 32bit it's becoming less and less useful
<geist>
nah, eisa does not interest me. same as MCA
<geist>
you basically need a server machine to ever find eisa
<kazinsal>
yeah, you're getting a bit too esoteric to be useful if you're in the eisa zone
<zid>
I've seen eisa a fair bit on youtube
<zid>
the 'prosumer' retro gear they all use has eisa
<zid>
because nobody wants the dirt cheap crap that rotted anyway
<zid>
they want the expensive boards
<geist>
kazinsal: so do tell re: the 68k + lance card you have
<kazinsal>
oh, I don't *have* one, I was just reading the datasheet for it
<geist>
i'm also putting off cleaning up prior to fam showing up later, so i need a distraction
<kazinsal>
I had a late night terrible idea of porting my OS to PDP-11, see
<geist>
ah but what was the purpose of the card in the first place? io processor?
<geist>
just, you know, in case you needed a nudge
<kazinsal>
the 68k handles the unibus transactions and the memory management as well as initialization for the LANCE
<zid>
pci-x is one thing I've literally never seen anywhere
<geist>
zid: servers and high end apple gear. my old g5 powermac had PCI-X
<zid>
nobody cares about pci era servers
<zid>
or apple. *dodges thrown shoes*
<geist>
well, just sayin, that's where i've seen it. possible there were workstation boards at the time
<geist>
but then the question is what cards were explicitly pci-x
<geist>
also pci 64bit
<zid>
that's why I'm saying I haven't seen it
<kazinsal>
yeah, probably that prosumer type segment
<zid>
because nobody gives a shit about pci era servers, they all went in the bin in the early 2000s
<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
<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
<zid>
anything inbetween is pretty wastelandish
<geist>
what i dont know is what sort of pci level busses things like alpha servers and sparc boxes got into
<kazinsal>
you'd need PCI-X for quad port gigabit as well
<geist>
presumably they had all kinds of bigass pci in those
<geist>
and those things are very valuable right now
<kazinsal>
the later ones had PCI-X I think
<geist>
yah i suspect that's where most of that drive came from
gioyik has quit [Ping timeout: 276 seconds]
<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
<kingoffrance>
thats likely why lawyers define things too, to "inline" them or "local" version
<geist>
well it does also kinda mirror the x86 architecture too: very append only
<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'
<geist>
ie, removing things does not always make it simpler, since removal generally involves phases of deprecation, etc
<zid>
nod
<zid>
plus x86's rampant backwards compat with that old stuff means your crap will at least.. work
<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
GeDaMo has quit [Remote host closed the connection]
<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
<zid>
hah
<kazinsal>
apparently "cursed startech products" is a popular genre
<zid>
I own a startech pci-e to usb card
<kazinsal>
this was a PCIe to 16x RS-232
<zid>
*points* it's there
<zid>
I got it because it had a very specific usb chip on it
<zid>
VTL7127 or something I forget
<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
<zid>
that.. actually makes sense, from a hw perspective
<zid>
I bet it's a mess of memory mapping in software
<kazinsal>
oh yeah, it is definitely a card made from the parts bin
<zid>
I'd be surprised if a pci-e to 16x rs-232 chip existed!
gioyik has joined #osdev
<kazinsal>
it also has a SATA power connector on it for the required current to drive sixteen RS-232 channels lol
<zid>
75W isn't enough? That's what you can draw from pci-e
<kazinsal>
may also be a voltage thing
<zid>
5V should be enough for anyone
<kazinsal>
oooooh right, 75W is only guaranteed in an x16 connector
<zid>
ahh
<kazinsal>
x1 connectors only get 10W
<zid>
even though all the power pins are in the stub on the left, and the lanes are just 'everything after'?
<zid>
that seems odd, but I guess it makes some sense
<kazinsal>
3A at 3.3V + 0.5A at 12V
<kazinsal>
though you're capped at 10...
<kazinsal>
so I guess you have to choose what you want
<zid>
isn't that.. 16W
<zid>
oh
<zid>
I bet I could shunt mod my gpu to draw more than 75W from the slot and the mobo would be happy
<zid>
especially if I didn't load the other slots
<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
<zid>
this board is kinda nutty in terms of features, I have a page in my bios about pci-e clocking
<zid>
how sharp the edges are, overclock, etc
freakazoid12345 has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
<zid>
am I going mad or does intel just completely neglect to mention what the value of IA32_APIC_BASE is
<zid>
oh I found it, that was hard to spot
<zid>
Using the APIC global enable/disable flag in the IA32_APIC_BASE MSR (MSR address 1BH; see Figure 10-5):
<zid>
On the like the 8th time it uses the term IA32_APIC_BASE
mahmutov_ has joined #osdev
mahmutov has quit [Ping timeout: 245 seconds]
gioyik has joined #osdev
sdfgsdfg has joined #osdev
<klange>
zid: the PIC is my friend and you wouldn't abandon a friend, would you?
<zid>
depends, how much money does it have?
gioyik has quit [Ping timeout: 276 seconds]
<geist>
zid: yah FWIW, i *think* pretty much everything prefixed with IA32_* is a MSR address
<geist>
i haven't checked, but presumably all the itanium ones share the same MSR namespace and were prefixed with IA64_
<geist>
same way that itanium has the same cpuid scheme, etc
mahmutov_ has quit [Ping timeout: 250 seconds]
<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
gioyik has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
[itchyjunk] has joined #osdev
gioyik has quit [Ping timeout: 276 seconds]
gioyik has joined #osdev
<zid>
geist: I knew it was an MSR, I just couldn't find the address
<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.
<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
<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...
<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...
[itchyjunk] has quit [Remote host closed the connection]
givemeyourpies has joined #osdev
<klange>
(and then for good measure, I copied the edited source over to my desktop...)
<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
<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
sprock has joined #osdev
[itchyjunk] has joined #osdev
<zid>
not in vol3 at least
dude12312414 has joined #osdev
givemeyourpies has quit [Read error: Connection reset by peer]