* Sunil Naidu <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> This is what am getting:-
>
> arch/i386/mm/built-in.o: In function `flush_cr3_cache':
> (.text+0x25c): undefined reference to `paravirt_enabled'
> arch/i386/mm/built-in.o: In function `flush_cr3_cache':
> (.text+0x26c): undefined referenc
S.Çağlar Onur wrote:
Hi;
01 Şub 2007 Per tarihinde, Linus Torvalds şunları yazmıştı:
I've added some initramfs people to the Cc: in case somebody has better
ideas, but in the absense of that, it really would be good to do that
bisection. Also, you might want to double-check that your cpio actu
Hi;
01 Şub 2007 Per tarihinde, Linus Torvalds şunları yazmıştı:
> I've added some initramfs people to the Cc: in case somebody has better
> ideas, but in the absense of that, it really would be good to do that
> bisection. Also, you might want to double-check that your cpio actually
> generates a
Alexander E. Patrakov wrote:
What's the proper way to make sure that the fix, when it appears, ends
up in my inbox?
Say "please", and give prompt feedback on any test patches that we send you.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On 1/31/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
When do_tune_cpucache() is called at bootup, I'm not sure how safe it is
to do the kzalloc() thing.
The kzalloc thing is safe as we have already successfully boostrapped
all kmalloc caches at that point. The per-CPU caches that are replaced
H. Peter Anvin wrote:
Linus Torvalds wrote:
On Wed, 31 Jan 2007, H. Peter Anvin wrote:
It would be interesting to know what the inode numbers are in the
image; also,
what is the exact behaviour -- do you end up with a missing link, or
do both
entries end up getting hard-linked to an empty fi
Linus Torvalds wrote:
On Wed, 31 Jan 2007, H. Peter Anvin wrote:
It would be interesting to know what the inode numbers are in the image; also,
what is the exact behaviour -- do you end up with a missing link, or do both
entries end up getting hard-linked to an empty file?
Judging by the
On Wed, 31 Jan 2007, H. Peter Anvin wrote:
>
> It would be interesting to know what the inode numbers are in the image; also,
> what is the exact behaviour -- do you end up with a missing link, or do both
> entries end up getting hard-linked to an empty file?
Judging by the
request_mod
Linus Torvalds wrote:
On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
I think i found the cause of the problem, initramfs can't handle hardlinks
anymore (which works with 2.6.18), copying same /sbin/busybox binary with
different names into initramfs (which ends ups with 50 MB image) or using
symboli
On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
>
> I think i found the cause of the problem, initramfs can't handle hardlinks
> anymore (which works with 2.6.18), copying same /sbin/busybox binary with
> different names into initramfs (which ends ups with 50 MB image) or using
> symbolic ones inste
01 Şub 2007 Per tarihinde, Linus Torvalds şunları yazmıştı:
> That _usually_ just means that /sbin/modprobe is corrupt, or compiled with
> a binfmt that itself needs a module to load.
>
> Are you 100% certain that you didn't just happen to put an /sbin/modprobe
> into your initramfs that happens t
On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
>
> For me, both 2.6.20-rc6 and 2.6.20-rc7 fails while booting with initramfs
> (initramfs that uses busybox) with "request_module: runaway loop modprobe
> binfmt-" error.
That _usually_ just means that /sbin/modprobe is corrupt, or compiled with
Hi;
31 Oca 2007 Çar tarihinde şunları yazmıştınız:
> In other words, please do give it a good testing. We should have fixed the
> nasty stuff on Adrian's list (and here's another thanks to Adrian for
> keeping me on my toes!) and it's all good. But please give it a quick
> shake-down to make sure
On Thu, 1 Feb 2007, Nick Piggin wrote:
>
> We could make them both unsigned, and _add_ everything to min rather than
> subtracting from free_pages?
Yeah, that's the right thing to do, probably. However, since we do that
"min >>=1" thing, we'd have to do that to a separate "correction" factor
Linus Torvalds wrote:
if (free_pages <= min + z->lowmem_reserve[classzone_idx])
return 0;
gets broken, because the negative 'free_pages' will look like a huge
unsigned positive number (and we'll make it unsigned becaue 'min' got
turned unsigned). There was a reason tha
On Wed, 31 Jan 2007, Andrew Morton wrote:
>
> It would be cleaner to check for negativity, but note that we keep
> subtracting stuff from free_pages in the later loop, so we'd need to check
> there as well.
Yeah, not worth it. I'll just revert it.
If we really want to do the micro-optimization
On Wed, 31 Jan 2007 16:19:06 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I should either revert that commit or just check for "free_pages" being
> negative. The latter, in many ways, is probably better, because generally
> we simply should never work with negative numbers in the kern
On Thu, 1 Feb 2007, PaweÅ Sikora wrote:
>
> 2.6.18 works, 2.6.19-rc1 doesn't work.
> git bisect found this bad commit:
Git bisect rocks.
I'll give myself yet abother pat on the back for writing it. You can never
encourage genius like that too much.
> commit e80ee884ae0e3794ef2b65a18a767d502a
On Thu, 1 Feb 2007 00:37:48 +0100
Pawe__ Sikora <[EMAIL PROTECTED]> wrote:
> On Wednesday 31 of January 2007 17:04:29 Linus Torvalds wrote:
> > On Wed, 31 Jan 2007, Pawe__ Sikora wrote:
> > > The 2.6.20-rcX have the same nasty bug as 2.6.19.x.
> > >
> > > [ an oops inside kmem_get_pages ]
> > > ht
On Wed, 31 Jan 2007 08:04:29 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 31 Jan 2007, Pawe__ Sikora wrote:
> >
> > The 2.6.20-rcX have the same nasty bug as 2.6.19.x.
> >
> > [ an oops inside kmem_get_pages ]
> > http://bugzilla.kernel.org/show_bug.cgi?id=7889
>
> Pabe
On 1/31/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
It's in good enough shape that I'd probably have been happy to just
release it as 2.6.20, but since I want 2.6.20 to be a stability release, I
didn't want to risk any stupid bugs while the regressions got fixed, so
here's a final -rc7.
It's
On Wed, 31 Jan 2007, PaweÅ Sikora wrote:
>
> The 2.6.20-rcX have the same nasty bug as 2.6.19.x.
>
> [ an oops inside kmem_get_pages ]
> http://bugzilla.kernel.org/show_bug.cgi?id=7889
Pabel, can you detail more exactly which kernels don't work, and which do?
>From bugzilla:
- 2.6.18.x does
22 matches
Mail list logo
