From: Justin M. S. <str...@cl...> - 2007-11-03 19:36:27
|
Sorry for the extended absence - I had a recording gig come up that I had to get turned around pretty quickly. > There seems to be something very odd going on with the iso streaming here. > The "cycle too long" messages cannot be due to anything in the motutest iso > handlers because they were not active in the modified version. The "cycle > too long" messages are emitted by the kernel when too much time elapses > between the reception of "cycle start" packets (they essentially come from > the OHCI hardware via an interrupt). If this is to be believed it would > indicate that whichever node has become the IRM (Isosynchronous Resource > Manager) on the firewire bus is not doing its job and is not broadcasting > cycle start packets. Precisely why this would be happening is not clear to > me. All the other MOTU interfaces are IRM-capable, become the IRM during > bus arbitration and transmit cycle-start as required by the standard, so its > hard to see why things would be any different for the 8pre. > > Without a sniffer it's difficult to prove that this is what is happening > because the cycle-start packets are async packets. However, it would be > helpful if you could fire up gscanbus, select the MOTU interface and see if > "IRM-capable" is mentioned anywhere in the device's capabilities. gscanbus output follows. I don't see any mention of IRM anywhere. SelfID Info ----------- Physical ID: 0 Link active: Yes Gap Count: 63 PHY Speed: S400 PHY Delay: <=144ns IRM Capable: No Power Class: -1W Port 0: Connected to parent node Port 1: Not connected Init. reset: No CSR ROM Info ------------ GUID: 0x0001F2000007E919 Node Capabilities: 0x000083C0 Vendor ID: 0x000001F2 Unit Spec ID: 0x000001F2 Unit SW Version: 0x0000000F Model ID: 0x00100800 Nr. Textual Leafes: 0 Vendor: Unknown Textual Leafes: AV/C Subunits ------------- N/A > What firewire card are you using for these tests again? This is the built-in Firewire 400 port on my Dell Latitude D820 laptop. lspci doesn't have much to say about it... 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Unknown device 00f7 (rev 02) > I'm also at a loss to explain how the 8pre's iso output is turned off when > the write to the iso control register is flagged as failing. > > Ok, here's another test. Take the modified motutest source and find the > lines which start with > > motufw_reg_write(motus, 0x0b00, ... > > These are the writes to the streaming control register. There should be two > relevant calls - one before the usleep(100000) call, and one after. Comment > these two out, recompile and rerun motutest. Use dumpiso to see if any iso > data is dumped while this new motutest variant is running. Done. The dumpiso log is here: http://www.cluebyfour.org/downloads/20071103/dumpiso-20071103.log.bz2 jms |