# weird dmesg message with many fffffffffffffffs {SOLVED}

## _______0

I have a weird problem with 3.7.0, no sure if it's something to do with a mem related kernel option.

```
vmalloc: allocation failure: 0 bytes

modprobe: page allocation failure: order:0, mode:0xd2

Pid: 26382, comm: modprobe Not tainted 3.7.0-gentoo #1

Call Trace:

 [<ffffffff810c9084>] 0xffffffff810c9084

 [<ffffffff810f76b9>] 0xffffffff810f76b9

 [<ffffffff81086d18>] ? 0xffffffff81086d18

 [<ffffffff81022475>] 0xffffffff81022475

 [<ffffffff81086d18>] ? 0xffffffff81086d18

 [<ffffffff81086d18>] 0xffffffff81086d18

 [<ffffffff8108798e>] 0xffffffff8108798e

 [<ffffffff8111176b>] ? 0xffffffff8111176b

 [<ffffffff81217bc3>] ? 0xffffffff81217bc3

 [<ffffffff81088276>] 0xffffffff81088276

 [<ffffffff814221d2>] 0xffffffff814221d2

Mem-Info:

DMA per-cpu:

CPU    0: hi:    0, btch:   1 usd:   0

CPU    1: hi:    0, btch:   1 usd:   0

CPU    2: hi:    0, btch:   1 usd:   0

CPU    3: hi:    0, btch:   1 usd:   0

CPU    4: hi:    0, btch:   1 usd:   0

CPU    5: hi:    0, btch:   1 usd:   0

CPU    6: hi:    0, btch:   1 usd:   0

CPU    7: hi:    0, btch:   1 usd:   0

DMA32 per-cpu:

CPU    0: hi:  186, btch:  31 usd: 178

CPU    1: hi:  186, btch:  31 usd: 184

CPU    2: hi:  186, btch:  31 usd:   0

CPU    3: hi:  186, btch:  31 usd:  13

CPU    4: hi:  186, btch:  31 usd:   0

CPU    5: hi:  186, btch:  31 usd:   0

CPU    6: hi:  186, btch:  31 usd:   0

CPU    7: hi:  186, btch:  31 usd:   0

Normal per-cpu:

CPU    0: hi:  186, btch:  31 usd:  62

CPU    1: hi:  186, btch:  31 usd:  36

CPU    2: hi:  186, btch:  31 usd:  60

CPU    3: hi:  186, btch:  31 usd:  69

CPU    4: hi:  186, btch:  31 usd: 173

CPU    5: hi:  186, btch:  31 usd: 114

CPU    6: hi:  186, btch:  31 usd: 164

CPU    7: hi:  186, btch:  31 usd: 170

```

This happens during boot several times and then occasionally. The first victim so far is audio stopping, but no kernel panics yet.

How to fix this?Last edited by _______0 on Sat Dec 29, 2012 12:59 pm; edited 1 time in total

----------

## gerard27

Hexadecimal addresses.

Post your emerge --info.

Looks like you have a very unstable system.

Gerard.

----------

## wswartzendruber

Those look like stack addresses on a 64-bit system.

----------

## salahx

This can't be right - this is an out-of-memory error, but failed vmalloc call was trying to allocate 0 bytes! Until recently you cannot vmalloc 0 bytes (since fixed), but is probably a mistake to malloc 0 bytes anyway (even though its legal). Since modprobe triggered the error, its either  corrupt module or (more likely) a corrupt or missing firmware image in /lib/firmware for whatever module  it was trying to load.

----------

## _______0

solved by checking KALLSYMS kernel option.

Yet another kernel option that fails to work as advertised!!!

Some background on the issue from arch forums:

 *Quote:*   

> This problem appeared for me when I ported our code
> 
> from 2.6.36.4 to 3.2.16 - its quite annoying. Happens
> 
> when loading some modules. Used to also hang the
> ...

 

----------

## wswartzendruber

 *salahx wrote:*   

> This can't be right - this is an out-of-memory error, but failed vmalloc call was trying to allocate 0 bytes! Until recently you cannot vmalloc 0 bytes (since fixed), but is probably a mistake to malloc 0 bytes anyway (even though its legal). Since modprobe triggered the error, its either  corrupt module or (more likely) a corrupt or missing firmware image in /lib/firmware for whatever module  it was trying to load.

 

Allocating zero bytes might still require a page table entry.

----------

