On Tue, 2007-06-05 at 08:36 +1000, Nigel Cunningham wrote:
> I spent some time, last I think, seriously considering this approach.
> The more I thought about the details, the more I realised that it wasn't
> a viable approach. As I said before, it does indeed sound like a dream
> at first, but
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 10:11:56 +0200
> > > I just want to win the "who's laziest?" league. It would take me
> > > about 5 minutes to get the netdev tree and test compile the change.
> > > Of which 5 seconds would be actually updating the patch. I was
>
On Tue, Jun 05, 2007 at 09:33:35AM +0200, Oleg Verych wrote:
> Hallo.
>
> On Sun, Jun 03, 2007 at 10:47:00PM +0200, Sam Ravnborg wrote:
> > Subject: [PATCH 08/19] scripts: Make cleanfile/cleanpatch warn about long
> > lines
> > From: H. Peter Anvin <[EMAIL PROTECTED]>
> > Date: Fri, 25 May 2007
On Mon, Jun 04, 2007 at 10:46:24AM +0100, Andy Whitcroft wrote:
>
> This version brings a host of changes to cure false positives and
> bugs detected on patches submitted to lkml and -mm. It also brings
> a number of new tests in response to reviews, of particular note:
>
> - catch use of
> > I just want to win the "who's laziest?" league. It would take me
> > about 5 minutes to get the netdev tree and test compile the change.
> > Of which 5 seconds would be actually updating the patch. I was
> > thought it was OK to pass that 5 seconds worth of hard work to you in
> > order to
On Jun 5 2007 00:35, Mike Richards wrote:
>
> In my research on this matter I've come across various comments by
> people saying that getting rid of swap entirely will hurt performance
> somehow, but on these servers I'm seeing very little swap used in the
> first place, so I'm not seeing how
Stefan, Mircea,
reagarding your Turion cpufreq issues - is that solved by now?
http://lkml.org/lkml/2007/4/8/59
Regards,
Peter Oruba
--
AMD Saxony Limited Liability Company & Co. KG
Operating System Research Center
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA
On Mon, Jun 04, 2007 at 11:53:13PM -0700, David Miller wrote:
> From: Sam Ravnborg <[EMAIL PROTECTED]>
> Date: Sat, 2 Jun 2007 21:16:46 +0200
>
> > >
> > > promcon_init() can be called again from visual_init() during
> > > vc_allocate(). So anything referenced by promcon_init() should not be
>
* Li Yu <[EMAIL PROTECTED]> wrote:
> Eh, I wrong again~ I even took an experiment in last week end, this
> idea is really bad! ;(
>
> I think the most inner of source of my wrong again and again is
> misunderstanding virtual time. For more better understanding this, I
> try to write one
* Balbir Singh <[EMAIL PROTECTED]> wrote:
> + /*
> + * Split up sched_exec_time according to the utime and
> + * stime ratio. At this point utime contains the summed
> + * sched_exec_runtime and stime is zero
> + */
> +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tilman Schmidt schrieb:
> Am 17.05.2007 08:15 schrieb huang ying:
>> I think the "serio" (through drivers/input/serio/serport.c) may be a
>> choice too, like that in linux/drivers/input/mouse/sermouse.c, which
>> is an example to program serial port
Hi Linus,
On 6/5/2007, "Linus Walleij (LD/EAB)" <[EMAIL PROTECTED]>
wrote:
>> > Ok, FIR and SIR are definitey mixed up. So, now could you please
>try
>> > Bjorn's patch ?
>>
>> does not work.
>
>It looks like the purpose of the patch is to provide more printouts
>not to fix the problem,
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 09:42:41 +0200
> I just want to win the "who's laziest?" league. It would take me
> about 5 minutes to get the netdev tree and test compile the change.
> Of which 5 seconds would be actually updating the patch. I was
> thought it
On Mon, 4 Jun 2007, Yoann Padioleau wrote:
> parse errors in ifdefs
>
> Fix various bits of obviously-busted code which we're not happening to
> compile, due to ifdefs.
> --- a/arch/m68k/mac/debug.c
> +++ b/arch/m68k/mac/debug.c
> @@ -71,7 +71,7 @@ #ifdef DEBUG_SCREEN
>
> /* calculate
On Mon, Jun 04, 2007 at 07:31:27PM -0700, H. Peter Anvin wrote:
>Jeff Garzik wrote:
>>>
>>> So, it seems that we can reach an agreement. Any other comments or
>>> suggestions?
>>> Or can someone ack/merge this patch?
>>
>> Honestly, I think not reaching an agreement is a good thing.
>>
>>
> > > A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> > > send()+close() on the peer, causing recv() to return zero, even though
> > > the sent data should be received.
> > >
> > > This happens if the send() and the close() is performed between
> > > skb_dequeue() and checking
> > Ok, FIR and SIR are definitey mixed up. So, now could you please
try
> > Bjorn's patch ?
>
> does not work.
It looks like the purpose of the patch is to provide more printouts
not to fix the problem, please mail your dmesg post-patch.
Linus
-
To unsubscribe from this list: send the line
Christoph Hellwig wrote:
> On Tue, Jun 05, 2007 at 10:11:12AM +0400, Vasily Averin wrote:
return d_splice_alias(inode, dentry);
}
>>> Seems reasonable. So this prevents the bad inodes from getting onto the
>>> orphan list in the first place?
>> make_bad_inode() is called from
Balbir Singh wrote:
> Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
> ---
>
> Documentation/controller/rss.txt | 165
> +++
> 1 file changed, 165 insertions(+)
>
> diff -puN /dev/null Documentation/controller/rss.txt
> --- /dev/null 2007-06-01
Luca Tettamanti wrote:
Il Mon, Jun 04, 2007 at 11:51:10PM +0300, Avi Kivity ha scritto:
While doing repeated tests with the installer I ran into another
(unrelated) problem. Sometimes the guest kernel hangs at boot at:
NET: Registered protocol family 2
with any kind of networking options
On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
> signalfd() doesn't deliver thread-targeted signals to the wrong
> threads,
> does it?
>
> Hmm.
>
> It looks like reading from a signalfd will give you either
> process-global signals or the thread-specific signals that are
> targeted
>
Hallo.
On Sun, Jun 03, 2007 at 10:47:00PM +0200, Sam Ravnborg wrote:
> Subject: [PATCH 08/19] scripts: Make cleanfile/cleanpatch warn about long
> lines
> From: H. Peter Anvin <[EMAIL PROTECTED]>
> Date: Fri, 25 May 2007 17:58:26 -0700
>
> Make the "cleanfile" and "cleanpatch" script warn about
Hello,
after a little studing on new generic netlink interface and some
letters with Andrew Morton I decided to drop using the netlink API at
all and start using new specific syscalls.
Looking at current LinuxPPS API and at RFC2783 I think we need the
following syscalls:
asmlinkage long
* Matt Mackall <[EMAIL PROTECTED]> wrote:
> sleep_max: 57476665627
> block_max: 18014060106626075
hm, this block_max looks a bit suspect, it's 003fffb1359e341b. Does your
box make any use of cpufreq? (what CPU is it?)
> strace -f doesn't kill the
* Rusty Russell <[EMAIL PROTECTED]> wrote:
> This sounds like the waker process (nice 19) not getting a chance to
> run. You can hack around it for the moment by changing "nice(19)" in
> Documentation/lguest/lguest.c to something less aggressive.
even if the waker runs at nice+19, under CFS
From: Denis Cheng <[EMAIL PROTECTED]>
Date: Fri, 01 Jun 2007 19:08:51 -0700 (PDT)
> they should merged into one
>
> Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
Patch applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Mon, 04 Jun 2007 11:45:32 +0200
> > A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> > send()+close() on the peer, causing recv() to return zero, even though
> > the sent data should be received.
> >
> > This happens if the send() and
Andrew Morton wrote:
> On Wed, 30 May 2007 18:49:46 +
> Maxim Uvarov <[EMAIL PROTECTED]> wrote:
>
>> +void print_taskstats(struct taskstats *t)
>> +{
>> +printf("\n\nTask %15s%15s\n"
>> + " %15lu%15lu\n",
>> + "voluntary", "nonvoluntary",
>> +
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Sat, 2 Jun 2007 21:16:46 +0200
> >
> > promcon_init() can be called again from visual_init() during
> > vc_allocate(). So anything referenced by promcon_init() should not be
> > marked __init.
> >
> > Although, if you want to keep promfont_unitable
Eric Sandeen wrote:
> Vasily Averin wrote:
>> Bad inode can live some time, ext3_unlink can add it to orphan list, but
>> ext3_delete_inode() do not deleted this inode from orphan list. As result
>> we can have orphan list corruption detected in ext3_destroy_inode().
>
> Ah, I see - so you have
Eric Sandeen wrote:
> Vasily Averin wrote:
>> Customers claims to ext3-related errors, investigation showed that ext3
>> orphan list has been corrupted and have the reference to non-ext3 inode.
>> The following debug helps to understand the reasons of this issue.
>
> Vasily, does your customer
On Mon, Jun 04, 2007 at 07:15:58AM -0400, Robert P. J. Day wrote:
>
> Remove the "#if 0"ed definition of apm_get_battery_status().
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
> Acked-by: Stephen Rothwell <[EMAIL PROTECTED]>
Acked-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
>
>
[PATCH] x86_64: change dmi_ioremap to ioremap
dmi_scan_machine==>dmi_present==>dmi_table==>dmi_ioremap uses
early_ioremap in mm/init.c
dmi_scan_machine is called after init_memory_mappings, and could use
ioremap instead.
also remove extra extern declaring about dmi_ioremap
Signed-off-by:
On 6/4/07, Tim Bird <[EMAIL PROTECTED]> wrote:
Greg KH wrote:
> On Mon, Jun 04, 2007 at 12:10:01PM -0700, Tim Bird wrote:
>> Greg,
>>
>> I'm having problems cloning the stable git tree for 2.6.21.
>> Here's what I get:
>>
>> $ git clone
On Tue, 2007-06-05 at 13:22 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-06-04 at 19:38 -0700, Davide Libenzi wrote:
> > > - I still think there's something wrong with dequeue_signal() being
> > > potentially called with a task different than current by signalfd, since
> > >
On Mon, Jun 04, 2007 at 09:58:51PM +0100, Richard Purdie wrote:
> On Mon, 2007-06-04 at 23:56 +0530, Nitin Gupta wrote:
> > Yes there might still be problems - that is why I posted as RFC. I got
> > useful comments and the code is improving. Going for such fork might
> > be pain initially but IMHO
On Tue, Jun 05, 2007 at 10:11:12AM +0400, Vasily Averin wrote:
> >>return d_splice_alias(inode, dentry);
> >> }
> > Seems reasonable. So this prevents the bad inodes from getting onto the
> > orphan list in the first place?
>
> make_bad_inode() is called from ext3_read_inode() that is
Andrew Morton wrote:
> On Mon, 04 Jun 2007 09:19:10 +0400 Vasily Averin <[EMAIL PROTECTED]> wrote:
>> diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c
>> index 9bb046d..e3ac8c3 100644
>> --- a/fs/ext3/namei.c
>> +++ b/fs/ext3/namei.c
>> @@ -1019,6 +1019,11 @@ static struct dentry *ext3_lookup(struct
Andrew Morton wrote:
On Mon, 04 Jun 2007 09:19:10 +0400 Vasily Averin [EMAIL PROTECTED] wrote:
diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c
index 9bb046d..e3ac8c3 100644
--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -1019,6 +1019,11 @@ static struct dentry *ext3_lookup(struct inode * dir,
On Tue, Jun 05, 2007 at 10:11:12AM +0400, Vasily Averin wrote:
return d_splice_alias(inode, dentry);
}
Seems reasonable. So this prevents the bad inodes from getting onto the
orphan list in the first place?
make_bad_inode() is called from ext3_read_inode() that is called from
On Mon, Jun 04, 2007 at 09:58:51PM +0100, Richard Purdie wrote:
On Mon, 2007-06-04 at 23:56 +0530, Nitin Gupta wrote:
Yes there might still be problems - that is why I posted as RFC. I got
useful comments and the code is improving. Going for such fork might
be pain initially but IMHO its
On 6/4/07, Tim Bird [EMAIL PROTECTED] wrote:
Greg KH wrote:
On Mon, Jun 04, 2007 at 12:10:01PM -0700, Tim Bird wrote:
Greg,
I'm having problems cloning the stable git tree for 2.6.21.
Here's what I get:
$ git clone
http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.21.y.git
On Tue, 2007-06-05 at 13:22 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2007-06-04 at 19:38 -0700, Davide Libenzi wrote:
- I still think there's something wrong with dequeue_signal() being
potentially called with a task different than current by signalfd, since
__dequeue_signal()
[PATCH] x86_64: change dmi_ioremap to ioremap
dmi_scan_machine==dmi_present==dmi_table==dmi_ioremap uses
early_ioremap in mm/init.c
dmi_scan_machine is called after init_memory_mappings, and could use
ioremap instead.
also remove extra extern declaring about dmi_ioremap
Signed-off-by: Yinghai
On Mon, Jun 04, 2007 at 07:15:58AM -0400, Robert P. J. Day wrote:
Remove the #if 0ed definition of apm_get_battery_status().
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
Acked-by: Stephen Rothwell [EMAIL PROTECTED]
Acked-by: Anton Vorontsov [EMAIL PROTECTED]
---
diff --git
Eric Sandeen wrote:
Vasily Averin wrote:
Customers claims to ext3-related errors, investigation showed that ext3
orphan list has been corrupted and have the reference to non-ext3 inode.
The following debug helps to understand the reasons of this issue.
Vasily, does your customer have this
Eric Sandeen wrote:
Vasily Averin wrote:
Bad inode can live some time, ext3_unlink can add it to orphan list, but
ext3_delete_inode() do not deleted this inode from orphan list. As result
we can have orphan list corruption detected in ext3_destroy_inode().
Ah, I see - so you have confirmed
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Sat, 2 Jun 2007 21:16:46 +0200
promcon_init() can be called again from visual_init() during
vc_allocate(). So anything referenced by promcon_init() should not be
marked __init.
Although, if you want to keep promfont_unitable and
Andrew Morton wrote:
On Wed, 30 May 2007 18:49:46 +
Maxim Uvarov [EMAIL PROTECTED] wrote:
+void print_taskstats(struct taskstats *t)
+{
+printf(\n\nTask %15s%15s\n
+ %15lu%15lu\n,
+ voluntary, nonvoluntary,
+ t-nvcsw, t-nivcsw);
+}
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Mon, 04 Jun 2007 11:45:32 +0200
A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
send()+close() on the peer, causing recv() to return zero, even though
the sent data should be received.
This happens if the send() and the close() is
From: Denis Cheng [EMAIL PROTECTED]
Date: Fri, 01 Jun 2007 19:08:51 -0700 (PDT)
they should merged into one
Signed-off-by: Denis Cheng [EMAIL PROTECTED]
Patch applied.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
* Rusty Russell [EMAIL PROTECTED] wrote:
This sounds like the waker process (nice 19) not getting a chance to
run. You can hack around it for the moment by changing nice(19) in
Documentation/lguest/lguest.c to something less aggressive.
even if the waker runs at nice+19, under CFS (which
* Matt Mackall [EMAIL PROTECTED] wrote:
sleep_max: 57476665627
block_max: 18014060106626075
hm, this block_max looks a bit suspect, it's 003fffb1359e341b. Does your
box make any use of cpufreq? (what CPU is it?)
strace -f doesn't kill the latency,
Hallo.
On Sun, Jun 03, 2007 at 10:47:00PM +0200, Sam Ravnborg wrote:
Subject: [PATCH 08/19] scripts: Make cleanfile/cleanpatch warn about long
lines
From: H. Peter Anvin [EMAIL PROTECTED]
Date: Fri, 25 May 2007 17:58:26 -0700
Make the cleanfile and cleanpatch script warn about long lines,
Hello,
after a little studing on new generic netlink interface and some
letters with Andrew Morton I decided to drop using the netlink API at
all and start using new specific syscalls.
Looking at current LinuxPPS API and at RFC2783 I think we need the
following syscalls:
asmlinkage long
Luca Tettamanti wrote:
Il Mon, Jun 04, 2007 at 11:51:10PM +0300, Avi Kivity ha scritto:
While doing repeated tests with the installer I ran into another
(unrelated) problem. Sometimes the guest kernel hangs at boot at:
NET: Registered protocol family 2
with any kind of networking options
On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
signalfd() doesn't deliver thread-targeted signals to the wrong
threads,
does it?
Hmm.
It looks like reading from a signalfd will give you either
process-global signals or the thread-specific signals that are
targeted
towards the
Balbir Singh wrote:
Signed-off-by: Balbir Singh [EMAIL PROTECTED]
---
Documentation/controller/rss.txt | 165
+++
1 file changed, 165 insertions(+)
diff -puN /dev/null Documentation/controller/rss.txt
--- /dev/null 2007-06-01 20:42:04.0
Christoph Hellwig wrote:
On Tue, Jun 05, 2007 at 10:11:12AM +0400, Vasily Averin wrote:
return d_splice_alias(inode, dentry);
}
Seems reasonable. So this prevents the bad inodes from getting onto the
orphan list in the first place?
make_bad_inode() is called from ext3_read_inode() that
Ok, FIR and SIR are definitey mixed up. So, now could you please
try
Bjorn's patch ?
does not work.
It looks like the purpose of the patch is to provide more printouts
not to fix the problem, please mail your dmesg post-patch.
Linus
-
To unsubscribe from this list: send the line
A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
send()+close() on the peer, causing recv() to return zero, even though
the sent data should be received.
This happens if the send() and the close() is performed between
skb_dequeue() and checking sk-sk_shutdown in
On Mon, Jun 04, 2007 at 07:31:27PM -0700, H. Peter Anvin wrote:
Jeff Garzik wrote:
So, it seems that we can reach an agreement. Any other comments or
suggestions?
Or can someone ack/merge this patch?
Honestly, I think not reaching an agreement is a good thing.
style is always ultimately
On Mon, 4 Jun 2007, Yoann Padioleau wrote:
parse errors in ifdefs
Fix various bits of obviously-busted code which we're not happening to
compile, due to ifdefs.
--- a/arch/m68k/mac/debug.c
+++ b/arch/m68k/mac/debug.c
@@ -71,7 +71,7 @@ #ifdef DEBUG_SCREEN
/* calculate current
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Tue, 05 Jun 2007 09:42:41 +0200
I just want to win the who's laziest? league. It would take me
about 5 minutes to get the netdev tree and test compile the change.
Of which 5 seconds would be actually updating the patch. I was
thought it was OK to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tilman Schmidt schrieb:
Am 17.05.2007 08:15 schrieb huang ying:
I think the serio (through drivers/input/serio/serport.c) may be a
choice too, like that in linux/drivers/input/mouse/sermouse.c, which
is an example to program serial port in kernel
Hi Linus,
On 6/5/2007, Linus Walleij (LD/EAB) [EMAIL PROTECTED]
wrote:
Ok, FIR and SIR are definitey mixed up. So, now could you please
try
Bjorn's patch ?
does not work.
It looks like the purpose of the patch is to provide more printouts
not to fix the problem, please mail your dmesg
* Balbir Singh [EMAIL PROTECTED] wrote:
+ /*
+ * Split up sched_exec_time according to the utime and
+ * stime ratio. At this point utime contains the summed
+ * sched_exec_runtime and stime is zero
+ */
+ if
* Li Yu [EMAIL PROTECTED] wrote:
Eh, I wrong again~ I even took an experiment in last week end, this
idea is really bad! ;(
I think the most inner of source of my wrong again and again is
misunderstanding virtual time. For more better understanding this, I
try to write one python
Stefan, Mircea,
reagarding your Turion cpufreq issues - is that solved by now?
http://lkml.org/lkml/2007/4/8/59
Regards,
Peter Oruba
--
AMD Saxony Limited Liability Company Co. KG
Operating System Research Center
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA
On Mon, Jun 04, 2007 at 11:53:13PM -0700, David Miller wrote:
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Sat, 2 Jun 2007 21:16:46 +0200
promcon_init() can be called again from visual_init() during
vc_allocate(). So anything referenced by promcon_init() should not be
marked
On Jun 5 2007 00:35, Mike Richards wrote:
In my research on this matter I've come across various comments by
people saying that getting rid of swap entirely will hurt performance
somehow, but on these servers I'm seeing very little swap used in the
first place, so I'm not seeing how that's
On Mon, Jun 04, 2007 at 10:46:24AM +0100, Andy Whitcroft wrote:
This version brings a host of changes to cure false positives and
bugs detected on patches submitted to lkml and -mm. It also brings
a number of new tests in response to reviews, of particular note:
- catch use of volatile
On Tue, Jun 05, 2007 at 09:33:35AM +0200, Oleg Verych wrote:
Hallo.
On Sun, Jun 03, 2007 at 10:47:00PM +0200, Sam Ravnborg wrote:
Subject: [PATCH 08/19] scripts: Make cleanfile/cleanpatch warn about long
lines
From: H. Peter Anvin [EMAIL PROTECTED]
Date: Fri, 25 May 2007 17:58:26
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Tue, 05 Jun 2007 10:11:56 +0200
I just want to win the who's laziest? league. It would take me
about 5 minutes to get the netdev tree and test compile the change.
Of which 5 seconds would be actually updating the patch. I was
thought it
On Tue, 2007-06-05 at 08:36 +1000, Nigel Cunningham wrote:
I spent some time, last I think, seriously considering this approach.
The more I thought about the details, the more I realised that it wasn't
a viable approach. As I said before, it does indeed sound like a dream
at first, but once
I just want to win the who's laziest? league. It would take me
about 5 minutes to get the netdev tree and test compile the change.
Of which 5 seconds would be actually updating the patch. I was
thought it was OK to pass that 5 seconds worth of hard work to you in
order to save the rest
Pavel Emelianov wrote:
+1. RSS controller
+2. Page Cache controller
+3. mlock(2) controller
+4. Kernel user memory accounting and slab control
I would add the user-mappings-length controller
:-) I'll update the document
+The RSS controller is the first controller developed, the page
Am Dienstag, 5. Juni 2007 06:08 schrieb Andrew Morton:
Everything in USB appears to already be fixed, apart from the io_ti.c bug.
Yes, that's a bug. I've queued a patch.
Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
On 06/05/2007 01:09 AM, Christoph Lameter wrote:
Here a version of the patch that drops the WARN_ONs
And now all that's done, how about yet another random person stepping in and
suggesting NIL or maybe NIL_PTR instead of ZERO_SIZE_PTR?
I understand the idea is that code need not necesarily
Ingo Molnar wrote:
* Li Yu [EMAIL PROTECTED] wrote:
Eh, I wrong again~ I even took an experiment in last week end, this
idea is really bad! ;(
I think the most inner of source of my wrong again and again is
misunderstanding virtual time. For more better understanding this, I
try to
Mark Lord wrote:
That's odd. Could you try that again,
with the latest (either v7.3 or v7.4) version of hdparm
(from sourceforge) ?
Using Debian's 7.3 via apt-get experimental - is that OK or would you like me to
compile the upstream?
2.6.21.1
cu:~# hdparm -V
hdparm v7.3
cu:~# hdparm -K1
On 5 Jun, 05:40, Mike Richards [EMAIL PROTECTED] wrote:
Here's something that's been bugging me for a while now...
I have several Linux servers that have been given enough RAM that they
rarely ever use any swap space. For example, here's the typical output
of uptime and free:
[EMAIL PROTECTED]
On Mon, 4 Jun 2007, Robert Hancock wrote:
James Jarvis wrote:
I trust this is the right list...
The following patch enables reboot through BIOS on the Dell Optiplex 745
Small Form Factor base, on which reboot hangs. The larger form factor does
not require this, hence the match on
* Ingo Molnar [EMAIL PROTECTED] wrote:
the NMI watchdog warning is a bit weird:
Calling initcall 0xc0613e4f: check_nmi_watchdog+0x0/0x1a8()
Testing NMI watchdog ... CPU#0: NMI appears to be stuck (0-0)!
CPU#1: NMI appears to be stuck (0-0)!
initcall 0xc0613e4f:
On 06/05/2007 04:10 AM, WANG Cong wrote:
On Mon, Jun 04, 2007 at 01:57:51PM -0400, Jeff Garzik wrote:
A matter of opinion :) I tend to think goto is special enough to
warrant column 1 unconditionally. It is special, so it draws additional
attention over and above case labels.
I and others
* Matt Mackall [EMAIL PROTECTED] wrote:
Ok, my transcoding just finished as I was writing this. So I've
reproduced the problem with this Python script that I had handy:
memload.py:
#!/usr/bin/python
a = a * 16 * 1024 * 1024
while 1:
b = a[1:] + b
a = b[1:] + c
i suspect the
On Tue, 5 Jun 2007 11:11:51 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
hm, mm1 hangs during bootup on one of my boxes:
Calling initcall 0xc0628d39: pci_mmcfg_late_insert_resources+0x0/0x44()
initcall 0xc0628d39: pci_mmcfg_late_insert_resources+0x0/0x44() returned 0.
initcall 0xc0628d39
On Mon, 2007-06-04 at 22:50 -0700, Andrew Morton wrote:
I'd say go with the cleanups. The code I've seen is going to be quite
unmaintainable by any kernel developer.
Any fixes which come from upstream can be trivially applied by taking the
diffs against the version of upstream we started
Linus Torvalds wrote:
So -rc4 is out there now, hopefully shrinking the regression list further.
The diffstat (for those that look at those kinds of things) tells the
story: lots of small stuff to random files. I think the single biggest
file change was the patch-checking script, along
On Thu, May 31, 2007 at 06:08:23PM -0500, Steve French wrote:
With Samba 3.0.26pre it is now possible for a cifs client (one which
supports the newest Unix/Posix cifs extensions) to request up to
almost 8MB at a time on a cifs read request.
A patch for the cifs client to support larger reads
* Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 5 Jun 2007 11:11:51 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
hm, mm1 hangs during bootup on one of my boxes:
Calling initcall 0xc0628d39: pci_mmcfg_late_insert_resources+0x0/0x44()
initcall 0xc0628d39:
Hi,
On Sat, May 26, 2007 at 06:42:37PM -0400, Bill Davidsen wrote:
I was testing susp2disk in 2.6.21.1 under FC6, to support reliable computing
environment (RCE) needs. The idea is that if power fails, after some short
time on UPS the system does susp2disk with a time set, and boots back every
On Tue, Jun 05, 2007 at 10:15:41AM +0200, Xavier Bestel wrote:
FWIW, on my old laptop apm beats any kernel solution hands down in terms
of speed
This might be true on 64MB systems. It is surely not true on multi-Gigabyte-
RAM setups. At least not if you actually use that memory for anything
* Ingo Molnar [EMAIL PROTECTED] wrote:
yeah. I tried !hres and !dynticks too and that doesnt make any
difference to the end result - so my guess is on the NMI watchdog
re-programming thing on K8 CPUs (running the 32-bit kernel), which is
done in every NMI tick. check_watchdog() for some
On Tue, 2007-06-05 at 11:34 +0200, Stefan Seyfried wrote:
On Tue, Jun 05, 2007 at 10:15:41AM +0200, Xavier Bestel wrote:
FWIW, on my old laptop apm beats any kernel solution hands down in terms
of speed
This might be true on 64MB systems. It is surely not true on multi-Gigabyte-
RAM
* Ingo Molnar [EMAIL PROTECTED] wrote:
i have put an early_printk() into the NMI handler but it never
triggers.
commenting out check_nmi_watchdog() produces a booting kernel too. So
it's a side-effect of check_nmi_watchdog(). Problem is, nothing in nmi.c
changed in -mm1 AFAICS.
* Ingo Molnar [EMAIL PROTECTED] wrote:
commenting out check_nmi_watchdog() produces a booting kernel too. So
it's a side-effect of check_nmi_watchdog(). Problem is, nothing in
nmi.c changed in -mm1 AFAICS.
ah, plain -rc3 hangs too. So it's one of these commits i guess:
commit
So the only safe thing we can do is not use memory that is not
write-back cached. That we can positively detect and is a
conservative action so if anything will work that will.
Jesse wrote such a patch (or rather it limitted end_pfn), but it broke
the X server for so far unknown reasons.
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
commenting out check_nmi_watchdog() produces a booting kernel too. So
it's a side-effect of check_nmi_watchdog(). Problem is, nothing in
nmi.c changed in -mm1 AFAICS.
ah, plain -rc3 hangs too. So it's
* Ingo Molnar [EMAIL PROTECTED] wrote:
ah, plain -rc3 hangs too. So it's one of these commits i guess:
commit 1eeb66a1bb973534dc3d064920a5ca683823372e
commit 09198e68501a7e34737cd9264d266f42429abcdc
commit bbba11c35baaad3f70f32e185a2c1d40d7901fe9
commit
401 - 500 of 876 matches
Mail list logo
