Bug 807871 - Lockups with FC16 kernels 3.2 & 3.3 and 88se9485-based HBA
Summary: Lockups with FC16 kernels 3.2 & 3.3 and 88se9485-based HBA
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-29 01:21 UTC by Scott Olson
Modified: 2012-11-13 15:37 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-11-13 15:37:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
System smolt profile (3.56 KB, text/plain)
2012-03-29 01:21 UTC, Scott Olson
no flags Details

Description Scott Olson 2012-03-29 01:21:46 UTC
Created attachment 573496 [details]
System smolt profile

Description of problem:

I'm having a problem where my Supermicro AOC-SAS2LP-MV8 HBA is locking up while controlling a mdadm RAID-6 array with the 3.2 and 3.3 kernels that have come out for FC16.  Interestingly, if I stay with the old 3.1 kernel that was installed first for FC16, I don't get any lockups.  The AOC-SAS2LP-MV8 has a Marvell 88se9485 controller and uses the mvsas driver, the version that seems to work with it is 0.8.2, while the version that seems to cause it to lock up is 0.8.16 (as reported in both cases by modinfo).  I've seen the same behavior with both a RAID-6 and a RAID-10 array.


Version-Release number of selected component (if applicable):

Problem driver appears to be mvsas 0.8.16, mvsas 0.8.2 does not show the same problems.

How reproducible:

Happens with a Supermicro AOC-SAS2LP-MV8 HBA, controlling a RAID-6 or -10 array,  with mvsas 0.8.16 driver, receives or sends a large amount of data.  Data can come in at network (cable modem, for instance) speeds, or go out at USB2 speeds, and the hang can happen.  Hangs are not, per se, size related, sometimes they happen with a small amount of data written or read (less than 1 Gig), other times they do not happen until over 320 Gigs have been transferred.

Steps to Reproduce:

1.Start data transfer
2.When activity LED on the card begins to flicker at approximately 1 second intervals and other drive-based activity on that card stops, card is locked.

  
Actual results:

Card freezes, often with files not closed, causing inodes to be cleared after a hard reset.


Expected results:

Data is transferred without a card lockup.

Additional info:

Comment 1 Dave Jones 2012-10-23 15:27:51 UTC
# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).

Comment 2 Justin M. Forbes 2012-11-13 15:37:52 UTC
With no response, we are closing this bug under the assumption that it is no longer an issue. If you still experience this bug, please feel free to reopen the bug report.


Note You need to log in before you can comment on or make changes to this bug.