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]

Message-Id: <201004121156.41716.bjorn.helgaas@hp.com>
Date:	Mon, 12 Apr 2010 11:56:41 -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>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [2.6.34-rc1 REGRESSION] ahci 0000:00:1f.2: controller reset failed (0xffffffff)

On Tuesday 06 April 2010 09:59:43 pm Bjorn Helgaas wrote:
> 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.

We established that the patch in the message above wasn't enough
(the patch reserved 0xa0000-0xbffff, and Linux moved the AHCI
controller to 0xc0000 instead of 0xa0000).

But I'd still like to see the details of what ACPI is telling us,
so if you wouldn't mind trying that patch from bugzilla:
  https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
and collecting an acpidump, and attaching both to the bug report:
  https://bugzilla.kernel.org/show_bug.cgi?id=15744
that would be great.

Linux thinks the windows are:
  pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
  pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000effff]
  pci_root PNP0A03:00: host bridge window [mem 0x000f0000-0x000fffff]

The 0xa0000-0xbffff one makes good sense.  That's normally MMIO that's
routed via PCI to the VGA device frame buffer, and we should be able
to figure out how to avoid that area, e.g., by using BIOS info, PCI
class codes, etc.

Now we need to figure how to avoid the 0xc0000-0xeffff and 0xf0000-0xfffff
windows.  Maybe there's something special about how ACPI describes them.

Or maybe we're just unlucky because these are the first windows in the
_CRS list, and Linux tries them in order, while Windows uses a different
strategy.

Bjorn
--
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/