This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ASG v7 always crashes within a day?

Hi guys,

I am quite frustrated with my new ASG v7.005 setup at the moment. I installed it on my new Asus Pundit P1 Barebone (the specifications are in my signature) and there is always a certain point of the day where the ASG hangs so that you cannot login via ssh or webadmin. It is totally dead and needs a hard reboot.

I cannot access web pages as well, the internet is dead to me. I have http proxy running and IPS but I think my system has enough resources to manage. No I shut down the http proxy and will see if the ASG will still run tomorrow. Does anybody have the same problem? Here is a snippet of my kernel.log from the time the ASG crashes:

2007:07:09-07:49:18 (none) kernel: CSLIP: code copyright 1989 Regents of the University of California

2007:07:09-07:49:18 (none) kernel: PPP generic driver version 2.4.2
2007:07:09-07:49:19 (none) kernel: tun: Universal TUN/TAP device driver, 1.6
2007:07:09-07:49:19 (none) kernel: tun: (C) 1999-2004 Max Krasnyansky 
2007:07:09-07:49:20 (none) kernel: MPPE/MPPC encryption/compression module registered
2007:07:09-07:49:20 (none) kernel: PPP BSD Compression module registered
2007:07:09-07:49:20 (none) kernel: PPP Deflate Compression module registered
2007:07:09-07:49:25 (none) kernel: Ebtables v2.0 registered
2007:07:09-07:49:25 (none) kernel: netfilter PSD loaded - (c) astaro AG
2007:07:09-07:49:35 (none) kernel: parport0: PC-style at 0x378 [PCSPP(,...)]
2007:07:09-07:49:35 (none) kernel: parport0: PC-style at 0x378 [PCSPP(,...)]
2007:07:09-07:49:35 (none) kernel: Device not ready. Make sure there is a disc in the drive.
2007:07:09-07:49:35 (none) kernel: Device not ready. Make sure there is a disc in the drive.
2007:07:09-07:49:39 (none) kernel: device eth0 left promiscuous mode
2007:07:09-07:49:39 (none) kernel: eth0: Promiscuous mode enabled.
2007:07:09-07:49:39 (none) kernel: device eth0 entered promiscuous mode
2007:07:09-12:07:35 (none) kernel: Bad pte = 0000a666, process = confd.plx, vm_flags = 100077, vaddr = 8803f28
2007:07:09-12:07:35 (none) kernel: [] __handle_mm_fault+0x942/0x9c0
2007:07:09-12:07:35 (none) kernel: [] work_resched+0x5/0x16
2007:07:09-12:07:35 (none) kernel: [] notifier_call_chain+0x34/0x40
2007:07:09-12:07:35 (none) kernel: [] do_page_fault+0x3b2/0x640
2007:07:09-12:07:35 (none) kernel: [] do_page_fault+0x0/0x640
2007:07:09-12:07:35 (none) kernel: [] error_code+0x4f/0x54
2007:07:09-12:07:35 (none) kernel: VM: killing process confd.plx
2007:07:09-17:54:26 (none) kernel: Netfilter messages via NETLINK v0.30.


You can see that the ASG went down at around 12:07 this morning. At 17:54 I rebootet the device. Can you see anything in this log that logs suspicious? Do you need other logfile excerpts?

Thanks in advance for your help!


