* Bad page state with x86_64
@ 2006-09-26 10:18 Andreas Block
2006-09-26 12:41 ` Nick Piggin
0 siblings, 1 reply; 3+ messages in thread
From: Andreas Block @ 2006-09-26 10:18 UTC (permalink / raw)
To: linux-kernel
Hi,
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
Backtrace:
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
CPU 0
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,
Andreas
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bad page state with x86_64
2006-09-26 10:18 Bad page state with x86_64 Andreas Block
@ 2006-09-26 12:41 ` Nick Piggin
2006-09-27 7:20 ` Andreas Block
0 siblings, 1 reply; 3+ messages in thread
From: Nick Piggin @ 2006-09-26 12:41 UTC (permalink / raw)
To: Andreas Block; +Cc: linux-kernel
Andreas Block wrote:
> Hi,
>
> 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
> Backtrace:
>
> 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
> CPU 0
> 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.
It is freeing a PageReserved page. You should ensure to balance your
reference counting on *each* page (or allocate a compound page and
treat it as a single one). When you map pages into userspace via
nopage or remap_pfn_range, you need to increment their count, which
gets decremented by the VM when they are unmapped.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bad page state with x86_64
2006-09-26 12:41 ` Nick Piggin
@ 2006-09-27 7:20 ` Andreas Block
0 siblings, 0 replies; 3+ messages in thread
From: Andreas Block @ 2006-09-27 7:20 UTC (permalink / raw)
To: linux-kernel
On Tue, 26 Sep 2006 14:41:46 +0200, Nick Piggin <nickpiggin@yahoo.com.au>
wrote:
> It is freeing a PageReserved page. You should ensure to balance your
> reference counting on *each* page (or allocate a compound page and
> treat it as a single one). When you map pages into userspace via
> nopage or remap_pfn_range, you need to increment their count, which
> gets decremented by the VM when they are unmapped.
Thanks a lot for your time and help. Still there are a few things a
seemingly don't understand correctly.
Do I understand you right, I don't have to "put_page" after calling
"get_page" in my no-page handler?
Also I'm wondering, why this code works flawlessly on 2.6.10 32-Bit and
several 2.4.x kernels 32-Bit and PPC and is failing to work on x86_64,
only. Do I have to do the "get/put_page" mechanism differnetly on x86_64?
Another question:
In my no-page handler, I reserve the physical page. I do have to clear the
reserve bit of those page after unmap, right? Or is this done implicitly
as well?
Again, thanks for your effort.
--
-------------------------------------------------------------------------
_/_/_/_/ Andreas Block
_/_/_/_/ Dipl.-Ing.
_/_/_/_/ andreas.block@esd-electronics.com
_/_/_/ _/_/_/_/_/_/_/ esd electronic system design gmbh
_/ _/ _/ _/ Vahrenwalder Str. 207
_/ _/ _/_/_/ _/ _/ D-30165 Hannover
_/ _/ _/ _/ Phone: +49-511-37298-0
_/_/_/_/_/_/_/ _/_/_/ Fax: +49-511-37298-68
http://www.esd-electronics.com
-------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-09-27 7:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-26 10:18 Bad page state with x86_64 Andreas Block
2006-09-26 12:41 ` Nick Piggin
2006-09-27 7:20 ` Andreas Block
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox