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.
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?
Created attachment 15896 [details] dmesg dump from FC9 installer
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.
Can you please attach the result of "lspci -nnv"? Thanks.
Created attachment 15915 [details] lspci -nvv dump from FC9 installer
Created attachment 15916 [details] Corrected lspci Sorry I ran lspci -nnv the first time, here is a corrected dump of lspci -nvv
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
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.
Created attachment 15932 [details] ata_piix-sidpr-debug.patch 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. Thanks.
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? Thanks
The result of dmesg right after boot w/ and w/o the parameter.
Created attachment 15965 [details] Patched kernel
Created attachment 15966 [details] Patched kernel with boot options
Created attachment 15967 [details] ata_piix-sidpr-debug-1.patch 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. Thanks.
Sure enough it failed, but how can I capture the kernel log if it never boots?
What is the short-term fix here? Just disable SIDPR unconditionally for now?
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?
Created attachment 15979 [details] boot with static int check_sidpr = 1
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.
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.
I cannot get netconsole to work for the life of me, I am out of ideas, you have any more?
Eh... Let me cook up another debug patch. Please standby a bit.
Created attachment 15984 [details] ata_piix-sidpr-debug-2.patch Please try the attached patch and post the resulting boot log. Thanks.
Created attachment 15988 [details] dmesg of new patched kernel, worked perfect
Alright, will forward upstream. Closing as FIXED.
Thanks