Jump to content

bonienl

Community Developer
  • Content Count

    7444
  • Joined

  • Last visited

  • Days Won

    42

Report Comments posted by bonienl


  1. 2 minutes ago, Daniel Valadas said:

    Let me try the MTU thing

    In general it is better to leave the default MTU of 1500.

    When working with jumbo frames (9000) you'll need to ensure that everything in your network supports that, and still it can give unwanted side effects.


  2. Looks like a MTU problem. You have set an MTU of 9000.

    Edit the "network.cfg" file in the /config folder on your flash device and change to

    MTU[0]=""

    Then reboot your system

     

    Ps. This is not really a bug, but a specific issue to your system setup. It should have been asked under general support.


  3. There are known kernel/driver issues with some but not all Marvell SATA controllers.

    @40foot

    01:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller [1b4b:9230] (rev 11)

    @Kevlar75

    02:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller [1b4b:9230] (rev 11)

    See this answer under the Unraid 6.7 announcement topic for a possible workaround

     


  4. Why don't you use a "remote" login using a browser?

     

    It is very common to run Unraid headless and use the console connection for true troubleshooting only.


  5. The calculation for CPU26 based on these two samples is correct and 100%.

     

    One big difference between CPU26 and all the other CPUs is the IOwait time

          user    nice  system  idle       iowait    irq softirq
    cpu25 784637  25697 1747440 295493912  189817    0   9588    0 0 0
    cpu26 1567648 96275 4562200 21299937   270014868 0   38855   0 0 0
    cpu27 782504  26063 1728628 295529225  183739    0   9300    0 0 0

    This implies CPU26 is waiting most of the time on disk I/O activity to finish


  6. These call traces should not happen indeed, but it is very difficult to pinpoint why they happen.

    It looks like an external event triggers these call traces, some people have no issues (like me and I have a very extensive network set up) and others do.

    Perhaps a future kernel or docker update will address this, but nothing guaranteed.


  7. Some comments and advice

    • It is not recommended to change the MAC address, usually there is no true reason to do so.
      In your case you changed the vendor string from "Asus" to "ASrock" which is misleading to say the least
    • Any manual change in the network.cfg file will get lost whenever a update via the GUI is done
      If you insist, the correct syntax is HWADDR[0]="d0:50:99:9d:0f:df" (note the index and quotes)
    • The preferred solution is to assign the existing IP address to the new MAC address in your router configuration
    • The "bug" is that the MAC address of the interface isn't set correctly when the bridge function is enabled for that interface. A made a correction for this, but still recommend to use the solution given above.
    • Priority of this is "annoyance" (easy solvable by setting your router correctly)

     


  8. 28 minutes ago, itimpi said:

    Perhaps the options reading something like:

    - update ready  (instead of ‘updated’)

    - apply update  (instead of ‘update ready’)

    would be clearer and  less likely to lead to confusion (and not take up more space)?

    Nice. :) 

    Made a update with the textual adjustment.

    • Like 3