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-next>] [day] [month] [year] [list]
Date:	Tue, 9 Jun 2015 16:43:59 -0700
From:	Roland Dreier <roland@...estorage.com>
To:	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	George McCollister <george.mccollister@...il.com>
Subject: Regression in 3.10.80 vs. 3.10.79

Hi, I recently updated from 3.10.79 to 3.10.80, and my system wouldn't
boot any more.  I tracked this down to commit 92c934b10ec3 ("ACPI /
init: Fix the ordering of acpi_reserve_resources()").  With that
commit reverted, my system is OK again.

What happens is that ahci fails to initialize because
pcim_iomap_regions_request_all() fails with EBUSY, due to a resource
conflict on the first IO region of the ahci device.  Since my root
device is on ahci, that's the end of that.  I'm sure this is due to a
BIOS / ACPI table bug on my particular platform, but that's scant
comfort when the system won't boot :)

I patched 3.10.80 so that ahci continues to initialize after the
EBUSY, and relevant parts of the kernel log seem to be:

[    3.836643,26] system 00:06: [io  0x0400-0x047f] could not be reserved
...
[    3.844112,26] pci 0000:00:1f.2: BAR 0: assigned [io  0x0410-0x0417]
...
[    6.020040,00] ahci 0000:00:1f.2: BAR 0: can't reserve [io  0x0410-0x0417]

and /proc/ioports shows

    0410-0415 : ACPI CPU throttle

So if I'm understanding properly, for some reason we discover but fail
to reserve the region with the ACPI resources, then PCI decides to
assign ahci IO ports into that range, then ACPI loads and reserves
0x0410-0x0415, and then ahci fails to load.

If I fully revert the patch, then I see

[    3.853857,08] system 00:06: [io  0x0400-0x047f] has been reserved
...
[    3.861806,08] pci 0000:00:1f.2: BAR 0: assigned [io  0x0820-0x0827]

We're able to reserve the range, and then PCI assigns ahci into a
non-conflicting range.

I understand that the change here fixed another regression, but I'm
wondering if there's a way to make everyone happy here?  I can provide
debugging info from my system as required...

Thanks,
  Roland
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