linux.kernel Google Group

Re: [PATCH -tip] introduce sys_membarrier(): process-wide memory barrier (v9)

mi...@elte.hu (Ingo Molnar) — Tue, 16 Mar 2010 07:40:01 UT

How is it different from your syscall? I.e. which lines of code make the
difference? We could certainly apply the (trivial) barrier change to
context_switch().
Ingo

Re: [patch] x86: handle legacy PIC interrupts on all the cpu's

mi...@elte.hu (Ingo Molnar) — Tue, 16 Mar 2010 07:40:01 UT

Please submit the cleanup bit separately, we try to keep x86/urgent patches as
small as possible.
Thanks,
Ingo

Re: [PATCH] drivers/serial/sunsab.c: adjust the constant used to initialize the interrupt_mask0 fields

da...@davemloft.net (David Miller) — Tue, 16 Mar 2010 07:40:01 UT

Applied, thanks Julia.
I'll add some entries to MAINTAINERS so that you know to
CC: sparclinux for these sparc serial drivers in the future.

Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side

mi...@elte.hu (Ingo Molnar) — Tue, 16 Mar 2010 07:30:01 UT

The highest quality solution would be if KVM offered a 'guest extension' to
the guest kernel's /proc/kallsyms that made it easy for user-space to get this
information from an authorative source.
That's the main reason why the host side /proc/kallsyms is so popular and so
useful: while in theory it's mostly redundant information which can be gleaned

Re: [PATCH] trace power_frequency events on the correct cpu (for Intel x86 CPUs)

robert.scho...@tu-dresden.de (Robert Schöne) — Tue, 16 Mar 2010 07:20:04 UT

Am Montag, den 15.03.2010, 11:51 +0100 schrieb Thomas Renninger:
You are right, it should be in all cases, which execute a frequency change.
Yes
I don't know system io capable systems and what they are doing, so I ignored it to prevent reporting wrong "frequencies".
I stand corrected and appended the new patch (with an additional trace command for io capable systems)

Re: [RFC] remove implicit slab.h inclusion from percpu.h

adobri...@gmail.com (Alexey Dobriyan) — Tue, 16 Mar 2010 07:20:02 UT

This is done by compile testing, not by being smartass.

Re: [RFC] remove implicit slab.h inclusion from percpu.h

adobri...@gmail.com (Alexey Dobriyan) — Tue, 16 Mar 2010 07:20:02 UT

Because we want to #include less, not the same amount.
As a defensive measure, one can explicitly add slab.h to every file
which uses kmalloc/kfree.
But, who cares, since one still has to compile test regardless.

Re: [PATCH] r8169: Fix rtl8169_rx_interrupt()

eric.duma...@gmail.com (Eric Dumazet) — Tue, 16 Mar 2010 07:20:03 UT

Le mardi 16 mars 2010 à 08:50 +0200, Sergey Senozhatsky a écrit :
It's an old bug anyway, so you can pick up whats is the best for you.
My personal pref would be current kernel.
To trigger the original condition (fifo overflow), you might flood your
machine from another one with small packets, for example using pktgen.

Re: Will's kernel compilation error

mc...@orcon.net.nz (Michael Cree) — Tue, 16 Mar 2010 07:10:01 UT

As has been suggested your best bet for help is to post your .config.
If you don't want that publicly available then feel free to email it
privately to Matt and myself.
FWIW, I have two Hauppauge cards (PVR350 card and a Nova-T-500 DVB-T
card) in my Alpha, and have had no problems compiling the kernel, the

Re: [RFC] remove implicit slab.h inclusion from percpu.h

t...@kernel.org (Tejun Heo) — Tue, 16 Mar 2010 07:00:01 UT

Hello, Ingo.
I wanted to keep the discussion high level while giving a general idea
about the extent of necessary changes. I'll include the patch from
now on.
Sure.
I don't really get the 'experimental' part but if I count all the
files which ends up including percpu.h directly or indirectly on
allmodconfig it ends up including much more .c files than necessasry -

Re: [RFC] remove implicit slab.h inclusion from percpu.h

penb...@cs.helsinki.fi (Pekka Enberg) — Tue, 16 Mar 2010 07:00:02 UT

I am all for untangling the #include mess in slab.h and friends and I
think Ingo's suggestion is probably the best way forward. We should
avoid creating tree-wide breakage for this kind of cleanups.
Pekka

Re: Possible bug in eeepc-laptop.c - EeePC 900

corentin.ch...@gmail.com (Corentin Chary) — Tue, 16 Mar 2010 07:00:01 UT

Here is what I can read in your DSDT:
When INIT or _Q31 is called, the bios check the the battery is
present, and call FSBA(0) or FSBA(1).
_Q31 seems to be called by an hotkey, could you run "acpi_listen" and
search the hotkey that generate 0x50 or 0x51 ?
FSBA is the method called by CFVS. When you do "echo 1 > cpufv" it

Re: [PATCH] KVM MMU: check reserved bits only if CR4.PSE=1 or CR4.PAE=1

xiaoguangr...@cn.fujitsu.com (Xiao Guangrong) — Tue, 16 Mar 2010 07:00:01 UT

Quote AMD's specification:
The size of large pages in PAE-paging mode is 2 Mbytes rather than 4 Mbytes. PAE uses
the pagedirectory page-size bit (PDE.PS) to allow selection between 4-Kbyte and 2-Mbyte
page sizes. PAE automatically uses the page-size bit, so the value of CR4.PSE is ignored
by PAE paging.

Re: [rfc][patch] mm: lockdep page lock

npig...@suse.de (Nick Piggin) — Tue, 16 Mar 2010 06:50:02 UT

Not yet. Although I only did basic stress testing with tmpfs and ext3 so
far. It would get even further useful for fs developers combined with
annotating more bit locks like buffer lock.
BTW. I tried adding a might_fault() under page lock to see the infamous
old page_lock -> mmap_sem deadlock, but it didn't warn. Explicitly doing

Re: [PATCH] r8169: Fix rtl8169_rx_interrupt()

sergey.senozhat...@gmail.com (Sergey Senozhatsky) — Tue, 16 Mar 2010 06:50:02 UT

Hello,
Sure. Give me a couple of days. By the way, should I test against .34
or .33?
Sergey