linux1394-user Mailing List for IEEE 1394 for Linux (Page 15)
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: Robert L. <rob...@se...> - 2011-11-01 23:45:22
|
hi everyone, not sure how to approach this, don't know much about linux firewire support/ any pointers welcome: I have a basler a601f firewire camera, and a debian squeeze machine that I would like to use the camera with. kernel is a 2.6.32-5-amd64, lspci lists my firewire card: 03:01.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 61) lsmod | grep firew reports: firewire_ohci 19676 0 firewire_core 36848 2 firewire_sbp2,firewire_ohci crc_itu_t 1307 1 firewire_core 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 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 and unplugging the camera gives me: Nov 1 23:41:56 sandbender kernel: [54665.004775] firewire_ohci: IRQ 00000010 AR_req Nov 1 23:41:56 sandbender kernel: [54665.004782] firewire_ohci: AR evt_bus_reset, generation 149 Nov 1 23:41:56 sandbender kernel: [54665.005770] firewire_ohci: IRQ 00000010 AR_req Nov 1 23:41:56 sandbender kernel: [54665.005774] firewire_ohci: AR evt_bus_reset, generation 150 Nov 1 23:41:56 sandbender kernel: [54665.005948] firewire_ohci: IRQ 00010000 selfID Nov 1 23:41:56 sandbender kernel: [54665.005958] firewire_ohci: 1 selfIDs, generation 150, local node ID ffc0 Nov 1 23:41:56 sandbender kernel: [54665.005961] firewire_ohci: selfID 0: 807f8c56, phy 0 [---] S400 gc=63 -3W Lci Nov 1 23:41:56 sandbender kernel: [54665.005963] firewire_core: skipped bus generations, destroying all nodes Nov 1 23:41:57 sandbender kernel: [54665.504029] firewire_core: rediscovered device fw0 but I don't think the camera actually works. I don't get any device for it (I was expecting something in the logs, or a /dev/fw1 or so to appear, am I wrong?), and coriander claims that no camera is connnected. so: is this the right direction? should this work? Can anyone see something obvious? How should I go on from here? thanks robert |
From: Stefan R. <st...@s5...> - 2011-10-31 16:45:12
|
On Sep 17 Dan Dennedy wrote: > On Sat, Sep 17, 2011 at 11:42 AM, Stefan Richter > <st...@s5...> wrote: > > since kernel.org is taking an extended time off without any hint when it > > will come back, I uploaded copies of the git repositories and of the last > > source release tarballs of libraw1394 and libiec61883 to the following > > places: > > > > git clone/pull/fetch: > > git://git.user.in-berlin.de/s5r6/libraw1394.git > > git://git.user.in-berlin.de/s5r6/libiec61883.git > > > > gitweb: > > https://redmine.user.in-berlin.de/projects/libraw1394/repository > > https://redmine.user.in-berlin.de/projects/libiec61883/repository > > > > tarballs: > > https://redmine.user.in-berlin.de/projects/libraw1394/files > > https://redmine.user.in-berlin.de/projects/libiec61883/files > > > > All of those are copied from my PC at home, except for > > libiec61883-1.2.0.tar.gz which I didn't have anymore but found on the web > > from a mirror of ftp.kernel.org. I compared the contents of this tarball > > with the result of "make dist" and it is all well. > > > > Dan also still has got git trees but I don't know whether he has tarballs: > > Older tarballs are on http://sourceforge.net/projects/libraw1394/files/ Git trees have been restored at kernel.org now. The URL of the kernel driver repo has changed a bit (dropped the -2.6 suffix), the URLs of the library repos are the original ones. == 1394 kernel drivers == git fetch/pull/clone: git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git http://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git https://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git gitweb: http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394.git https://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394.git == libraw1394 == git fetch/pull/clone: git://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git http://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git https://git.kernel.org/pub/scm/libs/ieee1394/libraw1394.git gitweb: http://git.kernel.org/?p=libs/ieee1394/libraw1394.git https://git.kernel.org/?p=libs/ieee1394/libraw1394.git == libiec61883 == This is maintained by Dan, hence the master repo is located at git fetch/pull/clone: git://dennedy.org/libiec61883.git gitweb: http://www.dennedy.org/cgi-bin/gitweb.cgi?p=dennedy.org/libiec61883.git https://www.dennedy.org/cgi-bin/gitweb.cgi?p=dennedy.org/libiec61883.git but a backup repo which I update irregularly is located at git fetch/pull/clone: git://git.kernel.org/pub/scm/libs/ieee1394/libiec61883.git http://git.kernel.org/pub/scm/libs/ieee1394/libiec61883.git https://git.kernel.org/pub/scm/libs/ieee1394/libiec61883.git gitweb: http://git.kernel.org/?p=libs/ieee1394/libiec61883.git https://git.kernel.org/?p=libs/ieee1394/libiec61883.git I am not yet able to upload release tarballs of libraw1394 and libiec61883 to kernel.org and do not know when this will be reinstated. -- Stefan Richter -=====-==-== =-=- ===== http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-10-05 21:51:51
|
On Oct 02 Stefan Richter wrote: > Linux 3.1 is due to be released later this month; it is currently > available as release candidate 8. Among the usual small corrections and > improvements, the following changes to the IEEE 1394 kernel drivers were > released: [...] 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. -- Stefan Richter -=====-==-== =-=- --=-= http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-10-02 10:50:58
|
Hi all, Linux 3.1 is due to be released later this month; it is currently available as release candidate 8. Among the usual small corrections and improvements, the following changes to the IEEE 1394 kernel drivers were released: Documentation: - Some introductory documentation to the <linux/firewire-cdev.h> API was added in Documentation/ABI/stable/firewire-cdev. Inline documentation in the API header file was improved. - Added documentation of the firewire-core and firewire-sbp2 sysfs ABIs in Documentation/ABI/stable/sysfs-bus-firewire. <linux/firewire-cdev.h> API corrections: - The error return in case of an unknown ioctl number no has errno set to ENOTTY instead of EINVAL. Also fixed in kernel 3.0.1. - The first FW_CDEV_IOC_GET_INFO ioctl is clarified to start reception of bus reset events; earlier bus reset events are discarded. This ensures events with well-defined closure value under all circumstances. Also fixed in kernel 3.0.1. - Fixed an issue with 32 bit userland drivers on top of 64 bit kernel, resulting in FW_CDEV_IOC_GET_INFO failing with EFAULT. libraw1394 and libdc1394 were not affected by this issue. firewire-core: - Fixed "giving up on config rom" failures in detection of some older Panasonic based camcorders, e.g. Panasonic AG-EZ30 and NV-DX110, Grundig Scenos DLC 2000. (The fix addresses transaction failures to these camcorders which had more severe effect on the current driver stack than on the linux1394 drivers of kernel 2.6.36 and older. While basic DV capture without AV/C control works with these camcorders now, more work at the userland library is necessary for full interoperability. This has been discussed on linux1394-devel but not yet finalized.) firewire-ohci: - Continuing the optimization work that was released in kernel 3.0, CPU utilization during packet queueing was reduced further, benefiting all higherlevel 1394 kernel drivers and userland drivers. - Fix I/O and PM suspend with O2Micro PCIe FireWire controllers by blacklisting MSI on them. Also to be fixed in kernel 3.0.5. - A fix in the core kernel's memory management addresses firewire-ohci startup failures with kernels that were configured for a maximum number of CPUs of something else than a power of two. This was a regression since kernel 2.6.38. Also fixed in kernel 3.0.3. firewire-sbp2: - Fix panic when the module was unloaded while a management transaction was still pending, e.g. login. This was a regression since kernel 3.0. As long as the kernel.org services are still down, source code and tarballs are available at the following locations: Linux kernel: git: git://github.com/torvalds/linux gitweb: https://github.com/torvalds/linux tarballs: https://github.com/torvalds/linux/downloads IEEE 1394 kernel subsystem: git: git://git.user.in-berlin.de/s5r6/linux1394.git IEEE 1394 base libraries: git: git://git.user.in-berlin.de/s5r6/libraw1394.git git://git.user.in-berlin.de/s5r6/libiec61883.git gitweb: https://redmine.user.in-berlin.de/projects/libraw1394/repository https://redmine.user.in-berlin.de/projects/libiec61883/repository tarballs: https://redmine.user.in-berlin.de/projects/libraw1394/files https://redmine.user.in-berlin.de/projects/libiec61883/files Enjoy, -- 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 |
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: 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-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: Dan D. <da...@de...> - 2011-09-17 18:57:14
|
On Sat, Sep 17, 2011 at 11:42 AM, Stefan Richter <st...@s5...> wrote: > Hi all, > > since kernel.org is taking an extended time off without any hint when it > will come back, I uploaded copies of the git repositories and of the last > source release tarballs of libraw1394 and libiec61883 to the following > places: > > git clone/pull/fetch: > git://git.user.in-berlin.de/s5r6/libraw1394.git > git://git.user.in-berlin.de/s5r6/libiec61883.git > > gitweb: > https://redmine.user.in-berlin.de/projects/libraw1394/repository > https://redmine.user.in-berlin.de/projects/libiec61883/repository > > tarballs: > https://redmine.user.in-berlin.de/projects/libraw1394/files > https://redmine.user.in-berlin.de/projects/libiec61883/files > > All of those are copied from my PC at home, except for > libiec61883-1.2.0.tar.gz which I didn't have anymore but found on the web > from a mirror of ftp.kernel.org. I compared the contents of this tarball > with the result of "make dist" and it is all well. > > Dan also still has got git trees but I don't know whether he has tarballs: Older tarballs are on http://sourceforge.net/projects/libraw1394/files/ -- +-DRD-+ |
From: Stefan R. <st...@s5...> - 2011-09-17 18:43:08
|
Hi all, since kernel.org is taking an extended time off without any hint when it will come back, I uploaded copies of the git repositories and of the last source release tarballs of libraw1394 and libiec61883 to the following places: git clone/pull/fetch: git://git.user.in-berlin.de/s5r6/libraw1394.git git://git.user.in-berlin.de/s5r6/libiec61883.git gitweb: https://redmine.user.in-berlin.de/projects/libraw1394/repository https://redmine.user.in-berlin.de/projects/libiec61883/repository tarballs: https://redmine.user.in-berlin.de/projects/libraw1394/files https://redmine.user.in-berlin.de/projects/libiec61883/files All of those are copied from my PC at home, except for libiec61883-1.2.0.tar.gz which I didn't have anymore but found on the web from a mirror of ftp.kernel.org. I compared the contents of this tarball with the result of "make dist" and it is all well. Dan also still has got git trees but I don't know whether he has tarballs: git clone/pull/fetch: git://dennedy.org/libraw1394.git git://dennedy.org/libiec61883.git gitweb: http://www.dennedy.org/cgi-bin/gitweb.cgi?p=dennedy.org/libraw1394.git http://www.dennedy.org/cgi-bin/gitweb.cgi?p=dennedy.org/libiec61883.git (There is 1 commit and 2 tags more in my libraw1394 repo.) Alas I have no copy of ieee1394.wiki.kernel.org. There is also no archive of it on the web, presumably because robots were not permitted to traverse wiki.kernel.org. Furthermore, as noted in my other mail on linux1394-devel, there is also a transitional git tree for pending IEEE 1394 kernel subsystem patches at git://git.user.in-berlin.de/s5r6/linux1394.git gitweb is not yet available for this kernel repo. -- Stefan Richter -=====-==-== =--= =---= http://arcgraph.de/sr/ |
From: Touma, J. E Dr C. U. A. AFRL/R. <jim...@eg...> - 2011-08-21 15:24:38
|
UNSUBSCRIBE |
From: Clemens L. <cl...@la...> - 2011-08-11 19:51:30
|
Carl Karsten wrote: >dmesg shows lots of > >[482238.255966] usb 1-1.2: reset high speed USB device using ehci_hcd >and address 3 This message indicates that the kernel has decided to reset the device because of some problem, or that the device is resetting itself. I don't see any possibility how the FireWire driver could cause this; this is probably some PCI device blocking the bus for way too long, or electrical noise. >[ 70.496550] irq_handler: 33 callbacks suppressed >[ 70.496553] firewire_ohci: isochronous cycle inconsistent According to Google, this happens with a broken controller. Regards, Clemens |
From: Clemens L. <cl...@la...> - 2011-08-11 19:40:14
|
Carl Karsten wrote: >Clemens Ladisch wrote: >> replace (u64)&something with >> (unsigned long)&something in async-test.c. > >This one, right? > >313 get_info.bus_reset = (u64)&bus_reset; Yes. Regards, Clemens |
From: Carl K. <ca...@pe...> - 2011-08-10 23:03:19
|
On Wed, Aug 10, 2011 at 4:06 PM, Stefan Richter <st...@s5...> wrote: > On Aug 10 Carl Karsten wrote: > [...] >> async-test receive/send... >> >> It showed something like (I am doing this from memory, see why below) >> 4096 packets, 0.17 MB/s >> >> same when I switched >> >> dmesg shows lots of >> >> [482238.255966] usb 1-1.2: reset high speed USB device using ehci_hcd >> and address 3 >> >> I am not sure what all I had done to the box, so rebooted. > [...] > > Maybe a FireWire kernel driver bug could be the cause and USB a victim, by > the FW driver corrupting memory and other kernel subsystems beginning to > act strange. > > Or USB trouble was the cause and FireWire slowdown one result of it. > > (I don't know whether the above USB message is about the hardware doing > something to the kernel, or the kernel doing something to the hardware. > grep doesn't find the message in the source with the string fragments that > I tried.) running async test and dvgrab for a few hours - no errors reported by either app, dmesg shows: [ 7330.695465] firewire_core: Unsolicited response (source ffc1, tlabel 7) [ 7330.709945] firewire_core: Unsolicited response (source ffc1, tlabel a) [ 7330.710859] firewire_core: Unsolicited response (source ffc1, tlabel a) [ 7330.711482] firewire_core: Unsolicited response (source ffc1, tlabel a) [ 7330.716491] firewire_core: Unsolicited response (source ffc1, tlabel b) [ 7330.721875] firewire_core: Unsolicited response (source ffc1, tlabel c) [ 7330.725817] firewire_core: Unsolicited response (source ffc1, tlabel d) [ 7330.734088] firewire_core: Unsolicited response (source ffc1, tlabel f) [ 7330.734989] firewire_core: Unsolicited response (source ffc1, tlabel f) [ 7330.741211] firewire_core: Unsolicited response (source ffc1, tlabel 11) [ 7330.742833] firewire_core: Unsolicited response (source ffc1, tlabel 11) [ 7330.750206] firewire_core: Unsolicited response (source ffc1, tlabel 11) [ 7330.768571] firewire_core: Unsolicited response (source ffc1, tlabel 17) [ 7330.772457] firewire_core: Unsolicited response (source ffc1, tlabel 18) [ 7330.775688] firewire_core: Unsolicited response (source ffc1, tlabel 18) [ 7330.777571] firewire_core: Unsolicited response (source ffc1, tlabel 19) [ 7330.781273] firewire_core: Unsolicited response (source ffc1, tlabel 19) [ 7330.783561] firewire_core: Unsolicited response (source ffc1, tlabel 19) [ 7330.801291] firewire_core: Unsolicited response (source ffc1, tlabel 1e) [ 7330.803408] firewire_core: Unsolicited response (source ffc1, tlabel 1f) [ 7330.813008] firewire_core: Unsolicited response (source ffc1, tlabel 20) [ 7330.815530] firewire_core: Unsolicited response (source ffc1, tlabel 20) [ 7330.821509] firewire_core: Unsolicited response (source ffc1, tlabel 21) [ 7330.822544] firewire_core: Unsolicited response (source ffc1, tlabel 20) [ 7330.835853] firewire_core: Unsolicited response (source ffc1, tlabel 25) [ 7330.842394] firewire_core: Unsolicited response (source ffc1, tlabel 27) [ 7330.847752] firewire_core: Unsolicited response (source ffc1, tlabel 28) [ 7330.856019] firewire_core: Unsolicited response (source ffc1, tlabel 29) [ 7330.866216] firewire_core: Unsolicited response (source ffc1, tlabel 2b) [ 7330.870480] firewire_core: Unsolicited response (source ffc1, tlabel 2d) [ 7330.876955] firewire_core: Unsolicited response (source ffc1, tlabel 2e) [ 7330.878072] firewire_core: Unsolicited response (source ffc1, tlabel 2e) [ 7330.879999] firewire_core: Unsolicited response (source ffc1, tlabel 2e) [ 7330.880218] firewire_core: Unsolicited response (source ffc1, tlabel 2e) [ 7330.890098] firewire_core: Unsolicited response (source ffc1, tlabel 30) [ 7330.892483] firewire_core: Unsolicited response (source ffc1, tlabel 30) [ 7330.894967] firewire_core: Unsolicited response (source ffc1, tlabel 31) [ 7330.900325] firewire_core: Unsolicited response (source ffc1, tlabel 31) [ 7330.916255] firewire_core: Unsolicited response (source ffc1, tlabel 34) [ 7330.918720] firewire_core: Unsolicited response (source ffc1, tlabel 35) [ 7330.919713] firewire_core: Unsolicited response (source ffc1, tlabel 35) [ 7330.926464] firewire_core: Unsolicited response (source ffc1, tlabel 35) [ 7330.931777] firewire_core: Unsolicited response (source ffc1, tlabel 36) [ 7331.595808] firewire_core: Unsolicited response (source ffc1, tlabel 27) [ 7331.599822] firewire_core: Unsolicited response (source ffc1, tlabel 2d) [ 7331.608193] firewire_core: Unsolicited response (source ffc1, tlabel 39) [ 7331.613035] firewire_core: Unsolicited response (source ffc1, tlabel f) [ 7331.617269] firewire_core: Unsolicited response (source ffc1, tlabel 20) [ 7331.720069] firewire_core: Unsolicited response (source ffc1, tlabel 29) [ 7331.722728] firewire_core: Unsolicited response (source ffc1, tlabel 3) [ 7331.734084] firewire_core: Unsolicited response (source ffc1, tlabel 2a) [ 7331.740303] firewire_core: Unsolicited response (source ffc1, tlabel 10) [ 7331.752684] firewire_core: Unsolicited response (source ffc1, tlabel 32) [ 7331.758550] firewire_core: Unsolicited response (source ffc1, tlabel 37) [ 7331.759681] firewire_core: Unsolicited response (source ffc1, tlabel 39) [ 7331.769806] firewire_core: Unsolicited response (source ffc1, tlabel 7) [ 7331.783678] firewire_core: Unsolicited response (source ffc1, tlabel f) [ 7331.802278] firewire_core: Unsolicited response (source ffc1, tlabel 17) [ 7331.828140] firewire_core: Unsolicited response (source ffc1, tlabel 3b) [ 7331.833643] firewire_core: Unsolicited response (source ffc1, tlabel 1e) [ 7331.842223] firewire_core: Unsolicited response (source ffc1, tlabel 32) [ 7331.941672] firewire_core: Unsolicited response (source ffc1, tlabel 5) [ 7331.945800] firewire_core: Unsolicited response (source ffc1, tlabel 1) [ 7331.953144] firewire_core: Unsolicited response (source ffc1, tlabel e) [ 7331.960263] firewire_core: Unsolicited response (source ffc1, tlabel 23) [ 7331.962266] firewire_core: Unsolicited response (source ffc1, tlabel 23) [ 7331.963792] firewire_core: Unsolicited response (source ffc1, tlabel 23) [ 7331.963913] firewire_core: Unsolicited response (source ffc1, tlabel 23) [ 7331.965637] firewire_core: Unsolicited response (source ffc1, tlabel 1e) [ 7331.972407] firewire_core: Unsolicited response (source ffc1, tlabel 5) [ 7331.985267] firewire_core: Unsolicited response (source ffc1, tlabel 14) [ 7331.993752] firewire_core: Unsolicited response (source ffc1, tlabel 1d) [ 7332.004731] firewire_core: Unsolicited response (source ffc1, tlabel 12) [ 7332.004847] firewire_core: Unsolicited response (source ffc1, tlabel 12) [ 7332.015867] firewire_core: Unsolicited response (source ffc1, tlabel 20) [ 7332.019996] firewire_core: Unsolicited response (source ffc1, tlabel 20) [ 7332.113915] firewire_core: Unsolicited response (source ffc1, tlabel 9) [ 7332.114926] firewire_core: Unsolicited response (source ffc1, tlabel 9) [ 7332.116384] firewire_core: Unsolicited response (source ffc1, tlabel 9) [ 7332.136536] firewire_core: Unsolicited response (source ffc1, tlabel 24) [ 7332.136745] firewire_core: Unsolicited response (source ffc1, tlabel 24) [ 7332.206641] firewire_core: Unsolicited response (source ffc1, tlabel 35) [ 7332.503467] firewire_core: Unsolicited response (source ffc1, tlabel 21) [ 7953.959850] usb 1-1.2: reset high speed USB device using ehci_hcd and address 3 [ 8719.469428] usb 1-1.2: reset high speed USB device using ehci_hcd and address 3 [10626.237564] usb 1-1.2: reset high speed USB device using ehci_hcd and address 3 [16790.288018] usb 1-1.2: reset high speed USB device using ehci_hcd and address 3 [16988.171279] usb 1-1.2: reset high speed USB device using ehci_hcd and address 3 (veyepar)juser@cnt1:~$ Is this anything I should care about? -- Carl K |
From: Stefan R. <st...@s5...> - 2011-08-10 21:46:50
|
On Aug 10 Clemens Ladisch wrote: > Bah, the bytes of these few commands are not worth counting. :-) # CONFIG_DEBUG_INFO is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_OPTIMIZE_INLINING is not set size before size after delta --------------------------------------------------------------- core-cdev.s 87588 89244 +1656 core-cdev.o 25664 25984 +320 (It's all in slow paths and doesn't affect those who don't set CONFIG_COMPAT.) > > > > Is it worthwhile? > > Definitely. OK, I send a variant to -devel. -- Stefan Richter -=====-==-== =--- -=-=- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-08-10 21:06:22
|
On Aug 10 Carl Karsten wrote: [...] > async-test receive/send... > > It showed something like (I am doing this from memory, see why below) > 4096 packets, 0.17 MB/s > > same when I switched > > dmesg shows lots of > > [482238.255966] usb 1-1.2: reset high speed USB device using ehci_hcd > and address 3 > > I am not sure what all I had done to the box, so rebooted. [...] Maybe a FireWire kernel driver bug could be the cause and USB a victim, by the FW driver corrupting memory and other kernel subsystems beginning to act strange. Or USB trouble was the cause and FireWire slowdown one result of it. (I don't know whether the above USB message is about the hardware doing something to the kernel, or the kernel doing something to the hardware. grep doesn't find the message in the source with the string fragments that I tried.) -- Stefan Richter -=====-==-== =--- -=-=- http://arcgraph.de/sr/ |
From: Carl K. <ca...@pe...> - 2011-08-10 18:25:17
|
I am using this box to test my tests. currently async-test isn't alerting me to a problem, but it seems to be having a problem. so this is a problem :) async-test receive/send... It showed something like (I am doing this from memory, see why below) 4096 packets, 0.17 MB/s same when I switched dmesg shows lots of [482238.255966] usb 1-1.2: reset high speed USB device using ehci_hcd and address 3 I am not sure what all I had done to the box, so rebooted. now async-test ( shows: 20459520 packets, 20.82 MB/s dmesg: [ 70.496550] irq_handler: 33 callbacks suppressed [ 70.496553] firewire_ohci: isochronous cycle inconsistent [ 70.496645] firewire_core: phy config: card 1, new root=ffc1, gap_count=5 [ 70.991546] firewire_core: created device fw2: GUID 001106660000052c, S400 [ 70.991599] firewire_core: created device fw3: GUID 001e8c0000417075, S400 I am fielding around trying to get it back to the problem state. any suggestions? -- Carl K |
From: Carl K. <ca...@pe...> - 2011-08-10 17:36:57
|
On Wed, Aug 10, 2011 at 12:05 PM, Clemens Ladisch <cl...@la...> wrote: > Stefan Richter wrote: >> On Aug 10 Clemens Ladisch wrote: >> > So I'd guess the actual cost (.code section) is not nearly that high. >> >> FWIW, this is from one of the six u64_to_uptr call sites, >> ioctl_get_info(): >> ... >> mov %eax, %r13d # D.30771, D.30771 >> movq %gs:kernel_stack,%rdx #, pfo_ret__ >> testb $2, -8132(%rdx) #, <variable>.status >> cmove %rax, %r13 # D.30771,, D.30771, D.33010 > > Bah, the bytes of these few commands are not worth counting. :-) > >> And this appear to be the two uptr_to_u64 call sites: ... > > Where current_thread_info() was _already_ being used. > >> > > Is it worthwhile? > > Definitely. > > > Carl, if you're still reading this: Stefan's kernel patch will fix your > problem, but you could just as well replace (u64)&something with > (unsigned long)&something in async-test.c. > This one, right? 313 get_info.bus_reset = (u64)&bus_reset; -- Carl K |
From: Clemens L. <cl...@la...> - 2011-08-10 17:01:26
|
Stefan Richter wrote: > On Aug 10 Clemens Ladisch wrote: > > So I'd guess the actual cost (.code section) is not nearly that high. > > FWIW, this is from one of the six u64_to_uptr call sites, > ioctl_get_info(): > ... > mov %eax, %r13d # D.30771, D.30771 > movq %gs:kernel_stack,%rdx #, pfo_ret__ > testb $2, -8132(%rdx) #, <variable>.status > cmove %rax, %r13 # D.30771,, D.30771, D.33010 Bah, the bytes of these few commands are not worth counting. :-) > And this appear to be the two uptr_to_u64 call sites: ... Where current_thread_info() was _already_ being used. > > > Is it worthwhile? Definitely. Carl, if you're still reading this: Stefan's kernel patch will fix your problem, but you could just as well replace (u64)&something with (unsigned long)&something in async-test.c. Regards, Clemens |
From: Stefan R. <st...@s5...> - 2011-08-10 14:34:57
|
On Aug 10 Clemens Ladisch wrote: > Stefan Richter wrote: > > size before size after delta > > --------------------------------------------------------------- > > core-cdev.s 342946 352407 +9461 > > core-cdev.o 126544 130600 +4056 > > Is this with debug information? Yes it is; not sure why I didn't go on to test without it yesterday. > Because I cannot see how this many > bytes could be actual code, even with inlining (is_compat_task()'s > current_thread_info() call should end up as one pointer read). > > So I'd guess the actual cost (.code section) is not nearly that high. FWIW, this is from one of the six u64_to_uptr call sites, ioctl_get_info(): ==== before: .LBB942: .loc 1 439 0 movq 8(%rbx), %rax # <variable>.device, temp.1345 mov 4(%r12), %edx # <variable>.get_info.rom_length, <variable>.get_info.rom_length movq 752(%rax), %r15 # <variable>.config_rom_length, <variable>.config_rom_length movq 744(%rax), %r13 # <variable>.config_rom, D.30770 salq $2, %r15 #, tmp77 cmpq %rdx, %r15 # <variable>.get_info.rom_length, tmp77 cmova %rdx, %r15 # tmp77,, <variable>.get_info.rom_length, tmp77 call might_fault # movq %r13, %rsi # D.30770, movl %r15d, %edx # tmp77, movq %r14, %rdi # D.30762, call _copy_to_user # ==== after: .LBB1062: .loc 1 457 0 movq 8(%rbx), %rcx # <variable>.device, temp.1345 mov 4(%r12), %r15d # <variable>.get_info.rom_length, D.30774 mov %eax, %r13d # D.30771, D.30771 movq 752(%rcx), %rdx # <variable>.config_rom_length, movq %rdx, -104(%rbp) #, %sfp movq 744(%rcx), %r14 # <variable>.config_rom, D.30779 movq %gs:kernel_stack,%rdx #, pfo_ret__ testb $2, -8132(%rdx) #, <variable>.status cmove %rax, %r13 # D.30771,, D.30771, D.33010 call might_fault # movq -104(%rbp), %rdx # %sfp, tmp84 movq %r13, %rdi # D.33010, movq %r14, %rsi # D.30779, salq $2, %rdx #, tmp84 cmpq %r15, %rdx # D.30774, tmp84 cmova %r15, %rdx # tmp84,, D.30774, tmp84 call _copy_to_user # ==== And this appear to be the two uptr_to_u64 call sites: ==== before: .L197: .loc 1 1055 0 movq (%rbx), %r14 # <variable>.queue_iso.packets, p mov 16(%rbx), %eax # <variable>.queue_iso.size, D.31346 movq %gs:kernel_stack,%rcx #, pfo_ret__ movq %r14, %rdx # p, roksum add %rax,%rdx ; sbb %rsi,%rsi ; cmp %rdx,-8120(%rcx) ; sbb $0,%rsi # D.31346, roksum,, <variable>.addr_limit.seg ==== after: .L197: .loc 1 1073 0 movq (%rbx), %rax # <variable>.queue_iso.packets, D.31353 movq %gs:kernel_stack,%rcx #, pfo_ret__ testb $2, -8132(%rcx) #, <variable>.status mov %eax, %r14d # D.31353, D.31353 cmove %rax, %r14 # D.31353,, D.31353, p mov 16(%rbx), %eax # <variable>.queue_iso.size, D.31355 movq %r14, %rdx # p, roksum add %rax,%rdx ; sbb %rsi,%rsi ; cmp %rdx,-8120(%rcx) ; sbb $0,%rsi # D.31355, roksum,, <variable>.addr_limit.seg ==== > > Is it worthwhile? > > Arch-independent code should not depend on knowledge of compat_ptr()'s > implementation details. If we don't use compat_ptr(), we don't depend on its details. ;-) -- Stefan Richter -=====-==-== =--- -=-=- http://arcgraph.de/sr/ |
From: Clemens L. <cl...@la...> - 2011-08-10 07:19:21
|
Stefan Richter wrote: > On Aug 09 Clemens Ladisch wrote: > > I wrote: > > > get_info.bus_reset = (u64)&bus_reset; > > > > Uh-oh. 32-bit gcc 4.4.4 says "cast from pointer to integer of different > > size" and sign-extends the value. > > Hm, an old C book here about ANSI C says that your code is correct, > since the compiler would first cast the pointer into an unsigned integer > of the same size as the pointer's, then go on with integer-to-integer > conversion to whatever target type you have. > [...] > I wonder whether C90/C99 turned the ANSI way around or made it an > implementation specific thing. Both ISO C90 and C99 are identical with the respective ANSI standards. latest C99 draft: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf 6.3.2.3 6: | Any pointer type may be converted to an integer type. | Except [for a null pointer], the result is implementation-defined. C90 draft (third public review): http://flash-gordon.me.uk/ansi.c.txt 3.3.4: | A pointer may be converted to an integral type. The size of integer | required and the result are implementation-defined. [...] | An arbitrary integer may be converted to a pointer. The result is | implementation-defined./37/ | | 37. The mapping functions for converting a pointer to an integer or | an integer to a pointer are intended to be consistent with the | addressing structure of the execution environment. C90 Rationale for 3.3.4: | Nothing portable can be said about casting integers to pointers, or | vice versa, since the two are now incommensurate. | The definition of these conversions adopted in the Standard resembles | that in the Base Document, but with several significant differences. | The Base Document required that a pointer successfully converted to | an integer must be guaranteed to be convertible back to the same | pointer. This integer-to-pointer conversion is now specified as | implementation-defined. While a high-quality implementation would | preserve the same address value whenever possible, it was considered | impractical to require that the identical representation be preserved. | The Committee noted that, on some current machine implementations, | identical representations are required for efficient code generation | for pointer comparisons and arithmetic operations. (The "Base Document" is Ritchie's "The C Reference Manual", which was also published as appendix A of the old K&R.) > Anyhow. Perhaps not entirely by accident, Kristian for example put the > following into libraw1394's fw-cdev backend: > > #define ptr_to_u64(p) ((__u64)(unsigned long)(p)) > #define u64_to_ptr(p) ((void *)(unsigned long)(p)) > > Which looks good to me. Because in Linux, pointers are guaranteed to fit into unsigned long. C99 has uintptr_t for this (but says it's optional because such an integer type might not exist). > > firewire-cdev.c's u64_to_uptr() differs from compat_ptr() in that the > > latter correctly masks the source pointer to 32 bits. > > > > This is definitely a bug in async-test.c, but shouldn't the kernel use > > compat_ptr() for all pointers when is_compat_task()? u64_to_uptr() > > will definitely be wrong on s390 and tile (not that we care about those). > > Indeed we don't care about s390; they don't have PCI and we don't have any > non-PCI controller driver. > > Tile does support PCI (Express), but the userbase of FireWire on Tile (&& > 32 bit userland on 64 bit kernel) has silently put up with our bugs so far. arch/tile/Kconfig: | # Please note: TILE-Gx support is not yet finalized; this is | # the preliminary support. TILE-Gx drivers are only provided | # with the alpha or beta test versions for Tilera customers. | config TILEGX | depends on EXPERIMENTAL | bool "Building with TILE-Gx (64-bit) compiler and toolchain" > Let's pretend for a minute that we do care: > ... > +#ifdef CONFIG_COMPAT > +static inline void __user *u64_to_uptr(__u64 value) Nitpick: __u64 is meant to be used (only) in userspace-visible kernel headers, because u64 is not a reserved identifier in C9x. Kernel code can use u64. > +{ > + if (is_compat_task()) > + return compat_ptr(value); > ... > > gcc 4.4.5 x86-64 makes this of it: > > size before size after delta > --------------------------------------------------------------- > core-cdev.s 342946 352407 +9461 > core-cdev.o 126544 130600 +4056 Is this with debug information? Because I cannot see how this many bytes could be actual code, even with inlining (is_compat_task()'s current_thread_info() call should end up as one pointer read). So I'd guess the actual cost (.code section) is not nearly that high. > Is it worthwhile? Arch-independent code should not depend on knowledge of compat_ptr()'s implementation details. Regards, Clemens |
From: Stefan R. <st...@s5...> - 2011-08-09 20:33:07
|
On Aug 09 Stefan Richter wrote: > +#ifdef CONFIG_COMPAT > +static inline void __user *u64_to_uptr(__u64 value) > +{ > + if (is_compat_task()) > + return compat_ptr(value); > + else > + return (void __user *)(unsigned long)value; > +} > + > +static inline __u64 uptr_to_u64(void __user *ptr) > +{ > + if (is_compat_task()) > + return ptr_to_compat(ptr); > + else > + return (__u64)(unsigned long)ptr; > +} [...] > gcc 4.4.5 x86-64 makes this of it: > > size before size after delta > --------------------------------------------------------------- > CONFIG_CC_OPTIMIZE_FOR_SIZE=y > core-cdev.s 342946 352407 +9461 > core-cdev.o 126544 130600 +4056 > firewire-core.ko 454874 458930 +4056 > --------------------------------------------------------------- > CONFIG_CC_OPTIMIZE_FOR_SIZE=n > core-cdev.s 369209 379158 +9949 > core-cdev.o 133488 137616 +4128 > firewire-core.ko 481898 486002 +4104 > > Is it worthwhile? PS: Same result if the "inline"s are omitted. CONFIG_OPTIMIZE_INLINING=n -- Stefan Richter -=====-==-== =--- -=--= http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2011-08-09 20:17:39
|
On Aug 09 Clemens Ladisch wrote: > I wrote: > > get_info.bus_reset = (u64)&bus_reset; > > Uh-oh. 32-bit gcc 4.4.4 says "cast from pointer to integer of different > size" and sign-extends the value. Hm, an old C book here about ANSI C says that your code is correct, since the compiler would first cast the pointer into an unsigned integer of the same size as the pointer's, then go on with integer-to-integer conversion to whatever target type you have. Gcc C isn't ANSI C of course. Their site says: "A cast from pointer to integer discards most-significant bits if the pointer representation is larger than the integer type, sign-extends¹ if the pointer representation is smaller than the integer type, otherwise the bits are unchanged." "¹) Future versions of GCC may zero-extend, or use a target-defined ptr_extend pattern. Do not rely on sign extension." http://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html I wonder whether C90/C99 turned the ANSI way around or made it an implementation specific thing. Anyhow. Perhaps not entirely by accident, Kristian for example put the following into libraw1394's fw-cdev backend: #define ptr_to_u64(p) ((__u64)(unsigned long)(p)) #define u64_to_ptr(p) ((void *)(unsigned long)(p)) Which looks good to me. By sheer luck or maybe because I was warned by gcc on x86-32, the simple C examples in http://user.in-berlin.de/~s5r6/linux1394/utils/ cast to unsigned long first, too. > firewire-cdev.c's u64_to_uptr() differs from compat_ptr() in that the > latter correctly masks the source pointer to 32 bits. > > This is definitely a bug in async-test.c, but shouldn't the kernel use > compat_ptr() for all pointers when is_compat_task()? u64_to_uptr() > will definitely be wrong on s390 and tile (not that we care about those). Indeed we don't care about s390; they don't have PCI and we don't have any non-PCI controller driver. Tile does support PCI (Express), but the userbase of FireWire on Tile (&& 32 bit userland on 64 bit kernel) has silently put up with our bugs so far. Let's pretend for a minute that we do care: --- drivers/firewire/core-cdev.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/firewire/core-cdev.c +++ b/drivers/firewire/core-cdev.c @@ -214,19 +214,37 @@ struct outbound_phy_packet_event { struct inbound_phy_packet_event { struct event event; struct fw_cdev_event_phy_packet phy_packet; }; +#ifdef CONFIG_COMPAT +static inline void __user *u64_to_uptr(__u64 value) +{ + if (is_compat_task()) + return compat_ptr(value); + else + return (void __user *)(unsigned long)value; +} + +static inline __u64 uptr_to_u64(void __user *ptr) +{ + if (is_compat_task()) + return ptr_to_compat(ptr); + else + return (__u64)(unsigned long)ptr; +} +#else static inline void __user *u64_to_uptr(__u64 value) { return (void __user *)(unsigned long)value; } static inline __u64 uptr_to_u64(void __user *ptr) { return (__u64)(unsigned long)ptr; } +#endif /* CONFIG_COMPAT */ static int fw_device_op_open(struct inode *inode, struct file *file) { struct fw_device *device; struct client *client; gcc 4.4.5 x86-64 makes this of it: size before size after delta --------------------------------------------------------------- CONFIG_CC_OPTIMIZE_FOR_SIZE=y core-cdev.s 342946 352407 +9461 core-cdev.o 126544 130600 +4056 firewire-core.ko 454874 458930 +4056 --------------------------------------------------------------- CONFIG_CC_OPTIMIZE_FOR_SIZE=n core-cdev.s 369209 379158 +9949 core-cdev.o 133488 137616 +4128 firewire-core.ko 481898 486002 +4104 Is it worthwhile? -- Stefan Richter -=====-==-== =--- -=--= http://arcgraph.de/sr/ |
From: Mike A. <mik...@gm...> - 2011-08-09 18:41:36
|
Right, So in both directions (once my expresscard was detected) I got absolutely no read problems going from a XIO2200A to a XIO2200A at all. That suggests that the built-in Ricoh card is the one with the problem going over 1800 bytes. I haven't been able to verify if has that problem connected to anything other than a XIO2200A, but that's not really a test I can run myself. I'm not sure if there's anything that can be done for the Ricoh card, other than avoid using it, or specifically setting an explicit request size when using it, but I'm open to suggestions? Thanks, Mike 5:) |
From: Carl K. <ca...@pe...> - 2011-08-09 16:12:48
|
On Tue, Aug 9, 2011 at 10:32 AM, Clemens Ladisch <cl...@la...> wrote: > Carl Karsten wrote: >> ioctl get_info: Bad address >> >> https://gitorious.org/cfk_misc/fwdiag/blobs/master/async-test.c > > int main(int argc, char *argv[]) > { > struct fw_cdev_get_info get_info; > struct fw_cdev_event_bus_reset bus_reset; > ... > get_info.version = 3; > get_info.rom_length = 0; > get_info.rom = 0; > get_info.bus_reset = (u64)&bus_reset; > get_info.bus_reset_closure = 0; > if (ioctl(fd, FW_CDEV_IOC_GET_INFO, &get_info) == -1) { > perror("ioctl get_info"); > > Which architectures are you using in userspace and in the kernel? > > (veyepar)juser@cnt2:~$ file /sbin/async-test /sbin/async-test: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.15, not stripped (veyepar)juser@cnt2:~$ uname -a Linux cnt2 2.6.38-11-generic #47-Ubuntu SMP Fri Jul 15 19:27:09 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux -- Carl K |