All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	mingo@elte.hu, rdreier@cisco.com,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Huang Ying <ying.huang@intel.com>
Subject: Re: kexec boot regression
Date: Tue, 15 Dec 2009 13:26:19 -0800	[thread overview]
Message-ID: <4B27FEFB.30902@kernel.org> (raw)
In-Reply-To: <20091215210126.GB28252@kernel.dk>

Jens Axboe wrote:
> On Tue, Dec 15 2009, Jens Axboe wrote:
>> On Tue, Dec 15 2009, Jens Axboe wrote:
>>> On Tue, Dec 15 2009, Yinghai Lu wrote:
>>>> Jens Axboe wrote:
>>>>> On Tue, Dec 15 2009, Yinghai Lu wrote:
>>>>>> Jens Axboe wrote:
>>>>>>> On Tue, Dec 15 2009, Yinghai Lu wrote:
>>>>>>>> Jens Axboe wrote:
>>>>>>>>> On Tue, Dec 15 2009, Yinghai Lu wrote:
>>>>>>>>>> [PATCH] x86/pci: intel ioh bus num reg accessing fix
>>>>>>>>>>
>>>>>>>>>> it is above 0x100, so if mmconf is not enable, need to skip it
>>>>>>>>> This works, it kexecs kernels fine. But since 2.6.32 doesn't have the
>>>>>>>>> mmconf problem to begin with, are we now just working around the issue?
>>>>>>>>> SRAT still reports issues, numa doesn't work.
>>>>>>>> that patch will be bullet proof... we need it.
>>>>>>>>
>>>>>>>> also still need to figure out why memmap range is not passed properly.
>>>>>>>>
>>>>>>>> do you mean 2.6.32 kexec 2.6.32 it have worked mmconf and numa in
>>>>>>>> second kernel?
>>>>>>> Yes, 2.6.32 booted and 2.6.32 kexec'ed works just fine, no SRAT
>>>>>>> complaints and NUMA works fine.
>>>>>> do you need 
>>>>>> memmap=62G@4G
>>>>>> in this case?
>>>>> Yes, I've needed that always.
>>>> good,
>>>>
>>>> can you enable debug option in kexec to see why kexec can not pass
>>>> whole 38? range to second kernel?
>>> Not getting any output so far, -d doesn't do much. Poking around in the
>>> source...
>> OK, cold boot and kexec 2.0.1 gets all 39 ranges passed properly to
>> kexec'ed kernels. Since the older kexec stopped at range 30 (31 ranges
>> total), that smells like just a kexec bug. Retesting -git...
> 
> Current -git works fine when all the ranges are passed correctly. So, I
> think, the only existing regression is the SRAT issue.

did you change node_shift?

YH

  reply	other threads:[~2009-12-15 21:27 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-15 11:50 kexec boot regression Jens Axboe
2009-12-15 12:01 ` Yinghai Lu
2009-12-15 12:14   ` Jens Axboe
2009-12-15 12:31     ` Yinghai Lu
2009-12-15 12:39       ` Jens Axboe
2009-12-15 12:55         ` Yinghai Lu
2009-12-15 14:11           ` Jens Axboe
2009-12-15 18:39             ` Yinghai Lu
2009-12-15 18:47               ` Matthew Wilcox
2009-12-15 18:54               ` Jens Axboe
2009-12-15 18:59               ` Jens Axboe
2009-12-15 19:04                 ` Yinghai Lu
2009-12-15 19:11                   ` Jens Axboe
2009-12-15 19:17                     ` Yinghai Lu
2009-12-15 19:22                       ` Jens Axboe
2009-12-15 19:28                         ` Jens Axboe
2009-12-15 19:44                     ` Yinghai Lu
2009-12-15 19:48                       ` Jens Axboe
2009-12-15 19:49                         ` Yinghai Lu
2009-12-15 19:57                           ` Jens Axboe
2009-12-15 21:30                   ` Markus Trippelsdorf
2009-12-15 23:02                     ` kexec boot regression radeon/kms (bisected) Markus Trippelsdorf
2009-12-15 19:43               ` kexec boot regression Jens Axboe
2009-12-15 19:48                 ` Yinghai Lu
2009-12-15 19:51                   ` Jens Axboe
2009-12-15 19:56                     ` Yinghai Lu
2009-12-15 20:09                       ` Jens Axboe
2009-12-15 20:14                     ` Yinghai Lu
2009-12-15 20:19                       ` Jens Axboe
2009-12-15 20:21                         ` Yinghai Lu
2009-12-15 20:42                           ` Jens Axboe
2009-12-15 20:55                             ` Jens Axboe
2009-12-15 21:01                               ` Jens Axboe
2009-12-15 21:26                                 ` Yinghai Lu [this message]
2009-12-15 21:30                                   ` Jens Axboe
2009-12-15 21:40                                     ` Jens Axboe
2009-12-15 21:43                                       ` Yinghai Lu
2009-12-15 21:47                                         ` Jens Axboe
2009-12-15 21:50                                           ` Yinghai Lu
2009-12-15 21:52                                           ` Jens Axboe
2009-12-15 22:24                                             ` Yinghai Lu
2009-12-16 10:01                                               ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B27FEFB.30902@kernel.org \
    --to=yinghai@kernel.org \
    --cc=hpa@zytor.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rdreier@cisco.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.