This thread was automatically locked due to age.
Parents
  • Forgot to mention that also the up2date service isn't running correctly. Sometimes it works and sometimes not. Here is my version:

    Current pattern version: 3562
    Latest available pattern version: 3571

    This is the pattern I have for over a day now! And I do not have that much traffic here at home, just two Macintosh computers...
  • Radiohead, the kernel stack trace you see at 12:07 is definitely an issue, but doesn't appear to be related to the http proxy at all.

    Given that this is new hardware, I have to wonder if it is flaky and possibly is suffering from bad RAM? Did you test the hardware using memtest or similar tools before installation?

    If it's not bad RAM, it appears to be a bug in the kernel that ships with 7.005.
  • ASG ran for about 10minutes after heavy CPU load made it unusable. I have uploaded a video (6.1MB) where you can see what is going on with the top commande from cli of ASG. Weird.... But you can also see that my torrent download is at about 3.2Kbyte/s...

    Get the video here:

    http://www.jameslepthien.de/videos/astaro-high-load.mov.zip
  • RE: Hardware --- I've seen issues with those Nvidia MB Chipsets and windows before, and in Linux.  I'd ditch it for a Via chipset, or if you're considering going Intel, an Intel chipset.  I've also had good results using Serverworks chipsets.  I've also had more "wierd" issues with AMD processors than Intel, so we mostly use Intel now.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • ASG ran for about 10minutes after heavy CPU load made it unusable. I have uploaded a video (6.1MB) where you can see what is going on with the top commande from cli of ASG. Weird.... But you can also see that my torrent download is at about 3.2Kbyte/s...

    Get the video here:

    http://www.jameslepthien.de/videos/astaro-high-load.mov.zip


    amd has nothing to do with it.  the nforce chipsets are not designed for server grade loads.  Change motherboards.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • Well this is not going to be easy since it is a Asus Pundit Barebone which I bought recently and cannot give back. I do not want to spend money again on this.
  • the nforce chipsets are not designed for server grade loads.  Change motherboards.


    Why are the nforce chipsets supported by astaro then?

    http://www.astaro.com/lists/HCL-ASG-V7.txt
  • Why are the nforce chipsets supported by astaro then?

    http://www.astaro.com/lists/HCL-ASG-V7.txt

    that's because it uses the reverse engineered driver built into the Linux kernel.  I would not put a nforce based chipset into any server i want to use in a production environment.

    Le me clarify something to everyone.  I don't have a problem with reverse engineered drivers at all.  The nforce chipset is not a good chipset in terms of stability under heavy loads.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • Yeah, that is what I see right now. Actually I have the same problem as shown in the video right now again. What I realised is that the clock on the system now jumped up 2 hours and up again in the matter of seconds....

    See this:

    voldemort:/var/log # date
    Sat Jul 14 19:23:06 CEST 2007
    voldemort:/var/log # date
    Sat Jul 14 21:08:13 CEST 2007
    voldemort:/var/log # date
    Sat Jul 14 21:27:09 CEST 2007
    voldemort:/var/log # date
    Sat Jul 14 21:28:39 CEST 2007
    voldemort:/var/log # date
    Sat Jul 14 21:29:30 CEST 2007
    voldemort:/var/log # date
    Sat Jul 14 21:32:29 CEST 2007
    voldemort:/var/log # 


    I enetered the date commands right behind one another. In a matter of seconds....
  • I have not had good experiences with the Nvidia (N-Force) chipsets with Windows, etc... I'd change to something more mainstream.  Nvidia is good at video chipsets, they should've stuck to that in this case.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • Frankly, I have had reliability issues in certain cases under high DMA with certain Via chipsets as well, so might as well throw those into the "do not use for server class workloads".

    There are a LOT of people using Nvidia chipsets on Linux systems without issues, yes, even under high loads. Just have a look at the Fedora stats project. The #2 most popular IDE chipset is nVidia with 29k systems. #1 is Intel at 52k and #3 is Via with 12.5k. I know for a fact that there are TONs of people running nVidia chipsets on MythTV systems which spend a lot of time pushing a lot of data around.

    With IPS and the http proxy disabled, there really shouldn't be any significant load put on a machine as fast as Radioheads. All it's doing is pushing packets. A paltry single CPU 1GHz machine is probably overkill, even with just 512MB of RAM. Certainly even machines speced lower than that used to work just fine in v6, nevermind a dual-core with 1GB of ram.

    It certainly appears that there is a kernel bug which is triggered by this particular Nvidia system, but given how many other people are seeing system lockups in v7 on all sorts of hardware, I'm more inclined to think that there are real serious bugs in the kernel that Astaro ships.

    The time jumping around problem is an old bug related to the interaction of the kernel and ntp daemon. Someone else brought that up the other day.

    The extremely high load average shown in the video he took indicates that there are some processes getting hung on something. Getting the full process list would be helpful. BTW, is the video shown in real time? The speed at which top is updating is highly unusual and appears as if it is being played back fast forwarded. It would be much more informative if top was set to update once a second.
  •  BTW, is the video shown in real time? The speed at which top is updating is highly unusual and appears as if it is being played back fast forwarded. It would be much more informative if top was set to update once a second.


    Yes, that is what I meant when I said weird [[;)]]

    The video is in realtime. I guess I'll wait till we reach version 7.1 of the ASG. Right now I will back away from ASG and will use my OpenBSD box again. Thanks for your help and support but I want a stable solution for my home environment, since I have to do enough at work and I want to have some time for other things at home [[;)]]
Reply
  •  BTW, is the video shown in real time? The speed at which top is updating is highly unusual and appears as if it is being played back fast forwarded. It would be much more informative if top was set to update once a second.


    Yes, that is what I meant when I said weird [[;)]]

    The video is in realtime. I guess I'll wait till we reach version 7.1 of the ASG. Right now I will back away from ASG and will use my OpenBSD box again. Thanks for your help and support but I want a stable solution for my home environment, since I have to do enough at work and I want to have some time for other things at home [[;)]]
Children
  • Yeah, that's totally weird. Was that with booting with acpi=off and noapic?

    Only other thing I can think of now is to try v6, but not sure if it will run on your hardware or not.
  • Yeah, that's totally weird. Was that with booting with acpi=off and noapic?

    Only other thing I can think of now is to try v6, but not sure if it will run on your hardware or not.


    Yes, I booted with these kernel parameters... Tried to boot V6 but then it came to the point where it said that my HDD has not enough space and the installation stopped before it began...