> Have we done that? Yes. We actually had a "no-hlt" kernel command line
> flag that literally disabled halting the CPU, because it apparently caused
> problems for some floppy disk setups (and yes, the main reasonable
> explanation was some bad DMA interaction, we never figured it out).
>
>
On Mon, 20 Aug 2007, Chris Snook wrote:
>
> What about barrier removal? With consistent semantics we could optimize a
> fair amount of code. Whether or not that constitutes "premature" optimization
> is open to debate, but there's no question we could reduce our register wiping
> in some
Jeff Layton wrote:
This should fix all of the filesystems in the mainline kernels to handle
ATTR_KILL_SUID and ATTR_KILL_SGID correctly. For most of them, this is
just a matter of making sure that they call generic_attrkill early in
the setattr inode op.
Signed-off-by: Jeff Layton <[EMAIL
RX790 can't do MSI like its predecessors. Disable MSI on RX790.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
Okay, another one from ATI which can't do MSI. 2.6.23 material.
drivers/pci/quirks.c|1 +
include/linux/pci_ids.h |1 +
2 files changed, 2 insertions(+)
diff --git
>In the Linux proc filesystem, /proc/[pid]/fd is a link to the
>actually the actual pathname of the opened file.
>
>I am curious how Linux convert an fd to the pathname? Does it
>recursively walk back from current dentry to the root?
AFAICS the fd has a pointer to the vma of the file (don't
On Mon, 20 Aug 2007, David Brownell wrote:
> On Monday 20 August 2007, Linus Torvalds wrote:
> >
> > Fair enough. However, it still seems particularly idiotic to
> > - penalize everybody
> > - mix up two totally unrelated areas (cpufreq and USB) for a bug that is
> >extremely rare and
Fix all issues pointed out in Jeff's email.
Acked-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]>
---
drivers/ata/Kconfig | 16
drivers/ata/Makefile |1
drivers/ata/pata_bf54x.c | 1627
+++
3
On Mon, 20 Aug 2007 22:03:28 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> register_hotcpu_notifier() is cunning. If CONFIG_HOTPLUG_CPU=y, we need
> the notifier block and the function to which it points to be in .data and
> in .text. If CONFIG_HOTPLUG_CPU=n, we don't need them to be present
On Tue, 21 Aug 2007 10:07:31 +0530 (IST) Satyam Sharma <[EMAIL PROTECTED]>
wrote:
>
> WARNING: arch/i386/kernel/built-in.o(.data+0x2148): Section mismatch:
> reference
> to .init.text: (between 'thermal_throttle_cpu_notifier' and 'mtrr_mutex')
>
> comes because struct notifier_block
On Mon, 2007-08-20 at 20:54 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >
> > I think the "next" field can be u32 instead of u64. Because the linked
> > list of struct setup_data is prepared by bootloader, which can control
> > the memory location.
> >
>
> That's making some pretty
On Monday 20 August 2007, Linus Torvalds wrote:
>
> On Mon, 20 Aug 2007, David Brownell wrote:
> >
> > MMF basically means the "Transaction Translating" (TT) hub had data
> > for the host, but the host didn't collect it in time ... so that some
> > data was lost.
> >
> > Unfortunately, that's
diff --git a/Makefile b/Makefile
index bc2d377..f2a62ee 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 22
-EXTRAVERSION = .3
+EXTRAVERSION = .4
NAME = Holy Dancing Manatees, Batman!
# *DOCUMENTATION*
diff --git a/fs/exec.c b/fs/exec.c
index
We (the -stable team) are announcing the release of the 2.6.22.4 kernel.
It contains one security fix and all users of the 2.6.22 series are
encouraged to upgrade to it.
I'll also be replying to this message with a copy of the patch between
2.6.22.3 and 2.6.22.4
The updated 2.6.22.y git tree can
This patch replaces calls to sys_* with filp_open and vfs_read. And since this
is the last driver in the kernel that uses sys_{read,close}, it kills the
exports as well. sys_open is left exported for sparc64 only.
Cc: Takashi Iwai <[EMAIL PROTECTED]>
Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
[ GRR sorry for the premature "SEND" ... mouspads-r-evil ]
On Monday 20 August 2007, Linus Torvalds wrote:
>
> On Mon, 20 Aug 2007, David Brownell wrote:
>
> > On Monday 13 August 2007, Michal Piotrowski wrote:
> > > Subject     : EHCI Regression in 2.6.23-rc2
> > > References    :
WARNING: arch/i386/kernel/built-in.o(.data+0x2148): Section mismatch: reference
to .init.text: (between 'thermal_throttle_cpu_notifier' and 'mtrr_mutex')
comes because struct notifier_block thermal_throttle_cpu_notifier in
arch/i386/kernel/cpu/mcheck/therm_throt.c goes in .data section but
the
> -Original Message-
> From: Patrick Geoffray [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 20, 2007 1:34 PM
> To: Felix Marti
> Cc: Evgeniy Polyakov; David Miller; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
> [EMAIL
On Mon, Aug 20, 2007 at 04:19:06PM -0400, Mathieu Desnoyers wrote:
> Since it will not be used by other kernel objects, it makes sense to declare
> it
> static.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Acked-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
> CC: [EMAIL
On Mon, 20 Aug 2007, David Brownell wrote:
>
> MMF basically means the "Transaction Translating" (TT) hub had data
> for the host, but the host didn't collect it in time ... so that some
> data was lost.
>
> Unfortunately, that's the type of fault that's especially hard to
> recover from.
On Mon, Aug 20, 2007 at 04:19:04PM -0400, Mathieu Desnoyers wrote:
> Protect the instruction pages list by a specific insn pages mutex, called in
> get_insn_slot() and free_insn_slot(). It makes sure that architectures that
> does
> not need to call arch_remove_kprobe() does not take an unneeded
On Mon, Aug 20, 2007 at 04:19:05PM -0400, Mathieu Desnoyers wrote:
> Remove the kprobes mutex from kprobes.h, since it does not belong there. Also
> remove all use of this mutex in the architecture specific code, replacing it
> by
> a proper mutex lock/unlock in the architecture agnostic code.
>
> Starting 1-2 weeks ago I have very long resume from
> ram times. It takes more than 1 min to resume.
Do you see any difference with "pnpacpi=off"?
thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Hi everyone:
A posix timer race condition is found in current kernel source tree.
Jeremy has actually
reported the same problem.
I write a simple stress test program for posix timer subsystem, to
reproduce the problem in the lastest mainline kernel.
My test program creates 200 threads, and
On Monday 20 August 2007, Linus Torvalds wrote:
>
> On Mon, 20 Aug 2007, David Brownell wrote:
>
> > On Monday 13 August 2007, Michal Piotrowski wrote:
> > > Subject     : EHCI Regression in 2.6.23-rc2
> > > References    : http://lkml.org/lkml/2007/8/10/81
> > > Last known good : ?
Huang, Ying wrote:
>
> I think the "next" field can be u32 instead of u64. Because the linked
> list of struct setup_data is prepared by bootloader, which can control
> the memory location.
>
That's making some pretty serious assumptions on future boot loaders and
environments.
> Previously, I
Jonathan Lim wrote:
> taskstats.ac_exitcode is assigned to task_struct.exit_code in bacct_add_tsk()
> through the following kernel function calls:
>
> do_exit()
> taskstats_exit_send()
> fill_pid()
> bacct_add_tsk()
>
> The problem is that in do_exit(), task_struct.exit_code
Hi,
In the Linux proc filesystem, /proc/[pid]/fd is a link to the
actually the actual pathname of the opened file.
I am curious how Linux convert an fd to the pathname? Does it
recursively walk back from current dentry to the root?
Can someone point me to the right place in the kernel where
Find maintainer info for a patch or a file
Changes since last submission: (in for a penny...)
Might as well do them all.
Added --status - Print the status information
Added --subsystem - Print the subsystem title
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git
jungseung lee wrote:
> We are pleased to announce the release of gitstat 0.1.
>
> Gitstat is a GPL'd, web-based git statistics/monitoring system.
I have added information about gitstat to git wiki:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#gitstat
Please check if the information
taskstats.ac_exitcode is assigned to task_struct.exit_code in bacct_add_tsk()
through the following kernel function calls:
do_exit()
taskstats_exit_send()
fill_pid()
bacct_add_tsk()
The problem is that in do_exit(), task_struct.exit_code is set to 'code'
only after
On Mon, 20 Aug 2007, David Brownell wrote:
> On Monday 13 August 2007, Michal Piotrowski wrote:
> > Subject     : EHCI Regression in 2.6.23-rc2
> > References    : http://lkml.org/lkml/2007/8/10/81
> > Last known good : ?
> > Submitter    : Daniel Exner <[EMAIL PROTECTED]>
>
Robin Lee Powell digitalkingdom.org> writes:
> > Though I agree that it would be nice if we could convince all
> > subsequent requests to a server to fail EIO instead of just the
> > currently active ones. I'm not sure that just changing "umount
> > -f" is the right interface though Maybe
On Mon, 2007-08-20 at 10:12 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >>
> >> I propose that, in addition to the aforementioned version number and
> >> magic fields, we add a pointer, which should be the last pointer added
> >> that doesn't point into I/O space or reserved memory (i.e.
On Monday 13 August 2007, Michal Piotrowski wrote:
> Subject : EHCI Regression in 2.6.23-rc2
> References : http://lkml.org/lkml/2007/8/10/81
> Last known good : ?
> Submitter : Daniel Exner <[EMAIL PROTECTED]>
> Caused-By : [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>
Hi Geert,
On Mon, 20 Aug 2007, Geert Uytterhoeven wrote:
> On Sat, 18 Aug 2007, Satyam Sharma wrote:
> > On Sat, 18 Aug 2007, Jan Engelhardt wrote:
> > > On Aug 18 2007 20:07, Satyam Sharma wrote:
> > > >On Fri, 17 Aug 2007, Geert Uytterhoeven wrote:
> > > >> On Thu, 16 Aug 2007, NeilBrown
Ingo Molnar <[EMAIL PROTECTED]> writes:
You should just be using idle notifiers instead instead of adding more
and more custom hooks (like NOHZ has already) x86-64 still has them
and there is a old patch around to add them to i386.
-Andi
-
To unsubscribe from this list: send the line
[TSO / LRO discussion snipped -- it's not the main point so no sense
spending energy arguing about it]
> Just be realistic and accept that RDMA is a point in time solution,
> and like any other such technology takes flexibility away from users.
>
> Horizontal scaling of cpus up to huge arity
> Right. I am not sure exactly how to handle that. There is also the issue
> of the writes being deferred. I thought maybe of using pdflush to writeout
> the pages? Maybe increase priority of the pdflush so that it runs
> immediately when notified. Shrink_page_list would gather the dirty pages
Hello,
after running a few instances of bittorent-curses on 2.6.22 - 2.6.22.3 it
takes about 15min to 2hrs for my System to hang. 2.6.21.7 is definately fine,
2.6.21 probably (ran for 4hrs without hanging).
If I'm lucky the Oops below makes it to my syslog (unfortunately SysRq-{p,s,i}
doesn't
Some external modules like Speakup need to use the PC keyboard to control
them and also need to get keyboard feedback (caps lock status, etc.)
This adds a keyboard notifier that such modules can use to get the keyboard
events and possibly eat them, at several stages:
- keycodes: even before
This patch uses kzalloc to zero all of struct dio rather than manually trying
to track which fields we rely on being zero. It passed aio+dio stress testing
and some bug regression testing on ext3.
This patch was introduced by Linus in the conversation that lead up to Badari's
minimal fix to
On Mon, 2007-08-20 at 16:27 -0400, Mathieu Desnoyers wrote:
> The marker activation functions sits in kernel/marker.c. A hash table is used
> to keep track of the registered probes and armed markers, so the markers
> within
> a newly loaded module that should be active can be activated at module
On Mon, Aug 20, 2007 at 11:14:08PM +0200, Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 13:27 -0700, Christoph Lameter wrote:
> > On Mon, 20 Aug 2007, Peter Zijlstra wrote:
> >
> > > > Plus the same issue can happen today. Writes are usually not completed
> > > > during reclaim. If the writes
Hi,
Some braille keyboards have 10 dots, so extend the Input braille keys
definitions.
Signed-off-by: Samuel Thibault <[EMAIL PROTECTED]>
diff --git a/include/linux/input.h b/include/linux/input.h
index e02c6a6..17df5a7 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -552,6
Being able to run 'silentoldconfig' with an existing .config has been
immensely useful, especially for automated builds. If the kernel code
changes in an incompatible manner without the associated .config being
updated, the build will fail and call attention to the need for an update.
AFAICT,
On Mon, Aug 20, 2007 at 12:15:01PM -0700, Christoph Lameter wrote:
> On Mon, 20 Aug 2007, Peter Zijlstra wrote:
>
> > > > <> What Christoph is proposing is doing recursive reclaim and not
> > > > initiating writeout. This will only work _IFF_ there are clean pages
> > > > about. Which in the
On Mon, Aug 20, 2007 at 05:51:34AM +0200, Peter Zijlstra wrote:
> On Thu, 2007-08-16 at 05:29 +0200, Nick Piggin wrote:
> > Well perhaps it doesn't work for networked swap, because dirty accounting
> > doesn't work the same way with anonymous memory... but for _filesystems_,
> > right?
> >
> > I
On Tue, Aug 21, 2007 at 01:02:01AM +0200, Segher Boessenkool wrote:
> >>And no, RMW on MMIO isn't "problematic" at all, either.
> >>
> >>An RMW op is a read op, a modify op, and a write op, all rolled
> >>into one opcode. But three actual operations.
> >
> >Maybe for some CPUs, but not all. ARM
On Mon, 2007-08-20 at 16:26 -0400, Mathieu Desnoyers wrote:
> plain text document attachment (module.c-sort-module-list.patch)
> A race that appears both in /proc/modules and in kallsyms: if, between the
> seq file reads, the process is put to sleep and at this moment a module is
> or removed from
Find maintainer info for a patch or a file
Changes since last submission:
Added -f to search for the maintainer for a specific file
Added --scm - Print the S: information
Added --web - Print the W: information
Added die message "git not found. Add --nogit to options"
Changed git log tracking
Add cmpxchg_local to sparc64
Use cmpxchg_u32 and cmpxchg_u64 for cmpxchg_local and cmpxchg64_local. For other
type sizes, use the new generic cmpxchg_local (disables interrupt).
Change:
* Julian Calaby ([EMAIL PROTECTED]) wrote:
> Shouldn't #includes go at the start of the file?
>
Since the
On 8/21/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 21 Aug 2007, Julian Calaby wrote:
>
> > >})
> > >
> > > +#include
> >
> > Shouldn't #includes go at the start of the file?
>
> Most of the timee but there are exceptions.
As with most things =)
However, in the context of
On Tue, 21 Aug 2007, Julian Calaby wrote:
> >})
> >
> > +#include
>
> Shouldn't #includes go at the start of the file?
Most of the timee but there are exceptions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On 8/21/07, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Use cmpxchg_u32 and cmpxchg_u64 for cmpxchg_local and cmpxchg64_local. For
> other
> type sizes, use the new generic cmpxchg_local (disables interrupt).
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
>
On Tue, Aug 21, 2007 at 09:27:06AM +1000, Neil Brown wrote:
> On Monday August 20, [EMAIL PROTECTED] wrote:
> > (cc's to me appreciated)
> >
> > It would be really, really nice if "umount -f" against a hung
> > NFS mount actually worked on Linux. As much as I hate Solaris,
> > I consider it the
On Mon, 2007-08-20 at 09:13 -0700, Jeremy Fitzhardinge wrote:
> Laurent Vivier wrote:
> > functionnalities:
> >
> > - allow to measure time spent by a CPU in a virtual CPU.
> > - allow to display in /proc/state this value by CPU
> > - allow to display in /proc//state this value by process
> > -
On Monday August 20, [EMAIL PROTECTED] wrote:
> (cc's to me appreciated)
>
> It would be really, really nice if "umount -f" against a hung NFS
> mount actually worked on Linux. As much as I hate Solaris, I
> consider it the gold standard in this case: If I say
> "umount -f /mount/that/is/hung"
>-Original Message-
>From: H. Peter Anvin [mailto:[EMAIL PROTECTED]
>Sent: Monday, August 20, 2007 3:27 PM
>To: Nelson, Shannon
>Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; Luck, Tony
>Subject: Re: [PATCH -mm] IOAT: fix for UP use of
I wrote:
> I've got a driver bug filed against 2.6.23-rc3-hrt2 with an oops beneath
> run_workqueue. It looks a lot like another bug in mainline with a panic
> beneath run_timer_softirq. Does -hrt replace tasklets by workqueues?
>
> http://bugzilla.kernel.org/show_bug.cgi?id=8906
>
On Mon, 21 Aug 2007, Andi Kleen wrote:
> Christoph Lameter <[EMAIL PROTECTED]> writes:
>
> > Switch off PF_MEMALLOC during both direct and kswapd reclaim.
> >
> > This works because we are not holding any locks at that point because
> > reclaim is essentially complete. The write occurs when the
Ingo Molnar writes:
> We seem to agree wrt. sched_clock()'s behavior while the virtual CPU is
> busy: sched_clock() very much wants to track virtual time. (real time is
> pretty much meaningless and coupling sched_clock() to real time would
> make the virtual machine's behavior dependent on
Roland McGrath writes:
> Hmm. Check the V=1 make output to see that the lparmap.c really got the -g0.
> The log says it didn't. Oops! It looks like the patch that got committed is
> the one that sets CFLAGS_lparmap.s, but really it needs to set
> CFLAGS_lparmap.o instead (go kbuild). Did I
And no, RMW on MMIO isn't "problematic" at all, either.
An RMW op is a read op, a modify op, and a write op, all rolled
into one opcode. But three actual operations.
Maybe for some CPUs, but not all. ARM for instance can't use the
load exclusive and store exclusive instructions to MMIO
I'm using 2.6.22.1 on my macbook (32bits). I had got this trace a few
hours after a suspend to disk. I never got this kind of trace without
suspend. I will try to reproduce with 2.6.22.3.
Here is the trace :
Aug 20 14:14:23 cocoduo kernel: kernel BUG at mm/slab.c:2980!
Aug 20 14:14:23 cocoduo
--
Content-Disposition: inline; filename=isdn-capi.patch
Convert from class_device to device for drivers/isdn/capi. This is
part of the work to eliminate struct class_device.
---
drivers/isdn/capi/capi.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
---
(cc's to me appreciated)
It would be really, really nice if "umount -f" against a hung NFS
mount actually worked on Linux. As much as I hate Solaris, I
consider it the gold standard in this case: If I say
"umount -f /mount/that/is/hung" it just goes away, immediately, and
anything still trying
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Mon, 20 Aug 2007 11:34:52 -0700 (PDT)
> On Fri, 17 Aug 2007, David Miller wrote:
>
> > When I force SLUB debugging on sparc64, it barfs on early bootup while
> > making the sysfs nodes. Removing the BUG()'s on the sysfs error
> > returns, and
--
Content-Disposition: inline; filename=misc.patch
Convert from class_device to device for drivers/misc/tifm. This is
part of the work to eliminate struct class_device.
---
drivers/misc/tifm_7xx1.c |4 ++--
drivers/misc/tifm_core.c | 24
include/linux/tifm.h
--
Content-Disposition: inline; filename=mfd.patch
Convert from class_device to device for drivers/mfd/ucb1x00. This is
part of the work to eliminate struct class_device.
---
drivers/mfd/ucb1x00-assabet.c | 17 +
drivers/mfd/ucb1x00-core.c| 14 +++---
--
Content-Disposition: inline; filename=usb-core.patch
Convert from class_device to device for drivers/ide/usb/core. Greg, not
sure if you're looking for a patch for this. Kay mentioned maybe it was to
be superceded by a diff mechanism. Free free to drop if so.
---
drivers/usb/core/hcd.c |
--
Content-Disposition: inline; filename=usb-host.patch
Convert from class_device to device for drivers/ide/usb/host. Greg, not
sure if you're looking for a patch for this. Kay mentioned maybe it was to
be superceded by a diff mechanism. Free free to drop if so. Thanks!
---
--
Content-Disposition: inline; filename=ide.patch
Convert from class_device to device for drivers/drivers/ide/ide-tape. This is
part of the work to eliminate struct class_device.
---
drivers/ide/ide-tape.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
---
--
Content-Disposition: inline; filename=dma.patch
Convert from class_device to device for drivers/dma/dmaengine. This is
part of the work to eliminate struct class_device.
---
drivers/dma/dmaengine.c | 43 ++-
include/linux/dmaengine.h |3 ++-
--
Content-Disposition: inline; filename=spi.patch
Convert from class_device to device for drivers/spi. This is part of the work
to eliminate struct class_device.
---
drivers/spi/spi.c | 36 ++--
drivers/spi/spi_bitbang.c |2 +-
--
Content-Disposition: inline; filename=wan.patch
Convert from class_device to device for drivers/net/wan/cosa. This is part of
the work to eliminate struct class_device.
---
drivers/net/wan/cosa.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/net/wan/cosa.c
--
Content-Disposition: inline; filename=mtd.patch
Convert from class_device to device for drivers/mtd/mtdchar. This is part of
the work to eliminate struct class_device.
---
drivers/mtd/mtdchar.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
---
--
Content-Disposition: inline; filename=aoechr.patch
Convert from class_device to device for block/aoechr. This is part of the
work to eliminate struct class_device.
---
drivers/block/aoe/aoechr.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
---
--
Content-Disposition: inline; filename=macintosh.patch
Convert from class_device to device for macintosh. This is part of the
work to eliminate struct class_device.
---
drivers/macintosh/adb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/macintosh/adb.c
+++
--
Content-Disposition: inline; filename=paride.patch
Convert from class_device to device for block/paride. This is part of the
work to eliminate struct class_device.
Signed-off-by: Tony Jones <[EMAIL PROTECTED]>
---
drivers/block/paride/pg.c |6 +++---
drivers/block/paride/pt.c | 12
--
Content-Disposition: inline; filename=block.patch
Convert from class_device to device for block/pktcdvd.
---
drivers/block/pktcdvd.c | 16 +++-
include/linux/pktcdvd.h |2 +-
2 files changed, 8 insertions(+), 10 deletions(-)
--- a/drivers/block/pktcdvd.c
+++
--
[patch 01/14] block/paride
[patch 02/14] block/pktcdvd
[patch 03/14] block/aoechr
[patch 04/14] drivers/macintosh
[patch 05/14] cosa sync driver
[patch 06/14] MTD/mtdchar
[patch 07/14] IDE/ide-tape
[patch 08/14] DMA engine
[patch 09/14] SPI
[patch 10/14] USB core
[patch 11/14] USB host
[patch
On Mon, Aug 20, 2007 at 03:22:47PM -0400, Robin Getz wrote:
> Try #4... (sorry)
>
> From: Robin Getz <[EMAIL PROTECTED]>
>
> This is a followup to the cleanups for earlyprintk patch from Gerd Hoffmann
>
>
On Tue, Aug 21, 2007 at 12:04:17AM +0200, Segher Boessenkool wrote:
> And no, RMW on MMIO isn't "problematic" at all, either.
>
> An RMW op is a read op, a modify op, and a write op, all rolled
> into one opcode. But three actual operations.
Maybe for some CPUs, but not all. ARM for instance
But there is no lparmap.o! lparmap.s is the generated file.
Yeah, tell that to scripts/Makefile.lib:
_c_flags = $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(basetarget).o)
What would do what a person expects is $(CFLAGS_$(@F)), I think.
Looks good to me. Sam? We wanted to set
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> @@ -1638,18 +1668,26 @@ static void __always_inline slab_free(st
> struct page *page, void *x, void *addr)
> {
> void **object = (void *)x;
> - unsigned long flags;
> + void **freelist;
> struct
In a way though, good thing, or mainline would have continued to be
broken :)
What do I need to do to see this bug, btw? A special config
symbol perhaps?
CONFIG_DEBUG_INFO=y
and pass-g-to-assembler-under-config_debug_info.patch from -mm
Ah, an -mm patch. Gotcha.
The fix most likely won't
Shannon Nelson wrote:
> Make sure we can use cpu_physical_id() even when compiled for
> uni-processor.
>
> diff --git a/drivers/dma/ioat_dca.c b/drivers/dma/ioat_dca.c
> index c3a500b..b1af49c 100644
> --- a/drivers/dma/ioat_dca.c
> +++ b/drivers/dma/ioat_dca.c
> @@ -25,6 +25,14 @@
> #include
>
Hi,
On Sat, 11 Aug 2007, Ingo Molnar wrote:
> the only relevant thing that comes to mind at the moment is that last
> week Peter noticed a buggy aspect of sleeper bonuses (in that we do not
> rate-limit their output, hence we 'waste' them instead of redistributing
> them), and i've got the
Such code generally doesn't care precisely when it gets the update,
just that the update is atomic, and it doesn't loop forever.
Yes, it _does_ care that it gets the update _at all_, and preferably
as early as possible.
Regardless, I'm convinced we just need to do it all in assembly.
So do
Christoph Lameter <[EMAIL PROTECTED]> writes:
> Switch off PF_MEMALLOC during both direct and kswapd reclaim.
>
> This works because we are not holding any locks at that point because
> reclaim is essentially complete. The write occurs when the memory on
> the zones is at the high water mark so
Right. ROTFL... volatile actually breaks atomic_t instead of making
it safe. x++ becomes a register load, increment and a register store.
Without volatile we can increment the memory directly. It seems that
volatile requires that the variable is loaded into a register first
and then operated
On Mon, 20 Aug 2007, Mathieu Desnoyers wrote:
> * Christoph Lameter ([EMAIL PROTECTED]) wrote:
> > On Mon, 20 Aug 2007, Mathieu Desnoyers wrote:
> >
> > > I'm digging in the slub with cmpxchg_local patch... first detail:
> > > slab_alloc seems to have a return path that does not reenable
> > >
On Mon, Aug 20, 2007 at 04:52:47PM -0400, Alan Stern wrote:
> On Mon, 20 Aug 2007, Michal Piotrowski wrote:
>
> > Subject : USB-related oops in sysfs with linux
> > v2.6.23-rc3-50-g28e8351
> > References : http://lkml.org/lkml/2007/8/15/144
> > Last known good : ?
> > Submitter
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> On Mon, 20 Aug 2007, Mathieu Desnoyers wrote:
>
> > I'm digging in the slub with cmpxchg_local patch... first detail:
> > slab_alloc seems to have a return path that does not reenable
> > preemption... I'll keep you posted when I finish the
Switch off PF_MEMALLOC during both direct and kswapd reclaim.
This works because we are not holding any locks at that point because
reclaim is essentially complete. The write occurs when the memory on
the zones is at the high water mark so it is unlikely that writeout
will get into trouble. If so
Direct reclaim collects a global laundry list in try_to_free_pages().
Pages are only written back after a reclaim pass is complete.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/vmscan.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
Index:
Both functions are equipped with an additional laundry parameter
that is then passed to shrink_page_list.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/vmscan.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
Index: linux-2.6/mm/vmscan.c
Collect dirty pages and perform writeout when everything else is done.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/vmscan.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: linux-2.6/mm/vmscan.c
This is necessary because we soon will do other things than calling
pageout() from shrink_page_list().
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/vmscan.c | 90 ++--
1 file changed, 45 insertions(+), 45 deletions(-)
If a laundry list is specified then do not write out pages but put
dirty pages on a laundry list for later processing.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/vmscan.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
Index:
1 - 100 of 792 matches
Mail list logo
