Bug 6393

Summary: sbp2 + ohci1394 with phys_dma=0 may freeze system
Product: Drivers Reporter: Stefan Richter (stefanr)
Component: IEEE1394Assignee: Stefan Richter (stefanr)
Status: REJECTED WILL_NOT_FIX    
Severity: normal CC: johannes, protasnb
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: all Subsystem:
Regression: --- Bisected commit-id:
Bug Depends on:    
Bug Blocks: 10046    
Attachments: panic screenshot
panic screenshot

Description Stefan Richter 2006-04-15 15:05:13 UTC 
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.
Comment 1 Andrew Morton 2006-04-15 15:10:06 UTC 

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.
Comment 2 Stefan Richter 2006-04-17 16:23:41 UTC 
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.
Comment 3 Stefan Richter 2006-12-31 11:21:14 UTC 
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.
Comment 4 Stefan Richter 2006-12-31 14:19:50 UTC 
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.
Comment 5 Stefan Richter 2007-07-05 11:56:45 UTC 
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.
Comment 6 Stefan Richter 2007-07-21 10:04:39 UTC 
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.
Comment 7 Stefan Richter 2007-12-21 16:29:08 UTC 
*** Bug 9616 has been marked as a duplicate of this bug. ***
Comment 8 Stefan Richter 2008-02-19 12:04:18 UTC 
There are currently no resources to fix this in drivers/ieee1394/.
drivers/firewire/ does not feature this problem.