ake[1]: *** [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/ar
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.
>
-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 syst
ManyThreads-CombinedTests4-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_worka
-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:
http://devloop.org.uk/documentation/database-performance/Linux-Kernels/Kernels-ManyThreads-CombinedTests3-10msYi
-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:
http://devloop.org.uk/documentation/database-
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 symb
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
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&#
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. IIRC
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 tha
[...]
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 di
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
[] worker
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
[] unlock_cpu_
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, mo
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 o
> > [ 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 parpo
20 matches
Mail list logo
