linux-kernel - Re: [2.6.34-rc1 REGRESSION] ahci 0000:00:1f.2: controller reset failed (0xffffffff)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 06 Apr 2010 21:59:43 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Andy Isaacson <adi@...apodia.org>
Cc:	linux-kernel@...r.kernel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: [2.6.34-rc1 REGRESSION] ahci 0000:00:1f.2: controller reset
	failed (0xffffffff)

On Tue, 2010-04-06 at 15:54 -0700, Andy Isaacson wrote:
> This Dell Precision WorkStation T3400 doesn't boot 2.6.34-rc1 (tried
> 522dba71).  2.6.33 was fine, and it's been running various stable
> kernels for the last 18 months.  Unfortunately I can't reasonably bisect
> as I need this machine to be usable, but I can test specific patches or
> options.  (three or four reboots is fine, 15 is not.)
> 
> full dmesg from failing boot and a successful boot at
> http://web.hexapodia.org/~adi/tmp/20100406-pci-ahci-reset-fail/
> 
> I suspect it's due to:
> 
> [    3.094038] pci 0000:00:1f.2: no compatible bridge window for [mem 0xff970000-0xff9707ff]
> [    3.103001] pci 0000:00:1f.2: can't reserve [mem 0xff970000-0xff9707ff]

Thanks a lot for reporting this!

No need to bisect it.  I'm pretty sure 2.6.34-rc1 will boot fine if you
use "pci=use_crs" (obviously that's only a temporary workaround until we
fix the real problem).

The BIOS apparently reported this window:

  pci_root PNP0A03:00: host bridge window [mem 0xff97c000-0xff97ffff]

which doesn't enclose the [mem 0xff970000-0xff9707ff] region where BIOS
put AHCI device, so we moved the AHCI device.  Unfortunately, we put it
at [mem 0x000a0000-0x000a07ff], which wasn't a very good choice because
that's probably already used by a VGA device.

If you happen to have Windows on this box, I'd love to know whether *it*
moves the AHCI device, too, or whether Windows interprets the BIOS
information differently than we do.  If you have Windows and can collect
screenshots of the Device Manager resources for the PCI bus and the AHCI
controller, that would be a good start.

Would you mind trying the patch below and the patch and kernel args
here:
  https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5

This will (1) reserve the VGA area, so we should put the AHCI device
elsewhere, and (2) collect a few more details about exactly what the
BIOS is reporting.

Bjorn


commit 46b6e80aae2ec1d073767c92bba1d98896bce700
Author: Bjorn Helgaas <bjorn.helgaas@...com>
Date:   Tue Apr 6 21:44:12 2010 -0600

diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index 86b1506..f4c0fe4 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -44,7 +44,6 @@ static inline void visws_early_detect(void) { }
 extern unsigned long saved_video_mode;
 
 extern void reserve_standard_io_resources(void);
-extern void i386_reserve_resources(void);
 extern void setup_default_timer_irq(void);
 
 #ifdef CONFIG_X86_MRST
diff --git a/arch/x86/kernel/head32.c b/arch/x86/kernel/head32.c
index b2e2460..966b37f 100644
--- a/arch/x86/kernel/head32.c
+++ b/arch/x86/kernel/head32.c
@@ -22,7 +22,6 @@ static void __init i386_default_early_setup(void)
 {
 	/* Initilize 32bit specific setup functions */
 	x86_init.resources.probe_roms = probe_roms;
-	x86_init.resources.reserve_resources = i386_reserve_resources;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
 
 	reserve_ebda_region();
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 9570541..24d9113 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -575,6 +575,13 @@ static struct resource standard_io_resources[] = {
 		.flags = IORESOURCE_BUSY | IORESOURCE_IO }
 };
 
+static struct resource video_ram_resource = {
+	.name	= "Video RAM area",
+	.start	= 0xa0000,
+	.end	= 0xbffff,
+	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
+};
+
 void __init reserve_standard_io_resources(void)
 {
 	int i;
@@ -583,6 +590,7 @@ void __init reserve_standard_io_resources(void)
 	for (i = 0; i < ARRAY_SIZE(standard_io_resources); i++)
 		request_resource(&ioport_resource, &standard_io_resources[i]);
 
+	request_resource(&iomem_resource, &video_ram_resource);
 }
 
 /*
@@ -1042,20 +1050,3 @@ void __init setup_arch(char **cmdline_p)
 
 	mcheck_init();
 }
-
-#ifdef CONFIG_X86_32
-
-static struct resource video_ram_resource = {
-	.name	= "Video RAM area",
-	.start	= 0xa0000,
-	.end	= 0xbffff,
-	.flags	= IORESOURCE_BUSY | IORESOURCE_MEM
-};
-
-void __init i386_reserve_resources(void)
-{
-	request_resource(&iomem_resource, &video_ram_resource);
-	reserve_standard_io_resources();
-}
-
-#endif /* CONFIG_X86_32 */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/