Holger Lubitz wrote:
| Hi,
|
| I tried posting this before, but apparently it didn't get through to the
| list.
| The following are the final lines of a strace of a failing mplayer:
|
| [...]
| modify_ldt(0x1, 0xbffff85c, 0x10) = -1 ENOMEM (Cannot allocate
| memory)
| --- SIGSEGV (Segmentation fault) ---
| +++ killed by SIGSEGV +++
Do you have an NTFS disk mounted? I had a similar problem which was
"fixed" by not having an NTFS vol mounted. Apparently the ntfs code
makes a lot of calls to vmalloc which leads to badness.
See http://www.uwsg.indiana.edu/hypermail/linux/kernel/0112.1/0878.html
if interested.
Leigh Orf
Leigh Orf proclaimed:
> Do you have an NTFS disk mounted? I had a similar problem which was
> "fixed" by not having an NTFS vol mounted. Apparently the ntfs code
> makes a lot of calls to vmalloc which leads to badness.
Yes, I have. I'll try not mounting it. Which would be a better
workaround than disabling 1/8 of my RAM.
The funny thing is just - why does it work fine with up to 896 MB, but
gives ENOMEM with _more_ RAM?
Holger
Holger Lubitz wrote:
>
> Leigh Orf proclaimed:
> > Do you have an NTFS disk mounted? I had a similar problem which was
> > "fixed" by not having an NTFS vol mounted. Apparently the ntfs code
> > makes a lot of calls to vmalloc which leads to badness.
>
> Yes, I have. I'll try not mounting it. Which would be a better
> workaround than disabling 1/8 of my RAM.
> The funny thing is just - why does it work fine with up to 896 MB, but
> gives ENOMEM with _more_ RAM?
Because of the way the kernel uses its 1GB of virtual address space.
Physical memory is mapped 1:1 up to 960 MB, with the remaining virtual
address space (64MB or more) is reserved for virtual mappings like
vmalloc and ioremap.
--
Brian Gerst