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
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
