Bad page state with x86_64

From: Andreas Block
Date: Tue Sep 26 2006 - 06:24:24 EST


the following problem occurs with a driver "pa_drv" written by myself under x84_64. Code works fine under x86_32 and with small modifications also under ppc. Problem also occurs under 2.6.15-1.2054_FC5.

Bad page state in process 'pa_test'
page:ffff810000869000 flags:0x0100000000000414 mapping:0000000000000000 mapcount:0 count:0
Trying to fix it up, but a reboot is needed

Call Trace:
[<ffffffff802642a4>] bad_page+0x4e/0x78
[<ffffffff80264591>] free_hot_cold_page+0x73/0xff
[<ffffffff8026c24e>] unmap_vmas+0x440/0x756
[<ffffffff8026f8f7>] unmap_region+0xb9/0x12c
[<ffffffff802705eb>] do_munmap+0x1fd/0x27a
[<ffffffff8043ed3d>] __down_write_nested+0x34/0x9e
[<ffffffff802706a8>] sys_munmap+0x40/0x5a
[<ffffffff80222508>] cstar_do_call+0x1b/0x65

----------- [cut here ] --------- [please bite here ] ---------
Kernel BUG at include/linux/mm.h:300
invalid opcode: 0000 [1] SMP
Modules linked in: pa_drv_k26 radeon drm autofs4 hidp nfs lockd nfs_acl rfcomm l2cap bluetooth sunrpc dm_mirror dm_mod video button battery asus_acpi ac ipv6 lp parport_pc parport floppy nvram snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm ehci_hcd ohci1394 ieee1394 ohci_hcd snd_timer snd soundcore i2c_nforce2 forcedeth i2c_core pcspkr snd_page_alloc ext3 jbd sata_nv libata sd_mod scsi_mod
Pid: 2722, comm: pa_test Tainted: G B 2.6.18 #1
RIP: 0010:[<ffffffff802647e7>] [<ffffffff802647e7>] __free_pages+0x7/0x2b
RSP: 0018:ffff8100064cfea0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff810012729ac0 RCX: 000000000000003f
RDX: 000000000001fff0 RSI: 0000000000000005 RDI: ffff810000869000
RBP: 0000000000005001 R08: 000000000804b02c R09: 00000000fff5a218
R10: 0000000000005001 R11: 0000000000005001 R12: 0000000000000000
R13: 0000000000005001 R14: ffff81001f534320 R15: ffff810012729ac0
FS: 00002acba44ea340(0000) GS:ffffffff8061f000(0063) knlGS:00000000f7faf6b0
CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 00000000f7fb1000 CR3: 000000000714e000 CR4: 00000000000006e0
Process pa_test (pid: 2722, threadinfo ffff8100064ce000, task ffff81000aaaa100)
Stack: ffffffff885071b2 ffff810012729ac0 ffffffff885071e5 0000000000000000
ffffffff88507373 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000005001
Call Trace:
[<ffffffff885071b2>] :pa_drv_k26:pa_free_local_buffer+0x1b/0x3b
[<ffffffff885071e5>] :pa_drv_k26:pa_destroy_local+0x13/0x17
[<ffffffff88507373>] :pa_drv_k26:pa_ioctl_unlocked+0x166/0x272
[<ffffffff802ad503>] compat_sys_ioctl+0xc5/0x2b2
[<ffffffff80222508>] cstar_do_call+0x1b/0x65

Code: 0f 0b 68 8e f5 46 80 c2 2c 01 90 ff 4f 08 0f 94 c0 84 c0 74
RIP [<ffffffff802647e7>] __free_pages+0x7/0x2b
RSP <ffff8100064cfea0>

I've a stripped down example, which reproduces the problem shown below. I'll happily sent an archive containing, code of driver, library and test application to anybody, who likes to spend a look at it or attach it to a mail to this list, if I'm allowed to do so.

Note: I'm not blaming the kernel to be buggy. It may well be, that the source of the problem sits between my keyboard and my chair, but I'd be very grateful for any advice on what I'm doing wrong, if so.

Best regards,

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at