Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Build pfSense-Full-Update-2.0-BETA4-20101109-0016.tgz seems broken

    2.0-RC Snapshot Feedback and Problems - RETIRED
    3
    8
    3.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      wallabybob
      last edited by

      I upgraded to pfSense-Full-Update-2.0-BETA4-20101109-0016.tgz from a build of early October (probably pfSense-Full-Update-2.0-BETA4-20101002-1627.tgz).  Before upgrading I made the IPv6 changes (gitsync to upgrade the GUI) and configured a tunnel for IPv6.

      With LAN and WAN both plugged in and running after completion of the upgrade I had a crash with apinger the current process. I removed the cables from the WAN and LAN interfaces and had a panic syncache: mbuf too small

      I don't know if the IPv6 related changes are a factor in the crash and panic.

      1 Reply Last reply Reply Quote 0
      • W
        wallabybob
        last edited by

        I tar'd up my production  pfSense system (version 1.2.3) and restored to the "V2", upgraded firmware to pfSense-Full-Update-2.0-BETA4-20101110-0504.tgz and restored the previous v2 config and haven't seen the panic again. I'll try the IPv6 gitsync within the next 12 hours and report on that.

        There seems to be a DNS forwarder problem with pfSense-Full-Update-2.0-BETA4-20101110-0504.tgz which I'm still looking into.

        1 Reply Last reply Reply Quote 0
        • W
          wallabybob
          last edited by

          @wallabybob:

          There seems to be a DNS forwarder problem with pfSense-Full-Update-2.0-BETA4-20101110-0504.tgz which I'm still looking into.

          rl0 interface to the DNS was "stuck" after reporting watchdog timeout many times. Removing the cable and putting it back in seemed to break it out of that state and DNS now works.

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            I have seen the mbuf too small panic but only on a dev kernel.

            Were you running a normal kernel?

            The mbuf size was increased on amd64, it may need increased on i386 as well. Ermal was waiting for more input to find out what the problem might be.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • E
              Efonnes
              last edited by

              I think I recall seeing some recent commits with changes to mbufs (not just that mbuf size parameter) and to something that uses them.  Could that have anything to do with it?

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                Yes, hence the reason that adjusting the size fixed amd64. The patches were added a week or so ago to increase performance.

                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • W
                  wallabybob
                  last edited by

                  I've seen a number of page fault panics while attempting playback gitsync. The display disappears too quickly for me to capture. When attempting to get a kernel that would pause on panic I trashed something and had to repair my system. I used a cloned 1.2.3 system, upgraded the firmware to pfSense-Full-Update-2.0-BETA4-20101109-0016.tgz and restored my previous config. I still saw the page fault panic part way through playback gitsync, during the fetch phase.

                  I've been running normal kernels but will switch to a developers kernel to attempt to capture some more information on the page fault.

                  1 Reply Last reply Reply Quote 0
                  • W
                    wallabybob
                    last edited by

                    I switched  to the developers kernel (# tar xzpf /kernels/kernel_Dev.gz -C /boot/ ) and rebooted but it didn't even complete the startup to console menu:

                    Fatal trap 12: page fault while in kernel mode
                    cpuid = 0; apic id = 00
                    fault virtual address    = 0xdedeadc8
                    fault code              = supervisor read, page not present
                    instruction pointer      = 0x20:0xc0a51ce6
                    stack pointer            = 0x28:0xc2763a88
                    frame pointer            = 0x28:0xc2763a90
                    code segment            = base 0x0, limit 0xfffff, type 0x1b
                                            = DPL 0, pres 1, def32 1, gran 1
                    processor eflags        = interrupt enabled, resume, IOPL = 0
                    current process          = 12 (irq10: rl ehci0)

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.