Bug 14075

Summary: SIS 182 on P5SD1-FM2 = slow boot
Product: IO/Storage Reporter: TAXI (taxi)
Component: Serial ATAAssignee: Tejun Heo (tj)
Status: RESOLVED CODE_FIX    
Severity: normal CC: devzero, taxi, tj
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg
classify-debug.patch
dmesg (with patch)
lspci -nn
dmidecode
classify-debug-1.patch
dmesg
classify-debug-2.patch
dmesg
sis-slave_link.patch
Simple Screenshot (kernel panic)
dmesg (from kernel panic)
sis-slave_link-1.patch
dmesg

Description TAXI 2009-08-27 17:37:48 UTC
Created attachment 22887 [details]
dmesg

When I boot My Fujitsu-Siemens P5SD1-FM2 with an Silicon Integrated Systems [SiS] 182 SATA/RAID Controller the boot process hangs for about 2-3 minutes
Comment 1 TAXI 2009-08-27 17:44:20 UTC
these people have the same problem: http://ubuntuforums.org/archive/index.php/t-1144924.html
Comment 2 Roland Kletzing 2009-08-29 20:36:47 UTC
could you try disabling the not connected sata port in the bios to see if this makes a difference ?
Comment 3 TAXI 2009-08-30 12:11:33 UTC
I can't find such option in the BIOS
Comment 4 Tejun Heo 2009-08-31 06:58:07 UTC
Created attachment 22920 [details]
classify-debug.patch

Interesting... Can you please do the followings?

1. Apply the attached patch and report the boot log.
2. Attach the output of "lspci -nn" and "dmidecode".

Thanks.
Comment 5 TAXI 2009-08-31 11:16:30 UTC
Created attachment 22923 [details]
dmesg (with patch)
Comment 6 TAXI 2009-08-31 11:17:25 UTC
Created attachment 22924 [details]
lspci -nn
Comment 7 TAXI 2009-08-31 11:18:12 UTC
Created attachment 22925 [details]
dmidecode
Comment 8 Tejun Heo 2009-08-31 11:57:45 UTC
Created attachment 22927 [details]
classify-debug-1.patch

Hmmm.... classification is working okay.  Strange it's still failing.  Can you please try this patch and report the log?

Thanks.
Comment 9 TAXI 2009-08-31 12:36:22 UTC
Created attachment 22928 [details]
dmesg
Comment 10 Tejun Heo 2009-08-31 13:54:52 UTC
Created attachment 22929 [details]
classify-debug-2.patch

Hmmmm.... still.  Can you please this?

Thanks.
Comment 11 TAXI 2009-08-31 14:10:47 UTC
Created attachment 22930 [details]
dmesg
Comment 12 Tejun Heo 2009-08-31 14:39:59 UTC
Okay, I finally understood it.  The problem is that sata_sis is using regular SCR handling ops while setting ATA_FLAG_SLAVE_POSS for SiS 182/965 controller.  This tells libata core layer that the port can have a slave device.  As sata_sis doesn't implement proper slave link, if the master link is online, the link slave device is supposed to be on seems online too which makes libata core layer believe that the driver failed to classify the present device on the slave link and retry.  Heh... it's a bit convoluted.

Ah.. okay, it's using the now obsolete (and broken) trick of combining SCR values in scr callbacks instead of using the slave mechanism.  I'll see if I can fix this.  Please standby a bit.

Thanks.
Comment 13 Tejun Heo 2009-09-01 00:57:45 UTC
Created attachment 22939 [details]
sis-slave_link.patch

Can you please try the attached patch and report the boot log?

Thanks.
Comment 14 TAXI 2009-09-01 09:00:30 UTC
Created attachment 22949 [details]
Simple Screenshot (kernel panic)

I think it don't recognize any SATA drive with this patch?
Comment 15 Tejun Heo 2009-09-01 09:04:48 UTC
Yeap, that's entirely possible.  Can you please capture the failing log?  This can be done by...

1. Using a small root fs on a usb stick or a drive attached to a different controller.

2. Setting up a serial console (Documentation/serial-console.txt)

3. Setting up a netconsole (Documentation/networking/netconsole.txt)

Thanks.
Comment 16 TAXI 2009-09-01 13:31:49 UTC
Created attachment 22951 [details]
dmesg (from kernel panic)
Comment 17 Tejun Heo 2009-09-01 13:55:04 UTC
Created attachment 22953 [details]
sis-slave_link-1.patch

Can you please try this?

Thanks.
Comment 18 TAXI 2009-09-01 14:04:49 UTC
Created attachment 22954 [details]
dmesg

Great Work!
Thanks a lot!
Comment 19 Tejun Heo 2009-09-01 14:19:44 UTC
Patch posted upstream.  Resolving as FIXED.  Thanks.
Comment 20 Tejun Heo 2009-09-01 14:20:00 UTC
Resolving...