On Sat, 2014-11-08 at 00:40 -0500, Gedalya wrote: > On 11/07/2014 03:25 AM, Ian Campbell wrote: > > On 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 weekend > > I 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. > > > Tried to just frankenport xen-netback from 3.18 into 3.16, didn't work > very well ;-)
Did you backport just the above or the full set of changes from 3.18? > I'm running 3.18rc3+ now. Bombarding the downed interface by > broadcast-pinging the network it's on causes the following > [ 281.396014] vif vif-3-0 vif3.0: Guest Rx stalled > [ 281.396080] breth1: port 3(vif3.0) entered disabled state > and 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 ready > And 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? I *think* this is the intended behaviour of "xen-netback: reintroduce guest Rx stall detection", since the interface is down on the guest side it becomes considered stalled (i.e not processing any packets). The "link becomes ready" message I think refers to the backend end of the connection, it's like a network cable only plugged in at one end or something. Perhaps things could be smarter, but that would be an upstream thing I think. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415443144.2030.23.ca...@hellion.org.uk
