Am Fri, 15 May 2009 12:05:47 -0400
schrieb John Baldwin j...@freebsd.org:
On Friday 15 May 2009 11:38:00 am Martin wrote:
Am Fri, 15 May 2009 11:09:20 -0400
schrieb John Baldwin j...@freebsd.org:
x/i please. The /i decodes it as an instruction so I can see
which registers it was
On Thu, May 14, 2009 at 03:32:34PM -0700, Chris Timmons wrote:
Can you get a stack trace? Your panic is quite different then the original
one.
Let me know if there is any other information which would be helpful. I
rebooted the 7.0 kernel from July, and the machine has been happily
#8 0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c,
dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89
89 *dswp = devvn_refthread(fp-f_vnode, devp);
(kgdb) p *(struct file *)0xc78fadf4
$1 = {f_list = {le_next = 0xc78ab5f0, le_prev = 0xc789e5f0}, f_type = 1,
On Fri, May 15, 2009 at 05:32:49AM -0700, Chris Timmons wrote:
#8 0xc076cf64 in devfs_fp_check (fp=0xc78fadf4, devp=0xee156b0c,
dswp=0xee156b08) at /usr/src/sys/fs/devfs/devfs_vnops.c:89
89*dswp = devvn_refthread(fp-f_vnode, devp);
(kgdb) p *(struct file *)0xc78fadf4
$1 =
On Thursday 14 May 2009 1:10:26 pm Martin wrote:
Am Thu, 14 May 2009 09:16:40 -0400
schrieb John Baldwin j...@freebsd.org:
On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote:
[...]
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
Am Fri, 15 May 2009 08:15:19 -0400
schrieb John Baldwin j...@freebsd.org:
Hi John,
When I have seen this, it has often been due to a hardware failure
such as bad RAM.
hmmm... I will check this next week.
cpuid = 2; apic id = 02
instruction pointer = 0x8:0x805bbc66
Can you do
On Friday 15 May 2009 10:57:27 am Martin wrote:
Am Fri, 15 May 2009 08:15:19 -0400
schrieb John Baldwin j...@freebsd.org:
Hi John,
When I have seen this, it has often been due to a hardware failure
such as bad RAM.
hmmm... I will check this next week.
cpuid = 2; apic id = 02
Hi John,
one more thing that I noticed. It seems that the netmask passed to the
procedure rt_maskedcopy is invalid. Cannot dereference the pointer.
I went one frame up and I've looked at the control flow of the parent
routine rtrequest1_fib. This routine passes the netmask, but before it
does
Am Fri, 15 May 2009 11:09:20 -0400
schrieb John Baldwin j...@freebsd.org:
x/i please. The /i decodes it as an instruction so I can see which
registers it was attempting to dereference.
Oh sorry...
(kgdb) x/i 0x805bbc66
0x805bbc66 rt_maskedcopy+6: movzbl (%rdx),%edx
--
On Friday 15 May 2009 11:36:18 am Martin wrote:
Hi John,
one more thing that I noticed. It seems that the netmask passed to the
procedure rt_maskedcopy is invalid. Cannot dereference the pointer.
I went one frame up and I've looked at the control flow of the parent
routine
Kostik,
Looking good after applying your patch and rebuilding the kernel. I've
been exercising the machine for a couple of hours under the same load
which crashed it in short order yesterday.
I will report back if any problems appear.
Thank you for your help!
Regards,
-Chris
last pid:
On Friday 15 May 2009 11:38:00 am Martin wrote:
Am Fri, 15 May 2009 11:09:20 -0400
schrieb John Baldwin j...@freebsd.org:
x/i please. The /i decodes it as an instruction so I can see which
registers it was attempting to dereference.
Oh sorry...
(kgdb) x/i 0x805bbc66
Am Fri, 15 May 2009 12:05:47 -0400
schrieb John Baldwin j...@freebsd.org:
(kgdb) x/i 0x805bbc66
0x805bbc66 rt_maskedcopy+6: movzbl (%rdx),%edx
Hmm, your %rdx is garbage. :(
rdx0xef3fdf377db53afa -1207000745686779142
That should at least be
Hi,
I've received a panic today on RELEASE 7.2 with bge(4). We have got
an apache 2.2 running that mounts an NFS share from a file server.
We have put some load on it, because we
have downloaded big files (700MB) for installation on two
workstations, about 15 of files were downloaded at the same
On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote:
Hi,
I've received a panic today on RELEASE 7.2 with bge(4). We have got
an apache 2.2 running that mounts an NFS share from a file server.
We have put some load on it, because we
have downloaded big files (700MB) for installation on
(kgdb) list *0xc07a4dac
0xc07a4dac is in devvn_refthread (/usr/src/sys/kern/kern_conf.c:209).
204 struct cdev_priv *cdp;
205
206 mtx_assert(devmtx, MA_NOTOWNED);
207 csw = NULL;
208 dev_lock();
209 *devp = vp-v_rdev;
210 if
Yesterday I updated a rock-solid machine (uptime hundreds of days) from
7-stable circa July, 2008, to the latest stable. I run Nessus on this
machine, with about 60 concurrent scans. It pushes the load average up as
high as 20 for short periods of time, but overall is reasonably efficient.
Am Thu, 14 May 2009 09:16:40 -0400
schrieb John Baldwin j...@freebsd.org:
On Thursday 14 May 2009 7:47:23 am Martin Sugioarto wrote:
[...]
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 0
fault virtual address =
On Thursday 14 May 2009 12:30:31 pm Chris Timmons wrote:
(kgdb) list *0xc07a4dac
0xc07a4dac is in devvn_refthread (/usr/src/sys/kern/kern_conf.c:209).
204 struct cdev_priv *cdp;
205
206 mtx_assert(devmtx, MA_NOTOWNED);
207 csw = NULL;
208
Can you get a stack trace? Your panic is quite different then the original
one.
Let me know if there is any other information which would be helpful. I
rebooted the 7.0 kernel from July, and the machine has been happily
chugging along running Nessus under load for almost 6 hours.
20 matches
Mail list logo
