mirror of
https://github.com/FEX-Emu/linux.git
synced 2024-12-18 15:09:53 +00:00
8d4ef88b5d
Based upon initial work by Keiichi Kii <k-keiichi@bx.jp.nec.com>. Add some useful general-purpose tips. Also suggest solution for the frequent problem of console loglevel set too low numerically (i.e. for high priority messages only) on the sender. Signed-off-by: Satyam Sharma <satyam@infradead.org> Acked-by: Keiichi Kii <k-keiichi@bx.jp.nec.com> Acked-by: Matt Mackall <mpm@selenic.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
83 lines
3.3 KiB
Plaintext
83 lines
3.3 KiB
Plaintext
|
|
started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
|
|
2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
|
|
|
|
Please send bug reports to Matt Mackall <mpm@selenic.com>
|
|
|
|
This module logs kernel printk messages over UDP allowing debugging of
|
|
problem where disk logging fails and serial consoles are impractical.
|
|
|
|
It can be used either built-in or as a module. As a built-in,
|
|
netconsole initializes immediately after NIC cards and will bring up
|
|
the specified interface as soon as possible. While this doesn't allow
|
|
capture of early kernel panics, it does capture most of the boot
|
|
process.
|
|
|
|
It takes a string configuration parameter "netconsole" in the
|
|
following format:
|
|
|
|
netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
|
|
|
|
where
|
|
src-port source for UDP packets (defaults to 6665)
|
|
src-ip source IP to use (interface address)
|
|
dev network interface (eth0)
|
|
tgt-port port for logging agent (6666)
|
|
tgt-ip IP address for logging agent
|
|
tgt-macaddr ethernet MAC address for logging agent (broadcast)
|
|
|
|
Examples:
|
|
|
|
linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
|
|
|
|
or
|
|
|
|
insmod netconsole netconsole=@/,@10.0.0.2/
|
|
|
|
Built-in netconsole starts immediately after the TCP stack is
|
|
initialized and attempts to bring up the supplied dev at the supplied
|
|
address.
|
|
|
|
The remote host can run either 'netcat -u -l -p <port>' or syslogd.
|
|
|
|
WARNING: the default target ethernet setting uses the broadcast
|
|
ethernet address to send packets, which can cause increased load on
|
|
other systems on the same ethernet segment.
|
|
|
|
TIP: some LAN switches may be configured to suppress ethernet broadcasts
|
|
so it is advised to explicitly specify the remote agents' MAC addresses
|
|
from the config parameters passed to netconsole.
|
|
|
|
TIP: to find out the MAC address of, say, 10.0.0.2, you may try using:
|
|
|
|
ping -c 1 10.0.0.2 ; /sbin/arp -n | grep 10.0.0.2
|
|
|
|
TIP: in case the remote logging agent is on a separate LAN subnet than
|
|
the sender, it is suggested to try specifying the MAC address of the
|
|
default gateway (you may use /sbin/route -n to find it out) as the
|
|
remote MAC address instead.
|
|
|
|
NOTE: the network device (eth1 in the above case) can run any kind
|
|
of other network traffic, netconsole is not intrusive. Netconsole
|
|
might cause slight delays in other traffic if the volume of kernel
|
|
messages is high, but should have no other impact.
|
|
|
|
NOTE: if you find that the remote logging agent is not receiving or
|
|
printing all messages from the sender, it is likely that you have set
|
|
the "console_loglevel" parameter (on the sender) to only send high
|
|
priority messages to the console. You can change this at runtime using:
|
|
|
|
dmesg -n 8
|
|
|
|
or by specifying "debug" on the kernel command line at boot, to send
|
|
all kernel messages to the console. A specific value for this parameter
|
|
can also be set using the "loglevel" kernel boot option. See the
|
|
dmesg(8) man page and Documentation/kernel-parameters.txt for details.
|
|
|
|
Netconsole was designed to be as instantaneous as possible, to
|
|
enable the logging of even the most critical kernel bugs. It works
|
|
from IRQ contexts as well, and does not enable interrupts while
|
|
sending packets. Due to these unique needs, configuration cannot
|
|
be more automatic, and some fundamental limitations will remain:
|
|
only IP networks, UDP packets and ethernet devices are supported.
|