twitter: linux.kernel - 26 new messages in 19 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* mmc: add module parameter to set whether cards are assumed removable - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a705788681739db0?hl=en
* pty performance problem - 4 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/3571c2f820f52980?hl=en
* writeback: Fix missing kernel-doc notation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a797cd6e5be45438?hl=en
* MIPS: Add a high resolution sched_clock() via cnt32_to_63(). - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/ffa03d318b75462b?hl=en
* ieee80211_tx_status: headroom too small - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8fc413533e92a62f?hl=en
* XD/smartmedia - how to implement it right? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6f53dbadce197305?hl=en
* perf: use default compiler mode by default - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1e5e77593be8c19c?hl=en
* x86: crash kernel reserve with reserve_early - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/07356dbd4327d0dd?hl=en
* perf tools: support static build - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a55d7d59edac138b?hl=en
* sched: add the other missing clock update to migrate_task() - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/829c37e694b39911?hl=en
* sched: improve tick time missed wakeup preempt protection - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/7e93faab55eb0262?hl=en
* perf: suggest static libraries as well - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d09335c1800f1f08?hl=en
* mtd: fix mtd_blkdevs problem with caches on some architectures (2.6.31) - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/17808090887d3de0?hl=en
* set_all_monitor_traces() sleeping bug. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/20d077d3639f0646?hl=en
* Null suspend/resume functions - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a52bf40ee8d6d8b7?hl=en
* 2.6.32-rc7: compile regression on spitz - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c00704faa39e5fb1?hl=en
* Disassociating atheros wlan - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7eba6baddc3fd85f?hl=en
* e1000e: Use sizeof struct rather than pointer in e1000_get_eeprom() - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/4c8c3d1a4680b689?hl=en
* Interrupts enabled after irqrouter_resume - iMac9,1 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/26aab660ebc955a6?hl=en

==============================================================================
TOPIC: mmc: add module parameter to set whether cards are assumed removable
http://groups.google.com/group/linux.kernel/t/a705788681739db0?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Nov 22 2009 4:30 am
From: Wouter van Heyst

On Mon, Nov 16, 2009 at 10:31:49PM +0000, Ben Hutchings wrote:
> On Mon, 2009-11-16 at 12:23 -0800, Andrew Morton wrote:
> > On Wed, 11 Nov 2009 04:44:36 +0000
> > Ben Hutchings <ben@decadent.org.uk> wrote:
> >
> > > Some people run general-purpose distribution kernels on netbooks with
> > > a card that is physically non-removable or logically non-removable
> > > (e.g. used for /home) and cannot be cleanly unmounted during suspend.
> > > Add a module parameter to set whether cards are assumed removable or
> > > non-removable, with the default set by CONFIG_MMC_UNSAFE_RESUME.
> > >
> >
> > The description really doesn't give me enough info to work out what's
> > happening here and why this is being proposed. But it smells nasty.
>
> In general, it is not possible to tell whether a card present in an MMC
> slot after resume is the same that was there before suspend. So there
> are two possible behaviours, each of which will cause data loss in some
> cases:
>
> CONFIG_MMC_UNSAFE_RESUME=n (default): Cards are assumed to be removed
> during suspend. Any filesystem on them must be unmounted before
> suspend; otherwise, buffered writes will be lost.
>
> CONFIG_MMC_UNSAFE_RESUME=y: Cards are assumed to remain present during
> suspend. They must not be swapped during suspend; otherwise, buffered
> writes will be flushed to the wrong card.
>
> Currently the choice is made at compile time and this allows that to be
> overridden at module load time.

I'm running 2.6.32-rc7 with this patch applied and CONFIG_MMC_UNSAFE_RESUME=y
That works as desired for my non-removable case. Is it desired that I
test if 'removable=1' will thrash my filesystem?

Wouter van Heyst
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Sun, Nov 22 2009 4:40 am
From: Ben Hutchings

