<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers, branch v5.4.31</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v5.4.31</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=v5.4.31'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2020-04-08T07:08:46+00:00</updated>
<entry>
<title>i2c: i801: Do not add ICH_RES_IO_SMI for the iTCO_wdt device</title>
<updated>2020-04-08T07:08:46+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2020-02-26T13:21:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=15ee8da79ee3447d1c483c4c5500e0f12f07b6e2'/>
<id>urn:sha1:15ee8da79ee3447d1c483c4c5500e0f12f07b6e2</id>
<content type='text'>
commit 04bbb97d1b732b2d197f103c5818f5c214a4cf81 upstream.

Martin noticed that nct6775 driver does not load properly on his system
in v5.4+ kernels. The issue was bisected to commit b84398d6d7f9 ("i2c:
i801: Use iTCO version 6 in Cannon Lake PCH and beyond") but it is
likely not the culprit because the faulty code has been in the driver
already since commit 9424693035a5 ("i2c: i801: Create iTCO device on
newer Intel PCHs"). So more likely some commit that added PCI IDs of
recent chipsets made the driver to create the iTCO_wdt device on Martins
system.

The issue was debugged to be PCI configuration access to the PMC device
that is not present. This returns all 1's when read and this caused the
iTCO_wdt driver to accidentally request resourses used by nct6775.

It turns out that the SMI resource is only required for some ancient
systems, not the ones supported by this driver. For this reason do not
populate the SMI resource at all and drop all the related code. The
driver now always populates the main I/O resource and only in case of SPT
(Intel Sunrisepoint) compatible devices it adds another resource for the
NO_REBOOT bit. These two resources are of different types so
platform_get_resource() used by the iTCO_wdt driver continues to find
the both resources at index 0.

Link: https://lore.kernel.org/linux-hwmon/CAM1AHpQ4196tyD=HhBu-2donSsuogabkfP03v1YF26Q7_BgvgA@mail.gmail.com/
Fixes: 9424693035a5 ("i2c: i801: Create iTCO device on newer Intel PCHs")
[wsa: complete fix needs all of http://patchwork.ozlabs.org/project/linux-i2c/list/?series=160959&amp;state=*]
Reported-by: Martin Volf &lt;martin.volf.42@gmail.com&gt;
Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>watchdog: iTCO_wdt: Make ICH_RES_IO_SMI optional</title>
<updated>2020-04-08T07:08:46+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2020-02-26T13:21:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=079c8da9e5acc21665e3bbd2cea1b064b39976be'/>
<id>urn:sha1:079c8da9e5acc21665e3bbd2cea1b064b39976be</id>
<content type='text'>
commit e42b0c24389d5a1602e77db4f6def0d5a19e3e43 upstream.

The iTCO_wdt driver only needs ICH_RES_IO_SMI I/O resource when either
turn_SMI_watchdog_clear_off module parameter is set to match -&gt;iTCO_version
(or higher), and when legacy iTCO_vendorsupport is set. Modify the driver
so that ICH_RES_IO_SMI is optional if the two conditions are not met.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>watchdog: iTCO_wdt: Export vendorsupport</title>
<updated>2020-04-08T07:08:46+00:00</updated>
<author>
<name>Mika Westerberg</name>
<email>mika.westerberg@linux.intel.com</email>
</author>
<published>2020-02-26T13:21:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b42afa3475bfd9ce96c230a50c6cd81288147bac'/>
<id>urn:sha1:b42afa3475bfd9ce96c230a50c6cd81288147bac</id>
<content type='text'>
commit 7ca6ee38909109751bfab79e9f6c570d2ed258c6 upstream.

In preparation for making -&gt;smi_res optional the iTCO_wdt driver needs
to know whether vendorsupport is being set to non-zero. For this reason
export the variable.

Signed-off-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>IB/hfi1: Ensure pq is not left on waitlist</title>
<updated>2020-04-08T07:08:45+00:00</updated>
<author>
<name>Mike Marciniszyn</name>
<email>mike.marciniszyn@intel.com</email>
</author>
<published>2020-03-20T20:02:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a6b1820d333071943a9cba434249e9176fa7fed0'/>
<id>urn:sha1:a6b1820d333071943a9cba434249e9176fa7fed0</id>
<content type='text'>
commit 9a293d1e21a6461a11b4217b155bf445e57f4131 upstream.

The following warning can occur when a pq is left on the dmawait list and
the pq is then freed:

  WARNING: CPU: 47 PID: 3546 at lib/list_debug.c:29 __list_add+0x65/0xc0
  list_add corruption. next-&gt;prev should be prev (ffff939228da1880), but was ffff939cabb52230. (next=ffff939cabb52230).
  Modules linked in: mmfs26(OE) mmfslinux(OE) tracedev(OE) 8021q garp mrp ib_isert iscsi_target_mod target_core_mod crc_t10dif crct10dif_generic opa_vnic rpcrdma ib_iser libiscsi scsi_transport_iscsi ib_ipoib(OE) bridge stp llc iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crct10dif_pclmul crct10dif_common crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd ast ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm pcspkr joydev drm_panel_orientation_quirks i2c_i801 mei_me lpc_ich mei wmi ipmi_si ipmi_devintf ipmi_msghandler nfit libnvdimm acpi_power_meter acpi_pad hfi1(OE) rdmavt(OE) rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_core binfmt_misc numatools(OE) xpmem(OE) ip_tables
  nfsv3 nfs_acl nfs lockd grace sunrpc fscache igb ahci libahci i2c_algo_bit dca libata ptp pps_core crc32c_intel [last unloaded: i2c_algo_bit]
  CPU: 47 PID: 3546 Comm: wrf.exe Kdump: loaded Tainted: G W OE ------------ 3.10.0-957.41.1.el7.x86_64 #1
  Hardware name: HPE.COM HPE SGI 8600-XA730i Gen10/X11DPT-SB-SG007, BIOS SBED1229 01/22/2019
  Call Trace:
  [&lt;ffffffff91f65ac0&gt;] dump_stack+0x19/0x1b
  [&lt;ffffffff91898b78&gt;] __warn+0xd8/0x100
  [&lt;ffffffff91898bff&gt;] warn_slowpath_fmt+0x5f/0x80
  [&lt;ffffffff91a1dabe&gt;] ? ___slab_alloc+0x24e/0x4f0
  [&lt;ffffffff91b97025&gt;] __list_add+0x65/0xc0
  [&lt;ffffffffc03926a5&gt;] defer_packet_queue+0x145/0x1a0 [hfi1]
  [&lt;ffffffffc0372987&gt;] sdma_check_progress+0x67/0xa0 [hfi1]
  [&lt;ffffffffc03779d2&gt;] sdma_send_txlist+0x432/0x550 [hfi1]
  [&lt;ffffffff91a20009&gt;] ? kmem_cache_alloc+0x179/0x1f0
  [&lt;ffffffffc0392973&gt;] ? user_sdma_send_pkts+0xc3/0x1990 [hfi1]
  [&lt;ffffffffc0393e3a&gt;] user_sdma_send_pkts+0x158a/0x1990 [hfi1]
  [&lt;ffffffff918ab65e&gt;] ? try_to_del_timer_sync+0x5e/0x90
  [&lt;ffffffff91a3fe1a&gt;] ? __check_object_size+0x1ca/0x250
  [&lt;ffffffffc0395546&gt;] hfi1_user_sdma_process_request+0xd66/0x1280 [hfi1]
  [&lt;ffffffffc034e0da&gt;] hfi1_aio_write+0xca/0x120 [hfi1]
  [&lt;ffffffff91a4245b&gt;] do_sync_readv_writev+0x7b/0xd0
  [&lt;ffffffff91a4409e&gt;] do_readv_writev+0xce/0x260
  [&lt;ffffffff918df69f&gt;] ? pick_next_task_fair+0x5f/0x1b0
  [&lt;ffffffff918db535&gt;] ? sched_clock_cpu+0x85/0xc0
  [&lt;ffffffff91f6b16a&gt;] ? __schedule+0x13a/0x860
  [&lt;ffffffff91a442c5&gt;] vfs_writev+0x35/0x60
  [&lt;ffffffff91a4447f&gt;] SyS_writev+0x7f/0x110
  [&lt;ffffffff91f78ddb&gt;] system_call_fastpath+0x22/0x27

The issue happens when wait_event_interruptible_timeout() returns a value
&lt;= 0.

In that case, the pq is left on the list. The code continues sending
packets and potentially can complete the current request with the pq still
on the dmawait list provided no descriptor shortage is seen.

If the pq is torn down in that state, the sdma interrupt handler could
find the now freed pq on the list with list corruption or memory
corruption resulting.

Fix by adding a flush routine to ensure that the pq is never on a list
after processing a request.

A follow-up patch series will address issues with seqlock surfaced in:
https://lore.kernel.org/r/20200320003129.GP20941@ziepe.ca

The seqlock use for sdma will then be converted to a spin lock since the
list_empty() doesn't need the protection afforded by the sequence lock
currently in use.

Fixes: a0d406934a46 ("staging/rdma/hfi1: Add page lock limit check for SDMA requests")
Link: https://lore.kernel.org/r/20200320200200.23203.37777.stgit@awfm-01.aw.intel.com
Reviewed-by: Kaike Wan &lt;kaike.wan@intel.com&gt;
Signed-off-by: Mike Marciniszyn &lt;mike.marciniszyn@intel.com&gt;
Signed-off-by: Dennis Dalessandro &lt;dennis.dalessandro@intel.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iwlwifi: dbg: don't abort if sending DBGC_SUSPEND_RESUME fails</title>
<updated>2020-04-08T07:08:45+00:00</updated>
<author>
<name>Luca Coelho</name>
<email>luciano.coelho@intel.com</email>
</author>
<published>2020-03-06T13:16:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=be8a3aecd21ae4769766ca6f1a88a1fbfbe2d148'/>
<id>urn:sha1:be8a3aecd21ae4769766ca6f1a88a1fbfbe2d148</id>
<content type='text'>
commit 699b760bd29edba736590fffef7654cb079c753e upstream.

If the firmware is in a bad state or not initialized fully, sending
the DBGC_SUSPEND_RESUME command fails but we can still collect logs.

Instead of aborting the entire dump process, simply ignore the error.
By removing the last callpoint that was checking the return value, we
can also convert the function to return void.

Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Fixes: 576058330f2d ("iwlwifi: dbg: support debug recording suspend resume command")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Link: https://lore.kernel.org/r/iwlwifi.20200306151129.dcec37b2efd4.I8dcd190431d110a6a0e88095ce93591ccfb3d78d@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iwlwifi: yoyo: don't add TLV offset when reading FIFOs</title>
<updated>2020-04-08T07:08:45+00:00</updated>
<author>
<name>Mordechay Goodstein</name>
<email>mordechay.goodstein@intel.com</email>
</author>
<published>2020-03-06T13:16:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=b4190809a17be0e844ba54b6a75afae078386fc5'/>
<id>urn:sha1:b4190809a17be0e844ba54b6a75afae078386fc5</id>
<content type='text'>
commit a5688e600e78f9fc68102bf0fe5c797fc2826abe upstream.

The TLV offset is only used to read registers, while the offset used for
the FIFO addresses are hard coded in the driver and not given by the
TLV.

If we try to apply the TLV offset when reading the FIFOs, we'll read
from invalid addresses, causing the driver to hang.

Signed-off-by: Mordechay Goodstein &lt;mordechay.goodstein@intel.com&gt;
Fixes: 8d7dea25ada7 ("iwlwifi: dbg_ini: implement Rx fifos dump")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Link: https://lore.kernel.org/r/iwlwifi.20200306151129.fbab869c26fa.I4ddac20d02f9bce41855a816aa6855c89bc3874e@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iwlwifi: consider HE capability when setting LDPC</title>
<updated>2020-04-08T07:08:44+00:00</updated>
<author>
<name>Mordechay Goodstein</name>
<email>mordechay.goodstein@intel.com</email>
</author>
<published>2020-03-06T13:16:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=00e332e42bbe5b2def0d8c10cc3b7d82c44abd73'/>
<id>urn:sha1:00e332e42bbe5b2def0d8c10cc3b7d82c44abd73</id>
<content type='text'>
commit cb377dfda1755b3bc01436755d866c8e5336a762 upstream.

The AP may set the LDPC capability only in HE (IEEE80211_HE_PHY_CAP1),
but we were checking it only in the HT capabilities.

If we don't use this capability when required, the DSP gets the wrong
configuration in HE and doesn't work properly.

Signed-off-by: Mordechay Goodstein &lt;mordechay.goodstein@intel.com&gt;
Fixes: befebbb30af0 ("iwlwifi: rs: consider LDPC capability in case of HE")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Link: https://lore.kernel.org/r/iwlwifi.20200306151128.492d167c1a25.I1ad1353dbbf6c99ae57814be750f41a1c9f7f4ac@changeid
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>net/mlx5e: kTLS, Fix wrong value in record tracker enum</title>
<updated>2020-04-08T07:08:44+00:00</updated>
<author>
<name>Tariq Toukan</name>
<email>tariqt@mellanox.com</email>
</author>
<published>2020-02-24T11:56:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5f843cb7714272d88b7f42908b3b0227cb3dc9b7'/>
<id>urn:sha1:5f843cb7714272d88b7f42908b3b0227cb3dc9b7</id>
<content type='text'>
commit f28ca65efa87b3fb8da3d69ca7cb1ebc0448de66 upstream.

Fix to match the HW spec: TRACKING state is 1, SEARCHING is 2.
No real issue for now, as these values are not currently used.

Fixes: d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support")
Signed-off-by: Tariq Toukan &lt;tariqt@mellanox.com&gt;
Reviewed-by: Boris Pismenny &lt;borisp@mellanox.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@mellanox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>soc: mediatek: knows_txdone needs to be set in Mediatek CMDQ helper</title>
<updated>2020-04-08T07:08:44+00:00</updated>
<author>
<name>Bibby Hsieh</name>
<email>bibby.hsieh@mediatek.com</email>
</author>
<published>2020-02-14T04:35:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ea26f82a04223adeb86103e8f17040db128589cb'/>
<id>urn:sha1:ea26f82a04223adeb86103e8f17040db128589cb</id>
<content type='text'>
commit ce35e21d82bcac8b3fd5128888f9e233f8444293 upstream.

Mediatek CMDQ driver have a mechanism to do TXDONE_BY_ACK,
so we should set knows_txdone.

Fixes:576f1b4bc802 ("soc: mediatek: Add Mediatek CMDQ helper")

Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: Bibby Hsieh &lt;bibby.hsieh@mediatek.com&gt;
Reviewed-by: CK Hu &lt;ck.hu@mediatek.com&gt;
Signed-off-by: Matthias Brugger &lt;matthias.bgg@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Revert "dm: always call blk_queue_split() in dm_process_bio()"</title>
<updated>2020-04-08T07:08:43+00:00</updated>
<author>
<name>Mike Snitzer</name>
<email>snitzer@redhat.com</email>
</author>
<published>2020-04-02T23:36:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=2892100bc85ae446088cebe0c00ba9b194c0ac9d'/>
<id>urn:sha1:2892100bc85ae446088cebe0c00ba9b194c0ac9d</id>
<content type='text'>
commit 120c9257f5f19e5d1e87efcbb5531b7cd81b7d74 upstream.

This reverts commit effd58c95f277744f75d6e08819ac859dbcbd351.

blk_queue_split() is causing excessive IO splitting -- because
blk_max_size_offset() depends on 'chunk_sectors' limit being set and
if it isn't (as is the case for DM targets!) it falls back to
splitting on a 'max_sectors' boundary regardless of offset.

"Fix" this by reverting back to _not_ using blk_queue_split() in
dm_process_bio() for normal IO (reads and writes).  Long-term fix is
still TBD but it should focus on training blk_max_size_offset() to
call into a DM provided hook (to call DM's max_io_len()).

Test results from simple misaligned IO test on 4-way dm-striped device
with chunksize of 128K and stripesize of 512K:

xfs_io -d -c 'pread -b 2m 224s 4072s' /dev/mapper/stripe_dev

before this revert:

253,0   21        1     0.000000000  2206  Q   R 224 + 4072 [xfs_io]
253,0   21        2     0.000008267  2206  X   R 224 / 480 [xfs_io]
253,0   21        3     0.000010530  2206  X   R 224 / 256 [xfs_io]
253,0   21        4     0.000027022  2206  X   R 480 / 736 [xfs_io]
253,0   21        5     0.000028751  2206  X   R 480 / 512 [xfs_io]
253,0   21        6     0.000033323  2206  X   R 736 / 992 [xfs_io]
253,0   21        7     0.000035130  2206  X   R 736 / 768 [xfs_io]
253,0   21        8     0.000039146  2206  X   R 992 / 1248 [xfs_io]
253,0   21        9     0.000040734  2206  X   R 992 / 1024 [xfs_io]
253,0   21       10     0.000044694  2206  X   R 1248 / 1504 [xfs_io]
253,0   21       11     0.000046422  2206  X   R 1248 / 1280 [xfs_io]
253,0   21       12     0.000050376  2206  X   R 1504 / 1760 [xfs_io]
253,0   21       13     0.000051974  2206  X   R 1504 / 1536 [xfs_io]
253,0   21       14     0.000055881  2206  X   R 1760 / 2016 [xfs_io]
253,0   21       15     0.000057462  2206  X   R 1760 / 1792 [xfs_io]
253,0   21       16     0.000060999  2206  X   R 2016 / 2272 [xfs_io]
253,0   21       17     0.000062489  2206  X   R 2016 / 2048 [xfs_io]
253,0   21       18     0.000066133  2206  X   R 2272 / 2528 [xfs_io]
253,0   21       19     0.000067507  2206  X   R 2272 / 2304 [xfs_io]
253,0   21       20     0.000071136  2206  X   R 2528 / 2784 [xfs_io]
253,0   21       21     0.000072764  2206  X   R 2528 / 2560 [xfs_io]
253,0   21       22     0.000076185  2206  X   R 2784 / 3040 [xfs_io]
253,0   21       23     0.000077486  2206  X   R 2784 / 2816 [xfs_io]
253,0   21       24     0.000080885  2206  X   R 3040 / 3296 [xfs_io]
253,0   21       25     0.000082316  2206  X   R 3040 / 3072 [xfs_io]
253,0   21       26     0.000085788  2206  X   R 3296 / 3552 [xfs_io]
253,0   21       27     0.000087096  2206  X   R 3296 / 3328 [xfs_io]
253,0   21       28     0.000093469  2206  X   R 3552 / 3808 [xfs_io]
253,0   21       29     0.000095186  2206  X   R 3552 / 3584 [xfs_io]
253,0   21       30     0.000099228  2206  X   R 3808 / 4064 [xfs_io]
253,0   21       31     0.000101062  2206  X   R 3808 / 3840 [xfs_io]
253,0   21       32     0.000104956  2206  X   R 4064 / 4096 [xfs_io]
253,0   21       33     0.001138823     0  C   R 4096 + 200 [0]

after this revert:

253,0   18        1     0.000000000  4430  Q   R 224 + 3896 [xfs_io]
253,0   18        2     0.000018359  4430  X   R 224 / 256 [xfs_io]
253,0   18        3     0.000028898  4430  X   R 256 / 512 [xfs_io]
253,0   18        4     0.000033535  4430  X   R 512 / 768 [xfs_io]
253,0   18        5     0.000065684  4430  X   R 768 / 1024 [xfs_io]
253,0   18        6     0.000091695  4430  X   R 1024 / 1280 [xfs_io]
253,0   18        7     0.000098494  4430  X   R 1280 / 1536 [xfs_io]
253,0   18        8     0.000114069  4430  X   R 1536 / 1792 [xfs_io]
253,0   18        9     0.000129483  4430  X   R 1792 / 2048 [xfs_io]
253,0   18       10     0.000136759  4430  X   R 2048 / 2304 [xfs_io]
253,0   18       11     0.000152412  4430  X   R 2304 / 2560 [xfs_io]
253,0   18       12     0.000160758  4430  X   R 2560 / 2816 [xfs_io]
253,0   18       13     0.000183385  4430  X   R 2816 / 3072 [xfs_io]
253,0   18       14     0.000190797  4430  X   R 3072 / 3328 [xfs_io]
253,0   18       15     0.000197667  4430  X   R 3328 / 3584 [xfs_io]
253,0   18       16     0.000218751  4430  X   R 3584 / 3840 [xfs_io]
253,0   18       17     0.000226005  4430  X   R 3840 / 4096 [xfs_io]
253,0   18       18     0.000250404  4430  Q   R 4120 + 176 [xfs_io]
253,0   18       19     0.000847708     0  C   R 4096 + 24 [0]
253,0   18       20     0.000855783     0  C   R 4120 + 176 [0]

Fixes: effd58c95f27774 ("dm: always call blk_queue_split() in dm_process_bio()")
Cc: stable@vger.kernel.org
Reported-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Tested-by: Barry Marson &lt;bmarson@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
