Most recent kernel where this bug did not occur: none known Distribution: Mandrake 10.1 Hardware Environment: i386 Software Environment: Linus' kernel, linux1394.org drivers Problem Description: System may lock up when SBP-2 disks are accessed without using physical DMA on the 1394 host adapter. Steps to reproduce: Compile sbp2 with CONFIG_IEEE1394_SBP2_PHYS_DMA=y, load ohci1394 with "modprobe ohci1394 phys_dma=0", mount and access SBP-2 disk. Does not necessarily happen with all combinations of disks and host adapters. This bug's severity is set to "normal" instead of "high" because the mentioned setting is rather uncommon.
Begin forwarded message: Date: Sat, 15 Apr 2006 15:05:13 -0700 From: bugme-daemon@bugzilla.kernel.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 6393] New: sbp2 + ohci1394 with phys_dma=0 may freeze system http://bugzilla.kernel.org/show_bug.cgi?id=6393 Summary: sbp2 + ohci1394 with phys_dma=0 may freeze system Kernel Version: probably all, including 2.6.16, .15, .14... Status: NEW Severity: normal Owner: stefan-r-bz@s5r6.in-berlin.de Submitter: stefan-r-bz@s5r6.in-berlin.de Most recent kernel where this bug did not occur: none known Distribution: Mandrake 10.1 Hardware Environment: i386 Software Environment: Linus' kernel, linux1394.org drivers Problem Description: System may lock up when SBP-2 disks are accessed without using physical DMA on the 1394 host adapter. Steps to reproduce: Compile sbp2 with CONFIG_IEEE1394_SBP2_PHYS_DMA=y, load ohci1394 with "modprobe ohci1394 phys_dma=0", mount and access SBP-2 disk. Does not necessarily happen with all combinations of disks and host adapters. This bug's severity is set to "normal" instead of "high" because the mentioned setting is rather uncommon. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
PS: - This is most certainly a bug in sbp2, not anywhere else. - Due to time constraints, I will not work on this bug until I solved bug 1872. A solution to bug 1872 has a potential to solve bug 6393 as well.
Created attachment 9972 [details] panic screenshot I tested this under Linux 2.6.19 again, IEEE 1394 drivers equivalent to 2.6.20-rc2: After a little bit I/O activity, there is a kernel panic in the sbp2_handle_physdma_read tasklet. "EIP is at _mmx_memcpy". This is whith an AMD Athlon.
Created attachment 9973 [details] panic screenshot Also happens with kernel compiled for plain x86 instead of K7. And it happens in the sbp2_handle_physdma_write tasklet too: BUG: unable to handle kernel paging request at virtual address 3c873000 ... EIP is at sbp2_handle_physdma_write ... As for comment #2: What's left to be done to solve bug 1872 will not solve bug6393. These last two tests were done with sbp2 switched to serialize_io=1 (the current default) which prevents bug 1872.
Since it's panic in tasklet context, it might be interesting to debug & fix this before an eventual end of life of the old ieee1394 stack.
Still happens in 2.6.21.1 as in comment #3 on K7 uniprocessor. I did not observe it during a short test with 2.6.22 on x86-64 Core 2 Duo.
*** Bug 9616 has been marked as a duplicate of this bug. ***
There are currently no resources to fix this in drivers/ieee1394/. drivers/firewire/ does not feature this problem.