On Sun, 2009-11-22 at 12:42 +0100, Wouter van Heyst wrote:
> On Mon, Nov 16, 2009 at 10:31:49PM +0000, Ben Hutchings wrote:
[...]
> > In general, it is not possible to tell whether a card present in an MMC
> > slot after resume is the same that was there before suspend. So there
> > are two possible behaviours, each of which will cause data loss in some
> > cases:
> >
> > CONFIG_MMC_UNSAFE_RESUME=n (default): Cards are assumed to be removed
> > during suspend. Any filesystem on them must be unmounted before
> > suspend; otherwise, buffered writes will be lost.
> >
> > CONFIG_MMC_UNSAFE_RESUME=y: Cards are assumed to remain present during
> > suspend. They must not be swapped during suspend; otherwise, buffered
> > writes will be flushed to the wrong card.
> >
> > Currently the choice is made at compile time and this allows that to be
> > overridden at module load time.
>
> I'm running 2.6.32-rc7 with this patch applied and CONFIG_MMC_UNSAFE_RESUME=y
> That works as desired for my non-removable case. Is it desired that I
> test if 'removable=1' will thrash my filesystem?

Please test with CONFIG_MMC_UNSAFE_RESUME=n (which Debian will continue
to use) and removable=0.

Ben.

--
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.

==============================================================================
TOPIC: pty performance problem
http://groups.google.com/group/linux.kernel/t/3571c2f820f52980?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Nov 22 2009 4:30 am
From: Alan Cox

On Sun, 22 Nov 2009 07:39:26 +0100
Ingo Molnar <mingo@elte.hu> wrote:

>
> (Cc:-ed Alan and Linus - mail repeated below. eot.)

I saw it and replied already. The kernel now queues the work for the pty
as it does normal tty devices. If the CPU load is that low and nothing
else is happening it makes me wonder what the scheduler thinks it is
doing ?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 4 ==
Date: Sun, Nov 22 2009 4:30 am
From: Alan Cox

> While I could rewrite the communications to optionally use pipes, or
> get the client to reprocess a log file locally, what I have does seem
> a reasonable use of ptys.

Wouldn't argue with that. The tty layer queues the characters which then
get processed but at the moment get processed after the next timer tick
not when the CPU is idle. That wants changing and it strikes me as utterly
dumb in general to be deferring work when the CPU is idle.

Alan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 4 ==
Date: Sun, Nov 22 2009 4:50 am
From: Mike Galbraith

On Sun, 2009-11-22 at 12:29 +0000, Alan Cox wrote:
> > While I could rewrite the communications to optionally use pipes, or
> > get the client to reprocess a log file locally, what I have does seem
> > a reasonable use of ptys.
>
> Wouldn't argue with that. The tty layer queues the characters which then
> get processed but at the moment get processed after the next timer tick
> not when the CPU is idle. That wants changing and it strikes me as utterly
> dumb in general to be deferring work when the CPU is idle.

*blink*, up to 10 ms thumb twiddling session?

I wouldn't mind having a copy of the stripped down test proggy.

-Mike

== 4 of 4 ==
Date: Sun, Nov 22 2009 4:50 am
From: Ingo Molnar

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Sun, 22 Nov 2009 07:39:26 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
>
> >
> > (Cc:-ed Alan and Linus - mail repeated below. eot.)
>
> I saw it and replied already. The kernel now queues the work for the
> pty as it does normal tty devices. If the CPU load is that low and
> nothing else is happening it makes me wonder what the scheduler thinks
> it is doing ?

Would be nice to see the testcase, but by the looks if it there appears
to be a jiffy delay somewhere - not a scheduler delay. On an idle box
the scheduler will run any runnable tasks, with no delay.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: writeback: Fix missing kernel-doc notation
http://groups.google.com/group/linux.kernel/t/a797cd6e5be45438?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Nov 22 2009 4:40 am
From: Wu Fengguang

Acked-by: Wu Fengguang <fengguang.wu@intel.com>

Thanks!

