Re: fw1 not created for dv-camera
Brought to you by:
aeb,
bencollins
Menu
▾
▴
Re: fw1 not created for dv-camera
|
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/ |