Am Fri, 15 May 2009 12:05:47 -0400
schrieb John Baldwin :
> On Friday 15 May 2009 11:38:00 am Martin wrote:
> > Am Fri, 15 May 2009 11:09:20 -0400
> > schrieb John Baldwin :
> >
> > > x/i please. The /i decodes it as an instruction so I can see
> > > which registers it was attempting to derefere
Am Fri, 15 May 2009 12:05:47 -0400
schrieb John Baldwin :
> > (kgdb) x/i 0x805bbc66
> > 0x805bbc66 : movzbl (%rdx),%edx
>
> Hmm, your %rdx is garbage. :(
>
> rdx0xef3fdf377db53afa -1207000745686779142
>
> That should at least be
>
>0x
On Friday 15 May 2009 11:38:00 am Martin wrote:
> Am Fri, 15 May 2009 11:09:20 -0400
> schrieb John Baldwin :
>
> > 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
> 0x80
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: 4
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 rtrequ
Am Fri, 15 May 2009 11:09:20 -0400
schrieb John Baldwin :
> 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 : movzbl (%rdx),%edx
--
Martin
___
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 th
On Friday 15 May 2009 10:57:27 am Martin wrote:
> Am Fri, 15 May 2009 08:15:19 -0400
> schrieb John Baldwin :
>
> 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
> > >
Am Fri, 15 May 2009 08:15:19 -0400
schrieb John Baldwin :
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 'x/i 0xfff
On Thursday 14 May 2009 1:10:26 pm Martin wrote:
> Am Thu, 14 May 2009 09:16:40 -0400
> schrieb John Baldwin :
>
> > 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
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
>
#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 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 ha
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.
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 de
Am Thu, 14 May 2009 09:16:40 -0400
schrieb John Baldwin :
> 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 = 0x8
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.
(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
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 installati
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 t
20 matches
Mail list logo
