So far 2.6.32-47.109 seems OK. 5 days uptime and this hasn't happened
yet. I don't know what the change was that fixed it, but I also don't
have a lot of time for hunting it down.
I'm going to tentatively close this and hope that it stays fixed.
** Changed in: linux (Ubuntu)
Status:
That didn't do it. Happened again last night after just 3 days uptime.
So far, 267a6bfc is looking like the culprit. Any ideas from your end?
Hoping to get access to a testing server this coming week, so I can
start looking at upstream kernels.
--
You received this bug notification because you
There is a follow-up to 2d8a041b (267a6bfc in ubuntu-lucid.git)
upstream, and that is b61a602e (ipvs: initialize returned data in
do_ip_vs_get_ctl). I'm building a kernel now with that applied on top
of 2.6.32-46.108. JFTR, uptime of 5 days at time of writing with
267a6bfc reverted, no problems,
apport information
** Tags added: apport-collected
** Description changed:
Our mail server has its backups on a storage array which is mounted via
iSCSI. Starting April 11th, there have been 5 events where the iSCSI
connection has been lost and the filesystem has been automatically
The server now has an uptime of 9 days on 2.6.32-46.105 and the issue
has not come back. I'm convinced this bug is a regression in
2.6.32-46.107.
I've added apport-collect info from the working kernel, and I've set the
status back to Confirmed as that's what Brad's bot had it on.
For lack of
As this is a production server I'm not comfortable changing to such a
radically different kernel at this time. I can try to get access to
another server with the same hardware and reproduce the bug but it will
take some time.
At this time the server is running 2.6.32-46.105 and has an uptime of 3
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v3.9 kernel[0].
If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.
If the mainline kernel does not fix
