On Tue, Apr 03, 2007 at 07:45:16PM +0530, Gautham R Shenoy wrote:
Should we ignore this for the timebeing and take up later as and when
users report problems?
In my case, the problem of freezer failing was due to the vfork freezer race
in do_fork. The parent task was
On Wed, 04 Apr 2007 12:28:38 +1000 Rusty Russell wrote:
lguest wants range checking, but unless there are other users I'm not
sure this is worth the pain. Putting it out there in case it's useful.
Cheers,
Rusty.
==
There are some places where we want to check if a value + length is
From: Randy Dunlap [EMAIL PROTECTED]
Fix section mismatch warnings in mtrr code.
Fix line length on one source line.
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to
.init.data: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x103)
WARNING:
On Tue, 03 Apr 2007 19:20:04 PDT, Randy Dunlap said:
On Tue, 03 Apr 2007 21:35:54 -0400 [EMAIL PROTECTED] wrote:
I do a '/ACPI_SLEEP' inside that, and I get this output:
x Symbol: ACPI_SLEEP [=n] x
x Depends on: !X86_NUMAQ !X86_VISWS
[EMAIL PROTECTED] wrote:
On Tue, 03 Apr 2007 19:20:04 PDT, Randy Dunlap said:
On Tue, 03 Apr 2007 21:35:54 -0400 [EMAIL PROTECTED] wrote:
I do a '/ACPI_SLEEP' inside that, and I get this output:
x Symbol: ACPI_SLEEP [=n] x
x Depends on:
On Fri, Mar 30, 2007 at 04:40:48AM +0200, Nick Piggin wrote:
Well it would make life easier if we got rid of ZERO_PAGE completely,
which I definitely wouldn't complain about ;)
So, what bad things (apart from my bugs in untested code) happen
if we do this? We can actually go further, and
vatsa wrote:
User space queries like what is the cpuset to which this task belongs,
where the answer needs to be something of the form /dev/cpuset/C1?
I think that answer should be of the form /C1, and not include the
cpuset file system mount point ... though for the purposes of the
present
On Tue, 03 Apr 2007, Jeremy Fitzhardinge wrote:
Attached. Is there some tool for decoding the DSDT?
iasl. The documentation is the ACPI Specification.
ezr:pts/1; cat /proc/acpi/ibm/thermal
temperatures: 72 55 -128 65 40 -128 35 -128 51 53 -128 -128 -128 -128
-128 -128
This is a
Matt Mackall wrote:
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
I think it would be better in mm/.
So would clear_refs_pte_range, and clear_refs_write (in a more
generic form), IMO.
Sweet patchset, though.
--
SUSE Labs, Novell
please check the patch
YH
[PATCH] x86_64/acpi: make kernel to be compiled when CONFIG_ACPI_NUMA is set and power management with acpi is not enabled
when CONFIG_ACPI_NUMA is set, and power management with acpi is not used. the kernel can not be compiled.
drivers/acpi/bus.c: In function
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/b44.c |2 +-
drivers/net/cxgb3/common.h|9 +--
drivers/net/cxgb3/cxgb3_main.c|
This is a first step as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
The current get_unmapped_area code calls the f_ops-get_unmapped_area or
the arch one (via the
Hi Yoichi,
Could you please try the patch below? It moves platform device creation
code into cobalt arch code to belletr follow driver model.
Thank you!
--
Dmitry
Input: cobalt buttons - separate device and driver registration
Create platform device for cobalt buttons as part of arch setup.
This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
mm/mmap.c | 16
1 file changed, 16 deletions(-)
Index: linux-cell/mm/mmap.c
===
--- linux-cell.orig/mm/mmap.c 2007-03-22 16:30:24.0 +1100
+++
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c
This also fixes a bug, I think, it used to return a pgoff (pfn)
instead of an address. (To split ?)
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/char/mem.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/drivers/char/mem.c
and change the caller now that everybody can handle it.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
mm/mmap.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
Index: linux-cell/mm/mmap.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
---
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
---
On Wed, 2007-04-04 at 14:01 +1000, Benjamin Herrenschmidt wrote:
This is a first step as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
.../...
And sorry for
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
===
---
On 4/3/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
User space queries like what is the cpuset to which this task belongs,
where the answer needs to be something of the form /dev/cpuset/C1?
The patches address that requirement atm by having a dentry pointer in
struct cpuset itself.
Have you
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm/hugetlbpage.c |8
2 files changed, 15 insertions(+)
Index: linux-cell/arch/ia64/kernel/sys_ia64.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/i386/mm/hugetlbpage.c
resend
On 4/3/07, Yinghai Lu [EMAIL PROTECTED] wrote:
please check the patch
YH
[PATCH] x86_64/acpi: make kernel to be compiled when CONFIG_ACPI_NUMA is set and power management with acpi is not enabled
when CONFIG_ACPI_NUMA is set, and power management with acpi is not used. the kernel
This is a first step as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
The current get_unmapped_area code calls the f_ops-get_unmapped_area or
the arch one (via the
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
---
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
===
--- linux-cell.orig/arch/frv/mm/elf-fdpic.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
--- linux-cell.orig/arch/alpha/kernel/osf_sys.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-cell/arch/arm/mm/mmap.c
===
--- linux-cell.orig/arch/arm/mm/mmap.c 2007-03-22
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-cell/arch/powerpc/mm/hugetlbpage.c
===
---
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
fs/ramfs/file-nommu.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-cell/fs/ramfs/file-nommu.c
===
--- linux-cell.orig/fs/ramfs/file-nommu.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/hugetlbfs/inode.c
===
--- linux-cell.orig/fs/hugetlbfs/inode.c2007-03-22
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
===
---
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/parisc/kernel/sys_parisc.c |5 +
1 file changed, 5 insertions(+)
Index: linux-cell/arch/parisc/kernel/sys_parisc.c
===
---
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/sparc64/mm/hugetlbpage.c
===
---
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/ia64/kernel/sys_ia64.c |7 +++
arch/ia64/mm/hugetlbpage.c |8
2 files changed, 15 insertions(+)
Index: linux-cell/arch/ia64/kernel/sys_ia64.c
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/hugetlbpage.c
===
--- linux-cell.orig/arch/i386/mm/hugetlbpage.c
On Mon, 2007-04-02 at 00:31 -0400, Dave Dillow wrote:
On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
[snipped for brevity]
[EMAIL PROTECTED] music]# stat .
Device: fd00h/64768dInode: 10354963Links: 39
Now rebooted to 2.6.21-rc5:
Device: ee00h/60928dInode: 10354963
On Sat, Mar 31, 2007 at 04:27:46PM +0530, Milind Arun Choudhary wrote:
Clean up ROUND_?UP, Use ALIGN where ever appropriate.
Signed-off-by: Milind Arun Choudhary [EMAIL PROTECTED]
Milind,
Looks good to me.
Signed-off-by: Grant Grundler [EMAIL PROTECTED]
Kyle,
can you remind me how these
Alan Cox writes:
That would be completely unmanagable on many systems with multiport
controllers and interfaces where the naming tells you things like which
cable port off which socket off which multiplexor is the one you are
talking about.
I never suggested *all* serial ports should be
Don't know if this got reported yet. It's slightly stale
(against 2.6.21-rc4-git6), but I don't recall seeing
anything in the changelogs recently that would make this
irrelevant.
Dave
--
http://www.codemonkey.org.uk
---BeginMessage---
Please do not reply directly to this email. All
Jan Engelhardt a écrit :
On Apr 2 2007 12:41, Eric Dumazet wrote:
The following patch does the right thing for pipes, I let you doing
the same for sockets...
Is struct sock-sk_receive_queue-qlen actually the thing I am
looking for? (Previously, I had struct sock-sk_rcvbuf, which was
obviously
On Sun, Apr 01, 2007 at 01:06:46PM +0530, Milind Arun Choudhary wrote:
ROUND_UP macro cleanup, use ALIGN where ever appropriate
Signed-off-by: Milind Arun Choudhary [EMAIL PROTECTED]
Also looks good to me. Just one white space nit we can fixup by hand.
Signed-off-by: Grant Grundler [EMAIL
On Tue, Apr 03, 2007 at 09:04:59PM -0700, Paul Menage wrote:
Have you posted the cpuset implementation over your system yet?
Yep, here:
http://lists.linux-foundation.org/pipermail/containers/2007-March/001497.html
For some reason, the above mail didnt make it into lkml (maybe it
exceeded the
H. Peter Anvin a écrit :
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Sounds like it would need a device which can be waited upon for changes.
A vdso-like shared page could have a futex in it.
Yes, but a futex couldn't be waited upon with a bunch of other things as
part of a poll or a
Eric Dumazet wrote:
There is one thing that always worried me.
Intel AMD manuals make clear that mixing data and program in the same
page is bad for performance.
In particular, x86_64 vsyscall put jiffies and other
vsyscall_gtod_data_t right in the midle of code. That is certainly not
On Wed, 2007-04-04 at 14:20 +1000, Paul Mackerras wrote:
I never suggested *all* serial ports should be /dev/ttySn, I said that
the built-in ports on the motherboard should be /dev/ttySn.
Why? What's so special about the name 'ttyS'?
The built-in ports can generally be enumerated early on
On Wed, Apr 04, 2007 at 01:51:37PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
I think it would be better in mm/.
I originally was looking at putting it in mm/memory.c and
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor modifies data within 2k of another
processor executing code,
H. Peter Anvin a écrit :
Eric Dumazet wrote:
There is one thing that always worried me.
Intel AMD manuals make clear that mixing data and program in the
same page is bad for performance.
In particular, x86_64 vsyscall put jiffies and other
vsyscall_gtod_data_t right in the midle of code.
This is an old bug. It has been happening forever, but I'd love to
know how I can help get this tracked down and fixed.
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV
On Tue, 2007-04-03 at 17:35 +0100, Paul LeoNerd Evans wrote:
On Tue, Apr 03, 2007 at 04:20:52PM +, Pavel Machek wrote:
HPA is right... this should be fixed in userland. Reset should reset a
console, and if you want utf-8, do \ec\ewhatever to get it.
As I've already said elsewhere, does
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor modifies data within 2k of
Nick Piggin a écrit :
Eric Dumazet wrote:
I do think such workloads might benefit from a vma_cache not shared by
all threads but private to each thread. A sequence could invalidate
the cache(s).
ie instead of a mm-mmap_cache, having a mm-sequence, and each thread
having a
On Tue, 2007-04-03 at 17:37 +0200, Martin Mares wrote:
Hello!
Does whatever defines what these escapes mean, have any comment to make
about UTF-8? If not, why can't we declare that UTF-8 mode is the reset
mode, the default that would be dropped to on a full reset, and if
anyone wanted
On Wed, 4 Apr 2007 00:33:36 -0500 Miles Lane [EMAIL PROTECTED] wrote:
This is an old bug. It has been happening forever, but I'd love to
know how I can help get this tracked down and fixed.
Yes, I've been hitting something like that in the past 3-4 weeks. We
started to diagnose it but I got
H. Peter Anvin a écrit :
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Mutable data should be separated from code. I think any current CPU
will do fine as long as they are in separate 128-byte chunks, but they
need at least that much separation.
P4 manual says that if one processor
Alan Cox wrote:
Nothing terribly exciting here just odd glitches from the merge
ACK, will apply if I can sort out the confusion between -mm and local
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: David Woodhouse [EMAIL PROTECTED]
Date: Wed, 04 Apr 2007 01:19:59 -0400
I don't see why that 'should' be the case. Certainly it _isn't_ the case
on most supported platforms -- we have separate device numbers, and
names, for most types of ports. There's only one or two drivers which
Matt Mackall wrote:
On Wed, Apr 04, 2007 at 01:51:37PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
I think it would be better in mm/.
I originally was looking at putting it in
David Woodhouse writes:
Why? What's so special about the name 'ttyS'?
It's the name that users of Linux expect built-in serial ports to have.
The built-in ports can generally be enumerated early on boot in a
stable order, and they should be assigned the low ttySn numbers,
regardless of
On Tue, 2007-04-03 at 07:31 +0200, Mike Galbraith wrote:
> On Tue, 2007-04-03 at 12:37 +1000, Con Kolivas wrote:
> > On Thursday 29 March 2007 15:50, Mike Galbraith wrote:
> > > On Thu, 2007-03-29 at 09:44 +1000, Con Kolivas wrote:
> > > + * This contains a bitmap for each dynamic priority level
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > Try two instances of chew.c at _differing_ nice levels on one cpu on
> > mainline, and then SD. This is why you can't renice X on mainline.
>
> How about something more challenging instead :)
>
> The numbers below are from my scheduler tree with
On Tue, 3 Apr 2007 15:44:19 +1000 David Chinner <[EMAIL PROTECTED]> wrote:
> In XFS, one of the shrinkers cwthat gets registered calls causes all
> the xfsbufd's in the system to run and write back delayed write
> metadata - this can't be freed up until it is clean, and this is the
> only hook we
The generic networking code ensures that no two networking devices
have the same name, so there is no time except when sysfs has
implementation bugs that device_rename when called from
dev_change_name will fail.
The current error handling for errors from device_rename in
dev_change_name is
On Tue, 03 Apr 2007 15:47:05 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-04-02 at 21:57 -0700, Andrew Morton wrote:
> > On Tue, 03 Apr 2007 14:45:02 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote:
> > > Does that mean the to function correctly every user needs some internal
> > >
On Tue, 2007-04-03 at 08:01 +0200, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > > Try two instances of chew.c at _differing_ nice levels on one cpu on
> > > mainline, and then SD. This is why you can't renice X on mainline.
> >
> > How about something more challenging
On Mon, 2007-04-02 at 19:09 +0200, Marco wrote:
> Marco ha scritto:
> >
> Any idea? :'(
Not sure why your /proc/mtrr output is like that, but if you want vesafb
to use mtrr, use:
video=vesafb:mtrr:3,ywrap... instead
(See Documentation/fb/vesafb.txt)
Tony
-
To unsubscribe from this list:
On Mon, Apr 02, 2007 at 11:01:58PM -0700, Andrew Morton wrote:
> On Tue, 3 Apr 2007 15:44:19 +1000 David Chinner <[EMAIL PROTECTED]> wrote:
>
> > In XFS, one of the shrinkers cwthat gets registered calls causes all
> > the xfsbufd's in the system to run and write back delayed write
> > metadata -
On Tue, 3 Apr 2007 01:04:05 -0400, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> What do you think?
The patch looks sane, although I haven't yet tested it. I'll live with
it until next quarterly update, then consider if I should take it or use
my patch for RHEL 5 and RHEL 4.
-- Pete
-
To
* Ayaz Abdulla <[EMAIL PROTECTED]> wrote:
> I had responded eariler to the thread asking you to try out the patch
> found in bug 8058:
> http://bugzilla.kernel.org/show_bug.cgi?id=8058
>
> I believe that is the caush of the NULL skb dereference issue.
there's a different type of regression
* David Sperry <[EMAIL PROTECTED]> wrote:
> > > I think there is some kind of bad behavior happening in the Nvidia
> > > driver with respect to softirq-net-tx and IRQ-8406.
> >
> > yes. Part of the problem is that the forcedeth.c driver does not
> > fully support NAPI - today i've implemented
>
> Hi all, I've bought a USB wireless TA bundled with GPL
> Linux drivers for 2.6.11 kernel series.
Hi. Maybe I can help u providing some http space. I also bought "Conitech Dakota
Wireless TA 56Mbps" but drivers are currently not working: my version is
"hal_059"...
-
To unsubscribe from this
On 02-04-2007 21:41, Christian Kujau wrote:
>
> Hi there,
>
> we have serious problems with 2 of our servers: both shiny new amd64
> dual core, with both 2GB RAM, 32bit kernel+userland (Debian/testing).
> Both servers have 2 NICs, RTL8139 (eth0, irq10) and RTL8169s
> (eth1, irq11).
Hi,
Did
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > I had responded eariler to the thread asking you to try out the patch
> > found in bug 8058:
> > http://bugzilla.kernel.org/show_bug.cgi?id=8058
> >
> > I believe that is the caush of the NULL skb dereference issue.
>
> there's a different type
On Mon, 2007-04-02 at 23:09 -0700, Andrew Morton wrote:
> hm, well, six-of-one, VI of the other. We save maybe four kmallocs across
> the entire uptime at the cost of exposing stuff kernel-side which doesn't
> need to be exposed.
This is not about efficiency. When have I *ever* posted
Hi Bob,
On Mon, 2 Apr 2007 13:55:49 -0700, Moore, Robert wrote:
> The ACPI specification allows concurrent execution of control methods
> although methods cannot be preempted. The ACPICA interpreter mutex is
> used to implement this model.
>
> From section 5.5.2, "Control Method Execution":
I'm using Linux 2.6.20.4. I noticed that I get lower SATA hard drive
throughput with 2.6.20.4 than with 2.6.19. The reason was that 2.6.20
enables NCQ by defauly (queue_depth = 31/32 instead of 0/32). Transfer rate
was measured using "hdparm -t":
With NCQ (queue_depth == 31): 50MB/s.
Without
Christoph Lameter wrote:
SLUB Core patch V6
This provides basic SLUB functionality and allows a choice of
slab allocators during kernel configuration. The default is still
slab. SLUB has been tested in various configurations but I think we
can be quite sure that there are still remaining
On Sat, Mar 24, 2007 at 08:35:35AM +0530, Maneesh Soni wrote:
> On Fri, Mar 23, 2007 at 12:43:27PM -0700, Ethan Solomita wrote:
> > I ran stress testing overnight and came up with a similar failure
> > (s_dentry == NULL) but in a different location. A NULL pointer
> > dereference happened in
Rafael J. Wysocki napsal(a):
> On Monday, 2 April 2007 10:24, Jiri Slaby wrote:
>> Rafael J. Wysocki napsal(a):
> On Thursday, 29 March 2007 09:44, Jiri Slaby wrote:
>> swsusp: critical section:
>> swsusp: Need to copy 131380 pages
>> swsusp: Not enough free memory
>> Error -12
I'm working on getting the IDE subsystem to communicate with an IDE
device wired to nCS5 on a CLEP7312 board. I have
0x5000 set to be remapped to 0xfe10 but whenever I try to access the
registers I get kernel crashes. I'm sure I'm doing
something wrong, since this works on a
This is a simplified and actually more comprehensive form of a bug
fix from Mitch Williams <[EMAIL PROTECTED]>.
When we mask or unmask a msi-x irqs the writes may be posted because
we are writing to memory mapped region. This means the mask and
unmask don't happen immediately but at some
On Mon, Apr 02, 2007 at 10:48:24PM +0200, Rafael J. Wysocki wrote:
> On Monday, 2 April 2007 15:56, Pavel Machek wrote:
> > Hi!
> >
> > > This patch provides an interface to extend the use of the process
> > > freezer beyond Suspend.
> > >
> > > The tasks can selectively mark themselves to be
what is the real advantage to package uml-kernel and rootfs into a single
file ?
If this needs to be distributed with additional script, that's two files,
anyway.
the classical way would be 3 files: uml-kernel, rootfs, script - put into
some tar.gz or tar.bz2
this could look as elegant
On Monday 02 April 2007 23:12, Andi Kleen wrote:
>
> > How would that work in the case where virtualized guests don't have a
> > visible PCI bus, and the virtual environment doesn't pretend to emulate
> > a PCI bus?
>
> If they emulated one with the appropiate device
> then distribution driver
On Tuesday 03 April 2007 10:29:06 Christian Borntraeger wrote:
> On Monday 02 April 2007 23:12, Andi Kleen wrote:
> >
> > > How would that work in the case where virtualized guests don't have a
> > > visible PCI bus, and the virtual environment doesn't pretend to emulate
> > > a PCI bus?
> >
> >
Hello,
I'm not sure whether a fix is necessary for the following scenario.
The kernel configure target "make menuconfig" requires ncurses. FWIW, it
could probably be better if the error message would indicate that that
ncurses is necessary for "make menuconfig" to run and that the user could
On Mon, 2 Apr 2007, Pete Zaitcev wrote:
> How about this?
Looks quite fine to me.
But in case that Dmitry's patch "Input: add generic suspend and resume for
uinput devices" fixes your issue too, I wouldn't merge it as it won't be
needed. Could you please let me know?
> @@ -947,6 +989,8 @@
On Mon, 2 Apr 2007 09:59:28 -0700,
David Brownell <[EMAIL PROTECTED]> wrote:
> But long term, I wonder. Isn't "no kevents issued" an extremely
> blunt tool, which could cause lots of damage? It might be better
> to have selective filters, one per event family: core (add/remove),
>
* David Sperry <[EMAIL PROTECTED]> wrote:
> > there are a few other things i'm working on to improve this. I've
> > uploaded -rt9 which is the current state of affairs. Note that using
> > -rt9 you'll likely only see IRQ-8406 overhead in the system, because
> > i've added an optimization to
On Tue, 3 Apr 2007, Li Yu wrote:
> What's the position of hidraw? It only is used when all other driver is
> not usable on some report? or, it should be stick every working device.
Current implementation (as you can see it in -mm or in my hid.git tree) is
creating hidraw interface for just
On Tue, 3 Apr 2007, Li Yu wrote:
> May be, we need some means to change blacklist in runtime.
Paul Walmsley (added to CC) sent me patches some time ago that among other
things implemented possibility to modify the hid_blacklist[] in runtime.
The patches had some issues which Paul said will fix
Jiri Kosina wrote:
As this quirk is only needed once in the initialization method, we could
probably get rid of it and just put and explicit test for PID and VID
there (with apropriate comment). We can't afford wasting quirk entries, as
we are slowly running out of them.
Is it a problem of
401 - 500 of 934 matches
Mail list logo
