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.3k 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 Offline
      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 Offline
        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 Offline
          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 Offline
            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 Offline
              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 Offline
                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 Offline
                  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 Offline
                    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 Offline
                      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 Offline
                        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 Offline
                          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.