On Fri, 11 May 2007 23:09:15 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
> > >
> > > hm, Fedora don't seem to want to give me an RPM which contains acpidump
> > > and
> > > all the yum servers are featuring scrogged checksums. I could build it, I
> > > guess, but there's a principle i
This patch adds checking for allocated memory
which is used to hold AGP info. Also some whitespace
cleanup.
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
arch/alpha/kernel/core_marvel.c | 137 ---
1 files changed, 71 insertions(+), 66 deletions(-)
This patch adds checking for allocated memory
which is used to hold AGP info. Also some whitespace
cleanup.
Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
---
arch/alpha/kernel/core_titan.c | 99 +---
1 files changed, 52 insertions(+), 47 deletions(-)
Andrew Morton wrote:
Well yup. We're kind of waiting for someone to reply
to http://lkml.org/lkml/2007/5/7/129
Seems to be the same or at least related.
On comment about my first mail: this is the correct code of condvars,
despite what I wrote before. I wasn't thinking clear. The internal
On Fri, May 11, 2007 at 04:22:28PM -0500, Kumar Gala wrote:
>
> On May 11, 2007, at 4:08 PM, Sam Ravnborg wrote:
>
> >- Forwarded message from Sam Ravnborg <[EMAIL PROTECTED]> -
> >
> >Forgot lkml in first mail...
> >
> > Sam
> >
> >Subject: [RFC PATCH] kbuild: silence section mismatc
Satyam Sharma wrote:
>
> Because volatile is ill-defined? Or actually, *undefined* (well,
> implementation-defined is as good as that)? It's *so* _vague_,
> one doesn't _feel_ like using it at all!
>
Sorry, that's just utter crap. Linux isn't written in some mythical C
which only exists in stan
On Fri, 11 May 2007 23:10:47 -0700 Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> I hooked up FUTEX_CMP_REQUEUE_PI here and got a kernel crash.
Well yup. We're kind of waiting for someone to reply
to http://lkml.org/lkml/2007/5/7/129
-
To unsubscribe from this list: send the line "unsubscribe linux
On Fri, 11 May 2007 23:55:37 +0200
Rodolfo Giometti <[EMAIL PROTECTED]> wrote:
> Hello,
>
> here my new patch with a lot of fixes.
>
> The only issue not still fixed is the one related with:
>
> #define NETLINK_PPSAPI 20
>
> I need time to resolve it.
>
> Follows my comments an
On 5/12/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Satyam Sharma wrote:
>
>> + - Pointers to data structures in coherent memory which might be
>> modified
>> +by I/O devices can, sometimes, legitimately be volatile. A ring
>> buffer
>> +used by a network adapter, where that adapter c
I hooked up FUTEX_CMP_REQUEUE_PI here and got a kernel crash. No serial
console so this is the output of the screen after the machine stopped.
This is of course on x86-64. Compiled from a rawhide-ified upstream
kernel from two days ago.
The situation is the we requeue from a non-PI futex to
Hello,
here my new patch with a lot of fixes.
The only issue not still fixed is the one related with:
#define NETLINK_PPSAPI 20
I need time to resolve it.
Follows my comments and then the patch, hope now I can came back into
-mm tree again! :)
On Thu, May 10, 2007 at 12:27:52
Con wrote:
> Hmm I'm not really sure what it takes to make it cpuset aware;
> ...
> It is numa aware to some degree. It stores the node id and when it starts
> prefetching it only prefetches to nodes that are suitable for prefetching to
> ...
> It would be absolutely trivial to add a check for 'n
Hi Dmitry,
On 5/12/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
On Friday 11 May 2007 20:53, Andrew Morton wrote:
> Ho hum. I suppose a suitable workaround would be to convert hdaps_mtx back
> into a semaphore. ug.
Actually I was looking for victimes^Wvolunteers to test the patch below.
It ge
H. Peter Anvin wrote:
>
> I don't see why Alan's way is necessarily better; it should work but is
> more heavy-handed as it's disabling *all* optimization such as loop
> invariants across the barrier.
>
To expand on this further: the way this probably *should* be handled,
Linux-style, is with in
Satyam Sharma wrote:
>
>> + - Pointers to data structures in coherent memory which might be
>> modified
>> +by I/O devices can, sometimes, legitimately be volatile. A ring
>> buffer
>> +used by a network adapter, where that adapter changes pointers to
>> +indicate which descriptors h
pradeep singh wrote:
>
> Sorry, for my misunderstanding but i hope Jonathan actually means
> volatile harmful only in C and not while using extended asm with gcc? Or
> does you all consider volatile while using extended asm as harmful too?
> Incidentally i came to know that using volatile in such
On Fri, May 11, 2007 at 10:27:29AM +0530, Ananth N Mavinakayanahalli wrote:
> On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote:
> > * Alan Cox ([EMAIL PROTECTED]) wrote:
>
> ...
> > > > * Third issue : Scalability. Changing code will stop every CPU on the
> > > > system for a wh
On Saturday 12 May 2007 15:03, Paul Jackson wrote:
> > Swap prefetch is not cpuset aware so make the config option depend on
> > !CPUSETS.
>
> Ok.
>
> Could you explain what it means to say "swap prefetch is not cpuset aware",
> or could you give a rough idea of what it would take to make it cpuset
On Friday 11 May 2007 20:53, Andrew Morton wrote:
> Ho hum. I suppose a suitable workaround would be to convert hdaps_mtx back
> into a semaphore. ug.
Actually I was looking for victimes^Wvolunteers to test the patch below.
It gets rid of _trylock business.
--
Dmitry
HWMON: hdaps - convert to
Hi,
On Friday 11 May 2007 23:18, Yin,Fengwei wrote:
>
> So if the evdev_release() is preempted at the point marked by another
> process which will open the evdev, which will make operation sequence
> like:
>
>--evdev->open in evdev_release()
> -> preempted
>
> Swap prefetch is not cpuset aware so make the config option depend on
> !CPUSETS.
Ok.
Could you explain what it means to say "swap prefetch is not cpuset aware",
or could you give a rough idea of what it would take to make it cpuset aware?
I wouldn't go so far as to say that no one would ever
It turns out that fixing swap prefetch was not that hard to fix and improve
upon, and since Andrew hasn't dropped swap prefetch, instead here are a swag
of fixes and improvements, including making it depend on !CPUSETS as Nick
requested.
These changes lead to dramatic improvements.
Eg on a mac
Satyam Sharma wrote:
On 5/11/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
+ - Pointers to data structures in coherent memory which might be
modified
+by I/O devices can, sometimes, legitimately be volatile. A ring
buffer
+used by a network adapter, where that adapter changes pointe
Words by Matt Mackall [Fri, May 11, 2007 at 09:39:05PM -0500]:
> On Sat, May 12, 2007 at 02:40:52AM +0100, Jose Celestino wrote:
> > Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]:
> > > On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote:
> > > >
> > > > What's eating
To: Richard-san
I'm sorry. The patch sent yesterday is corrected.
Only the ledtrig_bitpat_default function was changed.
The patch of "Custom triggers support, which are might not supported by all
LEDs"
is necessary.
LED driver of I-O DATA LANDISK and USL-5P
Signed-off-by: kogiidena <[EMAIL PROT
To: Richard-san
I'm sorry. The patch sent yesterday is corrected, too.
Because the source had not been read easily, it cleaned it.
There is no change for the basic function.
Add Bitpattern Trigger.
Bitpattern continuously turns LED on and off according to
the value directed "bitdata". "bitdata" i
I agree that we should keep the "platform" default,
as it went in 2 releases ago (nearly 6 months) without
any reported failures until this one -- and it fixed
a longstanding issue documented on many machines.
We should debug Qi's failure like any other.
We are actually in better shape on this one
On Fri, May 11, 2007 at 11:39:20AM +0200, Tejun Heo wrote:
> Paul Mundt wrote:
> > Bumping the hardreset delay up does indeed fix it, I've had to bump it up
> > to 1200 before it started working (at 600 it still fails):
> >
> > [0.967379] scsi0 : sata_sil
> > [0.970425] scsi1 : sata_sil
>
> > We're trying to track down the source of a problem that occurs
> > whenever the atl1 network driver is activated on a 32-bit 2.6.21-rc4
>
> and -rc5, -rc6, 2.6.20.x, 2.6.19.3, and probably others.
>
> > We can load the driver just fine, but whenever we activate the
> > network, we see APIC er
On 5/11/07, Jonathan Corbet <[EMAIL PROTECTED]> wrote:
Here's another version of the volatile document. Once again, I've tried
to address all of the comments. There haven't really been any recent
comments addressing the correctness of the document; people have been
more concerned with how it's
Hi,
When open/close evdev, the code is as following to handle multi-client
operation:
static int evdev_release(...)
{
...
if (!--evdev->open) {
exist)
input_close_device(...);
e
In article <[EMAIL PROTECTED]> you wrote:
> However, there are a large number of applications which have registered
> ports in this range.
And some application who request random listening ports actually query the
/etc/services file to ensure it is a "unnamed" port.
Gruss
Bernd
-
To unsubscribe f
On 5/12/07, Simon Arlott <[EMAIL PROTECTED]> wrote:
Spelling fix in init/.
Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
---
init/main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/init/main.c b/init/main.c
index e8d080c..7ee2031 100644
--- a/init/main.c
+++ b/in
Hi Sam,
On May 11, 2007, at 4:08 PM, Sam Ravnborg wrote:
> Following patch allow us in specific places to silence section
> mismatch warnings.
Well, I had spelled out my reservations about this earlier, but I don't feel
too strongly. Most people probably do not want / prefer to see warnings
(e
On Sat, May 12, 2007 at 02:40:52AM +0100, Jose Celestino wrote:
> Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]:
> > On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote:
> > >
> > > What's eating the battery life of my laptop? Why isn't it many more
> > > hours? Which
Benny Halevy <[EMAIL PROTECTED]> wrote:
>
> I was trying to say that the methods should be compatible, otherwise
> bugs can happen, and that your scheme is better since it can
> handle sglists with zero length entries that aren't the last.
> A case that might be valid after dma mapping and merging.
Changes the rwlock to a spinlock, and drops the use-count variable.
Operations are always bound by the mutex now, so the use-count is
no more needed. For the same reason, the rwlock can become a simple
spinlock.
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
Index: linux-2.6.21/f
On Fri, 2007-05-11 at 13:26 -0700, David Miller wrote:
> Hi Michael, I'm still working through the various regressions on
> sparc64 added by your MSI changes :-)
Hi Dave,
Guilty as charged - I did CC you on the patches though ;)
> The one I fixed the other day was a missed switch over to
> alloc
Fixes the epoll single pass code. During the unlocked event delivery
(to userspace) code, the poll callback can re-issue new events, and
we must receive them correctly. Since we loop in a lockless fashion,
we want to be O(nready), and we don't want to flash on/off the spinlock
for every event, we h
On Fri, 11 May 2007 09:19:32 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
> On Fri, 11 May 2007 16:42:07 +1000 Stephen Rothwell wrote:
>
> > This address bounces with "550 Unknown user".
> >
> > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
> > ---
> > MAINTAINERS |1 -
> > 1 files ch
On Fri, 2007-05-11 at 11:40 +0100, Andy Whitcroft wrote:
> Michael Ellerman wrote:
> > On Fri, 2007-05-11 at 00:16 -0700, Greg KH wrote:
> >> On Thu, May 10, 2007 at 04:54:41PM +0100, Andy Whitcroft wrote:
> >>> Greg KH wrote:
> On Thu, May 10, 2007 at 03:00:50PM +0100, Andy Whitcroft wrote:
>
David Miller wrote:
>
> All ports above and including 1024 are non-privileged and available to
> anyone.
>
> Applications which have some requirements in this area need to work
> those things out themselves.
However, there are a large number of applications which have registered
ports in this ra
Fix misc small issues/typos/grammar in Kconfigs for 2.6.21-git15.
Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]>
--
diff -ru a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig
--- a/arch/arm/plat-s3c24xx/Kconfig 2007-04-25 23:08:32.0 -0400
+++ b/arch/arm/plat-s3c24xx/Kc
Mark Glines wrote:
>
> By a one-in-a-million coincidence, this machine has a default port
> range starting with 2048, and this breaks things for me. I'm trying to
> run both klive and nfs on this box, but klive starts first (probably
> because of the filename sort order), and claims UDP port 2049
On Sat, 12 May 2007 10:33:00 +0900
Paul Mundt <[EMAIL PROTECTED]> wrote:
> On Fri, May 11, 2007 at 11:39:15AM -0700, Andrew Morton wrote:
> > On Fri, 11 May 2007 09:57:50 -0700
> > [EMAIL PROTECTED] wrote:
> >
> > > > I'll take a look at tidying up the PMB slab, getting rid of the dtor
> > > > sh
Words by Matt Mackall [Fri, May 11, 2007 at 07:17:19PM -0500]:
> On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote:
> >
> > What's eating the battery life of my laptop? Why isn't it many more
> > hours? Which software component causes the most power to be burned?
> > These are imp
On Fri, May 11, 2007 at 08:43:12PM +0100, Simon Arlott wrote:
> Spelling fixes in arch/sh/.
>
> Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
On Fri, May 11, 2007 at 08:43:19PM +0100, Simon Arlott wrote:
> Spelling fixes in arch/sh64/.
>
> Signed-off-by: Simon Arlott <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Fri, May 11, 2007 at 11:39:15AM -0700, Andrew Morton wrote:
> On Fri, 11 May 2007 09:57:50 -0700
> [EMAIL PROTECTED] wrote:
>
> > > I'll take a look at tidying up the PMB slab, getting rid of the dtor
> > > shouldn't be terribly painful. I simply opted to do the list management
> > > there sinc
On Fri, May 11, 2007 at 09:57:51AM -0700, [EMAIL PROTECTED] wrote:
> There is no user of destructors left. There is no reason why we should
> keep checking for destructors calls in the slab allocators.
>
> The RFC for this patch was discussed at
> http://marc.info/?l=linux-kernel&m=117882364330705
--- Davide Libenzi wrote:
> Charles, would you mind trying the patch below
> against -git13 on your
> machine. I tested it with wine and firefox on a 32
> bit P4 with HT and it's
> working fine.
i applied the patch against git13. starcraft,
pokerstars, and firefox under wine have not frozen.
On Sat, 12 May 2007, Oleg Nesterov wrote:
>
> However, in my opininon THAT PATCH has nothing to do with this problem.
> It just improves the code that we already have.
Sure.
However, I think it does it THE WRONG WAY, and doesn't actually fix the
much deeper problems with the freezer, as show
On Fri, 11 May 2007 17:53:35 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> And indeed that's buggy - the non-debug version of spin_lock_mutex() is not
> irq-safe.
>
> I'd say that's pretty dumb of the mutex interface, really. Doing a
> mutex_trylock() should be OK from all contexts.
We can f
On Saturday, 12 May 2007 02:08, Linus Torvalds wrote:
>
> On Sat, 12 May 2007, Oleg Nesterov wrote:
> >
> > things change, ->mm is not stable if the kernel thread does use_mm/unuse_mm.
>
> ->mm is not stable *regardless*!
>
> Trivial examples:
> - kernel thread does execve()
> - user thread d
On Sat, 12 May 2007 00:06:45 UTC
David Miller <[EMAIL PROTECTED]> wrote:
> All ports above and including 1024 are non-privileged and available to
> anyone.
>
> Applications which have some requirements in this area need to work
> those things out themselves.
Hi David,
I agree completely. My iss
On Fri, 11 May 2007, Simon Arlott wrote:
> - * Local routines to interrcept the standard I/O and vector handling
> - * code. Don't include this 'till now - initialization code above needs
> + * Local routines to intercept the standard I/O and vector handling
> + * code. Don't include thi
On 05/12, Oleg Nesterov wrote:
>
> Do we need freezer? Should we freeze kernel threads? I can't judge. I tried
> to read a long thread about suspend, and failed to understand it.
>
> I personally think we can simplify things if CPU-hotplug use freezer, at
> least.
Just a small example,
On Fri, 11 May 2007 19:21:15 -0500
Matt Mackall <[EMAIL PROTECTED]> wrote:
> This just hit:
>
> [7.856000] usbcore: registered new interface driver usbhid
> [7.86] BUG: at kernel/mutex.c:311 __mutex_trylock_slowpath()
> [7.868000] [] show_trace_log_lvl+0x1a/0x30
> [7.872000]
Gerd Hoffmann <[EMAIL PROTECTED]> writes:
> Hi,
>
> Checking video mode field only to see whenever SCREEN_INFO is
> initialized is not enougth, in some cases it is zero although
> a vga card is present. Lets additionally check cols and lines.
Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
On 05/11, Linus Torvalds wrote:
>
> On Sat, 12 May 2007, Oleg Nesterov wrote:
> >
> > things change, ->mm is not stable if the kernel thread does use_mm/unuse_mm.
>
> ->mm is not stable *regardless*!
>
> Trivial examples:
> - kernel thread does execve()
> - user thread does exit().
Yes sure.
On Fri, 11 May 2007, Oliver Xymoron wrote:
> And no sign of further progress. SLAB worked fine.
Add slub_debug to the command line. Any changes or any additional
diagnostic output?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
Kevin Winchester wrote:
> Not sure if you were looking for testing, but I fuzzed it to apply to
> 2.6.21-git and gave it a spin. Worked just like a normal boot (which I
> assume was the point).
That would be the point, yes :) Looking for breakage in video mode
detection, memory detection, and AP
On Fri, 11 May 2007, Andrew Morton wrote:
> However I think we've done enough slab work for 2.6.22 now so I'm inclined
> to queue these changes for 2.6.23. That would mean that the slab changes in
> -mm have a dependency on the sh git tree which I am sure to forget about.
> If I end up merging th
This just hit:
[7.856000] usbcore: registered new interface driver usbhid
[7.86] BUG: at kernel/mutex.c:311 __mutex_trylock_slowpath()
[7.868000] [] show_trace_log_lvl+0x1a/0x30
[7.872000] [] show_trace+0x12/0x14
[7.876000] [] dump_stack+0x15/0x17
[7.88] [] mute
On Fri, May 11, 2007 at 04:07:18PM -0700, Arjan van de Ven wrote:
>
> What's eating the battery life of my laptop? Why isn't it many more
> hours? Which software component causes the most power to be burned?
> These are important questions without a good answer... until now.
I get:
No detailed
On Saturday, 12 May 2007 01:25, Andrew Morton wrote:
> On Sat, 12 May 2007 01:22:06 +0200
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> > On Saturday, 12 May 2007 00:56, Linus Torvalds wrote:
> > >
> > > On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> > > >
> > > > For user space processe
On Sat, 12 May 2007, Oleg Nesterov wrote:
>
> things change, ->mm is not stable if the kernel thread does use_mm/unuse_mm.
->mm is not stable *regardless*!
Trivial examples:
- kernel thread does execve()
- user thread does exit().
The use "use_mm()" and "unuse_mm()" things are total red her
Simon Arlott writes:
> Spelling fixes in arch/powerpc/.
> - /* Retreive CPU related informations from the flat tree
> + /* Retreive CPU related information from the flat tree
^^
You missed one. :)
> - /* Clear the freeze bit, and reenable the interrupt.
> + /* Clea
From: Mark Glines <[EMAIL PROTECTED]>
Date: Fri, 11 May 2007 17:01:35 -0700
> Following the principle of least astonishment, I think it seems better
> to use high, out-of-the-way port numbers regardless of how much RAM the
> system has. So, the following patch changes this behavior slightly.
> Th
I hope Rafael will correct me if I am wrong,
On 05/12, Oleg Nesterov wrote:
>
> On 05/11, Linus Torvalds wrote:
> >
> > On Sat, 12 May 2007, Oleg Nesterov wrote:
> > >
> > > without task_lock() we can see "p->mm != NULL" but not PF_BORROWED_MM.
> >
> > Let me explain it one more time:
> > - sho
On a powerpc machine (kurobox) I have here with 128M of RAM, the default
value of /proc/sys/net/ipv4/ip_local_port_range is:
20484999
This setting affects the port assigned to an application by default
when the application doesn't specify a port to use, like, for instance,
an outgoing connecti
H. Peter Anvin wrote:
> Hello all,
>
> I believe the x86 setup tree is now finished. I will turn it into a
> "clean patchset" later this week, but I wanted to get flamed^W feedback
> on it first.
>
> The git tree is at:
>
> http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=sum
On Saturday, 12 May 2007 01:29, Linus Torvalds wrote:
>
> On Sat, 12 May 2007, Rafael J. Wysocki wrote:
> >
> > We use this function (ie. kernel/power/process.c:is_user_space()) to
> > distinguish kernel threads from user space processes. Therefore we make it
> > always return true for user space
On 05/11, Linus Torvalds wrote:
>
> On Sat, 12 May 2007, Oleg Nesterov wrote:
> >
> > without task_lock() we can see "p->mm != NULL" but not PF_BORROWED_MM.
>
> Let me explain it one more time:
> - shouldn't the *caller* protect this?
>
> Afaik, there's two situations:
> - either things don't c
On Fri, 11 May 2007, Andrew Morton wrote:
> I could reverse-engineer that info from the patch, I guess, but I'd
> prefer to go in the opposite direction: you tell us what the patch is
> trying to do, then we look at it and see if we agree that it is in fact
> doing that.
I've just quickly look
Hi,
On Fri, May 11, 2007 at 12:51:32PM -0700, Andrew Morton wrote:
> On Fri, 11 May 2007 10:45:31 +0200
> Tomas Janousek <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > On Thu, May 10, 2007 at 04:40:47PM -0700, Andrew Morton wrote:
> > > Tomas Janousek <[EMAIL PROTECTED]> wrote:
> > > > @@ -445,
On Sat, 12 May 2007, Oleg Nesterov wrote:
>
> without task_lock() we can see "p->mm != NULL" but not PF_BORROWED_MM.
Let me explain it one more time:
- shouldn't the *caller* protect this?
Afaik, there's two situations:
- either things don't change (in which case you don't need locking at
On Sat, 12 May 2007, Rafael J. Wysocki wrote:
>
> We use this function (ie. kernel/power/process.c:is_user_space()) to
> distinguish kernel threads from user space processes. Therefore we make it
> always return true for user space processes and always return false for kernel
> threads. In the
On Sat, 12 May 2007 01:22:06 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> On Saturday, 12 May 2007 00:56, Linus Torvalds wrote:
> >
> > On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> > >
> > > For user space processes this condition is always true.
> > >
> > > For kernel threads:
> >
Rene Herman <[EMAIL PROTECTED]> writes:
> /* Author, ideally of form NAME [, NAME ]*[ and NAME ]
>
> After my trivial patch, it says:
>
> /* Author, ideally of form NAME[, NAME]*[ and NAME] */
I think I would put something like this:
/* Author, of form NAME[, NAME]*[ and NAME]
* If you have a p
Hi!
> > Just to clarify, the change in question isn't new. It was introduced by the
> > commit 9185cfa92507d07ac787bc73d06c4eec7239 before 2.6.20, at Seife's
> > request and with Pavel's acceptance.
>
> Ok, if it's that old, we migt as leave it in. Clearly there weren't many
> regressions,
Robert Hancock wrote:
The ATA ones are more of a pain in that regard than SCSI though - SCSI
has all distinct error codes for different errors, whereas ATA has
bitmasks for everything..
That should not affect implementation. Either way, a table-driven
approach can easily work.
I favor deco
On 05/11, Linus Torvalds wrote:
>
> On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> >
> > Therefore, by taking the task_lock() here we make sure that the condition
> > is alyways false when we check it for kernel threads.
>
> Why *test* it then and return anything?
>
> Why not just doa "task_loc
On Saturday, 12 May 2007 00:56, Linus Torvalds wrote:
>
> On Fri, 11 May 2007, Rafael J. Wysocki wrote:
> >
> > For user space processes this condition is always true.
> >
> > For kernel threads:
> > (1) the change of tsk->mm from NULL to a nonzero value is only made in
> > fs/aio.c:use_mm() alo
Tejun Heo wrote:
Chuck Ebbert wrote:
Robert Hancock wrote:
+ ehc->i.serror & SERR_TRANS_ST_ERROR ? "TransStatTransErr "
: "",
+ ehc->i.serror & SERR_UNRECOG_FIS ? "UnrecogFIS " : "",
+ ehc->i.serror & SERR_DEV_XCHG ? "DevExchanged " : "" );
I'm not really convinced w
What's eating the battery life of my laptop? Why isn't it many more
hours? Which software component causes the most power to be burned?
These are important questions without a good answer... until now.
The Linux 2.6.21 kernel introduces the so called tickless-idle
feature. This feature allow
The git tree at
git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
could be set up in a simpler way:
$ git ls-remote
git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
fc4b5be9e651d3e71b54541e0315fc82211b42b5refs/heads/option_export
59a1fe35614c
From: Heiko Carstens <[EMAIL PROTECTED]>
Looks like these two are wired up in a wrong way.
Cc: Davide Libenzi <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---
arch/x86_64/ia32/ia32entry.S |6 +++---
1 file changed, 3 insertions(+),
From: Heiko Carstens <[EMAIL PROTECTED]>
Add missing cond_syscall statements for compat_sys_signalfd
and compat_sys_timerfd.
Cc: Davide Libenzi <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---
Index: linux-2.6/kernel/sys_ni.c
=
On 05/11, Peter Zijlstra wrote:
>
> +static inline int __rw_mutex_read_trylock(struct rw_mutex *rw_mutex)
> +{
> + preempt_disable();
> + if (likely(!__rw_mutex_reader_slow(rw_mutex))) {
--- WINDOW ---
> + percpu_counter_mod(&rw_mutex->readers, 1);
> + pre
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
>
> For user space processes this condition is always true.
>
> For kernel threads:
> (1) the change of tsk->mm from NULL to a nonzero value is only made in
> fs/aio.c:use_mm() along with the setting of PF_BORROWED_MM under
> the task_lock(),
> (2)
On Thu, 10 May 2007 16:57:14 -0700 Jeremy Fitzhardinge wrote:
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -2208,3 +2208,61 @@ asmlinkage long sys_getcpu(unsigned __us
> +
> +/**
> + * Trigger an orderly system poweroff
* orderly_poweroff - Trigger an orderly system poweroff
> + * @force:
On Thu, 10 May 2007 16:57:12 -0700 Jeremy Fitzhardinge wrote:
> --- /dev/null
> +++ b/lib/argv_split.c
> @@ -0,0 +1,159 @@
> +
> +/**
> + * argv_free - free an argv
> + *
extra "blank" line.
> + * @argv - the argument vector to be freed
> + *
> + * Frees an argv and the strings it points to.
> +
ACK -- this regression was fixed by Trond's recent NFS bugfix push upstream.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
>
> Just to clarify, the change in question isn't new. It was introduced by the
> commit 9185cfa92507d07ac787bc73d06c4eec7239 before 2.6.20, at Seife's
> request and with Pavel's acceptance.
Ok, if it's that old, we migt as leave it in. Clearly
On 5/11/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
erm, I was being funny. If you randomize a binary it won't run any more.
cp /dev/random /bin/login. Oh well.
My point is, we're not being told what is being randomized here. Is it the
virtual starting address of the main executable mmap? O
Current git, on Fedora 6/x86-64:
fs/nfs/read.c: In function ‘nfs_return_empty_page’:
fs/nfs/read.c:82: warning: ‘memclear_highpage_flush’ is deprecated
(declared at include/linux/highmem.h:115)
fs/nfs/read.c: In function ‘nfs_readpage_truncate_uninitialised_page’:
fs/nfs/read.c:106: warning: ‘m
Tejun Heo wrote:
+ if (class == ATA_DEV_ATA)
+ class = ATA_DEV_ATAPI;
+ else
+ class = ATA_DEV_ATA;
the 'else' branch is obviously redundant
-
To unsubscribe from this list: send the line "
Tejun Heo wrote:
It seems the world isn't as frank as we thought and some devices lie
about who they are. Fallback to the other IDENTIFY if IDENTIFY is
aborted by the device. As this is the strategy used by IDE for a long
time, it shouldn't cause too much problem.
Signed-off-by: Tejun Heo <[EM
Hi,
This patch adds a soft release key mask to input_dev, to enable keyboard
drivers to determine which keys never generate a hardware release event and
hence add a release event after every press event of such keys. The mask is
controlled by ioctls.
The Fn+F? key combinations of Dell Latitude se
1 - 100 of 414 matches
Mail list logo
