[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1355239011.2694.24.camel@thor>
Date: Tue, 11 Dec 2012 10:16:51 -0500
From: Peter Hurley <peter@...leysoftware.com>
To: Neil Horman <nhorman@...driver.com>
Cc: Cong Wang <xiyou.wangcong@...il.com>, netdev@...r.kernel.org
Subject: Re: netconsole fun
On Tue, 2012-12-11 at 09:30 -0500, Neil Horman wrote:
> On Tue, Dec 11, 2012 at 09:19:52AM -0500, Peter Hurley wrote:
> > On Tue, 2012-12-11 at 04:51 +0000, Cong Wang wrote:
> > > On Mon, 10 Dec 2012 at 14:17 GMT, Peter Hurley <peter@...leysoftware.com> wrote:
> > > > Now that netpoll has been disabled for slaved devices, is there a
> > > > recommended method of running netconsole on a machine that has a slaved
> > > > device?
> > > >
> > >
> > > Yes, running it on the master device instead.
> >
> > Thanks for the suggestion, but:
> >
> > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@....168.10.99/br0,30000@....168.10.100/xx:xx:xx:xx:xx:xx
> > ...
> > [ 5.289869] netpoll: netconsole: local port 6665
> > [ 5.289885] netpoll: netconsole: local IP 192.168.10.99
> > [ 5.289892] netpoll: netconsole: interface 'br0'
> > [ 5.289898] netpoll: netconsole: remote port 30000
> > [ 5.289907] netpoll: netconsole: remote IP 192.168.10.100
> > [ 5.289914] netpoll: netconsole: remote ethernet address xx:xx:xx:xx:xx:xx
> > [ 5.289922] netpoll: netconsole: br0 doesn't exist, aborting
> > [ 5.289929] netconsole: cleaning up
> > ...
> > [ 9.392291] Bridge firewalling registered
> > [ 9.396805] device eth1 entered promiscuous mode
> > [ 9.418350] eth1: setting full-duplex.
> > [ 9.421268] br0: port 1(eth1) entered forwarding state
> > [ 9.423354] br0: port 1(eth1) entered forwarding state
> >
> >
> > Is there a way to control or associate network device names prior to
> > udev renaming?
> >
> That looks like a systemd problem (or more specifically a boot dependency
> problem). You need to modify your netconsole unit/service file to start after
> all your networking is up. NetworkManager provides a dummy service file for
> this purpose, called networkmanager-wait-online.service
Ok. So with a single physical network interface that will be bridged,
netconsole cannot used for kernel boot messages.
With a machine with multiple nics, is there a way to control device
naming so that the interface name to be used by netconsole specified on
the boot command line will actually corresponding to the intended
device. For example,
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@....168.1.123/eth0,30000@....168.1.139/xx:xx:xx:xx:xx:xx
....
[ 4.092184] 3c59x: Donald Becker and others.
[ 4.092204] 0000:07:05.0: 3Com PCI 3c905C Tornado at ffffc9000186cf80.
[ 4.094035] tg3.c:v3.125 (September 26, 2012)
....
[ 4.125038] tg3 0000:08:00.0 eth1: Tigon3 [partno(BCM95754) rev b002] (PCI Express) MAC address xx:xx:xx:xx:xx:xx
[ 4.125055] tg3 0000:08:00.0 eth1: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 4.125062] tg3 0000:08:00.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[ 4.125068] tg3 0000:08:00.0 eth1: dma_rwctrl[76180000] dma_mask[64-bit]
This is attaching netconsole to the wrong device because bus
enumeration, and therefore load order, is not consistent from boot to
boot.
[ 3.840306] tg3.c:v3.127 (November 14, 2012)
[ 3.873390] tg3 0000:08:00.0 eth0: Tigon3 [partno(BCM95754) rev b002] (PCI Express) MAC address xx:xx:xx:xx:xx:xx
[ 3.873406] tg3 0000:08:00.0 eth0: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 3.873413] tg3 0000:08:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[ 3.873424] tg3 0000:08:00.0 eth0: dma_rwctrl[76180000] dma_mask[64-bit]
...
[ 3.884239] 3c59x: Donald Becker and others.
[ 3.884263] 0000:07:05.0: 3Com PCI 3c905C Tornado at ffffc9000187cf80.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists