linux-kernel - Re: [Bug 41722] Clevo M5X0JE hangs in ACPI init

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: <CAE9FiQVwbkxXbi4yFR4CCdpNr-bm2Bn13Jxap7mX6OrYbM+_kg@mail.gmail.com>
Date:	Mon, 9 Jan 2012 17:32:28 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Rogério Brito <rbrito@....usp.br>,
	bugzilla-daemon@...zilla.kernel.org,
	Edward Donovan <edward.donovan@...ble.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	linux-kernel@...r.kernel.org,
	Márcia Coutinho de Brito <mcbrito@...il.com>,
	Ram Pai <linuxram@...ibm.com>
Subject: Re: [Bug 41722] Clevo M5X0JE hangs in ACPI init

On Mon, Jan 9, 2012 at 11:41 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Mon, Jan 9, 2012 at 11:22 AM, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
>>
>> I don't remember what problems we hit, but if Ram and Yinghai are
>> willing to take a look at them we should go ahead and try again.
>
> So the two bugzilla entries quoted in the revert are
>
>  http://bugzilla.kernel.org/show_bug.cgi?id=10080
>  http://bugzilla.kernel.org/show_bug.cgi?id=9961
>
>  with at least one real smoking gun in this one:
>
>  https://lkml.org/lkml/2008/3/26/94
>
> however at least *part* of the problem for some people was not the
> transparency itself, as much as the fact that we did bad things with
> 64-bit resources etc.

2 cases:
a. transparent bridge has resource allocated from BIOS.
b. transparent bridge does not have resource allocated from BIOS.

skipping transparent bridge size checking only affects case b.

when skip code is there, those bridge register will not be probed (
with 0xfff0fff0),
and those bridge bar will not get allocated. and child devices that
does not get allocated from
BIOS, kernel will allocate from parent bus resources... up to peer root bus.

Rogério's laptop does not like bus resize, could be because the bridge
does not like kernel to use
0xfff0fff0 to probe it...

We could add one quirks etc to skip this kind of probe.

>
> So what I think mostly happened was that not sizing up transparent
> bridges ended up showing up other bugs. We've fixed at least some of
> those other bugs in the meantime (things like using "unsigned long"
> for physical addresses in ioremap etc, which broke when 64-bit
> resources were used on 32-bit architectures).
>
> But it's entirely possible that it will still trigger similar issues.
> For example, even if a bridge is transparent, maybe it is still
> limited to 32-bit addresses? If we look at the actual IO windows, we'd
> get that 32-bit limit right automatically. If we just say "it's
> transparent", we might allocate child devices with 64-bit resources
> above the 4GB area, and be screwed. That seems to have been one
> problem above - even if we now get it right on a software level, there
> may actually be hardware issues in the same area.

in pci_bus_alloc_resource(),  we already have

        /* don't allocate too high if the pref mem doesn't support 64bit*/
        if (!(res->flags & IORESOURCE_MEM_64))
                max = PCIBIOS_MAX_MEM_32;

So it should allocate to range below 4G to unassigned children devices.

but need to make sure (peer) root bus does have valid resource range at first.

Rogério,

Do you have bootlog with "debug ignore_loglevel pci=earlydump" ?

Thanks

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