]: *** [mm/memory.o] Error 1
make: *** [mm] Error 2
This fix is just a copy of what is found in later kernels.
Compiled and boot tested both 3.0.80 and 3.2.45, x86_64 and i386.
Signed-off-by: Antoine Martin
--- a/arch/um/include/asm/pgtable.h 2013-05-25 09:20:51.42000 +
+++ b/arch/um
]: *** [mm/memory.o] Error 1
make: *** [mm] Error 2
This fix is just a copy of what is found in later kernels.
Compiled and boot tested both 3.0.80 and 3.2.45, x86_64 and i386.
Signed-off-by: Antoine Martin anto...@nagafix.co.uk
--- a/arch/um/include/asm/pgtable.h 2013-05-25 09:20:51.42000
Carlo Marcelo Arenas Belon wrote:
> On Sat, Jan 12, 2008 at 11:01:28PM +0200, Avi Kivity wrote:
>> Antoine Martin wrote:
>>
>>> FYI, just tried building 2.6.24-rc7-git4 and got this warning:
>>> (...)
>> Probably harmless, but worth reporting to lkml.
>
Carlo Marcelo Arenas Belon wrote:
On Sat, Jan 12, 2008 at 11:01:28PM +0200, Avi Kivity wrote:
Antoine Martin wrote:
FYI, just tried building 2.6.24-rc7-git4 and got this warning:
(...)
Probably harmless, but worth reporting to lkml.
couldn't replicate it here, but I'd seen usually those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
These are pure cpu scheduling tests, not doing any I/O this time.
All these tests are still "pathological" in the sense that they are only
meant to show differences between schedulers rather than try to simulate
real usage scenarios.
all the graphs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
These are pure cpu scheduling tests, not doing any I/O this time.
All these tests are still pathological in the sense that they are only
meant to show differences between schedulers rather than try to simulate
real usage scenarios.
all the graphs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Ted / LKML,
I've got this snapshot of an ext3 filesystem with a directory that
simply cannot be removed! (image below is just 1.2MB)
As root:
# wget http://users.nagafix.co.uk/~antoine/root-broken.bz2
# bunzip2 root-broken.bz2
# mount -o loop -t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Satyam Sharma wrote:
> I don't have access to any real/meaningful SMP systems, so I wonder
> how much sense it makes in practical terms for me to try and run these
> tests locally on my little boxen ... would be helpful if someone with
> 4/8 CPU
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Satyam Sharma wrote:
I don't have access to any real/meaningful SMP systems, so I wonder
how much sense it makes in practical terms for me to try and run these
tests locally on my little boxen ... would be helpful if someone with
4/8 CPU systems
binedTests4-10msYield-noload.png
Thanks Ingo!
Does this mean that I'll have to keep doing:
echo 1 > /proc/sys/kernel/sched_yield_bug_workaround
Or are you planning on finding a more elegant solution?
# find /proc -name "*workaround*"
/proc/sys/kernel/sched_yield_bug_workaround
/proc/sys/net/
on finding a more elegant solution?
# find /proc -name *workaround*
/proc/sys/kernel/sched_yield_bug_workaround
/proc/sys/net/ipv4/tcp_workaround_signed_windows
On 9/13/07, Antoine Martin [EMAIL PROTECTED] wrote:
All the 2.6.23-rc kernels performed poorly (except -rc3!):
This is an interesting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I've tested a couple more kernels: 2.6.23-rc4-mm1 and 2.6.23-rc6 with
the "sched_yield_bug_workaround" patch from Ingo, results are here:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I've tested a couple more kernels: 2.6.23-rc4-mm1 and 2.6.23-rc6 with
the sched_yield_bug_workaround patch from Ingo, results are here:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi list,
I was working on some unit tests and thought I'd give CFS a whirl to see
if it had any impact on my workloads (to see what the fuss was about),
and I came up with some pretty disturbing numbers:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi list,
I was working on some unit tests and thought I'd give CFS a whirl to see
if it had any impact on my workloads (to see what the fuss was about),
and I came up with some pretty disturbing numbers:
Geert Uytterhoeven wrote:
On Wed, 4 Apr 2007, Antoine Martin wrote:
and this one:
http://www.suse.de/~kraxel/uml/patches/2.6.18-rc4/uml-x11-fb
which applied cleanly, but is not letting me set the option - Kconfig is
beyond me:
arch/um/Kconfig:144:warning: 'select' used by config symbol 'X11_FB
Geert Uytterhoeven wrote:
On Wed, 4 Apr 2007, Antoine Martin wrote:
and this one:
http://www.suse.de/~kraxel/uml/patches/2.6.18-rc4/uml-x11-fb
which applied cleanly, but is not letting me set the option - Kconfig is
beyond me:
arch/um/Kconfig:144:warning: 'select' used by config symbol 'X11_FB
Antoine Martin wrote:
Jeff Dike wrote:
On Mon, Apr 02, 2007 at 01:22:00PM +0200, Geert Uytterhoeven wrote:
There are patches floating around for a UML frame buffer device.
Gerd Kraxel^H^H^H^H^H^HHoffmann did one using plain X11, which worked
great when I gave it a try.
I suggest taking a look
Blaisorblade wrote:
On lunedì 2 aprile 2007, Antoine Martin wrote:
Jeff Dike wrote:
On Sun, Apr 01, 2007 at 08:58:45PM +0100, Antoine Martin wrote:
I reckon that one critical thing which could drastically increase the
user base would be to have a working virtual framebuffer implementation
Blaisorblade wrote:
On lunedì 2 aprile 2007, Antoine Martin wrote:
Jeff Dike wrote:
On Sun, Apr 01, 2007 at 08:58:45PM +0100, Antoine Martin wrote:
I reckon that one critical thing which could drastically increase the
user base would be to have a working virtual framebuffer implementation
Antoine Martin wrote:
Jeff Dike wrote:
On Mon, Apr 02, 2007 at 01:22:00PM +0200, Geert Uytterhoeven wrote:
There are patches floating around for a UML frame buffer device.
Gerd Kraxel^H^H^H^H^H^HHoffmann did one using plain X11, which worked
great when I gave it a try.
I suggest taking a look
Jeff Dike wrote:
On Mon, Apr 02, 2007 at 11:21:43AM +0100, Antoine Martin wrote:
Just like the network auto-configuration via dhcp, it would allow users
to download images+kernel and run them like appliances without
understanding anything about X or UML, just click and run.
True, but I don't
Jeff Dike wrote:
On Mon, Apr 02, 2007 at 01:22:00PM +0200, Geert Uytterhoeven wrote:
There are patches floating around for a UML frame buffer device.
Gerd Kraxel^H^H^H^H^H^HHoffmann did one using plain X11, which worked
great when I gave it a try.
I suggest taking a look at Gerd's patches.
Jeff Dike wrote:
On Sun, Apr 01, 2007 at 08:58:45PM +0100, Antoine Martin wrote:
I reckon that one critical thing which could drastically increase the
user base would be to have a working virtual framebuffer implementation.
Why? I've never understood what a framebuffer gives you that you
Jeff Dike wrote:
On Sun, Apr 01, 2007 at 08:58:45PM +0100, Antoine Martin wrote:
I reckon that one critical thing which could drastically increase the
user base would be to have a working virtual framebuffer implementation.
Why? I've never understood what a framebuffer gives you that you
Jeff Dike wrote:
On Mon, Apr 02, 2007 at 11:21:43AM +0100, Antoine Martin wrote:
Just like the network auto-configuration via dhcp, it would allow users
to download images+kernel and run them like appliances without
understanding anything about X or UML, just click and run.
True, but I don't
Jeff Dike wrote:
On Mon, Apr 02, 2007 at 01:22:00PM +0200, Geert Uytterhoeven wrote:
There are patches floating around for a UML frame buffer device.
Gerd Kraxel^H^H^H^H^H^HHoffmann did one using plain X11, which worked
great when I gave it a try.
I suggest taking a look at Gerd's patches.
[...]
in short:
it`s quite some work to be done to have your uml 2.6.21 with root-fs up and
running and working cleanly. whenever i search the net for some appropriate
UML fs image, those i find are very often old and outdated...
Hmm... I'd think we need a wizard for configuration. Plus some
[...]
in short:
it`s quite some work to be done to have your uml 2.6.21 with root-fs up and
running and working cleanly. whenever i search the net for some appropriate
UML fs image, those i find are very often old and outdated...
Hmm... I'd think we need a wizard for configuration. Plus some
Re:
http://lkml.org/lkml/2007/1/28/146
Just got a similar OOPS on a system under heavy load (transcode + p2p),
with kernel 2.6.20.3 / x86_64 (in free_block).
[] free_block+0xae/0x13c
[] drain_array+0x93/0xd1
[] cache_reap+0xea/0x239
[] cache_reap+0x0/0x239
[] run_workqueue+0x95/0x140
[]
Re:
http://lkml.org/lkml/2007/1/28/146
Just got a similar OOPS on a system under heavy load (transcode + p2p),
with kernel 2.6.20.3 / x86_64 (in free_block).
[802c5b95] free_block+0xae/0x13c
[802c5cb6] drain_array+0x93/0xd1
[802c6820] cache_reap+0xea/0x239
I just caught this in the log whilst running some unit tests.
(the test was in the process of starting 900 Java threads)
audit(1171565587.887:96): enforcing=0 old_enforcing=1 auid=4294967295
BUG: warning at kernel/cpu.c:51/unlock_cpu_hotplug()
Call Trace:
[] dump_stack+0x12/0x17
[]
I just caught this in the log whilst running some unit tests.
(the test was in the process of starting 900 Java threads)
audit(1171565587.887:96): enforcing=0 old_enforcing=1 auid=4294967295
BUG: warning at kernel/cpu.c:51/unlock_cpu_hotplug()
Call Trace:
[80269c98]
Andi Kleen wrote:
[Snip]
You run with report_lost_ticks and report the results to linux-kernel
Doing as I am told, here we go:
This is 100% reproducible, ie: just doing a big rsync between 2 disks
and burning a DVD at the same time. Note: the system isn't very
responsive when this happens,
Andi Kleen wrote:
[Snip]
You run with report_lost_ticks and report the results to linux-kernel
Doing as I am told, here we go:
This is 100% reproducible, ie: just doing a big rsync between 2 disks
and burning a DVD at the same time. Note: the system isn't very
responsive when this happens,
As Matt Mackall said:
"So yes, if a user reports a bug that's attributable to a single bit
memory error that's otherwise unreproduced and unexplained, it's totally
reasonable to chalk it up to cosmic rays until some sort of pattern of
reports emerges."
So I guess that the only way to figure
As Matt Mackall said:
So yes, if a user reports a bug that's attributable to a single bit
memory error that's otherwise unreproduced and unexplained, it's totally
reasonable to chalk it up to cosmic rays until some sort of pattern of
reports emerges.
So I guess that the only way to figure
> > [ 4788.218951] Unable to handle kernel NULL pointer dereference at
> > 0028 RIP:
> > [ 4788.218959] {inode_has_perm+81}
> > [ 4788.218971] PGD 2485f067 PUD 0
> > [ 4788.218975] Oops: [1] PREEMPT
> > [ 4788.218977] CPU 0
> > [ 4788.218979] Modules linked in: parport_pc lp
[ 4788.218951] Unable to handle kernel NULL pointer dereference at
0028 RIP:
[ 4788.218959] 80247381{inode_has_perm+81}
[ 4788.218971] PGD 2485f067 PUD 0
[ 4788.218975] Oops: [1] PREEMPT
[ 4788.218977] CPU 0
[ 4788.218979] Modules linked in: parport_pc lp
39 matches
Mail list logo
