http://blog.gmane.org/gmane.linux.kernel.firewire.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4511 <pre> Yes, they work fine. Ok. I run the latest BIOS available two weeks ago. I wanted to get k8-powernow, and hence updated the bios. But I really did not notice any change other than the 'nicer' bios configuration and boot screens. I also run the latest microcode in the cpu. :) I attach the dmesg, but it does not have the firewire camera connected now. 'dmesg | tail' when it hangs does not have any additional line. I attach the full dmesg (after a pm-suspend and awake), and the /proc/interrupts. Now gzipped. Regards, Lluís. CPU0 CPU1 CPU2 CPU3 0: 128 0 1 112 IO-APIC-edge timer 1: 2 0 0 2 IO-APIC-edge i8042 6: 0 0 0 3 IO-APIC-edge floppy 7: 1 0 0 0 IO-APIC-edge 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 3 0 0 4 IO-APIC-edge i8042 14: 0 0 0 0 IO-APIC-edge pata_atiixp 15: 0 0 0 0 IO-APIC-edge pata_atiixp 16: 599 5 437 741068 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, snd_hda_intel 17: 0 0 0 5 IO-APIC-fasteoi ehci_hcd:usb1 18: 332 1 61 59700 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, nvidia 19: 7 0 1 533 IO-APIC-fasteoi ehci_hcd:usb2, firewire_ohci 22: 162 4 178 128610 IO-APIC-fasteoi ahci 43: 1733 11 653 373981 PCI-MSI-edge eth0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 2229360 1786978 1736741 1790840 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES: 2432823 1392509 1317556 1164986 Rescheduling interrupts CAL: 1588 2380 1365 2377 Function call interrupts TLB: 30296 21113 22528 21463 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 115 114 114 114 Machine check polls ERR: 1 MIS: 0 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</pre> Lluís Batlle i Rossell 2012-05-09T21:28:24 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4510 <pre> Oh. Bad luck. This motherboard also hangs from time to time. Very annoying. Thank you for all your time! ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Lluís Batlle i Rossell 2012-05-11T17:48:41 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4509 <pre> All reads fail (I guess -x instead of -vvv will show all ff's). This means the chip doesn't react at all, as if it were unplugged. This looks like a plain hardware error. Regards, Clemens ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Clemens Ladisch 2012-05-11T17:47:12 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4508 <pre> Ah, ok. Yes, very different - lspci fails, after hang. # lspci -s 2:0 -vvv 02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: firewire_ohci Does it tell anything good? Thank you, Lluís. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Lluís Batlle i Rossell 2012-05-11T15:55:42 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4507 <pre> A "reply number rollover" happens when the device failed four times to send a PCIe packet. This is automatically handled by retraining the link and retrying again. This might be a consequence of the suspend. What I actually wanted to ask: Is there any difference in the lspci output before and during a hang? Regards, Clemens ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Clemens Ladisch 2012-05-11T14:13:03 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4506 <pre> Ah ok. I'm glad someone understands a bit how that works. It's not my case. I only know until the 8259, two cascaded at most. :) Here they are. Only 'RollOver' has a difference, watching on vimdiff. Not that I know what is it about. Just to avoid confusion, the firewire hangs either if it just rebooted or it came back from suspend. No difference. Thank you, Lluís. 02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8384 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast &gt;TAbort- &lt;TAbort- &lt;MAbort- &gt;SERR- &lt;PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at f7eff800 (64-bit, non-prefetchable) [size=2K] Region 2: I/O ports at c800 [size=256] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] MSI: Enable- Count=1/1 Maskable+ 64bit+ Address: 0000000000000000 Data: 0000 Masking: 00000000 Pending: 00000000 Capabilities: [98] Express (v1) Endpoint, MSI 00 DevCap:MaxPayload 128 bytes, PhantFunc 0, Latency L0s &lt;64ns, L1 &lt;1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta:CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend- LnkCap:Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 &lt;1us, L1 &lt;64us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta:Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [100 v1] Advanced Error Reporting UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt:DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta:RxErr- BadTLP- BadDLLP- Rollover+ Timeout+ NonFatalErr+ CEMsk:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap:First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [130 v1] Device Serial Number 00-1e-8c-ff-ff-c0-86-64 Kernel driver in use: firewire_ohci 02:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. Device 8384 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast &gt;TAbort- &lt;TAbort- &lt;MAbort- &gt;SERR- &lt;PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at f7eff800 (64-bit, non-prefetchable) [size=2K] Region 2: I/O ports at c800 [size=256] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] MSI: Enable- Count=1/1 Maskable+ 64bit+ Address: 0000000000000000 Data: 0000 Masking: 00000000 Pending: 00000000 Capabilities: [98] Express (v1) Endpoint, MSI 00 DevCap:MaxPayload 128 bytes, PhantFunc 0, Latency L0s &lt;64ns, L1 &lt;1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl:Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta:CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend- LnkCap:Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 &lt;1us, L1 &lt;64us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl:ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta:Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [100 v1] Advanced Error Reporting UESta:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk:DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt:DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta:RxErr- BadTLP- BadDLLP- Rollover- Timeout+ NonFatalErr+ CEMsk:RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap:First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [130 v1] Device Serial Number 00-1e-8c-ff-ff-c0-86-64 Kernel driver in use: firewire_ohci ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</pre> Lluís Batlle i Rossell 2012-05-10T20:32:13 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4505 <pre> Many thanks. As excpected, no changes from the VT6308. So the problem is not with IRQ 19 itself but with the routing of the PCI interrupt line from the controller to IRQ19. Please show the output of "lspci -s 2:0 -vvv" after a cold boot and after a suspend/resume. Regards, Clemens ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Clemens Ladisch 2012-05-10T13:50:15 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4504 <pre> Sorry. Now with camera: # lsfirewirephy bus 0, node 0: 080028:424296 Texas Instruments TSB41AB1/2 bus 0, node 1: 001163:306001 VIA Technologies VT630x Yes, the interrupt count increases, the usb works fine. Thank you a lot, Lluís. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Lluís Batlle i Rossell 2012-05-10T13:29:03 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4503 <pre> And what _is_ the output? :) These errors should not affect you, and it appears are normal with the BIOSes for certain CPU family. There's nothing else relevant in the log. Could you check whether this EHCI controller that shares the same interrupt works in this situation, i.e., if high-speed USB devices work on these ports? (Check whether there are USB ports where these interrupt counts increase when you plug something in.) Regards, Clemens ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Clemens Ladisch 2012-05-10T13:29:17 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4502 <pre> There were some additions in 2.6.36, but none of them affect your applications. (This should work directly after booting, before any hang.) All these symptoms indicate that the FireWire interrupt just isn't reported anymore. So this is probably not related with the VT6315 itself but with the system's interrupt routing. Sometimes, this is caused by ACPI problems; try updating the BIOS, if possible. What is the entire output of dmesg immediately after booting? What are the outputs of "cat /proc/interrupt" and "dmesg | tail" when it hangs? Regards, Clemens ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Clemens Ladisch 2012-05-09T06:21:29 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4501 <pre> PS, I forgot: A bus reset would flush such stuck requests out (hence Clemens' suggestion to test a bus reset...). But that only works if the controller's self-ID-complete DMA and interrupts still work. Alas, if the controller stopped issuing AT-req IRQs due to whatever fault, chances are limited that it would still issue self-ID-complete IRQs. </pre> Stefan Richter 2012-05-08T19:20:15 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4500 <pre> One potential cause for never timing out would be if the controller never gives us an AT-req IRQ ('asynchronous request transmitted' interrupt). That would be a chip bug against which our drivers are currently not protected. JMicron JMB38x is known to behave that way; I have particularly observed it with Coriander (IIDC capture application). However, I have not yet heard of VIA VT6315 behaving this way. (The old driver stack would time out even after missing AT-req IRQ, as would earlier versions of the newer driver stack --- at the risk of races with transaction completion though.) I'm not saying that this is what happens, just suggesting it as a possibility. After # echo 2 &gt; /sys/module/firewire_ohci/parameters/debug the driver will log all AT and AR events that do happen; alas it won't reveal a case when upper layers inserted a request but the controller did not raise AT-req. To detect that, we would have to modify the driver to log request insertion too. That's curious. Maybe these are two different chip revisions? lspci would possibly still show them with same revision number; a look at the actual chip may or may not tell more. Are these PCIe cards which you could swap between the two PCs? </pre> Stefan Richter 2012-05-08T18:28:48 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4499 <pre> On the older kernel stack, libdc1394 per default uses direct video1394 accesses for video capture but raw1394 accesses via libraw1394 for discovery, control and status I/O. (It also had a mode in which it used libraw1394 + raw1394 also for video capture, but support for that mode was removed in kernel 2.6.23 and libraw1394 2.0. I don't know if it was removed from the libdc1394 v2 codebase too; could be.) On the newer kernel stack, libdc1394 uses /dev/fw* for everything, without assistance by libraw1394. libdc1394 v2.1.2 (06/2009) is recommended as the minimum version to use together with the newer kernel stack; v2.2.0 (03/2012) is current. I don't know if the libdc1394 version could have an impact on the kind of behavior here, nor am I familiar with how well the VT6315 works for IIDC applications. I only have a VT6306 and two low-end IIDC cameras; it's been a while that I tested the VT6306 with these cameras. However, VT6306 is known to behave differently from (buggier than) VT6307/08/15. </pre> Stefan Richter 2012-05-08T18:13:36 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4498 <pre> Sorry, but before I told you the phenomII was running 3.3.4, but it is running 3.3.5. I updated the i7 machine to 3.3.5 too, and there it does not hang. Same chipset, same kernel, but in the phenomII it hangs (any of the two cameras we have, colour and mono), and in the i7 not. Annoying... Any idea from this confusion? :) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Lluís Batlle i Rossell 2012-05-08T16:37:03 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4497 <pre> Hm this was fast. I have the jujutils built: # lsfirewirephy timeout timeout Does this mean much? Regards, Lluís. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Lluís Batlle i Rossell 2012-05-08T16:31:36 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4496 <pre> I notice that, let's say, my /usr/include/linux is from 2.6.35, and I've all built with those headers. Is the public API of the kernel changed at 3.3.x, for firewire? Should I rebuild all the libdc/libraw code with newer headers? Or simply getting the newer firewire-cdev header files would be enough, building jujuutils with them? I'll try this later. Regards, Lluís. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Lluís Batlle i Rossell 2012-05-08T16:28:50 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4495 <pre> It does not help... Nothing changes, neither to fw1 or fw0. I only have 'lsfirewire': # lsfirewire -v device fw0: vendor ID: 0xd00d1e model ID: 0x000001 vendor: Linux Firewire model: Juju guid: 0x001e8c0001c08664 device fw1: vendor ID: 0x000a47 guid: 0x000a47010f0a468c units: 0x00a02d:0x000102 unit fw1.0: specifier ID: 0x00a02d version: 0x000102 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Lluís Batlle i Rossell 2012-05-08T15:34:41 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4494 <pre> Some command to the device did not get a response; the kernel is still waiting for one. In theory, there should be a two-second timeout; I don't know why is doesn't trigger. Please check whether a bus reset helps: download and install the jujuutils package from &lt;http://code.google.com/p/jujuutils/&gt;, and run: firewire-request /dev/fw1 reset (BTW: what is the output of lsfirewirephy?) Regards, Clemens ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Clemens Ladisch 2012-05-08T15:30:34 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4493 <pre> I'm using libraw1394 2.0.7. I can try 2.0.8. I will later. The program just blocked (in 3.3.4), and I attach strace: read(13, I look at the fd 13 in /proc: 13 -&gt; /dev/fw1 I use kill. SIGINT causes the read() call to restart: read(13, 0x7fff19de7760, 40) = ? ERESTARTSYS (To be restarted) --- {si_signo=SIGINT, si_code=SI_KERNEL, si_value={int=1174533440, ptr=0x7fbf4601f540}} (Interrupt) --- rt_sigaction(SIGINT, {0x7fe92d954390, [INT], SA_RESTORER|SA_RESTART, 0x7fe92b4e8b10}, {0x7fe92d954390, [INT], SA_RESTORER|SA_RESTART, 0x7fe92b4e8b10}, 8) = 0 rt_sigreturn(0) = 0 read(13, If now with strace attached I use kill -9, strace does not notice that. Ctrl-C to the strace, hangs: read(13, ^C &lt;unfinished ...&gt; cat /proc/5918/status: Name: cc1394 State: D (disk sleep) .... If I hadn't had strace attached, the process would appear defunct - as I tried other times. Unplugging the fw camera does not show any message in dmesg. Now issuing the sysreq w shows one task: [17613.274738] SysRq : Show Blocked State [17613.274749] task PC stack pid father [17613.274790] cc1394 D ffffffff81407520 0 5918 5880 0x00000005 [17613.274801] ffff880032101b68 0000000000000046 ffff880032101b08 ffff880000000000 [17613.274810] ffff8801285ea940 ffff880032101fd8 ffff880032101fd8 ffff880032101fd8 [17613.274819] ffff880129ace040 ffff8801285ea940 ffff880032101b78 ffff8800364a2c00 [17613.274828] Call Trace: [17613.274843] [&lt;ffffffff813c8baf&gt;] schedule+0x3f/0x60 [17613.274882] [&lt;ffffffffa0106fcd&gt;] fw_device_op_release+0x18d/0x250 [firewire_core] [17613.274894] [&lt;ffffffff8106b7c0&gt;] ? add_wait_queue+0x60/0x60 [17613.274904] [&lt;ffffffff8114c6ba&gt;] fput+0xea/0x220 [17613.274912] [&lt;ffffffff81149466&gt;] filp_close+0x66/0x90 [17613.274921] [&lt;ffffffff8104cc88&gt;] put_files_struct+0x88/0xf0 [17613.274930] [&lt;ffffffff8104cd9a&gt;] exit_files+0x4a/0x60 [17613.274938] [&lt;ffffffff8104d277&gt;] do_exit+0x197/0x870 [17613.274946] [&lt;ffffffff8104dcb4&gt;] do_group_exit+0x44/0xa0 [17613.274955] [&lt;ffffffff8105d7c5&gt;] get_signal_to_deliver+0x215/0x5e0 [17613.274964] [&lt;ffffffff810131b5&gt;] do_signal+0x65/0x710 [17613.274972] [&lt;ffffffff8104dfbb&gt;] ? sys_wait4+0xab/0xf0 [17613.274979] [&lt;ffffffff8106b7c0&gt;] ? add_wait_queue+0x60/0x60 [17613.274987] [&lt;ffffffff810138e5&gt;] do_notify_resume+0x65/0x80 [17613.274996] [&lt;ffffffff813ca7a2&gt;] int_signal+0x12/0x17 Does it tell enough to you? Any other test? Regards, Lluís. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Lluís Batlle i Rossell 2012-05-08T15:11:08 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4492 <pre> Try executing (as root) echo w &gt; /proc/sysrq-trigger when this happens; this should output a list of blocked tasks to the system log. The FireWire stack was completely rewritten. Check that your libraw1394 package is recent enough (current is 2.0.8, but 2.0.6 or newer should work). In any case, this library could not cause the kernel to lock up. Regards, Clemens ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Clemens Ladisch 2012-05-08T14:27:20 http://permalink.gmane.org/gmane.linux.kernel.firewire.user/4491 <pre> Another thing I could not find anywhere is that in the 2.6.35 computer, I get /dev/raw1394 and /dev/video1394-0. In the 3.3.x computer, I don't get any such device node, and I don't have any modules named raw1394 or video1394. Did those device nodes disappeared in recent kernels? Regards, Lluís. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Lluís Batlle i Rossell 2012-05-08T13:41:59 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.firewire.user