-stable review patch. If anyone has any objections, please let us know.
--
From: su henry <[EMAIL PROTECTED]>
The SATA controller device ID is different according to
the onchip SATA type set in the system BIOS:
Device Device ID
SATA in IDE mode
-stable review patch. If anyone has any objections, please let us know.
--
From: Timo Jantunen <[EMAIL PROTECTED]>
If the forcedeth driver receives too much work in an interrupt, it
assumes it has a broken hardware with stuck IRQ. It works around the
problem by disabling interrup
-stable review patch. If anyone has any objections, please let us know.
--
From: Andrew Morton <[EMAIL PROTECTED]>
Revert 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26. It broke S??bastien Dugu??'s
machine and Jeff said (persuasively)
This seems like it will break decades-long-wor
-stable review patch. If anyone has any objections, please let us know.
--
From: Francois Romieu <[EMAIL PROTECTED]>
Theory : though needless, it should not have hurt.
Practice: it does not play nice with DEBUG_SHIRQ + LOCKDEP + UP
(see https://bugzilla.redhat.com/bugzilla/show_
-stable review patch. If anyone has any objections, please let us know.
--
From: Haavard Skinnemoen <[EMAIL PROTECTED]>
These functions depend on "result" being initalized to 0, but "result"
is not included as an input constraint to the inline assembly block
following its initial
-stable review patch. If anyone has any objections, please let us know.
--
From: Bob Moore <[EMAIL PROTECTED]>
ACPICA: Fixed possible corruption of global GPE list
Fixed a problem in acpi_ev_delete_gpe_xrupt where the global interrupt
list could be corrupted if the interrupt be
-stable review patch. If anyone has any objections, please let us know.
--
From: Bob Moore <[EMAIL PROTECTED]>
ACPICA: Clear reserved fields for incoming ACPI 1.0 FADTs
Fixed a problem with the internal FADT conversion where ACPI 1.0
FADTs that contained invalid non-zero values
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Backport of commit 5c11ce700f77fada15b6264417d72462da4bbb1c
This patch avoids generating another IRQ if more packets
arrive while in the NAPI poll routine. Befo
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Backport of commit 71749531f2d1954137a1a77422ef4ff29eb102dd
If packet larger than MTU is received, the driver uses hardware to
truncate the packet. Use the stat
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
backport of commit 55d7b4e6ed6ad3ec5e5e30b3b4515a0a6a53e344
Make sky2 handle carrier similar to other drivers,
eliminate some possible races in carrier state tr
On Mon, 20 Aug 2007, David Brownell wrote:
>
> Try disabling USB_SUSPEND ... the rather aggressive powersave
> mechanism (autosuspend defaulting to always ON) has made lots
> of trouble. I think that default will change...
It's already disabled - so that's not it.
Linus
-
To u
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Backport of commit c59697e06058fc2361da8cefcfa3de85ac107582
This patch restores a couple of workarounds from 2.6.16:
* restart transmit moderation timer in cas
-stable review patch. If anyone has any objections, please let us know.
--
From: Jean Delvare <[EMAIL PROTECTED]>
The smsc47m1 driver no longer creates the name attribute used by
libsensors to identify chip types. It was lost during the conversion
to a platform driver. I was foo
-stable review patch. If anyone has any objections, please let us know.
--
From: "Mark M. Hoffman" <[EMAIL PROTECTED]>
Commit 348753379a7704087603dad403603e825422fd9a introduced a regression that
caused temp2 and temp3 sensor type settings to be written to temp1 instead.
The resu
This is the start of the stable review cycle for the 2.6.22.5 release.
There are 20 patches in this series, all will be posted as a response to
this one. If anyone has any issues with these being applied, please let
us know. If anyone is a maintainer of the proper subsystem, and wants
to add a Si
On Mon, 20 Aug 2007, Arjan van de Ven wrote:
>
> On Mon, 2007-08-20 at 23:26 -0700, Linus Torvalds wrote:
> >
> > On Mon, 20 Aug 2007, Arjan van de Ven wrote:
> > >
> > > untested patch to add this to cpufreq; this is probably a good idea in
> > > general even if using the latency framework d
Am Montag, 20. August 2007 schrieb Alan Stern:
> I could, but I don't know whether any of this would be accepted for
> 2.6.22.stable. It might not be too late to get into 2.6.23...
even without it is a first step. I hope it gets accepted into both,
as 2.6.22 broke kernel<->user space interfaces a
Thanks! That perfectly answered my question.
-x
On 8/21/07, Kevin Hao <[EMAIL PROTECTED]> wrote:
> > I am curious how Linux convert an fd to the pathname? Does it
> > recursively walk back from current dentry to the root?
> Using d_path.
> > Can someone point me to the right place in the kernel
On Monday 20 August 2007, Linus Torvalds wrote:
>
> On Mon, 20 Aug 2007, Linus Torvalds wrote:
> >
> > Ok. But in the meantime, I really think we should just revert the code
> > that causes a known regression.
>
> Side note: one reason I'm interested in this is that my mac mini (now used
> by
On Mon, 2007-08-20 at 23:26 -0700, Linus Torvalds wrote:
>
> On Mon, 20 Aug 2007, Arjan van de Ven wrote:
> >
> > untested patch to add this to cpufreq; this is probably a good idea in
> > general even if using the latency framework doesn't end up being used
> > for fixing this regression...
> >
On Mon, 2007-08-20 at 23:25 -0700, Linus Torvalds wrote:
> Do we actually have the latency information for these things? Especially
> since I assume a number of people use the specialized direct-hw-access
> cpufreq drivers..
>
> I realize that we *have* "transition_latency" at the cpufreq laye
Dear all,
I suddenly got flodded with
Bad pte = e900b50d, process = ???, vm_flags = 100173, vaddr = bfc87ee2
[] vm_normal_page+0x3e/0x53
[] follow_page+0x90/0x147
[] get_user_pages+0x20f/0x261
[] access_process_vm+0x7e/0x163
[] vma_merge+0x171/0x17f
[] proc_pid_cmdline+0x57/0xe7
[] proc_in
On Mon, 20 Aug 2007, Arjan van de Ven wrote:
>
> untested patch to add this to cpufreq; this is probably a good idea in
> general even if using the latency framework doesn't end up being used
> for fixing this regression...
>
>
> --- linux-2.6.23-rc2/drivers/cpufreq/cpufreq.c.org2007-08-20
On Mon, 20 Aug 2007, Arjan van de Ven wrote:
> >
> > So it might be much better if we instead re-introduced that kind of "DMA
> > latency requirement", and letting different subsystems react to that as
> > they may.
>
> wait we HAVE that infrastructure .. see kernel/latency.c ...
Heh. Ju
On Mon, 2007-08-20 at 22:51 -0700, Arjan van de Ven wrote:
> and the C-state code will honor it. CPUFREQ doesn't honor it yet but
> that's easy to add..
untested patch to add this to cpufreq; this is probably a good idea in
general even if using the latency framework doesn't end up being used
for
On Thu, Aug 16, 2007 at 02:53:50PM +0300, Dan Aloni wrote:
> On Sun, Jul 01, 2007 at 07:37:49PM +0400, Oleg Nesterov wrote:
> > I don't know how to test this patch, the ack/nack from maintainer is wanted.
> >
> > flush_scheduled_work() is evil and should be avoided. Change tty_set_ldisc()
> > and
> Blame intel ;)
>
> > Any other ideas and suggestions?
>
> Without knowing exactly what you are doing:
>
> - Copies to uncached memory are very expensive on an x86 processor
> (so it might be faster not to write and flush)
> - Its not clear from your description how intelligent your transfer
> sys
>
> Write-combining access seems the correct thing here, followed by a
> wmb(). Uncached writing would be horrendously slow.
>
> [snip]
> > So after all that I'd like to have some sort of uncached page list I
> > can allocate pages from
>
> This is exactly what Intel's PAT mechanism exists for - ju
> I am curious how Linux convert an fd to the pathname? Does it
> recursively walk back from current dentry to the root?
Using d_path.
> Can someone point me to the right place in the kernel where this
> functionality is implemented?
do_proc_readlink may be the function you want.
-
To unsubscribe
On Mon, 20 Aug 2007, Linus Torvalds wrote:
>
> Ok. But in the meantime, I really think we should just revert the code
> that causes a known regression.
Side note: one reason I'm interested in this is that my mac mini (now used
by the kids) has had a very flaky USB mouse lately. Is it related?
> 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).
>
> S
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 places
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 PROTEC
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 a/dr
>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 ask
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 co
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 f
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 thermal_th
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 serio
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 th
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 f20561f
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]>
S
[ 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 no
> -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 PR
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 PROTECT
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.
Fair
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 majordom
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 e
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 th
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 a/scripts/get_maintainer
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 pr
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 taskstats
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. me
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 wrote
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 "unsubscribe
[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 w
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 trans
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 manu
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 l
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 are
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 +55
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, th
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 gener
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 m
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 f
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 in
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 hea
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 this
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 ma
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]
> CC:
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 g
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
> > - all
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" it
>-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 cpu_phy
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
> http://bugzil
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 the
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 pos
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 space.
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 ker
--
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(-)
--- a/drivers/isdn/capi/ca
(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 to
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 add
--
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 +++---
drivers/mf
--
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 |
1 - 100 of 421 matches
Mail list logo
