As you may have guessed from the tracebacks, this is not an
altix specific problem.
I installed a tiger SDV in the lab to RHEL4 0907, then put the 549
kernel on the system. Once I did that, I just mounted and unmounted
a cdrom a few times and got a similar traceback. This system didn't
have a serial console but it looks very similar.
I'm going to unassign this - not because I'm not interested or don't
want to help, but because I'm probably not the best person to look at
this. If someone more experienced in this area doens't want to look,
I can take it back and try to fumble my way through it.
I wanted to at least test to be sure it affected more than just
Altix.

At first glance: in a couple of cases we've got a buffer_head data
struct going haywire and oopsing processes which access it. In one
other, it's an skbuf.
That could be _anything_. Have you been trying other kernels on the
same box with the same tests? Which was the last one to run correctly?

So I tried this test on ia32. I installed a ia32 box in Boston
(tiamat) to RHEL4 re0909 nightly. Then I put the 549 arjan kernel
on it.
I mounted the cdrom. When I unmounted, the system hung. The graphics
console said (no serial console, so this is by hand the best I can):
spin_is_locked on unitilized spinlock 11fd9818
A bunch of these spew. Line numbers 165 and 167 of transaction.c
are referenced and the system is generally hung at this point.
Switching to another vc and typing something just results in
more spinlock messages. I'm guessing this is the same issue but
it sure has a different failure mode (?). Thoughts? I'll do a
new bug search shortly I guess.

In my add above, I mentioned transaction.c line numbers 165 and
167 were called out. I re-checked my hand-written notes. It's
165 and 177. This makes more sense - the two lines are spin_lock
and spin_unlock lines.

Since I see a failure in the same situation on x86, I've decided to
adjust the summary slightly and mark it for all platforms.
The way to induce the problem is the same but what happens to the
system is different. I think it's likely related.

Umm, now I'm confused.
The first report here was in the middle of a wget(1), with no mention
of CD at all.
Now we've got a set of CD reports, involving ext3, with no backtraces.
Are you telling us that the initial one was involving CD too? And is
it really an ext3 CD (!), or what?
#132152 looks completely unrelated at first glance.
Given that this is reproducible, please try to hook up a serial
console and capture a trace.

Good point - sorry about that. Mounting/unmounting the CD is the only
way I can make the problem happen easily. You're right that the
wget was the frist way I hit the problem. Maybe I shouldn't have
changed the subject like that.
For the ia32 box, there isn't a backtrace - it hangs forever with
spinlock messages. If you're sure that's a separate issue, we can
file a different bug on it. But since the trigger is the same, I
was thinking they could be related. Do you want me to force a
backtrace using magic sys req?
For ia64, I've included several backtrace attachments.

Again, what sort of fs is on the CD?
And yes, for hangs, the more information the better: at a very
minimum, alt-sysrq-t and -p will help. If you have time to get at it
with kdb, then sure, the more information you can capture the better.