At this point a proper reproducer would help the most. This way we could get crashdumps and other useful information that may not be possible in production environments.
Reading through the bug the best description I can see is:
1) Start LXC container
2) Download > 100MB of data
3) Stop LXC container
4) Repeat until you see the kernel message
For example, I can script this a bit:
#!/bin/bash
# setup
sudo lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64
fallocate -l 1000000 file
IP=$(sudo lxc-attach -n u1 -- hostname -I)
# test
while true; do
sudo lxc-start --name u1 -d
ssh ubuntu@$IP rm file
scp file ubuntu@$IP:
sudo lxc-stop --name u1
done
Running this on my machine doesn't show a failure. So I suspect there are other variables involved. Please let us know other relevant info that would help isolate a reproducer for this.
Thanks,
At this point a proper reproducer would help the most. This way we could get crashdumps and other useful information that may not be possible in production environments.
Reading through the bug the best description I can see is:
1) Start LXC container
2) Download > 100MB of data
3) Stop LXC container
4) Repeat until you see the kernel message
For example, I can script this a bit:
#!/bin/bash
# setup
sudo lxc-create -t download -n u1 -- -d ubuntu -r trusty -a amd64
fallocate -l 1000000 file
IP=$(sudo lxc-attach -n u1 -- hostname -I)
# test
while true; do
sudo lxc-start --name u1 -d
ssh ubuntu@$IP rm file
scp file ubuntu@$IP:
sudo lxc-stop --name u1
done
Running this on my machine doesn't show a failure. So I suspect there are other variables involved. Please let us know other relevant info that would help isolate a reproducer for this.
Thanks,