Bug 243223 - [vtnet] panic during boot when IP is assigned in /etc/rc.conf
Summary: [vtnet] panic during boot when IP is assigned in /etc/rc.conf
Status: Closed Unable to Reproduce
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-09 18:13 UTC by Alfredo Dal'Ava Junior
Modified: 2020-01-09 18:53 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alfredo Dal'Ava Junior freebsd_committer freebsd_triage 2020-01-09 18:13:24 UTC 
While testing a custom kernel with virtio drivers bultin on FreeBSD 13/powerpc64, I hit a panic during boot.

I have the following line in /etc/rc.conf:

    ifconfig_vtnet0="inet 10.10.20.73 netmask 255.255.255.0"

If I remove this line, kernel boots correctly. Also NIC works normally if I configure the IP address manually after boot.

kernel log during boot:

vtnet0: link state changed to UP
panic: keg vtnet_tx_hdr initialization after use.
cpuid = 0
time = 1578601768
KDB: stack backtrace:
0xe00000005a459140: at kdb_backtrace+0x60
0xe00000005a459250: at vpanic+0x1d8
0xe00000005a459300: at panic+0x40
0xe00000005a459330: at uma_zone_reserve+0x160
0xe00000005a4593e0: at vtnet_debugnet_init+0xac
0xe00000005a459440: at debugnet_any_ifnet_update+0x74
0xe00000005a4594f0: at dn_ifnet_event+0x28
0xe00000005a459520: at do_link_state_change+0x29c
0xe00000005a4595d0: at taskqueue_run_locked+0x184
0xe00000005a4596a0: at taskqueue_run+0x64
0xe00000005a4596e0: at taskqueue_swi_run+0x28
0xe00000005a459710: at ithread_loop+0x2cc
0xe00000005a459820: at fork_exit+0xc4
0xe00000005a4598c0: at fork_trampoline+0x18
0xe00000005a4598f0: at -0x4
KDB: enter: panic
[ thread pid 12 tid 100024 ]
Stopped at      kdb_enter+0x78: ori     r0, r0, 0x0
db>
Comment 1 Mark Johnston freebsd_committer freebsd_triage 2020-01-09 18:16:12 UTC 
I believe this is fixed by r356484.
Comment 2 Alfredo Dal'Ava Junior freebsd_committer freebsd_triage 2020-01-09 18:53:42 UTC 
Sure, it's fixed in current HEAD, you were fast! :)

Thanks