Xen dom0 kernel corrupts software raid (2.6.24-19)

found the package name

Hello,
This is my first time posting in this system, so if I've overlooked some form of etiquette or done something wrong, I apologize in advance.

There was a discussion of this issue in the xen mailing list, culminating in a patch: http://lists.xensource.com/archives/html/xen-changelog/2008-04/msg00008.html

I've adapted the patch to the Ubuntu kernel build structure. The attached file simply needs to be dropped into debian/binary-custom.d/xen/patchset/ in the kernel source tree. After a rebuild of the xen-flavored kernel, I haven't been able to reproduce this bug no matter how hard I try. It was quite easy to trigger before via a few minutes of bonnie++ execution. I'll continue my stress testing and report back here if this doesn't fix the issue, but for now, I'm pretty sure that it does.

To be clear, I was testing this with linux-image-2.6.24-19-xen and both xen-3.2 and xen-3.1. According to posts on the xen mailing list, the issue is caused because the kernel will perform unnecessary bounce buffering with the sw-iommu when under heavy load from the 3w-9xxx driver.

I've been using the system heavily with linux-image-2.6.24-19-xen, ver 2.6.24-19.41 w/patch applied and xen-hypervisor-3.2 ver 3.2.0-0ubuntu10. The issue seems to be fixed by the upstream patch.

Thank you for your efforts, Amit!

Is anybody else running a kernel with the mentioned patch? I will try it myself in the coming days and report back here.

Why though is this seemingly ignored by the Ubuntu kernel team? 2.6.24 is the hardy kernel and hardy being a LTS release, shouldn't its kernels get fixed even if the bugged feature (e.g. xen dom0 support) has been dropped in the next release?

I just went ahead assigning this to the kernel team in the hopes of getting the fix into hardy-updates. My apologies if community members are not supposed to escalate issues in this way

Sorry for spamming your inboxes, just wanted to confirm that Amit's patch fixed the issue for me.

Previously I constantly ran into "Out of SW-IOMMU space" errors with my SATA controller ("ATI Technologies Inc SB600 Non-Raid-5 SATA"). Since applying the attached patch to the 2.6.24-21-xen kernel of my up-to-date hardy installation, I can not reproduce this error!

Hopefully this can be included into hardy-updates.

Thanks again, Amit!

This patch would have to go into the xen custom binaries. As there are no custom binaries for Intrepid and later that task could be closed.

IMO this is not linux-meta.

SRU justification:

Impact: Using SWIOMMU unnecessarily causes "out of space" errors and subsequently causes corruptions in software RAID (and probably also caused the problems mentioned in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/238118/comments/9).

Fix: (taken from the Xen changelog) This patch adds a new check, check_pages_physically_contiguous(),
to the test for pages stradding page boundaries both in swiotlb_map_sg() and dma_map_sg(), to capture these ranges and map them directly via virt_to_bus() mapping rather than through the swiotlb.

Testcase: See above.

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commitdiff;h=eb657c7a4d123b94b6b92d18650ee0ae3f87cdbb

Accepted linux into hardy-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package linux - 2.6.24-23.46

