Older blog entries for davem (starting at number 11)

12 Jun 2001 (updated 12 Jun 2001 at 21:33 UTC) »

Winter is long gone, this snowboard powder bum is depressed.

I just int10 booted the x86 bios on a r128 PCI graphics card on my Sparc SunBlade-100. Life is... ummm... good? Will be cleaning up these xf86-4.1.x mods and trying out tdfx and other cards tomorrow. Maybe I'll even get r128 DRI working on this box, which would be nice. Gareth Hughes promised he would help.

What does this mean? Well basically I can now multi-head Creator3D/Elite3D UPA boards, mach64 ATI cards with Sun firmware, and off the shelf PCI graphics cards with x86 bios on them.

I think I'll setup some scary Xinerama 6 head configuration using the endless supply of monitors I have here, just to scare the wife when she gets home :-)

In other news, linux-kernel thinks I'm a communist, I've become a gonzo journalism addict, and I've joined the playboy cyber club.

I've driven my pathfinder roughly 1,000 miles since my most recent powder day in the Sierras. I'm so pathetic, I know...

Got multi-depth (8, 24), many visuals (truecolor/directcolor/pseudocolor/staticgrey/etc), and hw accelerated double-buffering working with Creator/Creator3D. Just have to nail a few bugs then it's off to DRI/DRM direct 3d rendering.

Paul Oakenfold is the ruler.

The PPPOE/PPPOX patches are in 2.3.x, should show up in Linus's next pre-patch.

Starting looking into overlay support for FFB in xf86-4.0, unfortunately the xf40 overlay layer lacks the concept of window-id's for the 8-bit overlay (essentially, WIDs give you N 8-bit colormaps to use, where N is the number of window IDs supported by the ramdac) so we'll just use one WID for xf86-4.0 until this is cleared up. I wonder if I can trick the xf86 overlay layer and do WID management internally to the ffb driver.

Bleh, I'm hacking on the X server again...

Got the SysKonnect FDDI driver working and portable in 2.3.x Need to cut a 2.2.x version of these changes and submit to the SysKonnect folks for review...

Checking out axboe's latest cut of his elevator hacks, let's see how this goes.

I believe AT&T Cable has a conspiracy going. Every time I've gotten a new cable box, exactly one month later the cable goes out. I call them up, they ask for the number on the bottom of my Digital Cable box, and then immediately turn my service back on. I think what they're doing is just keeping track of the boxes their customers have on a lazy basis, ie. having the customer do the work for them.

Spent a few days on my new paging stuff, killed most of the bugs but it still had a lot of problems. Suddenly I realized that this isn't what I should be working on and as such I have dropped this work for a while, but I sent off a snapshot of the work to Stephen Tweedie in case he wishes to play with it.

Playing with Jens's new elevator stuff, on my box the first run looks really bad... hope that's just a cold first run issue because he's sent this stuff off to Linus already.

Wonder what the heck I'll talk about in my keynote. I'll probably just play it safe and do a "state of the kernel address" type presentation, with emphasis and detailing in the areas I have some clue about (ie. networking, sparc, page cache).

Andrew broke 3c59x.c on non-little-endian machines and those not supporting virt_to_bus/bus_to_bus in pre6-6, I've let him know about this. :-)
Starting to make more progress on my VM hacks, the anon layer was just the beginning. I hope after the 2nd or 3rd pot of coffee tonight I should have something that at least remotely resembles what I want it all to look like. If I arrive at something people can at least play with, I'll post patches.
The Sun IFB/Expert3D card turns out to be an Intense3D chipset (the Wildcat 4110). Their site claims a Linux driver around the summer, but I bet the fucks will do binary only x86 drivers which essentially screws over any chance of legitimate Sparc/Linux support.

Finally got to finishing half of the SKFP portability stuff.
Merged current tree to Linus.
Wrote an anon page layer for the Linux vm. It works, no leaks, no bugs, etc.
Older UltraSparc firmware aparently writes out the "assigned-address" PCI device properties incorrectly for 64-bit MEM space resources. I hate having to write workarounds for crap like this. Nice spotting on this one by Matt Jacob.
Jens is making nice progress on the elevator performance fixups. The one issue we really haven't looked deeply into is how the elevator interacts with the queue plugging, as done by the scsi layer. He is off checking this out already :-)
Went to Santa Cruz with the wife, stuffed ourselves with fish, listened to the sea lions growl, watched the surfers, and came home.

Jens is interested in improving elevator now too :-) Really, the problem is the missed coalescing, the latency concept is not fundamentally broken. The algorithm can get a lot of both worlds by coalescing whenever possible. In this way it performs latency reduction on groups of requests instead of on a per-request basis.

Got distracted for two days working on a prototype fibre channel card, can't talk much about it, but I can say there'll be a Linux driver for this beast :-)

Sun released their IFB (aka. "Expert 3D") graphics card yesterday. It's a bit pricey, but I'm so itching to do a Linux driver for it I may just end up buying one.

The cscope release made Larry McVoy nearly wet his pants.

I think I know why Andrea's new elevator code is so much worse than 2.2.x's disk sorting. The general scheme of the elevator is to keep low the latency introduced to old requests by new requests being added. In doing this, it prevents merging with other requests to the same area of the disk. In actuality this "latency reduction" is really increasing latency, because a missed merge means it will now take two I/O operations to move data which could have been done by a single request. Also, since the elevator will move the I/O request towards the end of the I/O queue, it is almost certain that requests to other sectors will happen first, thus an unnecessary disk seek. I have no idea why the elevator make LVM/IDE dbench runs faster for him, as it seems quite wrong fundamentally.
Will study this more soon.

2 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!