linux1394-user Mailing List for IEEE 1394 for Linux (Page 16)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(29) |
Nov
(36) |
Dec
(46) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(60) |
Feb
(82) |
Mar
(46) |
Apr
(50) |
May
(89) |
Jun
(60) |
Jul
(80) |
Aug
(130) |
Sep
(104) |
Oct
(105) |
Nov
(123) |
Dec
(107) |
2002 |
Jan
(142) |
Feb
(105) |
Mar
(63) |
Apr
(117) |
May
(136) |
Jun
(75) |
Jul
(105) |
Aug
(103) |
Sep
(149) |
Oct
(149) |
Nov
(98) |
Dec
(144) |
2003 |
Jan
(161) |
Feb
(100) |
Mar
(118) |
Apr
(126) |
May
(157) |
Jun
(173) |
Jul
(156) |
Aug
(89) |
Sep
(83) |
Oct
(106) |
Nov
(84) |
Dec
(69) |
2004 |
Jan
(119) |
Feb
(233) |
Mar
(232) |
Apr
(104) |
May
(113) |
Jun
(132) |
Jul
(87) |
Aug
(129) |
Sep
(186) |
Oct
(88) |
Nov
(148) |
Dec
(180) |
2005 |
Jan
(223) |
Feb
(176) |
Mar
(148) |
Apr
(193) |
May
(188) |
Jun
(236) |
Jul
(144) |
Aug
(89) |
Sep
(44) |
Oct
(86) |
Nov
(114) |
Dec
(89) |
2006 |
Jan
(94) |
Feb
(97) |
Mar
(57) |
Apr
(117) |
May
(46) |
Jun
(63) |
Jul
(51) |
Aug
(72) |
Sep
(50) |
Oct
(142) |
Nov
(70) |
Dec
(52) |
2007 |
Jan
(60) |
Feb
(67) |
Mar
(80) |
Apr
(81) |
May
(78) |
Jun
(52) |
Jul
(64) |
Aug
(55) |
Sep
(40) |
Oct
(87) |
Nov
(70) |
Dec
(44) |
2008 |
Jan
(80) |
Feb
(12) |
Mar
(82) |
Apr
(64) |
May
(33) |
Jun
(53) |
Jul
(41) |
Aug
(26) |
Sep
(35) |
Oct
(21) |
Nov
(30) |
Dec
(42) |
2009 |
Jan
(17) |
Feb
(32) |
Mar
(10) |
Apr
(19) |
May
(19) |
Jun
(28) |
Jul
(41) |
Aug
(14) |
Sep
(5) |
Oct
(46) |
Nov
(23) |
Dec
(20) |
2010 |
Jan
(46) |
Feb
(13) |
Mar
(9) |
Apr
(2) |
May
(19) |
Jun
(28) |
Jul
(37) |
Aug
(23) |
Sep
(5) |
Oct
(32) |
Nov
(19) |
Dec
(18) |
2011 |
Jan
(23) |
Feb
(9) |
Mar
(19) |
Apr
(38) |
May
(83) |
Jun
(30) |
Jul
(46) |
Aug
(32) |
Sep
(6) |
Oct
(3) |
Nov
(25) |
Dec
(31) |
2012 |
Jan
(21) |
Feb
(12) |
Mar
(19) |
Apr
(7) |
May
(27) |
Jun
(7) |
Jul
(2) |
Aug
(15) |
Sep
(8) |
Oct
(11) |
Nov
|
Dec
(3) |
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(14) |
Jul
(1) |
Aug
(3) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
|
2014 |
Jan
(14) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(14) |
Nov
(5) |
Dec
(18) |
2015 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
(11) |
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
|
May
(4) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Clemens L. <cl...@la...> - 2011-08-09 15:57:27
|
I wrote: > get_info.bus_reset = (u64)&bus_reset; Uh-oh. 32-bit gcc 4.4.4 says "cast from pointer to integer of different size" and sign-extends the value. firewire-cdev.c's u64_to_uptr() differs from compat_ptr() in that the latter correctly masks the source pointer to 32 bits. This is definitely a bug in async-test.c, but shouldn't the kernel use compat_ptr() for all pointers when is_compat_task()? u64_to_uptr() will definitely be wrong on s390 and tile (not that we care about those). Regards, Clemens |
From: Clemens L. <cl...@la...> - 2011-08-09 15:28:32
|
Carl Karsten wrote: > ioctl get_info: Bad address > > https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c int main(int argc, char *argv[]) { struct fw_cdev_get_info get_info; struct fw_cdev_event_bus_reset bus_reset; ... get_info.version = 3; get_info.rom_length = 0; get_info.rom = 0; get_info.bus_reset = (u64)&bus_reset; get_info.bus_reset_closure = 0; if (ioctl(fd, FW_CDEV_IOC_GET_INFO, &get_info) == -1) { perror("ioctl get_info"); Which architectures are you using in userspace and in the kernel? Regards, Clemens |
From: Carl K. <ca...@pe...> - 2011-08-09 14:22:49
|
new box, used it for a weekend of video, no problem. getting back to making tests: (veyepar)juser@cnt2:~$ sudo async-test receive 001e8c00004166f5 /dev/fw0: Success 001e8c00004166f5 001e8c00004166f5 65472 65472 ioctl get_info: Bad address https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c (veyepar)juser@cnt2:~$ lspci|grep 1394 04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01) 08:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) plug in cable, new dmesg: [ 258.595688] irq_handler: 6 callbacks suppressed [ 258.595692] firewire_ohci: isochronous cycle inconsistent [ 258.595752] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 [ 259.091178] firewire_core: created device fw2: GUID 0011066600000566, S400 [ 259.091295] firewire_core: created device fw3: GUID 001e8c00004166f5, S400 -- Carl K |
From: Stefan R. <st...@s5...> - 2011-08-05 19:45:44
|
On Jun 02 Joan Pau Beltran wrote: > We experienced data transmission problems when trying a Sweex Firewire > ExpressCard on a Sony Vaio VPCEB2S1E. The card is reported by lspci as: > 05:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. Device 3403. > > More precisely when using a firewire camera, the images are displayed > mixed or with interferences. We did tests with several cameras, two > identical cards and two Vaio laptops (testing each card in every laptop) > and all give the same result with corrupted images. > > However, the same cards with the same cameras work perfectly on another > laptop (a Toshiba one). In all three laptops we use Ubuntu 10.04. From > that I figure out that this is a problem of the ExpressCard controller > on Vaio laptops and not firewire related. But since I am not very > experienced with firewire, I may be wrong. So do you think it can be a > firewire problem? If not, do you know where should I report the problem? Try lin...@vg.... Is Intel VT-d enabled on the Sony but not on the Toshiba? -- 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-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 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: 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é |
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: <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-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: 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: Mike A. <mik...@gm...> - 2011-08-02 21:09:13
|
On 02/08/11 17:36, Clemens Ladisch wrote: > There were big changes, and big packets should work fine. This looks > more like a hardware issue. > > This 1800 bytes limit is suspiciously near the default 1.7 KB AT FIFO > DMA threshold of the XIO2200A. Apparently, the XIO2200A cannot read the > packet data from memory fast enough, so the packet gets corrupted. In > theory, this should result in the packet being retried when it has been > completely read into the FIFO, but this does not seem to happen in your > case. > > When I did stress testing my XIO2200A with a VT6308, this worked > correctly at all packet sizes, but this was with explicit AT transmit > requests/responses and not physical DMA reads. > > I see two possible problem sources: > 1) the XIO2200A does not retry physical read response packets; or > 2) the R5C832 does not correctly signal corrupted packets back to the > sending node. > > Ricoh chips are considered cheap crap, so I'd be more suspicious about > that one. However, the problem might be avoided with a controller that > does not have as agressive buffering as the XIO2200A, so you might try > to replace either one. Ok, thanks very much. I've got two of the XIO2200A's, but no cable for them, so that seems like the first step to test. I'll try to report back my findings, but it may take me a couple of weeks due to time constraints. Thanks again for you quick reply (and testing out the code to check that it works with similar hardware)! Mike 5:) |
From: Clemens L. <cl...@la...> - 2011-08-02 21:03:47
|
Mike Auty wrote: >I've included the relevant lines from an strace of a small python test >program (also included), This program seems to work fine with my XIO2200A and VT6308 in either direction. Regards, Clemens |
From: Clemens L. <cl...@la...> - 2011-08-02 16:33:06
|
Mike Auty wrote: > I've been using libforensic1394 to carry our raw reads of windows memory > using firewire from a linux system. The setup is a linux box with a > built-in firewire adaptor: > > 03:00.4 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd Device [1180:e832] (rev 03) > > And the windows box has had an expresscard inserted to ensure firewire > support. The card used shows up as follows under linux: > > 05:00.0 PCI bridge [0604]: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge [104c:8231] (rev 03) > 06:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments XIO2200(A) IEEE-1394a-2000 Controller (PHY/Link) [104c:8235] (rev 01) > > When running the code, the request_size is returned as 2048 (as > expected), but when carrying out reads of various sizes, the results are > consistent and valid up until 1800 bytes (exactly) and then 1801 - 1805 > sometimes work and sometimes don't, and beyond that they almost always > fail. Above 2048, the error returned is a request_size too big error, > but between 1800 and 2048, the RCODE that I've tracked it back to is 17 > (which appears to be RCODE_CANCELLED). This means that there was no response (or the response was not recognized). I guess it's slower because of a timeout (100 ms or 2 s, depending on kernel version)? > I've tested this on 2.6.35, 2.6.36, 2.6.39 and 3.0, and they all fail > in the same way. The author of libforensic1394 therefore suggested > that this might be a kernel issue There were big changes, and big packets should work fine. This looks more like a hardware issue. This 1800 bytes limit is suspiciously near the default 1.7 KB AT FIFO DMA threshold of the XIO2200A. Apparently, the XIO2200A cannot read the packet data from memory fast enough, so the packet gets corrupted. In theory, this should result in the packet being retried when it has been completely read into the FIFO, but this does not seem to happen in your case. When I did stress testing my XIO2200A with a VT6308, this worked correctly at all packet sizes, but this was with explicit AT transmit requests/responses and not physical DMA reads. I see two possible problem sources: 1) the XIO2200A does not retry physical read response packets; or 2) the R5C832 does not correctly signal corrupted packets back to the sending node. Ricoh chips are considered cheap crap, so I'd be more suspicious about that one. However, the problem might be avoided with a controller that does not have as agressive buffering as the XIO2200A, so you might try to replace either one. Regards, Clemens |
From: Mike A. <mik...@gm...> - 2011-08-01 20:16:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I've been using libforensic1394 to carry our raw reads of windows memory using firewire from a linux system. The setup is a linux box with a built-in firewire adaptor: 03:00.4 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd Device [1180:e832] (rev 03) And the windows box has had an expresscard inserted to ensure firewire support. The card used shows up as follows under linux: 05:00.0 PCI bridge [0604]: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge [104c:8231] (rev 03) 06:00.0 FireWire (IEEE 1394) [0c00]: Texas Instruments XIO2200(A) IEEE-1394a-2000 Controller (PHY/Link) [104c:8235] (rev 01) When running the code, the request_size is returned as 2048 (as expected), but when carrying out reads of various sizes, the results are consistent and valid up until 1800 bytes (exactly) and then 1801 - 1805 sometimes work and sometimes don't, and beyond that they almost always fail. Above 2048, the error returned is a request_size too big error, but between 1800 and 2048, the RCODE that I've tracked it back to is 17 (which appears to be RCODE_CANCELLED). I've tested this on 2.6.35, 2.6.36, 2.6.39 and 3.0, and they all fail in the same way. The author of libforensic1394 therefore suggested that this might be a kernel issue and that I should post my findings here. I also tried large bursts of reads below 1800 bytes to see whether too many asynchronous reads were causing the problem, but they all appeared to work fine. I've included the relevant lines from an strace of a small python test program (also included), and I'd be happy to run any additional tests, or answer any questions that I can in order to get this issue resolved... Thanks, Mike 5:) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk43BXoACgkQu7rWomwgFXoGmQCggeeB9KQkOubD25pL/4ihrsn1 MEsAoLPUK1q4Qj8OCms+TdYBCfy94iP2 =Ca/u -----END PGP SIGNATURE----- |
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: 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: Stefan R. <st...@s5...> - 2011-07-31 14:08:45
|
On Jul 28 Carl Karsten wrote: > ASUS motherboard, one on board firewire, one pci card. > > plug camera into card, all works fine. plug into on board and things fail > > (veyepar)juser@cnt2:~$ lspci |grep 13 > 04:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series > Firewire Controller (rev 01) > 08:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire > II(M)] IEEE 1394 OHCI Controller (rev 46) > > (veyepar)juser@cnt2:~$ dvgrab > Error: no camera exists > > [ 1106.523403] firewire_core: skipped bus generations, destroying all nodes > [ 1107.020284] firewire_core: rediscovered device fw0 > [ 1561.141043] firewire_core: skipped bus generations, destroying all nodes > [ 1561.638991] firewire_core: rediscovered device fw0 > [ 1561.638999] firewire_core: giving up on config rom for node id ffc0 > [ 1572.087990] firewire_ohci: isochronous cycle inconsistent > [ 1572.798527] firewire_core: created device fw2: GUID 008045821097902b, S100 > [ 1572.798534] firewire_core: phy config: card 1, new root=ffc1, gap_count=5 > [ 1572.799208] firewire_core: IRM is not 1394a compliant, making local node (ffc0) root. > [ 1572.799211] firewire_core: phy config: card 1, new root=ffc0, gap_count=5 What is the model designation of this camcorder? If this camcorder is plugged into to the PCI card (with which it works), does the "IRM is not 1394a compliant, making local node (ffc0) root" message show up too? -- Stefan Richter -=====-==-== -=== ===== http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-07-31 14:07:45
|
On Jul 29 Clemens Ladisch wrote: > (I guess there might be some cameras with working firmware, Sounds ridiculously improbable, but there actually do exist some. My entry-level JVC GR-D725E works properly. > but are there any other S100-only A/V devices?) There are also tape decks and converters which _may_ have S100 ports (or S200 ports in some cases). I don't know about the IRM/BM capabilities and about the bugs of such devices. -- 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 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: Stefan R. <st...@s5...> - 2011-07-31 08:37:59
|
For the list to know: The issue seems to be resolved by replacement of the cable. On Jul 30 Walt wrote: > Stefan: > > I think I finally discovered the problem. I bought a new cable last > week, then realized I had another already. After using the new one, and > running out of other things to test, I plugged in the cable I already > had and it worked! I've had a lot of practice with root commands and > leaned much about raw1394 that I never knew. > > Thank you for your time and patience. > > > Walt Frazer -- Stefan Richter -=====-==-== -=== ===== http://arcgraph.de/sr/ |
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-30 13:19:24
|
> On Fri, 2011-07-29 at 08:29 +0200, Stefan Richter wrote: > > As root user, run "echo 7 > /sys/module/firewire_ohci/parameters/debug", > > then connect the camcorder, then watch what is being added to the kernel > > log and post the result here. PS: In a terminal window, you can log in as root by the command "su". Unlike "sudo", this command requires the root password, not the user password. Or you can perform the ">" redirection also with sudo (with the user password) in the following way: sudo sh -c 'echo 7 > /sys/module/firewire_ohci/parameters/debug' After that, "cat /sys/module/firewire_ohci/parameters/debug" should confirm that there is a 7 in there now. You can later echo a 0 into the parameter in order to switch debug logging off again. The above only works if sudo is configured rather liberally on your system. Or you can do the following instead: 1. Unload the controller driver with sudo modprobe -r firewire-ohci 2. Check that it really went away. lsmod | grep fire (should not show firewire_ohci anymore) 3. Load it again but with debug logging enabled. sudo modprobe firewire-ohci debug=7 4. After you tested the camcorder and gathered the debug log, you get rid of the noisy driver by unloading it again. -- Stefan Richter -=====-==-== -=== ====- http://arcgraph.de/sr/ |