linux1394-user Mailing List for IEEE 1394 for Linux (Page 14)
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: Carl K. <ca...@pe...> - 2011-12-16 05:10:53
|
laptop with onboard and pcie slot. 2 test suggest this only happens when i plug the card in after boot. if it is plugged in when the kernel boots, no problem (and no need for the acpiphp module) So maybe it is a hot plug problem. boot with no card, load acpiphp plugged in a fw pcie card: [ 107.481212] pci 0000:04:00.0: [11c1:5901] type 0 class 0x000c00 [ 107.481252] pci 0000:04:00.0: reg 10: [mem 0x00000000-0x00000fff 64bit] [ 107.481342] pci 0000:04:00.0: supports D1 D2 [ 107.481349] pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 107.481359] pci 0000:04:00.0: PME# disabled [ 107.488468] pci 0000:04:00.0: BAR 0: assigned [mem 0xf2000000-0xf2000fff 64bit] [ 107.488488] pci 0000:04:00.0: BAR 0: set to [mem 0xf2000000-0xf2000fff 64bit] (PCI address [0xf2000000-0xf2000fff]) [ 107.488519] pci 0000:04:00.0: no hotplug settings from platform [ 107.494034] firewire_ohci 0000:04:00.0: enabling device (0000 -> 0002) [ 107.494595] ACPI: PCI Interrupt Link [LK1E] enabled at IRQ 16 [ 107.494610] firewire_ohci 0000:04:00.0: PCI INT A -> Link[LK1E] -> GSI 16 (level, low) -> IRQ 16 [ 107.494626] firewire_ohci 0000:04:00.0: setting latency timer to 64 [ 107.548128] firewire_ohci: Added fw-ohci device 0000:04:00.0, OHCI v1.10, 8 IR + 8 IT contexts, quirks 0x10 [ 108.048401] firewire_core: created device fw1: GUID 0108000000006351, S800 looped cable to on board port: [ 112.817782] firewire_ohci: isochronous cycle inconsistent [ 112.817820] firewire_core: phy config: card 1, new root=ffc1, gap_count=5 [ 143.392293] firewire_core: giving up on config rom for node id ffc1 [ 165.404068] firewire_core: giving up on config rom for node id ffc0 juser@pc8:~$ juser@pc8:~$ ls /dev/fw? /dev/fw0 /dev/fw1 juser@pc8:~$ cat /etc/modules loop lp rtc snd-hda-intel acpiphp 00:00.0 RAM memory: nVidia Corporation MCP67 Memory Controller (rev a2) 00:01.0 ISA bridge: nVidia Corporation MCP67 ISA Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP67 SMBus (rev a2) 00:01.2 RAM memory: nVidia Corporation MCP67 Memory Controller (rev a2) 00:01.3 Co-processor: nVidia Corporation MCP67 Co-processor (rev a2) 00:02.0 USB Controller: nVidia Corporation MCP67 OHCI USB 1.1 Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation MCP67 EHCI USB 2.0 Controller (rev a2) 00:04.0 USB Controller: nVidia Corporation MCP67 OHCI USB 1.1 Controller (rev a2) 00:04.1 USB Controller: nVidia Corporation MCP67 EHCI USB 2.0 Controller (rev a2) 00:06.0 IDE interface: nVidia Corporation MCP67 IDE Controller (rev a1) 00:07.0 Audio device: nVidia Corporation MCP67 High Definition Audio (rev a1) 00:08.0 PCI bridge: nVidia Corporation MCP67 PCI Bridge (rev a2) 00:09.0 IDE interface: nVidia Corporation MCP67 AHCI Controller (rev a2) 00:0a.0 Ethernet controller: nVidia Corporation MCP67 Ethernet (rev a2) 00:0c.0 PCI bridge: nVidia Corporation MCP67 PCI Express Bridge (rev a2) 00:0d.0 PCI bridge: nVidia Corporation MCP67 PCI Express Bridge (rev a2) 00:12.0 VGA compatible controller: nVidia Corporation C67 [GeForce 7150M / nForce 630M] (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 02:05.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05) 02:05.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 02:05.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 02:05.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) 03:00.0 Ethernet controller: Atheros Communications Inc. AR242x / AR542x Wireless Network Adapter (PCI-Express) (rev 01) 04:00.0 FireWire (IEEE 1394): Agere Systems FW643 PCI Express1394b Controller (PHY/Link) (rev 06) -- Carl K |
From: Michal S. <hra...@ce...> - 2011-11-26 12:00:42
|
On 26 November 2011 10:36, Stefan Richter <st...@s5...> wrote: > On Nov 22 Jack Chaney wrote: > [block layer bugs WRT device removal] >> I have been relying on Ubuntu 11.10 and I must reboot to minimize >> expose to this problem. Also, I redistribute a shareware application >> in a bootable iso file, and I need to remaster when this is fixed. >> >> Please send a heads-up when you know anything positive about this >> problem. Thanks. > > This is not what you are waiting for to hear, but alas the current > 3.2.0-rc still contains issues of this kind: > http://marc.info/?l=linux-scsi&m=132214509516626 For me the latest 3.2 rc fixed an issue with kernel bug when removing an USB floppy so there are some improvements. Or maybe I was just lucky and did not see the error because the block device happened to always go away at the right time. 3.2 is worth some testing I guess, though. Thanks Michal |
From: Stefan R. <st...@s5...> - 2011-11-26 09:36:15
|
On Nov 22 Jack Chaney wrote: [block layer bugs WRT device removal] > I have been relying on Ubuntu 11.10 and I must reboot to minimize > expose to this problem. Also, I redistribute a shareware application > in a bootable iso file, and I need to remaster when this is fixed. > > Please send a heads-up when you know anything positive about this > problem. Thanks. This is not what you are waiting for to hear, but alas the current 3.2.0-rc still contains issues of this kind: http://marc.info/?l=linux-scsi&m=132214509516626 -- Stefan Richter -=====-==-== =-== ==-=- http://arcgraph.de/sr/ |
From: Jack C. <jac...@ma...> - 2011-11-23 02:13:49
|
Stephan Richter, I have been relying on Ubuntu 11.10 and I must reboot to minimize expose to this problem. Also, I redistribute a shareware application in a bootable iso file, and I need to remaster when this is fixed. Please send a heads-up when you know anything positive about this problem. Thanks. Jack Chaney On Nov 3, 2011, at 11:05 AM, Stefan Richter wrote: > On Oct 05 Stefan Richter wrote: >> PS, unrelated to the 1394 subsystem but related to 1394 storage devices: >> The last few kernel releases had multiple bugs WRT hot removal of hard >> disks, CD ROM drives, card readers and so on. The word is that the last >> known one of these bugs has been fixed in 3.1-rc9 from yesterday. > > Not true. Sadly, the Linux block layer remains buggy WRT device removal. > AFAIU a thorough rework of the block layer with introduction of proper > reference counting is required to get this class of bugs really fixed. > Considering that there was a steady, frequent stream of related bug reports > for about a year now, and presumed fix after presumed fix was applied > without ultimate progress in the matter, it is easy to make an estimate > how quick this is going to be resolved. > > While I did not see a kernel panic anymore myself lately, processes and > kernel threads tend to fall into uninterruptible wait state if a storage > device is removed. > > Note to self: Always kill udisks-deamon before removing a CD-ROM drive or > a card reader, to reduce exposure to race conditions. > -- > Stefan Richter > -=====-==-== =-== ---== > http://arcgraph.de/sr/ > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > mailing list Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux1394-user |
From: Stefan R. <st...@s5...> - 2011-11-09 18:52:11
|
I just noticed that https://ieee1394.wiki.kernel.org/ is back online, but for the time being it is read-only. I have been told that it will be fully restored by the kernel.org team as soon as hardware and manpower allow. -- Stefan Richter -=====-==-== =-== -=--= http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-11-08 13:12:41
|
On Nov 07 Robert Lemmen wrote: > ok, I have found another firewire card. it says "ma-133" on it, and > lscpi says: > > 03:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire > II(M)] IEEE 1394 OHCI Controller (rev 46) > > this card has two jumpers on it labeled "Internal 12V" and "External > 12V". It also has a white 4-pin power connector. [...] > so: > - is that other chip (VIA VT6306) ok? Yes, it is. I have used VT6306 successfully with various different audio, video, and storage devices; also with multiple devices on the bus at once. There are some known problems though: - Audio device aggregation by FFADO does not work on this chip. This is a common problem of many other chips also. - DV capture with the gstreamer DV plugin or with the dv4lstart V4L2 device emulator does not work. This is a unique problem of VT6306. > - has anyone a similar card? what have you set your jumpers to? I don't. > - there is another 8-pin jumper block, anyone knows what that is good > for? This could be a header for a front panel breakout cable. VT6306 is a three-port chip, so if this card has got three ports already at its back plate, then such an internal connector would share pins with one of the external connectors. Only one of the shared connectors can be used at a time then, and signal quality on either connector is probably lower than on proper port connectors. On top of that, a breakout cable or any kind of passive extension cable would degrade the signal even more. Many 1394 PCI cards offer an internal 1394 connector, usually in the form of a regular 1394 6-pin socket or a 1394b 9-pin socket. Motherboards with onboard 1394 chip and an internal 1394 port on the other hand usually offer that internal port in the form of a pin header, looking like a jumper block. There might be PCI cards with pin header as internal connector too. That jumper block on your card might serve other purposes, but an internal 1394 port is IMO the most plausible explanation in case of a VT6306 based card. -- Stefan Richter -=====-==-== =-== -=--- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-11-08 06:54:30
|
On Nov 07 Robert Lemmen wrote: > would you think that bus power could > also lead to these constant bus resets? Yes, insufficient or unstable bus power could do that. > I am asking because I still hope > it is something with bus power rather than a broken camera. I'm still > hunting for a pci card that has known working bus power. the one I have > claims so, but the jumpers that I don't know what they are good for etc > makes me wonder... > > can I just check for bus power by looking at voltage/power on the cable? I think yes, if you measure with power consumer (e.g. camera) connected. I am not sure though at which frequency you need to be able to measure in order to determine that bus power is stable enough for the camera. > Or is this intelligently managed in the sense that the power is only > available if the device asks for it? Bus power is always there if there is a power provider on the bus. It is the other way around: A power management software could control power draw of consumers which support respective management functions. -- Stefan Richter -=====-==-== =-== -=--- http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2011-11-07 21:59:20
|
On Mon, Nov 7, 2011 at 2:35 PM, Robert Lemmen <rob...@se...> wrote: > On Wed, Nov 02, 2011 at 02:31:01PM -0500, Carl Karsten wrote: >> This is more for me than you, but it might help you.... >> >> If you have a 2nd firewire controller (card), plug one card into the >> other and run: >> >> https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c Whoops, that wasn't the one I was thinking of. That is v1, which needs to be run twice.. This is what I mean, and here is what 'good' looks like: juser@pc9e:~/fwdiag$ sudo ./async-loop-ck Main process: starting receiver Main: receiver started, pid: 2567; waiting 4 seconds... Receiver child process 2567 starting... Main process: starting sender Main: sender started, pid: 2568 Main process, waiting for child processes to finish... Sender child process 2568 starting... Received 524289389 bytes = 500.00 MB in 511745 packets in 28 seconds ...receiver finished Sent 524288119 bytes = 500.00 MB in 511753 packets in 28 seconds ...sender finished Main: processes finished -- Carl K |
From: Robert L. <rob...@se...> - 2011-11-07 21:52:32
|
On Mon, Nov 07, 2011 at 10:29:00PM +0100, Stefan Richter wrote: > The fact that you receive boatloads of bus reset events but never a > self-ID-complete event with the camera means that the camera is defective > (since you checked the card and the cable, and you apparently also ruled > out bus power as the problem source). great, thanks for the explanation! would you think that bus power could also lead to these constant bus resets? I am asking because I still hope it is something with bus power rather than a broken camera. I'm still hunting for a pci card that has known working bus power. the one I have claims so, but the jumpers that I don't know what they are good for etc makes me wonder... can I just check for bus power by looking at voltage/power on the cable? Or is this intelligently managed in the sense that the power is only available if the device asks for it? If I could just check for 12V at a given power draw on the cable, then that would be the easiest way to check for bus power... thanks robert -- Robert Lemmen http://www.semistable.com |
From: Stefan R. <st...@s5...> - 2011-11-07 21:45:19
|
On Nov 07 Stefan Richter wrote: > Old 1394-1995 hardware used to react with a short burst of bus resets every > time when something was plugged in to or out of a bus, and this burst was > followed by a self-ID-complete event. With 1394a-2000/ 1394b-2002/ > 1394-2008 compliant hardware, you typically get just one, maybe two bus > resets and then a self-ID-complete event. PS, for completeness: Briefly after this, there is often another pair of bus reset and self-ID-complete. This is when a bus manager software, e.g. the Linux driver, reconfigures the bus with better asynchronous arbitration gap settings or selected a different root node to ensure proper isochronous arbitration. Or/ and there may be another pair of bus reset and self-ID-complete when a newly switched-on node finished its boot sequence and signals to the rest of the bus that its higher functions are now ready for access. (Just to describe what kind of events should normally be seen; obviously that's not at all happening with your camera.) -- Stefan Richter -=====-==-== =-== --=== http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-11-07 21:29:11
|
On Nov 07 Robert Lemmen wrote: > not sure that means anyting, but if i do my modprobe with debug=8 rather > than debug=7 (no idea what any of this exactly means), then plugging in > my camera floods the dmesg with bus reset messages: > > [ 361.873332] firewire_ohci: IRQ 00020000 busReset > [ 361.873340] firewire_ohci: IRQ 00020000 busReset > [ 361.873349] firewire_ohci: IRQ 00020000 busReset > [ 361.873357] firewire_ohci: IRQ 00020000 busReset > [ 361.873366] firewire_ohci: IRQ 00020000 busReset > [ 361.873374] firewire_ohci: IRQ 00020000 busReset > > that can't be right at such a high rate! debug=7 actually means debug=1+2+4, meaning it should log (1) asynchronous packet transmit and receive events, (2) self-ID-complete events with self-ID packet contents, (4) any interrupt events from the set of interrupt types that the driver normally receives. debug=8 means that the driver shall activate reception of bus reset interrupts in addition to the set of the other interrupt event types and log them. (Normally the driver is not interested in getting bus reset IRQs. We only want to know when a bus reset is over and the bus is back in normal operation again --- and for that purpose we receive self-ID-complete IRQs.) Old 1394-1995 hardware used to react with a short burst of bus resets every time when something was plugged in to or out of a bus, and this burst was followed by a self-ID-complete event. With 1394a-2000/ 1394b-2002/ 1394-2008 compliant hardware, you typically get just one, maybe two bus resets and then a self-ID-complete event. By means of the self-ID-complete IRQ, the chip signals to the driver that transmission and reception of self-identification packets by all nodes right after bus reset and automatic enumeration of all nodes. (Unlike old parallel SCSI where node IDs where configured by the user, typically with small jumper switches at the back panel of each device, 1394 node IDs are re-negotiated between all devices at each bus reset.) The self-ID packets carry node IDs, how many ports each node has, parent--child connection relationships of all ports, and more. The fact that you receive boatloads of bus reset events but never a self-ID-complete event with the camera means that the camera is defective (since you checked the card and the cable, and you apparently also ruled out bus power as the problem source). -- Stefan Richter -=====-==-== =-== --=== http://arcgraph.de/sr/ |
From: Robert L. <rob...@se...> - 2011-11-07 20:50:05
|
hi folks, not sure that means anyting, but if i do my modprobe with debug=8 rather than debug=7 (no idea what any of this exactly means), then plugging in my camera floods the dmesg with bus reset messages: [ 361.873332] firewire_ohci: IRQ 00020000 busReset [ 361.873340] firewire_ohci: IRQ 00020000 busReset [ 361.873349] firewire_ohci: IRQ 00020000 busReset [ 361.873357] firewire_ohci: IRQ 00020000 busReset [ 361.873366] firewire_ohci: IRQ 00020000 busReset [ 361.873374] firewire_ohci: IRQ 00020000 busReset that can't be right at such a high rate! cu robert -- Robert Lemmen http://www.semistable.com |
From: Robert L. <rob...@se...> - 2011-11-07 20:47:57
|
On Mon, Nov 07, 2011 at 02:41:10PM -0600, Carl Karsten wrote: > But... looking at the output makes me wonder if it is detecting 2 > cards. I can at least see what happens if it I run it with only 1 > card. I should be able to do that today. I think it does, at least it goes through "fw0" to "fw3" with two cards, with one (or without a cable) it doesn't cu robert -- Robert Lemmen http://www.semistable.com |
From: Robert L. <rob...@se...> - 2011-11-07 20:43:30
|
On Mon, Nov 07, 2011 at 08:35:02PM +0000, Robert Lemmen wrote: > any combination of ports) I get: > > /dev/fw0: Success > 234 > 001106005350d195 65472 65472 > /dev/fw1: Invalid argument > 234 > 0000d100802a6abc 65473 65472 > /dev/fw2: Invalid argument > 234 > 0000d100802a6abc 65473 65473 > /dev/fw3: Invalid argument > 234 sorry, I copied from the wrong file. with the cable between the cards I get: dev/fw0: Success 234 0000d100802a6abc 65473 65473 /dev/fw1: Success 234 001106005350d195 65472 65472 /dev/fw2: Success 234 0000d100802a6abc 65473 65472 /dev/fw3: Success 234 001106005350d195 65472 65473 /dev/fw4: Success /dev/fw5: No such file or directory /dev/fw6: No such file or directory /dev/fw7: No such file or directory /dev/fw8: No such file or directory Device not found. : No such file or directory also, I get the same output no matter if I do "send" or "receive", and for any "guid" (whatever that is) cu robert -- Robert Lemmen http://www.semistable.com |
From: Carl K. <ca...@pe...> - 2011-11-07 20:41:38
|
On Mon, Nov 7, 2011 at 2:35 PM, Robert Lemmen <rob...@se...> wrote: > On Wed, Nov 02, 2011 at 02:31:01PM -0500, Carl Karsten wrote: >> This is more for me than you, but it might help you.... >> >> If you have a 2nd firewire controller (card), plug one card into the >> other and run: >> >> https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c >> >> If it finds an error, then the problem is one of the cards or cable >> and probably not the camera. >> >> Or the program is whacked. This is something a friend wrote, I >> haven't gotten around to testing it other than "it runs! great! >> thanks! I'll buy you a beer!" > > not sure how to interpret this, but with a cable between both cards (for > any combination of ports) I get: > > /dev/fw0: Success > 234 > 001106005350d195 65472 65472 > /dev/fw1: Invalid argument > 234 > 0000d100802a6abc 65473 65472 > /dev/fw2: Invalid argument > 234 > 0000d100802a6abc 65473 65473 > /dev/fw3: Invalid argument > 234 > 001106005350d195 65472 65473 > /dev/fw4: Invalid argument > /dev/fw5: No such file or directory > /dev/fw6: No such file or directory > /dev/fw7: No such file or directory > /dev/fw8: No such file or directory > Device not found. > : No such file or directory > > without a cable beteeen them, I get: > > /dev/fw0: Success > 234 > 001106005350d195 65472 65472 > /dev/fw1: Invalid argument > /dev/fw2: No such file or directory > 234 > 0000d100802a6abc 65472 65472 > /dev/fw3: No such file or directory > /dev/fw4: No such file or directory > /dev/fw5: No such file or directory > /dev/fw6: No such file or directory > /dev/fw7: No such file or directory > /dev/fw8: No such file or directory > Device not found. > : No such file or directory > > is that a sign for good cables and cards? Not really. I have not had a chance to run in on known bad hardware to verify it actually reports an error. If it reported an error, then there would be a clue what to look at. But... looking at the output makes me wonder if it is detecting 2 cards. I can at least see what happens if it I run it with only 1 card. I should be able to do that today. -- Carl K |
From: Robert L. <rob...@se...> - 2011-11-07 20:35:11
|
On Wed, Nov 02, 2011 at 02:31:01PM -0500, Carl Karsten wrote: > This is more for me than you, but it might help you.... > > If you have a 2nd firewire controller (card), plug one card into the > other and run: > > https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c > > If it finds an error, then the problem is one of the cards or cable > and probably not the camera. > > Or the program is whacked. This is something a friend wrote, I > haven't gotten around to testing it other than "it runs! great! > thanks! I'll buy you a beer!" not sure how to interpret this, but with a cable between both cards (for any combination of ports) I get: /dev/fw0: Success 234 001106005350d195 65472 65472 /dev/fw1: Invalid argument 234 0000d100802a6abc 65473 65472 /dev/fw2: Invalid argument 234 0000d100802a6abc 65473 65473 /dev/fw3: Invalid argument 234 001106005350d195 65472 65473 /dev/fw4: Invalid argument /dev/fw5: No such file or directory /dev/fw6: No such file or directory /dev/fw7: No such file or directory /dev/fw8: No such file or directory Device not found. : No such file or directory without a cable beteeen them, I get: /dev/fw0: Success 234 001106005350d195 65472 65472 /dev/fw1: Invalid argument /dev/fw2: No such file or directory 234 0000d100802a6abc 65472 65472 /dev/fw3: No such file or directory /dev/fw4: No such file or directory /dev/fw5: No such file or directory /dev/fw6: No such file or directory /dev/fw7: No such file or directory /dev/fw8: No such file or directory Device not found. : No such file or directory is that a sign for good cables and cards? thanks robert -- Robert Lemmen http://www.semistable.com |
From: Robert L. <rob...@se...> - 2011-11-07 20:32:18
|
On Thu, Nov 03, 2011 at 09:47:58AM +0100, Clemens Ladisch wrote: > PCI cards have two sense lines to tell the motherboard if they use up to > 7.5, 15, or 25 W. (I'd guess there are as many motherboards that make > use of this information as there are FireWire power managers.) However, > the maximum 12 V current is 500 mA, so bus power (with up to 1.5 A) must > come from a separate power connector. ok, I have found another firewire card. it says "ma-133" on it, and lscpi says: 03:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46) this card has two jumpers on it labeled "Internal 12V" and "External 12V". It also has a white 4-pin power connector. I have tried the same thing with this card, with and without direct power, with all settings of the jumpers, and with all ports of it. same problem: no device is created for the camera, when I unplug it I get: [ 378.411546] firewire_ohci: IRQ 00000010 AR_req [ 378.411553] firewire_ohci: AR evt_bus_reset, generation 5 [ 378.411557] firewire_ohci: IRQ 00010000 selfID [ 378.411567] firewire_ohci: 1 selfIDs, generation 5, local node ID ffc0 [ 378.411570] firewire_ohci: selfID 0: 807f8956, phy 0 [---] S400 gc=63 +15W Lci [ 378.411572] firewire_core: skipped bus generations, destroying all nodes [ 378.908018] firewire_core: rediscovered device fw0 and when i plug it in I get: [ 406.438553] firewire_ohci: IRQ 00000010 AR_req [ 406.438559] firewire_ohci: AR evt_bus_reset, generation 6 with stuff like this every now and then: [ 387.448656] firewire_ohci: IRQ 00200000 cycle64Seconds I ran the test program, and it leads me to believe both my cards and the cables are ok (but see my other mail). so: - is that other chip (VIA VT6306) ok? - has anyone a similar card? what have you set your jumpers to? - there is another 8-pin jumper block, anyone knows what that is good for? - can I just plug in my camera, and check the voltage on the cable? - any other ideas? thanks robert -- Robert Lemmen http://www.semistable.com |
From: Stefan R. <st...@s5...> - 2011-11-04 09:52:44
|
On Nov 04 Allan Duncan wrote: > On 04/11/11 05:05, Stefan Richter wrote: [storage device unplug bugs] > > AFAIU a thorough rework of the block layer with introduction of proper > > reference counting is required to get this class of bugs really fixed. [...] > Is it viable to add reference counting to your corner of the world so > that at least the 1394 subsystem keeps itself nice? As far as I can tell, the race conditions in block request queue management happen at a level at which the transport drivers (1394, SATA, USB...) are unable to save the day with their own reference counting or locking. -- Stefan Richter -=====-==-== =-== --=-- http://arcgraph.de/sr/ |
From: Allan D. <al...@fa...> - 2011-11-03 22:16:27
|
On 04/11/11 05:05, Stefan Richter wrote: > On Oct 05 Stefan Richter wrote: >> PS, unrelated to the 1394 subsystem but related to 1394 storage devices: >> The last few kernel releases had multiple bugs WRT hot removal of hard >> disks, CD ROM drives, card readers and so on. The word is that the last >> known one of these bugs has been fixed in 3.1-rc9 from yesterday. > > Not true. Sadly, the Linux block layer remains buggy WRT device removal. > AFAIU a thorough rework of the block layer with introduction of proper > reference counting is required to get this class of bugs really fixed. > Considering that there was a steady, frequent stream of related bug reports > for about a year now, and presumed fix after presumed fix was applied > without ultimate progress in the matter, it is easy to make an estimate > how quick this is going to be resolved. > > While I did not see a kernel panic anymore myself lately, processes and > kernel threads tend to fall into uninterruptible wait state if a storage > device is removed. > > Note to self: Always kill udisks-deamon before removing a CD-ROM drive or > a card reader, to reduce exposure to race conditions. Is it viable to add reference counting to your corner of the world so that at least the 1394 subsystem keeps itself nice? |
From: Stefan R. <st...@s5...> - 2011-11-03 18:05:44
|
On Oct 05 Stefan Richter wrote: > PS, unrelated to the 1394 subsystem but related to 1394 storage devices: > The last few kernel releases had multiple bugs WRT hot removal of hard > disks, CD ROM drives, card readers and so on. The word is that the last > known one of these bugs has been fixed in 3.1-rc9 from yesterday. Not true. Sadly, the Linux block layer remains buggy WRT device removal. AFAIU a thorough rework of the block layer with introduction of proper reference counting is required to get this class of bugs really fixed. Considering that there was a steady, frequent stream of related bug reports for about a year now, and presumed fix after presumed fix was applied without ultimate progress in the matter, it is easy to make an estimate how quick this is going to be resolved. While I did not see a kernel panic anymore myself lately, processes and kernel threads tend to fall into uninterruptible wait state if a storage device is removed. Note to self: Always kill udisks-deamon before removing a CD-ROM drive or a card reader, to reduce exposure to race conditions. -- Stefan Richter -=====-==-== =-== ---== http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2011-11-03 08:47:08
|
Stefan Richter wrote: > "Maximum power consumption for the A601f-HDR is 1.7 W at 12 VDC." > > A PCI slot has a single +12V pin. I don't know what its current and > ripple ratings are, whether PCI devices share a power budget on the > +12V rail. PCI cards have two sense lines to tell the motherboard if they use up to 7.5, 15, or 25 W. (I'd guess there are as many motherboards that make use of this information as there are FireWire power managers.) However, the maximum 12 V current is 500 mA, so bus power (with up to 1.5 A) must come from a separate power connector. Regards, Clemens |
From: Stefan R. <st...@s5...> - 2011-11-02 23:47:13
|
On Nov 02 Robert Lemmen wrote: > The firewire card is PCI (not pcmcia or anything weird), and i was > expecting it to provide bus power. but it's not one of the cards that > have an extra power supply connector... From the Basler A601f-HDR user manual: "Power must be supplied to the camera via the IEEE 1394 cable. Nominal input voltage is +12.0 VDC, however, the camera will operate properly on any input voltage from +8.0 VDC to +36.0 VDC as specified in the IEEE 1394 standard. Maximum power consumption for the A601f-HDR is 1.7 W at 12 VDC. Ripple must be less than 1%." A PCI slot has a single +12V pin. I don't know what its current and ripple ratings are, whether PCI devices share a power budget on the +12V rail. (PCI also has got +3.3V, +5V, -12V power rails. The Agere FW323 link and phy is a 3.3V powered device, so it is at least unlikely that the 1394 controller card itself uses the +12V rail for anything else besides 1394 bus power.) -- Stefan Richter -=====-==-== =-== ---== http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2011-11-02 19:31:28
|
On Wed, Nov 2, 2011 at 1:08 PM, Robert Lemmen <rob...@se...> wrote: > stefan, folks, > > On Wed, Nov 02, 2011 at 10:01:33AM +0100, Stefan Richter wrote: >> This not happening could be caused by >> - defect of the FireWire port of the PC, >> - cable defect, >> - defect of the FireWire port or of the logic board of the camera, >> - insufficient power supply of the camera. > > an excellent checklist! I'll go off and verify all of this. The last > item seems especially suspicious, the camera is bus-powered after all. > The firewire card is PCI (not pcmcia or anything weird), and i was > expecting it to provide bus power. but it's not one of the cards that > have an extra power supply connector... > This is more for me than you, but it might help you.... If you have a 2nd firewire controller (card), plug one card into the other and run: https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c If it finds an error, then the problem is one of the cards or cable and probably not the camera. Or the program is whacked. This is something a friend wrote, I haven't gotten around to testing it other than "it runs! great! thanks! I'll buy you a beer!" -- Carl K |
From: Robert L. <rob...@se...> - 2011-11-02 18:08:19
|
stefan, folks, On Wed, Nov 02, 2011 at 10:01:33AM +0100, Stefan Richter wrote: > This not happening could be caused by > - defect of the FireWire port of the PC, > - cable defect, > - defect of the FireWire port or of the logic board of the camera, > - insufficient power supply of the camera. an excellent checklist! I'll go off and verify all of this. The last item seems especially suspicious, the camera is bus-powered after all. The firewire card is PCI (not pcmcia or anything weird), and i was expecting it to provide bus power. but it's not one of the cards that have an extra power supply connector... cu robert -- Robert Lemmen http://www.semistable.com |
From: Stefan R. <st...@s5...> - 2011-11-02 09:01:46
|
On Nov 01 Robert Lemmen wrote: [...] > i tail /var/log/kern.log and modprobe firewire_ohci debug=7 (after > removing it first of course): > > Nov 1 23:40:08 sandbender kernel: [54557.082719] firewire_ohci 0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 > Nov 1 23:40:08 sandbender kernel: [54557.152008] firewire_ohci: Added fw-ohci device 0000:03:01.0, OHCI version 1.0 > Nov 1 23:40:08 sandbender kernel: [54557.152014] firewire_ohci: IRQ 00000010 AR_req > Nov 1 23:40:08 sandbender kernel: [54557.152020] firewire_ohci: AR evt_bus_reset, generation 147 > Nov 1 23:40:08 sandbender kernel: [54557.152023] firewire_ohci: IRQ 00010000 selfID > Nov 1 23:40:08 sandbender kernel: [54557.152034] firewire_ohci: 1 selfIDs, generation 147, local node ID ffc0 > Nov 1 23:40:08 sandbender kernel: [54557.152037] firewire_ohci: selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci > Nov 1 23:40:09 sandbender kernel: [54557.652109] firewire_core: created device fw0: GUID 0000d100802a6abc, S400 > > if i leave it like that i get this every now and then: > > Nov 1 23:41:06 sandbender kernel: [54614.877141] firewire_ohci: IRQ 00200000 cycle64Seconds This is all correct and expected. > if i plug in my camera I get: > > Nov 1 23:41:36 sandbender kernel: [54645.307192] firewire_ohci: AR evt_bus_reset, generation 148 [...] This on the other hand is far less than what should happen. Among else you should get one or two "selfID" IRQ events which contain 2 selfIDs --- one of the FireWire controller and one of the camera. After that there should be a bunch of AT and AR events when firewire-core probes the camera. Finally, firewire-core should report something like "created device fw1: GUID 003053.........., S400". This not happening could be caused by - defect of the FireWire port of the PC, - cable defect, - defect of the FireWire port or of the logic board of the camera, - insufficient power supply of the camera. -- Stefan Richter -=====-==-== =-== ---=- http://arcgraph.de/sr/ |