There is nothing inherent in HIGHMEM64G required for CONFIG_NUMA to work. It
just limits potential testing coverage so remove the limitation.
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -rup -X
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be lifted.
The following two patches remove the restrictions on pagetable layout and
Other means of communications include sysfs and procfs. These have the
advantage of supporting scripting and can survive ABI changes that can plague
the other interfaces; but are meant for low-bandwidth or out-of-band
configuration or simple status reporting.
Sincerely -- Mark Salyzyn
>
On Fri, 18 Jan 2008, Theodore Tso wrote:
> On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
>> But I heard some years ago from a disk drive engineer that that is a myth
>> just like the rotational energy thing. I added that to the discussion,
>> but admitted that I haven't
Bryan Henderson wrote:
We weren't actually talking about writing out the cache. While that was
part of an earlier thread which ultimately conceded that disk drives most
probably do not use the spinning disk energy to write out the cache, the
claim was then made that the drive at least
Tetsuo Handa wrote:
> checkpatch.pl was unable to handle \\ within quoted string.
Sorry, I didn't know checkpatch 0.13 is available.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 2008-01-18 at 22:54 +0800, huang ying wrote:
> On Jan 18, 2008 4:48 PM, Ian Campbell <[EMAIL PROTECTED]> wrote:
> > On Tue, 2008-01-15 at 13:45 +0800, Huang, Ying wrote:
> > > +void __init bt_ioremap_init(void)
> > > +{
> > > [...]
> > > + *pgd = __pa(bm_pte) | _PAGE_TABLE;
> > > +}
>
Hi Paul,
> Query for Cliff:
> 1) Can we narrow the scope of callback_mutex in scan_for_empty_cpusets()?
> 2) Can we avoid rewriting the cpus, mems of cpusets except when it is
>likely that we'll be changing them?
> 3) Should not remove_tasks_in_empty_cpuset() also check for empty mems?
>
I'm porting kernel 2.6.22.6 on custom embedded system (ARM1136).
During network subsystem initialization, kernel hangs in function
synchronize_rcu invoked by synchronize_net. In particular
wait_for_completion();
never returns and wakeme_after_rcu is never hit.
Anybody can give me any advice
[EMAIL PROTECTED] wrote:
Giacomo Catenazzi wrote:
const No writes through this lvalue. In the absence of this qualifier, writes
may occur
through this lvalue.
volatile No cacheing through this lvalue: each operation in the abstract
semantics must
be performed (that is, no cacheing
huang ying wrote:
If CONFIG_X86_PAE is defined, the set_pte, clear_pte etc will operate
3-level page tables, while on i386, the early page table is always
2-level, so set_pte, clear_pte etc functions can not be used here. The
boot_ioremap use a trick to deal with this problem. The
> > + /*
> > +* Did it hit the DOS screen memory VA from vm86 mode?
> > +*/
> > + if (v8086_mode(regs)) {
> > + unsigned long bit = (address - 0xA) >> PAGE_SHIFT;
> > + if (bit < 32)
> > + tsk->thread.screen_bitmap |= 1 << bit;
> > + }
this
On Fri, 2008-01-18 at 16:20 +0900, Tejun Heo wrote:
> aha152x.c and fdomain are built twice - once for the isa driver and
> once for the PCMCIA one. Through #ifdefs, the compiled codes are
> slightly different; thus, global symbols need to be given different
> names depending on which flavor is
On Fri, 18 Jan 2008, mokhtar wrote:
>
> Hi
>
> What are the different solution to make a user process communicate with a
> kernel modules?
>
> Whatis the the advantages and disadvanteges of each solutions ?
>
ioctl() is the universal Unix mechanism for control of drivers
(modules). open(),
On Jan 18, 2008 4:48 PM, Ian Campbell <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-15 at 13:45 +0800, Huang, Ying wrote:
> > +void __init bt_ioremap_init(void)
> > +{
> > [...]
> > + *pgd = __pa(bm_pte) | _PAGE_TABLE;
> > +}
> > [...]
> > +static void __init __bt_set_fixmap(enum
Steven Rostedt wrote:
...
> @@ -978,7 +980,13 @@ void release_console_sem(void)
> console_locked = 0;
> up(_sem);
Hmm, just looking at this fragment: Doesn't up() include the risk of
running onto the runqueue lock as well?
> spin_unlock_irqrestore(_lock, flags);
> - if
On Fri, Jan 18, 2008 at 02:31:16PM +0100, Björn Steinbrink wrote:
...
>
> Do you see anything that casts the const away? No? Me neither. Still,
> the memory that p points to was changed, because there was another
> pointer and that was not const.
*another* being key here.
>
> > *That* is the
From: David Brownell <[EMAIL PROTECTED]>
On the sam9 EK boards, the LCD backlight is hooked up to a PWM output
from the LCD controller. It's controlled by "contrast" registers though.
This patch lets boards declare that they have that kind of backlight
control. The driver can then export this
At Fri, 18 Jan 2008 15:10:08 +0100,
Rafael J. Wysocki wrote:
>
> On Friday, 18 of January 2008, Linus Torvalds wrote:
> >
> > On Thu, 17 Jan 2008, Andrew Morton wrote:
> > >
> > > > Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always
> > > > work on Lenovo X60s
> > > >
On 2.6.24-rc8-mm1:
uml:~# grep arch_dup_mmap /proc/slab_allocators
size-32: 10861 arch_dup_mmap+0x9f/0x130
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, Jan 18, 2008 at 12:47:01PM +0100, Giacomo A. Catenazzi wrote:
...
> "restrict" exists for this reason. const is only about lvalue.
You think that I try to put more meaning into const than I do - but I don't.
Please read what I wrote, not what you want to think I wrote.
I agree that if I
Add new card (0x1393:0x1143) support added in 1.11 original driver, also
allow rate change in set_serial_info ioctl (as per 1.11 too).
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
drivers/char/mxser.c | 29 +++--
1 files changed, 19 insertions(+), 10 deletions(-)
- remove dead MOXA_GET_CONF (always returned -ENXIO)
- remove useless MOXA_GET_CUMAJOR (unused)
- use get/put_user instead of copy_from/to_user for simple types
- cleanup TIOCMIWAIT -- return -ERESTARTSYS on signal, move condition into
separate function
Signed-off-by: Jiri Slaby <[EMAIL
Initialize temp structure directly with proper values without first zeroing
it and setting later as suggested by Jan.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Cc: Jan Engelhardt <[EMAIL PROTECTED]>
---
drivers/char/mxser_new.c | 27 ---
1 files changed, 12
On Friday, 18 of January 2008, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > > > Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts
> > > > > don't always work on Lenovo X60s
> > > > > Submitter : Roland Dreier <[EMAIL PROTECTED]>
> > > > > Date
Reorder fields to save some memory and code on 64bit due to alignment as
suggested by Jan.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Cc: Jan Engelhardt <[EMAIL PROTECTED]>
---
drivers/char/mxser_new.c | 60 +++---
1 files changed, 30 insertions(+),
Don't test a pointer against 0. Use NULL instead.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
drivers/char/mxser_new.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/mxser_new.c b/drivers/char/mxser_new.c
index 0b25457..d2dcc54 100644
---
Let the special baudrate processing on the tty layer. Also remove
set/get_special_rate ioctls introduced in commit
f64c84a1668930d1ca2b7dbaa92146c2139cb508, since it is no longer needed.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
---
drivers/char/mxser_new.c |
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
> But I heard some years ago from a disk drive engineer that that is a myth
> just like the rotational energy thing. I added that to the discussion,
> but admitted that I haven't actually seen a disk drive write a partial
>
On Friday, 18 of January 2008, Ingo Molnar wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > (it doesnt matter if graphics does not resume fine - at least for my
> > > tests)
> > >
> > > kprobes had similar problems and it now has a few simple smoke-tests
> > > - which i just saw
On Fri, Jan 18, 2008 at 08:56:43AM -0500, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >>Simulators can be fixed,
> >
> >They could, but why? I don't know of a good reason to require CLFLUSH.
>
> Well, simulators are generally expected to follow the architecture, not
> vice versa. I would tend
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > > > Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always
> > > > work on Lenovo X60s
> > > > Submitter : Roland Dreier <[EMAIL PROTECTED]>
> > > > Date: 2007-11-08 14:55
> > > > References :
On 18-01-08 14:37, David Newall wrote:
The problem is that _p is widely used for non-ISA devices.
Yes, we know, it's being fixed. Piss off.
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Friday, 18 of January 2008, Linus Torvalds wrote:
>
> On Thu, 17 Jan 2008, Andrew Morton wrote:
> >
> > There are thirteen regressions for which we have patches but they aren't
> > merged. That seems rather high.
>
> I think a number of them have been merged, or the thing that caused them
On Fri, 2008-01-18 at 14:57 +0100, Ingo Molnar wrote:
> [ Sidenote: "too small" and "too insignificant" is not a patch attribute
> that is in my vocabulary - by definition the best patches are very
> small and very insignificant (they just happen to end up doing
> something cool a 1000
Andi Kleen wrote:
Simulators can be fixed,
They could, but why? I don't know of a good reason to require CLFLUSH.
Well, simulators are generally expected to follow the architecture, not
vice versa. I would tend to agree with the coupling that recent
versions of Bochs appeared to have made
* Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > - return pte_val(pte) >> PAGE_SHIFT;
> > + return (pte_val(pte) >> PAGE_SHIFT) & ~_PAGE_NX;
> Shouldn't that be
>
> return (pte_val(pte) & ~_PAGE_NX) >> PAGE_SHIFT;
ouch! Sharp eyes! Fixed it.
Ingo
--
To unsubscribe from this
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> > I can propose a corresponding patch, and I'd suggest to make
> > CONFIG_PCSPEAKER depend on CONFIG_EMBEDDED.
>
> No, don't. It's fine the way it is. If INPUT_PCSPKR isn't set, we
> don't support the speaker, end of story.
yeah.
> Also, bear in
On Thu, 2008-01-17 at 21:08 -0800, Andrew Morton wrote:
> On Thu, 17 Jan 2008 19:29:18 -0600 Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> >
> > On Thu, 2008-01-17 at 15:10 -0600, Matt Mackall wrote:
> > > On Thu, 2008-01-17 at 02:35 -0800, Andrew Morton wrote:
> > > >
Giacomo Catenazzi wrote:
And to demostrate that Linus is not the only person
with this view, I copy some paragraphs from C99 rationale
(you can find standard, rationale and other documents
in http://clc-wiki.net/wiki/C_standardisation:ISO )
Page 75 of C99 rationale:
Type qualifiers were
On Tue, 15 Jan 2008, Jeremy Fitzhardinge wrote:
> In 32-bit PAE, mask NX from pte_pfn, since it isn't part of the PFN.
> This code is due for unification anyway, but this fixes a latent bug.
>
> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>
> ---
> include/asm-x86/pgtable-3level.h |
On Thu, 2008-01-17 at 16:18 -0800, Linus Torvalds wrote:
>
> On Thu, 17 Jan 2008, Andrew Morton wrote:
> >
> > There are thirteen regressions for which we have patches but they aren't
> > merged. That seems rather high.
>
> I think a number of them have been merged, or the thing that caused
Giacomo Catenazzi wrote:
And to demostrate that Linus is not the only person
with this view, I copy some paragraphs from C99 rationale
(you can find standard, rationale and other documents
in http://clc-wiki.net/wiki/C_standardisation:ISO )
Page 75 of C99 rationale:
Type qualifiers were
On Fri, 2008-01-18 at 14:03 +0100, Michael Opdenacker wrote:
> However, wouldn't the Makefile look nicer if we introduced a
> CONFIG_PCSPEAKER setting as in the mips platform? We would just have:
>
> obj-$(CONFIG_PCSPEAKER) += pcspeaker.o
Yes, that would be cleaner. Not worth it
Hello,
Maybe I missed it but I'm wondering why GIT is not used for
the RT development ? I can't find a rt tree anywhere and all
new rt release spoke about a patchset to apply on mainline
kernels.
Another question, is there a TODO list somewhere which would
help to port the RT patch to a new
Hi,
I just came across a strange behavior of epoll that seems to
contradict the documentation. Here is what happens:
* I have two processes P1 and P2, P1 accept()s connections, and send the
resulting file descriptors to P2 through a unix socket.
* P2 registers the received socket in his
From: Robert Olsson <[EMAIL PROTECTED]>
Date: Fri, 18 Jan 2008 14:00:57 +0100
> I don't understand the idea with semaphore for enabling/disabling
> irq's either the overall logic must safer/better without it.
They must have had code paths where they didn't know if IRQs were
enabled or not
Rene,
Here is why you shouldn't leap so quickly to rudeness. Everything is
being repeated over and over and over again (as you put it) because
people like you shout down people like me without making any apparent
effort to understand the truth of the problem.
Rene Herman wrote:
> We've already
Mark Hansen wrote:
Hello,
Firstly, may I apologise as I am not a member of the LKML, and ask that
I be CC'd in any responses that may be forthcoming.
My question concerns the following patch which was incorporated into the
2.6.22 kernel (quoted from that change log):
Today, all threads
On Thursday, 17 of January 2008, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/
>
> - selinux is busted on one of my two selinux-enabled test machines.
>
> - suspend-to-ram and suspend-to-disk are totally hosed on one of my test
On 2008.01.18 10:48:26 +0100, Jakob Oestergaard wrote:
> On Thu, Jan 17, 2008 at 01:25:39PM -0800, Linus Torvalds wrote:
> ...
> > Why do you make that mistake, when it is PROVABLY NOT TRUE!
> >
> > Try this trivial program:
> >
> > int main(int argc, char **argv)
> > {
> >
Gregory Haskins wrote:
(*) I have no information on whether the futex-plist implemetation was
pulled from the tree to cause your regression. It is possible that the
changes between 22 and 23 are just tickling your environment enough to
bring out this RT-preempt issue.
Hmm...seems I
Giacomo Catenazzi wrote:
> const No writes through this lvalue. In the absence of this qualifier, writes
> may occur
> through this lvalue.
>
> volatile No cacheing through this lvalue: each operation in the abstract
> semantics must
> be performed (that is, no cacheing assumptions may be
On Fri, Jan 18, 2008 at 08:51:44PM +0800, WANG Cong wrote:
> On Fri, Jan 18, 2008 at 01:46:27PM +0100, Sam Ravnborg wrote:
> >On Fri, Jan 18, 2008 at 08:29:17PM +0800, WANG Cong wrote:
> >> On Fri, Jan 18, 2008 at 01:18:27PM +0100, Toralf Förster wrote:
> >> >Hello,
> >> >
> >> >the build with the
checkpatch.pl was unable to handle \\ within quoted string.
+static void test(char *sp, char *dp)
+{
+ if (*sp == '\\') {
+ *dp++ = '\\';
+ *dp++ = '\\';
+ }
+}
I hope this patch can fix it.
But I don't know whether there is a side effect or not.
Should we
[EMAIL PROTECTED] wrote:
Hello,
I have some strange behavior in one of my systems.
I have a real-time kernel thread under SCHED_FIFO which is running every
10ms.
It is blocking on a semaphore and released by a timer interrupt every 10ms.
Generally this works really well.
However, there is a
On Jan. 18, 2008, 13:37 +0200, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 17, 2008 at 11:19:23AM -0800, Andrew Morton wrote:
>> On Thu, 17 Jan 2008 16:23:51 - Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>>
>>> This version brings a large number of fixes which have built up over
>>>
> Almost everything we do prior unification is double the work.
That's not correct in this case as there are no common workarounds for i386 and
x86-64.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
> (AMD machines apparently don't need it
That's not true -- we had AMD systems in the past with broken MTRRs for
large memory configurations too, Mostly it was pre revE though.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On 01/18/2008 01:29 PM, Ingo Molnar wrote:
>> perhaps the right solution would be to only build it in if
>> CONFIG_PCSPEAKER is "y" or "m". I.e. your original patch?
>>
>
> i've added your patch to x86.git - see below.
>
Many thanks Ingo!
> Index: linux-x86.q/arch/x86/kernel/Makefile
>
Paul Menage wrote:
> On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
>> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
>>> Allow to limit the block I/O bandwidth for specific process containers
>>> (cgroups) imposing additional delays on I/O requests for those
David Miller writes:
> > eth0 e1000_irq_enable sem = 1<- ifconfig eth0 down
> > eth0 e1000_irq_disable sem = 2
> >
> > **e1000_open <- ifconfig eth0 up
> > eth0 e1000_irq_disable sem = 3 Dead. irq's can't be enabled
> > e1000_irq_enable miss
> > eth0
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> "
> Checking aperture...
> CPU 0: aperture @400 size 64MB
> CPU 1: aperture @400 size 64MB
> "
> we should use use Node instead.
>
> we will get
> "
> Checking aperture...
> Node 0: aperture @400 size 64MB
> Node 1: aperture @400 size
Ingo Molnar wrote:
> * Mike Travis <[EMAIL PROTECTED]> wrote:
>
>> Hi Andrew,
>>
>> My automatic scripts accidentally sent this mail prematurely. Please
>> hold off applying yet.
>
> I've picked it up for x86.git and i'll keep testing it (the patches seem
> straightforward) and will report
* Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:
> Move the select_idle_routine() call to after the detect_ht() call at
> identify_cpu() on 64-bit. This change is for printing the polling idle
> and HT enabled warning message properly.
thanks, applied.
Ingo
--
To unsubscribe from this
* Hiroshi Shimamoto <[EMAIL PROTECTED]> wrote:
> The warning message at idle_setup() is never shown because
> smp_num_sibling hasn't been updated at this point yet.
>
> Move this polling idle and HT enabled warning to
> select_idle_routine(). I also implement this warning on 64-bit kernel.
On Fri, Jan 18, 2008 at 01:46:27PM +0100, Sam Ravnborg wrote:
>On Fri, Jan 18, 2008 at 08:29:17PM +0800, WANG Cong wrote:
>> On Fri, Jan 18, 2008 at 01:18:27PM +0100, Toralf Förster wrote:
>> >Hello,
>> >
>> >the build with the attached .config was successful however I got during
>> >make :
>> >
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> +/* Fam 10h MSRs */
> +#define MSR_FAM10H_MMIO_CONF_BASE0xc0010058
> +#define FAM10H_MMIO_CONF_ENABLE (1<<0)
> +#define FAM10H_MMIO_CONF_BUSRANGE_MASK 0xf
> +#define FAM10H_MMIO_CONF_BUSRANGE_SHIFT 2
> +#define
* Ian Campbell <[EMAIL PROTECTED]> wrote:
> Shouldn't these, and the rest of the file, be using the PTE accessor
> macros set_pte,clear_pte etc? The boot_ioremap it replaces seems to
> have done. Otherwise these patches don't appear to be paravirt_ops
> clean. I haven't had a chance to
Sam Ravnborg wrote:
> Hi Mike.
>
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -20,6 +20,7 @@ config X86
>> def_bool y
>> select HAVE_OPROFILE
>> select HAVE_KPROBES
>> +select HAVE_SETUP_PER_CPU_AREA if ARCH = "x86_64"
>
> It is simpler to just say:
>> +select
I am using this kernel and this OS on PC Dell SMT670 with processor Intel
Corporation E7525
Linux l2.6.22-3-686 #1 SMP Mon Oct 22 22:11:56 UTC 2007 i686 GNU/Linux
Debian GNU/Linux lenny/sid
When i am using the printer with the application acroread and evince ,
sometimes i have no
On Fri, Jan 18, 2008 at 08:29:17PM +0800, WANG Cong wrote:
> On Fri, Jan 18, 2008 at 01:18:27PM +0100, Toralf Förster wrote:
> >Hello,
> >
> >the build with the attached .config was successful however I got during make
> >:
> > AS .tmp_kallsyms2.o
> > LD vmlinux.o
> > MODPOST
* Balaji Rao <[EMAIL PROTECTED]> wrote:
> Ingo, here's the patch with the SOB. Please apply.
thanks - reinstated your original patch and added your fix too. I added:
Signed-off-by: Balaji Rao <[EMAIL PROTECTED]>
Tested-by: Yinghai Lu <[EMAIL PROTECTED]>
Ingo
--
To unsubscribe from
On Jan 18, 2008 7:36 AM, Dhaval Giani <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
> > Allow to limit the block I/O bandwidth for specific process containers
> > (cgroups) imposing additional delays on I/O requests for those processes
> > that exceed
> OK, I misunderstood your original report to mean that something was
> complaining about "too much" output. You're saying that lots of console
> output seems to lock the domain.
Sorry about that, and yes that is the case.
> I've had a report about heavy disk IO seems to lock up as well.
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> Subject: x86: Add support for the latest Intel processors to Oprofile
> From: Arjan van de Ven <[EMAIL PROTECTED]>
>
> The latest Intel processors (the 45nm ones) have a model number of 23
> (old ones had 15); they're otherwise compatible on the
On Fri, Jan 18, 2008 at 12:41:03PM +0100, Andrea Righi wrote:
> Allow to limit the block I/O bandwidth for specific process containers
> (cgroups) imposing additional delays on I/O requests for those processes
> that exceed the limits defined in the control group filesystem.
>
> Example:
> #
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> With the iounmap problem resolved, it should be OK to always set
> _PAGE_GLOBAL in __PAGE_KERNEL*.
thanks Jeremy, applied.
> [ Did this patch cause problems before? ]
not that i remember.
Ingo
--
To unsubscribe from this list: send
On Fri, Jan 18, 2008 at 01:18:27PM +0100, Toralf Förster wrote:
>Hello,
>
>the build with the attached .config was successful however I got during make :
> AS .tmp_kallsyms2.o
> LD vmlinux.o
> MODPOST vmlinux.o
>WARNING: vmlinux.o(.text.head+0x247): Section mismatch: reference to
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> > thanks. But, i think we should rather do the following: if X86_PAT
> > is eanbled then /proc/mtrr should be read-only. There's no problem
> > _looking_ at MTRR contents, as long as we do not try to modify them.
> > Hm?
>
> anyway
>
> depends on
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> perhaps the right solution would be to only build it in if
> CONFIG_PCSPEAKER is "y" or "m". I.e. your original patch?
i've added your patch to x86.git - see below.
Ingo
--->
Subject: x86: fix unconditional
* Michael Opdenacker <[EMAIL PROTECTED]> wrote:
> On 01/18/2008 12:02 PM, Ingo Molnar wrote:
> >
> > why didnt you make this:
> >
> > obj-$(CONFIG_INPUT_PCSPKR)+= pcspeaker.o
> >
> > ?
> >
> Many thanks for your feedback.
>
> That's what I did first, but if
On Fri, 2008-01-18 at 17:28 +0530, Aggrwal Poonam wrote:
> Hello All
>
> The TDM driver just now does not have a proper framework. Probably the
> interface cannot be generalised as such. Hence we could not decide
> whether it would be right to think of a TDM framework. Infact the
> interface
On Thu, 17 Jan 2008, Willy Tarreau wrote:
> Well, since there are commands that work on this (push and log at
> least), I believe that some operations could succeed. I *know* that
> remote cloning was impossible, and it *looked* like pulling too was
> during my attempts to fix the problem before
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > (it doesnt matter if graphics does not resume fine - at least for my
> > tests)
> >
> > kprobes had similar problems and it now has a few simple smoke-tests
> > - which i just saw trigger on a patch that i did not notice would
> > break kprobes.
On 01/18/2008 12:02 PM, Ingo Molnar wrote:
>
> why didnt you make this:
>
> obj-$(CONFIG_INPUT_PCSPKR) += pcspeaker.o
>
> ?
>
Many thanks for your feedback.
That's what I did first, but if CONFIG_INPUT_PCSPKR=m,
arch/x86/kernel/pcspeaker.c gets compiled as a module. While compiling
From: Robert Olsson <[EMAIL PROTECTED]>
Date: Wed, 16 Jan 2008 18:07:38 +0100
>
> eth0 e1000_irq_enable sem = 1<- High netload
> eth0 e1000_irq_enable sem = 1
> eth0 e1000_irq_enable sem = 1
> eth0 e1000_irq_enable sem = 1
> eth0 e1000_irq_enable sem = 1
> eth0 e1000_irq_enable sem = 1
>
On Fri, Jan 18, 2008 at 01:02:48PM +0100, Ingo Molnar wrote:
>
> * Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > > Style question, would the following be preferred?
> > >
> > > config 64BIT
> > > def_bool ARCH = "x86_64"
> > > prompt "64-bit kernel"
> > > help...
> >
> > No.
> > It is
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Also, the mem -> node hash lookup is fixed.
> >
> > Based on 2.6.24-rc6-mm1 + change-NR_CPUS-V3 patchset
>
> hm, I've been hiding from those patches.
>
> Are they ready?
i'm carrying them in x86.git, and they are pretty robust, with one
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> [PATCH] x86_64: only call early_init_amd one time
>
> Andi's patch
> "
> x86: move X86_FEATURE_CONSTANT_TSC into early cpu feature detection
>
> Need this in the next patch in time_init and that happens early.
>
> This includes a minor fix
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> > ok. So it seems we dont even need all that many special cases, a
> > "dont write MTRRs" and "use PATs everywhere" rule would just do the
> > right thing all across?
>
> Yes. The main thing required is on the lines of Jesse's patch. If the
>
* Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > Style question, would the following be preferred?
> >
> > config 64BIT
> > def_bool ARCH = "x86_64"
> > prompt "64-bit kernel"
> > help...
>
> No.
> It is most common to let the prompt follow the type and not
> as a separate property.
Hello All
The TDM driver just now does not have a proper framework. Probably the
interface cannot be generalised as such. Hence we could not decide
whether it would be right to think of a TDM framework. Infact the
interface this TDM driver(for MPC8323ERDB) supplies may not be usable
for some
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-01-18 at 11:44 +0100, Ingo Molnar wrote:
> > * Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > # Select 32 or 64 bit
> > > config 64BIT
> > > - bool "64-bit kernel" if ARCH = "x86"
> > > + bool "64-bit kernel"
> > > default
Jakob Oestergaard wrote:
On Thu, Jan 17, 2008 at 01:25:39PM -0800, Linus Torvalds wrote:
...
Why do you make that mistake, when it is PROVABLY NOT TRUE!
Try this trivial program:
int main(int argc, char **argv)
{
int i;
const int *c;
Allow to limit the block I/O bandwidth for specific process containers
(cgroups) imposing additional delays on I/O requests for those processes
that exceed the limits defined in the control group filesystem.
Example:
# mkdir /dev/cgroup
# mount -t cgroup -oio-throttle io-throttle /dev/cgroup
On Fri, Jan 18, 2008 at 02:50:48AM -0800, Harvey Harrison wrote:
>
> On Fri, 2008-01-18 at 11:44 +0100, Ingo Molnar wrote:
> > * Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > # Select 32 or 64 bit
> > > config 64BIT
> > > - bool "64-bit kernel" if ARCH = "x86"
> > > + bool "64-bit kernel"
>
On Thu, Jan 17, 2008 at 11:19:23AM -0800, Andrew Morton wrote:
> On Thu, 17 Jan 2008 16:23:51 - Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > This version brings a large number of fixes which have built up over
> > the Christmas period. Mostly these are fixes for false positives, both
> >
On Fri, 18 Jan 2008, Jiri Kosina wrote:
>
> If this patch is going to be merged, you should perhaps adjust the comment
> introduced by the above mentioned commit, so that it reflects the new
> behavior.
Thanks for pointing this out. Updated patch below:
-- Steve
=
I thought that one
> Possibly, I didn't see a quick way to break that iteration.
> >From a quick glance at prio_tree.c the iterator isn't valid anymore
> after releasing i_mmap_lock. Fixing that would be,.. 'fun'.
Maybe i_mmap_lock isn't needed at all, since msync holds mmap_sem,
which protects the prio tree as
401 - 500 of 1161 matches
Mail list logo
