Thread: fw1 not created for dv-camera
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-user
|
From: René F. <re...@co...> - 2011-07-30 17:30:26
|
Hi My mini-dv camcorder is not detected. The same hardware once worked, I guess with ohci1394 but I can't say definitely. I have a firewire scanner which works fine, but the camcorder not. I already searched the web for a solution but couldn't find one. At least none that helped me. As I understand the problem is that the device /dev/fw1 will no be created due to some problems I don't understand :-) Any help is much appreciated René Here are the facts: kubuntu 11.04 natty kernel 2.6.38-11 and I tried 3.0.0 too camcoder Grundig Scenos (old one but works fine for me :-) # lspci | grep 1394 03:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) (onboard controller) # lsmod | grep firewire firewire_sbp2 23099 0 firewire_ohci 40832 0 firewire_core 64614 2 firewire_sbp2,firewire_ohci crc_itu_t 12707 1 firewire_core # ls /dev/fw* /dev/fw0 # dmesg (with debug=7) [12018.315369] firewire_ohci: IRQ 00000010 AR_req [12018.315387] firewire_ohci: AR evt_bus_reset, generation 20 [12018.315535] firewire_ohci: IRQ 00010000 selfID [12018.315558] firewire_ohci: 2 selfIDs, generation 20, local node ID ffc1 [12018.315566] firewire_ohci: selfID 0: 807f0880, phy 0 [p..] S100 gc=63 +0W Lc [12018.315574] firewire_ohci: selfID 0: 817f8cd6, phy 1 [c--] S400 gc=63 -3W Lci [12018.315636] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 [12018.315660] firewire_ohci: IRQ 00000001 AT_req [12018.315669] firewire_ohci: AT ack_complete, PHY 01c50000 fe3affff [12018.315694] firewire_ohci: IRQ 00000010 AR_req [12018.315700] firewire_ohci: AR evt_bus_reset, generation 21 [12018.315705] firewire_ohci: AR evt_bus_reset, generation 21 [12018.315867] firewire_ohci: IRQ 00010000 selfID [12018.315886] firewire_ohci: 2 selfIDs, generation 22, local node ID ffc1 [12018.315892] firewire_ohci: selfID 0: 80450880, phy 0 [p..] S100 gc=5 +0W Lc [12018.315899] firewire_ohci: selfID 0: 81458cd6, phy 1 [c--] S400 gc=5 -3W Lci [12018.315904] firewire_core: skipped bus generations, destroying all nodes [12018.810031] firewire_core: giving up on config rom for node id ffc0 [12018.810060] firewire_core: rediscovered device fw0 [12018.810081] firewire_ohci: IRQ 00000001 AT_req [12018.810088] firewire_ohci: AT spd 0 tl 3c, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 [12018.814386] firewire_ohci: IRQ 00000020 AR_resp [12018.814392] firewire_ohci: AR spd 0 tl 3c, ffc0 -> ffc1, ack_complete, QR resp = 040fa4df [12018.814506] firewire_ohci: IRQ 00000001 AT_req [12018.814511] firewire_ohci: AT spd 0 tl 3f, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 [12021.820107] firewire_ohci: IRQ 00000001 AT_req [12021.820125] firewire_ohci: AT spd 0 tl 00, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 [12021.823489] firewire_ohci: IRQ 00000020 AR_resp [12021.823503] firewire_ohci: AR spd 0 tl 00, ffc0 -> ffc1, ack_complete, QR resp = 040fa4df [12021.823637] firewire_ohci: IRQ 00000001 AT_req [12021.823646] firewire_ohci: AT spd 0 tl 01, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 [12024.830097] firewire_ohci: IRQ 00000001 AT_req [12024.830116] firewire_ohci: AT spd 0 tl 02, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 and so on |
|
From: Stefan R. <st...@s5...> - 2011-07-31 10:52:28
|
On Jul 30 René Fritz wrote: > Hi > > My mini-dv camcorder is not detected. > > The same hardware once worked, I guess with ohci1394 but I can't say > definitely. I have a firewire scanner which works fine, but the camcorder not. > > I already searched the web for a solution but couldn't find one. At least none > that helped me. > > As I understand the problem is that the device /dev/fw1 will no be created due > to some problems I don't understand :-) > > Any help is much appreciated > René > > > > Here are the facts: > > kubuntu 11.04 natty > kernel 2.6.38-11 and I tried 3.0.0 too > > camcoder Grundig Scenos (old one but works fine for me :-) > > > # lspci | grep 1394 > 03:0e.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 > Controller (PHY/Link) > > (onboard controller) > > > # lsmod | grep firewire > firewire_sbp2 23099 0 > firewire_ohci 40832 0 > firewire_core 64614 2 firewire_sbp2,firewire_ohci > crc_itu_t 12707 1 firewire_core > > > # ls /dev/fw* > /dev/fw0 > > > # dmesg (with debug=7) > [12018.315369] firewire_ohci: IRQ 00000010 AR_req > [12018.315387] firewire_ohci: AR evt_bus_reset, generation 20 > [12018.315535] firewire_ohci: IRQ 00010000 selfID > [12018.315558] firewire_ohci: 2 selfIDs, generation 20, local node ID ffc1 > [12018.315566] firewire_ohci: selfID 0: 807f0880, phy 0 [p..] S100 gc=63 +0W Lc > [12018.315574] firewire_ohci: selfID 0: 817f8cd6, phy 1 [c--] S400 gc=63 -3W Lci > [12018.315636] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 > [12018.315660] firewire_ohci: IRQ 00000001 AT_req > [12018.315669] firewire_ohci: AT ack_complete, PHY 01c50000 fe3affff > [12018.315694] firewire_ohci: IRQ 00000010 AR_req > [12018.315700] firewire_ohci: AR evt_bus_reset, generation 21 > [12018.315705] firewire_ohci: AR evt_bus_reset, generation 21 > [12018.315867] firewire_ohci: IRQ 00010000 selfID > [12018.315886] firewire_ohci: 2 selfIDs, generation 22, local node ID ffc1 > [12018.315892] firewire_ohci: selfID 0: 80450880, phy 0 [p..] S100 gc=5 +0W Lc > [12018.315899] firewire_ohci: selfID 0: 81458cd6, phy 1 [c--] S400 gc=5 -3W Lci > [12018.315904] firewire_core: skipped bus generations, destroying all nodes > [12018.810031] firewire_core: giving up on config rom for node id ffc0 > [12018.810060] firewire_core: rediscovered device fw0 > [12018.810081] firewire_ohci: IRQ 00000001 AT_req > [12018.810088] firewire_ohci: AT spd 0 tl 3c, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 > [12018.814386] firewire_ohci: IRQ 00000020 AR_resp > [12018.814392] firewire_ohci: AR spd 0 tl 3c, ffc0 -> ffc1, ack_complete, QR resp = 040fa4df > [12018.814506] firewire_ohci: IRQ 00000001 AT_req > [12018.814511] firewire_ohci: AT spd 0 tl 3f, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 > [12021.820107] firewire_ohci: IRQ 00000001 AT_req > [12021.820125] firewire_ohci: AT spd 0 tl 00, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 > [12021.823489] firewire_ohci: IRQ 00000020 AR_resp > [12021.823503] firewire_ohci: AR spd 0 tl 00, ffc0 -> ffc1, ack_complete, QR resp = 040fa4df > [12021.823637] firewire_ohci: IRQ 00000001 AT_req > [12021.823646] firewire_ohci: AT spd 0 tl 01, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 > [12024.830097] firewire_ohci: IRQ 00000001 AT_req > [12024.830116] firewire_ohci: AT spd 0 tl 02, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 > > and so on This is almost exactly the same behavior that Thomas (Cc'd) reported in "Panasonic AG-EZ30 - camera can't connect". http://thread.gmane.org/gmane.linux.kernel.firewire.user/4306 Differences between these two reports, besides Panasonic vs. Grundig (they may use the same interface hardware internally) is that Thomas has a NEC controller vs. your Texas Instruments controller, and that Thomas' camcorder is known to work on a Mac while yours worked a time ago with an older Linux distribution. The two reports taken together indicate that aged hardware is not the problem here, or at least not the primary problem. Rather we are apparently facing a device hardware/firmware quirk here with which our current drivers deal worse than other OSs or even our older drivers. René and Thomas, please test the following: - Unload the OHCI-1394 driver: modprobe -r firewire-ohci; lsmod | grep fire - Plug in and switch on the camcorder. - Reload the driver: modprobe firewire-ohci debug=7 Then post the output of dmesg or contents of /var/log/kern.log starting from the point where you unloaded the driver. Please try the above with the camcorder in recorder mode and also in player mode. Also, would you be willing to take the time to compile a modified kernel? In http://thread.gmane.org/gmane.linux.kernel.firewire.user/4306/focus=4313 I suggested: - Change firewire-ohci's maxATReqRetries setting from the current maximum possible value to something less. This is unlikely to help. firewire-ohci currently uses the same parameters there as ohci1394 has been using for years. - Disable firewire-core's bus management. This could have an effect. The ieee1394 driver had different bus management with fewer features than firewire-core, notably no gap count optimization. - Insert a small pause between reception of quadlet response and transmission of the next quadlet request in firewire-core's reading of the Configuraton ROM. Might not help; ieee1394 also used to send those quadlet requests as soon as it could. The following steps are involved: - Get the kernel sources, either from a source package of your distribution or from kernel.org. - Copy the configuration of the current kernel into the base directory of the kernel sources. The existing configuration file is typically named /boot/config-2.6.38* or similar. It needs to be copied to e.g. "/usr/src/linux-2.6.38/.config" or wherever the linux sources were unpacked. - Optionally, run the kernel configurator in order to disable all drivers that you are sure that you don't need. cd /usr/src/linux-2.6.38 # or wherever make xconfig # or make menuconfig - Build the kernel and kernel modules: nice make -j4 The number after j should be the same as the number of CPU cores, or one or two more, in order to utilize your CPU resources fully. This is because the first time that you compile the kernel is going to take very long. The "nice" in front of make lets you continue to use the PC while it compiles without much impact on interactive usage. - Build the initrd. For this step, please look for documentation that is specific to your distribution. I have not used distributor kernels for many years myself, and always configured my kernels such that they can boot without an initrd. - Install kernel, modules, and initrd. Configure the boot manager such that it offers a menu at boot that lets you choose between your own kernel and the existing distributor kernel. Again, look for distribution specific documentation on this step. - Reboot into the new, self built kernel. After that, you can modify firewire driver sources according to directions that I would give you, or apply patches that I would send you. After such a modification, you can rebuild and install the firewire modules in less than a minute (the rest of the kernel won't be rebuilt), unload the unmodified modules and load the modified modules. -- Stefan Richter -=====-==-== -=== ===== http://arcgraph.de/sr/ |
|
From: René F. <re...@co...> - 2011-08-03 08:37:54
|
Hi Stefan Currently a kernel is compiling, so it seems I'm able to test patches. I had a quick look in the sources and gave up after a few seconds. :-) So what now? René Am Sonntag, 31. Juli 2011, 12:51:56 schrieben Sie: > Also, would you be willing to take the time to compile a > modified kernel? In > http://thread.gmane.org/gmane.linux.kernel.firewire.user/4306/focus=4313 > I suggested: > > - Change firewire-ohci's maxATReqRetries setting from the current > maximum possible value to something less. > > This is unlikely to help. firewire-ohci currently uses the same > parameters there as ohci1394 has been using for years. > > - Disable firewire-core's bus management. > > This could have an effect. The ieee1394 driver had different bus > management with fewer features than firewire-core, notably no gap count > optimization. > > - Insert a small pause between reception of quadlet response and > transmission of the next quadlet request in firewire-core's reading of > the Configuraton ROM. |
|
From: Stefan R. <st...@s5...> - 2011-08-03 11:37:42
|
On Aug 03 René Fritz wrote: > Currently a kernel is compiling, so it seems I'm able to test patches. > > I had a quick look in the sources and gave up after a few seconds. :-) > So what now? Tell me the exact version of the kernel sources from which you build, and I can prepare patches for you. I expect a Panasonic NV-DX110 to arrive in my mail this week. This device is from the looks and feature set the same as Panasonic AG-EZ30. Besides under Linux, I will be able to test it on OS X and Windows XP. I may also be able to capture traffic between those other OSs and the camcorder by means of a PCILynx card and Linux' FireWire packet sniffer "nosy". -- Stefan Richter -=====-==-== =--- ---== http://arcgraph.de/sr/ |
|
From: <re...@co...> - 2011-08-03 11:55:24
|
> Tell me the exact version of the kernel sources from which you build, and > I can prepare patches for you. Kubuntu Natty 2.6.38-11-generic amd64 build from the deb source package - which actually fetches the source from ubuntu git btw: I plan to insert the build modules with insmod and not to install the kernel if possible (hadn't time to try that today) René |
|
From: Stefan R. <st...@s5...> - 2011-08-04 19:21:04
|
On Aug 03 Stefan Richter wrote: > I expect a Panasonic NV-DX110 to arrive in my mail this week. This device > is from the looks and feature set the same as Panasonic AG-EZ30. Besides > under Linux, I will be able to test it on OS X and Windows XP. I may > also be able to capture traffic between those other OSs and the camcorder > by means of a PCILynx card and Linux' FireWire packet sniffer "nosy". OK, I've got my hands on an NV-DX110 now. - Kernel 3.0, x86-64, Agere FW643e controller, - kernel 2.6.33 + firewire updates to current master, x86-32, Agere FW323: behave exactly like with René's Grundig Scenos DLC 2000 and Thomas' Panasonic AG-EZ30. There are always ack-busy-x when the second quadlet of the Configuration ROM is attempted to be read: Aug 4 20:28:44 stein kernel: firewire_ohci: IRQ 00010010 selfID AR_req Aug 4 20:28:44 stein kernel: firewire_ohci: AR evt_bus_reset, generation 54 Aug 4 20:28:44 stein kernel: firewire_ohci: 2 selfIDs, generation 54, local node ID ffc1 Aug 4 20:28:44 stein kernel: firewire_ohci: selfID 0: 807f0880, phy 0 [p..] S100 gc=63 +0W Lc Aug 4 20:28:44 stein kernel: firewire_ohci: selfID 0: 817fcc76, phy 1 [-c-] beta gc=63 -3W Lci Aug 4 20:28:44 stein kernel: firewire_core: phy config: card 0, new root=ffc1, gap_count=5 Aug 4 20:28:44 stein kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 20:28:44 stein kernel: firewire_ohci: AT ack_complete, PHY 01c50000 fe3affff Aug 4 20:28:44 stein kernel: firewire_ohci: IRQ 00000010 AR_req Aug 4 20:28:44 stein kernel: firewire_ohci: AR evt_bus_reset, generation 55 Aug 4 20:28:44 stein kernel: firewire_ohci: IRQ 00010000 selfID Aug 4 20:28:44 stein kernel: firewire_ohci: 2 selfIDs, generation 55, local node ID ffc1 Aug 4 20:28:44 stein kernel: firewire_ohci: selfID 0: 80450880, phy 0 [p..] S100 gc=5 +0W Lc Aug 4 20:28:44 stein kernel: firewire_ohci: selfID 0: 8145cc76, phy 1 [-c-] beta gc=5 -3W Lci Aug 4 20:28:44 stein kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 20:28:44 stein kernel: firewire_ohci: AT spd 0 tl 00, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Aug 4 20:28:44 stein kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 20:28:44 stein kernel: firewire_ohci: AR spd 0 tl 00, ffc0 -> ffc1, ack_complete, QR resp = 040fc824 Aug 4 20:28:44 stein kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 20:28:44 stein kernel: firewire_ohci: AT spd 0 tl 01, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 [...] Aug 4 20:29:14 stein kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 20:29:14 stein kernel: firewire_ohci: AT spd 0 tl 14, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Aug 4 20:29:14 stein kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 20:29:14 stein kernel: firewire_ohci: AR spd 0 tl 14, ffc0 -> ffc1, ack_complete, QR resp = 040fc824 Aug 4 20:29:14 stein kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 20:29:14 stein kernel: firewire_ohci: AT spd 0 tl 15, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 Aug 4 20:29:14 stein kernel: firewire_core: giving up on config rom for node id ffc0 Next test: - Kernel 2.6.33 ohci1394 + ieee1394 + raw1394, x86-32, Agere FW 323, everything works fine. Aug 4 20:34:40 mini kernel: ohci1394 0000:03:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 Aug 4 20:34:40 mini kernel: ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[90000000-900007ff] Max Packet=[2048] IR/IT contexts=[8/8] Aug 4 20:34:42 mini kernel: ieee1394: Host added: ID:BUS[0-01:1023] GUID[0017f2fffe66fb80] Aug 4 20:34:49 mini kernel: ieee1394: raw1394: /dev/raw1394 device initialized Aug 4 20:35:00 mini kernel: ieee1394: Node added: ID:BUS[0-00:1023] GUID[008045801086917b] Aug 4 20:35:00 mini kernel: ieee1394: Node changed: 0-01:1023 -> 0-02:1023 From there on, gscanbus and kino are able to access the camcorder, and kino shows the live preview in its capture pane. (On the node IDs in the mini log: There is a third node on mini's bus, a 1394a 6-port hub. This doesn't matter for the failure mode with firewire-ohci and firewire-core.) (Unrelated observation: These three 1/4" sensors in the NV-DX110 are a whole different ballgame from the extremely noisy single 1/6" sensor that is in my other two toy camcorders, or the single 1/4" sensor of the Apple iSight or of the Unibrain Fire-i.) Conclusion: This is a regression of the firewire driver stack relative to the ieee1394 driver stack. Now we just need to find out how to make it work with the newer drivers like it did with the older ones. Another quick test: Back on stein with kernel 3.0, Agere FW643e and firewire-core/ohci but now with a 1394b 3port hub between card and camcorder the failure is again the same as before. I added this 1394b hub as a lazy trick to disable gap count optimization: Aug 4 21:08:18 stein kernel: firewire_ohci: IRQ 00010010 selfID AR_req Aug 4 21:08:18 stein kernel: firewire_ohci: AR evt_bus_reset, generation 59 Aug 4 21:08:18 stein kernel: firewire_ohci: 3 selfIDs, generation 59, local node ID ffc2 Aug 4 21:08:18 stein kernel: firewire_ohci: selfID 0: 807f0880, phy 0 [p..] S100 gc=63 +0W Lc Aug 4 21:08:18 stein kernel: firewire_ohci: selfID 0: 813fc478, phy 1 [-cp] beta gc=63 -3W Aug 4 21:08:18 stein kernel: firewire_ohci: selfID 0: 827fcc74, phy 2 [-c-] beta gc=63 -3W Lc Aug 4 21:08:18 stein kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 21:08:18 stein kernel: firewire_ohci: AT spd 0 tl 37, ffc2 -> ffc0, ack_pending , QR req, fffff0000400 Aug 4 21:08:18 stein kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 21:08:18 stein kernel: firewire_ohci: AR spd 0 tl 37, ffc0 -> ffc2, ack_complete, QR resp = 040fc824 Aug 4 21:08:18 stein kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 21:08:18 stein kernel: firewire_ohci: AT spd 0 tl 38, ffc2 -> ffc0, ack_busy_X, QR req, fffff0000404 [...] Aug 4 21:08:49 stein kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 21:08:49 stein kernel: firewire_ohci: AT spd 0 tl 0b, ffc2 -> ffc0, ack_pending , QR req, fffff0000400 Aug 4 21:08:49 stein kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 21:08:49 stein kernel: firewire_ohci: AR spd 0 tl 0b, ffc0 -> ffc2, ack_complete, QR resp = 040fc824 Aug 4 21:08:49 stein kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 21:08:49 stein kernel: firewire_ohci: AT spd 0 tl 0c, ffc2 -> ffc0, ack_busy_X, QR req, fffff0000404 Aug 4 21:08:49 stein kernel: firewire_core: giving up on config rom for node id ffc0 So, gap count 5 or 7 or 63 don't matter to the issue here. ieee1394 always leaves the gap count unmodified. gscanbus confirms a gap count of 63 if the Linux node is root node from the beginning, and 44 if the camcorder starts out as root node. ieee1394 forces itself to become root node then because the camcorder's IRM is not 1394a compliant, but that single bus reset still leaves the gap count at 44. ieee1394's bus reset to force a 1394a IRM does not break accessibility of the camcorder. This means that the equivalent routine in firewire-core is not the culprit either. -- Stefan Richter -=====-==-== =--- --=-- http://arcgraph.de/sr/ |
|
From: Stefan R. <st...@s5...> - 2011-08-04 19:47:09
|
On Aug 04 Stefan Richter wrote: > OK, I've got my hands on an NV-DX110 now. > > - Kernel 3.0, x86-64, Agere FW643e controller, > - kernel 2.6.33 + firewire updates to current master, x86-32, Agere FW323: > > behave exactly like with René's Grundig Scenos DLC 2000 and Thomas' > Panasonic AG-EZ30. There are always ack-busy-x when the second quadlet > of the Configuration ROM is attempted to be read: Same with kernel 2.6.33.14 and its original firewire-core/-ohci drivers. Another observation: As expected, the PHY vendor/model IDs of the camcorder cannot be queried by Clemens' lsfirewirephy. This PHY is a 1394-1995 one which does not implement remote access/reply PHY packets. -- Stefan Richter -=====-==-== =--- --=-- http://arcgraph.de/sr/ |
|
From: Stefan R. <st...@s5...> - 2011-08-04 21:25:28
|
The following simple modification helps somewhat: --- a/drivers/firewire/core-device.c +++ b/drivers/firewire/core-device.c @@ -432,6 +432,8 @@ static int read_rom(struct fw_device *de /* device->node_id, accessed below, must not be older than generation */ smp_rmb(); + msleep(10); + rcode = fw_run_transaction(device->card, TCODE_READ_QUADLET_REQUEST, device->node_id, generation, device->max_speed, (CSR_REGISTER_BASE | CSR_CONFIG_ROM) + index * 4, Aug 4 23:05:57 mini kernel: firewire_ohci: IRQ 00000010 AR_req Aug 4 23:05:57 mini kernel: firewire_ohci: AR evt_bus_reset, generation 22 Aug 4 23:05:57 mini kernel: firewire_ohci: IRQ 00010000 selfID Aug 4 23:05:57 mini kernel: firewire_ohci: 4 selfIDs, generation 22, local node ID ffc2 Aug 4 23:05:57 mini kernel: firewire_ohci: selfID 0: 807f0880, phy 0 [p..] S100 gc=63 +0W Lc Aug 4 23:05:57 mini kernel: firewire_ohci: selfID 0: 813f8465, phy 1 [-p-] S400 gc=63 -3W Aug 4 23:05:57 mini kernel: firewire_ohci: selfID n: 8181d000, phy 1 [-c-.....] Aug 4 23:05:57 mini kernel: firewire_ohci: selfID 0: 827f88d4, phy 2 [c--] S400 gc=63 +0W Lc Aug 4 23:05:57 mini kernel: firewire_core: phy config: card 0, new root=ffc2, gap_count=7 Aug 4 23:05:57 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:05:57 mini kernel: firewire_ohci: AT ack_complete, phy config packet, 02c70000 Aug 4 23:05:57 mini kernel: firewire_ohci: IRQ 00000010 AR_req Aug 4 23:05:57 mini kernel: firewire_ohci: AR evt_bus_reset, generation 23 Aug 4 23:05:57 mini kernel: firewire_ohci: AR evt_bus_reset, generation 24 Aug 4 23:05:57 mini kernel: firewire_ohci: IRQ 00010000 selfID Aug 4 23:05:57 mini kernel: firewire_ohci: 4 selfIDs, generation 24, local node ID ffc2 Aug 4 23:05:57 mini kernel: firewire_ohci: selfID 0: 80470880, phy 0 [p..] S100 gc=7 +0W Lc Aug 4 23:05:57 mini kernel: firewire_ohci: selfID 0: 81078465, phy 1 [-p-] S400 gc=7 -3W Aug 4 23:05:57 mini kernel: firewire_ohci: selfID n: 8181d000, phy 1 [-c-.....] Aug 4 23:05:57 mini kernel: firewire_ohci: selfID 0: 824788d4, phy 2 [c--] S400 gc=7 +0W Lc Aug 4 23:05:57 mini kernel: firewire_core: skipped bus generations, destroying all nodes Aug 4 23:05:57 mini kernel: firewire_core: giving up on config rom for node id ffc0 Aug 4 23:05:57 mini kernel: firewire_core: rediscovered device fw0 Aug 4 23:05:57 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:05:57 mini kernel: firewire_ohci: AT spd 0 tl 1b, ffc2 -> ffc0, ack_pending , QR req, fffff0000400 Aug 4 23:05:57 mini kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 23:05:57 mini kernel: firewire_ohci: AR spd 0 tl 1b, ffc0 -> ffc2, ack_complete, QR resp = 040fc824 Aug 4 23:05:57 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:05:57 mini kernel: firewire_ohci: AT spd 0 tl 1c, ffc2 -> ffc0, ack_busy_X, QR req, fffff0000404 Aug 4 23:06:00 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:06:00 mini kernel: firewire_ohci: AT spd 0 tl 1f, ffc2 -> ffc0, ack_pending , QR req, fffff0000400 Aug 4 23:06:00 mini kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 23:06:00 mini kernel: firewire_ohci: AR spd 0 tl 1f, ffc0 -> ffc2, ack_complete, QR resp = 040fc824 Aug 4 23:06:00 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:06:00 mini kernel: firewire_ohci: AT spd 0 tl 20, ffc2 -> ffc0, ack_busy_X, QR req, fffff0000404 Aug 4 23:06:03 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:06:03 mini kernel: firewire_ohci: AT spd 0 tl 21, ffc2 -> ffc0, ack_pending , QR req, fffff0000400 Aug 4 23:06:03 mini kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 23:06:03 mini kernel: firewire_ohci: AR spd 0 tl 21, ffc0 -> ffc2, ack_complete, QR resp = 040fc824 Aug 4 23:06:03 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:06:03 mini kernel: firewire_ohci: AT spd 0 tl 22, ffc2 -> ffc0, ack_pending , QR req, fffff0000404 Aug 4 23:06:03 mini kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 23:06:03 mini kernel: firewire_ohci: AR spd 0 tl 22, ffc0 -> ffc2, ack_complete, QR resp = 31333934 Aug 4 23:06:03 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:06:03 mini kernel: firewire_ohci: AT spd 0 tl 23, ffc2 -> ffc0, ack_pending , QR req, fffff0000408 Aug 4 23:06:03 mini kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 23:06:03 mini kernel: firewire_ohci: AR spd 0 tl 23, ffc0 -> ffc2, ack_complete, QR resp = e0643000 Aug 4 23:06:03 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:06:03 mini kernel: firewire_ohci: AT spd 0 tl 24, ffc2 -> ffc0, ack_pending , QR req, fffff000040c Aug 4 23:06:04 mini kernel: firewire_ohci: IRQ 00000020 AR_resp [...] Aug 4 23:06:04 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:06:04 mini kernel: firewire_ohci: AT spd 0 tl 2f, ffc2 -> ffc0, ack_pending , QR req, fffff0000438 Aug 4 23:06:04 mini kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 23:06:04 mini kernel: firewire_ohci: AR spd 0 tl 2f, ffc0 -> ffc2, ack_complete, QR resp = 00804580 Aug 4 23:06:04 mini kernel: firewire_ohci: IRQ 00000001 AT_req Aug 4 23:06:04 mini kernel: firewire_ohci: AT spd 0 tl 30, ffc2 -> ffc0, ack_pending , QR req, fffff000043c Aug 4 23:06:04 mini kernel: firewire_ohci: IRQ 00000020 AR_resp Aug 4 23:06:04 mini kernel: firewire_ohci: AR spd 0 tl 30, ffc0 -> ffc2, ack_complete, QR resp = 1086917b Aug 4 23:06:04 mini kernel: firewire_core: created device fw1: GUID 008045801086917b, S100, 2 config ROM retries After that, kino shows video from the camcorder in the capture pane. But it is unable to determine the status of the camcorder due to many I/O errors of the sort of rom1394_2 warning: read failed: 0x0000fffff0000414 (and at other offsets). he kernel logs these as ack_busy_X failures again. Kino's status bar at the bottom shows "No AV/C compliant cam connected or not switched on?" With ohci1394 + ieee1394 + raw1394, there are a few of such I/O failures in Kino too (also "AVC status error" now and then), but they happen at a far lower frequency. The stats bar generally shows "AV/C Controls Enabled". I need to have a closer look at firewire-ohci vs. ohci1394, whether there are any differences WRT busy-retries (I was under the impression there wasn't) or WRT setup of the local PHY as far as it might affect bus arbitration (though firewire-ohci in 2.6.33 does not enable some 1394a stuff as newer versions do). -- Stefan Richter -=====-==-== =--- --=-- http://arcgraph.de/sr/ |
|
From: Stefan R. <st...@s5...> - 2011-07-31 13:08:06
|
On Jul 30 René Fritz wrote: > camcoder Grundig Scenos (old one but works fine for me :-) What is the exact model number? -- Stefan Richter -=====-==-== -=== ===== http://arcgraph.de/sr/ |
|
From: Stefan R. <st...@s5...> - 2011-07-31 23:14:56
|
For the list to know. On Jul 31 René Fritz wrote: > Am Sonntag, 31. Juli 2011, 15:07:21 schrieben Sie: > > What is the exact model number? > > Grundig Scenos DLC 2000 > > "Made in Japan" which could be a hint that it's build by Panasonic although I > couldn't find any resource saying that. But there were Grundig models which > were similar to Panasonic models. On Jul 31 René Fritz wrote: > > - Unload the OHCI-1394 driver: > > modprobe -r firewire-ohci; lsmod | grep fire [...] > > - Plug in and switch on the camcorder. > > - Reload the driver: > > modprobe firewire-ohci debug=7 [...] > Here's the log for player mode: > > [ 2686.634991] firewire_ohci 0000:03:0e.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 > [ 2686.690133] firewire_ohci: Added fw-ohci device 0000:03:0e.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x2 > [ 2686.690183] firewire_ohci: IRQ 00a00000 cycle64Seconds cycleInconsistent > [ 2686.690189] firewire_ohci: isochronous cycle inconsistent > [ 2686.690203] firewire_ohci: IRQ 00000010 AR_req > [ 2686.690211] firewire_ohci: AR evt_bus_reset, generation 1 > [ 2686.690213] firewire_ohci: AR evt_bus_reset, generation 1 > [ 2686.690382] firewire_ohci: IRQ 00010000 selfID > [ 2686.690402] firewire_ohci: 2 selfIDs, generation 2, local node ID ffc0 > [ 2686.690405] firewire_ohci: selfID 0: 806c8c96, phy 0 [p--] S400 gc=44 -3W Lci > [ 2686.690408] firewire_ohci: selfID 0: 816c08c0, phy 1 [c..] S100 gc=44 +0W Lc So in this case, the camcorder starts out as root node (and thereby as IRM node). Interestingly, the two nodes start with gap count 44. The camcorder must have sent a PHY config packet for that before the fw-ohci link was switched on. The IRM in Sony DCR-TRV25 sets a gap count of 44 too. I wonder who chose this, and why. Perhaps somebody at camcorder vendor X chose it as "better as 63 but still safe for every hop count that will presumably ever happen in practice", and then camcorder vendor Y copied it. > [ 2686.950066] firewire_ohci: IRQ 00000021 AR_resp AT_req > [ 2686.950077] firewire_ohci: AR spd 0 tl 00, ffc1 -> ffc0, ack_complete, Lk resp 4,2 > [ 2686.950083] firewire_ohci: AT spd 0 tl 00, ffc0 -> ffc1, pending/cancelled, Lk req, fffff000021c 8,2 Our BM code is able to use the Bus_Manager_ID register at the camcorder. > [ 2687.190181] firewire_core: created device fw0: GUID 00df399600001d7d, S400 > [ 2687.190212] firewire_ohci: IRQ 00000001 AT_req > [ 2687.190221] firewire_ohci: AT spd 0 tl 19, ffc0 -> ffc1, ack_pending , QR req, fffff0000400 > [ 2687.195098] firewire_ohci: IRQ 00000020 AR_resp > [ 2687.195108] firewire_ohci: AR spd 0 tl 19, ffc1 -> ffc0, ack_complete, QR resp = 040fa4df > [ 2687.195473] firewire_ohci: IRQ 00000001 AT_req > [ 2687.195478] firewire_ohci: AT spd 0 tl 1a, ffc0 -> ffc1, ack_busy_X, QR req, fffff0000404 > [ 2690.200073] firewire_ohci: IRQ 00000001 AT_req > [ 2690.200083] firewire_ohci: AT spd 0 tl 1b, ffc0 -> ffc1, ack_pending , QR req, fffff0000400 > [ 2690.203907] firewire_ohci: IRQ 00000020 AR_resp > [ 2690.203916] firewire_ohci: AR spd 0 tl 1b, ffc1 -> ffc0, ack_complete, QR resp = 040fa4df > [ 2690.204287] firewire_ohci: IRQ 00000001 AT_req > [ 2690.204292] firewire_ohci: AT spd 0 tl 1c, ffc0 -> ffc1, ack_busy_X, QR req, fffff0000404 But alas, the Configuration ROM can again not be read. And this is even though the camcorder is root node and had configured the bus by itself, and our BM code has not done anything yet apart from the successful Bus_Manager_ID lock transaction. This may turn out to be a real head-scratcher. > [ 2693.210087] firewire_ohci: IRQ 00000001 AT_req > [ 2693.210097] firewire_ohci: AT spd 0 tl 1d, ffc0 -> ffc1, ack_pending , QR req, fffff0000400 > [ 2693.213794] firewire_ohci: IRQ 00000020 AR_resp > [ 2693.213806] firewire_ohci: AR spd 0 tl 1d, ffc1 -> ffc0, ack_complete, QR resp = 040fa4df > [ 2693.214177] firewire_ohci: IRQ 00000001 AT_req > [ 2693.214184] firewire_ohci: AT spd 0 tl 1e, ffc0 -> ffc1, ack_busy_X, QR req, fffff0000404 [...] > [ 2717.290075] firewire_ohci: IRQ 00000001 AT_req > [ 2717.290086] firewire_ohci: AT spd 0 tl 2d, ffc0 -> ffc1, ack_pending , QR req, fffff0000400 > [ 2717.293690] firewire_ohci: IRQ 00000020 AR_resp > [ 2717.293701] firewire_ohci: AR spd 0 tl 2d, ffc1 -> ffc0, ack_complete, QR resp = 040fa4df > [ 2717.294073] firewire_ohci: IRQ 00000001 AT_req > [ 2717.294079] firewire_ohci: AT spd 0 tl 2e, ffc0 -> ffc1, ack_busy_X, QR req, fffff0000404 > [ 2717.294088] firewire_core: giving up on config rom for node id ffc1 So, probe of the camcorder failed as before. > [ 2717.294095] firewire_core: phy config: card 0, new root=ffc0, gap_count=5 > [ 2717.294113] firewire_ohci: IRQ 00000001 AT_req > [ 2717.294118] firewire_ohci: AT ack_complete, PHY 00c50000 ff3affff Our BM gets into business, sets the optimum gap count, and resets the bus. > [ 2717.294134] firewire_ohci: IRQ 00000010 AR_req > [ 2717.294139] firewire_ohci: AR evt_bus_reset, generation 3 > [ 2717.294141] firewire_ohci: AR evt_bus_reset, generation 3 > [ 2717.294309] firewire_ohci: IRQ 00010000 selfID > [ 2717.294326] firewire_ohci: 2 selfIDs, generation 4, local node ID ffc1 > [ 2717.294330] firewire_ohci: selfID 0: 80450880, phy 0 [p..] S100 gc=5 +0W Lc > [ 2717.294334] firewire_ohci: selfID 0: 81458cd6, phy 1 [c--] S400 gc=5 -3W Lci > [ 2717.294336] firewire_core: skipped bus generations, destroying all nodes While we normally do a 1394a-style arbitrated bus reset here, the camcorder most certainly has a 1394-1995 PHY and hence a long reset is performed. Actually, several resets happen, such that the bus generation increases by more than one. > [ 2717.790055] firewire_core: rediscovered device fw0 This causes firewire-core to probe all nodes again, which of course succeeds in case of the local node, but... > [ 2717.790085] firewire_ohci: IRQ 00000001 AT_req > [ 2717.790092] firewire_ohci: AT spd 0 tl 06, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 > [ 2717.794843] firewire_ohci: IRQ 00000020 AR_resp > [ 2717.794854] firewire_ohci: AR spd 0 tl 06, ffc0 -> ffc1, ack_complete, QR resp = 040fa4df > [ 2717.794976] firewire_ohci: IRQ 00000001 AT_req > [ 2717.794982] firewire_ohci: AT spd 0 tl 09, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 ...does not with the camcorder... [...] > [ 2746.239034] firewire_ohci: IRQ 00200000 cycle64Seconds > [ 2747.890073] firewire_ohci: IRQ 00000001 AT_req > [ 2747.890084] firewire_ohci: AT spd 0 tl 1c, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 > [ 2747.893520] firewire_ohci: IRQ 00000020 AR_resp > [ 2747.893529] firewire_ohci: AR spd 0 tl 1c, ffc0 -> ffc1, ack_complete, QR resp = 040fa4df > [ 2747.893655] firewire_ohci: IRQ 00000001 AT_req > [ 2747.893660] firewire_ohci: AT spd 0 tl 1d, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 > [ 2747.893667] firewire_core: giving up on config rom for node id ffc0 > [ 2810.228003] firewire_ohci: IRQ 00200000 cycle64Seconds ...which again fails exactly in the way it did before. Note, while this Grundig/ Panasonic camcorder set a gap count of 44 like the Sony camcorder does, there is no attempt by the camcorder to revert the gap count of 5 that our BM set afterwards. In contrast, the Sony camcorder would go on to set his gap count and reset the bus, and its IRM and our BM would continue to play that back and forth, never letting the bus settle down. (This was fixed by http://git.kernel.org/linus/10389536742cefbedecb67a5b2906f155cf3a1c3 which in turn regressed with Canon MV5i for which we came up with http://git.kernel.org/linus/6044565af458e7fa6e748bff437ecc49dea88d79 .) So, apart from the gap count 44 similarity between this Grundig camcorder and the Sony one, the Grundig and Sony bugs are disjunct. > and now recorder mode: > > [ 3009.050117] firewire_ohci 0000:03:0e.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 > [ 3009.110128] firewire_ohci: Added fw-ohci device 0000:03:0e.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x2 > [ 3009.110198] firewire_ohci: IRQ 00000010 AR_req > [ 3009.110208] firewire_ohci: AR evt_bus_reset, generation 1 > [ 3009.110211] firewire_ohci: AR evt_bus_reset, generation 1 > [ 3009.110375] firewire_ohci: IRQ 00010000 selfID > [ 3009.110394] firewire_ohci: 2 selfIDs, generation 2, local node ID ffc1 > [ 3009.110398] firewire_ohci: selfID 0: 807f0880, phy 0 [p..] S100 gc=63 +0W Lc > [ 3009.110402] firewire_ohci: selfID 0: 817f8cd6, phy 1 [c--] S400 gc=63 -3W Lci This time, the Linux node happens to start out as root node; and the bus is at the default gap count of 63. > [ 3009.610175] firewire_core: created device fw0: GUID 00df399600001d7d, S400 > [ 3009.610205] firewire_ohci: IRQ 00000001 AT_req > [ 3009.610212] firewire_ohci: AT spd 0 tl 19, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 > [ 3009.610408] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 > [ 3009.610426] firewire_ohci: IRQ 00000001 AT_req > [ 3009.610431] firewire_ohci: AT ack_complete, PHY 01c50000 fe3affff > [ 3009.610445] firewire_ohci: IRQ 00000010 AR_req > [ 3009.610450] firewire_ohci: AR evt_bus_reset, generation 3 > [ 3009.610452] firewire_ohci: AR evt_bus_reset, generation 3 > [ 3009.610623] firewire_ohci: IRQ 00010000 selfID > [ 3009.610638] firewire_ohci: 2 selfIDs, generation 4, local node ID ffc1 > [ 3009.610641] firewire_ohci: selfID 0: 80450880, phy 0 [p..] S100 gc=5 +0W Lc > [ 3009.610643] firewire_ohci: selfID 0: 81458cd6, phy 1 [c--] S400 gc=5 -3W Lci > [ 3009.610645] firewire_core: skipped bus generations, destroying all nodes > [ 3009.710027] firewire_core: giving up on config rom for node id ffc0 > [ 3010.110057] firewire_core: rediscovered device fw0 > [ 3010.110098] firewire_ohci: IRQ 00000001 AT_req > [ 3010.110109] firewire_ohci: AT spd 0 tl 31, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 > [ 3010.114204] firewire_ohci: IRQ 00000020 AR_resp > [ 3010.114216] firewire_ohci: AR spd 0 tl 31, ffc0 -> ffc1, ack_complete, QR resp = 040fa4df > [ 3010.114343] firewire_ohci: IRQ 00000001 AT_req > [ 3010.114350] firewire_ohci: AT spd 0 tl 34, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 [...] > [ 3040.210054] firewire_ohci: IRQ 00000001 AT_req > [ 3040.210064] firewire_ohci: AT spd 0 tl 07, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 > [ 3040.213263] firewire_ohci: IRQ 00000020 AR_resp > [ 3040.213270] firewire_ohci: AR spd 0 tl 07, ffc0 -> ffc1, ack_complete, QR resp = 040fa4df > [ 3040.213474] firewire_ohci: IRQ 00000001 AT_req > [ 3040.213479] firewire_ohci: AT spd 0 tl 08, ffc1 -> ffc0, ack_busy_X, QR req, fffff0000404 > [ 3040.213493] firewire_core: giving up on config rom for node id ffc0 > [ 3080.097782] firewire_ohci: IRQ 00200000 cycle64Seconds The rest is then like in René's first report. So, the first of these two sessions in which the camcorder starts as root and as IRM strongly indicates that it won't help if we just disabled the BM code in firewire-core. Perhaps what we rather need is a different Config ROM fetching strategy; e.g. a little extra delay between response and next request as I mentioned in the other post --- or maybe the camcorder expects us to send block requests instead of quadlet requests. (The spec says quadlet requests /must/ be supported in the Configuration ROM register, but that's just the spec...) -- Stefan Richter -=====-==-== -=== ===== http://arcgraph.de/sr/ |
|
From: Clemens L. <cl...@la...> - 2011-08-01 06:20:47
|
Stefan Richter wrote: > Interestingly, the two nodes start with gap count 44. The camcorder must > have sent a PHY config packet for that before the fw-ohci link was > switched on. The IRM in Sony DCR-TRV25 sets a gap count of 44 too. I > wonder who chose this, and why. Perhaps somebody at camcorder vendor X > chose it as "better as 63 but still safe for every hop count that will > presumably ever happen in practice", The gap count value for the _theoretical_ maximum of 16 hops is 43; probably somebody decided to add one just to be sure (especially after it was found out that IEEE1394-1995 had specified wrong gap counts that were too small). Regards, Clemens |
|
From: Carl K. <ca...@pe...> - 2011-08-03 15:25:05
|
On Wed, Aug 3, 2011 at 6:49 AM, <re...@co...> wrote: > build from the deb source package - which actually fetches the source > from ubuntu git What's the commands to get that? -- Carl K |
|
From: René F. <re...@co...> - 2011-08-03 18:27:13
|
Am Mittwoch, 3. August 2011, 10:24:37 schrieb Carl Karsten: > On Wed, Aug 3, 2011 at 6:49 AM, <re...@co...> wrote: > > build from the deb source package - which actually fetches the source > > from ubuntu git > > What's the commands to get that? I used following resources (even though they are not for natty): https://help.ubuntu.com/community/Kernel/Compile http://parabing.com/2011/04/28/ubuntu-natty-a-custom-kernel-is-what-you-want/ I did this (hopefully it's complete) # sudo apt-get build-dep --no-install-recommends linux-image-$(uname -r) # apt-get source linux-image-$(uname -r) # cd linux* # chmod -R u+x debian/scripts/* only needed when module configuration should be changed # debian/rules editconfigs # debian/rules updateconfigs # fakeroot debian/rules clean parallel=2 means 2 cpus for comiling # DEB_BUILD_OPTIONS=parallel=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic IMPORTANT: I'm unsure if the kernel configuration is the same as the official kernel package. I wasn't able to check that. (/boot/config-2.6.38-11-generic differs from debian/config/i386/*) René |
Thanks for helping keep SourceForge clean.
X