On Tue, 13 Apr 2021, Mike Rapoport wrote:
>
> I think I've found the reason. trim_snb_memory() reserved the entire first
> megabyte very early leaving no room for real mode trampoline allocation.
> Since this reservation is needed only to make sure integrated gfx does not
> access some memory, it
On 4/13/21 11:23 AM, Mike Rapoport wrote:
> On Tue, Apr 13, 2021 at 10:34:25AM -0700, Randy Dunlap wrote:
>> On 4/13/21 9:58 AM, Mike Rapoport wrote:
>>
>> Mike,
>> That works.
>>
>> Please send the next test.
>
> I think I've found the reason. trim_snb_memory() reserved the entire first
> megaby
On Tue, Apr 13, 2021 at 10:34:25AM -0700, Randy Dunlap wrote:
> On 4/13/21 9:58 AM, Mike Rapoport wrote:
> > On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
> >> On 4/12/21 11:06 PM, Mike Rapoport wrote:
> >>> Hi Randy,
> >>>
> >>> On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunla
On 4/13/21 9:58 AM, Mike Rapoport wrote:
> On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
>> On 4/12/21 11:06 PM, Mike Rapoport wrote:
>>> Hi Randy,
>>>
>>> On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
On 4/12/21 10:01 AM, Mike Rapoport wrote:
> On Mon, Apr
On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
> On 4/12/21 11:06 PM, Mike Rapoport wrote:
> > Hi Randy,
> >
> > On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
> >> On 4/12/21 10:01 AM, Mike Rapoport wrote:
> >>> On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap
On 4/12/21 11:06 PM, Mike Rapoport wrote:
> Hi Randy,
>
> On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
>> On 4/12/21 10:01 AM, Mike Rapoport wrote:
>>> On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
>>>
>>> I thought about adding some prints to see what's causing
Hi Randy,
On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
> On 4/12/21 10:01 AM, Mike Rapoport wrote:
> > On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
> >
> > I thought about adding some prints to see what's causing the hang, the
> > reservations or their absence.
On 4/12/21 10:01 AM, Mike Rapoport wrote:
> On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
>> On 4/11/21 11:14 PM, Mike Rapoport wrote:
>>> Hi Randy,
>>>
>>> On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> Hi all,
>>
On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
> On 4/11/21 11:14 PM, Mike Rapoport wrote:
> > Hi Randy,
> >
> > On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
> >> On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Changes since 20210408:
> >>>
> >>
On 4/11/21 11:14 PM, Mike Rapoport wrote:
> Hi Randy,
>
> On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
>> On 4/9/21 4:51 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20210408:
>>>
>>
>> Hi,
>>
>> I cannot boot linux-next 20210408 nor 20210409 on an antique
>> x86_
Hi Randy,
On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
> On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20210408:
> >
>
> Hi,
>
> I cannot boot linux-next 20210408 nor 20210409 on an antique
> x86_64 laptop (Toshiba Portege).
>
> After many faile
On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20210408:
>
Hi,
I cannot boot linux-next 20210408 nor 20210409 on an antique
x86_64 laptop (Toshiba Portege).
After many failed tests, I finally resorted to git bisect,
which led me to:
git bisect start
# good: [e49d033bdd
.kernel.org; Gary Bisson
> ; Fabio Estevam ;
> Shawn Guo
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
>
> [...]
>
> > Hi Ulf and Shawn,
> >
> > Aisheng and I debug this issue these days, and we find the root cause.
> > There are two thing
[...]
> Hi Ulf and Shawn,
>
> Aisheng and I debug this issue these days, and we find the root cause. There
> are two things
> to describe.
>
> 1) voltage switch issue. The properity "no-1-8-v" do not work for
> MMC_TIMING_MMC_DDR52.
> This is another bug, we need to fix, but has no relation wi
[...]
>>> >
>>> > In the meantime, I will follow the process of Haibo Chen's debugging
>>> > around the voltage switch issue and look into what Dong's suggesting
>>> > around this may be.
>>> >
>>> > Just to be clear, I would definitely prefer a fix in the sdhci driver,
>>>
>>> yup, I prefer to fi
Hi Shawn,
On Fri, Jan 13, 2017 at 12:03 PM, Shawn Lin wrote:
[...]
>
>> 2) root cause, in __mmc_switch, the process is send CMD6 --> set DDR52
>> timing --> polling for busy.
>> For the DDR52 timing setting, we call set_ios(), in the set_ios, we first
>> set DDR_EN to config sdhc in ddr mode,
x-...@vger.kernel.org; Linus Walleij
>> ; Adrian Hunter ; A.S.
>> Dong ; linux-kernel@vger.kernel.org; Bough Chen
>> ; Gary Bisson ;
>> Fabio Estevam ; Shawn Guo
>> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
>>
>> On 2017/1/13 0:51, Ulf Hans
-kernel@vger.kernel.org; Bough Chen
; Gary Bisson ;
Fabio Estevam ; Shawn Guo
Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
On 2017/1/13 0:51, Ulf Hansson wrote:
+ Haibo, Gary, Fabio, Shawn Gou
On 6 January 2017 at 16:56, Clemens Gruber
wrote:
On Fri, Jan 06, 2017 at 10:33
x-kernel@vger.kernel.org; Bough Chen
> ; Gary Bisson ;
> Fabio Estevam ; Shawn Guo
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
>
> On 2017/1/13 0:51, Ulf Hansson wrote:
> > + Haibo, Gary, Fabio, Shawn Gou
> >
> > On 6 January 2017 at 16:56, Cl
On 2017/1/13 0:51, Ulf Hansson wrote:
+ Haibo, Gary, Fabio, Shawn Gou
On 6 January 2017 at 16:56, Clemens Gruber wrote:
On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
On 2017/1/6 8:41, Clemens Gruber wrote:
Hi,
with the current mainline 4.10-rc2 kernel, I can no longer boot from
+ Haibo, Gary, Fabio, Shawn Gou
On 6 January 2017 at 16:56, Clemens Gruber wrote:
> On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
>> On 2017/1/6 8:41, Clemens Gruber wrote:
>> > Hi,
>> >
>> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
>> > the eMMC on my i.M
On Tue, Jan 10, 2017 at 6:25 AM, Jagan Teki wrote:
> On Fri, Jan 6, 2017 at 5:07 PM, Clemens Gruber
> wrote:
>> On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
>>> On 2017/1/6 8:41, Clemens Gruber wrote:
>>> > Hi,
>>> >
>>> > with the current mainline 4.10-rc2 kernel, I can no longer b
On Fri, Jan 6, 2017 at 8:41 AM, Clemens Gruber
wrote:
> Hi,
>
> with the current mainline 4.10-rc2 kernel, I can no longer boot from
> the eMMC on my i.MX6Q board.
>
> Details:
> The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
> eMMC 4.41 features and we did not implement v
; Ulf Hansson ; Linus
> Walleij ; Adrian Hunter ;
> A.S. Dong ; linux-kernel@vger.kernel.org
> Subject: Re: eMMC boot problem: switch to bus width 8 ddr failed
>
> On 2017/1/6 23:56, Clemens Gruber wrote:
> > On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> >&g
Hi Jagan,
On 2017/1/10 6:25, Jagan Teki wrote:
On Fri, Jan 6, 2017 at 5:07 PM, Clemens Gruber
wrote:
On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
On 2017/1/6 8:41, Clemens Gruber wrote:
Hi,
with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.M
On Fri, Jan 6, 2017 at 5:07 PM, Clemens Gruber
wrote:
> On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
>> On 2017/1/6 8:41, Clemens Gruber wrote:
>> > Hi,
>> >
>> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
>> > the eMMC on my i.MX6Q board.
>> >
>> > Details:
On 2017/1/7 0:07, Clemens Gruber wrote:
On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
On 2017/1/6 8:41, Clemens Gruber wrote:
Hi,
with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.
Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but
On 2017/1/6 23:56, Clemens Gruber wrote:
On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
On 2017/1/6 8:41, Clemens Gruber wrote:
Hi,
with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.
Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT bu
On Fri, Jan 06, 2017 at 10:54:35AM +0800, Shawn Lin wrote:
> On 2017/1/6 8:41, Clemens Gruber wrote:
> > Hi,
> >
> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
> > the eMMC on my i.MX6Q board.
> >
> > Details:
> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q
On Fri, Jan 06, 2017 at 10:33:49AM +0800, Shawn Lin wrote:
> On 2017/1/6 8:41, Clemens Gruber wrote:
> > Hi,
> >
> > with the current mainline 4.10-rc2 kernel, I can no longer boot from
> > the eMMC on my i.MX6Q board.
> >
> > Details:
> > The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q
On 2017/1/6 8:41, Clemens Gruber wrote:
Hi,
with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.
Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
On 2017/1/6 8:41, Clemens Gruber wrote:
Hi,
with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.
Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
Hi,
with the current mainline 4.10-rc2 kernel, I can no longer boot from
the eMMC on my i.MX6Q board.
Details:
The eMMC is a Micron MTFC4GACAJCN-1M WT but as the i.MX6Q only supports
eMMC 4.41 features and we did not implement voltage switching from 3.3V
to 1.8V or lower, I did add no-1-8-v; (but
Hello,
I can confirm certain wireless networks cause hangs (stalls - mostly
swapper/n). This only happens with one network here, others are fine. I
tried to bisect it but never came to an presentable result.
Greetings,
Tobias
On 01.12.2016 17:10, Radim Krčmář wrote:
2016-11-30 14:20-0800,
2016-11-30 14:20-0800, Kui Zhang:
> this result seem to result same panic
> +CONFIG_CFG80211=y
I still can't reproduce, sorry, and the attached panic is yet another
thing ... you mentioned that it regressed between v4.9-rc5 and v4.9-rc7;
please run git bisect on it.
2016-11-29 09:04-0800, Kui Zhang:
> Config attached.
Not here; needs Mr. Clippy to hold in place.
Thanks
I was able to reproduce the problem with v4.9-rc7+ (commit
88abd8249ee8bcebb98c90e890ea5e342db832af), after git clean -xdf; make
mrproper
Config attached. Need to set CONFIG_KVM=y to reproduce boot issue.
set CONFIG_KVM=y in menuconfig also set CONFIG_IRQ_BYPASS_MANAGER=y, I
dont see conf
2016-11-29 03:04-0800, Kui Zhang:
> Looks like my boot issue might be kvm related. System boots fine with
> CONFIG_KVM=m
v4.9-rc6 has some funny changes around modversion, although your bug
looks even more random ...
Can you reproduce with v4.9-rc7 built from a clean repo?
Please send your config
Looks like my boot issue might be kvm related. System boots fine with
CONFIG_KVM=m
--- .config 2016-11-29 02:41:24.753930839 -0800
+++ .config.working 2016-11-29 02:41:11.029065291 -0800
@@ -3544,7 +3544,7 @@
# CONFIG_IMG_ASCII_LCD is not set
# CONFIG_UIO is not set
# CONFIG_VFIO is not set
-
Hello,
I am having problem booting 4.9.0-rc6+ on my laptop.
4.9.0-rc5+ works, so not likely hardware issues.
Ubuntu Zesty Zapus
###
gcc-6 with
CONFIG_PCI_QUIRKS=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
After grub, screen turns off. No pre modeset messages. Then system
reboot itself.
When
Dear friends, I have problem booting my custom HW (around s5pv210 SoC)
using the latest stable kernel release (v4.8.5). Of course this is the first DT
based kernel I'm trying to boot with in this HW. I chose s5pv210_defconfig and
by checking CONFIG_ARM_APPENDED_DTB, appended the DTB (s5pv210-smdk
A machine with only node 1 was observed to crash very early in boot with
the following message
[0.00] BUG: unable to handle kernel paging request at 0002a3c8
[0.00] PGD 0
[0.00] Modules linked in:
[0.00] Hardware name: Supermicro H8DSP-8/H8DSP-8, BIOS 080011
On Wed, Jan 20, 2016 at 1:36 PM, Larry Finger wrote:
> On 01/20/2016 02:33 PM, Dan Williams wrote:
> That isn't quite right. I added that patch, and restored the 4.4.0
> configuration. That one has "CONFIG_STRICT_DEVM=y". After I ran "make
> oldconfig", CONFIG_STRICT_DEVM was still set, which kill
On 01/20/2016 02:33 PM, Dan Williams wrote:
On Wed, Jan 20, 2016 at 12:16 PM, Dan Williams wrote:
On Wed, Jan 20, 2016 at 12:08 PM, Dan Williams wrote:
On Wed, Jan 20, 2016 at 12:01 PM, Larry Finger
wrote:
My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the
4.4-git se
On 01/20/2016 02:16 PM, Dan Williams wrote:
On Wed, Jan 20, 2016 at 12:08 PM, Dan Williams wrote:
On Wed, Jan 20, 2016 at 12:01 PM, Larry Finger
wrote:
My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the
4.4-git series. The problem was bisected to commit 21266be. It too
On Wed, Jan 20, 2016 at 12:16 PM, Dan Williams wrote:
> On Wed, Jan 20, 2016 at 12:08 PM, Dan Williams
> wrote:
>> On Wed, Jan 20, 2016 at 12:01 PM, Larry Finger
>> wrote:
>>> My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the
>>> 4.4-git series. The problem was bisected
On Wed, Jan 20, 2016 at 12:08 PM, Dan Williams wrote:
> On Wed, Jan 20, 2016 at 12:01 PM, Larry Finger
> wrote:
>> My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the
>> 4.4-git series. The problem was bisected to commit 21266be. It took a while
>> to figure out why a commi
On Wed, Jan 20, 2016 at 12:01 PM, Larry Finger
wrote:
> My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the
> 4.4-git series. The problem was bisected to commit 21266be. It took a while
> to figure out why a commit that only rearranges the Kconfig files could
> cause the pro
My PowerBook G4 Aluminum with a 32-bit PPC processor fails to boot for the
4.4-git series. The problem was bisected to commit 21266be. It took a while to
figure out why a commit that only rearranges the Kconfig files could cause the
problem.
The answer came when I read the commit message for 9
On Thu, 24 Oct, at 12:14:26PM, Jasper Bryant-Greene wrote:
> I have a box here which is set up for EFI boot with no boot loader.
>
> The kernel is compiled with a built-in initrd and command line.
>
> In 3.10 this was all working well. However, after updating to 3.11.5 a
> reboot leads to the EFI
I have a box here which is set up for EFI boot with no boot loader.
The kernel is compiled with a built-in initrd and command line.
In 3.10 this was all working well. However, after updating to 3.11.5 a reboot
leads to the EFI firmware boot screen appearing followed by the middle section
of it
On Wed, 23 Jan 2008, Nishanth Aravamudan wrote:
> Right, so it might have functioned before, but the correctness was
> wobbly at best... Certainly the memoryless patch series has tightened
> that up, but we missed these SLAB issues.
>
> I see that your patch fixed Olaf's machine, Pekka. Nice work
On 23.01.2008 [13:14:26 -0800], Christoph Lameter wrote:
> On Wed, 23 Jan 2008, Pekka Enberg wrote:
>
> > I think Mel said that their configuration did work with 2.6.23
> > although I also wonder how that's possible. AFAIK there has been some
> > changes in the page allocator that might explain th
On Wed, 23 Jan 2008, Pekka Enberg wrote:
> I think Mel said that their configuration did work with 2.6.23
> although I also wonder how that's possible. AFAIK there has been some
> changes in the page allocator that might explain this. That is, if
> kmem_getpages() returned pages for memoryless nod
Hi,
On Jan 23, 2008 9:52 PM, Nishanth Aravamudan <[EMAIL PROTECTED]> wrote:
> On at least one of the machines in question, wasn't it the case that
> node 0 had all the memory and node 1 had all the CPUs? In that case, you
> would have to boot off a memoryless node? And as long as that is a
> physi
On 23.01.2008 [19:29:15 +0200], Pekka J Enberg wrote:
> Hi,
>
> On Wed, 23 Jan 2008, Mel Gorman wrote:
> > Applied in combination with the N_NORMAL_MEMORY revert and it fails to
> > boot. Console is as follows;
>
> Thanks for testing!
>
> On Wed, 23 Jan 2008, Mel Gorman wrote:
> > [c05c3
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> Fine. But, why are we hitting fallback_alloc() in the first place? It's
> definitely not because of missing ->nodelists as we do:
>
> cache_cache.nodelists[node] = &initkmem_list3[CACHE_CACHE];
>
> before attempting to set up kmalloc caches.
On Wed, 23 Jan 2008, Mel Gorman wrote:
> This patch adds the necessary checks to make sure a kmem_list3 exists for
> the preferred node used when growing the cache. If the preferred node has
> no nodelist then the currently running node is used instead. This
> problem only affects the SLAB allocat
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> I still think Christoph's kmem_getpages() patch is correct (to fix
> cache_grow() oops) but I overlooked the fact that none the callers of
> cache_alloc_node() deal with bootstrapping (with the exception of
> __cache_alloc_node() that even has a
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> Furthermore, don't let kmem_getpages() call alloc_pages_node() if nodeid
> passed
> to it is -1 as the latter will always translate that to numa_node_id() which
> might not have ->nodelist that caused the invocation of fallback_alloc() in
> the
> firs
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> As far as I can tell, there are two ways to fix this:
[snip]
> (2) initialize cache_cache.nodelists with initmem_list3 equivalents
> for *each node hat has normal memory*
An untested patch follows:
---
mm/slab.c | 39 -
Hi,
On Wed, 23 Jan 2008, Mel Gorman wrote:
> Applied in combination with the N_NORMAL_MEMORY revert and it fails to
> boot. Console is as follows;
Thanks for testing!
On Wed, 23 Jan 2008, Mel Gorman wrote:
> [c05c3b40] c00dadb4 .cache_grow+0x7c/0x338
> [c05c3c00] c00
On (23/01/08 16:49), Pekka J Enberg didst pronounce:
> Hi,
>
> On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> > > I still think Christoph's kmem_getpages() patch is correct (to fix
> > > cache_grow() oops) but I overlooked the fact that none the callers of
> > > cache_alloc_node() deal with bo
Hi,
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> > I still think Christoph's kmem_getpages() patch is correct (to fix
> > cache_grow() oops) but I overlooked the fact that none the callers of
> > cache_alloc_node() deal with bootstrapping (with the exception of
> > __cache_alloc_node() that
On (23/01/08 15:27), Olaf Hering didst pronounce:
> On Wed, Jan 23, Mel Gorman wrote:
>
> > This patch in combination with a partial revert of commit
> > 04231b3002ac53f8a64a7bd142fde3fa4b6808c6 fixes a regression between 2.6.23
> > and 2.6.24-rc8 where a PPC64 machine with all CPUS on a memoryles
On Wed, 23 Jan 2008, Pekka J Enberg wrote:
> I still think Christoph's kmem_getpages() patch is correct (to fix
> cache_grow() oops) but I overlooked the fact that none the callers of
> cache_alloc_node() deal with bootstrapping (with the exception of
> __cache_alloc_node() that even has a c
On Wed, Jan 23, Mel Gorman wrote:
> This patch in combination with a partial revert of commit
> 04231b3002ac53f8a64a7bd142fde3fa4b6808c6 fixes a regression between 2.6.23
> and 2.6.24-rc8 where a PPC64 machine with all CPUS on a memoryless node fails
> to boot. If approved by the SLAB maintainers,
Hi Mel,
On Wed, 23 Jan 2008, Mel Gorman wrote:
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
> linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c
> linux-2.6.24-rc8-010_handle_missing_l3/mm/slab.c
> --- linux-2.6.24-rc8-005-revert-memoryless-slab/mm/slab.c 2008-01-22
> 17:46:32.
This patch in combination with a partial revert of commit
04231b3002ac53f8a64a7bd142fde3fa4b6808c6 fixes a regression between 2.6.23
and 2.6.24-rc8 where a PPC64 machine with all CPUS on a memoryless node fails
to boot. If approved by the SLAB maintainers, it should be merged for 2.6.24.
With memo
On Sat, Dec 22, 2007 at 09:37:17AM +0100, Sam Ravnborg wrote:
> Hi Jesper.
>
> > __initramfs_end = .;
> > - /* We fill to the next page, so we can discard all init
> > - pages without needing to consider what payload might be
> > - appended to the ke
Hi Jesper.
> __initramfs_end = .;
> - /* We fill to the next page, so we can discard all init
> -pages without needing to consider what payload might be
> -appended to the kernel image. */
> - FILL (0);
> - . = ALI
= .;
__data_end = . ; /* Move to _edata ? */
__bss_start = .; /* BSS */
> On Fri, Dec 21, 2007 at 04:14:04PM +0100, Jesper Nilsson wrote:
> >
> > On Sat, Dec 15, 2007 at 02:59:33PM +0900, Yuusei KUWANA wrote:
> > > arch/cris/arch-v10/vmlin
sson wrote:
>
> On Sat, Dec 15, 2007 at 02:59:33PM +0900, Yuusei KUWANA wrote:
> > arch/cris/arch-v10/vmlinux.lds.S
> > fix boot problem
> > * too old initcall style. replace INITCALLS macro
> > * __init_begin, __init_end move for free_initmem()
>
> Hi,
>
>
On Sat, Dec 15, 2007 at 02:59:33PM +0900, Yuusei KUWANA wrote:
> arch/cris/arch-v10/vmlinux.lds.S
> fix boot problem
> * too old initcall style. replace INITCALLS macro
> * __init_begin, __init_end move for free_initmem()
Hi,
The conversion to INITCALLS is ok (I have the same chang
arch/cris/arch-v10/vmlinux.lds.S
fix boot problem
* too old initcall style. replace INITCALLS macro
* __init_begin, __init_end move for free_initmem()
Note: with this patch kernel boot and mount root,
but after init done, kernel panic at do_signal() ...
ryu
Signed-off-by: Yuusei KUWANA
> > #define set_pageblock_order(x) do {} while (0)
> >
> > #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
> > @@ -3442,7 +3452,7 @@ static void __meminit free_area_init_cor
> > if (!size)
> > continue;
> >
> > - se
On Thu, 15 Nov 2007 10:52:38 + [EMAIL PROTECTED] (Mel Gorman) wrote:
> > Shouldn't this have been HUGETLB_PAGE_ORDER?
> >
>
> As a #define, possibly but as a static inline - definitly not.
>
> In this context, the define is not used because set_pageblock_order()
> is a no-op when CONFIG_HUG
On (15/11/07 02:39), Andrew Morton didst pronounce:
> On Thu, 15 Nov 2007 10:13:22 + [EMAIL PROTECTED] (Mel Gorman) wrote:
>
> > This patch is a fix for 2.6.24.
> >
> > Ordinarily the size of a pageblock is determined at compile-time based on
> > the
> > hugepage size. On PPC64, the hugepage
On Thu, 15 Nov 2007 10:13:22 + [EMAIL PROTECTED] (Mel Gorman) wrote:
> This patch is a fix for 2.6.24.
>
> Ordinarily the size of a pageblock is determined at compile-time based on the
> hugepage size. On PPC64, the hugepage size is determined at runtime based on
> what is supported by the ma
(!size)
> continue;
>
> - set_pageblock_order(HUGETLB_PAGE_ORDER);
> + set_pageblock_order(pageblock_default_order());
> setup_usemap(pgdat, zone, size);
> ret = init_currently_empty_zone(zone, zone_start_pfn,
This patch is a fix for 2.6.24.
Ordinarily the size of a pageblock is determined at compile-time based on the
hugepage size. On PPC64, the hugepage size is determined at runtime based on
what is supported by the machine. With legacy machines such as iSeries that do
not support hugepages, HPAGE_SHI
Mel Gorman wrote:
On (25/04/07 08:08), Randy Dunlap didst pronounce:
On Tue, 24 Apr 2007 14:04:28 -0700 [EMAIL PROTECTED] wrote:
The patch titled
Handle kernelcore= boot parameter in common code to avoid boot problem on
IA64
has been added to the -mm tree. Its filename is
handle
On (25/04/07 08:08), Randy Dunlap didst pronounce:
> On Tue, 24 Apr 2007 14:04:28 -0700 [EMAIL PROTECTED] wrote:
>
> >
> > The patch titled
> > Handle kernelcore= boot parameter in common code to avoid boot problem
> > on IA64
> > has been add
On Tue, 24 Apr 2007 14:04:28 -0700 [EMAIL PROTECTED] wrote:
>
> The patch titled
> Handle kernelcore= boot parameter in common code to avoid boot problem
> on IA64
> has been added to the -mm tree. Its filename is
>
> handle-kernelcore=-boot-parameter-in-comm
On Tue, 24 Apr 2007 19:00:52 +0100 (IST) Mel Gorman <[EMAIL PROTECTED]> wrote:
>
> When "kernelcore" boot option is specified, kernel can't boot up on ia64
> because of an infinite loop. In addition, the parsing code can be handled
> in an architecture-independent manner.
>
> This patch patches
When "kernelcore" boot option is specified, kernel can't boot up on ia64
because of an infinite loop. In addition, the parsing code can be handled
in an architecture-independent manner.
This patch patches uses common code to handle the kernelcore= parameter.
It is only available to architectures
, if an invalid page is
passed to page_zone(), it can result in breakage on machines requiring
CONFIG_HOLES_IN_ZONE. This patch avoids the use of page_zone() and instead
checks the PFNs against the PFN ranges of the zone. This fixes a boot
problem on IA64 using the config arch/ia64/configs
Hi Kevin,
Thanks for your quick response. Here are my answers posted to the group:
> The 2.6.11 tree is a kernel.org tree?
Yes. I downloaded it from www.kernel.org/pub/linux/kernel/v2.6
> Are you using LVM or regular partitions?
Regular.
> Do you see the scsi driver find the disks?
Nope, that's
On 8/15/05, Srinivasan, Usha <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have been successfully running 2.6.11 under Red Hat RHEL4 environment
> with no problems at all. I needed to switch to 2.6.12 and chose
> 2.6.12.3. However, I am having problems booting 2.6.12.3. My SCSI HBAs
> & disks are n
Hello,
I have been successfully running 2.6.11 under Red Hat RHEL4 environment
with no problems at all. I needed to switch to 2.6.12 and chose
2.6.12.3. However, I am having problems booting 2.6.12.3. My SCSI HBAs
& disks are not being found at boot time and I see these errors during
boot:
Red
Brad Barnett wrote:
Hey,
I have a very odd problem with an Acer Aspire 1691WCLi. This laptop will
simply not boot with any Debian precompiled kernel, with the exception of
Debian's 2.4.27-2 initrd kernel. I have compiled my own kernels, using a
vast array of options, 2.6.11, 2.6.12, 2.6.12
On Fri, Jul 29, 2005 at 12:01:26PM -0500, Jesus Delgado wrote:
> Iam have is the same problems with emachines M6807.
> On 7/29/05, Brad Barnett <[EMAIL PROTECTED]> wrote:
> > I have a very odd problem with an Acer Aspire 1691WCLi. This laptop will
> > simply not boot with any Debian precompiled
Hi all:
Iam have is the same problems with emachines M6807.
Any Idea?
On 7/29/05, Brad Barnett <[EMAIL PROTECTED]> wrote:
>
>
>
> Hey,
>
> I have a very odd problem with an Acer Aspire 1691WCLi. This laptop will
> simply not boot with any Debian precompiled kernel, with the exception of
Hey,
I have a very odd problem with an Acer Aspire 1691WCLi. This laptop will
simply not boot with any Debian precompiled kernel, with the exception of
Debian's 2.4.27-2 initrd kernel. I have compiled my own kernels, using a
vast array of options, 2.6.11, 2.6.12, 2.6.12.3, 2.6.13-rc4 and 2.4
Hey,
I have a very odd problem with an Acer Aspire 1691WCLi. This laptop will
simply not boot with any Debian precompiled kernel, with the exception of
Debian's 2.4.27-2 initrd kernel. I have compiled my own kernels, using a
vast array of options, 2.6.11, 2.6.12, 2.6.12.3, 2.6.13-rc4 and 2.4
The problem is simple and I have it since 2.6.12 final (tested on 2.6.12,
2.6.12.2, 2.6.13-rc3). After grub stage2 (kernel image loaded) the system
freeze and I can only hit the three-finger-salute (ctrl+alt+del).
The system is:
Asus A8V Deluxe bios 1014.007 (tested with 1014.001 and 1013)
AMD A
The problem is simple and I have it since 2.6.12 final (tested on 2.6.12,
2.6.12.2, 2.6.13-rc3). After grub stage2 (kernel image loaded) the system
freeze and I can only hit the three-finger-salute (ctrl+alt+del).
The system is:
Asus A8V Deluxe bios 1014.007 (tested with 1014.001 and 1013)
AMD A
Thanks for tip and patch Michael.
Best regards / Grüße
--
Klaus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkm
[EMAIL PROTECTED] wrote:
>Dual P4 (Tyan S2662/I7505)
>
>Booting of 2.6.12-rc1-bk6 stops after these lines ..
>
>..
>Enabling IO-APIC IRQs
>.. TIMER; vector=0x31 oin1=2 pin2=-1
>checking TSC synchronization across 4 CPUs: passed
>Brought up 4 CPUs
>
>2.6.12-rc1 works.
>Please cc me, I am not subscr
Dual P4 (Tyan S2662/I7505)
Booting of 2.6.12-rc1-bk6 stops after these lines ..
..
Enabling IO-APIC IRQs
.. TIMER; vector=0x31 oin1=2 pin2=-1
checking TSC synchronization across 4 CPUs: passed
Brought up 4 CPUs
2.6.12-rc1 works.
Please cc me, I am not subscribed.
--
Klaus
-
To unsubscribe from
1 - 100 of 109 matches
Mail list logo
