[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


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.


 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

 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: ...
      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


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.


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.


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.


This level is for timer-based media selection and operation watchdog
messages.  This information is usually useful only for debugging.


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.


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.


This message levels enables emitting a message for packet queued for transmit.


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


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.


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.


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