linux1394-user Mailing List for IEEE 1394 for Linux (Page 8)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(29) |
Nov
(36) |
Dec
(46) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(60) |
Feb
(82) |
Mar
(46) |
Apr
(50) |
May
(89) |
Jun
(60) |
Jul
(80) |
Aug
(130) |
Sep
(104) |
Oct
(105) |
Nov
(123) |
Dec
(107) |
2002 |
Jan
(142) |
Feb
(105) |
Mar
(63) |
Apr
(117) |
May
(136) |
Jun
(75) |
Jul
(105) |
Aug
(103) |
Sep
(149) |
Oct
(149) |
Nov
(98) |
Dec
(144) |
2003 |
Jan
(161) |
Feb
(100) |
Mar
(118) |
Apr
(126) |
May
(157) |
Jun
(173) |
Jul
(156) |
Aug
(89) |
Sep
(83) |
Oct
(106) |
Nov
(84) |
Dec
(69) |
2004 |
Jan
(119) |
Feb
(233) |
Mar
(232) |
Apr
(104) |
May
(113) |
Jun
(132) |
Jul
(87) |
Aug
(129) |
Sep
(186) |
Oct
(88) |
Nov
(148) |
Dec
(180) |
2005 |
Jan
(223) |
Feb
(176) |
Mar
(148) |
Apr
(193) |
May
(188) |
Jun
(236) |
Jul
(144) |
Aug
(89) |
Sep
(44) |
Oct
(86) |
Nov
(114) |
Dec
(89) |
2006 |
Jan
(94) |
Feb
(97) |
Mar
(57) |
Apr
(117) |
May
(46) |
Jun
(63) |
Jul
(51) |
Aug
(72) |
Sep
(50) |
Oct
(142) |
Nov
(70) |
Dec
(52) |
2007 |
Jan
(60) |
Feb
(67) |
Mar
(80) |
Apr
(81) |
May
(78) |
Jun
(52) |
Jul
(64) |
Aug
(55) |
Sep
(40) |
Oct
(87) |
Nov
(70) |
Dec
(44) |
2008 |
Jan
(80) |
Feb
(12) |
Mar
(82) |
Apr
(64) |
May
(33) |
Jun
(53) |
Jul
(41) |
Aug
(26) |
Sep
(35) |
Oct
(21) |
Nov
(30) |
Dec
(42) |
2009 |
Jan
(17) |
Feb
(32) |
Mar
(10) |
Apr
(19) |
May
(19) |
Jun
(28) |
Jul
(41) |
Aug
(14) |
Sep
(5) |
Oct
(46) |
Nov
(23) |
Dec
(20) |
2010 |
Jan
(46) |
Feb
(13) |
Mar
(9) |
Apr
(2) |
May
(19) |
Jun
(28) |
Jul
(37) |
Aug
(23) |
Sep
(5) |
Oct
(32) |
Nov
(19) |
Dec
(18) |
2011 |
Jan
(23) |
Feb
(9) |
Mar
(19) |
Apr
(38) |
May
(83) |
Jun
(30) |
Jul
(46) |
Aug
(32) |
Sep
(6) |
Oct
(3) |
Nov
(25) |
Dec
(31) |
2012 |
Jan
(21) |
Feb
(12) |
Mar
(19) |
Apr
(7) |
May
(27) |
Jun
(7) |
Jul
(2) |
Aug
(15) |
Sep
(8) |
Oct
(11) |
Nov
|
Dec
(3) |
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(14) |
Jul
(1) |
Aug
(3) |
Sep
(4) |
Oct
(5) |
Nov
|
Dec
|
2014 |
Jan
(14) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(2) |
Jun
(7) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(14) |
Nov
(5) |
Dec
(18) |
2015 |
Jan
(3) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
(11) |
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
|
May
(4) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Carl K. <ca...@pe...> - 2012-10-22 15:40:47
|
A friend is helping me by coding up a diagnostic tool. It is meant to test firewire hardware. We don't have a baseline to know the quality of the hardware we are testing, so we are not sure if the results are due to faulty hardware or faulty code or we just don't know how to interpret the results. Could someone help review this? https://gitorious.org/~eviljoel/cfk_misc/fwdiag-cleanup/ 1 box with 2 controllers, cable between the 2, here is what the results look like: ************************************ (veyepar)juser@pc9d:~/fwdiag-cleanup$ sudo ./async-loop-ck 0, node_id: 65473, local_node_id: 65473, devices[ 0 ]->receiveDescriptor: /dev/fw0 1, node_id: 65472, local_node_id: 65472, devices[ 1 ]->receiveDescriptor: /dev/fw1 2, node_id: 65472, local_node_id: 65473, devices[ 0 ]->sendDescriptor: /dev/fw2 3, node_id: 65473, local_node_id: 65472, devices[ 1 ]->sendDescriptor: /dev/fw3 Main process: starting receiver Main: receiver started, pid: 11107; waiting 4 seconds... Receiver child process 11107 starting... Main process: starting sender Main: sender started, pid: 11108 Main process, waiting for child processes to finish... Sender child process 11108 starting... Received 524289389 bytes = 500.00 MB in 511745 packets in 21 seconds ...receiver finished Sent 524288119 bytes = 500.00 MB in 511753 packets in 21 seconds ...sender finished Main: processes finished Main process: starting receiver Main: receiver started, pid: 11109; waiting 4 seconds... Receiver child process 11109 starting... unexpected packet: 0x7cf2c unexpected packet: 0x7cf2d unexpected packet: 0x7cf2e unexpected packet: 0x7cf2f unexpected packet: 0x7cf30 unexpected packet: 0x7cf31 unexpected packet: 0x7cf32 unexpected packet: 0x7cf33 unexpected packet: 0x7cf34 unexpected packet: 0x7cf35 unexpected packet: 0x7cf36 unexpected packet: 0x7cf37 unexpected packet: 0x7cf38 unexpected packet: 0x7cf39 Main process: starting sender Main: sender started, pid: 11110 Main process, waiting for child processes to finish... Sender child process 11110 starting... Received 524289257 bytes = 500.00 MB in 511746 packets in 32 seconds ...receiver finished Sent 524288119 bytes = 500.00 MB in 511753 packets in 28 seconds ...sender finished Main: processes finished ************************************ And sometimes it gets stuck: ************************************ (veyepar)juser@pc9d:~/fwdiag-cleanup$ sudo ./async-loop-ck 0, node_id: 65472, local_node_id: 65472, devices[ 0 ]->receiveDescriptor: /dev/fw0 1, node_id: 65473, local_node_id: 65473, devices[ 1 ]->receiveDescriptor: /dev/fw1 2, node_id: 65472, local_node_id: 65473, devices[ 1 ]->sendDescriptor: /dev/fw2 3, node_id: 65473, local_node_id: 65472, devices[ 0 ]->sendDescriptor: /dev/fw3 Main process: starting receiver Main: receiver started, pid: 11516; waiting 4 seconds... Receiver child process 11516 starting... Main process: starting sender Main: sender started, pid: 11517 Main process, waiting for child processes to finish... Sender child process 11517 starting... send error: 0x10 ************************************ -- Carl K |
From: Stefan R. <st...@s5...> - 2012-10-03 17:16:08
|
Dear all, Linux kernel 3.6 has been released last Sunday. It brings a few small fixes and optimizations to the firewire drivers [http://marc.info/?l=linux1394-devel&m=134355348001969] and a new sysfs attribute "/sys/bus/firewire/devices/fw[0-9]*/is_local" which can for example be used to set special ownership of local nodes' /dev/fw* files when they are created and launch target-like usermode drivers. While there aren't many news to report about the firewire kernel drivers, there is a big release of the FFADO project to celebrate: v2.1.0 of the Free FireWire Audio Drivers has been released on September 18th, with largely expanded hardware support and many improvements. [http://www.ffado.org/?q=release/2.1.0] Enjoy, -- Stefan Richter -=====-===-- =-=- ---== http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-09-27 23:05:20
|
On Sep 27 Nicklas Eriksson wrote: > I replaced the card with an older, very old, aten ic1394 today, that do > work. If it would be of use I can put it in again. But here is the > numbers I have printed on the card. > > Written on the pcb: BIGBEN-51016499-1.2B > Label, backside of card: 203560825154400345 > > It has the two firewire ports at the bottom, the analogue port on top > with an audio out in the middle. That one I never understood the reason > for, never had any use for it... Maybe it's for analogue. To bad neither > analogue nor dv work in linux. > > Hope this is of any help. My MovieBoard 12 has the same number on the PCB (BIGBEN-51016499-1.2B) and the same ports as you describe. Only the serial(?) number on the sticker on the back differs (242000825982304772). So we do have the same board revision and possibly also the same chip, a Fujitsu chip with "MB87J3560" printed on. -- Stefan Richter -=====-===-- =--= ===-- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-09-27 17:34:33
|
On Sep 26 Nicklas Eriksson wrote: [...] > 03:06.0 Multimedia controller: Pinnacle Systems Inc. AV/DV Studio Capture Card > 03:06.1 FireWire (IEEE 1394): Pinnacle Systems Inc. Device 0015 Could you check the numerical device IDs with "lspci -nnvv"? I would like to know whether I have the same or a different card (https://bugzilla.kernel.org/show_bug.cgi?id=36622#c7). [PS, your message was side-tracked into the mailinglist moderation queue but I am not sure why. Could have been the missing subject or some Yahoo mail headers or the HTML body part. Please ignore this little nuisance. Normally the list is unmoderated, and false-positive flagging of mails for moderation is rare.] -- Stefan Richter -=====-===-- =--= ==-== http://arcgraph.de/sr/ |
From: Nicklas E. <eri...@ya...> - 2012-09-26 20:33:46
|
Hi, My Pinnacle Movieboard stopped working with the new firewire stack. Strange since it worked in the old. Capture video was stable enough. I understand it is a known issue, but anyway dissapointing. The analog breakout box never worked in linux, but that is not relevant here I guess. Just wanted to post it, don't know if it can be to any use. /nicklas Kernel 3.2.0-23-realtime ~$ lsmod | grep -e 1394 -e firewire firewire_ohci 40995 0 firewire_core 63680 1 firewire_ohci crc_itu_t 12707 1 firewire_core ~$ dmesg | grep firewire [ 4.381935] firewire_ohci 0000:03:06.1: Pinnacle MovieBoard is not yet supported [ 4.382092] firewire_ohci: probe of 0000:03:06.1 failed with error -38 Peripheral: Pinnacle Studio Plus 700-PCI ~$ lspci 00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge 00:02.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (ext gfx port 0) 00:0a.0 PCI bridge: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 5) 00:11.0 SATA controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] 00:12.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:12.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1 Controller 00:12.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1 Controller 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 3c) 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 IDE Controller 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC host controller 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge 00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI2 Controller 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h Processor Link Control 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Juniper [Radeon HD 5700 Series] 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Juniper HDMI Audio [Radeon HD 5700 Series] 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) 03:06.0 Multimedia controller: Pinnacle Systems Inc. AV/DV Studio Capture Card 03:06.1 FireWire (IEEE 1394): Pinnacle Systems Inc. Device 0015 |
From: Apostolos B. <ba...@gm...> - 2012-09-04 11:57:54
|
Upgrading the BIOS on this motherboard creates two problems. First it gives the same error (irq 16 etc). And more importantly kills booting linux in UEFI mode which is nice if you don't want to use a bootloader etc. I had to downgrade to the "original" BIOS (version 57) to get my computer working again. But that doesn't matter. The irq problem remains. Anything more i can do?? Regards. On 09/02/2012 04:56 PM, Clemens Ladisch wrote: > Apostolos Bartziokas wrote: >> [ 3.123973] irq 16: nobody cared >> >> 16: 100001 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb5 >> 18: 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi firewire_ohci > Yeah, that's a misrouted interrupt. > > The reason for that is unclear, but you definitely should upgrade to > BIOS version 0085 (it has fixes for ASPM, which might help). > > > Regards, > Clemens > |
From: Clemens L. <cl...@la...> - 2012-09-02 13:57:49
|
Apostolos Bartziokas wrote: > [ 3.123973] irq 16: nobody cared > > 16: 100001 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb5 > 18: 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi firewire_ohci Yeah, that's a misrouted interrupt. The reason for that is unclear, but you definitely should upgrade to BIOS version 0085 (it has fixes for ASPM, which might help). Regards, Clemens |
From: Apostolos B. <ba...@gm...> - 2012-09-02 10:56:47
|
Clemens thanks for the reply. This is the message i get today. [ 3.123973] irq 16: nobody cared (try booting with the "irqpoll" option) [ 3.123976] Pid: 0, comm: swapper/0 Not tainted 3.5.3-1-ARCH #1 [ 3.123976] Call Trace: [ 3.123977] <IRQ> [<ffffffff810d4d3d>] __report_bad_irq+0x3d/0xe0 [ 3.123984] [<ffffffff810d5033>] note_interrupt+0x1a3/0x1f0 [ 3.123986] [<ffffffff810d292f>] handle_irq_event_percpu+0xbf/0x260 [ 3.123988] [<ffffffff810d2b18>] handle_irq_event+0x48/0x70 [ 3.123990] [<ffffffff810d5b4a>] handle_fasteoi_irq+0x5a/0x100 [ 3.123993] [<ffffffff810160c2>] handle_irq+0x22/0x40 [ 3.123996] [<ffffffff81484cea>] do_IRQ+0x5a/0xe0 [ 3.123998] [<ffffffff8147c12a>] common_interrupt+0x6a/0x6a [ 3.123999] <EOI> [<ffffffffa0305f01>] ? acpi_idle_enter_c1+0xda/0x104 [processor] [ 3.124013] [<ffffffffa0305edc>] ? acpi_idle_enter_c1+0xb5/0x104 [processor] [ 3.124016] [<ffffffff8134f159>] cpuidle_enter+0x19/0x20 [ 3.124018] [<ffffffff8134f7a6>] cpuidle_idle_call+0xa6/0x330 [ 3.124021] [<ffffffff8101daaf>] cpu_idle+0xbf/0x130 [ 3.124024] [<ffffffff81456fbc>] rest_init+0x80/0x84 [ 3.124026] [<ffffffff818bbc35>] start_kernel+0x3c1/0x3ce [ 3.124028] [<ffffffff818bb673>] ? repair_env_string+0x5e/0x5e [ 3.124030] [<ffffffff818bb356>] x86_64_start_reservations+0x131/0x135 [ 3.124032] [<ffffffff818bb45a>] x86_64_start_kernel+0x100/0x10f [ 3.124033] handlers: [ 3.124037] [<ffffffffa01eb0b0>] usb_hcd_irq [usbcore] [ 3.124039] Disabling IRQ #16 The /proc/interupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 51 0 0 0 0 0 0 0 IR-IO-APIC-edge timer 1: 3 0 0 0 0 0 0 0 IR-IO-APIC-edge i8042 8: 1 0 0 0 0 0 0 0 IR-IO-APIC-edge rtc0 9: 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi acpi 12: 4 0 0 0 0 0 0 0 IR-IO-APIC-edge i8042 16: 100001 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb5 18: 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi firewire_ohci 23: 45 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb6 40: 0 0 0 0 0 0 0 0 DMAR_MSI-edge dmar0 42: 438598 0 0 0 0 0 0 0 IR-PCI-MSI-edge radeon 43: 25700 0 0 0 0 0 0 0 IR-PCI-MSI-edge ahci 44: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ahci 45: 1235 0 0 0 0 0 0 0 IR-PCI-MSI-edge xhci_hcd 46: 103914 0 0 0 0 0 0 0 IR-PCI-MSI-edge xhci_hcd 47: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge xhci_hcd 48: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge xhci_hcd 49: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge xhci_hcd 50: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge xhci_hcd 51: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge xhci_hcd 52: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge xhci_hcd 53: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge xhci_hcd 54: 619 0 0 0 0 0 0 0 IR-PCI-MSI-edge snd_hda_intel 55: 245 0 0 0 0 0 0 0 IR-PCI-MSI-edge snd_hda_intel 56: 264921 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0 57: 15 0 0 0 0 0 0 0 IR-PCI-MSI-edge mei NMI: 319 272 220 247 40 76 53 97 Non-maskable interrupts LOC: 226986 197865 217960 198983 135291 64230 126681 95503 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 319 272 220 247 40 76 53 97 Performance monitoring interrupts IWI: 0 0 0 0 0 0 0 0 IRQ work interrupts RTR: 0 0 0 0 0 0 0 0 APIC ICR read retries RES: 197071 70738 7916 1710 195 142 5251 149 Rescheduling interrupts CAL: 13370 71454 74796 75281 77564 75819 77180 77570 Function call interrupts TLB: 29311 35669 28538 26015 6356 10738 7476 14418 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 26 26 26 26 26 26 26 26 Machine check polls ERR: 0 MIS: 0 If you want more info let me know. Regards. On 09/02/2012 01:48 PM, Clemens Ladisch wrote: > Apostolos Bartziokas wrote: >> Since i installed linux on my new machine i get errors on my logs >> related to firewire. If i disable firewire from the motherboard bios the >> errors in the logs don't appear anymore. >> >> dmesg error: >> [ 3.084743] Pid: 0, comm: swapper/0 Not tainted 3.5.3-1-ARCH #1 >> [ 3.084744] Call Trace: >> [ 3.084745] <IRQ> [<ffffffff810d4d3d>] __report_bad_irq+0x3d/0xe0 > The beginning of the error message is missing, but this looks as if > interrupts from the FireWire controller might be routed to the wrong > interrupt line. > > What are the contents of /proc/interrupts? > > Please try updating the motherboard BIOS. > >> 03:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev 30) > This cheap and crappy PCIe/PCI bridge chip is known to have problems with > ASPM; I wouldn't be surprised if it also has broken interrupt handling. > > > Regards, > Clemens > |
From: Clemens L. <cl...@la...> - 2012-09-02 10:49:32
|
Apostolos Bartziokas wrote: > Since i installed linux on my new machine i get errors on my logs > related to firewire. If i disable firewire from the motherboard bios the > errors in the logs don't appear anymore. > > dmesg error: > [ 3.084743] Pid: 0, comm: swapper/0 Not tainted 3.5.3-1-ARCH #1 > [ 3.084744] Call Trace: > [ 3.084745] <IRQ> [<ffffffff810d4d3d>] __report_bad_irq+0x3d/0xe0 The beginning of the error message is missing, but this looks as if interrupts from the FireWire controller might be routed to the wrong interrupt line. What are the contents of /proc/interrupts? Please try updating the motherboard BIOS. > 03:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev 30) This cheap and crappy PCIe/PCI bridge chip is known to have problems with ASPM; I wouldn't be surprised if it also has broken interrupt handling. Regards, Clemens |
From: Apostolos B. <ba...@gm...> - 2012-09-01 16:35:22
|
Hello. Since i installed linux on my new machine i get errors on my logs related to firewire. If i disable firewire from the motherboard bios the errors in the logs don't appear anymore. version: (I started with 3.3.7 kernel and get the error up to this kernel) Linux mainland 3.5.3-1-ARCH #1 SMP PREEMPT Sun Aug 26 09:14:51 CEST 2012 x86_64 GNU/Linux kernel drivers: firewire_ohci 31653 0 firewire_core 52733 1 firewire_ohci crc_itu_t 1363 1 firewire_core dmesg error: (as i said the error goes away when i disable firewire form the bios) [ 3.084743] Pid: 0, comm: swapper/0 Not tainted 3.5.3-1-ARCH #1 [ 3.084744] Call Trace: [ 3.084745] <IRQ> [<ffffffff810d4d3d>] __report_bad_irq+0x3d/0xe0 [ 3.084750] [<ffffffff810d5033>] note_interrupt+0x1a3/0x1f0 [ 3.084752] [<ffffffff810d292f>] handle_irq_event_percpu+0xbf/0x260 [ 3.084754] [<ffffffff810d2b18>] handle_irq_event+0x48/0x70 [ 3.084755] [<ffffffff810d5b4a>] handle_fasteoi_irq+0x5a/0x100 [ 3.084757] [<ffffffff810160c2>] handle_irq+0x22/0x40 [ 3.084759] [<ffffffff81484cea>] do_IRQ+0x5a/0xe0 [ 3.084761] [<ffffffff8147c12a>] common_interrupt+0x6a/0x6a [ 3.084762] <EOI> [<ffffffffa02b3f01>] ? acpi_idle_enter_c1+0xda/0x104 [processor] [ 3.084775] [<ffffffffa02b3edc>] ? acpi_idle_enter_c1+0xb5/0x104 [processor] [ 3.084778] [<ffffffff8134f159>] cpuidle_enter+0x19/0x20 [ 3.084779] [<ffffffff8134f7a6>] cpuidle_idle_call+0xa6/0x330 [ 3.084781] [<ffffffff8101daaf>] cpu_idle+0xbf/0x130 [ 3.084783] [<ffffffff81456fbc>] rest_init+0x80/0x84 [ 3.084785] [<ffffffff818bbc35>] start_kernel+0x3c1/0x3ce [ 3.084787] [<ffffffff818bb673>] ? repair_env_string+0x5e/0x5e [ 3.084788] [<ffffffff818bb356>] x86_64_start_reservations+0x131/0x135 [ 3.084790] [<ffffffff818bb45a>] x86_64_start_kernel+0x100/0x10f [ 3.084790] handlers: [ 3.085650] [<ffffffffa01eb0b0>] usb_hcd_irq [usbcore] [ 3.086483] Disabling IRQ #16 The motherboard i am using is an Intel DZ77BH-55K lspci: 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4) 00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4) 00:1c.7 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 8 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation Z77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts PRO [Radeon HD 6800 Series] 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Barts HDMI Audio [Radeon HD 6800 Series] 03:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev 30) 04:02.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx] 05:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) 06:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (rev 11) The IRQ#16 seems to be related to the USB controllers which is puzzling. I don't have any firewire devices in order to test if it works ok. Thanks in advance. |
From: Dirk L. <dir...@gm...> - 2012-08-28 19:35:22
|
Hi Stefan, thanks for the reply. Am Dienstag, 28. August 2012, 16:19:26 schrieb Stefan Richter: > On Aug 28 Dirk Langner wrote: > > A friend of mine tries to attach his (Sony) camera to a NEC uPD72874 > > firewire card. Sometimes the captures works, most of the time the > > control of camera and firewire interface for whatever reason fails to > > work correctly. > > Is this a DV/HDV camcorder or an IIDC/DCAM industrial camera? > Which application is your friend using for control and capture? Sony DCR-TRV9E, DVCAM. We've tried with kdenlive, kino, but also dvgrab -i. The behaviour was unstable, sometimes a picture could be seen, but you hadn't had any control of the camera, most of the time simply nothing happens (especially using dvgrab). But also: sometimes the capture went through. > > dmesg throughs out the messages: > > [...] > > [ 480.812183] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 > > [firewire_core] [ 480.812210] [<ffffffffa0076eb5>] > > fw_device_op_release+0x1a5/0x270 [firewire_core] > > > > Has anybody seen error messages like that and know what this might cause? > > How to get around this problem? > > These two lines are unexpected. Please post all dmesg lines around these > two, not only the lines which contain something about firewire. If you > are only in the slightest doubt what could be related and what's not, > simply post everything from dmesg. (Try to keep the message size below 50 > kByte, otherwise the message will make a detour through the moderation > queue.) Ok, thanks. I'll try to obtain the requested info and keep you posted. Dirk |
From: Stefan R. <st...@s5...> - 2012-08-28 14:19:46
|
On Aug 28 Dirk Langner wrote: > A friend of mine tries to attach his (Sony) camera to a NEC uPD72874 firewire > card. Sometimes the captures works, most of the time the control of camera and > firewire interface for whatever reason fails to work correctly. Is this a DV/HDV camcorder or an IIDC/DCAM industrial camera? Which application is your friend using for control and capture? > dmesg throughs out the messages: > [ 424.051551] firewire_ohci: isochronous cycle inconsistent If this happens only at the moment when the camera is plugged in or switched on, then this is normal. The kernel simply always logs this, regardless whether a bus topology change happened or not and regardless whether isochronous DMAs are active or not. I guess we should suppress the message at least if isochronous DMA is off. > [ 480.812183] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] > [ 480.812210] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] > > Has anybody seen error messages like that and know what this might cause? How > to get around this problem? These two lines are unexpected. Please post all dmesg lines around these two, not only the lines which contain something about firewire. If you are only in the slightest doubt what could be related and what's not, simply post everything from dmesg. (Try to keep the message size below 50 kByte, otherwise the message will make a detour through the moderation queue.) > Thanks, > Dirk > > > > Kernel 3.0.0, Linux Mint 12 Should be OK. > libraw1394 2.0.7 This too. By the way, libraw1394 2.0.7 does not use ioctl_get_speed. > ~ $ lspci | grep FireWire > 04:06.0 FireWire (IEEE 1394): NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-ort PHY-Link Ctrlr (rev 01) Should work, from what I know. I have a NEC controller too, but a different model. > ~ $ lsmod | grep fire > firewire_ohci 40722 0 > firewire_core 63626 1 firewire_ohci > crc_itu_t 12707 1 firewire_core > > ~ $ ls -l /dev/fw* > crw------- 1 root root 251, 0 2012-08-04 15:22 /dev/fw0 > crw-rw----+ 1 root video 251, 1 2012-08-04 15:24 /dev/fw1 OK. > ~ $ dmesg | grep firewire > [ 2.028465] firewire_ohci 0000:04:06.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 > [ 2.084103] firewire_ohci: Added fw-ohci device 0000:04:06.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x1 > [ 2.584242] firewire_core: created device fw0: GUID 00004c010000404f, S400 > [ 95.874456] firewire_core: skipped bus generations, destroying all nodes > [ 96.372150] firewire_core: rediscovered device fw0 > [ 96.481178] firewire_core: created device fw1: GUID 08004601012fa403, S100 > [ 96.481187] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 > [ 96.481427] firewire_core: skipped bus generations, destroying all nodes > [ 96.980085] firewire_core: rediscovered device fw0 > [ 97.088906] firewire_core: rediscovered device fw1 > [ 97.097512] firewire_ohci: isochronous cycle inconsistent Looks normal. The "destroying all nodes" may sound scary or at least weird, but the procedure which prints this is actually pretty straightforward and common. Therefore this message is no longer printed by most recent kernels (3.4 and later). > [ 360.812159] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] > [ 360.812190] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] [...] As noted, these messages are unusual, but we need more context to learn what this is about. -- Stefan Richter -=====-===-- =--- ===-- http://arcgraph.de/sr/ |
From: Dirk L. <dir...@gm...> - 2012-08-28 12:14:08
|
Hi everybody, A friend of mine tries to attach his (Sony) camera to a NEC uPD72874 firewire card. Sometimes the captures works, most of the time the control of camera and firewire interface for whatever reason fails to work correctly. dmesg throughs out the messages: [ 424.051551] firewire_ohci: isochronous cycle inconsistent [ 480.812183] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 480.812210] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] Has anybody seen error messages like that and know what this might cause? How to get around this problem? Thanks, Dirk Kernel 3.0.0, Linux Mint 12 libraw1394 2.0.7 ~ $ lspci | grep FireWire 04:06.0 FireWire (IEEE 1394): NEC Corporation uPD72874 IEEE1394 OHCI 1.1 3-ort PHY-Link Ctrlr (rev 01) ~ $ lsmod | grep fire firewire_ohci 40722 0 firewire_core 63626 1 firewire_ohci crc_itu_t 12707 1 firewire_core ~ $ ls -l /dev/fw* crw------- 1 root root 251, 0 2012-08-04 15:22 /dev/fw0 crw-rw----+ 1 root video 251, 1 2012-08-04 15:24 /dev/fw1 ~ $ dmesg | grep firewire [ 2.028465] firewire_ohci 0000:04:06.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 [ 2.084103] firewire_ohci: Added fw-ohci device 0000:04:06.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x1 [ 2.584242] firewire_core: created device fw0: GUID 00004c010000404f, S400 [ 95.874456] firewire_core: skipped bus generations, destroying all nodes [ 96.372150] firewire_core: rediscovered device fw0 [ 96.481178] firewire_core: created device fw1: GUID 08004601012fa403, S100 [ 96.481187] firewire_core: phy config: card 0, new root=ffc1, gap_count=5 [ 96.481427] firewire_core: skipped bus generations, destroying all nodes [ 96.980085] firewire_core: rediscovered device fw0 [ 97.088906] firewire_core: rediscovered device fw1 [ 97.097512] firewire_ohci: isochronous cycle inconsistent [ 360.812159] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 360.812190] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] [ 424.051551] firewire_ohci: isochronous cycle inconsistent [ 480.812183] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 480.812210] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] [ 600.812214] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 600.812241] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] [ 600.812422] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 600.812445] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] [ 720.812198] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 720.812225] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] [ 720.812406] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 720.812429] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] [ 840.812189] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 840.812216] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] [ 840.812396] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 840.812419] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] [ 960.812219] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 960.812246] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] [ 960.812428] [<ffffffffa0074f50>] ? ioctl_get_speed+0x20/0x20 [firewire_core] [ 960.812451] [<ffffffffa0076eb5>] fw_device_op_release+0x1a5/0x270 [firewire_core] |
From: Jarvis S. <sch...@gm...> - 2012-08-24 23:49:42
|
I purchased this card from Amazon: http://www.amazon.com/gp/product/B003GAM68U/ref=oh_details_o00_s00_i00 It features the VT6315 chipset. After plugging my device in through this card, the problem disappeared. Not the ideal solution, but definitely solved my problem. Thanks for all the help! On Mon, Aug 6, 2012 at 11:15 AM, Jarvis Schultz <sch...@gm...>wrote: > Just FYI, I gave the Phantom Omni forum a quick overview of the > discussion that we have been having, and I just received a response. > Here is a quote from one of their support team members: > > > Most of the firewire cards have some firmware logic in them to arbitrate > the 1394 isochronous mode. The omni also operates in the isochronous mode. > > If the firmware in the 1394 chip has some problem, then you are going to > see it in someway of the other. Because, the isochronous mode is > > completely initiated and managed by the 1394 controller. > > He then provided a link to some recommended cards that seem to work. > I just ordered the cheapest recommended one, and I will report back > with the results and the card info. > > On Thu, Aug 2, 2012 at 8:49 PM, Jarvis Schultz <sch...@gm...> > wrote: > > > > On Thu, Aug 2, 2012 at 5:12 PM, Stefan Richter > > <st...@s5...> wrote: > > > > > > On Aug 02 Jarvis Schultz wrote: > > > > On Thu, Aug 2, 2012 at 1:54 AM, Stefan Richter > > > > <st...@s5...> > > > > wrote: > > > > > Your kernel "3.2.0-27" is possibly based on 3.2.6 or later. What > does > > > > > "grep firewire /proc/interrupts" show? > > > > > > > > > Here is the output of that: > > > > 19: 3043 0 0 0 0 > 0 > > > > 0 21 IO-APIC-fasteoi firewire_ohci > > > > > > I.e. your kernel has got the "don't use MSI on Ricoh OHCI-1394" flag > > > already in its built in table. > > > > > > [...] > > > > > Vice versa, if the quirk is built in, it can be switched off > > > > > by a different value to the module parameter: > > > [...] > > > > I tried both of these "quirk" levels, and there is no change to the > > > > behavior. > > > > > > Interesting; this means we could narrow the built-in quirk down to the > > > chip version which was originally reported as broken with MSI, and let > > > chip versions like yours use MSI again. But this doesn't help you one > > > bit, alas. > > > > > > [...] > > > > >> System Details: > > > > >> Kernel version - 3.2.0-27 > > > [...] > > > > grep command: > > > > # CONFIG_PREEMPT_RCU is not set > > > > CONFIG_PREEMPT_NOTIFIERS=y > > > > # CONFIG_PREEMPT_NONE is not set > > > > CONFIG_PREEMPT_VOLUNTARY=y > > > > # CONFIG_PREEMPT is not set > > > > > > Have a look whether your distribution also offers a kernel package > which > > > is called "lowlatency" or "desktop" or something along these lines --- > and > > > in effect has got CONFIG_PREEMPT=y and "# CONFIG_PREEMPT_VOLUNTARY is > not > > > set". The CONFIG_PREEMPT option is found under "Processor type and > > > features -> Preemption Model -> Preemptible Kernel (Low-Latency > Desktop)" > > > in the kernel configuration menu when kernel sources are configured as > > > preparation of a kernel build from source. > > > > > > CONFIG_PREEMPT means that kernel threads are put to sleep by the CPU > > > scheduler when it used up its time slice and another process is > waiting to > > > get CPU time, very much the same way as the CPU scheduler treats > userspace > > > processes when they used up their time slice. > > > > > > I am suggesting to try such a kernel because there is a slight chance > that > > > reduced scheduling latency helps the Phantom Omni drivers to queue > > > FireWire packets more steadily, which in turn might reduce the > likelihood > > > that Ricoh controller stops its DMA unrecoverably. > > > > > I just ran installed the most up-to-date lowlatency kernel that Ubuntu > > 12.04 has which was built around 3.2.0-23. To address the next > > comment, I booted into a console-only-mode, and made sure the fglrx > > drivers weren't loaded. I saw the same behavior as before. Also, I > > tried both kernels with the open source radeon drivers in a full > > desktop session, and repeatedly received the same errors. > > > > I attached my /proc/interrupts file as interrupts_log.txt > > > > > > Looks inconspicuous to me. Just one thing: Have you tried the > mainline > > > "radeon" driver instead of the closed source fglrx driver already? 3rd > > > party kernel drivers tend to be latency sources due to lack of > independent > > > review and tie-in into mainline development. > > > > > > [...] > > > > > Could you send the chip IDs as "lspci -nn | grep 1394" shows them? > > > > > > > > > Here it is: > > > > 09:00.3 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 PCIe IEEE > 1394 > > > > Controller [1180:e832] (rev 01) > > > > > > Thanks for this. Same PCI ID as in the report which led to kernel > commit > > > 320cfa6ce0b3, but rev 01 instead of rev 00. > > > > > > > >> Phantom Omni PDD drivers version = Linux JUJU PDD pre-beta > > > > >> > > > > >> libraw1394 version - 2.0.5 > > > > > > > > > > Are the Phantom Omni drivers kernel drivers or userspace drivers? > If > > > > > the > > > > > latter, are they using libraw1394? You could for example check > with > > > > > "ldd /path/to/the/driver/binary.xy" which lists all libraries to > which > > > > > 'binary.xy' is dynamically linked to. Libraries which are > statically > > > > > linked into a binary ( = incorporated into the binary) won't show > up > > > > > this > > > > > way though. > > > > > > > > > The drivers are userspace drivers, and they are distributed as just a > > > > sequence of shared libraries. The old drivers that they released > > > > depended > > > > on the raw1394 kernel module. These new "pre-beta JUJU" drivers do > not. > > > > I > > > > originally tried to get this working with their old drivers, and > > > > followed > > > > the instructions at this site: > > > > > https://wiki.sofa-framework.org/tdev/wiki/HowTo/SensableWithoutRaw1394 > > > > to > > > > create a "dummy" kernel module. > > > > > > Argh. :-) Nitpick: "ln /dev/null /dev/raw1394" probably would have > worked > > > just as well as "ln /dev/fw0 /dev/raw1394". /dev/fw* does not support > > > any of the ioctl/write/read operations that are valid on /dev/raw1394. > > > Anyway, the former necessity of this dummy module and dummy file is a > fine > > > showcase of the joys and wonders of non-free software. > > > > > > > I am not positive I was getting the same > > > > error messages, but I was getting the same "freezing" behavior. > > > > > > > > > The term "JUJU" implies that the drivers are not using libraw1394. > > > > > But if > > > > > they do, you should try to update to libraw1394 2.0.7 or later > because > > > > > it > > > > > has got changes which affect isochronous streaming. Current and > > > > > stable is > > > > > 2.1.0. Of course an update of the system-wide installed libraw1394 > > > > > would > > > > > only have effect if the Phantom Omni drivers are dynamically > linked to > > > > > it. > > > > > > > > > I am a little confused by their terminology. Their binaries are > > > > absolutely > > > > linked to libraw1394 libraries. I believe they are using the term > JUJU > > > > because they no longer use the kernel module raw1394. > > > > > > They never directly used the kernel module, they used libraw1394. > > > (Which is good because the developers of raw1394 intended the raw1394 > > > kernel interface to be private to the raw1394<-->libraw1394 pair. This > > > in turn facilitated the transition to the binary incompatible > > > <linux/firewire-cdev.h> kernel interface provided by firewire-core > > > while retaining compatibility with libraw1394 based application > > > software. libraw1394 v2 transparently uses raw1394's or > firewire-core's > > > mutually incompatible interfaces depending on what libraw1394 detects > to > > > be > > > available at runtime.) > > > > > > So this "JUJU" designation either refers to the accomplishment of > removing > > > that silly check for presence of raw1394, or it means that they added a > > > new > > > <linux/firewire-cdev.h> backend but are still keeping a libraw1394 > based > > > backend as an alternative or for parts of their functionality. > > > > > > Or it means that they noticed that libraw1394 does not behave 100% the > > > same when running on top of firewire-core versus raw1394, and added > some > > > workarounds in their own code (instead of submitting fixes to upstream > > > libraw1394 or kernel, or at least reporting such issues). > > > > > > I guess one could find out more about it by running it all in a > debugger > > > or by inserting some simple debug logging into libraw1394. But I don't > > > think at this point that it would get us nearer to a fix for the Ricoh > > > problem (or what I believe to be a Ricoh problem). > > > > > > > Not really sure if > > > > this is correct. I just downloaded and compiled libraw1394 2.1.0, > and > > > > made > > > > sure that the drivers were finding the new versions that I installed > > > > (using > > > > ldd and ldconfig). I still get the same error message. > > > > > > OK. Either the libraw1394 2.0.7 change which I alluded to simply does > not > > > have a positive effect here ---- which is not surprising since that > change > > > was implemented to address a different problem than yours ---, or the > > > drivers bypass libraw1394 when running on top of firewire-core, or > both. > > > > > > > > http://www.sensable.com/support-download-pdd.htm looks like the > > > > > Phantom > > > > > Omni drivers are not free, not open source, and not even made > > > > > available > > > > > to anybody but customers of theirs. In which case it would be > hard to > > > > > find out what kinds of I/O these drivers need and which userspace/ > > > > > kernelspace code paths they go through, obviously. > > > > > > > > You are absolutely correct. I have to provide them with my device > > > > serial > > > > number, just to access the driver download, and even then, I only get > > > > binaries and libraries, not source code. I guess it's not quite > > > > "OpenHaptics"... > > > > > > Well, at least they do provide something for Linux users among their > > > customers, although in a not particularly pragmatic form. > > That is absolutely right, the Linux support is definitely appreciated! > > > > As a final update, I just did some testing with our lab's server > > machine. The machine has the same version for the kernel, the > > drivers, the shared libraries the drivers depend on, and the > > application I have been using to test (i.e. quite similar software > > builds). The firewire controller on that machine is > > > > 06:0c.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB22A > > IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx] [104c:8023] > > > > Every test application that sensable/ OpenHaptics provides worked > > without any errors. > > > > > -- > > > Stefan Richter > > > -=====-===-- =--- ---== > > > http://arcgraph.de/sr/ > |
From: Clemens L. <cl...@la...> - 2012-08-08 16:50:31
|
Nizamov Shawkat wrote: > i5-760 @ 2.80GHz. <http://download.intel.com/design/processor/datashts/322164.pdf> mentions in section 2.1.6 a "fast exit" memory controller power-down mode, which is to be used when there are two DIMMs per channel. Section 4.3 mentions an "active power down" mode, but I haven't found any register to configure this in <http://download.intel.com/design/processor/datashts/322165.pdf>. Regards, Clemens |
From: Nizamov S. <niz...@gm...> - 2012-08-08 15:40:21
|
2012/8/8 Clemens Ladisch <cl...@la...>: > Nizamov Shawkat wrote: >> On old PC this CCD camera was connected using VT6307 card. I used this >> setup for more than the year and it showed no corruptions at all [...] >> However, after connecting the same camera using the same VT6307 card >> to the quad-core p5@2.8GHz > > The P5 was sold in 1993. Do you mean the i5-2300? Sorry, i5-760 @ 2.80GHz. Gigabyte GA-P55A-UD3 motherboard. > >> 8 Gb RAM (Linux), I noticed that there are corruptions in the acquired >> frames. [...] >> With the same VT6307 card and CCD camera on my newer Linux workstation, >> I noticed that about 1 byte in 15000 bytes would be lost (actually in >> my case that means that approximately 1 line of pixels would be zeroed >> out in every 5-10 frames). > > Please note that modern Intel chipsets do not have PCI support, so many > mainboards include some PCIe/PCI bridge chip -- and almost all vendors > try to save a few cents by using cheap crap. > > Which bridge do you have (lspci)? > It's all Intel : 00:00.0 Host bridge: Intel Corporation Core Processor DMI (rev 11) 00:03.0 PCI bridge: Intel Corporation Core Processor PCI Express Root Port 1 (rev 11) 00:08.0 System peripheral: Intel Corporation Core Processor System Management Registers (rev 11) 00:08.1 System peripheral: Intel Corporation Core Processor Semaphore and Scratchpad Registers (rev 11) 00:08.2 System peripheral: Intel Corporation Core Processor System Control and Status Registers (rev 11) 00:08.3 System peripheral: Intel Corporation Core Processor Miscellaneous Registers (rev 11) 00:10.0 System peripheral: Intel Corporation Core Processor QPI Link (rev 11) 00:10.1 System peripheral: Intel Corporation Core Processor QPI Routing and Protocol Registers (rev 11) 00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 06) 00:1a.1 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 06) 00:1a.2 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 06) 00:1a.7 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06) 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06) 00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 (rev 06) 00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 5 (rev 06) 00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 06) 00:1d.1 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 06) 00:1d.2 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 06) 00:1d.3 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 06) 00:1d.7 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) 00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 06) 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 06) 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06) 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar PRO [Radeon HD 5450] 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI Audio [Radeon HD 5400/6300 Series] 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) 04:00.0 Signal processing controller: National Instruments PXIe-4353 05:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) 3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-Core Registers (rev 04) 3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 04) 3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 04) 3f:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 04) 3f:03.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller (rev 04) 3f:03.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Target Address Decoder (rev 04) 3f:03.4 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Test Registers (rev 04) 3f:04.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Control Registers (rev 04) 3f:04.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Address Registers (rev 04) 3f:04.2 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Rank Registers (rev 04) 3f:04.3 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Thermal Control Registers (rev 04) 3f:05.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Control Registers (rev 04) 3f:05.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Address Registers (rev 04) 3f:05.2 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Rank Registers (rev 04) 3f:05.3 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Thermal Control Registers (rev 04) >> I guess that this is very small error rate > > The expected error rate for a correctly designed and configured system > is expected to be essentially zero. > I mean that in general such errors are not noticed by the user. Not that it is acceptable by design. I did not noticed it too in coriander when checking it as a generic video camera. But on absolutely static and generally homogenous image with illumination conditions changing each frame, inter-frame buffer corruptions were revealed immediately. >> I changed PCI ports, made sure that there is no other PCI devices on >> the bus, adjusted all possible PCI bus and device settings including >> exotic ones (memory/address stepping), played with giving real-time >> priority to my test program, higher interrupt priority to the firewire >> module, tried to force VT6307 to run in OHCI1.1 mode, recompile dc1394 >> libraries, coriander etc. I tried a fresh Linux kernel 3.5. I got the >> smaller rate of corruptions but never could get rid of them >> completely. > > In theory, none of these should be able to affect your C-state problem. > Were there methods that actually did have a significant effect? > There were no significant or obviously notable changes. Slight changes that I observed most probably should be attributed to the background processes, which wake up CPU cores more or less frequently. I have a bunch of desktop and development applications open, however top and iotop did not show any heavyweight processes during acquisition. >> I could not find the LSI chips with 4kb buffer therefore I >> bought FW card with 2 Kb buffer, but with much more robust TI chip >> (43AB23). > > PCI or PCIe? If the latter, which bridge? > It is PCI. 05:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI]) Flags: bus master, medium devsel, latency 32, IRQ 18 Memory at fbbff000 (32-bit, non-prefetchable) [size=2K] Memory at fbbf8000 (32-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: firewire_ohci Kernel modules: firewire-ohci As far as I understand, it is connected via this bridge and it is the only PCI device connected to this bridge: 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=32 >> I found an application note which blamed that newer Intel CPU's >> introduced so known C-states for power consumption reduction. They >> claimed that even if a single core of CPU gets into such state, not >> only its frequency, but the bandwidth of buses will be reduced too! > > All modern CPUs include the memory controller, so they have to be woken > up for the controller to be able to write data to memory. The deeper > the sleep state, the longer it takes to wake up. (In theory, it should > be possible to configure the MC to prevent it from sleeping, but I doubt > that there is any BIOS option for this.) > > It explains a lot, thank you. With best regards, S.Nizamov |
From: Damien D. <dd...@do...> - 2012-08-08 14:58:05
|
Shawkat, On Wed, 2012-08-08 at 14:46 +0200, Nizamov Shawkat wrote: [snip] > Looking through the vendors site I found an application note > which blamed that newer Intel CPU's introduced so known C-states for > power consumption reduction. They claimed that even if a single core > of CPU gets into such state, not only its frequency, but the bandwidth > of buses will be reduced too! Being a little bit skeptic, I > nevertheless disabled these C-states. It turns out that disabling them > in BIOS is not enough, linux kernel loads module intel_idle which > re-enables these C-states. The solution is loading the kernel with > "intel_idle.max_cstate=0" option. Check in dmesg for the "intel_idle: > disabled" line to see if it worked. > > And it really solved both my problems - both USB2 and FW400 cameras > work on my workstation with practically saturation level transfer > speeds (more than 30MB/s) and without any corruptions! > > Hopefully it will help someone to fix their problem with firewire corruptions. The corruption of 1394 data (or at least IIDC data) when entering C1E and possibly other sleep states is a known issue. For 5 or 6 years, the very first thing I do when I buy a computer is disable all the C-states in the BIOS! But I was not aware that Linux could re-enable them; this is probably a feature of newer kernels. I will definitely keep your kernel option in mind in the future... Thanks for sharing :) -- Damien 高原 Douxchamps http://damien.douxchamps.net/ |
From: Clemens L. <cl...@la...> - 2012-08-08 13:50:55
|
Nizamov Shawkat wrote: > On old PC this CCD camera was connected using VT6307 card. I used this > setup for more than the year and it showed no corruptions at all [...] > However, after connecting the same camera using the same VT6307 card > to the quad-core p5@2.8GHz The P5 was sold in 1993. Do you mean the i5-2300? > 8 Gb RAM (Linux), I noticed that there are corruptions in the acquired > frames. [...] > With the same VT6307 card and CCD camera on my newer Linux workstation, > I noticed that about 1 byte in 15000 bytes would be lost (actually in > my case that means that approximately 1 line of pixels would be zeroed > out in every 5-10 frames). Please note that modern Intel chipsets do not have PCI support, so many mainboards include some PCIe/PCI bridge chip -- and almost all vendors try to save a few cents by using cheap crap. Which bridge do you have (lspci)? PCI transfers data one 32-bit word at a time, while PCIe uses packets that can be much larger. How a PCI data burst is split into packets depends on the bridge implementation, especially on how much buffer space it has. PCIe cards with a PCI controller should use a suitable bridge; PCIe controllers do not have this problem. > I guess that this is very small error rate The expected error rate for a correctly designed and configured system is expected to be essentially zero. > I changed PCI ports, made sure that there is no other PCI devices on > the bus, adjusted all possible PCI bus and device settings including > exotic ones (memory/address stepping), played with giving real-time > priority to my test program, higher interrupt priority to the firewire > module, tried to force VT6307 to run in OHCI1.1 mode, recompile dc1394 > libraries, coriander etc. I tried a fresh Linux kernel 3.5. I got the > smaller rate of corruptions but never could get rid of them > completely. In theory, none of these should be able to affect your C-state problem. Were there methods that actually did have a significant effect? > I could not find the LSI chips with 4kb buffer therefore I > bought FW card with 2 Kb buffer, but with much more robust TI chip > (43AB23). PCI or PCIe? If the latter, which bridge? > I found an application note which blamed that newer Intel CPU's > introduced so known C-states for power consumption reduction. They > claimed that even if a single core of CPU gets into such state, not > only its frequency, but the bandwidth of buses will be reduced too! All modern CPUs include the memory controller, so they have to be woken up for the controller to be able to write data to memory. The deeper the sleep state, the longer it takes to wake up. (In theory, it should be possible to configure the MC to prevent it from sleeping, but I doubt that there is any BIOS option for this.) Regards, Clemens |
From: Nizamov S. <niz...@gm...> - 2012-08-08 12:46:45
|
Hello, recently I tried to connect my dc1394 compliant FW400 camera from my older laboratory PC (dual-core P4-3200 GHz/ 2Gb RAM), running 32-bit WinXP, to a newer much more powerful workstation running Linux (64-bit Ubuntu 12.04). On old PC this CCD camera was connected using VT6307 card. I used this setup for more than the year and it showed no corruptions at all, despite the stream was topping the FW-400 speed - 12(16)-bit grayscale 1 MP @ 16 fps, 4092 bit packet size. I save data stream for hours, later process and visualize them and pretty much sure that there were no corruptions. However, after connecting the same camera using the same VT6307 card to the quad-core p5@2.8GHz, 8 Gb RAM (Linux), I noticed that there are corruptions in the acquired frames. Corruptions are in form of lines, which are not overwritten by the newer frame data and contain the older buffer data (or zeros, if buffer was clean). The length of this line is nearly of the buffer size of VT6307 (circa 2 kbytes or 1k pixels). I wrote a simple test program using dc1394 library, which would always clean out the buffer after acquiring the frame. Because my camera has an DAC offset it never outputs the pixel values less than circa 190. So it was easy to distinguish real pixel data (in the range of 190-4096) from corruptions. With the same VT6307 card and CCD camera on my newer Linux workstation, I noticed that about 1 byte in 15000 bytes would be lost (actually in my case that means that approximately 1 line of pixels would be zeroed out in every 5-10 frames). I guess that this is very small error rate and in most applications it is practically unnoticeable (e.g. in case of video, if one frame contains a very small random portion of older frame and these frames do not differ much). But in my use-case it is not acceptable and I tried to fix the issue. I tried VT6306 and VT6307 cards. I changed PCI ports, made sure that there is no other PCI devices on the bus, adjusted all possible PCI bus and device settings including exotic ones (memory/address stepping), played with giving real-time priority to my test program, higher interrupt priority to the firewire module, tried to force VT6307 to run in OHCI1.1 mode, recompile dc1394 libraries, coriander etc. I tried a fresh Linux kernel 3.5. I got the smaller rate of corruptions but never could get rid of them completely. I could not find the LSI chips with 4kb buffer therefore I bought FW card with 2 Kb buffer, but with much more robust TI chip (43AB23). Things get actually worse - if with VT6306/VT6307 I would get zeros instead of actual pixel data, now alongside such pixels there would be also a few pixels with values higher than 4096 - also corruptions, but of another kind. At the same time I was evaluating a newly bought USB2 camera (not dcam/iidc compatible, with proprietary library). It worked flawlessly on my older laboratory PC and with my notebook (the same 64-bit ubuntu 12.04 as my workstation). But it mysteriously failed with my workstation too! All the controls would work perfectly but I could get data stream out of it only at USB1 speeds - something like 1 frame per second. Looking through the vendors site I found an application note which blamed that newer Intel CPU's introduced so known C-states for power consumption reduction. They claimed that even if a single core of CPU gets into such state, not only its frequency, but the bandwidth of buses will be reduced too! Being a little bit skeptic, I nevertheless disabled these C-states. It turns out that disabling them in BIOS is not enough, linux kernel loads module intel_idle which re-enables these C-states. The solution is loading the kernel with "intel_idle.max_cstate=0" option. Check in dmesg for the "intel_idle: disabled" line to see if it worked. And it really solved both my problems - both USB2 and FW400 cameras work on my workstation with practically saturation level transfer speeds (more than 30MB/s) and without any corruptions! Hopefully it will help someone to fix their problem with firewire corruptions. With best regards, S.Nizamov |
From: Jarvis S. <sch...@gm...> - 2012-08-06 16:15:56
|
Just FYI, I gave the Phantom Omni forum a quick overview of the discussion that we have been having, and I just received a response. Here is a quote from one of their support team members: > Most of the firewire cards have some firmware logic in them to arbitrate the 1394 isochronous mode. The omni also operates in the isochronous mode. > If the firmware in the 1394 chip has some problem, then you are going to see it in someway of the other. Because, the isochronous mode is > completely initiated and managed by the 1394 controller. He then provided a link to some recommended cards that seem to work. I just ordered the cheapest recommended one, and I will report back with the results and the card info. On Thu, Aug 2, 2012 at 8:49 PM, Jarvis Schultz <sch...@gm...> wrote: > > On Thu, Aug 2, 2012 at 5:12 PM, Stefan Richter > <st...@s5...> wrote: > > > > On Aug 02 Jarvis Schultz wrote: > > > On Thu, Aug 2, 2012 at 1:54 AM, Stefan Richter > > > <st...@s5...> > > > wrote: > > > > Your kernel "3.2.0-27" is possibly based on 3.2.6 or later. What does > > > > "grep firewire /proc/interrupts" show? > > > > > > > Here is the output of that: > > > 19: 3043 0 0 0 0 0 > > > 0 21 IO-APIC-fasteoi firewire_ohci > > > > I.e. your kernel has got the "don't use MSI on Ricoh OHCI-1394" flag > > already in its built in table. > > > > [...] > > > > Vice versa, if the quirk is built in, it can be switched off > > > > by a different value to the module parameter: > > [...] > > > I tried both of these "quirk" levels, and there is no change to the > > > behavior. > > > > Interesting; this means we could narrow the built-in quirk down to the > > chip version which was originally reported as broken with MSI, and let > > chip versions like yours use MSI again. But this doesn't help you one > > bit, alas. > > > > [...] > > > >> System Details: > > > >> Kernel version - 3.2.0-27 > > [...] > > > grep command: > > > # CONFIG_PREEMPT_RCU is not set > > > CONFIG_PREEMPT_NOTIFIERS=y > > > # CONFIG_PREEMPT_NONE is not set > > > CONFIG_PREEMPT_VOLUNTARY=y > > > # CONFIG_PREEMPT is not set > > > > Have a look whether your distribution also offers a kernel package which > > is called "lowlatency" or "desktop" or something along these lines --- and > > in effect has got CONFIG_PREEMPT=y and "# CONFIG_PREEMPT_VOLUNTARY is not > > set". The CONFIG_PREEMPT option is found under "Processor type and > > features -> Preemption Model -> Preemptible Kernel (Low-Latency Desktop)" > > in the kernel configuration menu when kernel sources are configured as > > preparation of a kernel build from source. > > > > CONFIG_PREEMPT means that kernel threads are put to sleep by the CPU > > scheduler when it used up its time slice and another process is waiting to > > get CPU time, very much the same way as the CPU scheduler treats userspace > > processes when they used up their time slice. > > > > I am suggesting to try such a kernel because there is a slight chance that > > reduced scheduling latency helps the Phantom Omni drivers to queue > > FireWire packets more steadily, which in turn might reduce the likelihood > > that Ricoh controller stops its DMA unrecoverably. > > > I just ran installed the most up-to-date lowlatency kernel that Ubuntu > 12.04 has which was built around 3.2.0-23. To address the next > comment, I booted into a console-only-mode, and made sure the fglrx > drivers weren't loaded. I saw the same behavior as before. Also, I > tried both kernels with the open source radeon drivers in a full > desktop session, and repeatedly received the same errors. > > > I attached my /proc/interrupts file as interrupts_log.txt > > > > Looks inconspicuous to me. Just one thing: Have you tried the mainline > > "radeon" driver instead of the closed source fglrx driver already? 3rd > > party kernel drivers tend to be latency sources due to lack of independent > > review and tie-in into mainline development. > > > > [...] > > > > Could you send the chip IDs as "lspci -nn | grep 1394" shows them? > > > > > > > Here it is: > > > 09:00.3 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 PCIe IEEE 1394 > > > Controller [1180:e832] (rev 01) > > > > Thanks for this. Same PCI ID as in the report which led to kernel commit > > 320cfa6ce0b3, but rev 01 instead of rev 00. > > > > > >> Phantom Omni PDD drivers version = Linux JUJU PDD pre-beta > > > >> > > > >> libraw1394 version - 2.0.5 > > > > > > > > Are the Phantom Omni drivers kernel drivers or userspace drivers? If > > > > the > > > > latter, are they using libraw1394? You could for example check with > > > > "ldd /path/to/the/driver/binary.xy" which lists all libraries to which > > > > 'binary.xy' is dynamically linked to. Libraries which are statically > > > > linked into a binary ( = incorporated into the binary) won't show up > > > > this > > > > way though. > > > > > > > The drivers are userspace drivers, and they are distributed as just a > > > sequence of shared libraries. The old drivers that they released > > > depended > > > on the raw1394 kernel module. These new "pre-beta JUJU" drivers do not. > > > I > > > originally tried to get this working with their old drivers, and > > > followed > > > the instructions at this site: > > > https://wiki.sofa-framework.org/tdev/wiki/HowTo/SensableWithoutRaw1394 > > > to > > > create a "dummy" kernel module. > > > > Argh. :-) Nitpick: "ln /dev/null /dev/raw1394" probably would have worked > > just as well as "ln /dev/fw0 /dev/raw1394". /dev/fw* does not support > > any of the ioctl/write/read operations that are valid on /dev/raw1394. > > Anyway, the former necessity of this dummy module and dummy file is a fine > > showcase of the joys and wonders of non-free software. > > > > > I am not positive I was getting the same > > > error messages, but I was getting the same "freezing" behavior. > > > > > > > The term "JUJU" implies that the drivers are not using libraw1394. > > > > But if > > > > they do, you should try to update to libraw1394 2.0.7 or later because > > > > it > > > > has got changes which affect isochronous streaming. Current and > > > > stable is > > > > 2.1.0. Of course an update of the system-wide installed libraw1394 > > > > would > > > > only have effect if the Phantom Omni drivers are dynamically linked to > > > > it. > > > > > > > I am a little confused by their terminology. Their binaries are > > > absolutely > > > linked to libraw1394 libraries. I believe they are using the term JUJU > > > because they no longer use the kernel module raw1394. > > > > They never directly used the kernel module, they used libraw1394. > > (Which is good because the developers of raw1394 intended the raw1394 > > kernel interface to be private to the raw1394<-->libraw1394 pair. This > > in turn facilitated the transition to the binary incompatible > > <linux/firewire-cdev.h> kernel interface provided by firewire-core > > while retaining compatibility with libraw1394 based application > > software. libraw1394 v2 transparently uses raw1394's or firewire-core's > > mutually incompatible interfaces depending on what libraw1394 detects to > > be > > available at runtime.) > > > > So this "JUJU" designation either refers to the accomplishment of removing > > that silly check for presence of raw1394, or it means that they added a > > new > > <linux/firewire-cdev.h> backend but are still keeping a libraw1394 based > > backend as an alternative or for parts of their functionality. > > > > Or it means that they noticed that libraw1394 does not behave 100% the > > same when running on top of firewire-core versus raw1394, and added some > > workarounds in their own code (instead of submitting fixes to upstream > > libraw1394 or kernel, or at least reporting such issues). > > > > I guess one could find out more about it by running it all in a debugger > > or by inserting some simple debug logging into libraw1394. But I don't > > think at this point that it would get us nearer to a fix for the Ricoh > > problem (or what I believe to be a Ricoh problem). > > > > > Not really sure if > > > this is correct. I just downloaded and compiled libraw1394 2.1.0, and > > > made > > > sure that the drivers were finding the new versions that I installed > > > (using > > > ldd and ldconfig). I still get the same error message. > > > > OK. Either the libraw1394 2.0.7 change which I alluded to simply does not > > have a positive effect here ---- which is not surprising since that change > > was implemented to address a different problem than yours ---, or the > > drivers bypass libraw1394 when running on top of firewire-core, or both. > > > > > > http://www.sensable.com/support-download-pdd.htm looks like the > > > > Phantom > > > > Omni drivers are not free, not open source, and not even made > > > > available > > > > to anybody but customers of theirs. In which case it would be hard to > > > > find out what kinds of I/O these drivers need and which userspace/ > > > > kernelspace code paths they go through, obviously. > > > > > > You are absolutely correct. I have to provide them with my device > > > serial > > > number, just to access the driver download, and even then, I only get > > > binaries and libraries, not source code. I guess it's not quite > > > "OpenHaptics"... > > > > Well, at least they do provide something for Linux users among their > > customers, although in a not particularly pragmatic form. > That is absolutely right, the Linux support is definitely appreciated! > > As a final update, I just did some testing with our lab's server > machine. The machine has the same version for the kernel, the > drivers, the shared libraries the drivers depend on, and the > application I have been using to test (i.e. quite similar software > builds). The firewire controller on that machine is > > 06:0c.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB22A > IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx] [104c:8023] > > Every test application that sensable/ OpenHaptics provides worked > without any errors. > > > -- > > Stefan Richter > > -=====-===-- =--- ---== > > http://arcgraph.de/sr/ |
From: Jarvis S. <sch...@gm...> - 2012-08-03 01:49:28
|
On Thu, Aug 2, 2012 at 5:12 PM, Stefan Richter <st...@s5...> wrote: > > On Aug 02 Jarvis Schultz wrote: > > On Thu, Aug 2, 2012 at 1:54 AM, Stefan Richter > > <st...@s5...> > > wrote: > > > Your kernel "3.2.0-27" is possibly based on 3.2.6 or later. What does > > > "grep firewire /proc/interrupts" show? > > > > > Here is the output of that: > > 19: 3043 0 0 0 0 0 > > 0 21 IO-APIC-fasteoi firewire_ohci > > I.e. your kernel has got the "don't use MSI on Ricoh OHCI-1394" flag > already in its built in table. > > [...] > > > Vice versa, if the quirk is built in, it can be switched off > > > by a different value to the module parameter: > [...] > > I tried both of these "quirk" levels, and there is no change to the > > behavior. > > Interesting; this means we could narrow the built-in quirk down to the > chip version which was originally reported as broken with MSI, and let > chip versions like yours use MSI again. But this doesn't help you one > bit, alas. > > [...] > > >> System Details: > > >> Kernel version - 3.2.0-27 > [...] > > grep command: > > # CONFIG_PREEMPT_RCU is not set > > CONFIG_PREEMPT_NOTIFIERS=y > > # CONFIG_PREEMPT_NONE is not set > > CONFIG_PREEMPT_VOLUNTARY=y > > # CONFIG_PREEMPT is not set > > Have a look whether your distribution also offers a kernel package which > is called "lowlatency" or "desktop" or something along these lines --- and > in effect has got CONFIG_PREEMPT=y and "# CONFIG_PREEMPT_VOLUNTARY is not > set". The CONFIG_PREEMPT option is found under "Processor type and > features -> Preemption Model -> Preemptible Kernel (Low-Latency Desktop)" > in the kernel configuration menu when kernel sources are configured as > preparation of a kernel build from source. > > CONFIG_PREEMPT means that kernel threads are put to sleep by the CPU > scheduler when it used up its time slice and another process is waiting to > get CPU time, very much the same way as the CPU scheduler treats userspace > processes when they used up their time slice. > > I am suggesting to try such a kernel because there is a slight chance that > reduced scheduling latency helps the Phantom Omni drivers to queue > FireWire packets more steadily, which in turn might reduce the likelihood > that Ricoh controller stops its DMA unrecoverably. > I just ran installed the most up-to-date lowlatency kernel that Ubuntu 12.04 has which was built around 3.2.0-23. To address the next comment, I booted into a console-only-mode, and made sure the fglrx drivers weren't loaded. I saw the same behavior as before. Also, I tried both kernels with the open source radeon drivers in a full desktop session, and repeatedly received the same errors. > > I attached my /proc/interrupts file as interrupts_log.txt > > Looks inconspicuous to me. Just one thing: Have you tried the mainline > "radeon" driver instead of the closed source fglrx driver already? 3rd > party kernel drivers tend to be latency sources due to lack of independent > review and tie-in into mainline development. > > [...] > > > Could you send the chip IDs as "lspci -nn | grep 1394" shows them? > > > > > Here it is: > > 09:00.3 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 PCIe IEEE 1394 > > Controller [1180:e832] (rev 01) > > Thanks for this. Same PCI ID as in the report which led to kernel commit > 320cfa6ce0b3, but rev 01 instead of rev 00. > > > >> Phantom Omni PDD drivers version = Linux JUJU PDD pre-beta > > >> > > >> libraw1394 version - 2.0.5 > > > > > > Are the Phantom Omni drivers kernel drivers or userspace drivers? If > > > the > > > latter, are they using libraw1394? You could for example check with > > > "ldd /path/to/the/driver/binary.xy" which lists all libraries to which > > > 'binary.xy' is dynamically linked to. Libraries which are statically > > > linked into a binary ( = incorporated into the binary) won't show up > > > this > > > way though. > > > > > The drivers are userspace drivers, and they are distributed as just a > > sequence of shared libraries. The old drivers that they released > > depended > > on the raw1394 kernel module. These new "pre-beta JUJU" drivers do not. > > I > > originally tried to get this working with their old drivers, and > > followed > > the instructions at this site: > > https://wiki.sofa-framework.org/tdev/wiki/HowTo/SensableWithoutRaw1394 > > to > > create a "dummy" kernel module. > > Argh. :-) Nitpick: "ln /dev/null /dev/raw1394" probably would have worked > just as well as "ln /dev/fw0 /dev/raw1394". /dev/fw* does not support > any of the ioctl/write/read operations that are valid on /dev/raw1394. > Anyway, the former necessity of this dummy module and dummy file is a fine > showcase of the joys and wonders of non-free software. > > > I am not positive I was getting the same > > error messages, but I was getting the same "freezing" behavior. > > > > > The term "JUJU" implies that the drivers are not using libraw1394. > > > But if > > > they do, you should try to update to libraw1394 2.0.7 or later because > > > it > > > has got changes which affect isochronous streaming. Current and > > > stable is > > > 2.1.0. Of course an update of the system-wide installed libraw1394 > > > would > > > only have effect if the Phantom Omni drivers are dynamically linked to > > > it. > > > > > I am a little confused by their terminology. Their binaries are > > absolutely > > linked to libraw1394 libraries. I believe they are using the term JUJU > > because they no longer use the kernel module raw1394. > > They never directly used the kernel module, they used libraw1394. > (Which is good because the developers of raw1394 intended the raw1394 > kernel interface to be private to the raw1394<-->libraw1394 pair. This > in turn facilitated the transition to the binary incompatible > <linux/firewire-cdev.h> kernel interface provided by firewire-core > while retaining compatibility with libraw1394 based application > software. libraw1394 v2 transparently uses raw1394's or firewire-core's > mutually incompatible interfaces depending on what libraw1394 detects to > be > available at runtime.) > > So this "JUJU" designation either refers to the accomplishment of removing > that silly check for presence of raw1394, or it means that they added a > new > <linux/firewire-cdev.h> backend but are still keeping a libraw1394 based > backend as an alternative or for parts of their functionality. > > Or it means that they noticed that libraw1394 does not behave 100% the > same when running on top of firewire-core versus raw1394, and added some > workarounds in their own code (instead of submitting fixes to upstream > libraw1394 or kernel, or at least reporting such issues). > > I guess one could find out more about it by running it all in a debugger > or by inserting some simple debug logging into libraw1394. But I don't > think at this point that it would get us nearer to a fix for the Ricoh > problem (or what I believe to be a Ricoh problem). > > > Not really sure if > > this is correct. I just downloaded and compiled libraw1394 2.1.0, and > > made > > sure that the drivers were finding the new versions that I installed > > (using > > ldd and ldconfig). I still get the same error message. > > OK. Either the libraw1394 2.0.7 change which I alluded to simply does not > have a positive effect here ---- which is not surprising since that change > was implemented to address a different problem than yours ---, or the > drivers bypass libraw1394 when running on top of firewire-core, or both. > > > > http://www.sensable.com/support-download-pdd.htm looks like the > > > Phantom > > > Omni drivers are not free, not open source, and not even made > > > available > > > to anybody but customers of theirs. In which case it would be hard to > > > find out what kinds of I/O these drivers need and which userspace/ > > > kernelspace code paths they go through, obviously. > > > > You are absolutely correct. I have to provide them with my device > > serial > > number, just to access the driver download, and even then, I only get > > binaries and libraries, not source code. I guess it's not quite > > "OpenHaptics"... > > Well, at least they do provide something for Linux users among their > customers, although in a not particularly pragmatic form. That is absolutely right, the Linux support is definitely appreciated! As a final update, I just did some testing with our lab's server machine. The machine has the same version for the kernel, the drivers, the shared libraries the drivers depend on, and the application I have been using to test (i.e. quite similar software builds). The firewire controller on that machine is 06:0c.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx] [104c:8023] Every test application that sensable/ OpenHaptics provides worked without any errors. > -- > Stefan Richter > -=====-===-- =--- ---== > http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-08-02 22:12:47
|
On Aug 02 Jarvis Schultz wrote: > On Thu, Aug 2, 2012 at 1:54 AM, Stefan Richter <st...@s5...> > wrote: > > Your kernel "3.2.0-27" is possibly based on 3.2.6 or later. What does > > "grep firewire /proc/interrupts" show? > > > Here is the output of that: > 19: 3043 0 0 0 0 0 > 0 21 IO-APIC-fasteoi firewire_ohci I.e. your kernel has got the "don't use MSI on Ricoh OHCI-1394" flag already in its built in table. [...] > > Vice versa, if the quirk is built in, it can be switched off > > by a different value to the module parameter: [...] > I tried both of these "quirk" levels, and there is no change to the > behavior. Interesting; this means we could narrow the built-in quirk down to the chip version which was originally reported as broken with MSI, and let chip versions like yours use MSI again. But this doesn't help you one bit, alas. [...] > >> System Details: > >> Kernel version - 3.2.0-27 [...] > grep command: > # CONFIG_PREEMPT_RCU is not set > CONFIG_PREEMPT_NOTIFIERS=y > # CONFIG_PREEMPT_NONE is not set > CONFIG_PREEMPT_VOLUNTARY=y > # CONFIG_PREEMPT is not set Have a look whether your distribution also offers a kernel package which is called "lowlatency" or "desktop" or something along these lines --- and in effect has got CONFIG_PREEMPT=y and "# CONFIG_PREEMPT_VOLUNTARY is not set". The CONFIG_PREEMPT option is found under "Processor type and features -> Preemption Model -> Preemptible Kernel (Low-Latency Desktop)" in the kernel configuration menu when kernel sources are configured as preparation of a kernel build from source. CONFIG_PREEMPT means that kernel threads are put to sleep by the CPU scheduler when it used up its time slice and another process is waiting to get CPU time, very much the same way as the CPU scheduler treats userspace processes when they used up their time slice. I am suggesting to try such a kernel because there is a slight chance that reduced scheduling latency helps the Phantom Omni drivers to queue FireWire packets more steadily, which in turn might reduce the likelihood that Ricoh controller stops its DMA unrecoverably. > I attached my /proc/interrupts file as interrupts_log.txt Looks inconspicuous to me. Just one thing: Have you tried the mainline "radeon" driver instead of the closed source fglrx driver already? 3rd party kernel drivers tend to be latency sources due to lack of independent review and tie-in into mainline development. [...] > > Could you send the chip IDs as "lspci -nn | grep 1394" shows them? > > > Here it is: > 09:00.3 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 PCIe IEEE 1394 > Controller [1180:e832] (rev 01) Thanks for this. Same PCI ID as in the report which led to kernel commit 320cfa6ce0b3, but rev 01 instead of rev 00. > >> Phantom Omni PDD drivers version = Linux JUJU PDD pre-beta > >> > >> libraw1394 version - 2.0.5 > > > > Are the Phantom Omni drivers kernel drivers or userspace drivers? If the > > latter, are they using libraw1394? You could for example check with > > "ldd /path/to/the/driver/binary.xy" which lists all libraries to which > > 'binary.xy' is dynamically linked to. Libraries which are statically > > linked into a binary ( = incorporated into the binary) won't show up this > > way though. > > > The drivers are userspace drivers, and they are distributed as just a > sequence of shared libraries. The old drivers that they released depended > on the raw1394 kernel module. These new "pre-beta JUJU" drivers do not. I > originally tried to get this working with their old drivers, and followed > the instructions at this site: > https://wiki.sofa-framework.org/tdev/wiki/HowTo/SensableWithoutRaw1394 to > create a "dummy" kernel module. Argh. :-) Nitpick: "ln /dev/null /dev/raw1394" probably would have worked just as well as "ln /dev/fw0 /dev/raw1394". /dev/fw* does not support any of the ioctl/write/read operations that are valid on /dev/raw1394. Anyway, the former necessity of this dummy module and dummy file is a fine showcase of the joys and wonders of non-free software. > I am not positive I was getting the same > error messages, but I was getting the same "freezing" behavior. > > > The term "JUJU" implies that the drivers are not using libraw1394. But if > > they do, you should try to update to libraw1394 2.0.7 or later because it > > has got changes which affect isochronous streaming. Current and stable is > > 2.1.0. Of course an update of the system-wide installed libraw1394 would > > only have effect if the Phantom Omni drivers are dynamically linked to it. > > > I am a little confused by their terminology. Their binaries are absolutely > linked to libraw1394 libraries. I believe they are using the term JUJU > because they no longer use the kernel module raw1394. They never directly used the kernel module, they used libraw1394. (Which is good because the developers of raw1394 intended the raw1394 kernel interface to be private to the raw1394<-->libraw1394 pair. This in turn facilitated the transition to the binary incompatible <linux/firewire-cdev.h> kernel interface provided by firewire-core while retaining compatibility with libraw1394 based application software. libraw1394 v2 transparently uses raw1394's or firewire-core's mutually incompatible interfaces depending on what libraw1394 detects to be available at runtime.) So this "JUJU" designation either refers to the accomplishment of removing that silly check for presence of raw1394, or it means that they added a new <linux/firewire-cdev.h> backend but are still keeping a libraw1394 based backend as an alternative or for parts of their functionality. Or it means that they noticed that libraw1394 does not behave 100% the same when running on top of firewire-core versus raw1394, and added some workarounds in their own code (instead of submitting fixes to upstream libraw1394 or kernel, or at least reporting such issues). I guess one could find out more about it by running it all in a debugger or by inserting some simple debug logging into libraw1394. But I don't think at this point that it would get us nearer to a fix for the Ricoh problem (or what I believe to be a Ricoh problem). > Not really sure if > this is correct. I just downloaded and compiled libraw1394 2.1.0, and made > sure that the drivers were finding the new versions that I installed (using > ldd and ldconfig). I still get the same error message. OK. Either the libraw1394 2.0.7 change which I alluded to simply does not have a positive effect here ---- which is not surprising since that change was implemented to address a different problem than yours ---, or the drivers bypass libraw1394 when running on top of firewire-core, or both. > > http://www.sensable.com/support-download-pdd.htm looks like the Phantom > > Omni drivers are not free, not open source, and not even made available > > to anybody but customers of theirs. In which case it would be hard to > > find out what kinds of I/O these drivers need and which userspace/ > > kernelspace code paths they go through, obviously. > > You are absolutely correct. I have to provide them with my device serial > number, just to access the driver download, and even then, I only get > binaries and libraries, not source code. I guess it's not quite > "OpenHaptics"... Well, at least they do provide something for Linux users among their customers, although in a not particularly pragmatic form. -- Stefan Richter -=====-===-- =--- ---== http://arcgraph.de/sr/ |
From: Jarvis S. <sch...@gm...> - 2012-08-02 19:06:39
|
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 46 0 0 307778 0 0 0 0 IO-APIC-edge timer 1: 1 0 0 10 0 0 0 0 IO-APIC-edge i8042 8: 0 0 0 1 0 0 0 0 IO-APIC-edge rtc0 9: 28992 0 0 1079 0 0 0 0 IO-APIC-fasteoi acpi 10: 2245 0 0 341 10162 0 0 0 IO-APIC-edge ite-cir 12: 1 0 0 172 0 0 0 0 IO-APIC-edge i8042 16: 0 23 0 0 0 0 94 0 IO-APIC-fasteoi ehci_hcd:usb1, mmc0 19: 3049 0 0 0 0 0 0 21 IO-APIC-fasteoi 23: 29203 0 0 0 0 0 0 408 IO-APIC-fasteoi ehci_hcd:usb2 40: 314187 0 0 0 0 0 0 0 HPET_MSI-edge hpet2 41: 0 290033 0 0 0 0 0 0 HPET_MSI-edge hpet3 42: 0 0 292723 0 0 0 0 0 HPET_MSI-edge hpet4 43: 0 0 0 276075 0 0 0 0 HPET_MSI-edge hpet5 44: 0 0 0 0 156037 0 0 0 HPET_MSI-edge hpet6 45: 108515 0 0 0 0 0 0 0 PCI-MSI-edge ahci 46: 257229 0 0 0 0 0 0 0 PCI-MSI-edge iwlwifi 47: 209 276 0 0 0 0 0 0 PCI-MSI-edge snd_hda_intel 48: 0 0 319 0 0 0 0 0 PCI-MSI-edge snd_hda_intel 49: 0 0 3 0 0 0 0 0 PCI-MSI-edge eth0 50: 0 0 0 5 0 0 0 0 PCI-MSI-edge fglrx[0]@PCI:2:0:0 51: 0 0 0 4213 0 0 0 0 PCI-MSI-edge firewire_ohci NMI: 152 103 94 108 55 55 58 58 Non-maskable interrupts LOC: 262 263 237 211 185 175542 185641 190251 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 152 103 94 108 55 55 58 58 Performance monitoring interrupts IWI: 0 0 0 0 0 0 0 0 IRQ work interrupts RES: 347731 398976 341506 360340 126306 136364 136631 111185 Rescheduling interrupts CAL: 848 1252 1283 1300 1236 1270 914 1288 Function call interrupts TLB: 21666 17918 21093 14404 14252 9846 11215 11708 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 20 20 20 20 20 20 20 20 Machine check polls ERR: 0 MIS: 0 |
From: Stefan R. <st...@s5...> - 2012-08-02 06:54:29
|
On Jul 31 Jarvis Schultz wrote: > I'm trying to use the Phantom Omni haptic device, and the apps keep > freezing. The driver developers insist that the drivers work stably on all > of the linux distros that they have tested them on. Phantom Omni's developers possibly don't have a Ricoh PCIe controller, or do they? > Yet, both firewire > computers I have are producing the exact same results. I noticed that in > the change log for kernel version 3.3 there was mention of some bug fixes > for the Ricoh PCIe 1394 controllers. I'm wondering if it is possible that > I am experiencing some of these downstream fixed bugs? The Ricoh PCIe controller related change in kernel 3.3 simply consists of using classic interrupts instead of MSI (http://en.wikipedia.org/wiki/Message_Signaled_Interrupts). http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=320cfa6ce0b3dc794fedfa4bae54c0f65077234d This change was also put into kernel 3.2.6, released on 13 February 2012. http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=c1a1e15fd6fe7ed496d115ac9b87649e4d827d65 Your kernel "3.2.0-27" is possibly based on 3.2.6 or later. What does "grep firewire /proc/interrupts" show? The "disable MSI" quirk can also be switched on by means of a module parameter to firewire-ohci if you have a kernel without the built-in quirk table entry. As root user: # modprobe -r firewire-ohci # modprobe firewire-ohci quirks=17 Vice versa, if the quirk is built in, it can be switched off by a different value to the module parameter: # modprobe -r firewire-ohci # modprobe firewire-ohci quirks=1 (A note for other readers and for the mailinglist archive: This module parameter is not a stable API and does some fairly low-level changes. For this and other reasons this module parameter is not normally meant to be used by end users, and particularly not meant for permanent use.) > Occasionally when connecting the device I get a message that says > > firewire_ohci: isochronous cycle inconsistent This is quite common when the bus topology changes. I wonder if we should normally suppress this message. If the drivers are not yet active at the very moment when you connect the device, you can disregard this message. Or are they? > Every application that I run works for a few seconds, and then just > freezes. The message printed in dmesg every time an app freezes is > > firewire_ohci: DMA context IT0 has stopped, error code: evt_timeout This indicates that drivers use isochronous transmission DMA (among else), i.e. a stream of packets from the PC to the device at a steady rate of 8000 packets per second. This is probably the carrier for the force feedback functionality. The message is logged when an interrupt signaled to the CPU that one or more DMA stopped due to an unrecoverable error. If they do, then the drivers are quite likely to be affected by controller hardware bugs to a similar extent as the FFADO audio drivers. http://subversion.ffado.org/wiki/HostControllers gives you an expression how many controller types are actually very unreliable as soon as I/O gets a little bit different from the usual SBP-2 storage or DV capture applications. > System Details: > Kernel version - 3.2.0-27 What do you get from "grep PREEMPT /boot/config-$(uname -r)" and from "cat /proc/interrupts"? > Kernel drivers, adapter, card and OHCI chipset - > 09:00.3 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller (rev 01) (prog-if 10 [OHCI]) > Kernel driver in use: firewire_ohci > Kernel modules: firewire-ohci Could you send the chip IDs as "lspci -nn | grep 1394" shows them? > Phantom Omni PDD drivers version = Linux JUJU PDD pre-beta > > libraw1394 version - 2.0.5 Are the Phantom Omni drivers kernel drivers or userspace drivers? If the latter, are they using libraw1394? You could for example check with "ldd /path/to/the/driver/binary.xy" which lists all libraries to which 'binary.xy' is dynamically linked to. Libraries which are statically linked into a binary ( = incorporated into the binary) won't show up this way though. The term "JUJU" implies that the drivers are not using libraw1394. But if they do, you should try to update to libraw1394 2.0.7 or later because it has got changes which affect isochronous streaming. Current and stable is 2.1.0. Of course an update of the system-wide installed libraw1394 would only have effect if the Phantom Omni drivers are dynamically linked to it. http://www.sensable.com/support-download-pdd.htm looks like the Phantom Omni drivers are not free, not open source, and not even made available to anybody but customers of theirs. In which case it would be hard to find out what kinds of I/O these drivers need and which userspace/ kernelspace code paths they go through, obviously. -- Stefan Richter -=====-===-- =--- ---=- http://arcgraph.de/sr/ |
From: Jarvis S. <sch...@gm...> - 2012-08-01 04:41:19
|
00:00.0 Host bridge: Intel Corporation Core Processor DMI (rev 11) 00:03.0 PCI bridge: Intel Corporation Core Processor PCI Express Root Port 1 (rev 11) 00:08.0 System peripheral: Intel Corporation Core Processor System Management Registers (rev 11) 00:08.1 System peripheral: Intel Corporation Core Processor Semaphore and Scratchpad Registers (rev 11) 00:08.2 System peripheral: Intel Corporation Core Processor System Control and Status Registers (rev 11) 00:08.3 System peripheral: Intel Corporation Core Processor Miscellaneous Registers (rev 11) 00:10.0 System peripheral: Intel Corporation Core Processor QPI Link (rev 11) 00:10.1 System peripheral: Intel Corporation Core Processor QPI Routing and Protocol Registers (rev 11) 00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05) 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 05) 00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 (rev 05) 00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 (rev 05) 00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 5 (rev 05) 00:1c.5 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 6 (rev 05) 00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a5) 00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 05) 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 05) 02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730 XT [Mobility Radeon HD 4670] 02:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI RV710/730 HDMI Audio [Radeon HD 4000 series] 05:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300 09:00.0 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller (rev 01) 09:00.1 System peripheral: Ricoh Co Ltd Memory Stick Host Controller (rev 01) 09:00.2 System peripheral: Ricoh Co Ltd Device e852 (rev 01) 09:00.3 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller (rev 01) 0b:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5784M Gigabit Ethernet PCIe (rev 10) ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-Core Registers (rev 04) ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 04) ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 04) ff:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 04) ff:03.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller (rev 04) ff:03.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Target Address Decoder (rev 04) ff:03.4 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Test Registers (rev 04) ff:04.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Control Registers (rev 04) ff:04.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Address Registers (rev 04) ff:04.2 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Rank Registers (rev 04) ff:04.3 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Thermal Control Registers (rev 04) ff:05.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Control Registers (rev 04) ff:05.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Address Registers (rev 04) ff:05.2 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Rank Registers (rev 04) ff:05.3 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Thermal Control Registers (rev 04) |