fetch = +refs/heads/*:refs/remotes/linux-2.6.22.y/*
[remote "linux-2.6.23.y"]
url =
http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git
fetch = +refs/heads/*:refs/remotes/linux-2.6.23.y/*
Which basically means I am cloning Linus' git and fetchi
Hi Rafael,
> Can you please check if you are able to reproduce the problem with
> 2.6.24-rc2?
I am not able to reproduce the problem with 2.6.24-rc2. I am able to
suspend
to disk successfully.
Thank for the prompt fix! :)
C.
-
To unsubscribe from this list: send the line "unsu
On Tuesday, 30 of October 2007, CSights wrote:
> >
> > Thanks, I'll try to reproduce the problem here and fix it.
>
> No really, thank you!
Sorry for the long delay.
Can you please check if you are able to reproduce the problem with 2.6.24-rc2?
Thanks,
Rafael
-
To unsubscribe from this list: se
>
> Thanks, I'll try to reproduce the problem here and fix it.
No really, thank you!
C.
-
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 FAQ at
On Sunday, 28 October 2007 16:33, C Sights wrote:
> >
> > Well, a test program that triggers the SIGABRT under gdb would be useful.
>
> The attached program causes a SIGABRT for me,
>
> Thanks,
> C.
Thanks, I'll try to reproduce the problem here and fix it.
Greetings,
Rafael
-
To unsubscr
>
> Well, a test program that triggers the SIGABRT under gdb would be useful.
The attached program causes a SIGABRT for me,
Thanks,
C.
#include
using namespace std;
int main (char **argv, int argc) {
string t = "linux rocks!";
t.replace(LONG_MAX, 1, "sigabrt here");
return 0;
}
On Sat, Oct 27, 2007 at 08:08:14AM +0200, Kay Sievers wrote:
> On Fri, 2007-10-26 at 19:36 -0700, Greg KH wrote:
> > On Fri, Oct 26, 2007 at 08:07:44PM +0200, Kay Sievers wrote:
> > > On Fri, 2007-10-26 at 12:05 -0500, Larry Finger wrote:
> > > > On my openSUSE 10.3 x86_64 system running v2.6.24-rc
On Fri, 2007-10-26 at 19:36 -0700, Greg KH wrote:
> On Fri, Oct 26, 2007 at 08:07:44PM +0200, Kay Sievers wrote:
> > On Fri, 2007-10-26 at 12:05 -0500, Larry Finger wrote:
> > > On my openSUSE 10.3 x86_64 system running v2.6.24-rc1-281-g22d2aa1,
> > > I get the sysfs rename messages.
> >
> > Care
On Fri, Oct 26, 2007 at 08:07:44PM +0200, Kay Sievers wrote:
> On Fri, 2007-10-26 at 12:05 -0500, Larry Finger wrote:
> > On my openSUSE 10.3 x86_64 system running v2.6.24-rc1-281-g22d2aa1,
> > I get the sysfs rename messages.
>
> Care to try this? Seems like a silly bug in the core if
> SYSFS_DEP
On Friday, 26 October 2007 03:03, CSights wrote:
> Hi LKML,
> My computer running kernel 2.6.23 does not "hibernate" (suspend to disk
> using
> the kernel's methods) with a program (named stringTest) running in gdb, but
> has received a SIGABRT.
> The hibernate is successful when run
Kay Sievers wrote:
> On Fri, 2007-10-26 at 12:05 -0500, Larry Finger wrote:
>> On my openSUSE 10.3 x86_64 system running v2.6.24-rc1-281-g22d2aa1,
>> I get the sysfs rename messages.
>
> Care to try this? Seems like a silly bug in the core if
> SYSFS_DEPRECATED=y. That's why we didn't catch this e
On Fri, 2007-10-26 at 12:05 -0500, Larry Finger wrote:
> On my openSUSE 10.3 x86_64 system running v2.6.24-rc1-281-g22d2aa1,
> I get the sysfs rename messages.
Care to try this? Seems like a silly bug in the core if
SYSFS_DEPRECATED=y. That's why we didn't catch this earlier, sorry.
Thanks a lot
On my openSUSE 10.3 x86_64 system running v2.6.24-rc1-281-g22d2aa1, I get the
sysfs rename messages.
Using Greg's patch, nothing changed. The log results are:
sysfs: duplicate filename 'eth1' can not be created
WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Call Trace:
[] sysfs_add_one+0x5c/0x
Hi LKML,
My computer running kernel 2.6.23 does not "hibernate" (suspend to disk
using
the kernel's methods) with a program (named stringTest) running in gdb, but
has received a SIGABRT.
The hibernate is successful when running kernel 2.6.22.7 !
Here is the message from gdb:
te
On Wed, 2007-10-24 at 16:52 -0700, Greg KH wrote:
> On Wed, Oct 24, 2007 at 04:43:48PM -0700, Greg KH wrote:
> > On Wed, Oct 17, 2007 at 12:16:54PM +0200, Kay Sievers wrote:
> > > On Tue, 2007-10-16 at 16:23 -0700, Greg KH wrote:
> > > > On Tue, Oct 16, 2007 at 03:32:48PM -0700, David Miller wrote
On Wed, Oct 24, 2007 at 04:43:48PM -0700, Greg KH wrote:
> On Wed, Oct 17, 2007 at 12:16:54PM +0200, Kay Sievers wrote:
> > On Tue, 2007-10-16 at 16:23 -0700, Greg KH wrote:
> > > On Tue, Oct 16, 2007 at 03:32:48PM -0700, David Miller wrote:
> > > > From: Greg KH <[EMAIL PROTECTED]>
> > > > Date: T
On Wed, Oct 17, 2007 at 12:16:54PM +0200, Kay Sievers wrote:
> On Tue, 2007-10-16 at 16:23 -0700, Greg KH wrote:
> > On Tue, Oct 16, 2007 at 03:32:48PM -0700, David Miller wrote:
> > > From: Greg KH <[EMAIL PROTECTED]>
> > > Date: Tue, 16 Oct 2007 14:37:30 -0700
> > >
> > > > Kay, are we doing som
On Mon, 22 Oct 2007, Esben Stien wrote:
> [] input_unregister_device+0x67/0xfc
> [] hidinput_disconnect+0x2e/0x47
> [] hid_disconnect+0x76/0xce
> [] usb_unbind_interface+0x2d/0x6e
> [] __device_release_driver+0x71/0x8e
> [] device_release_driver+0x18/0x21
> [] bus_remove_device+0x70/0x80
>
I also saw this in 2.6.22-rt9. When I disconnect a USB device the
whole USB system goes down and I'm not able to insert any other USB
device until I reboot.
This happens every time. I'm on a P4.
usb 1-1.3: USB disconnect, address 11
BUG: unable to handle kernel paging request at virtual address 0
* Mel Gorman <[EMAIL PROTECTED]> wrote:
> Subject: Document profile=sleep requiring CONFIG_SCHEDSTATS
>
> profile=sleep only works if CONFIG_SCHEDSTATS is set. This patch notes
> the limitation in Documentation/kernel-parameters.txt and prints a
> warning at boot-time if profile=sleep is used
On Wednesday, 17 October 2007 12:17, Kay Sievers wrote:
> On 10/17/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > On Tuesday, 16 October 2007 23:36, Greg KH wrote:
> > > On Tue, Oct 16, 2007 at 11:13:19PM +0200, Rafael J. Wysocki wrote:
> > > > On Tuesday, 16 October 2007 22:50, Jens Axboe wr
On Wed, Oct 17 2007, Jens Axboe wrote:
> On Wed, Oct 17 2007, Kay Sievers wrote:
> > On 10/16/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > > On Tue, Oct 16 2007, Greg KH wrote:
> > > > On Tue, Oct 16, 2007 at 10:04:51PM +0200, Rafael J. Wysocki wrote:
> > > > > On Tuesday, 16 October 2007 06:50, G
On Wed, Oct 17 2007, Kay Sievers wrote:
> On 10/16/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > On Tue, Oct 16 2007, Greg KH wrote:
> > > On Tue, Oct 16, 2007 at 10:04:51PM +0200, Rafael J. Wysocki wrote:
> > > > On Tuesday, 16 October 2007 06:50, Greg KH wrote:
> > > > > On Sat, Oct 13, 2007 at 0
On 10/16/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 16 2007, Greg KH wrote:
> > On Tue, Oct 16, 2007 at 10:04:51PM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, 16 October 2007 06:50, Greg KH wrote:
> > > > On Sat, Oct 13, 2007 at 09:26:32PM +0200, Rafael J. Wysocki wrote:
> > > >
On 10/17/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> On Tuesday, 16 October 2007 23:36, Greg KH wrote:
> > On Tue, Oct 16, 2007 at 11:13:19PM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, 16 October 2007 22:50, Jens Axboe wrote:
> > > > On Tue, Oct 16 2007, Greg KH wrote:
> > > > > On Tu
On Tue, 2007-10-16 at 16:23 -0700, Greg KH wrote:
> On Tue, Oct 16, 2007 at 03:32:48PM -0700, David Miller wrote:
> > From: Greg KH <[EMAIL PROTECTED]>
> > Date: Tue, 16 Oct 2007 14:37:30 -0700
> >
> > > Kay, are we doing something wrong in userspace when renaming wireless
> > > devices such that
On Tuesday, 16 October 2007 23:36, Greg KH wrote:
> On Tue, Oct 16, 2007 at 11:13:19PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, 16 October 2007 22:50, Jens Axboe wrote:
> > > On Tue, Oct 16 2007, Greg KH wrote:
> > > > On Tue, Oct 16, 2007 at 10:04:51PM +0200, Rafael J. Wysocki wrote:
> > >
On Tue, Oct 16, 2007 at 03:32:48PM -0700, David Miller wrote:
> From: Greg KH <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 14:37:30 -0700
>
> > Kay, are we doing something wrong in userspace when renaming wireless
> > devices such that we can overlap names?
>
> It does it for all network devices,
From: Greg KH <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 14:37:30 -0700
> Kay, are we doing something wrong in userspace when renaming wireless
> devices such that we can overlap names?
It does it for all network devices, I see this ugly message on every
single system I have from Fedora foo to RH
On Tue, Oct 16, 2007 at 10:50:54PM +0200, Jens Axboe wrote:
> On Tue, Oct 16 2007, Greg KH wrote:
> > On Tue, Oct 16, 2007 at 10:04:51PM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, 16 October 2007 06:50, Greg KH wrote:
> > > > On Sat, Oct 13, 2007 at 09:26:32PM +0200, Rafael J. Wysocki wrote:
On Tue, Oct 16, 2007 at 11:13:19PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 16 October 2007 22:50, Jens Axboe wrote:
> > On Tue, Oct 16 2007, Greg KH wrote:
> > > On Tue, Oct 16, 2007 at 10:04:51PM +0200, Rafael J. Wysocki wrote:
> > > > On Tuesday, 16 October 2007 06:50, Greg KH wrote:
> > >
On Tuesday, 16 October 2007 22:50, Jens Axboe wrote:
> On Tue, Oct 16 2007, Greg KH wrote:
> > On Tue, Oct 16, 2007 at 10:04:51PM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, 16 October 2007 06:50, Greg KH wrote:
> > > > On Sat, Oct 13, 2007 at 09:26:32PM +0200, Rafael J. Wysocki wrote:
> > >
On Tue, Oct 16 2007, Greg KH wrote:
> On Tue, Oct 16, 2007 at 10:04:51PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, 16 October 2007 06:50, Greg KH wrote:
> > > On Sat, Oct 13, 2007 at 09:26:32PM +0200, Rafael J. Wysocki wrote:
> > > > Hi,
> > > >
> > > > There are many traces like this in my
On Tue, Oct 16 2007, Rafael J. Wysocki wrote:
> On Tuesday, 16 October 2007 06:50, Greg KH wrote:
> > On Sat, Oct 13, 2007 at 09:26:32PM +0200, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > There are many traces like this in my dmesg from 2.6.23-git3 (they don't
> > > appear for vanilla 2.6.23):
On Tue, Oct 16, 2007 at 10:04:51PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 16 October 2007 06:50, Greg KH wrote:
> > On Sat, Oct 13, 2007 at 09:26:32PM +0200, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > There are many traces like this in my dmesg from 2.6.23-git3 (they don't
> > > appear
On Tuesday, 16 October 2007 06:50, Greg KH wrote:
> On Sat, Oct 13, 2007 at 09:26:32PM +0200, Rafael J. Wysocki wrote:
> > Hi,
> >
> > There are many traces like this in my dmesg from 2.6.23-git3 (they don't
> > appear for vanilla 2.6.23):
> >
> > <4>sysfs: duplicate filename 'ethxx1' can not be
On 10/14/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> I didn't notice that qemu was involved. Does qemu have an emulator for the
> gdth hardware?
>
I think no, the kernel just probe exist or not hardware, and hangs after that.
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Sat, Oct 13, 2007 at 09:26:32PM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> There are many traces like this in my dmesg from 2.6.23-git3 (they don't
> appear for vanilla 2.6.23):
>
> <4>sysfs: duplicate filename 'ethxx1' can not be created
> WARNING: at /home/rafael/src/linux-2.6/fs/sysfs/dir.c:
On Sun, 2007-10-14 at 12:21 -0700, Andrew Morton wrote:
> On Sun, 14 Oct 2007 22:45:47 +0400 "Dave Milter" <[EMAIL PROTECTED]> wrote:
>
> > I build linux-2.6.23-mm1 and try to boot it using qemu,
> > and it crashed with trace like this:
> > do_pa
Hi and thanks for your reply :)
On Friday 12 October 2007, you wrote:
> i have no quick ideas - the behavior you are seeing is quite unexpected.
> Could you try the current sched-devel code:
>
>
> http://redhat.com/~mingo/cfs-scheduler/devel/sched-devel-combo-v2.6.23.patc
>h
Maybe I messed somet
(please don't top-post! edited...)
On Sun, 14 Oct 2007 23:24:39 +0400 "Dave Milter" <[EMAIL PROTECTED]> wrote:
> On 10/14/07, Dave Milter <[EMAIL PROTECTED]> wrote:
> > I build linux-2.6.23-mm1 and try to boot it using qemu,
> > and it crash
t; to qemu options you can after that do:
gdb vmlinux
$target remote localhost:1234
$br gth_timeout
$continue
On 10/14/07, Dave Milter <[EMAIL PROTECTED]> wrote:
> I build linux-2.6.23-mm1 and try to boot it using qemu,
> and it crashed with trace like this:
> do_page_
On Sun, 14 Oct 2007 22:45:47 +0400 "Dave Milter" <[EMAIL PROTECTED]> wrote:
> I build linux-2.6.23-mm1 and try to boot it using qemu,
> and it crashed with trace like this:
> do_page_fault
> error_code
> lock_acquire
> _spin_lock_irqsave
> gdth_timeo
Hi,
There are many traces like this in my dmesg from 2.6.23-git3 (they don't
appear for vanilla 2.6.23):
<4>sysfs: duplicate filename 'ethxx1' can not be created
WARNING: at /home/rafael/src/linux-2.6/fs/sysfs/dir.c:425 sysfs_add_one()
Call Trace:
[] sysfs_add_one+0x5c/0xc9
[] sysfs_create_lin
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
;) I think you snipped the important bit:
"the peak is terrible but it has virtually no dropoff and performs
better under load than the default 2.6.21 scheduler." (verbatim)
hm, i understood that peak remark to be in reference to F
On Friday 12 October 2007 15:46, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > ;) I think you snipped the important bit:
> >
> > "the peak is terrible but it has virtually no dropoff and performs
> > better under load than the default 2.6.21 scheduler." (verbatim)
>
> hm, i unde
* poison <[EMAIL PROTECTED]> wrote:
> Also the transfer rate didn't degrade too much for copying directly
> from reiserfs to reiserfs and not using encfs:
>
> dd if=/mnt/.backup/2CpGkrxvz6wgA0b0xloz8PavzMLrMymOgi9 of=/mnt/.tdata/test
> 1033+0 records in
> 1033+0 records out
> 1083179008 bytes (
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> ;) I think you snipped the important bit:
>
> "the peak is terrible but it has virtually no dropoff and performs
> better under load than the default 2.6.21 scheduler." (verbatim)
hm, i understood that peak remark to be in reference to FreeBSD's
sche
On Wednesday 10 October 2007 20:14, Ingo Molnar wrote:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
> > Does CFS still generate the following sysbench graphs with 2.6.23, or
> > did that get fixed?
> >
> > http://people.freebsd.org/~kris/scaling/linux-pgsql.png
> > http://people.freebsd.org/~kris/
Hi =)
On Thursday 11 October 2007, Helmut Toplizer wrote:
> Hi!
>
> I had similar behavior in the kernel releases since I can think of.
It doesn't happen before 2.6.23.
> (You may find some reports about at
> http://marc.info/?a=11350857446&r=1&w=2)
>
> Maybe your problem is similar.
>
> Here
* Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
> > ( Config is at http://redhat.com/~mingo/misc/config, system is Core2Duo
> > 1.83 GHz, mysql-5.0.45, glibc-2.6. Nothing fancy either in the config
> > nor in the setup - everything is pretty close to the defaults. )
>
> I used FedoraCore 8 Test2 d
Hi!
I had similar behavior in the kernel releases since I can think of.
(You may find some reports about at
http://marc.info/?a=11350857446&r=1&w=2)
Maybe your problem is similar.
Here's what have been found out:
Plugin of ehci devices causes some strange DMA thing
which causes delays becaus
On Wed, 2007-10-10 at 12:14 +0200, Ingo Molnar wrote:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
>
> > Does CFS still generate the following sysbench graphs with 2.6.23, or
> > did that get fixed?
> >
> > http://people.freebsd.org/~kris/scaling/linux-pgsql.png
> > http://people.freebsd.org/~k
Hi :)
I have two harddisks with encfs on top of reiserfs between which I could copy
data at ~22MB/s before the upgrade from 2.6.22 to 2.6.23.
After the upgrade the transfer rate stuck at ~14MB/s and changing nice values
did not help anything.
And now the funny part:
I noticed the transfer rate
On Wed, 2007-10-10 at 12:14 +0200, Ingo Molnar wrote:
> * Nicholas Miell <[EMAIL PROTECTED]> wrote:
>
> > Does CFS still generate the following sysbench graphs with 2.6.23, or
> > did that get fixed?
> >
> > http://people.freebsd.org/~kris/scaling/linux-pgsql.png
> > http://people.freebsd.org/~k
Ingo Molnar <[EMAIL PROTECTED]> writes:
> - an uncommon embedded config combinatio: if CONFIG_EMBEDDED=y and
> CONFIG_BLOCK is unset. (a normally useless combination)
Uncommon but far from useless - may be pure initramfs-based.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line
Ingo Molnar <[EMAIL PROTECTED]> writes:
> your superblock build failure would be a new and so far unknown build
> breakage variant - please send the .config you used, and double-check
> that it's indeed a vanilla 2.6.23 tree.
It is not -- my 2.6.23 tree doesn't have the prototype that broke
th
Ingo Molnar wrote:
> * René Rebe <[EMAIL PROTECTED]> wrote:
>
>> Hi Linus et al.,
>>
>> 2.6.23 does not build with my usual .config on x86_64 and gcc-4.2.1:
[]
> your superblock build failure would be a new and so far unknown build
> breakage variant - please send the .config you used, and double
* René Rebe <[EMAIL PROTECTED]> wrote:
> Hi Linus et al.,
>
> 2.6.23 does not build with my usual .config on x86_64 and gcc-4.2.1:
i know about 4 (low-impact, cornercase) build breakages for 2.6.23-final
on x86:
- an uncommon embedded config combinatio: if CONFIG_EMBEDDED=y and
CONFIG_BLOCK
Jan Engelhardt wrote:
> On Oct 10 2007 14:36, Alexey Dobriyan wrote:
>>>>> --- linux-2.6.23/include/linux/mm.h.vanilla
>>>>> +++ linux-2.6.23/include/linux/mm.h
>>>>> +struct super_block;
>>>>> extern void drop_pagecache_sb(struc
On Oct 10 2007 14:36, Alexey Dobriyan wrote:
>> >> --- linux-2.6.23/include/linux/mm.h.vanilla
>> >> +++ linux-2.6.23/include/linux/mm.h
>> >
>> >> +struct super_block;
>> >> extern void drop_pagecache_sb(struct super_block *);
>
aches.c:8:
> >> include/linux/mm.h:1210: warning: 'struct super_block' declared inside
> >> parameter list
> >
> >> --- linux-2.6.23/include/linux/mm.h.vanilla
> >> +++ linux-2.6.23/include/linux/mm.h
> >
> >> +struct super_block;
&g
* Nicholas Miell <[EMAIL PROTECTED]> wrote:
> Does CFS still generate the following sysbench graphs with 2.6.23, or
> did that get fixed?
>
> http://people.freebsd.org/~kris/scaling/linux-pgsql.png
> http://people.freebsd.org/~kris/scaling/linux-mysql.png
as far as my testsystem goes, v2.6.23
ock' declared inside
>> parameter list
>
>> --- linux-2.6.23/include/linux/mm.h.vanilla
>> +++ linux-2.6.23/include/linux/mm.h
>
>> +struct super_block;
>> extern void drop_pagecache_sb(struct super_block *);
>> void drop_pagecache(void);
>> void dro
On 10/10/07, René Rebe <[EMAIL PROTECTED]> wrote:
> 2.6.23 does not build with my usual .config on x86_64 and gcc-4.2.1:
>
> In file included from fs/drop_caches.c:8:
> include/linux/mm.h:1210: warning: 'struct super_block' declared inside
> parameter list
&
_sb'
include/linux/mm.h:1210: error: previous declaration of 'drop_pagecache_sb' was
here
A little forward declaration fixes this:
--- linux-2.6.23/include/linux/mm.h.vanilla 2007-10-10 09:28:33.0
+0200
+++ linux-2.6.23/include/linux/mm.h 2007
On Tue, 2007-10-09 at 13:54 -0700, Linus Torvalds wrote:
> Finally.
>
> Yeah, it got delayed, not because of any huge issues, but because of
> various bugfixes trickling in and causing me to reset my "release clock"
> all the time. But it's out there now, and hopefully better for the wait.
>
>
data access out of array bounds
Kyle McMartin (1):
Revert "intel_agp: fix stolen mem range on G33"
Linus Torvalds (3):
VT_WAITACTIVE: Avoid returning EINTR when not necessary
Don't do load-average calculations at even 5-second intervals
Linux 2.6.23
Maarten Bress
On Tue, 2007-10-09 at 00:05 +0200, Pavel Machek wrote:
> Hi!
>
> I played with powertop a bit, and found a fairly interesting failure
> mode. If I boot init=/bin/bash vga=1, I get ~2 wakeups a second, nice.
>
> When I boot init=/bin/bash vga=791 (vesa framebuffer), most wakeups
> are caused by cu
Clemens Koller wrote:
When I boot init=/bin/bash vga=791 (vesa framebuffer), most wakeups
are caused by cursor painting (I should fix that some day, I
guess). But... the cursor blinking does not even work properly!
It blinks at normal speed, then (randomly) it blinks slowly, then gets
back to n
Pavel Machek schrieb:
I played with powertop a bit, and found a fairly interesting failure
mode. If I boot init=/bin/bash vga=1, I get ~2 wakeups a second, nice.
When I boot init=/bin/bash vga=791 (vesa framebuffer), most wakeups
are caused by cursor painting (I should fix that some day, I
guess
Hi!
I played with powertop a bit, and found a fairly interesting failure
mode. If I boot init=/bin/bash vga=1, I get ~2 wakeups a second, nice.
When I boot init=/bin/bash vga=791 (vesa framebuffer), most wakeups
are caused by cursor painting (I should fix that some day, I
guess). But... the curso
On Friday 05 October 2007 09:32:40 you wrote:
> On Fri, 5 Oct 2007, Sam Ravnborg wrote:
> > > > cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
> > > >
> > > > Obviously, this file has moved to arch/x86/boot, but it seems like
> > > > possibly unnecessary breakage. I've been c
Mathieu Chouquet-Stringer wrote:
Hey there,
I've seen the changes you made in commit b6a2fea39318 and I guess they
might be responsible for my xargs breakage...
In the kernel source tree, if I run a stupid find | xargs ls, I now get
this:
xargs: ls: Argument list too long
Which is kin
Am Samstag, 6. Oktober 2007 10:29 schrieb Hans-Peter Jansen:
> Am Donnerstag, 4. Oktober 2007 19:05 schrieb Mathieu Chouquet-Stringer:
> > Hey there,
> >
> > I've seen the changes you made in commit b6a2fea39318 and I guess they
> > might be responsible for my xargs breakage...
> >
> > In
Am Donnerstag, 4. Oktober 2007 19:05 schrieb Mathieu Chouquet-Stringer:
> Hey there,
>
> I've seen the changes you made in commit b6a2fea39318 and I guess they
> might be responsible for my xargs breakage...
>
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this
On Fri, 5 Oct 2007, Sam Ravnborg wrote:
> > > cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
> > >
> > > Obviously, this file has moved to arch/x86/boot, but it seems like
> > > possibly unnecessary breakage. I've been copying bzImage for years
> > > from arch/x86_64/boot,
On Fri, 2007-10-05 at 05:22 +0200, Mathieu Chouquet-Stringer wrote:
> On Thu, Oct 04, 2007 at 05:12:11PM -0700, Linus Torvalds wrote:
> > I also tested that "ulimit -s" seems to do the right thing for me.
> >
> > I'm also assuming Mathieu is running x86 (or x86-64): HP-PA has a stack
> > that gro
> > cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory
> >
> > Obviously, this file has moved to arch/x86/boot, but it seems like
> > possibly unnecessary breakage. I've been copying bzImage for years
> > from arch/x86_64/boot, and I'm sure there's a handful of scripts
> > (o
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> On 10/2/07, Alistair John Strachan <[EMAIL PROTECTED]> wrote:
> > This is certainly a tool issue, but if I use Debian's kernel-image
> > "make-kpkg"
> > wrapper around the kernel build system, it fails with:
> >
> > cp: cannot stat `arch/x
* Alistair John Strachan <[EMAIL PROTECTED]> wrote:
> On Tuesday 02 October 2007 04:41:49 Linus Torvalds wrote:
> [snip]
> > In other words, people who know they may be affected and would want to
> > prepare can look at (for example)
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tglx/
On Thu, Oct 04, 2007 at 05:12:11PM -0700, Linus Torvalds wrote:
> I also tested that "ulimit -s" seems to do the right thing for me.
>
> I'm also assuming Mathieu is running x86 (or x86-64): HP-PA has a stack
> that grows upwards, and that has traditionally been exciting.
Correct, x86 it is but
On Fri, 5 Oct 2007, Paul Mackerras wrote:
> Linus Torvalds writes:
> >
> > Well, since others definitely don't see this, including me, and I can do
> > things like 62MB exec arrays:
> >
> > [EMAIL PROTECTED] linux]$ echo $(find /home/torvalds/) | wc
> > 1 883304 63000962
>
> Th
Linus Torvalds writes:
> Well, since others definitely don't see this, including me, and I can do
> things like 62MB exec arrays:
>
> [EMAIL PROTECTED] linux]$ echo $(find /home/torvalds/) | wc
> 1 883304 63000962
That wouldn't actually do an exec, assuming you're using bash,
On Thu, Oct 04, 2007 at 07:17:50PM +0200, Peter Zijlstra wrote:
> what happens if you up the stack limit to say 128M ?
>
> Also, do you happen to have execve syscall audit stuff enabled?
Actually, you were right, not only it's enabled but it's also the
culprit. If I stop it, all is well...
Sorr
On Thu, Oct 04, 2007 at 05:50:00PM -0400, Chuck Ebbert wrote:
> On 10/04/2007 01:05 PM, Mathieu Chouquet-Stringer wrote:
> > In the kernel source tree, if I run a stupid find | xargs ls, I now get
> > this:
> > xargs: ls: Argument list too long
> >
>
> Can you strace it to see what syscall is fai
On 10/04/2007 01:05 PM, Mathieu Chouquet-Stringer wrote:
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this:
> xargs: ls: Argument list too long
>
Can you strace it to see what syscall is failing?
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
On Thu, Oct 04, 2007 at 07:17:50PM +0200, Peter Zijlstra wrote:
> /me tries
>
> yep works like a charm, and that is a tree with a full git repo and
> several build dirs in it.
Well, what can I say? ;-)
> what happens if you up the stack limit to say 128M ?
It's unlimited.
> Also, do you happen
Thank you for getting back to me.
On Thu, Oct 04, 2007 at 10:27:52AM -0700, Linus Torvalds wrote:
> What does your "ulimit -s" say?
That's actually the first thing I checked.
mchouque - /usr/src/kernel/linux %ulimit -s
unlimited
And for the record, ulimit -a yields:
-t: cpu time (seconds)
On Thu, 4 Oct 2007, Mathieu Chouquet-Stringer wrote:
>
> Anything else you'd like me to try?
Well, since others definitely don't see this, including me, and I can do
things like 62MB exec arrays:
[EMAIL PROTECTED] linux]$ echo $(find /home/torvalds/) | wc
1 883304 63000
Hey there,
I've seen the changes you made in commit b6a2fea39318 and I guess they
might be responsible for my xargs breakage...
In the kernel source tree, if I run a stupid find | xargs ls, I now get
this:
xargs: ls: Argument list too long
Which is kind of annoying but I can work around
On Thu, 4 Oct 2007, Mathieu Chouquet-Stringer wrote:
>
> I've seen the changes you made in commit b6a2fea39318 and I guess they
> might be responsible for my xargs breakage...
>
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this:
> xargs: ls: Argument list too long
On Thu, 2007-10-04 at 19:05 +0200, Mathieu Chouquet-Stringer wrote:
> Hey there,
>
> I've seen the changes you made in commit b6a2fea39318 and I guess they
> might be responsible for my xargs breakage...
>
> In the kernel source tree, if I run a stupid find | xargs ls, I now get
> this:
> xargs:
On 10/4/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 08:11:05AM -0700, Linus Torvalds wrote:
> >...
> > and btw, there is no question what-so-ever about whether your compiler
> > might be doing a legal optimization - the compiler really is wrong, and is
> > total shit. You n
On Wed, Oct 03, 2007 at 08:11:05AM -0700, Linus Torvalds wrote:
>...
> and btw, there is no question what-so-ever about whether your compiler
> might be doing a legal optimization - the compiler really is wrong, and is
> total shit. You need to make a gcc bug-report.
>...
Ingo can't send a gcc b
On Wed, 3 Oct 2007, Jeff Garzik wrote:
>
> I'm a bit confused... you typed 2.6.24-rc4; I'm guessing you meant
> 2.6.24-rc1, but did you mean
No, I just meant "2.6.24 merge window", so:
> "x86 merge as soon as 2.6.23 is released" (merge window opens)
is the correct interpretation.
It w
Linus Torvalds wrote:
Doing it as early as possible in the 2.6.24-rc4 series (basically I'll do
it first thing) will mean that we'll have the maximum amount of time to
sort out any issues, and the thing is, Thomas and Ingo already have a tree
ready to go, so people can check their work against
On Wed, 3 Oct 2007, Jan Engelhardt wrote:
>
> >When I'm ruler of the universe, it *will* be illegal. I'm just getting a
> >bit ahead of myself.
>
> Any time frame when that will happen?
I'm working on it, I'm working on it. I'm just as frustrated as you are.
It turns out to be a non-trivial p
On Oct 3 2007 09:09, Linus Torvalds wrote:
>On Wed, 3 Oct 2007, Alan Cox wrote:
>>
>> > and btw, there is no question what-so-ever about whether your compiler
>> > might be doing a legal optimization - the compiler really is wrong, and is
>>
>> Pedant: valid. Almost all optimizations are legal,
On Wed, 3 Oct 2007, Alan Cox wrote:
>
> > and btw, there is no question what-so-ever about whether your compiler
> > might be doing a legal optimization - the compiler really is wrong, and is
>
> Pedant: valid. Almost all optimizations are legal, nobody has yet written
> laws about compilers.
1 - 100 of 299 matches
Mail list logo
