On Sun, 28 Nov 2010 04:18:25 + Ben Hutchings b...@debian.org wrote:
On Sun, 2010-11-28 at 08:28 +1100, Neil Brown wrote:
The fix I would recommend for 2.6.26 is to add
if (q-merge_bvec_fn)
rs-max_phys_segments = 1;
to dm_set_device_limits. Though the redhat one
On Mon, 2010-11-29 at 09:37 +1100, Neil Brown wrote:
On Sun, 28 Nov 2010 04:18:25 + Ben Hutchings b...@debian.org wrote:
On Sun, 2010-11-28 at 08:28 +1100, Neil Brown wrote:
The fix I would recommend for 2.6.26 is to add
if (q-merge_bvec_fn)
On Mon, 29 Nov 2010 00:08:47 + Ben Hutchings b...@debian.org wrote:
if (q-merge_bvec_fn !ti-type-merge)
limits-max_segments = 1;
(the test on -type-merge is important and applies to 2.6.26 as well).
Why is it not necessary to set seg_boundary_mask to
On Mon, 2010-11-29 at 11:48 +1100, Neil Brown wrote:
On Mon, 29 Nov 2010 00:08:47 + Ben Hutchings b...@debian.org wrote:
if (q-merge_bvec_fn !ti-type-merge)
limits-max_segments = 1;
(the test on -type-merge is important and applies to 2.6.26 as well).
Why
On Wed, 2010-11-24 at 17:01 +0100, Wouter D'Haeseleer wrote:
Hi Ben,
I have now successfully compiled the kernel including the patch which
this time applied without problem.
However the original bug is still present with the patch you grabbed
upstream.
For testing purpose I have tried
Ben,
I'm running 4 days now without any disk errors anymore.
As stated in my previous message this is with the RedHat patch applied.
If I compair the patches I see that the patch you grabed upstream does not deal
with t-limits.max_sectors
Thanks for a reply
Wouter
--
To UNSUBSCRIBE, email
Neil, would you mind looking at this:
On Sat, 2010-11-27 at 10:49 +0100, Wouter D'Haeseleer wrote:
Ben,
I'm running 4 days now without any disk errors anymore.
As stated in my previous message this is with the RedHat patch applied.
If I compair the patches I see that the patch you grabed
On Sat, 27 Nov 2010 19:53:54 + Ben Hutchings b...@debian.org wrote:
Neil, would you mind looking at this:
On Sat, 2010-11-27 at 10:49 +0100, Wouter D'Haeseleer wrote:
Ben,
I'm running 4 days now without any disk errors anymore.
As stated in my previous message this is with the
On Sun, 2010-11-28 at 08:28 +1100, Neil Brown wrote:
On Sat, 27 Nov 2010 19:53:54 + Ben Hutchings b...@debian.org wrote:
Neil, would you mind looking at this:
On Sat, 2010-11-27 at 10:49 +0100, Wouter D'Haeseleer wrote:
Ben,
I'm running 4 days now without any disk errors
Hi Ben,
I have now successfully compiled the kernel including the patch which this time
applied without problem.
However the original bug is still present with the patch you grabbed upstream.
For testing purpose I have tried also the patch which is supplied by redhat and
I can confirm that
Hi Ben,
Thanks for the quick response.
I'm trying the patch you send me but it seems to be a huge difference
from what I get using the source.
This is what i did:
apt-get source linux-image-2.6.26-2-xen-686
cd linux-2.6-2.6.26
fakeroot debian/rules source
fakeroot debian/rules setup
cd
Oeps, please ignore my previous post, it seems I made a mistake with the patch
files.
I have re-compiled the kernel.
I can say that after running now almost 3 hours I don't see the error anymore.
Therefore I can say this bug is resolved.
When will this patch make it into the normal updates?
I Spoke to soon, issue still present using the patch.
Just a small question to be sure I patched it correctly this is what I
did
cd /usr/src
apt-get build-dep linux-image-2.6.26-2-xen-686
apt-get source linux-image-2.6.26-2-xen-686
cd linux-2.6-2.6.26
fakeroot debian/rules source
fakeroot debian/rules setup
cd debian/build/source_i386_xen
#
On Tue, 2010-11-23 at 18:20 +0100, Wouter D'Haeseleer wrote:
Just a small question to be sure I patched it correctly this is what I
did
cd /usr/src
apt-get build-dep linux-image-2.6.26-2-xen-686
apt-get source linux-image-2.6.26-2-xen-686
cd linux-2.6-2.6.26
fakeroot debian/rules
On Tue, 2010-11-23 at 17:50 +, Ben Hutchings wrote:
[...]
Oops, that version was not quite completely adjusted. Please test this
instead.
and I have no idea why I thought that, because the first version I sent
you was correct and the second was not.
*sigh* OK, neither of them was
Package: linux-image-2.6.26-2-xen-686
Version: 2.6.26-25lenny1
Severity: critical
Justification: causes serious data loss
When accessing an lv using configured on a raid10 using xen results in
corrupted data as the following syslog indicates:
kernel: raid10_make_request bug: can't convert block
On Mon, 2010-11-22 at 11:48 +0100, Wouter D'Haeseleer wrote:
Package: linux-image-2.6.26-2-xen-686
Version: 2.6.26-25lenny1
Severity: critical
Justification: causes serious data loss
When accessing an lv using configured on a raid10 using xen results in
corrupted data as the following
On Tue, 2010-11-23 at 02:31 +, Ben Hutchings wrote:
I have attempted to adjust this for Debian's stable kernel version
(2.6.26) and the result is attached. Please could you test this,
following the instructions at
19 matches
Mail list logo
