Bug 807871

Summary: Lockups with FC16 kernels 3.2 & 3.3 and 88se9485-based HBA
Product: [Fedora] Fedora Reporter: Scott Olson <scottolson275>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: gansalmon, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-13 15:37:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
System smolt profile none

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.