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

Powered by Openwall GNU/*/Linux Powered by OpenVZ