If I interrupt cdrecord before the kernel panic but after the interrupt message,
I get the kernel panic anyway. This time I got it with following stack:
update_process_times, run_timer_list, bh_action, tasklet_hi_action, do_softirq,
do_IRQ, call_do_IRQ, pci_conf1_read, default_idle, apm_cpu_idle, default_idle,
stext, cpu_idle

I am assuming you run it from text console, and not X11 window,
because this is how we can see messages.
When it hangs, does <CapsLock> switch LEDs? If yes, please, try to
hit <Alt><SysRq>"T" and let me know if stack trace is dumped.
If keyboard is dead, please add "nmi_watchdog=1" to your grub.conf
arguments where root=LABEL=/ sits, and retry the test. It might
convert a hang to oops, which may be possible to debug. A blind hang
is hopeless.

Pawel, I would you to try Fedora's kernel 2.4.22-1.2140 (or later).
It has a fix for such problem. If you're still on RHL 9, just install
the rpm, it is pretty much compatible (minus external modules).
Please let me know the status.

It does not hang any more - which is a great success! - but the
recorder still does not function. Info about interrupts is still being
printed (I do not know whether it is relevant or not but I thought I
would mention it).
usb-uhci.c: interrupt, status 3, frame# 1156
usb-uhci.c: interrupt, status 3, frame# 1144
System info:
2.4.22-1.2140.nptlsmp #1 SMP Tue Jan 6 20:11:24 EST 2004 i686 i686
i386 GNU/Linux

Something is very fishy. The Mitsumi with 8020 protocol is one of
the oldest, well understood devices. It must just work.
At this point, I am willing to entertain wild theories, such as
BIOS interfering by emulating PS/2. Is it possible to plug the thing
into the another UHCI? Two connectors together are fed from the same
controllers, but there must be a header or a front connector...
Another good thing to try would be to run a stock 2.4 kernel or
2.6 kernel and see if one of them works.