On Sun, Nov 22, 2009 at 04:16:09PM +0800, Jaswinder Singh Rajput wrote:
>
> Fix the following htmldocs warning:
>
> Warning(fs/fs-writeback.c:255): No description found for parameter 'sb'
>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> Cc: Wu Fengguang <fengguang.wu@intel.com>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Jens Axboe <jens.axboe@oracle.com>
> Cc: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> fs/fs-writeback.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index 9d5360c..b15c97f 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -242,6 +242,7 @@ static void bdi_sync_writeback(struct backing_dev_info *bdi,
> /**
> * bdi_start_writeback - start writeback
> * @bdi: the backing device to write from
> + * @sb: write inodes from this super_block
> * @nr_pages: the number of pages to write
> *
> * Description:
> --
> 1.6.5.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: MIPS: Add a high resolution sched_clock() via cnt32_to_63().
http://groups.google.com/group/linux.kernel/t/ffa03d318b75462b?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Nov 22 2009 4:40 am
From: Ralf Baechle

On Sun, Nov 22, 2009 at 07:08:05PM +0800, Wu Zhangjin wrote:

> > > + data = (0xffffffffUL / tclk / 2 - 2) * HZ;
>
> Because the MIPS c0 count's frequency is half of the cpu frequency(Hi,
> Ralf, does every MIPS c0 count meet this feature?), so, the above line
> should be:

There are processors which have no cp0 counter at all; these are mostly
very old pre-R4000 era 32-bit MIPS I and MIPS II cores.

Of those which have a cp0 counter most will clock it at "half the maximum
instruction issue rate" and a few at the full rate. Finally for a few
such as the RM52xx either half or the full count the rate is selectable by
the reset initialization bitstream fed into the processor. Too make this
feature suck nicely there is no way for software to find out which rate
was selected so software must know that or calibrate against a timer of
known frequency.

Platform-specific code does this by setting mips_hpt_frequency to the
count rate before calling init_r4k_clocksource; it's also the value being
passed into setup_sched_clock_update() so you don't need to count for the
half / full clock rate thing there.

I don't see why you need the -2 in your formula so the whole thing can
be simplified to:

data = 0x80000000 / tclk * HZ;

Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Sun, Nov 22 2009 5:20 am
From: Wu Zhangjin

On Sun, 2009-11-22 at 12:35 +0000, Ralf Baechle wrote:
> On Sun, Nov 22, 2009 at 07:08:05PM +0800, Wu Zhangjin wrote:
>
> > > > + data = (0xffffffffUL / tclk / 2 - 2) * HZ;
> >
> > Because the MIPS c0 count's frequency is half of the cpu frequency(Hi,
> > Ralf, does every MIPS c0 count meet this feature?), so, the above line
> > should be:
>
> There are processors which have no cp0 counter at all; these are mostly
> very old pre-R4000 era 32-bit MIPS I and MIPS II cores.
>
> Of those which have a cp0 counter most will clock it at "half the maximum
> instruction issue rate" and a few at the full rate. Finally for a few
> such as the RM52xx either half or the full count the rate is selectable by
> the reset initialization bitstream fed into the processor. Too make this
> feature suck nicely there is no way for software to find out which rate
> was selected so software must know that or calibrate against a timer of
> known frequency.
>
> Platform-specific code does this by setting mips_hpt_frequency to the
> count rate before calling init_r4k_clocksource; it's also the value being
> passed into setup_sched_clock_update() so you don't need to count for the
> half / full clock rate thing there.
>
> I don't see why you need the -2 in your formula so the whole thing can
> be simplified to:
>
> data = 0x80000000 / tclk * HZ;
>

Sorry, I have mixed the mips_hpt_frequency with the cpu frequency,
mips_hpt_frequency is exactly the frequency of the timer. so, there is
no need to consider the relation between it and the cpu frequency here.
therefore, my old formula should be okay, that -2 is used to ensure data
is smaller than half of the period of the timer.

Best Regards,
Wu Zhangjin

==============================================================================
TOPIC: ieee80211_tx_status: headroom too small
http://groups.google.com/group/linux.kernel/t/8fc413533e92a62f?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Nov 22 2009 4:50 am
From: Gertjan van Wingerde

On 11/22/09 08:09, David Ellingsworth wrote:
> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
> <gwingerde@gmail.com> wrote:
>> On 11/21/09 02:30, David Ellingsworth wrote:
>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>> kernel built from the wireless-testing repository I'm getting a number
>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>> access point. The relevant information about my card from lspci is:
>>>
>>> 01:08.0 0280: 1814:0301
>>> Subsystem: 1458:e934
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> Latency: 64, Cache Line Size: 128 bytes
>>> Interrupt: pin A routed to IRQ 18
>>> Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>> Capabilities: [40] Power Management version 2
>>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>> Kernel driver in use: rt61pci
>>>
>>> If you need any other information, I'll be happy to provide it.
>>>
>>
>> Hi David,
>>
>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>> copying to the monitor interface.
>>
>> Can you check whether the attached patch fixes the issue for you?
>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>
>
> Gertjan,
>
> I haven't really been able to test this. The kernel version I was
> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
> certain the patch will resolve the issue, but I've been unable to get
> my wireless card to function properly with the latest 2.6.32-rc8-wl
> master branch. I'm not entirely sure what changed since two days ago,
> but I know the following:
>
> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
> this issue. However, this patch will not apply on top of 2.6.32-rc8.
>
> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
> above mentioned error. Unable to test patch since I pulled all the
> recent modifications down.
> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
>
> I'm not entirely sure what the differences are between Linus' master
> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
> changes have been made on the wireless-testing master branch in the
> last couple of days that are preventing me from fully testing this
> patch.
>
> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
> and without the patch I can associate and authenticate with my AP but
> am unable to do anything else. Any attempt to establish a wireless
> connection thus dies while trying to obtain an ip address via DHCP.
> Sadly, no errors are logged indicating what the cause of this problem
> might be. Given that I've only seen these errors after establishing a
> wireless connection, it's a little difficult for me to test without
> being able to transmit any data.
>
> I don't know if it's worth the effort or not, but if this patch were
> re-based against Linus' master branch I might be able to test it since
> my AP at least works with 2.6.32-rc8.

David,

OK. Find attached the patch ported to Linus' tree. It should apply to
any version of Linus' tree after 2.6.32-rc8.
I think it is good to get real confirmation that the patch behaves
as expected.

---
Gertjan.

==============================================================================
TOPIC: XD/smartmedia - how to implement it right?
http://groups.google.com/group/linux.kernel/t/6f53dbadce197305?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Nov 22 2009 5:00 am
From: Maxim Levitsky

On Sat, 2009-11-21 at 11:25 +0100, Jörn Engel wrote:
> On Sat, 21 November 2009 02:25:44 +0200, Maxim Levitsky wrote:
> >
> > This thread is meant to continue discussion about XD/smartmedia support
> > in linux.
> >
> > I CC'd few peoples that participated in original discussion.
> >
> > Alex Dubov attempted to write a driver for jmicron device (I have it
> > btw), but this was rejected due to code duplication.
> >
> > I successfully reverse engineered (in my free time) the XD card reader
> > found on my laptop (ricoh based one)
> >
> > I would like to know how you think to implement the subsystem support
> > right.
> >
> > I would go with mmc subsystem + FTL, but according to original thread,
> > there are numerous problems with this approach.
> >
> > Any advice is appreciated.
>
> A novel approach might be to just send the code as a patch. Last time
> around noone seemed to have had a real look.
>
> The "mtd uses blocking calls" argument I can help with. For some other
> project I've added non-blocking calls to mtd[1].
>
> Biggest problems I see are a) the userspace interface and b) allowing
> both raw flash access through MTD and block device access with an FTL.
>
> [1] http://lists.infradead.org/pipermail/linux-mtd/2009-November/028065.html
>
> Jörn

I don't have much to say right now, I will study the sources for a
while, and then continue the effort.

Best regards,
Maxim Levitsky

==============================================================================
TOPIC: perf: use default compiler mode by default
http://groups.google.com/group/linux.kernel/t/1e5e77593be8c19c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Nov 22 2009 5:00 am
From: Ingo Molnar

* Michael S. Tsirkin <mst@redhat.com> wrote:

> gcc with no flags typically is a sane default for systems to use, and
> looking at the running kernel is probably broken for cross-builds
> anyway, so let's not do this. Add EXTRA_CFLAGS so that users can
> override default gcc mode if they want to.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> tools/perf/Makefile | 20 +++-----------------
> 1 files changed, 3 insertions(+), 17 deletions(-)
>
> diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> index d0bdaf2..ab35b0f 100644
> --- a/tools/perf/Makefile
> +++ b/tools/perf/Makefile
> @@ -148,6 +148,8 @@ all::
> # broken, or spawning external process is slower than built-in grep perf has).
> #
> # Define LDFLAGS=-static to build a static binary.
> +#
> +# Define EXTRA_CFLAGS=-m64 or EXTRA_CFLAGS=-m32 as appropriate for cross-builds.
>
> PERF-VERSION-FILE: .FORCE-PERF-VERSION-FILE
> @$(SHELL_PATH) util/PERF-VERSION-GEN
> @@ -160,22 +162,6 @@ uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
> uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
> uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
>
> -#
> -# Add -m32 for cross-builds:
> -#
> -ifdef NO_64BIT
> - MBITS := -m32
> -else
> - #
> - # If we're on a 64-bit kernel (except ia64), use -m64:
> - #
> - ifneq ($(uname_M),ia64)
> - ifneq ($(patsubst %64,%,$(uname_M)),$(uname_M))
> - MBITS := -m64
> - endif
> - endif
> -endif

iirc PowerPC had some trouble in this area. Paulus?

==============================================================================
TOPIC: x86: crash kernel reserve with reserve_early
http://groups.google.com/group/linux.kernel/t/07356dbd4327d0dd?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Nov 22 2009 5:00 am
From: ebiederm@xmission.com (Eric W. Biederman)

Yinghai Lu <yhlu.kernel@gmail.com> writes:

> [PATCH] x86: crash kernel reserve with reserve_early
>
> use find_e820_area/reserve_early instead.
> will get next good one automatically with alignment

Semantically this is broken, as you are now ignoring a passed in
base address if one is supplied. What problem are you trying to fix?

Eric

>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> ---
> arch/x86/kernel/setup.c | 60 ++++++++++--------------------------------------
> 1 file changed, 13 insertions(+), 47 deletions(-)
>
> Index: linux-2.6/arch/x86/kernel/setup.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/kernel/setup.c
> +++ linux-2.6/arch/x86/kernel/setup.c
> @@ -488,42 +488,11 @@ static void __init reserve_early_setup_d
>
> #ifdef CONFIG_KEXEC
>
> -/**
> - * Reserve @size bytes of crashkernel memory at any suitable offset.
> - *
> - * @size: Size of the crashkernel memory to reserve.
> - * Returns the base address on success, and -1ULL on failure.
> - */
> -static
> -unsigned long long __init find_and_reserve_crashkernel(unsigned long long size)
> -{
> - const unsigned long long alignment = 16<<20; /* 16M */
> - unsigned long long start = 0LL;
> -
> - while (1) {
> - int ret;
> -
> - start = find_e820_area(start, ULONG_MAX, size, alignment);
> - if (start == -1ULL)
> - return start;
> -
> - /* try to reserve it */
> - ret = reserve_bootmem_generic(start, size, BOOTMEM_EXCLUSIVE);
> - if (ret >= 0)
> - return start;
> -
> - start += alignment;
> - }
> -}
> -
> static inline unsigned long long get_total_mem(void)
> {
> unsigned long long total;
>
> - total = max_low_pfn - min_low_pfn;
> -#ifdef CONFIG_HIGHMEM
> - total += highend_pfn - highstart_pfn;
> -

twitter

Sunday, November 22, 2009

linux.kernel - 26 new messages in 19 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts