Thread: Problems with Texas Instruments TSB82AA2 chipset and cameras on both new and old stacks
Brought to you by:
aeb,
bencollins
From: Joan P. <jo...@gm...> - 2010-11-15 10:39:15
|
I am experiencing problems with the Texas Instruments TSB82AA2 chipset on an Eurotech COM1461 PC104 pci firewire card (ieee1394 a and b) in Ubuntu 10.04 (withs linux-image-2.6.32-21-generic). I tried both an Unibrain Fire-i camera and an AVT Marvin camera. The cameras work perfectly under Windows on the same machine. They also work on another Ubuntu 10.04 machine (with linux-image-2.6.32-21-generic) with different a firewire card. By default, the old stack modules are loaded, but they don't work. Unloading and blacklisting them in modprobe.conf and loading the new stack ones do not work for me either. I tried to update the kernel to linux-image-2.6.35-22-generic from Maverick repository, but a FATAL error appears at boot saying that modules were not found. Even though, I modprobed the new stack modules (and surprisingly they get loaded) but no luck, the problems persist. Sorry but I can not attach the kernel log excerpts with the errors until Wednesday, because the machine is embedded on an underwater robot now at the factory. I suppose that I should use the new stack modules, but to be sure, which stack should I use when attaching the kernel log with the errors? -- Joan Pau Beltran |
From: Stefan R. <st...@s5...> - 2010-11-15 20:31:56
|
On Nov 15 Joan Pau wrote: > I am experiencing problems with the Texas Instruments TSB82AA2 chipset on an > Eurotech COM1461 PC104 pci firewire card (ieee1394 a and b) in Ubuntu 10.04 > (withs linux-image-2.6.32-21-generic). There is a TSB81BA3 physical layer chip on that card. This is an early 1394b device with a long list of serious hardware errata (TI literature SLLZ015C). Hardly any of them can be worked around in software. Most of these errata affect 1394b mode only though, i.e. not 1394a cameras such as yours. However, one or another hardware workaround for 1394b issues may in turn cause cause problems in 1394a mode. One of the errata is actually a documentation erratum that caused board designers to provide for insufficient cooling of TSB81BA3. But I would expect this to become a problem only after some use. Problems due to overheating PHYs have indeed be reported here on this list a few years ago. Furthermore, 1394b hardware requires clean board layouts. I wonder whether this was done properly on a crammed board like this PC/104+ one. > I tried both an Unibrain Fire-i camera and an AVT Marvin camera. > The cameras work perfectly under Windows on the same machine. > They also work on another Ubuntu 10.04 machine (with > linux-image-2.6.32-21-generic) with different a firewire card. At least this is an indication that you already got around the usual setup problems (unsuitable group ownership of /dev/raw1394 and possibly /dev/video1394/* on Ubuntu). > By default, the old stack modules are loaded, but they don't work. > Unloading and blacklisting them in modprobe.conf and loading the new stack > ones do not work for me either. > > I tried to update the kernel to linux-image-2.6.35-22-generic from Maverick > repository, but a FATAL error appears at boot saying that modules were not > found. Can't comment on that. Maybe there is an Ubuntu user here wo can tell what to watch out for if a kernel package from a newer Ubuntu version is to be installed. That said, I don't expect any benefit of a kernel update for the 1394 hardware that you want to use, as far as the IEEE 1394 drivers (older stack or newer stack) are concerned. > Even though, I modprobed the new stack modules (and surprisingly they get > loaded) but no luck, the problems persist. Eventually, you should get to the point where you define "problems". :-) > Sorry but I can not attach the kernel log excerpts with the errors until > Wednesday, because the machine is embedded on an underwater robot now at the > factory. > I suppose that I should use the new stack modules, but to be sure, which > stack should I use when attaching the kernel log with the errors? Would be good to see logs from either of the two stacks if you can arrange for that. In addition, it may be helpful if you gather a log from a session that you initiated with # modprobe firewire-ohci debug=-1 for much increased verbosity. -- Stefan Richter -=====-==-=- =-== -==== http://arcgraph.de/sr/ |
From: Joan P. <jo...@gm...> - 2010-11-16 09:52:12
|
Thankyou for the quick response. I hope tomorrow I will be able to send the errors log in both the new and the old stack. I don't know if I am going to be able to plug and unplug the camera since the factory may send the robot closed and locked. The problem is that the camera does not get connected (I think), but I can not interpret the errors in kern.log. 2010/11/15 Stefan Richter <st...@s5...> > There is a TSB81BA3 physical layer chip on that card. This is an early > 1394b device with a long list of serious hardware errata (TI literature > SLLZ015C). Hardly any of them can be worked around in software. Most > of these errata affect 1394b mode only though, i.e. not 1394a cameras > such as yours. However, one or another hardware workaround for 1394b > issues may in turn cause cause problems in 1394a mode. > > One of the errata is actually a documentation erratum that caused board > designers to provide for insufficient cooling of TSB81BA3. But I would > expect this to become a problem only after some use. Problems due to > overheating PHYs have indeed be ported here on this list a few years > ago. > Oh, we didn't know that. This card had worked without problems for quite a lot of time with a 1394a camera in another underwater robot (bigger than the one where it is being installed now, cooling matters!) . Since we need to buy another PCI firewirecard (there are two robots), is there any hardware compatibility list up-to-date? Because the snapshot linked in the wiki seems a bit old (the TSB82AA2 is said to "work great" but it seems that it is not the case now). We would not expect to find a PC104 firewire card in there, since they are not very common in use, but at least we could compare the chipsets that come into the cards from several vendors and choose one already tested and working. -- Joan Pau Beltran |
From: Stefan R. <st...@s5...> - 2010-11-16 13:07:58
|
On Nov 16 Joan Pau wrote: > 2010/11/15 Stefan Richter <st...@s5...> > > > There is a TSB81BA3 physical layer chip on that card. This is an early > > 1394b device with a long list of serious hardware errata (TI literature > > SLLZ015C). [...] > Oh, we didn't know that. This card had worked without problems for quite a > lot of time with a 1394a camera in another underwater robot (bigger than the > one where it is being installed now, cooling matters!) . Since we need to > buy another PCI firewirecard (there are two robots), is there any hardware > compatibility list up-to-date? There is no catch-all 1394 compatibility list maintained anymore. We have compatibility with virtually all OHCI-1394 controllers. Some very rare ones pose difficulties in practice (ALi, NVidia, one on Audigy sound cards, some Ricoh ones) depending on the usage pattern. OHCI-1394 controllers all adhere to the same open link layer controller specification (well, to one out of two-and-a-half marginally different versions of the spec). They only have different bugs. > Because the snapshot linked in the wiki seems > a bit old (the TSB82AA2 is said to "work great" but it seems that it is not > the case now). AFAICT TSB82AA2 works very well overall. But the TSB81BA3 which is used on most TSB82AA2 based cards is a failure. Newer versions of it, TSB81BA3D and E, are much preferable but rarely or never found on TSB82AA2 cards. But as I said, the majority of TSB81BA3's problems is with 1394b hardware only, not with 1394a hardware. > We would not expect to find a PC104 firewire card in there, > since they are not very common in use, but at least we could compare the > chipsets that come into the cards from several vendors and choose one > already tested and working. Mostly. But there is some variability in case of link layer controllers with external physical layer chip (lspci does not show the latter, hence this information is often unknown). And there is some variability WRT board layout, components for bus power supply etc. A poorly laid out board might "work great" in PC A with cable B and device C but might fail miserably in PC X with cable Y and device Z. However, such issues do not occur very often, I think. They should not happen at all if designers and manufacturers followed the specs and the recommendations and testing procedures from 1394 TA, but sometimes corners are cut. Anyway. Let's wait for your kernel logs. -- Stefan Richter -=====-==-=- =-== =---- http://arcgraph.de/sr/ |
From: Joan P. B. <joa...@ui...> - 2010-12-07 15:23:29
|
Sorry for the delay, but had power connection problems in the vehicle and I could not test the firewire card again until yesterday, when the came back from the factory. The vehicle ships a Bumblebee2 stereo pair (1394a device from PointGrey Research Inc.). Surprisingly, coriander detects the camera and can grab the images, and this really puzzles me! Situation is: same kernel version (linux-image-2.6.32-21-generic), same software (libdc1394-22 v2.1.2-2 and coriander v2.0.0-4), all from Ubuntu repositories: 1.- Eurotech COM1461 firewire card + Unibrain Fire-i or AVT Marvin does not work. Coriander does not detect the camera, and the kernel log shows different errors (depending on which firewire stack modules are loaded). 2.- On another machine with a PCI card (listed by lspci as "FireWire (IEEE 1394) VIA Technologies, Inc. VT6306/7/8...") both Unibrain Fire-i and AVT Marvin work properly. Coriander detects them and captures images. 3.- Eurotech COM1461 firewire card + Pointgrey BumbleBee2 works. Coriander detects the camera and captures images properly. Unfortunately, I could not recover the old kernel logs with the errors from the vehicle, neither plug again the Fire-i nor the Marvin cameras. I am not sure if I we can reproduce the errors (we might need to open the vehicle again in some future but I hope we don't!!!). If we have the chance, I'll collect as much information as possible and post it. -- Joan Pau Beltran |
From: Stefan R. <st...@s5...> - 2010-11-20 14:45:29
|
On Nov 15 Joan Pau wrote: > I am experiencing problems with the Texas Instruments TSB82AA2 chipset on an > Eurotech COM1461 PC104 pci firewire card (ieee1394 a and b) in Ubuntu 10.04 > (withs linux-image-2.6.32-21-generic). > I tried both an Unibrain Fire-i camera and an AVT Marvin camera. > The cameras work perfectly under Windows on the same machine. > They also work on another Ubuntu 10.04 machine (with > linux-image-2.6.32-21-generic) with different a firewire card. > By default, the old stack modules are loaded, but they don't work. > Unloading and blacklisting them in modprobe.conf and loading the new stack > ones do not work for me either. Since I am not using TSB82AA2 cards myself very often anymore, I now did a smoke test with a LaCie CardBus card with TSB82AA2 and an Unibrain Fire-i, powered by the PSU that came with the LaCie card. No problem. Software used: Current kernel drivers (but I would be surprised if older ones behaved differently with this hardware configuration) and coriander. But I guess there are other Linux users too with IIDC cameras ran on TSB82AA2 cards. So there is no general problem with this combination, just a special one with your card. Which leaves us with the necessity that you add some detail to "does not work". ;-) -- Stefan Richter -=====-==-=- =-== =-=-- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-09-19 19:38:33
|
(Full quote because the message did not go through to the list.) On Sep 19 Joan Pau Beltran wrote: > Hi again, > > Here I can provide some new information about the mentioned problem. > Sorry for the long idle time but the hardware at my company was not > available for me again until now. > The PC104-Plus firewire card has been replaced by this other model: > CM17208 by RTD. > According to the output of lspci (attached) and the manual of the card, > it comes with the same chips : TSB82AA2 Link Layer and TSB81BA3 > Transceiver/Arbiter. > > We are using two Pointgrey Bumblebee2 stereo cameras connected to that > card (in Format7 mode and selecting the apropiate packet size to not > blow up the bus bandwith). > The problem is that the cameras work for a while (sometimes hours, > sometime minutes) but eventually they hang (no error messages from > libdc1394). > > To set an scenario, we are still using Ubuntu 10.04 x86-64, but with > backported kernel 2.6.38-10. > We remove the new stack modules and load it again with debug option: > > user@fugu-c:~$ sudo modprobe -r -v firewire_ohci > > rmmod > > /lib/modules/2.6.38-10-generic/kernel/drivers/firewire/firewire-ohci.ko > > rmmod > > /lib/modules/2.6.38-10-generic/kernel/drivers/firewire/firewire-core.ko > > rmmod /lib/modules/2.6.38-10-generic/kernel/lib/crc-itu-t.ko > > user@fugu-c:~$ sudo modprobe -v firewire_ohci debug=15 > > insmod /lib/modules/2.6.38-10-generic/kernel/lib/crc-itu-t.ko > > insmod > > /lib/modules/2.6.38-10-generic/kernel/drivers/firewire/firewire-core.ko > > insmod > > /lib/modules/2.6.38-10-generic/kernel/drivers/firewire/firewire-ohci.ko debug=15 > As shown in the attached file, the correct drivers seem to be loaded. For the list: ------------------------- lsmod.txt from Joan ------------------------- Module Size Used by firewire_ohci 40012 0 firewire_core 62534 9 firewire_ohci crc_itu_t 12707 1 firewire_core cp210x 21776 0 binfmt_misc 17498 1 ppdev 17180 0 i915 518574 2 drm_kms_helper 42054 1 i915 usbserial 42893 1 cp210x drm 227552 3 i915,drm_kms_helper r8712u 307506 0 psmouse 73514 0 i2c_i801 17449 1 serio_raw 13208 0 i2c_algo_bit 13368 1 i915 video 19280 1 i915 hwmon_vid 12746 0 coretemp 13519 0 i2c_dev 13355 2 lp 17789 0 parport 46360 2 ppdev,lp e1000e 158424 0 ----------------------------------------------------------------------- ------------------------- lspci.txt from Joan ------------------------- 00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller 00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller 00:19.0 Ethernet controller: Intel Corporation 82567V-3 Gigabit Network Connection (rev 04) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 04) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 04) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f4) 00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 04) 00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 04) 01:04.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01) ----------------------------------------------------------------------- Module list and lspci output are fine. > The other file attached is the kernel log. Some parts seem to be > misaligned, I don't know why, but they are not important. For the list: I uploaded Joan's kern.log to http://paste.ubuntu.com/693238/. It is 5 MB big which is why Joan's mail was retained by the list server. > Everything is working fine, images are read from the cameras at the > correct frame rate, and the log only contain bus reset messages (what do > they mean?). But approximately at second 1421 the cameras get stacked, > and new messages appear in the log. I can not interpret their meaning, > but could they point out to a software problem? Or to a hardware one? > The hang is much more frequent when the cylinder that contains the > cameras is closed, which may be related with the heat problems mentioned > in the previous posts. > > What do you think? > > Thanks again for your interest and attention. In the first part of your log, everything looks perfectly fine. From timestamp 1418.424221 to 1431.015034, you get a storm of bus reset events. None of these bus resets is concluded with a so-called self-ID- complete event, which would be when the nodes on the bus identified themselves to each other after the bus reset. Normal FireWire traffic can only happen after a self-ID-complete event and before the next bus reset event. At timestamp 1431.015048, the first self-ID-complete event happens, i.e. a successful conclusion of a bus reset. After that, the kernel and your application are apparently able to use the cameras again. Bus resets _normally_ happen: 1. If you plug a FireWire device in to or out of the FireWire bus or power a FireWire device up or down, 2. if bus management software or node management firmware or special application software requests a bus reset as a means to announce a change of node configuration to all peers. Bus resets _abnormally_ happen: 3. If rogue software requests a bus reset for no good reason, 4. if a physical interface chip malfunctions due to hardware errata, 5. if a physical interface chip of a device or a cable or a combination of chips and cable works too far off the standardized electrical parameters of the FireWire physical layer. The storm of bus resets from timestamp 1418.424221 onwards is of course of one of the abnormal types. On 3.: firewire-core since kernel 2.6.36 contains safeguards which prevent any software that runs on the Linux node to cause a storm of bus resets. On 4.: Texas Instruments TSB81BA3 (all revisions up to revision C inclusive) is a seriously buggy PHY which tends to fall into bus reset storms at the drop of a hat. However, this is only known to happen in case of pure 1394b "beta mode" buses: http://www.ti.com/litv/pdf/sllz015c Your cameras are 1394a devices, therefore the bus operates in "alpha mode" a.k.a. data-strobe mode. The above mentioned TSB81BA3 errata are *not* known to happen in alpha mode; instead, as far as documented by TI and as far as I have observed myself, having one or more 1394a node on the bus keeps TSB81BA3 working correctly. On 5.: Various circumstances can contribute to such malfunctions, alone or in combination: - Plainly damaged hardware of course, - badly constructed or miswired or too long cables, - badly laid out circuit boards, - too weak or electrically too noisy power supplies, - badly selected or overheating clocking crystals, - overheating physical interface chips, - electromagnetic interference from within one of the FireWire nodes or from external sources. My suggestion to you, if you haven't done so already: Check whether you have high-quality cables, whether the environmental conditions in your lab (EMI, temperature, humidity, mechanical vibrations, radiation,...) are in line with what is specified for your embedded PC and for the Bumblebee2 cameras or what is generally assumed for office use, whether power supply is adequate and stable, whether your embedded PC is properly shielded against EMI (inbound and outbound). If you are more or less certain that your equipment and lab are OK, you should approach Point Grey or/and the vendors of the components of your embedded PC with the issue. If you have adverse conditions in your lab (or wherever this equipment is deployed) which you cannot improve, ask Point Grey and the other component vendors as well whether they have recommendations for counter measures. ----------------------------------------------------------------------- Oh wait, I now looked up the prior postings of this thread in my mail archive. On 07 Dec 2010 you wrote that this equipment is built into a vehicle. So that pretty much means that the last paragraph applies, unless if the issue also happens if you have cameras and PC taken out of the vehicle and are testing it under good conditions in your office. The 1394 Trade Association has a working group which deals with 1394 based in-vehicle networks. There tend to be special 1394b-2002/ 1394-2008 beta mode based cables and connectors involved which are quite different from the traditional 1394-1995/ 1394a-2000 cables and plugs. -- Stefan Richter -=====-==-== =--= =--== http://arcgraph.de/sr/ |
From: Joan P. B. <joa...@ui...> - 2011-09-20 08:55:15
|
Some comments after the quote. Al 19/09/11 21:38, En/na Stefan Richter ha escrit: > In the first part of your log, everything looks perfectly fine. > > From timestamp 1418.424221 to 1431.015034, you get a storm of bus reset > events. None of these bus resets is concluded with a so-called self-ID- > complete event, which would be when the nodes on the bus identified > themselves to each other after the bus reset. > > Normal FireWire traffic can only happen after a self-ID-complete event > and before the next bus reset event. > > At timestamp 1431.015048, the first self-ID-complete event happens, i.e. > a successful conclusion of a bus reset. After that, the kernel and your > application are apparently able to use the cameras again. > > Bus resets _normally_ happen: > 1. If you plug a FireWire device in to or out of the FireWire bus or > power a FireWire device up or down, > 2. if bus management software or node management firmware or special > application software requests a bus reset as a means to announce > a change of node configuration to all peers. > > Bus resets _abnormally_ happen: > 3. If rogue software requests a bus reset for no good reason, > 4. if a physical interface chip malfunctions due to hardware errata, > 5. if a physical interface chip of a device or a cable or a > combination of chips and cable works too far off the standardized > electrical parameters of the FireWire physical layer. > > The storm of bus resets from timestamp 1418.424221 onwards is of course > of one of the abnormal types. > > On 3.: firewire-core since kernel 2.6.36 contains safeguards which > prevent any software that runs on the Linux node to cause a storm of > bus resets. > > On 4.: Texas Instruments TSB81BA3 (all revisions up to revision C > inclusive) is a seriously buggy PHY which tends to fall into bus reset > storms at the drop of a hat. However, this is only known to happen in > case of pure 1394b "beta mode" buses: > http://www.ti.com/litv/pdf/sllz015c > > Your cameras are 1394a devices, therefore the bus operates in "alpha > mode" a.k.a. data-strobe mode. The above mentioned TSB81BA3 errata are > *not* known to happen in alpha mode; instead, as far as documented by > TI and as far as I have observed myself, having one or more 1394a node > on the bus keeps TSB81BA3 working correctly. > > On 5.: Various circumstances can contribute to such malfunctions, alone > or in combination: > - Plainly damaged hardware of course, > - badly constructed or miswired or too long cables, > - badly laid out circuit boards, > - too weak or electrically too noisy power supplies, > - badly selected or overheating clocking crystals, > - overheating physical interface chips, > - electromagnetic interference from within one of the FireWire nodes > or from external sources. > > My suggestion to you, if you haven't done so already: > > Check whether you have high-quality cables, whether the environmental > conditions in your lab (EMI, temperature, humidity, mechanical vibrations, > radiation,...) are in line with what is specified for your embedded PC > and for the Bumblebee2 cameras or what is generally assumed for office > use, whether power supply is adequate and stable, whether your embedded PC > is properly shielded against EMI (inbound and outbound). > > If you are more or less certain that your equipment and lab are OK, you > should approach Point Grey or/and the vendors of the components of your > embedded PC with the issue. > > If you have adverse conditions in your lab (or wherever this equipment > is deployed) which you cannot improve, ask Point Grey and the other > component vendors as well whether they have recommendations for > counter measures. > > ----------------------------------------------------------------------- > > Oh wait, I now looked up the prior postings of this thread in my mail > archive. On 07 Dec 2010 you wrote that this equipment is built into a > vehicle. So that pretty much means that the last paragraph applies, > unless if the issue also happens if you have cameras and PC taken out of > the vehicle and are testing it under good conditions in your office. Well, the equipment is mounted on an underwater vehicle, but basically this vehicle is just a water-proof methacrylate cylinder with aluminum plates, with all the components inside. When the cylinder is opened, the problem is by far less frequent. I mean that the cameras can work for hours without errors and and only rare times they hang up. When the cylinder is closed, the error happens just after 20-40 minutes of operation. To isolate the problem, and suspecting that it may be related to heat accumulation, we performed several tests under good conditions in the office with the cylinder opened. First, the problem is present with two different firewire cards: RTD CM17208 and Eurotech COM-1461, both of them with TSB82AA2 and TSB81BA3. To check for a possible power problem, I connected a digital real-time oscilloscope to the 12V input of the firewire card with infinite persistence. The signal seemed quite normal (range 12V - 12'5 V, never below 12V) and no glitches were present during the failures. To discard a problem with the cameras, we took them out of the cylinder and plugged them to another PC and firewire card using the same cables. Applying heat externally and measuring temperature, they worked for hours without exhibiting any problem. Thus, from the list on 5, I would discard: - Plainly damaged hardware of course, - badly constructed or miswired or too long cables, - too weak or electrically too noisy power supplies, So it leaves us with the following list of possible causes: - badly laid out circuit boards, - badly selected or overheating clocking crystals, - overheating physical interface chips, - electromagnetic interference from within one of the FireWire nodes or from external sources. In any case, it seems that this is not a software problem, so sorry for the noise on the list. We will try to apply some extra cooling to see if the problem still persists, and let you know. Thank you very much for your help! |
From: Stefan R. <st...@s5...> - 2011-09-20 14:49:45
|
On Sep 20 Joan Pau Beltran wrote: > Well, the equipment is mounted on an underwater vehicle, but basically > this vehicle is just a water-proof methacrylate cylinder with aluminum > plates, with all the components inside. > When the cylinder is opened, the problem is by far less frequent. I mean > that the cameras can work for hours without errors and and only rare > times they hang up. > When the cylinder is closed, the error happens just after 20-40 minutes > of operation. > To isolate the problem, and suspecting that it may be related to heat > accumulation, we performed several tests under good conditions in the > office with the cylinder opened. [...] Maybe a small fan which forces convection within the cylinder is already enough to get it more stable. On the other hand, the fan would increase overall heat production. The Bumblebee datasheet states 0...45 °C operating temperature range and 2.5 W or 4 W power consumption (depending on type). So, since these 2.5...4 W need to go somewhere, these up to 45 °C environmental temperature certainly refer to conditions which still include at least some degree of natural convection. Given the chain of convection from equipment to enclosure (or conduction?) and convection from enclosure to water (or to air when not submerged), water temperature must be somewhere below 45 °C (or air temperature quite a lot below 45 °C, again depending on the possibilities for convection or conduction inside the enclosure). Of course there might also be some other arcane factor than temperature involved. -- Stefan Richter -=====-==-== =--= =-=-- http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2011-09-20 18:31:02
|
This is the kind of problem I am trying to address with some diagnostic utilities. My current goal is to test 2 controllers hooked together. Kinda like the loop back testers for serial ports. or the ping command to test network stacks. note: I am mostly a Python guy, so out of my comfort zone hacking on C/kernel stuff - so don't rely on anything you get out of me - but it may give you clues you can use to verify what is really going on. Here is what I have so far: https://gitorious.org/cfk_misc/fwdiag/trees/master Clemens gave me async-test.c and I added some code to make it work with guid's. I wrote fw_test.sh to fire up the receiver and then sender in a xterm. Using this has made it clear that a problem I have with a laptop is the laptop and not the cameras. I suspected this, but being able to run a test that does not use a camera was nice. A friend just gave me async-loop-ck.c - it is basically the same as the fw_test.sh/async-test but is a single app that takes care of setting up the ends and doesn't need X. I have not had a chance to use it, all I know is it runs. -- Carl K |