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.
Created attachment 639766 [details] dmesg output while attaching the dock under 3.5.3-1
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.
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
Are you still seeing this with 3.7.9 or 3.8.2 in updates-testing?
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.
Thanks for letting us know.