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:	Sat, 30 Aug 2008 20:00:00 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Yinghai Lu <yhlu.kernel@...il.com>
cc:	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Jordan Crouse <jordan.crouse@....com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>, Tejun Heo <htejun@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	David Witbrodt <dawitbro@...global.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel Testers <kernel-testers@...r.kernel.org>
Subject: Re: Linux 2.6.27-rc5: System boot regression caused by commit
 a2bd7274b47124d2fc4dfdb8c0591f545ba749dd



On Sat, 30 Aug 2008, Yinghai Lu wrote:
> >
> >                /* Don't touch classless devices or host bridges or ioapics.  */
> >                if (class == PCI_CLASS_NOT_DEFINED ||
> >                    class == PCI_CLASS_BRIDGE_HOST)
> >                        continue;
> >
> >
> > it skips the host bridge...
> 
> what's story for not touching host bridges?

Ahh. Exactly because of things like this. The hist bridge BAR's are often 
special.

That code comes from almost four years ago, the commit message was:

  Author: Maciej W. Rozycki <macro@...s.com>
  Date:   Thu Dec 16 21:44:31 2004 -0800

    [PATCH] PCI: Don't touch BARs of host bridges
    
     BARs of host bridges often have special meaning and AFAIK are best left
    to be setup by the firmware or system-specific startup code and kept
    intact by the generic resource handler.  For example a couple of host
    bridges used for MIPS processors interpret BARs as target-mode decoders
    for accessing host memory by PCI masters (which is quite reasonable).
    For them it's desirable to keep their decoded address range overlapping
    with the host RAM for simplicity if nothing else (I can imagine running
    out of address space with lots of memory and 32-bit PCI with no DAC
    support in the participating devices).
    
     This is already the case with the i386 and ppc platform-specific PCI
    resource allocators.  Please consider the following change for the generic
    allocator.  Currently we have a pile of hacks implemented for host bridges
    to be left untouched and I'd be pleased to remove them.
    
    From: "Maciej W. Rozycki" <macro@...s.com>
    Signed-off-by: Greg Kroah-Hartman <greg@...ah.com>

and we've had other things where host bridges are special (ie iirc, if you 
turn off PCI_COMMAND_MEM from a host bridge, it stops access to real RAM 
from the CPU for some bridges - so you must never turn those things off or 
you get a dead system).

(But at least Intel host bridges will just ignore writes to the CMD 
register, I think - you cannot turn MEM off).

			Linus
--
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