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

    My Network Card is continuse go down…..

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    15 Posts 6 Posters 4.2k Views
    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.
    • dotdashD
      dotdash
      last edited by

      I had a similar issue with some on-board fxp interfaces. I found manually setting them for 100/full-duplex made them stable. It's worth a shot.

      1 Reply Last reply Reply Quote 0
      • A
        averykao
        last edited by

        @dotdash:

        I had a similar issue with some on-board fxp interfaces. I found manually setting them for 100/full-duplex made them stable. It's worth a shot.

        ok  ,  i will try it later..

        but now , i turn off webConfigurator  Protocol (https) , to use http at pfsense…
        then the cpu loading is down....then the NIC is not going down anymore.....

        why ?

        1 Reply Last reply Reply Quote 0
        • C
          cmb
          last edited by

          It's the opposite, the NIC isn't flapping, so the CPU usage goes down. It has nothing to do with whether you're using HTTP or HTTPS, that's a trivial difference in CPU.

          1 Reply Last reply Reply Quote 0
          • A
            averykao
            last edited by

            @cmb:

            It's the opposite, the NIC isn't flapping, so the CPU usage goes down. It has nothing to do with whether you're using HTTP or HTTPS, that's a trivial difference in CPU.

            I really don't know.. but why the process```
            and [check_reload_status] is continuse high loading....

            ======================================
            PID USERNAME PRI NICE  SIZE    RES STATE    TIME  WCPU COMMAND
              259 root    131  20  3352K  1176K RUN    65:50 66.06% check_reload_status
            33519 root      76  20 82736K 29528K nanslp  0:01 56.79% php

            1 Reply Last reply Reply Quote 0
            • A
              averykao
              last edited by

              @cmb:

              It's the opposite, the NIC isn't flapping, so the CPU usage goes down. It has nothing to do with whether you're using HTTP or HTTPS, that's a trivial difference in CPU.

              soory .. cmb

              what resion would cause the NIC flapping ?

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                Figure out why you're cycling link, what are you plugged into, is there a cabling issue, NIC issue, something else going on there?

                check_reload_status and PHP have to do many things when link status changes. When it changes non-stop they have to do a lot of things non-stop, using a lot of CPU in the process.

                1 Reply Last reply Reply Quote 0
                • A
                  averykao
                  last edited by

                  @cmb:

                  Figure out why you're cycling link, what are you plugged into, is there a cabling issue, NIC issue, something else going on there?

                  check_reload_status and PHP have to do many things when link status changes. When it changes non-stop they have to do a lot of things non-stop, using a lot of CPU in the process.

                  thanks a lot for cmb 
                  I will try to find out the cycling link

                  1 Reply Last reply Reply Quote 0
                  • M
                    maverick_slo
                    last edited by

                    This is a driver issue.
                    Merge all posts from last 2 weeks and you will clearly see that:
                    a) Cables are OK
                    b) NICs are OK
                    c) Switches are OK
                    d) On some installs like mine there was no change other than pfsense snapshot update…

                    Regards,
                    Greg

                    1 Reply Last reply Reply Quote 0
                    • A
                      averykao
                      last edited by

                      @maverick_slo:

                      This is a driver issue.
                      Merge all posts from last 2 weeks and you will clearly see that:
                      a) Cables are OK
                      b) NICs are OK
                      c) Switches are OK
                      d) On some installs like mine there was no change other than pfsense snapshot update…

                      Regards,
                      Greg

                      Thanks a lot fot Greg ….

                      last few days , I check the cables , NIC , Switches . It is really found nothing wrong . And the problem would happen at when I upgrape the kernel.
                      So , I think , It is driver issue , really ! 
                      Thanks~

                      1 Reply Last reply Reply Quote 0
                      • A
                        algowlight
                        last edited by

                        I had the same problem off and on over this past week. I checked everything I could think of then I called my ISP, we ran a series of test and determined it was a bad NIC. I replaced the NIC and haven't had any problems since. Sometimes it's just a simple hardware problem.

                        http://www.speedtest.net/result/2687996289.png

                        1 Reply Last reply Reply Quote 0
                        • M
                          maverick_slo
                          last edited by

                          Yes, but this is different case…
                          There are a lot of reports lately about FXP NICs and not all of them have bad hardware...
                          For bad HW I don`t need to call ISP, I can determine that by myself...

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