IT WORKED! I fixed it in this way:
mpu401_uart.c:229
if (mpu->hardware != MPU401_HW_TRID4DWAVE && mpu->hardware != MPU401_HW_ICE1712) { mpu->write(mpu, 0x00, MPU401D(mpu)); /*snd_mpu401_uart_clear_rx(mpu);*/ }
I don't know if this will work on non-AMD machines and if it will work on all ice1712 machines... Next week I can test it with different M-Audio cards on single-processor machines (Pentium and AMD).
Thanks a lot! Florian
On 4/24/2007 5:04 PM, Takashi Iwai wrote:
At Tue, 24 Apr 2007 16:53:20 +0200, Florian wrote:
When the hang-up occurs at the first write, it must be in snd_mpu401_uart_cmd(). At the very beginning, it calls mpu->write(mpu, 0x00, MPU401D(mpu)); Try to comment out this and see what happens.
I had tried that - I think that I just commented out the reset command.
The reset command contains a series of writes. The write access (zero to 0x304c) is the very first part, and this isn't always necessary. For example, trident doesn't like this sequence. So, just commenting out this write should be fairly harmless to the later behavior.
So, commenting only the first zero write is worth to try (if you didn't do yet).
It would not crash or reboot, but it did not haver functionality either.
Do I understand correctly that this bug happens when you open a rawmidi device for read, e.g. % cat /dev/snd/midiC0D0 > /dev/null
yes. I usually used amidi -p hw:0 -d
Perhaps an easiest but foolishest way to trace this is to put printk at each io-port access and any other important points, and give some sleep at each point, then watch the kernel message. You can get rid of spin_lock_*() around that, just for testing.
I've done this until I traced it to the first outb() call, i.e. the initialization mentioned above. The first outb() will cause the reboot.
And this causes an immediate reboot, not panic or oops, right? You shouldn't do this kind of debug on X but on VGA console, BTW.
Takashi