---------------
linux (2.6.24-23.46) hardy-proposed; urgency=low

  [Alessio Igor Bogani]

  * rt: Updated PREEMPT_RT support to rt21
    - LP: #302138

  [Amit Kucheria]

  * SAUCE: Update lpia patches from moblin tree
    - LP: #291457

  [Andy Whitcroft]

  * SAUCE: replace gfs2_bitfit with upstream version to prevent oops
    - LP: #276641

  [Colin Ian King]

  * isdn: Do not validate ISDN net device address prior to interface-up
    - LP: #237306
  * hwmon: (coretemp) Add Penryn CPU to coretemp
    - LP: #235119
  * USB: add support for Motorola ROKR Z6 cellphone in mass storage mode
    - LP: #263217
  * md: fix an occasional deadlock in raid5
    - LP: #208551

  [Stefan Bader]

  * SAUCE: buildenv: Show CVE entries in printchanges
  * SAUCE: buildenv: Send git-ubuntu-log informational message to stderr
  * Xen: dma: avoid unnecessarily SWIOTLB bounce buffering
    - LP: #247148
  * Update openvz patchset to apply to latest stable tree.
    - LP: #301634
  * XEN: Fix FTBS with stable updates
    - LP: #301634

  [Steve Conklin]

  * Add HID quirk for dual USB gamepad
    - LP: #140608

  [Tim Gardner]

  * Enable CONFIG_AX25_DAMA_SLAVE=y
    - LP: #257684
  * SAUCE: Correctly blacklist Thinkpad r40e in ACPI
    - LP: #278794
  * SAUCE: ALPS touchpad for Dell Latitude E6500/E6400
    - LP: #270643

  [Upstream Kernel Changes]

  * Revert "[Bluetooth] Eliminate checks for impossible conditions in IRQ
    handler"
    - LP: #217659
  * KVM: VMX: Clear CR4.VMXE in hardware_disable
    - LP: #268981
  * iov_iter_advance() fix
    - LP: #231746
  * Fix off-by-one error in iov_iter_advance()
    - LP: #231746
  * USB: serial: ch341: New VID/PID for CH341 USB-serial
    - LP: #272485
  * x86: Fix 32-bit x86 MSI-X allocation leakage
    - LP: #273103
  * b43legacy: Fix failure in rate-adjustment mechanism
    - LP: #273143
  * x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap.
    - LP: #276334
  * openvz: merge missed fixes from vanilla 2.6.24 openvz branch
    - LP: #298059
  * openvz: some autofs related fixes
    - LP: #298059
  * openvz: fix ve stop deadlock after nfs connect
    - LP: #298059
  * openvz: fix netlink and rtnl inside container
    - LP: #298059
  * openvz: fix wrong size of ub0_percpu
    - LP: #298059
  * openvz: fix OOPS while stopping VE started before binfmt_misc.ko loaded
    - LP: #298059
  * x86-64: Fix "bytes left to copy" return value for copy_from_user()
  * NET: Fix race in dev_close(). (Bug 9750)
    - LP: #301608
  * IPV6: Fix IPsec datagram fragmentation
    - LP: #301608
  * IPV6: dst_entry leak in ip4ip6_err.
    - LP: #301608
  * IPV4: Remove IP_TOS setting privilege checks.
    - LP: #301608
  * IPCONFIG: The kernel gets no IP from some DHCP servers
    - LP: #301608
  * IPCOMP: Disable BH on output when using shared tfm
    - LP: #301608
  * IRQ_NOPROBE helper functions
    - LP: #301608
  * MIPS: Mark all but i8259 interrupts as no-probe.
    - LP: #301608
  * ub: fix up the conversion to sg_init_table()
    - LP: #301608
  * x86: adjust enable_NMI_through_LVT0()
    - LP: #301608
  * SCSI ips: handle scsi_add_host() failure, and other err cl...

It would be great to get confirmation from the original bug reporter, spbike, that this bug is indeed fixed with this newer kernel. Thanks.

I'm very excited for this to be fixed in Hardy, as I have had quite a bit of trouble with it.

I am perhaps not up-to-speed on things. But although I know that KVM is now the preferred virtualization solution, due in part to ease-of-use at the desktop, Xen still has a lot of usefulness at the server.

I would, of course, be happy to run my data center on Ubuntu, if all the requirements can be met. At the data center level, support for Xen would be one of them.

Is there any chance of keeping builds of Xen binaries in the repositories of intrepid and forward, without changing the direction of KVM as the preferred solution? I don't believe that what I am requesting here is a change. Merely that we continue to build and support what we already used to build and support.

Thanks,
- alvinc

Leann Ogasawara wrote:
> It would be great to get confirmation from the original bug reporter,
> spbike, that this bug is indeed fixed with this newer kernel. Thanks.
>

I switched to a fedora derived kernel for a good while, but when I installed a
few more dom0's I used the ubuntu kernel without problem. Now it seems harder
(again), but Xen seems to be no longer supported. Our newest installs are now
switching to Enomaly and kvm.