Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 57 replies
  • Subscribers 2 subscribers
  • Views 15134 views
  • Users 0 members are here
Options
Suggested
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?

Radiohead-79
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.
  • 0 in reply to drees
    There is nothing wrong with a reverse engineered driver, but your computer is obviously suffering from some sort of kernel issue.

    Given that your most recent kernel bug is completely different than the original, I really have to suspect some sort of hardware issue or low level kernel/hardware issue.

    Can you try booting with the grub options "acpi=off noapic" and see if that helps?


    I just remounted my /boot partition rw and changed the menu.lst so that I now have acpi=off noapic as a boot parameter. I hope that will help.

    I think you are right about the hardware thing cause now I do not have any proxies enabled. I just use the packetfilter and vpn. Here is my lspci output:

    00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
    00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
    00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
    00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
    00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
    00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
    00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
    00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
    00:05.0 VGA compatible controller: nVidia Corporation C51PV [GeForce 6150] (rev a2)
    00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
    00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
    00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
    00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
    00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
    00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
    00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1)
    00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1)
    00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
    00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
    00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
    00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
    00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
    00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
    01:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev c0)
    01:09.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)
    01:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)


    Is this hardware known to make trouble? What is also making me curious is that I turned off my box at around 1800 and when I look into the logfiles after the ASG is up again I see that while the machine is booting the timestamps are wrong. They say something like 2000 and when the machine finishes booting the logfiles get the right time stamp again...
  • 0 in reply to Radiohead-79
    I just remounted my /boot partition rw and changed the menu.lst so that I now have acpi=off noapic as a boot parameter. I hope that will help.

    We shall see. I regularly read the Astaro boards and you are the only one reporting random kernel panics like the one you posted, but not the only one reporting frequent machine lockups.
    I think you are right about the hardware thing cause now I do not have any proxies enabled. I just use the packetfilter and vpn. Here is my lspci output:

    Is this hardware known to make trouble?.

    Problems seem to be hit or miss. It doesn't help that Astaro's kernel is based off a fairly old kernel, many fixes may have gone into recent kernels to help stabilize or fix bugs with certain hardware setups, but I have not searched for specific issues with nvidia related kernel bugs.
    What is also making me curious is that I turned off my box at around 1800 and when I look into the logfiles after the ASG is up again I see that while the machine is booting the timestamps are wrong. They say something like 2000 and when the machine finishes booting the logfiles get the right time stamp again...

    That issue is likely unrelated to the others. When you turned off the box, did you just power it off or did you shut it down nicely through the admin interface? When shutting down cleanly, the system should sync the system time to the BIOS time.

    What you also should check is if the BIOS on your box is the latest one. Many times system instability issues are fixed by BIOS updates.
  • 0 in reply to Radiohead-79
    More googling (try "site:lkml.org kernel BUG mm/rmap") turns up a good number of kernel stack traces like the one in post #27.

    Most don't seem to turn up any solution. Some seem to point fingers at Nvidia hardware. 1 seems to point fingers at Suse kernels (which Astaro uses as a base). Some seem to point at flaky hardware.

    You may want to also try a mprime CPU torture test to rule out issues with the CPU. You mentioned that you only ran memtest through 2 passes? If you can run it at least 8 hours that would further help ensure that memory isn't the issue.
  • 0 in reply to drees
    Hey drees thank you for your great support. I now did update my asus bios to the latest version and am now running a memtest again and will let it run till morning which is about 10 hours now. Hopefully everything will be okay then.

    Tomorrow I will then turn on the ASG again and then I will test it through the weekend.
  • 0 in reply to Radiohead-79
    Okay. The memtest ran for about 8 and a half hours without any errors. (20 passes) I will now use www.stresslinux.org in order to check my system with heavy load. Will tell you what happens....
  • 0 in reply to Radiohead-79
    Okay. Stresslinux has got problems booting (runs into kernel panic) because of the Athlon64. Seems to be a known problem. Well, then I'll turn on the ASG again and see what the bios update has done. Downloading some Linux images right now via torrent. I'll have a look after work and tell you what's up.
  • 0 in reply to Radiohead-79
    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
  • 0 in reply to Radiohead-79
    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.

  • 0 in reply to Radiohead-79
    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

  • 0 in reply to William Warren
    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.
Cookie Information Banner