On 11/07/2014 03:25 AM, Ian Campbell wrote:
Tried to just frankenport xen-netback from 3.18 into 3.16, didn't work very well ;-) I'm running 3.18rc3+ now. Bombarding the downed interface by broadcast-pinging the network it's on causes the followingOn Thu, 2014-11-06 at 11:06 -0500, Gedalya wrote:I suspect we will need to backport some xen-netback patch or other. I've put some feelers out to see if any of the upstream devs have any hints...OK so if it's just a matter of changing a kernel on one box, I can perhaps try to build a 3.18 this weekendI think these commits, which are in v3.18-rc3, are probably the ones: ecf08d2 xen-netback: reintroduce guest Rx stall detection f48da8b xen-netback: fix unlimited guest Rx internal queue and carrier flapping bc96f64 xen-netback: make feature-rx-notify mandatory I'll investigate a backport/check if they are destined for stable@. Ian.
[ 281.396014] vif vif-3-0 vif3.0: Guest Rx stalled [ 281.396080] breth1: port 3(vif3.0) entered disabled stateand that's it. This is instead of the previously repeated 'draining TX queue' messages. Let's assume it won't crash, I'll let you know if this assumption turns out to be wrong.
I'm kind of curious why this is preceded by [ 46.232475] vif vif-3-0 vif3.0: Guest Rx ready [ 46.232514] IPv6: ADDRCONF(NETDEV_CHANGE): vif3.0: link becomes readyAnd the host figures out it's down only when traffic comes and doesn't get through.
I guess this might change if I run 3.18 in the guest too?