[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47E80247.8090702@m3y3r.de>
Date: Mon, 24 Mar 2008 20:34:31 +0100
From: Thomas Meyer <thomas@...3r.de>
To: Ingo Molnar <mingo@...e.hu>
CC: Stefan Richter <stefanr@...6.in-berlin.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
"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>
Subject: Re: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported
regressions from 2.6.24)
Ingo Molnar schrieb:
> * Stefan Richter <stefanr@...6.in-berlin.de> wrote:
>
>
>> On my x86-32 test system, none of the devices gets an MMIO region
>> above the 4G map. (Reconfigured with CONFIG_RESOURCES_64BIT=y while
>> having CONFIG_HIGHMEM4G=y, like in Thomas M's .config.)
>>
>
> 64-bit ioremap on x86 never worked AFAIK, the whole API is using 32-bit
> physical addresses which is limited to 4GB. But ... this bug does have
> the feeling of the wrong IO side physical memory being mapped. (0xff
> data means there's no device there - typical of non-existent RAM/IO)
>
> could you please pull the x86/latest tree to do a kernel pagetable dump
> for us? You can pull it via the instructions here:
>
> http://people.redhat.com/mingo/x86.git/README
>
> then enable CONFIG_DEBUG_KERNEL=y and CONFIG_X86_PTDUMP=y boot the
> kernel so that ohci1394 doesnt work. Then dump the pagetables and other
> hw info via:
>
> http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
>
> send us the cfs-debug-info file that gets generated. We'll be able to
> tell from that whether your ioremap's are OK. (x86/latest will also
> printk all ioremap()s and results that are done)
>
>
See attached file.
View attachment "cfs-debug-info-2008.03.24-20.18.20" of type "text/plain" (351697 bytes)
Powered by blists - more mailing lists