Bug 10512

Summary: SATA controller in MacBook no longer detected with 2.6.25 kernel
Product: IO/Storage Reporter: Ryan Roth (ryan.roth)
Component: Serial ATAAssignee: Tejun Heo (htejun)
Severity: normal CC: bunk
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.25 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: dmesg dump from FC9 installer
lspci -nvv dump from FC9 installer
Corrected lspci
Patched kernel
Patched kernel with boot options
boot with static int check_sidpr = 1
dmesg of new patched kernel, worked perfect

Description Ryan Roth 2008-04-23 14:38:31 UTC
Latest working kernel version:  2.6.24
Earliest failing kernel version:  2.6.25
Distribution:  Fedora
Hardware Environment:  MacBook 4,1 Santa Rosa - This is the same controller as the previous revision of MacBooks.
Problem Description:  The 2.6.25 kernel no longer detects the SATA controller used by the MacBook.

Steps to reproduce:  Either compile 2.6.25 kernel from source or try booting a distro (such as Fedora 9) that uses the new kernel and the controller will not be detected nor function.
Comment 1 Tejun Heo 2008-04-23 15:16:16 UTC
Any chance you can provide the failing boot log?  Maybe by booting an installation media w/ 2.6.25 kernel, using a separate harddisk or netconsole?
Comment 2 Ryan Roth 2008-04-24 11:41:32 UTC
Created attachment 15896 [details]
dmesg dump from FC9 installer
Comment 3 Ryan Roth 2008-04-24 11:43:29 UTC
The dmesg dump is from 2.6.25-rc9 and is the same as the 2.6.25 release.  I just happened to use the FC9 preview CD with uses the rc9 not final release.
Comment 4 Tejun Heo 2008-04-24 14:28:18 UTC
Can you please attach the result of "lspci -nnv"?  Thanks.
Comment 5 Ryan Roth 2008-04-25 10:39:40 UTC
Created attachment 15915 [details]
lspci -nvv dump from FC9 installer
Comment 6 Ryan Roth 2008-04-25 14:32:36 UTC
Created attachment 15916 [details]
Corrected lspci

Sorry I ran  lspci -nnv the first time, here is a corrected dump of lspci -nvv
Comment 7 Ryan Roth 2008-04-25 14:39:36 UTC
Here are the sections of interest from lspci.  The first if the broken kernel and the latter is a working kernel.

Kernel 2.6.25:
00:1f.2 0101: 8086:2828 (rev 03) (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: 106b:00a1
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 18
	Region 0: I/O ports at 60f8 [size=8]
	Region 1: I/O ports at 611c [size=4]
	Region 2: I/O ports at 60f0 [size=8]
	Region 3: I/O ports at 6118 [size=4]
	Region 4: I/O ports at 6020 [size=16]
	Region 5: I/O ports at 4000 [size=16]
	Capabilities: [70] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ata_piix

Kernal 2.6.24:
00:1f.2 IDE interface [0101]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller [8086:2828] (rev 03) (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: Apple Computer Inc. Unknown device [106b:00a1]
	Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 18
	I/O ports at 60f8 [size=8]
	I/O ports at 611c [size=4]
	I/O ports at 60f0 [size=8]
	I/O ports at 6118 [size=4]
	I/O ports at 6020 [size=16]
	I/O ports at 4000 [size=16]
	Capabilities: <access denied>
	Kernel driver in use: ata_piix
	Kernel modules: pata_acpi, ata_piix, ata_generic
Comment 8 Tejun Heo 2008-04-27 02:33:06 UTC
Hmm... ICH8M.  Strange, SIDPRs don't seem to work.  The third nibble in SControl should be 3 at the very list.  Weird, the controller is meeting all criteria for SIDPR access in the ICH8 datasheet.  Maybe apple did something strange, which wouldn't be the first time.  I'll prep a patch to work around the problem.  Please standby.
Comment 9 Tejun Heo 2008-04-27 03:20:21 UTC
Created attachment 15932 [details]

Okay, here's the debug patch.  Can you please do the followings?

1. Boot with the patched kernel.  It should successfully detect the harddrive.  Please attach the resulting kernel boot log here.

2. Boot with the patched kernel with "ata_piix.check_sidpr=1" specified.  This should succeed to detect the drive but might fail.  Please report how it works and if it works please attach the resulting kernel log.

Comment 10 Ryan Roth 2008-04-27 12:37:14 UTC
The patch worked perfect with and without the "ata_piix.check_sidpr=1" 
As far as the kernel log what file dd you want posted?

Comment 11 Tejun Heo 2008-04-27 20:44:15 UTC
The result of dmesg right after boot w/ and w/o the parameter.
Comment 12 Ryan Roth 2008-04-28 17:05:42 UTC
Created attachment 15965 [details]
Patched kernel
Comment 13 Ryan Roth 2008-04-28 17:06:09 UTC
Created attachment 15966 [details]
Patched kernel with boot options
Comment 14 Tejun Heo 2008-04-28 19:06:43 UTC
Created attachment 15967 [details]

Hmm.. The ata_piix option is not getting through your initrd. :-( Can you please apply the modified patch and do the followings?

* Boot the patched kernel.  Detection will fail.  Please post the resulting kernel log.

* Change "static int check_sidpr;" to "static int check_sidpr = 1;" in drivers/ata/ata_piix.c, rebuild the kernel and post the resulting kernel log.

Comment 15 Ryan Roth 2008-04-29 08:21:51 UTC
Sure enough it failed, but how can I capture the kernel log if it never boots?
Comment 16 Chuck Ebbert 2008-04-29 09:10:55 UTC
What is the short-term fix here? Just disable SIDPR unconditionally for now?
Comment 17 Ryan Roth 2008-04-29 09:14:55 UTC
Is there a way to disable SIDPR on existing kernels with this issue?  Can we just tag "ata_piix.check_sidpr=1" on to the boot config?
Comment 18 Ryan Roth 2008-04-29 13:18:33 UTC
Created attachment 15979 [details]
boot with static int check_sidpr = 1
Comment 19 Ryan Roth 2008-04-29 14:19:14 UTC
What are the odds of getting this fixed even if it is a short term fix?  I would like to see a working kernel make it in before the April 1st deadline for Fedora 9.
Comment 20 Tejun Heo 2008-04-29 18:54:31 UTC
The behavior w/ .check_sidpr=1 is the proposed solution but I wanna make sure it's doing the right thing before sending it upstream.  I for some reason thought you had another harddrive connected to the system.  Is it possible for you to setup netconsole (Documentation/networking/netconsole.txt) and grab the failing boot log?  I'll push the fix upstream as soon as the log is verified.  If you want the fix to be included in fedora, you'll need to file a bug report w/ them tho.
Comment 21 Ryan Roth 2008-04-29 22:43:57 UTC
I cannot get netconsole to work for the life of me, I am out of ideas, you have any more?
Comment 22 Tejun Heo 2008-04-30 00:05:36 UTC
Eh... Let me cook up another debug patch.  Please standby a bit.
Comment 23 Tejun Heo 2008-04-30 01:53:50 UTC
Created attachment 15984 [details]

Please try the attached patch and post the resulting boot log.  Thanks.
Comment 24 Ryan Roth 2008-04-30 08:01:54 UTC
Created attachment 15988 [details]
dmesg of new patched kernel, worked perfect
Comment 25 Tejun Heo 2008-04-30 17:54:16 UTC
Alright, will forward upstream.  Closing as FIXED.
Comment 26 Ryan Roth 2008-04-30 17:55:35 UTC