4

There is a similar question here What is the "Current message level"?

Reference linked in the answer there doesn't mention this 0x00000033 (51) value.

Here is the complete output of ethtool:

Settings for enp5s0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Half 1000baseT/Full 
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full 
                        100baseT/Half 100baseT/Full 
                        1000baseT/Half 1000baseT/Full 
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                     100baseT/Half 100baseT/Full 
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000033 (51)
               drv probe ifdown ifup
Link detected: yes
1

2 Answers 2

2

The key phrase from the NETIF Msg Level document1 referenced by the What is the “Current message level”? question (and quoted by nelaaro’s answer to this question) is “The variable is a bit map ….”

You are asking about message level 0x00000033.  0x33 = 0x1 | 0x2 | 0x10 | 0x20, so that message level is equivalent to NETIF_MSG_DRV + NETIF_MSG_PROBE + NETIF_MSG_RX_ERR + NETIF_MSG_TX_ERR + NETIF_MSG_TX_QUEUED + NETIF_MSG_INTR.  You may be able to find details of what that means in the source code for the Linux Ethernet driver, or its documentation.

___________
1 The content of the "NETIF Msg Level" document is available in unformatted, text-only form in the Documentation/networking/netif-msg.txt file in the kernel source, and also here (which has some markup) and here.

1
  • Thanks for the answer, I understand it now. I worked with C/C++ (junior level stuff). I did not realise that it's a bit mask. May 23, 2017 at 18:54
-1

Taken from the following link http://pastebin.com/raw/WKyEQAUp


NETIF Msg Level

The design of the network interface message level setting.

History

The design of the debugging message interface was guided and constrained by backwards compatibility previous practice. It is useful to understand the history and evolution in order to understand current practice and relate it to older driver source code.

From the beginning of Linux, each network device driver has had a local integer variable that controls the debug message level. The message level ranged from 0 to 7, and monotonically increased in verbosity.

The message level was not precisely defined past level 3, but were always implemented within +-1 of the specified level. Drivers tended
to shed the more verbose level messages as they matured.
0 Minimal messages, only essential information on fatal errors.
1 Standard messages, initialization status. No run-time messages
2 Special media selection messages, generally timer-driver.
3 Interface starts and stops, including normal status messages
4 Tx and Rx frame error messages, and abnormal driver operation
5 Tx packet queue information, interrupt events.
6 Status on each completed Tx packet and received Rx packets
7 Initial contents of Tx and Rx packets

Initially this message level variable was uniquely named in each driver e.g. "lance_debug", so that a kernel symbolic debugger could locate and modify the setting. When kernel modules became common, the variables were consistently renamed to "debug" and allowed to be set as a module parameter.

This approach worked well. However there is always a demand for additional features. Over the years the following emerged as reasonable and easily implemented enhancements Using an ioctl() call to modify the level. Per-interface rather than per-driver message level setting. More selective control over the type of messages emitted.

The netif_msg recommendation adds these features with only a minor complexity and code size increase.

The recommendation is the following points Retaining the per-driver integer variable "debug" as a module parameter with a default level of '1'.

Adding a per-interface private variable named "msg_enable".  The
variable is a bit map rather than a level, and is initialized as
   1 << debug
Or more precisely
    debug < 0 ? 0 : 1 << min(sizeof(int)-1, debug)

Messages should changes from
  if (debug > 1)
       printk(MSG_DEBUG "%s: ...
to
  if (np->msg_enable & NETIF_MSG_LINK)
       printk(MSG_DEBUG "%s: ...


The set of message levels is named
  Old level   Name   Bit position
    0    NETIF_MSG_DRV      0x0001
    1    NETIF_MSG_PROBE    0x0002
    2    NETIF_MSG_LINK     0x0004
    2    NETIF_MSG_TIMER    0x0004
    3    NETIF_MSG_IFDOWN   0x0008
    3    NETIF_MSG_IFUP     0x0008
    4    NETIF_MSG_RX_ERR   0x0010
    4    NETIF_MSG_TX_ERR   0x0010
    5    NETIF_MSG_TX_QUEUED    0x0020
    5    NETIF_MSG_INTR     0x0020
    6    NETIF_MSG_TX_DONE  0x0040
    6    NETIF_MSG_RX_STATUS    0x0040
    7    NETIF_MSG_PKTDATA  0x0080

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .