[vortex] 3c575 support broken
Donald Becker
becker@scyld.com
Thu Nov 22 10:56:03 2001
On Wed, 21 Nov 2001 ruben@nutz.nl wrote:
> On Wed, Nov 21, 2001 at 10:56:24AM -0500, Donald Becker wrote:
>
> > This was an ill-advised effort. The network drivers are pretty good
> > about minimizing the messages. Compare to the many lines of e.g. IRQ
> > mapping information.
>
> No easy way to implement some parameter to silence the messages?
Yes, set the debug level to '0' instead of the default '1'. But the
network driver from my drivers are minimal at '1' (with the exception of
the eepro100 self-test output).
> I boot as
> less as possible, but would like a quiet boot on some systems (like my
> workstation) and a noisy one on others (failed servers that get
> reanimated). Some mechanism line 'touch /etc/shutup.wile.you.boot' would be
> perfect.
That won't work with many built-in drivers. Some of my drivers set
debug from the low bits of the fourth "LILO" parameter, but almost all
systems now use modules so that has been dropped in the PCI drivers.
Here is more detail that you could want about the new message level
definition.
________________
NETIF Msg Level
Written by Donald Becker, 2001.
Contact becker@scyld.com before publishing this working draft.
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 New Bit position
0 NETIF_MSG_DRV 0x0001
1 NETIF_MSG_PROBE 0x0002
2 NETIF_MSG_LINK 0x0004
2 NETIF_MSG_TIMER 0x0008
3 NETIF_MSG_IFDOWN 0x0010
3 NETIF_MSG_IFUP 0x0020
4 NETIF_MSG_RX_ERR 0x0040
4 NETIF_MSG_TX_ERR 0x0080
5 NETIF_MSG_TX_QUEUED 0x0100
5 NETIF_MSG_INTR 0x0200
6 NETIF_MSG_TX_DONE 0x0400
6 NETIF_MSG_RX_STATUS 0x0800
7 NETIF_MSG_PKTDATA 0x1000
The intent of the message levels are as follows
NETIF_MSG_DRV
This level is for overall driver messages, such as identity, version and
copyright information. The default message level should always emit
this information. A driver should unconditionally emit the driver name
and version information before any device probing is done.
With drivers released under the GPL it may be a license violation to
configure the message level with the intent to obscure the origin or
license status of the driver.
This is only message level that should deviate from the standard message
format of
"%s: Message.\n", netdev->name
since there is no specific interface name.
NETIF_MSG_PROBE
This level is for messages that name the network interface and identify
the basic hardware and configuration. For most physical devices this
includes a device address (which may be a bus position e.g. with USB)
and related information such as IRQ. Devices with station addresses
should emit the station address as soon as it is known.
In the special case that a device is detected but is unusable, and thus
no interface name is assigned, the standard message format may be ignored.
One-time messages about static link or media selection, including
media overrides such as user-forced full duplex, should be emitted at
this level.
NETIF_MSG_LINK
This level is for messages related to initial link status, link status
changes, and dynamic media selection.
Development discussion: There should be finer control over reporting the
initial link status and media selection process. The initial messages
about which media type is selected are usually very useful. Messages
about link status changes may be useful, but a user might disabled them
for a laptop that is frequently disconnected. Messages about searching
for valid transceiver are frequently useless.
NETIF_MSG_TIMER
This level is for timer-based media selection and operation watchdog
messages. This information is usually useful only for debugging.
NETIF_MSG_IFDOWN
NETIF_MSG_IFUP
These message levels are for noting the status when starting or stopping
an interface. Typical information emitted is status register values.
NETIF_MSG_IFDOWN may be used to show the state of ring buffers and
unique statistic counters.
Development discussion: IFDOWN and IFUP are mostly similar.
NETIF_MSG_RX_ERR
NETIF_MSG_TX_ERR
These message levels enable emitting a message for each receive or
transmit error. This is useful for tracking down intermittent errors,
but may result in overwhelming system message load when Things Go Wrong.
NETIF_MSG_TX_QUEUED
This message levels enables emitting a message for packet queued for transmit.
NETIF_MSG_INTR 0x0200
This message level enables emitting a message for each interrupt. The
message should include the interrupt status register value. Most
drivers will emit a message for each pass through the event dispatch
loop.
NETIF_MSG_TX_DONE
This message level enables emitting a message for each transmit complete
event. The final transmit status, if meaningful, should be printed.
It is acceptable for a driver to not emit Tx failure status messages.
Both TX_DONE and TX_ERR should be set to log all transmit attempts.
NETIF_MSG_RX_STATUS
This message level enables emitting a status message for each receive
complete event. Most hardware silently drops Rx packets with errors,
thus the semantics differ slightly from Tx.
NETIF_MSG_PKTDATA
This message level enables printing the contents of received packets.
This information is usually useful only for initial driver debugging.
Most drivers will ignore this setting. Those that implement it will
usually only emit the initial address and protocol information.
Development note: There is no message level for interesting operational
events such as
increasing the Tx FIFO threshold,
decreasing the size of a Rx ring due to an allocation failure
Transmit timeout
Transmitter unexpectedly failing
System error, such as a PCI Bus error.
Changing the multicast filter, or switching filter modes
Handling power events.
Unregistering an interface
Detecting an unexpected device ejection/detach.
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993