[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151217171057.6c0d3b35@xeon-e3>
Date: Thu, 17 Dec 2015 17:10:57 -0800
From: Stephen Hemminger <stephen@...workplumber.org>
To: Calvin Owens <calvinowens@...com>
Cc: <davem@...emloft.net>, <shm@...ulusnetworks.com>,
<izumi.taku@...fujitsu.com>, <linville@...driver.com>,
<dsa@...ulusnetworks.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <kernel-team@...com>
Subject: Re: [PATCH] netconsole: Initialize after all core networking
drivers
On Thu, 17 Dec 2015 15:52:39 -0800
Calvin Owens <calvinowens@...com> wrote:
> With built-in netconsole and IXGBE, configuring netconsole via the kernel
> cmdline results in the following panic at boot:
>
> netpoll: netconsole: device eth0 not up yet, forcing it
> usb 2-1: new high-speed USB device number 2 using ehci-pci
> ixgbe 0000:03:00.0: registered PHC device on eth0
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000810
> <snip>
> Call Trace:
> [<ffffffff81578661>] ? vxlan_get_rx_port+0x41/0xa0
> [<ffffffff81586828>] ixgbe_open+0x4e8/0x540
> [<ffffffff8168045c>] __dev_open+0xac/0x120
> [<ffffffff81680506>] dev_open+0x36/0x70
> [<ffffffff8169abec>] netpoll_setup+0x23c/0x300
> [<ffffffff8169a66a>] ? netpoll_parse_options+0x19a/0x200
> [<ffffffff81d797a8>] ? option_setup+0x1f/0x1f
> [<ffffffff81d79882>] init_netconsole+0xda/0x262
> [<ffffffff81d797a8>] ? option_setup+0x1f/0x1f
> [<ffffffff810003a8>] do_one_initcall+0x88/0x1b0
> [<ffffffff81d31144>] kernel_init_freeable+0x14a/0x1e3
> [<ffffffff81d308f1>] ? do_early_param+0x8c/0x8c
> [<ffffffff81778610>] ? rest_init+0x80/0x80
> [<ffffffff8177861e>] kernel_init+0xe/0xe0
> [<ffffffff8177dc5f>] ret_from_fork+0x3f/0x70
> [<ffffffff81778610>] ? rest_init+0x80/0x80
>
> This happens because IXGBE assumes that vxlan has already been initialized.
> The cleanest way to fix this is to just initialize netconsole after all the
> other core networking stuff has completed.
>
> Signed-off-by: Calvin Owens <calvinowens@...com>
Fixing this by changing Makefile order is too fragile.
You are depending on the fact that Makefile order determines link order
and that determines initialization order. Down that path demons lie.
--
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