Bug 10512

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