Re: [PATCH] x86/i386: Check PSE bit before using PAGE_KERNEL_LARGE.

No, PAE kernels cannot boot on non-PAE hardware.

Konrad Rzeszutek Wilk <konrad.wilk <at> oracle.com> wrote:

>On Thu, May 31, 2012 at 01:21:02PM -0700, H. Peter Anvin wrote:
>> On 05/31/2012 12:40 PM, Konrad Rzeszutek Wilk wrote:
>> > During bootup we would unconditionally do this on any
>> > machine that was built with CONFIG_NUMA=y on i386:
>> > 
>> > setup_arch
>> >   \-initmem_init
>> >       \-x86_numa_init (with dummy_init as callback)
>> >           \- init_alloc_remap
>> >                \- set_pmd_pfn (with PAGE_PSE)
>> > 
>> > without checking to see if the CPU supports PSE. This
>> > patch adds that and also allows the init_alloc_remap function
>> > to properly work by falling back on PTEs.
>> > 
>> 
>> Well, the code looks like it is PAE-specific, and PAE implies PSE.
>
>I have to double check - but I think a kernel built with
>CONFIG_HIGHMEM64=y
>and CONFIG_NUMA=y would boot on a Pentium II which can't do PAE.
>
>But perhaps there are some other checks that would halt the kernel
>before it even got there?
>
>> 

Re: [Xen-devel] swap: don't do discard if no discard option added

On Tue, 29 May 2012, Konrad Rzeszutek Wilk wrote:
> 
> I think I know and just narrowed down the issue this Friday.
> 
> William, could you please apply the patch outlined in
> https://bugzilla.redhat.com/show_bug.cgi?id=824641
> to your dom0 and see if that (so do not have 052b198 in your branch)
> 
> > 
> > At present I see no connection (beyond the fact that the patch fixes
> > the symptom): in the absence of understanding, I have to beware that
> > the underlying issue may remain unfixed.
> 
> <nods>

Thanks a lot for pursuing that to a much more satisfying conclusion.

Hugh

Re: [PATCH 2/4] [RFC] Range tree implementation

On 05/31/2012 03:35 PM, Jan Kara wrote:
> On Thu 31-05-12 14:04:23, John Stultz wrote:
>> On 05/31/2012 01:48 PM, Jan Kara wrote:
>>> On Fri 25-05-12 12:17:34, John Stultz wrote:
>>>> I suspect range-tree isn't a totally accurate name, but I
>>>> couldn't quite make out the difference between range trees
>>>> and interval trees, so I just picked one to call it. Do
>>>> let me know if you have a better name.
>>>    Well, interval tree is a data structure for tracking a set of
>>> possibly overlapping intervals. Range tree is a data structure tracking
>>> points allowing for fast queries on a set of points contained in a given
>>> range (gets useful and interesting when dimension>   1). Your data structure
>>> is neither so it would be good to have a different name. OTOH there are so
>>> many data structures that it's hard to find a reasonable unused name ;)
>> Although I'm not sure your interval tree description doesn't match
>> what I'm trying to provide. Could you clarify why that doesn't
>> match?
>    Wikipedia has a good description of Interval trees:
>    http://en.wikipedia.org/wiki/Interval_tree
>
>    For example they are tertiary trees.
So roughly the naive approach listed in the wikipedia link is what I'm 
using here.
I'm fine renaming it to interval_tree, but if you really think it should 
be something else,  by all means let me know.

