linux-kernel - Re: kexec + ACPI in 2.6.19 (was: Re: kexec + USB storage in 2.6.19)

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]

Message-ID: <20070112165600.GB24291@localdomain>
Date:	Fri, 12 Jan 2007 18:56:00 +0200
From:	Dan Aloni <da-x@...atomic.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: kexec + ACPI in 2.6.19 (was: Re: kexec + USB storage in 2.6.19)

On Fri, Jan 12, 2007 at 06:43:40PM +0200, Dan Aloni wrote:
> On Fri, Jan 12, 2007 at 06:28:00PM +0200, Dan Aloni wrote:
> > On Fri, Jan 12, 2007 at 06:02:43PM +0200, Dan Aloni wrote:
> > > On Fri, Jan 12, 2007 at 08:26:03AM -0700, Eric W. Biederman wrote:
> > > > Dan Aloni <da-x@...atomic.org> writes:
> > > > 
> > > > > I'm attaching the full logs.
> > > > 
> > > > Thanks.
> > > > 
> > > > > [ 8656.272980] ACPI Error (tbxfroot-0512): Could not map memory at 0000040E for length 2 [20060707]
> > > > 
> > > > Ok. This looks like the first sign of trouble.
> > > > Normally I would suspect a memory map issue but your e820 memory map looks fine,
> > > > although a little different between the two kernels.
> > > > 
> > > > Is this enough of a hint for you to dig more deeply?
> > > 
> > > Reverting just the ACPI code (everything under drivers/acpi/*) 
> > > back to the version of 2.6.18.3 doesn't fix the problem, so it 
> > > must be something else.
> > 
> > Just occured to me that I didn't revert the relevant code under 
> > arch/x86_64 so it might still be related somehow..
> 
> After adding a few prints inside __ioremap() it appears the function
> exits for phys_addr==0x40e because (!PageReserved(page)).
> 
> Isn't page 0 supposed to be reserved? I clearly see that it is
> being reserved under setup_arch(). 
> 
> Odd, I must say...

In __ioremap() I added this under if(!PageReserved(page)) {...}:

		if (phys_addr == 0x40e) {
			printk("PAGE %p (pfn=%ld): flags=%lx, count=%d\n",
			       page,
			       page_to_pfn(page),
			       page->flags,
			       atomic_read(&page->_count));
		}

And I get:

[ 1013.864201] PAGE ffff810001000000 (pfn=0): flags=0, count=0

So at least no one is using that page. Still it is not clear why it
doesn't have the reserve flag turned on.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-
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/