Bug 873935

Summary: Kernel Panic when using sil3132
Product: [Fedora] Fedora Reporter: Billy Croan <Billy>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 17CC: Billy, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-26 00:07:53 UTC Type: Bug
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
Digital photograph of the kernel panic
none
dmesg output while attaching the dock under 3.5.3-1 none

Description Billy Croan 2012-11-07 02:41:24 UTC
Created attachment 639765 [details]
Digital photograph of the kernel panic

Description of problem:
When attaching the StarTech SATDOCK4U3, or adding the third of four drive to it, I get a kernel panic, and my system becomes unresponsive.


Version-Release number of selected component (if applicable):
This happens in 3.6.5-1.fc17.x86_64, and 3.6.3-1.fc17.x86_64 in but not in 3.5.3-1.fc17.x86_64

Some regression must have happened between 3.5.3 and 3.6.3.


How reproducible:
100%


Steps to Reproduce:
1.  boot the current kernel, 3.6.5-1.fc17.x86_64
2.  plug in dock
3.  Take picture (attached)
 

Actual results:
Kernel Panic


Expected results:
Kernel Serenity


Additional info:
This happens on two different eSATA controllers:
00:1f.2 SATA controller [0106]: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller [8086:3b22] (rev 06)
01:00.0 SATA controller [0106]: ASMedia Technology Inc. Device [1b21:0612] (rev 01)
So I do not believe it has to do with the eSATA controllers

This happens with many different drives, some of which were blank.  So I do not believe this can have anything to do with filesystems or the drives themselves.

I believe this has to do with the sata port-expander in the StarTech SATDOCK4U3, called sil3132, but I am not 100% sure.

When I boot  and attach the dock, here is the dmesg output it creates.  ata6 is the onboard esata port.

Comment 1 Billy Croan 2012-11-07 02:42:39 UTC
Created attachment 639766 [details]
dmesg output while attaching the dock under 3.5.3-1

Comment 2 Billy Croan 2012-11-08 16:53:48 UTC
Correction.  The dock model is SATDOCK4U3E.  And after disassembling the dock, I can tell that the SATA port expander chip is JMicron JMB321.  JMB321 is a s-port sata "switch" evidently, and StarTech uses it to join four sata drives to one of two phys.  (Either the eSATA port, or the JMicron JMS539 sata2-to-usb3 chip onboard.)

This finding is contrary to the StarTech documentaiton of the SATDOCK4U3E which does not mention the expander chipset, and lists an ASMedia usb-to-sata chip and VIA usb hub chip.

I experience the error with two different sata controllers with on the new kernel, and it works fine on both controllers with the old kernel.

I am willing to try installing kernel versions in-between 3.5.3 and 3.6.3 to find out exactly when this regression was introduced, but I am unsure where to get these intermediary versions.

Comment 3 Josh Boyer 2013-01-07 22:01:31 UTC
Unfortunately, the kernel panic photo shows the machine was already dying at that point.  There was a panic that happened before the one you took a photo of.

If this is still happening, you might try adding "pause_on_oops=60" to the kernel parameters list so that the kernel panic code will pause before it scrolls something off the screen.

If you want to find intermediary versions between 3.5.3 and 3.6.3, you can find them in koji here:

http://koji.fedoraproject.org/koji/packageinfo?packageID=8

Comment 4 Josh Boyer 2013-03-12 18:53:45 UTC
Are you still seeing this with 3.7.9 or 3.8.2 in updates-testing?

Comment 5 Billy Croan 2013-03-25 23:59:59 UTC
I have since updated this machine to f18.  3.8.3-203.fc18.x86_64 does not experience this bug.  FIXED as of 3.8.3 apparently.

Comment 6 Josh Boyer 2013-03-26 00:07:53 UTC
Thanks for letting us know.