lkml.org 
[lkml]   [2012]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [Bug 41722] Clevo M5X0JE hangs in ACPI init
From
On Mon, Jan 9, 2012 at 11:41 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Jan 9, 2012 at 11:22 AM, Jesse Barnes <jbarnes@virtuousgeek.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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-01-10 02:35    [W:1.161 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site