kernel-packages team mailing list archive

[Launchpad Bug Tracker <1469829@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package linux - 4.1.0-1.1

---------------
linux (4.1.0-1.1) wily; urgency=low

  [ Andy Whitcroft ]

  * SAUCE: overlay: add backwards compatible overlayfs format support V3
    - LP: #1395877, #1410480
  * SAUCE: overlayfs: when copying up and reading directories ensure
    mounter had permissions V2
    - CVE-2015-1328
  * [Packaging] fix up Vcs-Git: to point to launchpad
  * [Config] correct linux-initramfs-tool virtual linkage
    - LP: #1474810

  [ Chris J Arges ]

  * [Config] Add dm-service-time to multipath-modules
    - LP: #1469240
  * [Config] Add MTD_POWERNV_FLASH and OPAL_PRD
    - LP: #1464560

  [ Jay Vosburgh ]

  * SAUCE: fan: Proof of concept implementation (v2)
    - LP: #1439706
  * SAUCE: fan: tunnel multiple mapping mode (v3)
    - LP: #1470091

  [ Leann Ogasawara ]

  * Revert "SAUCE: ext4: disable ext4_punch_hole for indirect filesystems"
  * Revert "SAUCE: intel_pstate: inform user that thermald is worth
    considering"
  * Revert "SAUCE: Work around broken ACPI backlight on Dell Inspiron 5537"
  * Revert "SAUCE: dm-crypt: never use write same"
  * Release Tracking Bug
    - LP: #1476333

  [ Tim Gardner ]

  * Rebase to v4.1
    - LP: #1443371
  * [Config] Enable Apparmor
  * [Config] CONFIG_OVERLAY_FS_V1=y
  * [Config] DEFAULT_IOSCHED="deadline" for ppc64el
    - LP: #1469829
  * [Config] CONFIG_VM86=n
    - LP: #1473447
  * [Config] ACORN_PARTITION=n
    - LP: #1453117

  [ Timo Aaltonen ]

  * [Config] Disable CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT
    - LP: #1473319

  [ Upstream Kernel Changes ]

  * efi: efivar_create_sysfs_entry() should return negative error codes
  * efi: Add esrt support
  * x86, doc: Remove cmdline_size from list of fields to be filled in for
    EFI handover
  * efi/esrt: Fix some compiler warnings
  * efi: dmi: List SMBIOS3 table before SMBIOS table
  * efi: Add 'systab' information to Documentation/ABI
  * ALSA: hda - restore the MIC FIXUP for some Dell machines
    - LP: #1473560
  * mtd: powernv: Add powernv flash MTD abstraction driver
    - LP: #1464560
  * powerpc/powernv: Expose OPAL APIs required by PRD interface
    - LP: #1464560
  * powerpc/powernv: Add opal-prd channel
    - LP: #1464560
  * powerpc/powernv: fix construction of opal PRD messages
    - LP: #1464560
  * powerpc/include: Add opal-prd to installed uapi headers
    - LP: #1464560
  * powerpc/powernv: Fix vma page prot flags in opal-prd driver
    - LP: #1464560

 -- Leann Ogasawara <leann.ogasawara@xxxxxxxxxxxxx>  Mon, 20 Jul 2015
10:16:06 -0700

** Changed in: linux (Ubuntu)
       Status: In Progress => Fix Released

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2015-1328

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1469829

Title:
  ppc64el should use 'deadline' as default io scheduler

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  In Progress
Status in linux source package in Utopic:
  In Progress
Status in linux source package in Vivid:
  In Progress

Bug description:
  -- Problem Description --

  Firestone system given to DASD group failed HTX overnight test with miscompare error.
  HTX mdt.hdbuster was running on secondary drive and failed about 12 hours into test

  HTX miscompare analysis:
  ====================-==

  Device under test: /dev/sdb
  Stanza running: rule_3
  miscompare offset: 0x40
  Transfer size: Random Size
  LBA number: 0x70fc
  miscompare length: all the blocks in the transfer size

  *- STANZA 3: Creates number of threads twice the queue depth. Each thread  -*
  *- doing 20000 num_oper with RC operation with xfer size between 1 block   -*
  *- to 256K.                                                                -*

  This miscompare shows read operation is unable to get the expected
  data from the disk. The re-read buffer also shows the same data as the
  first read operation. Since the first read and next re-read shows same
  data, there could be a write operation (of previous rule stanza to
  initialize disk with pattern 007 ) failure on the disk. The same
  miscompare behavior shows for all the blocks in the transfer size.

  /dev/sdb          Jun  2 02:29:43 2015 err=000003b6 sev=2 hxestorage      <<===  device name (/dev/sdb)
  rule_3_13  numopers=     20000  loop=       767  blk=0x70fc len=89088
   min_blkno=0 max_blkno=0x74706daf, RANDOM access
  Seed Values= 37303, 290, 23235
  Data Pattern Seed Values = 37303, 291, 23235
  BWRC LBA fencepost Detail:
  th_num                min_lba                  max_lba      status
       0                 0            1c9be3ff    R
       1          1d1c1b6c            3a3836d7    F
       2          3a3836d8            57545243    F
       3          57545244            74706daf    F
  Miscompare at buffer offset 64 (0x40)                             <<===   miscompare offset (0x40)
  (Flags: badsig=0; cksum=0x60000)  Maximum LBA = 0x74706daf
  wbuf (baseaddr 0x3ffe1c0e6600) b0ffffffffffffffffffffffffffffffffffffff
  rbuf (baseaddr 0x3ffe1c0fc400) 850100fc700200fd700300fe700400ff70050000
  Write buffer saved in /tmp/htxsdb.wbuf1
  Read buffer saved in /tmp/htxsdb.rbuf1
  Re-read fails compare at offset64; buffer saved in /tmp/htxsdb.rerd1
  errno: 950(Unknown error 950)

  Asghar reproduced that HTX hang he is seeing. Looking in the kernel
  logs I see some messages from the kernel that there are user threads
  blocked on getting reads serviced. So likely HTX is seeing the same
  thing. I've asked Asghar to try using the deadline I/O scheduler
  rather than CFQ to see if that makes any difference. If that does not
  make any difference, the next thing to try is reducing the queue depth
  of the device. Right now its 31, which I think is pretty high.

  Step 1:

  echo deadline > /sys/block/sda/queue/scheduler
  echo deadline > /sys/block/sdb/queue/scheduler

  If that reproduces the issue, go to step 2:

  echo cfq > /sys/block/sda/queue/scheduler
  echo cfq > /sys/block/sdb/queue/scheduler
  echo 8 > /sys/block/sda/device/queue_depth
  echo 8 > /sys/block/sdb/device/queue_depth

  Breno - it looks like the default I/O scheduler + default queue depth
  for the SATA disks in Firestone is not optimal, in that when running a
  heavy I/O workload, we see read starvation occurring, which is making
  the system nearly unusable.

  Once we changed the I/O scheduler from cfq to deadline, all the issues
  went away and the system is able to run the same workload yet still be
  responsive. Suggest we either encourage Canonical to change the
  default I/O scheduler to deadline or at the very least provide
  documentation to encourage our customers to make this change
  themselves.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1469829/+subscriptions