From: Jonathan W. <jw...@ph...> - 2007-10-22 23:43:52
|
> > What's happening on the second log is not a motutest hang. The 8pre seems to > > be in a blocked state and doesn't answer to anything. So motutest can't > > access to it at all. > > The odd thing is that I can't clear whatever is preventing motutest from > accessing the 8pre again by powering the 8pre off and then on again. Now that *is* curious. Power cycling the interface will trigger a bus reset and this should in turn force everything on the bus back into a known default state. The fact that it's only cleared by a reboot suggests that maybe something odd is going on inside Linux's ieee1394 subsystem on your system. Which kernel ieee1394 subsystem are you using - the original one now known as ieee1394 or the newer one known as "firewire" (or "Juju", for some odd reason)? If it's the newer one there may still be some issues. If you didn't configure/compile your kernel you might not know this. If not, just send me the output of the "lsmod" command and hopefully it'll be evident from that. For example, do lsmod > lsmod.log and email me the lsmod.log file. I ask this because some distros are now shipping with the new kernel firewire stack enabled even though there are still issues with it. > > Does the 8pre switch to 48kHz if it was set to something else before running > > motutest? > > It does not. I ran one test with the 8pre set to 44.1k and it did not > reset to 48k. Ok, so the 8pre's clock control register is not the same as the Traveler/828. That's progress of sorts. Regards jonathan |