Bug 807871 - Lockups with FC16 kernels 3.2 & 3.3 and 88se9485-based HBA
Lockups with FC16 kernels 3.2 & 3.3 and 88se9485-based HBA
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-28 21:21 EDT by Scott Olson
Modified: 2012-11-13 10:37 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-13 10:37:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Scott Olson 2012-03-28 21:21:46 EDT
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 11:27:51 EDT
# 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 10:37:52 EST
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.