Are you using the standard kernel26 package? I'm on Arch, and when I connect my plug, two USB ttys show up and I can't seem to get OpenOCD to access JTAG. I'm not sure what could be different.

I saw that, and the config that's labeled for 2.6.30.4 is actually from 2.6.30.3, but I guess there were no changes in options that affected it. I generated a patch from the kirkwood_defconfig to that config, and I'll be looking through it tomorrow to see what significant changes are in there.
I'll probably wind up just using the uImage from that link or the one from the recovery/install system, but it'll be interesting to see what's different.

EDIT:
Here's what the problem was:

After doing that, my kernel boots.

That didn't do the trick.
Reading the above log, it seems like the root partition in the flash is now /dev/mtdblock2, but it was originally /dev/mtdblock1, but changing that doesn't make a difference either. I can see JFFS2 loading from the kernel boot log, so I'm not sure what's causing the issues.
My bootargs in U-Boot is currently "console=ttyS0,115200 mtdparts=nand_mtd:0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/mtdblock2 rw ip=10.4.50.4:10.4.50.5:10.4.50.5:255.255.255.0:DB88FXX81:eth0:none rootfs=jffs2"
I haven't modified the flash partition sizes, so that part should still be correct.
The boot fails, ending in these lines:

Here's where it scans the flash:

Here's the line where the JFFS2 system initializes:


I guess the first thing I should ask is whether there's a patch that fixes this behavior because this image is the 2.6.30.4 kernel compiled from the kirkwood_defconfig with no patches and no modifications to the config.
The second thing I should ask is whether this is worth diagnosing because I can just get a premade image elsewhere. If I've configured something wrong though, it could be a good learning experience.

Well, I tried building 2.6.30.4 of the mainline kernel today, using the kirkwood_defconfig, and now I'm getting this when I reboot:

I assumed that the defconfig would have jffs2 support, but apparantly this isn't the case. Do I have to get uBoot to boot from TFTP now if I want to get it running again? Where can I find a good kernel uImage to start from?

Arrived on my doorstep today (August 3). I knew the Sheevaplug was small, but for some reason I was expecting a larger box.

Ordered June 13, shipped today (July 29). Hopefully they'll give me a tracking number, but I've learned not to rely on tracking services. UPS and FedEx are more worried about getting the package there than letting you watch as it goes through shipping hubs.

I'm not sure where floating point operations are and aren't used, but I do know that lossy codecs tend to use them, and basically any significant floating point use will kill the plug. It's floating point performance is probably below that of the original Pentium (although it doesn't have a division glitch like the Pentium had).

I don't even have a SD card; my plan is to have it boot from the onboard flash and use an external hard drive for bulk storage.
The trick is that I maintain two linux boxes in a network of Windows boxes, and I need to be able to backup both types, which AMANDA doesn't do well. If I remember correctly, it can backup Windows boxes if you share the hard drive with SMB, which just doesn't seem like something I want to do.
I did, however, get Bacula working on Vista, and I'm looking into getting scheduled backups running. It's not as simple as just making a tar.lzma of my entire root filesystem, but it'll work for everything.

The problem isn't CPU power, the problem is that there is no hardware FPU (Floating Point Unit) to process floating point values quickly. As a consequence, the CPU must do floating point calculations, which is much much slower. Lossy encoding, such as video encoding, generally uses floating point values.

I'm not sure what your point is. I've already stated that I doubt many 32 bit systems will still be in operation, and I used the embedded device example just to show that changing the currently used date format isn't possible in many scenarios. I never said we were all doomed; this is just a problem on the horizon. It will probably cause some problems in the next 20 years, but due to the 64 bit move, I doubt there will be any immensely serious consequences.
In case it wasn't clear before, 64 bit Posix operating systems do store the time in a 64 bit signed integer, which will overflow in a few million years. Applications compiled for these systems also store the date in 64 bits. Ironically enough, the open source world is pretty much perfectly safe.

Unfortunately, my assumption is also correct. The Unix time is stored as a signed 32 bit integer in Unix, Linux, and other operating systems, and it has been stored that way for a very long time. So many applications depend on this that it can't be easily changed. Even if the kernel code was modified to use a 64 bit signed integer instead, or even two 32 bit fields as you suggest, the bug would still exist and it would still have consequences because applications couldn't be adapted to the new format.
Furthermore, embedded systems like the Sheevaplug that are used in many environments where they are configured and left to run for years with no maintenance frequently cannot be updated, and thus will suffer from a problem like this.

Well, it's basically the Y2K bug all over again, only this time it only affects Unix and Linux.
Unix and Linux measure time in seconds since January 1, 1970, and on some day in 2038, 32 bit versions of Unix and Linux are going to overflow their clocks and wind up showing that the time is somewhere way in the past. It's a good ways off, though, and I doubt many 32 bit systems will still be in operation.
For more, you can check out the Wikipedia article at http://en.wikipedia.org/wiki/Year_2038_problem

I would investigate this line:
usb 7-2: Ignoring serial port reserved for JTAG

There's probably some new method for accessing JTAG that was added in the new kernel or something. It knows it's there, it just won't use it as a serial console.

EDIT:
A quick google shows that if you really want to access JTAG, you should investigate openocd. The serial driver was revised so it doesn't treat JTAG interfaces as serial consoles.

This is true. I asked out of curiosity after I found out about the 2038 problem. I highly doubt my Sheevaplug will still be operational by then, but if it is, I'll have problems.
I'm not really worried about it. 

The comments on this forum aren't relevant to you because we ordered while a backorder notice was in place and you didn't. If they deliberately removed it, they must think that the massive delays they experienced before are coming to a close. I highly doubt that they would remove the backorder notice and still have a massive delay.
Have you emailed their sales department to see when they expect it to ship? I would expect that it may take a week or two, but I doubt you'll experience the month or two month delays that we saw.