G'day, I've committed some sanity checking code to the FreeBSD-current/Xen netfront drivers. The driver now ensures there are TX mbuf and xen TX ring descriptor slots available before it queues a packet.
There's some debugging printf()'s that will spit out messages when things go awry, eg: xn_start_locked: xn_tx_chain_cnt (254) + nfrags 2 >= NET_TX_RING_SIZE (256); must be full! xn_start_locked: xn_tx_chain_cnt (255) + nfrags 1 >= NET_TX_RING_SIZE (256); must be full! This seems to have ceased the panics under CPU/memory pressure on my playpen server. I'm going to continue tidying up the netfront driver a little more over the next few days to hopefully wrap up some dangling loose ends which I can see. I'd appreciate it if people could give FreeBSD-current/Xen a right royal thrashing (eg, 4 FreeBSD vms on one host pegging network and CPU traffic at maximum between each other) to try and elicit any other crazy network behaviour. There's only so much I can test atm. Thanks, Adrian Adrian _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"