>>>> +
>>>> +/**
>>>> + * range_tree_add - Add a node to a range tree
>>>> + *  <at> root: range tree to be added to

Tracking down a compiler bug - any hints?

So I had a nicely working kernel at 3.3.0-rc6-next-20120305.

I got distracted for a while, so the next kernel I built was
3.4.0-next-20120523. This locked up on me good and solid when it tried to
launch X. No panic, no dmesg, nothing on netconsole, just a fast and deadly
freeze that required holding down the power button to clear.  Been there, done
that, time to break out the bisect.  'git bisect bad next-20120523', 'git
bisect good 3.3-rc6' and go to it. And I got like 8 bisects in a row that locked
up.  Even worse, all 95 or so commits that were left were included in
next-20120305.

Then I tried rebuilding next-20120305 using the exact same config I
had working (zcat /proc/config.gz > .config) - *THAT* kernel locked up.

This is when I noticed that my working kernel was compiled with gcc 4.6.2,
and all the busted ones were compiled with 4.7.0.  Backleveled to 4.6.2,
and both next-20120305 and next-20120523 build and boot just fine.

So obviously something is skunky with 4.7.0.  But where do I go from here?

(Side note - I'd love to get this resolved, as currently my laptop is in a semi-screwed
state due to RPM hell - backleveling gcc required backleveling glibc, and several
other packages, and some stuff is still busted because I didn't backlevel *them*.
It's amazing how many packages link against 'gmp' for no obvious reason :)

[PATCH v2 1/3] [RFC] Generic Red-Black Trees

Well, I'm running on 3.4 patched with this generic rb tree
implementation in the fair scheduler (although these are slightly
cleaned up, so I still need to boot this version to make sure there's no
last minute snafus).  So I finally settled on a mechanism for the
type-safety, even though it's a big macro (not my first choice), it's
the mechanism that works on all versions of gcc that still matter.

This is still preliminary.  I have a user-space test program (that just
compiles the rbtree.h in userspace) and a test module that I want to
refine to do profiling & stress tests so that performance can be easily
checked on various architectures & compilers.  So here's the outstanding
list:

* insert_near not finished (low priority)
* find_near not yet tested
* augmented not yet tested

[PATCH v2 2/3] [RFC] Generic Red-Black Trees

[PATCH v2 3/3] [RFC] Generic Red-Black Trees

I've put a few performance notes in comments.  Specifically, I'm curious
if an inline function that expands to 128+ bytes like this should
possibly be wrapped in an __attribute__((flatten))
__attribute__((noinline)) function to force full expansion in one place
and then prevent it from getting inlined elsewhere (to keep the
generated code size down).

[git pull] signal.git pile 2 (of 3, probably)

That one is just task_work_add() series + remaining prereqs for it.
There probably will be another pull request from that tree this
cycle - at least for helpers, to get them out of the way for per-arch
fixes remaining in the tree.  Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus

Shortlog:
Al Viro (4):
      TIF_NOTIFY_RESUME is defined on all targets now
      move key_repace_session_keyring() into tracehook_notify_resume()
      parisc: need to check NOTIFY_RESUME when exiting from syscall
      avr32: missed _TIF_NOTIFY_RESUME on one of do_notify_resume callers

Oleg Nesterov (5):
      task_work_add: generic process-context callbacks
      genirq: reimplement exit_irq_thread() hook via task_work_add()
      keys: change keyctl_session_to_parent() to use task_work_add()
      keys: kill the dummy key_replace_session_keyring()
      keys: kill task_struct->replacement_session_keyring

Diffstat:
 arch/alpha/kernel/signal.c       |    2 -
 arch/arm/kernel/signal.c         |    2 -
 arch/avr32/kernel/entry-avr32b.S |    2 +-
 arch/avr32/kernel/signal.c       |    2 -
 arch/blackfin/kernel/signal.c    |    2 -
 arch/c6x/kernel/signal.c         |    2 -
 arch/cris/kernel/ptrace.c        |    2 -
 arch/frv/kernel/signal.c         |    2 -
 arch/h8300/kernel/signal.c       |    2 -

[GIT PULL] fbdev updates for 3.5

Hi Linus,

please pull the changes below.

Thanks,

Florian Tobias Schandinat

The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:

  Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)

are available in the git repository at:

  git://github.com/schandinat/linux-2.6.git fbdev-updates-for-3.5

for you to fetch changes up to c895305e806b4346006d3cfba2b432d52268ecd3:

  video: bfin_adv7393fb: Fix cleanup code (2012-05-29 13:16:45 +0000)

----------------------------------------------------------------
fbdev updates for 3.5

It includes:
- driver for AUO-K1900 and AUO-K1901 epaper controller
- large updates for OMAP (e.g. decouple HDMI audio and video)
- some updates for Exynos and SH Mobile
- various other small fixes and cleanups

----------------------------------------------------------------

[PATCH] regmap: Fix the size calculation for map->format.buf_size

From: Fabio Estevam <fabio.estevam <at> freescale.com>

The word to be transmitted/received via regmap is composed by the following
parts:

config->reg_bits
config->val_bits
config->pad_bits

,so the total size should be calculated by summing up the number of bits of
each element and using a DIV_ROUND_UP to return the number of bytes.

Signed-off-by: Fabio Estevam <fabio.estevam <at> freescale.com>
---
 drivers/base/regmap/regmap.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 2aa076e..25c3d12 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
 <at>  <at>  -246,11 +246,11  <at>  <at>  struct regmap *regmap_init(struct device *dev,
 		map->lock = regmap_lock_mutex;
 		map->unlock = regmap_unlock_mutex;
 	}
-	map->format.buf_size = (config->reg_bits + config->val_bits) / 8;
 	map->format.reg_bytes = DIV_ROUND_UP(config->reg_bits, 8);
 	map->format.pad_bytes = config->pad_bits / 8;
 	map->format.val_bytes = DIV_ROUND_UP(config->val_bits, 8);
-	map->format.buf_size += map->format.pad_bytes;