RE: Spontan reboot of FreeBSD 4,x box

From: Don Bowman (don_at_sandvine.com)
Date: 05/28/03

  • Next message: Crist J. Clark: "Re: ipfw rules vs routes to localhost?"
    To: 'Dennis Pedersen' <mlists@daydreamer.dk>, Don Bowman <don@sandvine.com>, freebsd-net@FreeBSD.org
    Date: Wed, 28 May 2003 16:49:47 -0400
    
    

    well, I would speculate that your /etc/periodic is
    running @ 3am doing things like looking for setuid files,
    pruning /tmp, etc, which sparks up some disk activity, forks
    a few processes, walks the filesystem, etc, which is tripping some
    bug you have in the kernel, or bad memory. [i have a version
    of memtest86 which can be loaded from 'loader' and placed on
    a fbsd file system if you wish to try the bad memory theory
    conveniently].

    I have a similar problem in 4.7 that occurs once in a while
    @ 3:01am which seems to randomly corrupt memory. I've been
    chasing it for a while but is hasn't been reproducible enough
    to find.

    This is pure speculation.

    man 8 periodic
    see /etc/periodic.conf

    > -----Original Message-----
    > From: Dennis Pedersen [mailto:mlists@daydreamer.dk]
    > Sent: May 28, 2003 16:46
    > To: Don Bowman; freebsd-net@FreeBSD.org
    > Subject: Re: Spontan reboot of FreeBSD 4,x box
    >
    >
    >
    > ----- Original Message -----
    > From: "Don Bowman" <don@sandvine.com>
    > To: "'Dennis Pedersen'" <mlists@daydreamer.dk>;
    > <freebsd-net@FreeBSD.org>
    > Sent: Wednesday, May 28, 2003 3:56 PM
    > Subject: RE: Spontan reboot of FreeBSD 4,x box
    >
    >
    > > > From: Dennis Pedersen [mailto:mlists@daydreamer.dk]
    > > >
    > > > I have a couple of FreeBSD 4,4 and one 4,7 that are beeing
    > > > used as firewalls
    > > > in different locations.
    > > > Lately i haven noticed that one of the firewall's was
    > > > starting to reboot at
    > > > a certin time of the day (give or take maybe 10min).
    > >
    > > The time it resets wouldn't correlate to the periodic (e.g.
    > > 3am) would it?
    >
    > On one of the box´s that fits yeah..
    > What am i missing?
    > cron_enable is set to no in rc.conf and the cron deamon isnt running?
    >
    >
    > Regards,
    > Dennis
    >
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"


  • Next message: Crist J. Clark: "Re: ipfw rules vs routes to localhost?"

    Relevant Pages

    • Re: [PATCH 1/2] I386 fix pte clear
      ... I have also fixed the barrier to be smp_wmb as Nick pointed out. ... On> 4GB memory machines, the implementation of pte_clear for PAE was clearly ... dereferencing these bogus TLB mappings, even if the clear is followed fairly ... The processor can speculate memory operations, including memory writes, as long ...
      (Linux-Kernel)
    • [patch 19/24] x86/PAE: Fix pte_clear for the >4GB RAM case
      ... On> 4GB memory machines, the implementation of pte_clear for PAE was clearly ... dereferencing these bogus TLB mappings, even if the clear is followed fairly ... The processor can speculate memory operations, including memory writes, as long ... the fix so simple that I think fixing them immediately is justified. ...
      (Linux-Kernel)
    • Re: [PATCH 1/2] I386 fix pte clear
      ... On> 4GB memory machines, the implementation of pte_clear for PAE was clearly ... dereferencing these bogus TLB mappings, even if the clear is followed fairly ... The processor can speculate memory operations, including memory writes, as long ... the fix so simple that I think fixing them immediately is justified. ...
      (Linux-Kernel)
    • [PATCH 1/2] I386 fix pte clear
      ... Page table entries in PAE mode are 64-bits ... On> 4GB memory machines, the implementation of pte_clear for PAE was clearly ... dereferencing these bogus TLB mappings, even if the clear is followed fairly ... The processor can speculate memory operations, including memory writes, as long ...
      (Linux-Kernel)