linux1394-user Mailing List for IEEE 1394 for Linux (Page 5)
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...> - 2014-10-10 07:31:29
|
Daniel Robbins wrote: > With kernel 3.17.0, it now looks like firewire-ohci is misbehaving: > > [ 2.723177] firewire_ohci 0000:06:00.0: failed to allocate interrupt 20 > [ 2.723206] firewire_ohci: probe of 0000:06:00.0 failed with error -5 > > 3.16.0 worked with your fixes... now that the fixes are in 3.17.0, firewire-ohci appears broken. This has nothing to do with the sound driver. Please show the "lspci -nnvv" entry of the controller, and the entire log. Is there any other driver on IRQ 20? Regards, Clemens |
From: Takashi S. <o-t...@sa...> - 2014-10-10 07:09:27
|
On Oct 10 2014 16:06, Clemens Ladisch wrote: > Daniel Robbins wrote: >> With kernel 3.17.0, it now looks like firewire-ohci is misbehaving: >> >> [ 2.723177] firewire_ohci 0000:06:00.0: failed to allocate interrupt 20 >> [ 2.723206] firewire_ohci: probe of 0000:06:00.0 failed with error -5 >> >> 3.16.0 worked with your fixes... now that the fixes are in 3.17.0, firewire-ohci appears broken. > > This has nothing to do with the sound driver. Indeed. > Please show the "lspci -nnvv" entry of the controller, and the entire log. > Is there any other driver on IRQ 20? Output from /proc/interrupts will be our help, too. Regards Takashi Sakamoto o-t...@sa... |
From: Stefan R. <st...@s5...> - 2014-07-26 11:51:29
|
Hi, here are release notes for the IEEE 1394 subsystem of kernel 3.16 (final release to be available soon, currently at -rc6): snd-fireworks - New ALSA driver, implemented by Takashi Sakamoto, for FireWire audio devices which are based on the Echo Digital Audio Fireworks platform. The following devices are supported: Echo AudioFire 12/ 8 (until 2009 July) Echo AudioFire 2/ 4/ Pre8/ 8 (since 2009 July) Echo Fireworks 8/ HDMI Gibson Robot Interface Pack/ GoldTop Mackie Onyx 400F/ 1200F snd-bebob - New ALSA driver, implemented by Takashi Sakamoto, for FireWire audio devices based on BridgeCo DM1000/DM1100/DM1500 chipsets with BeBoB firmware, in particular: Acoustic Reality eAR Master One Apogee X-FireWire card for DA/AD/DD-16X and Rosetta 200/400 Apogee Ensemble Behringer Digital Mixer X32 series (X-UF card) Behringer XENIX UFX 1204/ 1604 BridgeCo RDAudio1/ Audio5 CME Matrix K Edirol FA-66/ FA-101 ESI Quatafire 610 Focusrite Saffire, Saffire LE, Saffire PRO 10 I/O, Saffire PRO 26 I/O (the older silver model; newer Saffire PRO models use a different chipset) iCON FireXon Lynx Aurora 8/ 16 with LT-FW Mackie d.2 with FireWire option Mackie Onyx 1220/ 1620/ 1640 with FireWire I/O card M-Audio FireWire 1814, ProjectMix I/O M-Audio FireWire 410/ AudioPhile/ Solo M-Audio Ozonic, NRV10, ProFire LightBridge Phonic Helix Board 12/18/24 FireWire MKII Phonic Helix Board 12/18/24 Universal PreSonus FireBox, FP10 (FirePod), Inspire 1394 Prism Sound Orpheus, ADA-8XR Stanton FinalScratch 2 (ScratchAmp) Tascam IF-FW/DM TerraTec Aureon 7.1 FireWire TerraTec EWS MIC2, EWS MIC8 TerraTec Phase 24FW, Phase X24FW, Phase 88RackFW Yamaha GO44, GO46 snd-firewire-lib - several extensions implemented by Takashi Sakamoto in order to support the two new drivers Many of the mentioned audio devices are also supported by the FFADO userspace drivers (and have been for some time) [http://ffado.org/]. The new ALSA kernel drivers are an alternative to (or replacement of) the sound streaming portion of FFADO, i.e. the part which implements PCM and MIDI I/O. Extra userspace software like ffado-mixer remains required for control of device features like router, mixer, clock source, port modes, and so on. Takashi Sakamoto published an extensive report on the new drivers: https://github.com/takaswie/alsa-firewire-report/blob/master/firewire.pdf -- Stefan Richter -=====-====- -=== ==-=- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2014-07-26 11:43:27
|
Hi all, somewhat late, here are IEEE 1394 subsystem release notes for the last two kernel releases: *Linux 3.14, released on March 30* firewire-net - Fix a use-after-free bug which could occur after transmission failures. firewire-ohci - The new module parameter "remote_dma" (default = N, enable unfiltered remote DMA = Y) replaces the former build-time option CONFIG_FIREWIRE_OHCI_REMOTE_DMA. (This kernel configuration option was located in the "Kernel hacking" menu, item "Remote debugging over FireWire with firewire-ohci".) It is therefore now possible to switch on RDMA at runtime on all kernels with firewire-ohci loaded or built-in, for example for remote debugging, without the need for a custom build option. - Fix initialization failure with Agere FW323 and some other Agere/LSI controllers. These failures were a regression since Linux v3.10 inclusive. Also fixed in v3.13.7, v3.12.15, v3.11.10.7, v3.10.41. *Linux 3.15, released on June 8* firewire-core, firewire-ohci - A feature was added in v3.14 to enable remote DMA from and to memory outside the 32 bit range of physical addresses, which is possible at least with LSI FW643 controllers. This feature clashed with at least one vendor-specific device control protocol and was therefore reverted in v3.15 and v3.14.7. -- Stefan Richter -=====-====- -=== ==-=- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2014-06-09 14:25:42
|
On Jun 09 Alex John wrote: >>>> On Sat, 2014-06-07 at 13:50 +0800, Alex John wrote: >>>>> The cable is spliced >>>>> and joined again using molex connectors and shielded with aluminum >>>>> foil for extra protection. We are thinking that it shuts down because >>>>> of EMI. [...] > The cameras that die are always the external cameras. The difference is > that we have cut the cables and used our own underwater cables including > connectors. The camera that is in the hull connected straight using the > original FireWire cable never has any issues. Both cameras are running > on the same power system. Did you use stock 1394 cable material, or other material? Here are some points from the IEEE 1394 reference cable constructions concerning the shields and their connections to the plugs, for comparison: - Each of the two data pairs has got its own shield. In addition, there is an outer shield around everything, including the power pair. - In 4-4, 4-6, 4-9, 6-9 pin cables, the two inner shields around the data pairs shall be in contact with each other and shall be isolated from the outer shield. - In 9-9 pin cables, the two inner shields should be isolated from each other and shall be isolated from the outer shield. - The inner shields shall be connected with the 4-pin connector's plug shield, or with the 6-pin connector's VG pin, or with the 9-pin connector's dedicated Twisted Pair A Ground Reference and Twisted Pair B Ground Reference pins, respectively. - The outer shield shall be connected with the 6- or 9-pin connector's plug shield. [These and the other parameters of the reference cable constructions, such as permissible length and wire gage, are just examples which work, not strict requirements. Actual requirements of the standard are specified in terms of performance criteria, as far as I understand, not being an electrical engineer.] Did you als modify anything at the device side, i.e. boards or chassis? If so, the question is whether termination and isolation of the signal pairs, power pair, and shields are affected by those modifications. -- Stefan Richter -=====-====- -==- -=--= http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2014-06-09 14:01:26
|
Alex John wrote: > we have cut the cables and used our own underwater cables including > connectors. The camera that is in the hull connected straight using > the original FireWire cable never has any issues. So you made your own FireWire cables? How did you ensure that these cables conform to the IEEE-1394 specification? Did you test them? <http://www.1394ta.org/developers/PublicSpecs/2009008.pdf> Regards, Clemens |
From: Carl K. <ca...@pe...> - 2014-06-09 13:41:17
|
On Mon, Jun 9, 2014 at 6:04 AM, Alex John <al...@nu...> wrote: > The cameras that die are always the external cameras. The difference is > that we have cut the cables and used our own underwater cables including > connectors. The camera that is in the hull connected straight using the > original FireWire cable never has any issues. Both cameras are running on > the same power system. The cameras that die are always the external cameras, and only when submerged, right? Would it be possible to do a test with the same cameras inside? Ideally with a new cable and then as much of the modified cabling as possible. Also, can we get a picture of the underwater cables including connectors? Long shot: can you take the external cameras out of the system and loop the firewire back to the other firewire port and see if there is any odd behavior? The thought is maybe the system side firewire chips may be the ones being disrupted by dirty signals. -- Carl K |
From: Alex J. <al...@nu...> - 2014-06-09 11:04:14
|
> On 9 Jun, 2014, at 18:41, Stefan Richter <st...@s5...> wrote: > >> On Jun 07 Damien Douxchamps wrote: >>> On Sat, 2014-06-07 at 13:50 +0800, Alex John wrote: >>> I am using a pair of FireWire cameras (Guppy/Guppy Pro) connected via >>> an AVT pci controller card (TI-TSB43AB22A). I'm using them as vision >>> cameras for an underwater autonomous vehicle. I'm facing a very weird >>> issue where the cameras shut down when certain thrusters are fired. >>> The device disappears from the device list and has to be physically >>> replugged to raise it again. >> >> That looks like a power supply issue to me... At least I would start >> investigating there with a multimeter to see if/how the voltage drops on >> the supply rails when the motors run. If you use batteries or an >> umbilical (any other option anyway? :) you may get voltage drops due to >> batteries limitations or wire resistance. >> We already filter the power to a certain degree and the wire resistance was measures and found to be okayish. I can get the exact measurements but this brings me to the issue that I forgot to mention which I'll detail below- >> Next step is using a scope to check the noise on the supply voltage, if >> the motors run on the same supply as the cameras. > [...] > > I too think that this sounds more like instability or noise on the power > supply rails rather than HF noise on the signal lines. > > Incidentally, I too have got a "device disappears" problem at home with a > cable TV box (FireDTV C/CI): Often when another electrical device is > switched on (or sometimes when switched off) at the 230 V 50 Hz power > grid --- e.g. a PC, monitor, RAID enclosure, or vacuum cleaner ---, the bus > with the FireDTV sees a bus reset, and the phy of the FireDTV is no longer > present according to selfID reception. To recover, the FireDTV has to be > plugged out and in again. > > The FireDTV has a TSB41AB2 phy according to lsfirewirephy from jujuutils. > I have got some other devices with TSB41AB2 phy though which do not > exhibit such an issue. > > Usually I power the FireDTV from one or another PC's FireWire bus power. > The PCs don't exhibit any other stability issues though, neither do any of > a bunch of other bus-powered FireWire devices of various kinds. The PCs' > PSUs (Seasonic models from different generations) are said to deliver > comparatively clean and stable output. > > From a few brief tests it seems there are two ways to fix this issue: > - Powering the FireDtV from a separate 12 V PSU, or > - putting a ground loop filter (a capacitive coupler, I think) between > TV cable and FireDTV. > > So I suspect that my particular issue is not actually caused by a voltage > drop on the FireWire bus on its own but by a current between FireWire > ground and TV cable ground. Thanks for the suggestions, I'll look into it but there's another aspect of the problem that I forgot to mention. The cameras that die are always the external cameras. The difference is that we have cut the cables and used our own underwater cables including connectors. The camera that is in the hull connected straight using the original FireWire cable never has any issues. Both cameras are running on the same power system. > -- > Stefan Richter > -=====-====- -==- -=--= > http://arcgraph.de/sr/ Thanks Alex |
From: Stefan R. <st...@s5...> - 2014-06-09 10:42:02
|
On Jun 07 Damien Douxchamps wrote: > On Sat, 2014-06-07 at 13:50 +0800, Alex John wrote: > > I am using a pair of FireWire cameras (Guppy/Guppy Pro) connected via > > an AVT pci controller card (TI-TSB43AB22A). I'm using them as vision > > cameras for an underwater autonomous vehicle. I'm facing a very weird > > issue where the cameras shut down when certain thrusters are fired. > > The device disappears from the device list and has to be physically > > replugged to raise it again. > > That looks like a power supply issue to me... At least I would start > investigating there with a multimeter to see if/how the voltage drops on > the supply rails when the motors run. If you use batteries or an > umbilical (any other option anyway? :) you may get voltage drops due to > batteries limitations or wire resistance. > > Next step is using a scope to check the noise on the supply voltage, if > the motors run on the same supply as the cameras. [...] I too think that this sounds more like instability or noise on the power supply rails rather than HF noise on the signal lines. Incidentally, I too have got a "device disappears" problem at home with a cable TV box (FireDTV C/CI): Often when another electrical device is switched on (or sometimes when switched off) at the 230 V 50 Hz power grid --- e.g. a PC, monitor, RAID enclosure, or vacuum cleaner ---, the bus with the FireDTV sees a bus reset, and the phy of the FireDTV is no longer present according to selfID reception. To recover, the FireDTV has to be plugged out and in again. The FireDTV has a TSB41AB2 phy according to lsfirewirephy from jujuutils. I have got some other devices with TSB41AB2 phy though which do not exhibit such an issue. Usually I power the FireDTV from one or another PC's FireWire bus power. The PCs don't exhibit any other stability issues though, neither do any of a bunch of other bus-powered FireWire devices of various kinds. The PCs' PSUs (Seasonic models from different generations) are said to deliver comparatively clean and stable output. From a few brief tests it seems there are two ways to fix this issue: - Powering the FireDtV from a separate 12 V PSU, or - putting a ground loop filter (a capacitive coupler, I think) between TV cable and FireDTV. So I suspect that my particular issue is not actually caused by a voltage drop on the FireWire bus on its own but by a current between FireWire ground and TV cable ground. -- Stefan Richter -=====-====- -==- -=--= http://arcgraph.de/sr/ |
From: Damien D. <dd...@do...> - 2014-06-07 07:27:49
|
Hi Alex, On Sat, 2014-06-07 at 13:50 +0800, Alex John wrote: > Good morning, > > I am using a pair of FireWire cameras (Guppy/Guppy Pro) connected via > an AVT pci controller card (TI-TSB43AB22A). I'm using them as vision > cameras for an underwater autonomous vehicle. I'm facing a very weird > issue where the cameras shut down when certain thrusters are fired. > The device disappears from the device list and has to be physically > replugged to raise it again. That looks like a power supply issue to me... At least I would start investigating there with a multimeter to see if/how the voltage drops on the supply rails when the motors run. If you use batteries or an umbilical (any other option anyway? :) you may get voltage drops due to batteries limitations or wire resistance. Next step is using a scope to check the noise on the supply voltage, if the motors run on the same supply as the cameras. > Is anyone here familiar with this kind if issue? The cable is spliced > and joined again using molex connectors and shielded with aluminum > foil for extra protection. We are thinking that it shuts down because > of EMI. > > Reducing the data rate does not seem to help. All thrusters firing as > fast as possible on land does not seem to cause any issues but as soon > as the vehicle is in water we lose the FireWire devices. I imagine that motors won't draw maximum current above water as the medium is much less dense. The motors' current will be higher underwater (higher torque required) and the supply rails may then drop significantly. OTOH 1394 cameras have DC-DC converters to deal with the varying supply voltage found on 1394 busses, so they should be able to cope with transients. Of course the cams may fail if you supply them at a nominally low voltage (e.g. 5V) and the voltage drops further down. What kind of supply are you using? If you supply 12V to the cameras they should be able to cope with supply variation pretty well. Damien -- Damien 高原 Douxchamps http://damien.douxchamps.net/ |
From: Alex J. <al...@nu...> - 2014-06-07 05:50:56
|
Good morning, I am using a pair of FireWire cameras (Guppy/Guppy Pro) connected via an AVT pci controller card (TI-TSB43AB22A). I'm using them as vision cameras for an underwater autonomous vehicle. I'm facing a very weird issue where the cameras shut down when certain thrusters are fired. The device disappears from the device list and has to be physically replugged to raise it again. Is anyone here familiar with this kind if issue? The cable is spliced and joined again using molex connectors and shielded with aluminum foil for extra protection. We are thinking that it shuts down because of EMI. Reducing the data rate does not seem to help. All thrusters firing as fast as possible on land does not seem to cause any issues but as soon as the vehicle is in water we lose the FireWire devices. Any input would be appreciated! Thanks alex |
From: Stefan R. <st...@s5...> - 2014-05-09 22:10:15
|
> Stefan Richter escreveu: > > a) The PowerLook 1100 works OK with VueScan 9.0.96 on OS X 10.4. > > > > b) My other FireWire scanner, the Epson Perfection 2450 Photo, works OK > > with VueScan 9.2.21 x64 on Gentoo Linux AMD64, kernel 3.9. > > > > c) Latter system and software, but UMAX PowerLook 1100, gets this far: > > - PowerLook 1100 is detected properly by kernel and VueScan. > > - Starting a preview in VueScan results in two messages > > "kernel: scsi 184:0:0:0: timing out command, waited 120s" > > but eventually succeeds. > > The scanner isn't particularly fast to begin with, but having to > > wait four extra minutes is a bit much of course... ;-/ > > - After that, starting a scan sets the scanner immediately into action > > and goes through the entire scan just fine, without command timeout. PS: More tests revealed that it is more likely for setup "c" to get stuck very early at a scan, or to produce an incomplete and garbled scan (perhaps with mostly random junk of uninitialized buffer memory). The kind of delayed but in the end successful scanning like in the earliest few tests is more an exception then the rule. In other words, my further results came closer to what you are getting. -- Stefan Richter -=====-====- -=-= -=-=- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2014-05-09 22:03:50
|
On Apr 01 Renan Calliari wrote: > Any progress in firewire SBP2 module? > I tried o make my scanner work with the latest kernel from fedora 20 > without success. Sorry for remaining quiet for so long. I have been looking into some very simple aspects (Config ROM parameters; the various existing firewire-sbp2 quirks that you already checked without success IIRC, and things like that). I didn't learn anything useful so far, unfortunately. I have been planning to check some more points, notably: - Does the PowerLook perhaps expect ORB addresses to be aligned at more even addresses, e.g. ORB size aligned? - Does it perhaps require simple buffers instead of scatter-gather buffers? - Another option that I could pursue would be to log the packet traffic with VueScan on OS X (using a PCILynx card for packet capture), compare that with that of VueScan on Linux, and hopefully find some significant difference there. While the third option could be quite time-consuming, the first two would presumably involve just a moderate amount of kernel manipulation and testing. I am chronically short of spare time though... -- Stefan Richter -=====-====- -=-= -=--= http://arcgraph.de/sr/ |
From: Renan C. <ren...@te...> - 2014-04-01 22:19:45
|
Hi Stefan, Any progress in firewire SBP2 module? I tried o make my scanner work with the latest kernel from fedora 20 without success. Renan Stefan Richter escreveu: > Hi Renan, > > about a week ago I received a UMAX PowerLook 1100, with transparency > option even. I didn't get around to actually start testing it until today. > > My first results: > > a) The PowerLook 1100 works OK with VueScan 9.0.96 on OS X 10.4. > > b) My other FireWire scanner, the Epson Perfection 2450 Photo, works OK > with VueScan 9.2.21 x64 on Gentoo Linux AMD64, kernel 3.9. > > c) Latter system and software, but UMAX PowerLook 1100, gets this far: > - PowerLook 1100 is detected properly by kernel and VueScan. > - Starting a preview in VueScan results in two messages > "kernel: scsi 184:0:0:0: timing out command, waited 120s" > but eventually succeeds. > The scanner isn't particularly fast to begin with, but having to > wait four extra minutes is a bit much of course... ;-/ > - After that, starting a scan sets the scanner immediately into action > and goes through the entire scan just fine, without command timeout. > > d) After that I tried skanlite 1.0 + sane-backends 1.0.23-r1 on the same > Gentoo Linux box. It discovered the PowerLook but crashed immediately > when I initiated the preview. However, SANE's UMAX SCSI backend does > not have official support for PowerLook 1100 yet, so nobody is to blame. > > So in this single first test on Linux, VueScan + PowerLook 1100 did > actually work for me, but there were command timeouts which prolonged the > preview. Warm-up doesn't take so long; this is about 25 seconds or so on > OS X, judging from the time between pressing the preview buttun and the > moment when the scanner starts to blink its LED and to make noises. > > I don't have a precise idea which step to take next, but one thing which > comes to my mind is to look at firewire-sbp2's way to align the commands > in memory. |
From: A&M A. <new...@am...> - 2014-04-01 09:44:01
|
Contacts List ------------------------------------------------ We have removed your email address from our list. We're sorry to see you go. ----------------------------------- Did you forward your email to a friend, and they accidentally clicked the unsubscribe link? If this was a mistake, you can re-subscribe at: http://list.mlgn2eu.com/subscribe?u=8ae5780d22688d976ebce9d8fb3db81c&id=0f55a446 ----------------------------------- For questions or comments, please contact us at: new...@am... |
From: Stefan R. <st...@s5...> - 2014-03-02 15:26:29
|
On Feb 27 Clemens Ladisch wrote: > llESEll Man wrote: > > Not sure if I'm having a design bug in the motherboard for this listing > > thirty empty devices, which I guess are causing problems to run correctly. > > > > 03:00.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) > > 03:01.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) > > 03:02.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) > > ... > > Check the PCI connector for dirt or a short circuit. > > If this doesn't help, you have a hardware bug on either the motherboard or > the PCI card; you have to try with another board/card to check which one > is broken. For the linux1394-user archive: The cause was mechanical contact between graphics card and 1394 card. http://sourceforge.net/p/ffado/mailman/message/32041477/ -- Stefan Richter -=====-====- --== ---=- http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2014-02-27 21:10:00
|
llESEll Man wrote: > Not sure if I'm having a design bug in the motherboard for this listing > thirty empty devices, which I guess are causing problems to run correctly. > > 03:00.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) > 03:01.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) > 03:02.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) > ... Check the PCI connector for dirt or a short circuit. If this doesn't help, you have a hardware bug on either the motherboard or the PCI card; you have to try with another board/card to check which one is broken. Regards, Clemens |
From: llESEll M. <spl...@gm...> - 2014-02-27 18:23:47
|
Hi The first greet, is the first time I write to you. Not sure if I'm having a design bug in the motherboard for this listing thirty empty devices, which I guess are causing problems to run correctly.Not sure if I'm having a design bug in the motherboard for this listing thirty empty devices, which I guess are causing problems to run correctly. The Mobo is: MSI 760GM-P23/FX (MS-7641) With a pci card pluged: FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) And im trying to make work a: Focusrite Saffire Pro 24 Dsp The kernel im using is: Linux systemost 3.8.0-32-lowlatency #24-Ubuntu SMP PREEMPT Tue Oct 15 20:28:21 UTC 2013 i686 athlon i386 GNU/Linux and lsmod | grep -e 1394 -e firewire firewire_ohci 35914 0 firewire_core 62086 1 firewire_ohci crc_itu_t 12627 1 firewire_core Strange things begins in dmesg with 30 of this: 01-01-14 00:00:00 irewire_ohci 0000 3:00.0: failed to reset ohci card 01-01-14 00:00:00 irewire_ohci probe of 0000:03:00.0 failed with error -16 Maybe the system stunt? but it seems everything allright beacuse: 02-01-14 00:00:00 irewire_core 0000 3:1f.0: created device fw0: GUID 00308d0121d4d49a, S400 15-01-14 00:00:00 irewire_core 0000 3:1f.0: created device fw1: GUID 00130e0402000dd1, S400 i know lspci is not showing the saffire - lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] RS780 Host Bridge 00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI bridge (ext gfx port 0) 00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 1) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:12.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0 USB OHCI1 Controller 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 3c) 00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 IDE Controller 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller 00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge 00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 650 Ti] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GK106 HDMI Audio Controller (rev a1) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) 03:00.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) 03:01.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) 03:02.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) 03:03.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) 03:04.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) 03:05.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 61) 03:06.0 FireWire (IEEE 1394): LSI Corpo... - bla bla bla... to 30 devices the version of libraw1394 2.0.7-1ubuntu1 ,ffado 2.1.9999 and jackd 6:1.9.10~git20140122-1+kxstudio1~precise2 i think are all the related, ffado<jack simply says "can't find the jack-dbus server" and can't find the way to get nothing else and is needed a bus reset to try again depends on which distro im using that works or i have to reboot to start again. lsfirewirephy drop timeout timeout lsfirewire fw0: Linux Firewire Juju fw1: Focusrite SAFFIRE_PRO_24DSP basicaly is well detected it seems like is bad redirected i don't know exactly what i have to do I have two fronts opends in the ffado-users mail and in linux musicians but I guess it is more logical to start from the beginning I would like if you could offer any help or ideas you can try to try to run the sound card. sorry if I have good length in the explanation, and have tried many things which can not exactly be really useful. thanks in advance and best regards. |
From: Stefan R. <st...@s5...> - 2014-01-29 21:44:41
|
On Jan 29 pho...@ya... wrote: > any chance that my firewire errors/problems with the Freecom Quattro 3.0 > will be eventually solved - or shall I rather return the external hdd as > defective and be done with it ? Now that I suspect buggy firmware, and given that I at least currently don't have the resources to examine the firmware behavior further in order to judge whether this could be worked around, suggest that you return it if you can. (Unless the USB or eSATA functions of it were a workable alternative for you.) > What would be a known working external firewire hdd ? Are the new Lacie > external drives any good ? I am not up-to-date in this matter. -- Stefan Richter -=====-====- ---= ===-= http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2014-01-29 21:33:59
|
On Jan 22 pho...@ya... wrote: > here is all the info that I collected about the errors with the Freecom > Quattro 3.0 attached via firewire. > > I am now running 3.13 > #> uname -r -v > 3.13.0-031300-generic #201401192235 SMP Mon Jan 20 03:36:48 UTC 2014 > > I have increased log verbosity for creating this log as per your suggestion. > > I have not yet tried to connect that Freecom Quattro 3.0 to another PC > with firewire. However I got hold of another Western Digital disk at a > friend's place, connected it via firewire, and it worked just fine. So > maybe the Freecom Quattro 3.0 is just crappy engineering :( > > Best regards > P. > > > [crapp_fw0_config_rom text/plain (1342 bytes)] > ROM header and bus information block > ----------------------------------------------------------------- > 400 04047561 bus_info_length 4, crc_length 4, crc 30049 > 404 31333934 bus_name "1394" > 408 f000a222 irmc 1, cmc 1, isc 1, bmc 1, pmc 0, cyc_clk_acc 0, > max_rec 10 (2048), max_rom 2, gen 2, spd 2 (S400) > 40c 334fc000 company_id 334fc0 | > 410 33abb470 device_id 0033abb470 | EUI-64 334fc00033abb470 [...] > 454 4a756a75 "Juju" This is the Configuration ROM of the Linux node. Almost all of it in there is defined by the firewire-core kernel driver. A few things aretaken from the hardware though, among them the globally unique ID in EUI-64 form, which is 334fc00033abb470 in the instance of your controller. The company ID part of it, 334fc0, is not a valid OUI from IEEE RAC. However, it is not likely in my opinion that the firmware of the Freecom Quattro cares about that. An SBP-2 target firmware uses the initiator's EUI-64 in order to keep track of the source of requests to the target, but for that purpose the target just needs to store and compare EUI-64 as 64 bits wide blobs without regard to the inner structure of those blobs. [crapp_fw1_config_rom text/plain (2205 bytes)] > ROM header and bus information block > ----------------------------------------------------------------- > 400 0404e11a bus_info_length 4, crc_length 4, crc 57626 (should be > 34316) 404 31333934 bus_name "1394" > 408 00ffb113 irmc 0, cmc 0, isc 0, bmc 0, pmc 0, cyc_clk_acc 255, > max_rec 11 (4096), max_rom 1, gen 1, spd 3 (S800) > 40c 0001db92 company_id 0001db | > 410 00188188 device_id 9200188188 | EUI-64 0001db9200188188 [...] > 44c 46524545 "FREE" > 450 434f4d00 "COM" > > unit directory at 460 > ----------------------------------------------------------------- > 460 000d1486 directory_length 13, crc 5254 > 464 1200609e specifier id: INCITS > 468 13010483 version: SBP-2 > 46c 21000001 SBP-2 revision 1 = SBP-3 > 470 54004008 --> SBP-2 management agent CSR at fffff0010020 > 474 3a003c09 SBP-2 unit char.: mgt_ORB_timeout 30s, ORB_size 9 quadlets > 478 3800609e SBP-2 command set spec id: INCITS > 47c 390104d8 SBP-2 command set: SCSI Primary Commands 2 and related standards > 480 3b000000 SBP-2 command set revision > 484 3c000102 SBP-2 firmware revision 000102 > 488 3d000003 SBP-2 reconnect timeout: max_reconnect_hold 4s > 48c 144e0000 SBP-2 logical unit number: ordered 1, type RBC, lun 0000 [...] > 4ac 48617264 "Hard" > 4b0 20447269 " Dri" > 4b4 76652051 "ve Q" > 4b8 75617474 "uatt" > 4bc 726f2033 "ro 3" This is of course the Configuration ROM of the disk. I am not noticing anything suspicious or wrong in it. Unfortunately, it also does not tell more about the chipset in the device. [dmesg.txt text/plain (7621 bytes)] > [ 817.327764] firewire_ohci 0000:03:01.4: 2 selfIDs, generation 10, local node ID ffc0 > [ 817.327781] firewire_ohci 0000:03:01.4: selfID 0: 807f8880, phy 0 [p..] S400 gc=63 +0W Lc > [ 817.327791] firewire_ohci 0000:03:01.4: selfID 0: 817fc55e, phy 1 [--c] beta gc=63 ?W Li > [ 827.020976] firewire_ohci 0000:03:01.4: 2 selfIDs, generation 11, local node ID ffc0 > [ 827.020991] firewire_ohci 0000:03:01.4: selfID 0: 807f8880, phy 0 [p..] S400 gc=63 +0W Lc > [ 827.021001] firewire_ohci 0000:03:01.4: selfID 0: 817fc55e, phy 1 [--c] beta gc=63 ?W Li > [ 828.338669] scsi7 : SBP-2 IEEE-1394 > [ 828.338743] firewire_core 0000:03:01.4: created device fw1: GUID 0001db9200188188, S400 > [ 828.338749] firewire_core 0000:03:01.4: phy config: new root=ffc0, gap_count=5 > [ 828.339432] firewire_ohci 0000:03:01.4: 2 selfIDs, generation 12, local node ID ffc1 > [ 828.339437] firewire_ohci 0000:03:01.4: selfID 0: 8045c558, phy 0 [--p] beta gc=5 ?W L > [ 828.339441] firewire_ohci 0000:03:01.4: selfID 0: 814588c2, phy 1 [c..] S400 gc=5 +0W Lci > [ 828.554814] firewire_sbp2 fw1.0: logged in to LUN 0000 (0 retries) > [ 828.555818] scsi 7:0:0:0: Direct-Access ST3000DM 001-1CH166 PQ: 0 ANSI: 5 > [ 828.556903] sd 7:0:0:0: Attached scsi generic sg2 type 0 > [ 828.571738] sd 7:0:0:0: [sdb] 5860533152 512-byte logical blocks: (3.00 TB/2.72 TiB) > [ 828.587042] sd 7:0:0:0: [sdb] Write Protect is off > [ 828.587049] sd 7:0:0:0: [sdb] Mode Sense: 10 00 00 00 > [ 828.617036] sd 7:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > [ 828.699070] sdb: sdb1 > [ 828.761692] sd 7:0:0:0: [sdb] Attached SCSI disk > [ 851.912710] bio: create slab <bio-2> at 2 > [ 852.231531] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null) > [ 944.787481] firewire_sbp2 fw1.0: status write for unknown ORB > [ 954.211113] firewire_sbp2 fw1.0: status write for unknown ORB > [ 963.436402] sd 7:0:0:0: [sdb] Unhandled error code > [ 963.436407] sd 7:0:0:0: [sdb] > [ 963.436409] Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK > [ 963.436412] sd 7:0:0:0: [sdb] CDB: > [ 963.436413] Write(16): 8a 00 00 00 00 00 10 ff 89 00 00 00 04 00 00 00 > [ 963.436425] end_request: I/O error, dev sdb, sector 285182208 > [ 963.436463] EXT4-fs warning (device dm-0): ext4_end_bio:317: I/O error writing to inode 114434179 (offset 8388608 size 8388608 starting block 35647488) > [ 963.436466] Buffer I/O error on device dm-0, logical block 35647488 > [ 963.436470] Buffer I/O error on device dm-0, logical block 35647489 > [ 963.436473] Buffer I/O error on device dm-0, logical block 35647490 > [ 963.436475] Buffer I/O error on device dm-0, logical block 35647491 > [ 963.436482] Buffer I/O error on device dm-0, logical block 35647492 > [ 963.436484] Buffer I/O error on device dm-0, logical block 35647493 > [ 963.436486] Buffer I/O error on device dm-0, logical block 35647494 > [ 963.436488] Buffer I/O error on device dm-0, logical block 35647495 > [ 963.436490] Buffer I/O error on device dm-0, logical block 35647496 > [ 963.436492] Buffer I/O error on device dm-0, logical block 35647497 > [ 963.622762] firewire_sbp2 fw1.0: status write for unknown ORB > [ 982.791361] firewire_sbp2 fw1.0: status write for unknown ORB > [ 992.208952] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1001.432404] sd 7:0:0:0: [sdb] Unhandled error code > [ 1001.432421] sd 7:0:0:0: [sdb] > [ 1001.432426] Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK > [ 1001.432430] sd 7:0:0:0: [sdb] CDB: > [ 1001.432433] Write(16): 8a 00 00 00 00 00 10 ff cd 00 00 00 04 00 00 00 > [ 1001.432455] end_request: I/O error, dev sdb, sector 285199616 > [ 1001.432517] EXT4-fs warning (device dm-0): ext4_end_bio:317: I/O error writing to inode 114434179 (offset 16777216 size 8388608 starting block 35649664) > [ 1001.432523] buffer_io_error: 118 callbacks suppressed > [ 1001.432527] Buffer I/O error on device dm-0, logical block 35649664 > [ 1001.432534] Buffer I/O error on device dm-0, logical block 35649665 > [ 1001.432539] Buffer I/O error on device dm-0, logical block 35649666 > [ 1001.432543] Buffer I/O error on device dm-0, logical block 35649667 > [ 1001.432547] Buffer I/O error on device dm-0, logical block 35649668 > [ 1001.432551] Buffer I/O error on device dm-0, logical block 35649669 > [ 1001.432555] Buffer I/O error on device dm-0, logical block 35649670 > [ 1001.432559] Buffer I/O error on device dm-0, logical block 35649671 > [ 1001.432563] Buffer I/O error on device dm-0, logical block 35649672 > [ 1001.432567] Buffer I/O error on device dm-0, logical block 35649673 > [ 1001.626577] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1011.026839] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1049.773080] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1068.832685] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1078.617655] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1098.394512] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1107.794741] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1117.496439] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1137.852013] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1177.881913] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1187.470062] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1218.498244] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1227.915797] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1237.140148] sd 7:0:0:0: [sdb] Unhandled error code > [ 1237.140163] sd 7:0:0:0: [sdb] > [ 1237.140167] Result: hostbyte=DID_BUS_BUSY driverbyte=DRIVER_OK > [ 1237.140172] sd 7:0:0:0: [sdb] CDB: > [ 1237.140175] Write(16): 8a 00 00 00 00 00 12 0f 09 00 00 00 04 00 00 00 > [ 1237.140196] end_request: I/O error, dev sdb, sector 302975232 > [ 1237.140245] EXT4-fs warning (device dm-0): ext4_end_bio:317: I/O error writing to inode 114434181 (offset 25165824 size 4194304 starting block 37871616) > [ 1237.140248] buffer_io_error: 118 callbacks suppressed > [ 1237.140250] Buffer I/O error on device dm-0, logical block 37871616 > [ 1237.140254] Buffer I/O error on device dm-0, logical block 37871617 > [ 1237.140256] Buffer I/O error on device dm-0, logical block 37871618 > [ 1237.140258] Buffer I/O error on device dm-0, logical block 37871619 > [ 1237.140260] Buffer I/O error on device dm-0, logical block 37871620 > [ 1237.140262] Buffer I/O error on device dm-0, logical block 37871621 > [ 1237.140264] Buffer I/O error on device dm-0, logical block 37871622 > [ 1237.140265] Buffer I/O error on device dm-0, logical block 37871623 > [ 1237.140267] Buffer I/O error on device dm-0, logical block 37871624 > [ 1237.140269] Buffer I/O error on device dm-0, logical block 37871625 > [ 1237.331110] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1249.108424] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1278.293678] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1288.046882] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1318.483257] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1328.643319] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1366.661827] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1377.213409] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1386.623543] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1396.477497] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1406.642138] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1418.814202] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1440.203493] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1459.279209] firewire_sbp2 fw1.0: status write for unknown ORB > [ 1479.500552] firewire_sbp2 fw1.0: status write for unknown ORB This is interesting. When I asked you for this verbose log, I was wondering whether frequent bus resets are happening during I/O. If yes, they would have been a very sure sign of electrical problems (e.g. electromagnetic interference, overheated components, or the likes). The debug parameter which I gave you does actually not log bus resets, but "self identification complete events" which follow after a successful bus reset phase. As you see, you got selfID events directly when the disk was plugged in (as expected), but not later between the I/O error messages. This means that either there did not in fact happen any bus resets, or they did happen but were not followed up by selfID complete events. However, the presence of "firewire_sbp2 fw1.0: status write for unknown ORB" messages means that we are *not* dealing with bus resets without selfIDs here. This shifts my suspicion away from physical problems towards software problems. "Software" meaning primarily Linux' block/ SCSI/ firewire-sbp2 initiator stack on one hand, and the Quattro's SBP-2 target firmware on the other hand. Call me biased, by out of these, the firmware is my prime suspect. Note that the FireWire part of the Quattro and its USB part run totally independent and very different firmwares. (And the eSATA part is perhaps a firmware-less pass-through, but I am not sure.) Meaning that these the FireWire and USB firmwares of the Quattro differ from each other also with respect to the bugs that they do or do not contain. [lsfirewirephy_with_freecom_quattro_3_0_attached text/plain (94 bytes)] > bus 0, node 0: 00053d:08430b Agere Systems (unknown) > bus 0, node 1: 000cc2:401104 (unknown) [lsfirewirephy_with_nothing_attached text/plain (40 bytes)] > bus 0, node 0: 000cc2:401104 (unknown) 000cc2:401104 is apparently the integrated PHY of the O2 Micro controller of yours, and 00053d:08430b is apparently a discrete LSI/Agere FW843 1394b PHY in the Freecom Quattro. I don't have any device with Agere FW843 myself, but as I argued above, I no longer suspect the physical layer to be the source of the problems. -- Stefan Richter -=====-====- ---= ===-= http://arcgraph.de/sr/ |
From: <pho...@ya...> - 2014-01-29 14:21:53
|
Hello List, Hello Stefan, any chance that my firewire errors/problems with the Freecom Quattro 3.0 will be eventually solved - or shall I rather return the external hdd as defective and be done with it ? What would be a known working external firewire hdd ? Are the new Lacie external drives any good ? BR P. |
From: <pho...@ya...> - 2014-01-22 20:13:39
|
Hello Stefan, here is all the info that I collected about the errors with the Freecom Quattro 3.0 attached via firewire. I am now running 3.13 #> uname -r -v 3.13.0-031300-generic #201401192235 SMP Mon Jan 20 03:36:48 UTC 2014 I have increased log verbosity for creating this log as per your suggestion. I have not yet tried to connect that Freecom Quattro 3.0 to another PC with firewire. However I got hold of another Western Digital disk at a friend's place, connected it via firewire, and it worked just fine. So maybe the Freecom Quattro 3.0 is just crappy engineering :( Best regards P. |
From: Stefan R. <st...@s5...> - 2014-01-20 16:27:47
|
Hi all, besides the usual small behind-the-curtains changes, the following notable IEEE 1394 kernel updates have been released with the latest kernel versions: *Linux 3.12, released on November 3* firewire-core and firewire-ohci: - Fix a subsystem deadlock at bus reset which was sometimes observed if CPU resources were low. (This fixes a regression since Linux 3.2 inclusive. The subsystem workqueue deadlocked between transaction completion handling and bus reset handling if the kernel's worker thread pool could not be increased in time.) *Linux 3.13, released on January 19* snd-dice: - New ALSA driver, written by Clemens Ladisch. This is a playback-only driver for IEEE 1394 audio interfaces which are based on the DICE chip family (DICE-II/Jr/Mini) from TC Applied Technologies. For the time being, this driver is being bound only to devices which do not expose recording channels. Drivers which support playback + capture + MIDI are available from the FFADO project in the form of JACK backends, implemented in userspace. There are people working on extending the snd-dice ALSA driver to support capture and MIDI too, and to bring similar ALSA support to other FireWire audio devices. When this is done, ALSA would replace FFADO's streaming related components. Device control however, i.e. mixer and router controls etc., will continue to be implemented in userspace (typically by ffado-mixer of the FFADO project). (Those who want to try the snd-dice playback driver together with DICE devices which are not limited to playback in hardware, can generate themselves a reverting patch from commit b20be8de1b39. Then such a device will be available through ALSA as if it was a playback-only capable device.) -- Stefan Richter -=====-====- ---= =-=-- http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2014-01-19 17:08:09
|
pho...@ya... wrote: > Could you recommend some very good firewire cables, a certain > manufacturer maybe so that I could eliminate that potential problem? I > currently got the cables supplied with the freecom and western digital > drives, plus some from reichelt.de and some new delock ones bought from > amazon. I don't know where the device manufacturers get their cheap junk (although shorter cables actually are more handy), but any separately bought cable should work fine ... > They all work fine with the older freecom drives, but not with > the new 4tb freecom drive. ... especially if they work somewhere else. (FireWire connectors are constructed so that only the cables wear out.) > On this google code webpage https://code.google.com/p/jujuutils/ is this > requirement "package requires the new "Juju" FireWire stack.". Does the > new kernel use that juju firewire stack ? Yes. (It says so right on that page. Now. ;-) Regards, Clemens |
From: <pho...@ya...> - 2014-01-19 11:44:47
|
Hello Stefan, thanks for getting back to me. I am currently away from work and the new 4gb Freecom disk, but will be back with the disk on Wednesday. I can and will do all the things you suggested. I can compile c without problems. I this laptop with the firewire port I am using two older Freecom Quattro disks (ones with USB 2.0 connector in contrast to the new one with USB 3.0), they do work fine without problems, it does not matter whether I connect them directly or if I daisy chain them. I have also used a Western Digital MyBook Studio disk (silver enclosure) with this particular laptop earlier without any problems. Could you recommend some very good firewire cables, a certain manufacturer maybe so that I could eliminate that potential problem? I currently got the cables supplied with the freecom and western digital drives, plus some from reichelt.de and some new delock ones bought from amazon. They all work fine with the older freecom drives, but not with the new 4tb freecom drive. I saw that I have a firewire port on another computer with an asus motherboard. I will try the freecom disk there next week too. On this google code webpage https://code.google.com/p/jujuutils/ is this requirement "package requires the new "Juju" FireWire stack.". Does the new kernel use that juju firewire stack ? Thanks Best regards > On Jan 15 pho...@ya... wrote: >>> I still do have the problems with my new Freecom Hard Drive on its >>> firewire port. Anyway, I thought I might try a new kernel to see if the >>> problems would go away. However the errors are still coming. > [...] > > Thanks for testing the most recent kernel. > > Overall it looks like a hardware problem to me, for example due to a poorly > designed circuit board in the Freecom Quattro. Some customer reviews of > the Freecom Quattro 3.0 at amazon.co.uk report unreliable operation via > FireWire (in contrast to USB or eSATA), especially when daisy-chained with > more FireWire devices, but also when attached alone. > > Some questions: > > You wrote earlier that you used older disks successfully. Did you use > them at the very same laptop? > > Please send the file /sys/bus/firewire/devices/fw?/config_rom which > corresponds with the Freecom Quattro. This is a binary file; if you want > you can transform it into a human-readable text before posting by means of > the script "crpp" from http://me.in-berlin.de/~s5r6/linux1394/utils/. > > Also, please generate a more verbose kernel log from a session with these > I/O errors, by running > sudo dd of=/sys/module/firewire_ohci/parameters/debug <<< 2 > before you attach the Freecom Quattro, then reproduce the I/O errors. > > Lastly, if you have the means to compile C programs on this laptop, it > would interesting to see the output of the program > lsfirewirephy > from https://code.google.com/p/jujuutils/. > |