Re: Page fault in swp_pager_meta_build()
:It currently has no swap started at all, which is one reason I was rather :puzzled to see this panic: : :192.168.50.1:/cboss/devel/nfsroot/crash2.cboss.tislabs.com / nfs ro 0 : 0 :proc/proc procfs rw 0 0 :/dev/ad0s1e /mntufs rw 0 0 :... :Should it even be hitting this code if swap hasn't been enabled? I've run :into a couple of other weird bugs and wouldn't be surprised if there is a :memory allocation problem. The problem I was actually trying to reproduce :with these two crash boxes was one where the socket used by NFS get :zero'd, resulting in a null pointer dereference. The other one is in odd :panic in the mutex code during an early VFS operation. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project The case can be hit but it shouldn't have found any swap to free. Huh. Maybe there is a degenerate case in the swap code that blows up if swap is compiled in but no swap has been added. If the problem goes away when you add a tiny amount of swap that would confirm it. What is the 'swhash_mask' global contain? -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page fault in swp_pager_meta_build()
On Sun, 28 Apr 2002, Matthew Dillon wrote: > > :(Matt gets CC'd because he's just unlucky :-) > : > :This system is (as always) a pxeboot'd nfsroot'd dual processor box. This > :time, however, it's running straight GENERIC from the main tree instead of > :the MAC branch. The box network boots, does a buildkernel -j 8, and then > :reboots. It currently has no configured swap, suggesting that things > :broke down when it tried to think about using some swap. Not sure how > :many loops it took to get to this, but I've seen a couple of different > :panics that I'll be posting about as they recur. I'm actually trying to > :track an odd mbuf/nfs interaction... > > No idea, but the last time someone had a weird swap issue it > turned out that they had swapon'd the same swap partition twice. > The system's checks are not sufficient if you swapon the same device > from different mounts. So check that first. It currently has no swap started at all, which is one reason I was rather puzzled to see this panic: 192.168.50.1:/cboss/devel/nfsroot/crash2.cboss.tislabs.com / nfs ro 0 0 proc/proc procfs rw 0 0 /dev/ad0s1e /mntufs rw 0 0 > The swap code preallocates its bitmap space, the hash table array is > malloc'd once at boot time, and the swblock is zalloc()'d. From the > looks of it the hash chain either got corrupted somehow or part of > the kernel's KVM space containing either the hash table or > the swblock's got corrupted. Unless someone worked on the swap > code recently I would focus on either the memory subsystem or > on unrelated kernel subsystems blowing up KVK. Should it even be hitting this code if swap hasn't been enabled? I've run into a couple of other weird bugs and wouldn't be surprised if there is a memory allocation problem. The problem I was actually trying to reproduce with these two crash boxes was one where the socket used by NFS get zero'd, resulting in a null pointer dereference. The other one is in odd panic in the mutex code during an early VFS operation. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page fault in swp_pager_meta_build()
On Sun, 28 Apr 2002, Hiten Pandya wrote: > Talking about doing something twice, it reminds me, that there is the same > type of issue with the md devices, which when they are destroyed twice or > thrice, they panic the kernel. Re.v.108 of kern_conf.c fixes similar bugs. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page fault in swp_pager_meta_build()
--- Matthew Dillon <[EMAIL PROTECTED]> wrote: > No idea, but the last time someone had a weird swap issue it > turned out that they had swapon'd the same swap partition twice. > The system's checks are not sufficient if you swapon the same device > from different mounts. So check that first. Talking about doing something twice, it reminds me, that there is the same type of issue with the md devices, which when they are destroyed twice or thrice, they panic the kernel. I talked about this issue before but it didn't get discussed further, and the other thing is, I am not able to produce a kernel crash dump. Regards, -- Hiten __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page fault in swp_pager_meta_build()
:(Matt gets CC'd because he's just unlucky :-)
:
:This system is (as always) a pxeboot'd nfsroot'd dual processor box. This
:time, however, it's running straight GENERIC from the main tree instead of
:the MAC branch. The box network boots, does a buildkernel -j 8, and then
:reboots. It currently has no configured swap, suggesting that things
:broke down when it tried to think about using some swap. Not sure how
:many loops it took to get to this, but I've seen a couple of different
:panics that I'll be posting about as they recur. I'm actually trying to
:track an odd mbuf/nfs interaction...
No idea, but the last time someone had a weird swap issue it
turned out that they had swapon'd the same swap partition twice.
The system's checks are not sufficient if you swapon the same device
from different mounts. So check that first.
The swap code preallocates its bitmap space, the hash table array is
malloc'd once at boot time, and the swblock is zalloc()'d. From the
looks of it the hash chain either got corrupted somehow or part of
the kernel's KVM space containing either the hash table or
the swblock's got corrupted. Unless someone worked on the swap
code recently I would focus on either the memory subsystem or
on unrelated kernel subsystems blowing up KVK.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:Fatal trap 12: page fault while in kernel mode
:cpuid = 0; lapic.id =
:fault virtual address = 0x20097479
:fault code = supervisor read, page not present
:instruction pointer = 0x8:0xc0337da8
:stack pointer = 0x10:0xc8f22b2c
:frame pointer = 0x10:0xc8f22b38
:code segment= base 0x0, limit 0xf, type 0x1b
:= DPL 0, pres 1, def32 1, gran 1
:processor eflags= interrupt enabled, resume, IOPL = 0
:current process = 2 (pagedaemon)
:kernel: type 12 trap, code=0
:Stopped at swp_pager_meta_build+0xf0: cmpl%ebx,0x4(%eax)
:db> trace
:swp_pager_meta_build(c97ff120,0,8000) at swp_pager_meta_build+0xf0
:swap_pager_putpages(c97ff120,c8f22c34,4,0,c8f22bbc) at
:swap_pager_putpages+0x57
:default_pager_putpages(c97ff120,c8f22c34,4,0,c8f22bbc,c0428be0,1,c03ebb80,8e)
:at default_pager_putpages+0x17
:vm_pageout_flush(c8f22c34,4,0,c03d0c7a,246) at vm_pageout_flush+0xe5
:vm_pageout_clean(c0a09204) at vm_pageout_clean+0x1ec
:vm_pageout_scan(0,c034469c,c8f22d34,c023d838,0) at vm_pageout_scan+0x35a
:vm_pageout(0,c8f22d48,c8e2c728,c034469c,0) at vm_pageout+0x231
:fork_exit(c034469c,0,c8f22d48) at fork_exit+0x88
:fork_trampoline() at fork_trampoline+0x37
:
:(kgdb) l *swp_pager_meta_build+0xf0
:0xc0337da8 is in swp_pager_meta_build (../../../vm/swap_pager.c:1654).
:1649struct swblock *swap;
:1650
:1651index &= ~SWAP_META_MASK;
:1652pswap = &swhash[(index ^ (int)(intptr_t)object) & swhash_mask];
:1653while ((swap = *pswap) != NULL) {
:1654if (swap->swb_object == object &&
:1655swap->swb_index == index
:1656) {
:1657break;
:1658}
:
:
:Robert N M Watson FreeBSD Core Team, TrustedBSD Project
:[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Page fault in swp_pager_meta_build()
(Matt gets CC'd because he's just unlucky :-)
This system is (as always) a pxeboot'd nfsroot'd dual processor box. This
time, however, it's running straight GENERIC from the main tree instead of
the MAC branch. The box network boots, does a buildkernel -j 8, and then
reboots. It currently has no configured swap, suggesting that things
broke down when it tried to think about using some swap. Not sure how
many loops it took to get to this, but I've seen a couple of different
panics that I'll be posting about as they recur. I'm actually trying to
track an odd mbuf/nfs interaction...
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x20097479
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0337da8
stack pointer = 0x10:0xc8f22b2c
frame pointer = 0x10:0xc8f22b38
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (pagedaemon)
kernel: type 12 trap, code=0
Stopped at swp_pager_meta_build+0xf0: cmpl%ebx,0x4(%eax)
db> trace
swp_pager_meta_build(c97ff120,0,8000) at swp_pager_meta_build+0xf0
swap_pager_putpages(c97ff120,c8f22c34,4,0,c8f22bbc) at
swap_pager_putpages+0x57
default_pager_putpages(c97ff120,c8f22c34,4,0,c8f22bbc,c0428be0,1,c03ebb80,8e)
at default_pager_putpages+0x17
vm_pageout_flush(c8f22c34,4,0,c03d0c7a,246) at vm_pageout_flush+0xe5
vm_pageout_clean(c0a09204) at vm_pageout_clean+0x1ec
vm_pageout_scan(0,c034469c,c8f22d34,c023d838,0) at vm_pageout_scan+0x35a
vm_pageout(0,c8f22d48,c8e2c728,c034469c,0) at vm_pageout+0x231
fork_exit(c034469c,0,c8f22d48) at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x37
(kgdb) l *swp_pager_meta_build+0xf0
0xc0337da8 is in swp_pager_meta_build (../../../vm/swap_pager.c:1654).
1649struct swblock *swap;
1650
1651index &= ~SWAP_META_MASK;
1652pswap = &swhash[(index ^ (int)(intptr_t)object) & swhash_mask];
1653while ((swap = *pswap) != NULL) {
1654if (swap->swb_object == object &&
1655swap->swb_index == index
1656) {
1657break;
1658}
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
page fault in swp_pager_meta_build
This is from -CURRENT a few days ago with the TrustedBSD MAC patches.
Unfortunately, I don't know what time the panic occurred, so I can't say
what the machine was doing. Either it was largely idle, or it was working
on a make -j 8 buildworld. It's a pxeboot'd machine, with most
filesystems out of NFS, including the root filesystem, with the exception
of /usr/obj, which is locally mounted, swap, which is also local, and the
normal set of /tmp, /var, etc, that are md-backed FFS filesystems. The
only unusual thing about the setup was that I started the buildworld, got
a "swap_pager_getswapspace: failed", then did swapon /dev/ad0s1b.
Normally, I'd start swap when it booted, but there was a problem merging
the configuration during the update, so that was lost. Panic and trace
below.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x82004
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc034753c
stack pointer = 0x10:0xc8f00b38
frame pointer = 0x10:0xc8f00b44
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (pagedaemon)
kernel: type 12 trap, code=0
Stopped at swp_pager_meta_build+0xf0: cmpl%ebx,0x4(%eax)
db> trace
swp_pager_meta_build(ca733660,0,8000) at swp_pager_meta_build+0xf0
swap_pager_putpages(ca733660,c8f00c34,1,0,c8f00bc8) at
swap_pager_putpages+0x57
default_pager_putpages(ca733660,c8f00c34,1,0,c8f00bc8,c0440760,1,c0403580,8e) at
default_pager_putpages+0x17
vm_pageout_flush(c8f00c34,1,0,1,c03dc437) at vm_pageout_flush+0xe5
vm_pageout_clean(c0a09678) at vm_pageout_clean+0x1ec
vm_pageout_scan(0,c0353ce8,c8f00d34,c023d1d4,0) at vm_pageout_scan+0x35a
vm_pageout(0,c8f00d48,c8e20730,c0353ce8,0) at vm_pageout+0x231
fork_exit(c0353ce8,0,c8f00d48) at fork_exit+0x88
fork_trampoline() at fork_trampoline
For reference purposes:
(kgdb) l *0xc034753c
0xc034753c is in swp_pager_meta_build (../../../vm/swap_pager.c:1654).
1649struct swblock *swap;
1650
1651index &= ~SWAP_META_MASK;
1652pswap = &swhash[(index ^ (int)(intptr_t)object) & swhash_mask];
1653while ((swap = *pswap) != NULL) {
1654if (swap->swb_object == object &&
1655swap->swb_index == index
1656) {
1657break;
1658}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
