Re: kernel BUG at arch/x86_64/mm/../../i386/mm/hugetlbpage.c:140!

From: Alexander Y. Fomichev
Date: Tue Mar 06 2007 - 07:46:14 EST


On Saturday 03 March 2007, Bill Irwin wrote:
> On Fri, Mar 02, 2007 at 04:51:15PM +0300, Alexander Y. Fomichev wrote:
> > I'm hit a bug on 2.6.21-rc1 at startup of mysql with 'large-pages' flag
> > set. (at this point mysql trying to allocate pages from hugetlb pool by
> > sysv shm syscalls). Seems like it could be triggered by previous badness
> > and probably hugetlb itself is not related. Anyway i couldn't reproduce
> > it by now with 2.6.21-rc2 git commit
> > 562aa1d4c6a874373f9a48ac184f662fbbb06a04. Very likely it has been fixed
> > somwhere between 2.6.21-rc1 and -rc2, but i couldn't find something
> > related by git log so any comments are welcome.
>
> If you have a known-working kernel version, git-bisect might help you
> track down where it was introduced. Given the messages prior to the
> hugetlbpage.c BUG_ON I'd say that this is something else besides the
> specific code listed by line number,

Nop, seems like it is hugetlb bug fixed by Adam
commit 516dffdcd8827a40532798602830dfcfc672294c
[PATCH] Fix get_unmapped_area and fsync for hugetlb shm segments
I've disregard it thoughtlessly so Adam marks it specific for powerpc/ia64.
(hmm.. i donno realy why, huge pages should be alined anyway and if i
understend it correctly it may not be if is_file_hugepages() fails)

As of "junk" just before the BUG this again IIUC because o-direct staff
catches this issue before hugetlb.

> though I wouldn't rule out hugetlb
> having tripped over itself before the actual BUG.
>

Yep, it is.

> -- wli


--
Best regards.
Alexander Y. Fomichev <gluk@xxxxxxx>
Public PGP key: http://sysadminday.org.ru/gluk.asc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/