Re: ifconfig triggers kernel trap on boot

From: Attilio Rao <attilio_at_freebsd.org>
Date: Fri, 22 May 2009 21:34:27 +0200
2009/5/22 Stefan Bethke <stb_at_lassitu.de>:
> Just updated my month-old current.  On boot, ifconfig triggers this panic:
>
> Trying to mount root from ufs:/dev/mirror/diesel_root
>
> (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
> (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition
> (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0
> (probe0:umass-sim0:0:0:0): Medium not present
> (probe0:umass-sim0:0:0:0): Unretryable error
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <Generic- SD/MMC 1.00> Removable Direct Access SCSI-0 device
> da0: 40.000MB/s transfers
> da0: Attempt to query device size failed: NOT READY, Medium not present
> Entropy harvesting: interrupts ethernet
> point_to_point(probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0
> (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error
> (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition
> (probe0:umass-sim0:0:0:1): NOT READY asc:3a,0
> (probe0:umass-sim0:0:0:1): Medium not present
> (probe0:umass-sim0:0:0:1): Unretryable error
> da1 at umass-sim0 bus 0 target 0 lun 1
> da1: <Generic- MS/MS-Pro 1.00> Removable Direct Access SCSI-0 device
> da1: 40.000MB/s transfers
> da1: Attempt to query device size failed: NOT READY, Medium not present
>  kickstart.
> /odev/mirror/diesel_root: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /deirror/diesel_root: clean, 759914 free (27202 frags, 91589 blocks, 1.3%
> fragmentation)
> bridge0: Ethernet address: d6:a8:2e:5f:c3:64
> tap0: Ethernet address: 00:bd:4b:24:00:00
> tap0: promiscuous mode enabled
> vlan1: promiscuous mode enabled
> kernel trap 9 with interrupts disabled
>
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 1; apic id = 01
> instruction pointer     = 0x20:0xffffffff80323f5b
> stack pointer           = 0x28:0xffffff80771c2760
> frame pointer           = 0x28:0xffffff80771c2770
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 536 (ifconfig)
> [thread pid 536 tid 100085 ]
> Stopped at      turnstile_setowner+0x2b:        movq    %rcx,0x68(%rdx)
> db> bt
> Tracing pid 536 tid 100085 td 0xffffff0004533ab0
> turnstile_setowner() at turnstile_setowner+0x2b
> turnstile_wait() at turnstile_wait+0x296
> _mtx_lock_sleep() at _mtx_lock_sleep+0xb0
> _mtx_lock_flags() at _mtx_lock_flags+0x43
> ifaof_ifpforaddr() at ifaof_ifpforaddr+0x57
> rt_getifa_fib() at rt_getifa_fib+0xa8
> rtrequest1_fib() at rtrequest1_fib+0x3d9
> in_ifinit() at in_ifinit+0x3ba
> in_control() at in_control+0xd81
> ifioctl() at ifioctl+0x2de
> kern_ioctl() at kern_ioctl+0xb6
> ioctl() at ioctl+0xfd
> syscall() at syscall+0x1a5
> Xfast_syscall() at Xfast_syscall+0xd0
> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800a6efbc, rsp =
> 0x7fffffffe4c8, rbp = 0x7fffffffef6d ---
> db>
>
>
> I've added an additional debug to network.subr to find out which ifconfig
> exactly it trips over, and it appears to be:
>
> /etc/rc: DEBUG: Cloned: bridge0 tap0 vlan1 vlan2 vlan3
> /etc/rc: DEBUG: ifconfig lo0 inet 127.0.0.1
> /etc/rc: DEBUG: ifconfig em0 up
> /etc/rc: DEBUG: tifconfig bridge0a ether 02:00:00:p00:00:01 addm ta0p0 addm
> vlan1
> : promiscuous mode enabled
> vlan1: promiscuous mode enabled
> kernel trap 9 with interrupts disabled
>
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 1; apic id = 01
> instruction pointer     = 0x20:0xffffffff80323f5b
> stack pointer           = 0x28:0xffffff80771c7760
> frame pointer           = 0x28:0xffffff80771c7770
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 581 (ifconfig)
>
> (The serial link is only 3wire, so it's slightly garbled.)
>
> This corresponds to these rc.conf settings:
> ifconfig_bridge0="ether 02:00:00:00:00:01"
> ifconfig_bridge0_alias0="addm tap0 addm vlan1"
>
> It appears that adding vlan1 triggers the panic.
>
> Using the month-old kernel manages to bring up the system, but I'm getting a
> generic "login: Could not determine audit condition" on the console.
>
> Additionally, while changing configuration in single user with the
> up-to-date kernel, I got this on reboot:
>
> Syncing disks, vnodes remaining...0 done
> All buffers synced.
> GEOM_MIRROR: Device diesel_root: provider mirror/diesel_root destroyed.
> Uptime: 6m32s
> GEOM_MIRROR: Device diesel_root destroyed.
> Rebooting...
> cpu_reset: Stopping other CPUs
> spin lock 0xffffffff8078c900 (sched lock 1) held by 0xffffff00014d4ab0 (tid
> 100002) too long
> panic: spin lock held too long
> cpuid = 0
> KDB: enter: panic
> [thread pid 77 tid 100090 ]
> Stopped at      kdb_enter+0x3d: movq    $0,0x48bbd0(%rip)
> db> bt
> Tracing pid 77 tid 100090 td 0xffffff000457bab0
> kdb_enter() at kdb_enter+0x3d
> panic() at panic+0x17b
> _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39
> _mtx_lock_spin() at _mtx_lock_spin+0x9e
> _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x72
> sched_balance_group() at sched_balance_group+0xc5
> sched_balance_group() at sched_balance_group+0x1f8
> sched_balance() at sched_balance+0xa2
> sched_clock() at sched_clock+0xf6
> statclock() at statclock+0xbd
> lapic_handle_timer() at lapic_handle_timer+0x197
> Xtimerint() at Xtimerint+0x8c
> --- interrupt, rip = 0xffffffff80541cc4, rsp = 0xffffff80771dba90, rbp =
> 0xffffff80771dbab0 ---
> DELAY() at DELAY+0x64
> cpu_reset() at cpu_reset+0xdd
> boot() at boot+0x2e6
> reboot() at reboot+0x42
> syscall() at syscall+0x1a5
> Xfast_syscall() at Xfast_syscall+0xd0
> --- syscall (55, FreeBSD ELF64, reboot), rip = 0x800788eec, rsp =
> 0x7fffffffeca8, rbp = 0 ---

Did this happen inside VMware or with normal running?

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
Received on Fri May 22 2009 - 17:34:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:48 UTC