Hello, Adam.
You wrote 1 февраля 2011 г., 21:59:31:
> Did it help the problem? I think I saw a related panic today so I'm
> going to try updating past the time this was MFC'ed to 8 which I think
> was Sat Jan 22 01:34:08 2011 UTC (10 days, 17 hours ago). Thanks.
It doesn't crash anymore, but my
On 01/20/11 03:05, Lev Serebryakov wrote:
Hello, Eugene.
You wrote 19 января 2011 г., 12:50:25:
Yes, I've missed it's PRERELEASE already.
Backtrace points to the problem in em_local_timer() fixed in CURRENT
7 days ago, take a look:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/if_em.c
Hello, Eugene.
You wrote 19 января 2011 г., 12:50:25:
> Yes, I've missed it's PRERELEASE already.
> Backtrace points to the problem in em_local_timer() fixed in CURRENT
> 7 days ago, take a look:
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/if_em.c#rev1.65
> I run my servers with this
On 19.01.2011 15:00, Lev Serebryakov wrote:
> Hello, Eugene.
> You wrote 19 января 2011 г., 11:44:01:
>
>> There is known instability in em(4) driver in 8.2-RELEASE,
>> it may panic due to some lack of NULL pointer checks.
>> You should update to RELENG_8 containting fix and retest.
> uname -v
>
Hello, Eugene.
You wrote 19 января 2011 г., 11:44:01:
> There is known instability in em(4) driver in 8.2-RELEASE,
> it may panic due to some lack of NULL pointer checks.
> You should update to RELENG_8 containting fix and retest.
uname -v
FreeBSD 8.2-PRERELEASE #5: Sat Jan 8 14:38:46 MSK 2011
On 19.01.2011 03:12, Lev Serebryakov wrote:
> Hello, Freebsd-stable.
>
>
> One of my servers crashes about once a week, with always same
> diagnostics: "kernel trap 12 with interrupts disabled" and in same
> process: "swi4: clock"
>
> It doesn
Hello, Jeremy.
You wrote 19 января 2011 г., 0:46:54:
> CC'ing Jack Vogel of Intel, as this looks like it could be something the
> em(4) driver might be tickling. I do see it in the stack trace shortly
> before the crash. In the interim, can you please provide output from the
> following command:
Hello, Eugene.
You wrote 19 января 2011 г., 0:30:09:
> You have not mentioned what tasks does it perform.
Storage of all my data with software RAID5 + torrent-box for
25Mibt/s connection/
--
// Black Lion AKA Lev Serebryakov
___
freebsd-stable@fre
On Wed, Jan 19, 2011 at 12:12:48AM +0300, Lev Serebryakov wrote:
> Hello, Freebsd-stable.
>
> One of my servers crashes about once a week, with always same
> diagnostics: "kernel trap 12 with interrupts disabled" and in same
> process: "swi4: clock"
>
>
On 19.01.2011 03:12, Lev Serebryakov wrote:
> Hello, Freebsd-stable.
>
>
> One of my servers crashes about once a week, with always same
> diagnostics: "kernel trap 12 with interrupts disabled" and in same
> process: "swi4: clock"
>
> It doesn
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
> > >
> > >
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; a
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
nd. I've got only an USB keyboard that
> would not help in this situation. It wasn't even plugged in.
>
> Btw, promiscuous mode is enabled, because ipcad is running to count
> traffic. I've got this problem the second time now.
>
>
> The panic looks like this
tw, promiscuous mode is enabled, because ipcad is running to count
traffic. I've got this problem the second time now.
The panic looks like this:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 0
fault virtual address = 0x80
Just got this panic on my amd64 smp system running stable:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x20
fault code = supervisor read, page not present
instruction pointer = 0x8
Am Mittwoch, 9. März 2005 03:04 schrieb Pierre-Luc Drouin:
> I have updated a system from FreeBSD 4.10 to 5.3 (I did a fresh new
> installation from scatch). At the same time we put a new CPUs in there.
[...]
> What could be the cause?
The non-technical answer: FreeBSD 5.4 is in the release cycle
I have updated a system from FreeBSD 4.10 to 5.3 (I did a fresh new
installation from scatch). At the same time we put a new CPUs in there.
The system is now a dual Xenon 3.2 GHZ with hyperthreading. When there's
load on the server, it crashes. Here is what I get on the console:
kernel tr
33 matches
Mail list logo
