linux-kernel - Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)

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:	Wed, 26 Mar 2008 13:14:50 +0300
From:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Thomas Meyer <thomas@...3r.de>, Ingo Molnar <mingo@...e.hu>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Gary Hade <garyhade@...ibm.com>
Subject: Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported
	regressions from 2.6.24)

On Tue, Mar 25, 2008 at 02:47:35PM -0700, Linus Torvalds wrote:
> On Tue, 25 Mar 2008, Thomas Meyer wrote:
> > 
> > and compare lspci -vv from 2.6.25 and 2.6.24:
> > 
> > 2.6.25:
> >
> >    Region 0: [virtual] Memory at 100000000 (32-bit, non-prefetchable) [size=4K]
> > 
> > 2.6.24:
> >
> >    Region 0: Memory at 8c000000 (32-bit, non-prefetchable) [size=4K]
> 
> Ok, so it didn't use to be at the 4GB mark.

Note that 'Memory at 100000000' is totally bogus as this is 32-bit BAR
and respective PCI bridge is 32-bit either.

Most interesting thing is that under 2.6.24 Tomas had

PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: 8c000000-8c0fffff
  PREFETCH window: disabled.

but with 2.6.25

PCI: Bridge: 0000:00:1e.0
  IO window: disabled.
  MEM window: 0x00000000-0x000fffff
  PREFETCH window: disabled.

I'm sure that MEM window was actually 0x100000000-0x1000fffff as that
printk shows only 8 hex digits.

> This seems to be a PCI and resource alloc issue. It would be really 
> interesting to see where the 4GB allocation started. Ie ignore anything 
> else (warnings, driver loadings etc), and _just_ look at lspci -vv output 
> for where the memory got allocated.

Yeah, it's resource issue for sure. The 00:1e.0 is a transparent bridge,
so I blame commit 8fa5913d54f3b1e09948e6a0db34da887e05ff1f
(PCI: remove transparent bridge sizing). It's wrong for two reasons:
- we cannot ignore standard windows of a transparent bridge as they
  always positive decode, so they are potential source of address conflicts;
- that patch just broke whole bridge setup logic in unpredictable way.

What confused me a lot initially is that the patch was already there
in 2.6.24. But I think that issue was somehow masked by 'unsigned
longs' used in setup-bus.c all over the place instead of resource_size_t,
which has been fixed by Ben in 2.6.25...
I think that's why Thomas has everything working again without
CONFIG_RESOURCES_64BIT.

Thomas, can you put CONFIG_RESOURCES_64BIT=y back and either
revert commit 8fa5913d54f3b1e09948e6a0db34da887e05ff1f, or
just comment out these two lines in drivers/pci/setup-bus.c:

		if (bus->self->transparent)
			break;

and check if it helps?

Ivan.
--
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/