Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 57 replies
  • Subscribers 2 subscribers
  • Views 15131 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.
Parents
  • 0
    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...
  • 0 in reply to Radiohead-79
    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.
  • 0 in reply to drees

    We already know that BitTorrent will do a number on the IPS software.


    Tonight the ASG hang again. But without IPS or HTTP Proxu enabled. I have to investigate further whether my roommate turned on his Azureus client or not...

    I'll check the logs.
  • 0 in reply to Radiohead-79
    Hi guys,

    there was no bittorrent running at this time. Here is an excerpt of my kernel.log from the crash time [;)] 

    2007:07:11-19:45:02 (none) kernel: kernel BUG at mm/rmap.c:560!

    2007:07:11-19:45:02 (none) kernel: invalid opcode: 0000 [#1]

    2007:07:11-19:45:02 (none) kernel: SMP 

    2007:07:11-19:45:02 (none) kernel: Modules linked in: nfnetlink_queue xt_condition iptable_ips ip_nat_ftp ip_conntrack_ftp ipt_MASQUERADE ipt_REDIRECT iptable_nat edd sr_mod ide_cd cdrom parpo

    rt_pc parport ppp_deflate zlib_deflate bsd_comp sha1 arc4 ppp_mppe ppp_async crc_ccitt ppp_generic slhc ipt_hashlimit xt_limit xt_conntrack ipt_esp xt_tcpudp ipt_psd ipt_addrtype ip_nat_mms ip

    _nat_pptp ip_nat_irc ebtable_nat ebtables iptable_mangle ip_conntrack_mms ip_conntrack_pptp ip_conntrack_irc tun crypto_null blowfish cast5 serpent twofish ipsec af_packet ipt_logmark ipt_CONF

    IRMED ipt_confirmed ipt_owner ipt_REJECT usb_storage evdev ehci_hcd uhci_hcd ohci_hcd xt_state xt_NOTRACK iptable_raw iptable_filter ip_conntrack_netlink ip_nat ipt_LOG ip_conntrack ip_tables 

    x_tables nfnetlink_log nfnetlink 3c59x mii forcedeth capability commoncap loop sg sata_nv libata sd_mod scsi_mod

    2007:07:11-19:45:02 (none) kernel: CPU:    1

    2007:07:11-19:45:02 (none) kernel: EIP:    0060:[]    Not tainted VLI

    2007:07:11-19:45:02 (none) kernel: EFLAGS: 00010286   (2.6.16.43-46-smp #1) 

    2007:07:11-19:45:02 (none) kernel: EIP is at page_remove_rmap+0x9e/0xb0

    2007:07:11-19:45:02 (none) kernel: eax: ffffffff   ebx: c1648020   ecx: 00000000   edx: 00000292

    2007:07:11-19:45:02 (none) kernel: esi: c1648020   edi: 082d6000   ebp: 00000020   esp: e2791d94

    2007:07:11-19:45:02 (none) kernel: ds: 007b   es: 007b   ss: 0068

    2007:07:11-19:45:02 (none) kernel: Process confd.plx (pid: 17645, threadinfo=e2790000 task=ed349550)

    2007:07:11-19:45:02 (none) kernel: Stack: c03329bd f2b9ff2c d8adfb58 c014b417 c1648020 082d6000 32401065 00000000 

    2007:07:11-19:45:02 (none) kernel: 00000001 08400000 de0a6080 f7c5cc80 c17cc940 fffffe68 ffffffff c1315bec 

    2007:07:11-19:45:02 (none) kernel: de0a6080 08e07fff 0018cfe4 08e08000 00000000 e2791e18 dbf78284 f7c5cc80 

    2007:07:11-19:45:02 (none) kernel: Call Trace:

    2007:07:11-19:45:02 (none) kernel: [] unmap_vmas+0x2a7/0x5a0

    2007:07:11-19:45:02 (none) kernel: [] exit_mmap+0x8f/0x120

    2007:07:11-19:45:02 (none) kernel: [] mmput+0x38/0xb0

    2007:07:11-19:45:02 (none) kernel: [] exit_mm+0xa8/0x140

    2007:07:11-19:45:02 (none) kernel: [] do_exit+0xd3/0x840

    2007:07:11-19:45:02 (none) kernel: [] __sigqueue_free+0x37/0x40

    2007:07:11-19:45:02 (none) kernel: [] do_group_exit+0x3c/0xa0

    2007:07:11-19:45:02 (none) kernel: [] get_signal_to_deliver+0x25f/0x4b0

    2007:07:11-19:45:02 (none) kernel: [] do_page_fault+0x0/0x640

    2007:07:11-19:45:02 (none) kernel: [] do_notify_resume+0xa7/0x730

    2007:07:11-19:45:02 (none) kernel: [] notifier_call_chain+0x34/0x40

    2007:07:11-19:45:02 (none) kernel: [] do_page_fault+0x10e/0x640

    2007:07:11-19:45:02 (none) kernel: [] do_page_fault+0x0/0x640

    2007:07:11-19:45:02 (none) kernel: [] work_notifysig+0x13/0x19

    2007:07:11-19:45:02 (none) kernel: Code: 24 a6 29 33 c0 83 c0 01 89 44 24 04 e8 fc bb fc ff 8b 43 10 c7 04 24 bd 29 33 c0 89 44 24 04 e8 e9 bb fc ff eb 83 8b 53 0c eb d0  0b 30 02 84 29 33

     c0 e9 79 ff ff ff 90 8d 74 26 00 83 ec 2c 

    2007:07:11-19:45:02 (none) kernel: Fixing recursive fault but reboot is needed!

    2007:07:11-19:45:03 (none) kernel: scheduling while atomic: confd.plx/0x00000001/17645

    2007:07:11-19:45:03 (none) kernel: [] schedule+0xa93/0xdd0

    2007:07:11-19:45:03 (none) kernel: [] net_rx_action+0x76/0x120

    2007:07:11-19:45:03 (none) kernel: [] apic_timer_interrupt+0x1c/0x24

    2007:07:11-19:45:03 (none) kernel: [] do_invalid_op+0xab/0xc0

    2007:07:11-19:45:03 (none) kernel: [] release_console_sem+0x1fb/0x210

    2007:07:11-19:45:03 (none) kernel: [] vprintk+0x28b/0x330

    2007:07:11-19:45:03 (none) kernel: [] release_pages+0x11f/0x190

    2007:07:11-19:45:03 (none) kernel: [] error_code+0x4f/0x54

    2007:07:11-19:45:03 (none) kernel: [] unmap_vmas+0x2a7/0x5a0

    2007:07:11-19:45:03 (none) kernel: [] exit_mmap+0x8f/0x120

    2007:07:11-19:45:03 (none) kernel: [] mmput+0x38/0xb0

    2007:07:11-19:45:03 (none) kernel: [] exit_mm+0xa8/0x140

    2007:07:11-19:45:03 (none) kernel: []  [] __sigqueue_free+0x37/0x40

    2007:07:11-19:45:03 (none) kernel: [] do_group_exit+0x3c/0xa0

    2007:07:11-19:45:03 (none) kernel: []  [] do_page_fault+0x0/0x640

    2007:07:11-19:45:03 (none) kernel: [] do_notify_resume+0xa7/0x730

    2007:07:11-19:45:03 (none) kernel: [] notifier_call_chain+0x34/0x40

    2007:07:11-19:45:03 (none) kernel: [] do_page_fault+0x0/0x640

    2007:07:11-19:45:03 (none) kernel: [] work_notifysig+0x13/0x19
  • 0 in reply to Radiohead-79
    I also changed my internal NIC now to a 3com since I read that the onboard nforce NIC is not really supported because the driver was heavily reverse engineered...
  • 0 in reply to Radiohead-79
    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?
  • 0 in reply to drees
    I'm willing to bet it's the nforce chipset causing his issues.  Hopefully the noapic works..

    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 drees

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


    How can I add this line permanently? When booting by editing the grub.conf? Will this last after a new reboot?
  • 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.
Reply
  • 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.
Children
  • 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.
  • 0 in reply to William Warren
    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
  • 0 in reply to Radiohead-79
    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

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

Cookie Information Banner