amd64/183397: Kernel panic at first incoming ssh

[John Baldwin]

On Friday, November 01, 2013 12:48:54 pm Torbjorn Granlund wrote:
> John Baldwin <jhb at freebsd.org> writes:
> 
>   Can you fire up gdb against your 64-bit kernel file (e.g. gdb 
>   /boot/kernel/kernel) and do 'l *xn_intr+0x7d'?
> 
> I'm afraid my ignorance of how to debug the kernel will show itself
> here.
> 
> I did this:
> 
> 1. booted the system.
> 2. logged in as root on the (vnc) console.
> 3. issued the command "gdb /boot/kernel/kernel"
> 4. Issued the above command and got this printout:
> 
> (gdb) l *xn_intr+0x7d
> 0xffffffff8079fb7d is in xn_intr (atomic.h:161).
> 156     atomic.h: No such file ot directory.
>         in atomic.h
> (gdb)

Hummm, I assume you can't get a crashdump when this happens?  atomic.h means 
it is likely acquiring a lock:

static void
xn_intr(void *xsc)
{
	struct netfront_info *np = xsc;
	struct ifnet *ifp = np->xn_ifp;

#if 0
	if (!(np->rx.rsp_cons != np->rx.sring->rsp_prod &&
	    likely(netfront_carrier_ok(np)) &&
	    ifp->if_drv_flags & IFF_DRV_RUNNING))
		return;
#endif
	if (RING_HAS_UNCONSUMED_RESPONSES(&np->tx)) {
		XN_TX_LOCK(np);
		xn_txeof(np);
		XN_TX_UNLOCK(np);			
	}	

	XN_RX_LOCK(np);
	xn_rxeof(np);
	XN_RX_UNLOCK(np);

Either the XN_TX_LOCK() or XN_RX_LOCK().  It's hard to narrow down where the 
corruption lies without a dump.

-- 
John Baldwin