<geist>
also if you accidentally used APIC ID 0, it's pretty much guaranteed to be BSP
<geist>
id wrap, truncation, etc
<geist>
though yeah getting into the AP code from reset is odd
biblio has quit [Quit: Leaving]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
freakazoid333 has joined #osdev
m5zs7k has quit [Quit: m5zs7k]
m5zs7k has joined #osdev
m5zs7k has quit [Client Quit]
m5zs7k has joined #osdev
m5zs7k has quit [Quit: m5zs7k]
m5zs7k has joined #osdev
gog has quit [Remote host closed the connection]
gog has joined #osdev
<kazinsal>
Hmm. I'm hesitant to call this a VMware bug, because I'm generally hesitant to blame anything other than my own code, but I can't reproduce this in VirtualBox or QEMU (with or without KVM). Haven't tried on Hyper-V (don't have a Hyper-V box handy) or real hardware so time to keep digging.
freakazoid333 has quit [Ping timeout: 258 seconds]
[itchyjunk] has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
CryptoDavid has quit [Quit: Connection closed for inactivity]
m3a has quit [Quit: leaving]
particleflux has quit [Ping timeout: 264 seconds]
particleflux has joined #osdev
m3a has joined #osdev
freakazoid343 has joined #osdev
Benjojo_ has joined #osdev
Benjojo has quit [Ping timeout: 260 seconds]
dude12312414 has joined #osdev
Benjojo_ is now known as Benjojo
Benjojo has quit [Ping timeout: 264 seconds]
paulbarker has quit [Ping timeout: 260 seconds]
Benjojo has joined #osdev
gjnoonan has quit [Ping timeout: 260 seconds]
sts-q has quit [Ping timeout: 260 seconds]
gjnoonan_ has joined #osdev
paulbarker has joined #osdev
<geist>
nice, finally around to setting up a private 10gbe link between my VM server and my NAS box
<geist>
definitely seems to be pretty speedy. maxes out the disks at 350MB/sec and if it's cached on the NAS seems to push about 700 over NFS
srjek has quit [Ping timeout: 245 seconds]
<geist>
basically a pair of 10gbe pcie-4 copper nics with a cat 6 3 foot wire
<geist>
ACQ-107 chipset, which seems decent enough for the price (about $100)
<geist>
i might regret using copper and not SFP+ though, since it seems most switches are SFP+
<geist>
if i ever get around to adding a switch in the middle of it
<geist>
in that case SFP+ kinda makes some sense. cheaper switch, pay by the connection for the transceiver
sts-q has joined #osdev
mahmutov has joined #osdev
<kazinsal>
nice. SFP+ transcievers for 10GBASE-T are pretty inexpensive now
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
freakazoid343 has quit [Read error: Connection reset by peer]
<geist>
yah looks like most relatively inexpensive 10gbe switches are mostly just a pile of SFP+s
<kazinsal>
hmm, generic SFP+ 10GBASE-T transcievers are about $65 USD now. not as inexpensive as I thought
<kazinsal>
10GBASE-SR fibre transcievers are $20
<geist>
yah that's possibly why 10gbase-t switches are expensive
<geist>
sounds like the per port hardware is pretty hard to make
<geist>
whereas dumping it onto fiber may be simpler
<kazinsal>
lot higher wattage and more complex I think
<geist>
yah i read there's a fair amount of compelxity and ECC and retransmitting and whatnot to get 10gbe over copper
<geist>
so lots of asic there to back it up
<geist>
may be tossing itonto fiber is much less complicated silicon wise
<kazinsal>
yeah, the line coding for 10GBASE-T is way more complex
<klange>
Ah, well. So the cause here was actually the terminal scrollback eating all of memory, combined with an oversight on how I'm mapping physical memory for arbitrary modification.
<klange>
Also general problems with my heap implementation showing up in both the kernel and userspace. I really should write a new malloc - this one predates the beginning of the ToaruOS project.
<geist>
yah i need to finally write a real driver model for LK
<geist>
but there are sooo many existing drivers
<geist>
tiny little one off things, but getting them all converted is going to be a pain
<moon-child>
geist: niice
<moon-child>
i only have a 2.5gbps thing
Oli has quit [Quit: leaving]
<klange>
The key problem with my malloc is that it will never release memory, and if you get it to fragment just right you can manage to be constantly allocating more memory while not actually using much.
<klange>
In userspace that is resolvable by just killing the process, but I use the same heap implementation in the kernel, where there's no good fix.
<geist>
i do recommend always having a really dumb simple one to use for things liek bootloaders and whatnot
<geist>
i wrote a super simple default one for LK years ago that just uses a linked list of free blocks that has been useful to plonk into random projects
<klange>
It's actually a fairly good malloc if you can ignore that flaw.
<klange>
The main source of its issues is that it was written for uni coursework that stipulated system mechanisms and also there were a competition with a particular test suite, so it's kinda tuned for that environment.
<klange>
And ten years ago I gave up on improving it. It's thread safe by heavy locking, it never reclaims memory, it only uses sbrk()... but it does okay with alignment requirements, has a good binning strategy for small allocations, and it's faster than glibc's default at least.
<klange>
It's actually really good if you have lots of small allocations but don't really know how big they'll be. It's not great at large allocations, and that's the main source of issues with fragmentation - you start allocating buffers that are bigger than the max bin size and all hell breaks loose.
<klange>
I had a huge TODO that I think has lived as a big #if 0'd chunk of code to have it merge neighboring unused regions.
<klange>
Really, I need to get off my ass on implementing a proper mmap and stop relying on a single heap break. At least with the kernel this should be more straightforward, and in fact I do quite a lot of direct page allocation instead of going to heap, where I can.
<klange>
I did a few more tests with this loopback and, uh, actually the problem is a combination of things, but I think the biggest one is that I didn't put a limit on queue sizes and it can send much faster than it can receive in most situations.
<klange>
So I sent a few million UDP packets and before you know it you've got the kernel heap moved a gigabyte up and that's never going back to the available memory pool and you better hope you want more allocations of the same size when they finall get cleared out...
<klange>
This reminds me that I do something terribly silly in one of my userspace apps: The desktop provider will kill itself after changing the wallpaper.
<klange>
It does this intentionally. it loads the new wallpaper, does a transition animation, then restarts itself (I think I just re-exec it), which ensures the memory from the old wallpaper is released.
<klange>
The compositor handles this okay since it never actually clears the screen, so you just get a tiny bit of ghosting from things being redraw on top of themselves in the framebuffer before the new wallpaper client starts up again.
vai has joined #osdev
<vai>
hi all
<vai>
working on my pet project
[itchyjunk] has quit [Remote host closed the connection]
Brnocrist has quit [Ping timeout: 268 seconds]
Brnocrist has joined #osdev
ravan has quit [Quit: Leaving]
ThinkT510 has quit [Quit: WeeChat 3.3]
ThinkT510 has joined #osdev
xenos1984 has joined #osdev
lleo has joined #osdev
lleo has quit [Quit: beforge.net]
biblio has joined #osdev
biblio has quit [Remote host closed the connection]
Mikaku has quit [Quit: server maintenance ...]
Mikaku has joined #osdev
mahmutov has quit [Ping timeout: 244 seconds]
vdamewood has joined #osdev
MiningMarsh has quit [Ping timeout: 264 seconds]
Arthuria has joined #osdev
GeDaMo has joined #osdev
[itchyjunk] has joined #osdev
Arthuria has quit [Ping timeout: 260 seconds]
z_is_stimky has quit [Read error: Connection reset by peer]
z_is_stimky_ has joined #osdev
gog has quit [Quit: byee]
gog has joined #osdev
theruran has quit [Quit: Connection closed for inactivity]
X-Scale has quit [Ping timeout: 260 seconds]
m3a has quit [Quit: leaving]
tenshi has joined #osdev
ElectronApps has joined #osdev
josuah has joined #osdev
Oli has joined #osdev
lanodan has quit [Quit: WeeChat 3.1]
lanodan has joined #osdev
nyah has joined #osdev
X-Scale has joined #osdev
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Nine out of ten l33t h4x0rz prefer it]
unmanbearpig has quit [Ping timeout: 260 seconds]
pretty_dumm_guy has joined #osdev
stzsch|2 has quit [Ping timeout: 264 seconds]
srjek has joined #osdev
MiningMarsh has joined #osdev
aleamb has joined #osdev
unmanbearpig has joined #osdev
dude12312414 has joined #osdev
mahmutov has joined #osdev
ElectronApps has quit [Remote host closed the connection]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
kpel has joined #osdev
kpel has quit [Client Quit]
kpel has joined #osdev
mahmutov has quit [Ping timeout: 260 seconds]
mahmutov has joined #osdev
wootehfoot has joined #osdev
theruran has joined #osdev
shikhin has joined #osdev
Oli has quit [Quit: Lost terminal]
Oli has joined #osdev
tenshi has quit [Quit: WeeChat 3.3]
m3a has joined #osdev
GeDaMo has quit [Remote host closed the connection]
dude12312414 has joined #osdev
nvmd has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]