[PATCH] doc: updated release notes for r2.1

[PATCH] doc: updated release notes for r2.1

[John McNamara]

Please review the DPDK 2.1 release notes for omissions or errors.

John McNamara (1):
  doc: updated release notes for r2.1

 doc/guides/rel_notes/release_2_1.rst | 980 ++++++++++++++++++++++++++++++++++-
 1 file changed, 970 insertions(+), 10 deletions(-)

-- 
1.8.1.4

[PATCH] doc: updated release notes for r2.1

[John McNamara]

Added release notes for the DPDK R2.1 release.

Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
 doc/guides/rel_notes/release_2_1.rst | 980 ++++++++++++++++++++++++++++++++++-
 1 file changed, 970 insertions(+), 10 deletions(-)

diff --git a/doc/guides/rel_notes/release_2_1.rst b/doc/guides/rel_notes/release_2_1.rst
index c39418c..2bcc719 100644
--- a/doc/guides/rel_notes/release_2_1.rst
+++ b/doc/guides/rel_notes/release_2_1.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-    Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+    Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
     All rights reserved.
 
     Redistribution and use in source and binary forms, with or without
@@ -36,34 +36,994 @@ DPDK Release 2.1
 New Features
 ------------
 
-*   TODO.
+* **Enabled cloning of indirect mbufs.**
+
+  This feature removes a limitation of ``rte_pktmbuf_attach()`` which
+  generated the warning: "mbuf we're attaching to must be direct".
+
+  Now, when attaching to an indirect mbuf it is possible to:
+
+   * Copy all relevant fields (address, length, offload, ...) as before.
+
+   * Get the pointer to the mbuf that embeds the data buffer (direct mbuf),
+     and increase the reference counter.
+
+   When detaching the mbuf, we can now retrieve this direct mbuf as the
+   pointer is determined from the buffer address.
+
+
+* **Extended packet type support.**
+
+  In previous releases mbuf packet types were indicated by 6 bits in the
+  ``ol_flags``. This was not enough for some supported NICs. For example i40e
+  hardware can recognize more than 150 packet types. Not being able to
+  identify these additional packet types limits access to hardware offload
+  capabilities
+
+  So an extended "unified" packet type was added to support all possible
+  PMDs. The 16 bit packet_type in the mbuf structure was changed to 32 bits
+  and used for this purpose.
+
+  To avoid breaking ABI compatibility, the code changes this feature are
+  enclosed in a ``RTE_NEXT_ABI`` ifdef. This is enabled by default but can be
+  turned off for ABI compatibility with DPDK R2.0.
+
+
+* **Reworked memzone to be allocated by malloc and also support freeing.**
+
+  In the memory hierarchy, memsegs are groups of physically contiguous
+  hugepages, memzones are slices of memsegs, and malloc slices memzones
+  into smaller memory chunks.
+
+  This feature modifies ``malloc()`` so it partitions memsegs instead of
+  memzones. Now  memzones allocate their memory from the malloc heap.
+
+  Backward compatibility with API and ABI are maintained.
+
+  This also memzones, and any other structure based on memzones, for example
+  mempools, to be freed. Currently only the API from freeing memzones is
+  supported.
+
+
+* **Interrupt mode PMD.**
+
+  This feature introduces a low-latency one-shot RX interrupt into DPDK. It
+  also adds a polling and interrupt mode switch control example.
+
+  DPDK userspace interrupt notification and handling mechanism is based on
+  UIO/VFIO with the following limitations:
+
+  * Per queue RX interrupt events are only allowed in VFIO which supports
+    multiple MSI-X vectors.
+  * In UIO, the RX interrupt shares the same vector with other
+    interrupts. When the RX interrupt and LSC interrupt are both enabled, only
+    the former is available.
+  * RX interrupt is only implemented for the linuxapp target.
+  * The feature is only currently enabled for tow PMDs: ixgbe and igb.
+
+
+* **Packet Framework enhancements.**
+
+  Several enhancements were made to the Packet Framework:
+
+  * A new configuration file syntax has been introduced for IP pipeline
+    applications. Parsing of the configuration file is changed.
+  * Implementation of the IP pipeline application is modified to make it more
+    structured and user friendly.
+  * Implementation of the command line interface (CLI) for each pipeline type
+    has been moved to the separate compilation unit. Syntax of pipeline CLI
+    commands has been changed.
+  * Initialization of IP pipeline is modified to match the new parameters
+    structure.
+  * New implementation of pass-through pipeline, firewall pipeline, routing
+    pipeline, and flow classification has been added.
+  * Master pipeline with CLI interface has been added.
+  * Added extended documentation of the IP Pipeline.
+
+
+* **Added API for IEEE1588 timestamping.**
+
+  This feature adds an ethdev API to enable, disable and read IEEE1588/802.1AS
+  PTP timestamps from devices that support it. The following functions were
+  added:
+
+  * ``rte_eth_timesync_enable()``
+  * ``rte_eth_timesync_disable()``
+  * ``rte_eth_timesync_read_rx_timestamp()``
+  * ``rte_eth_timesync_read_tx_timestamp()``
+
+  The "ieee1588" forwarding mode in testpmd was also refactored to demonstrate
+  the new API.
+
+
+* **Added multicast address filtering.**
+
+  Added multicast address filtering via a new ethdev function
+  ``set_mc_addr_list()``.
+
+  This overcomes a limitation in previous releases where the receipt of
+  multicast packets on a given port could only be enabled by invoking the
+  ``rte_eth_allmulticast_enable()`` function. This method did not work for VFs
+  in SR-IOV architectures when the host PF driver does not allow these
+  operation on VFs. In such cases, joined multicast addresses had to be added
+  individually to the set of multicast addresses that are filtered by the [VF]
+  port.
+
+
+* **Added Flow Director extensions.**
+
+  Several Flow Director extensions were added such as:
+
+  * Support for RSS and Flow Director hashes in vector RX.
+  * Added Flow Director for L2 payload.
+
+
+* **Added RSS hash key size query per port.**
+
+  This feature supports querying the RSS hash key size of each port. A new
+  field ``hash_key_size`` has been added in the ``rte_eth_dev_info`` struct
+  for storing hash key size in bytes.
+
+
+* **Added userspace ethtool support.**
+
+  Added userspace ethtool support to provide a familiar interface for
+  applications that manage devices via kernel-space ``ethtool_op`` and
+  ``net_device_op``.
+
+  The initial implementation focuses on operations that can be implemented
+  through existing ``netdev`` APIs. More operations will be supported in later
+  releases.
+
+
+* **Updated the ixgbe base driver.**
+
+  The ixgbe base driver was updated with several changes including the
+  following:
+
+  * Added a new 82599 device id.
+  * Added new X550 PHY ids.
+  * Added SFP+ dual-speed support.
+  * Added wait helper for X550 IOSF accesses.
+  * Added X550em features.
+  * Added X557 PHY LEDs support.
+  * Commands for flow director.
+  * Issue firmware command when resetting X550em.
+
+  See the git log for full details of the ixgbe/base changes.
+
+
+* **Added additional hotplug support.**
+
+  Port hotplug support was added to the following PMDs:
+
+  * e1000/igb.
+  * ixgbe.
+  * i40e.
+  * fm10k.
+  * Ring.
+  * Bonding.
+  * Virtio.
+
+  Port hotplug support was added to BSD.
+
+
+* **Added ixgbe LRO support.**
+
+  Added LRO support for x540 and 82599 devices.
+
+
+* **Added extended statistics for ixgbe.**
+
+  Implemented ``xstats_get()`` and ``xstats_reset()`` in dev_ops for
+  ixgbe to expose detailed error statistics to DPDK applications.
+
+  These will be implemented for other PMDs in later releases.
+
+
+* **Added proc_info application.**
+
+  Created a new ``proc_info`` application, by refactoring the existing
+  ``dump_cfg`` application, to demonstrate the usage of retrieving statistics,
+  and the new extended statistics (see above), for DPDK interfaces.
+
+
+* **Updated the i40e base driver.**
+
+  The i40e base driver was updated with several changes including the
+  following:
+
+  *  Support for building both PF and VF driver together.
+  *  Support for CEE DCBX on recent firmware versions.
+  *  Replacement of ``i40e_debug_read_register()``.
+  *  Rework of ``i40e_hmc_get_object_va``.
+  *  Update of shadow RAM read/write functions.
+  *  Enhancement of polling NVM semaphore.
+  *  Enhancements on adminq init and sending asq command.
+  *  Update of get/set LED functions.
+  *  Addition of AOC phy types to case statement in get_media_type.
+  *  Support for iSCSI capability.
+  *  Setting of FLAG_RD when sending driver version to FW.
+
+  See the git log for full details of the i40e/base changes.
+
+
+* **Added support for port mirroring in i40e.**
+
+  Enabled mirror functionality in the i40e driver.
+
+
+* **Added support for i40e double VLAN, QinQ, stripping and insertion.**
+
+  Added support to the i40e driver for offloading double VLAN (QinQ) tags to
+  the mbuf header, and inserting double vlan tags by hardware to the packets
+  to be transmitted.  Added a new field ``vlan_tci_outer`` in the ``rte_mbuf``
+  struct, and new flags in ``ol_flags`` to support this feature.
+
+
+
+* **Added fm10k promiscuous mode support.**
+
+  Added support for promiscuous/allmulticast enable and disable in the fm10k PF
+  function. VF is not supported yet.
+
+
+* **Added fm10k jumbo frame support.**
+
+  Added support for jumbo frame less than 15K in both VF and PF functions in the
+  fm10k pmd.
+
+
+* **Added fm10k mac vlan filtering support.**
+
+  Added support for the fm10k MAC filter, only available in PF. Updated the
+  VLAN filter to add/delete one static entry in the MAC table for each
+  combination of VLAN and MAC address.
+
+
+* **Added support for the Broadcom bnx2x driver.**
+
+  Added support for the Broadcom NetXtreme II bnx2x driver.
+
+
+* **Added support for the Chelsio CXGBE driver.**
+
+  Added support for the CXGBE Poll Mode Driver for the Chelsio Terminator 5
+  series of 10G/40G adapters.
+
+
+* **Enabled VMXNET3 vlan filtering.**
+
+  Added support for the VLAN filter functionality of the VMXNET3 interface.
+
+
+* **Added support for vhost live migration.**
+
+  Added support to allow live migration of vhost. Without this feature, qemu
+  will report the following error: "migrate: Migration disabled: vhost lacks
+  VHOST_F_LOG_ALL feature".
+
+
+* **Added support for pcap jumbo frames.**
+
+  Extended the PCAP PMD to support jumbo frames for RX and TX.
+
+
+* **Added support for the TILE-Gx architecture.**
+
+  Added support for the EZchip TILE-Gx family of SoCs.
+
+
+* **Added hardware memory transactions/lock elision for x86.**
+
+  Added the use of hardware memory transactions (HTM) on fast-path for rwlock
+  and spinlock (a.k.a. lock elision). The methods are implemented for x86
+  using Restricted Transactional Memory instructions (Intel(r) Transactional
+  Synchronization Extensions). The implementation fall-backs to the normal
+  rwlock if HTM is not available or memory transactions fail. This is not a
+  replacement for all rwlock usages since not all critical sections protected
+  by locks are friendly to HTM. For example, an attempt to perform a HW I/O
+  operation inside a hardware memory transaction always aborts the transaction
+  since the CPU is not able to roll-back should the transaction
+  fail. Therefore, hardware transactional locks are not advised to be used
+  around ``rte_eth_rx_burst()`` and ``rte_eth_tx_burst()`` calls.
+
+
+* **Updated Jenkins Hash function**
+
+  Updated the version of the Jenkins Hash (jhash) function used in DPDK from
+  the 1996 version to the 2006 version. This gives up to 35% better
+  performance, compared to the original one.
+
+  Note, the hashes generated by the updated version differ from the hashes
+  generated by the previous version.
+
+
+* **Added software implementation of the Toeplitz RSS hash**
+
+  Added a software implementation of the Toeplitz hash function used by RSS. It
+  can be used either for packet distribution on a single queue NIC or for
+  simulating RSS computation on a specific NIC (for example after GRE header
+  de-encapsulation).
+
+
+* **Replaced the existing hash library with a Cuckoo hash implementation.**
+
+  Replaced the existing hash library with another approach, using the Cuckoo
+  Hash method to resolve collisions (open addressing). This method pushes
+  items from a full bucket when a new entry must be added to it, storing the
+  evicted entry in an alternative location, using a secondary hash function.
+
+  This gives the user the ability to store more entries when a bucket is full,
+  in comparison with the previous implementation.
+
+  The API has not been changed, although new fields have been added in the
+  ``rte_hash`` structure, which has been changed to internal use only.
+
+  The main change when creating a new table is that the number of entries per
+  bucket is now fixed, so its parameter is ignored now (it is still there to
+  maintain the same parameters structure).
+
+  Also, the maximum burst size in lookup_burst function hash been increased to
+  64, to improve performance.
+
+
+* **Optimized KNI RX burst size computation.**
+
+  Optimized KNI RX burst size computation by avoiding checking how many
+  entries are in ``kni->rx_q`` prior to actually pulling them from the fifo.
+
+
+* **Added KNI multicast.**
+
+  Enabled adding multicast addresses to KNI interfaces by adding an empty
+  callback for ``set_rx_mode`` (typically used for setting up hardware) so
+  that the ioctl succeeds. This is the same thing as the Linux tap interface
+  does.
+
+
+* **Added cmdline polling mode.**
+
+  Added the ability to process console input in the same thread as packet
+  processing by using the ``poll()`` function.
+
+* **Added VXLAN Tunnel End point sample application.**
+
+  Added a Tunnel End point (TEP) sample application that simulates a VXLAN
+  Tunnel Endpoint (VTEP) termination in DPDK. It is used to demonstrate the
+  offload and filtering capabilities of Intel XL710 10/40 GbE NICsfor VXLAN
+  packets.
+
+
+* **Enabled combining of the ``-m`` and ``--no-huge`` EAL options.**
+
+  Added option to allow combining of the ``-m`` and ``--no-huge`` EAL command
+  line options.
+
+  This allows user application to run as non-root but with higher memory
+  allocations, and removes a constraint on ``--no-huge`` mode being limited to
+  64M.
+
 
 
 Resolved Issues
 ---------------
 
-*   TODO.
+* **acl: Fix ambiguity between test rules.**
+
+  Some test rules had equal priority for the same category. That could cause
+  an ambiguity in building the trie and test results.
+
+
+* **acl: Fix invalid rule wildness calculation for bitmask field type.**
+
+
+* **acl: Fix matching rule.**
+
+
+* **acl: Fix unneeded trie splitting for subset of rules.**
+
+  When rebuilding a trie for limited rule-set, don't try to split the rule-set
+  even further.
+
+
+* **app/testpmd: Fix crash when port id out of bound.**
+
+  Fixed issues in testpmd where using a port greater than 32 would cause a seg
+  fault.
+
+  Fixes: edab33b1c01d ("app/testpmd: support port hotplug")
+
+
+* **app/testpmd: Fix reply to a multicast ICMP request.**
+
+  Set the IP source and destination addresses in the IP header of the ICMP
+  reply.
+
+
+* **app/testpmd: fix MAC address in ARP reply.**
+
+  Fixed issue where in the ``icmpecho`` forwarding mode, ARP replies from
+  testpmd contain invalid zero-filled MAC addresses.
+
+  Fixes: 31db4d38de72 ("net: change arp header struct declaration")
+
+
+* **app/testpmd: fix default flow control values.**
+
+  Fixes: 422a20a4e62d ("app/testpmd: fix uninitialized flow control variables")
+
+
+* **bonding: Fix crash when stopping inactive slave.**
+
+
+* **bonding: Fix device initialization error handling.**
+
+
+* **bonding: Fix initial link status of slave.**
+
+  On Fortville NIC, link status change interrupt callback was not executed
+  when slave in bonding was (re-)started.
+
+
+* **bonding: Fix socket id for LACP slave.**
+
+  Fixes: 46fb43683679 ("bond: add mode 4")
+
+
+* **bonding: Fix device initialization error handling.**
+
+
+* **cmdline: Fix small memory leak.**
+
+  A function in ``cmdline.c`` had a return that did not free the buf properly.
+
+
+* **config: Enable same drivers options for Linux and BSD.**
+
+  Enabled vector ixgbe and i40e bulk alloc for BSD as it is already done for
+  Linux.
+
+  Fixes: 304caba12643 ("config: fix bsd options")
+  Fixes: 0ff3324da2eb ("ixgbe: rework vector pmd following mbuf changes")
+
+
+* **devargs: Fix crash on failure.**
+
+  This problem occurred when passing an invalid PCI id to the blacklist API in
+  devargs.
+
+
+* **e1000/i40e: Fix descriptor done flag with odd address.**
+
+
+* **e1000/igb: fix ieee1588 timestamping initialization.**
+
+  Fixed issue with e1000 ieee1588 timestamp initialization. On initialization
+  the IEEE1588 functions read the system time to set their timestamp. However,
+  on some 1G NICs, for example, i350, system time is disabled by default and
+  the IEEE1588 timestamp was always 0.
+
+
+* **eal/Linux: Fix irq handling with igb_uio.**
+
+  Fixed an issue where the the introduction of ``uio_pci_generic`` broke
+  interrupt handling with igb_uio.
+
+  Fixes: c112df6875a5 ("eal/Linux: toggle interrupt for uio_pci_generic")
+
+
+* **eal/bsd: Fix inappropriate header guards.**
+
+
+* **eal/bsd: Fix virtio on FreeBSD.**
+
+  Closing the ``/dev/io`` fd caused a SIGBUS in inb/outb instructions as the
+  process lost the IOPL privileges once the fd is closed.
+
+  Fixes: 8a312224bcde ("eal/bsd: fix fd leak")
+
+
+* **eal/linux: Fix comments on vfio MSI.**
+
+
+* **eal/linux: Fix numa node detection.**
+
+
+* **eal/linux: Fix socket value for undetermined numa node.**
+
+  Sets zero as the default value of pci device numa_node if the socket could
+  not be determined. This provides the same default value as FreeBSD which has
+  no NUMA support, and makes the return value of ``rte_eth_dev_socket_id()``
+  be consistent with the API description.
+
+
+* **eal/ppc: Fix cpu cycle count for little endian.**
+
+  On IBM POWER8 PPC64 little endian architecture, the definition of tsc union
+  will be different. This fix enables the right output from ``rte_rdtsc()``.
+
+
+* **ethdev: Fix check of threshold for TX freeing.**
+
+  Fixed issue where the parameter to ``tx_free_thresh`` was not consistent
+  between the drivers.
+
+
+* **ethdev: Fix crash if malloc of user callback fails.**
+
+  If ``rte_zmalloc()`` failed in ``rte_eth_dev_callback_register`` then the
+  NULL pointer would be dereferenced.
+
+
+* **ethdev: Fix illegal port access.**
+
+  To obtain a detachable flag, ``pci_drv`` is accessed in
+  ``rte_eth_dev_is_detachable()``. However ``pci_drv`` is only valid if port
+  is enabled. Fixed by checking ``rte_eth_dev_is_valid_port()`` first.
+
+
+* **ethdev: Make tables const.**
+
+
+* **ethdev: Rename and extend the mirror type.**
+
+
+* **examples/distributor: Fix debug macro.**
+
+  The macro to turn on additional debug output when the app was compiled with
+  ``-DDEBUG`` was broken.
+
+  Fixes: 07db4a975094 ("examples/distributor: new sample app")
+
+
+* **examples/kni: Fix crash on exit.**
+
+
+* **examples/vhost: Fix build with debug enabled.**
+
+  Fixes: 72ec8d77ac68 ("examples/vhost: rework duplicated code")
+
+
+* **fm10k: Fix RETA table initialization.**
+
+  The fm10k driver has 128 RETA entries in 32 registers, but it only
+  initialized the first 32 when doing multiple RX queue configurations. This
+  fix initializes all 128 entries.
+
+
+* **fm10k: Fix RX buffer size.**
+
+
+* **fm10k: Fix TX multi-segment frame.**
+
+
+* **fm10k: Fix TX queue cleaning after start error.**
+
+
+* **fm10k: Fix Tx queue cleaning after start error.**
+
+
+* **fm10k: Fix default mac/vlan in switch.**
+
+
+* **fm10k: Fix interrupt fault handling.**
+
+
+* **fm10k: Fix jumbo frame issue.**
+
+
+* **fm10k: Fix mac/vlan filtering.**
+
+
+* **fm10k: Fix maximum VF number.**
+
+
+* **fm10k: Fix maximum queue number for VF.**
+
+  Both PF and VF shared code in function ``fm10k_stats_get()``. The function
+  worked with PF, but had problems with VF since it has less queues than PF.
+
+  Fixes: a6061d9e7075 ("fm10k: register PF driver")
+
+
+* **fm10k: Fix queue disabling.**
+
+
+* **fm10k: Fix switch synchronization.**
+
+
+* **i40e/base: Fix error handling of NVM state update.**
+
+
+* **i40e/base: Fix hardware port number for pass-through.**
+
+
+* **i40e/base: Rework virtual address retrieval for lan queue.**
+
+
+* **i40e/base: Update LED blinking.**
+
+
+* **i40e/base: Workaround for PHY type with firmware < 4.4.**
+
+
+* **i40e: Disable setting of PHY configuration.**
+
+
+* **i40e: Fix SCTP flow director.**
+
+
+* **i40e: Fix check of descriptor done flag.**
+
+  Fixes: 4861cde46116 ("i40e: new poll mode driver")
+  Fixes: 05999aab4ca6 ("i40e: add or delete flow director")
+
+
+* **i40e: Fix condition to get VMDQ info.**
+
+
+* **i40e: Fix registers access from big endian CPU.**
+
+
+* **i40evf: Clear command when error occurs.**
+
+
+* **i40evf: Fix RSS with less RX queues than TX queues.**
+
+
+* **i40evf: Fix crash when setup TX queues.**
+
+
+* **i40evf: Fix jumbo frame support.**
+
+
+* **i40evf: Fix offload capability flags.**
+
+  Added checksum offload capability flags which have already been supported
+  for a long time.
+
+
+* **ivshmem: Fix crash in corner case.**
+
+  Fixed issues where depending on the configured segments it was possible to
+  hit a segmentation fault as a result of decrementing an unsigned index with
+  value 0.
+
+
+  Fixes: 40b966a211ab ("ivshmem: library changes for mmaping using ivshmem")
+
+
+* **ixgbe/base: Fix SFP probing.**
+
+
+* **ixgbe/base: Fix TX pending clearing.**
+
+
+* **ixgbe/base: Fix X550 CS4227 address.**
+
+
+* **ixgbe/base: Fix X550 PCIe master disabling.**
+
+
+* **ixgbe/base: Fix X550 check.**
+
+
+* **ixgbe/base: Fix X550 init early return.**
+
+
+* **ixgbe/base: Fix X550 link speed.**
+
+
+* **ixgbe/base: Fix X550em CS4227 speed mode.**
+
+
+* **ixgbe/base: Fix X550em SFP+ link stability.**
+
+
+* **ixgbe/base: Fix X550em UniPHY link configuration.**
+
+
+* **ixgbe/base: Fix X550em flow control for KR backplane.**
+
+
+* **ixgbe/base: Fix X550em flow control to be KR only.**
+
+
+* **ixgbe/base: Fix X550em link setup without SFP.**
+
+
+* **ixgbe/base: Fix X550em mux after MAC reset.**
+
+  Fixes: d2e72774e58c ("ixgbe/base: support X550")
+
+
+* **ixgbe/base: Fix bus type overwrite.**
+
+
+* **ixgbe/base: Fix init handling of X550em link down.**
+
+
+* **ixgbe/base: Fix lan id before first i2c access.**
+
+
+* **ixgbe/base: Fix mac type checks.**
+
+
+* **ixgbe/base: Fix tunneled UDP and TCP frames in flow director.**
+
+
+* **ixgbe: Check mbuf refcnt when clearing a ring.**
+
+  The function to clear the TX ring when a port was being closed, e.g. on exit
+  in testpmd, was not checking the mbuf refcnt before freeing it. Since the
+  function in the vector driver to clear the ring after TX does not setting
+  the pointer to NULL post-free, this caused crashes if mbuf debugging was
+  turned on.
+
+
+* **ixgbe: Fix RX with buffer address not word aligned.**
+
+  Niantic HW expects the Header Buffer Address in the RXD must be word
+  aligned.
+
+
+* **ixgbe: Fix RX with buffer address not word aligned.**
+
+
+* **ixgbe: Fix Rx queue reset.**
+
+  Fix to reset vector related RX queue fields to their initial values.
+
+  Fixes: c95584dc2b18 ("ixgbe: new vectorized functions for Rx/Tx")
+
+
+* **ixgbe: Fix TSO in IPv6.**
+
+  When TSO was used with IPv6, the generated frames were incorrect. The L4
+  frame was OK, but the length field of IPv6 header was not populated
+  correctly.
+
+
+* **ixgbe: Fix X550 flow director check.**
+
+
+* **ixgbe: Fix check for split packets.**
+
+  The check for split packets to be reassembled in the vector ixgbe PMD was
+  incorrectly only checking the first 16 elements of the array instead of
+  all 32.
+
+  Fixes: cf4b4708a88a ("ixgbe: improve slow-path perf with vector scattered Rx")
+
+
+* **ixgbe: Fix data access on big endian cpu.**
+
+
+* **ixgbe: Fix flow director flexbytes offset.**
+
+
+  Fixes: d54a9888267c ("ixgbe: support flexpayload configuration of flow director")
+
+
+* **ixgbe: Fix number of segments with vector scattered Rx.**
+
+  Fixes: cf4b4708a88a (ixgbe: improve slow-path perf with vector scattered Rx)
+
+
+* **ixgbe: Fix offload config option name.**
+
+  The RX_OLFLAGS option was renamed from DISABLE to ENABLE in the driver code
+  and Linux config. It is now renamed also in the BSD config and
+  documentation.
+
+  Fixes: 359f106a69a9 ("ixgbe: prefer enabling olflags rather than not disabling")
+
+
+* **ixgbe: Fix release queue mbufs.**
+
+  The calculations of what mbufs were valid in the RX and TX queues were
+  incorrect when freeing the mbufs for the vector PMD. This led to crashes due
+  to invalid reference counts when mbuf debugging was turned on, and possibly
+  other more subtle problems (such as mbufs being freed when in use) in other
+  cases.
+
+
+  Fixes: c95584dc2b18 ("ixgbe: new vectorized functions for Rx/Tx")
+
+
+* **ixgbe: Move PMD specific fields out of base driver.**
+
+  Move ``rx_bulk_alloc_allowed`` and ``rx_vec_allowed`` from ``ixgbe_hw`` to
+  ``ixgbe_adapter``.
+
+  Fixes: 01fa1d6215fa ("ixgbe: unify Rx setup")
+
+
+* **ixgbe: Rename TX queue release function.**
+
+
+* **ixgbevf: Fix RX function selection.**
+
+  The logic to select ixgbe the VF RX function is different than the PF.
+
+
+* **ixgbevf: Fix link status for PF up/down events.**
+
+
+* **kni: Fix RX loop limit.**
+
+  Loop processing packets dequeued from rx_q was using the number of packets
+  requested, not how many it actually received.
+
+
+* **kni: Fix ioctl in containers, like Docker.**
+
+
+* **kni: Fix multicast ioctl handling.**
+
+
+* **log: Fix crash after log_history dump.**
+
+
+* **lpm: Fix big endian support.**
+
+
+* **lpm: Fix depth small entry add.**
+
+
+* **mbuf: Fix cloning with private mbuf data.**
+
+  Added a new ``priv_size`` field in mbuf structure that should be initialized
+  at mbuf pool creation. This field contains the size of the application
+  private data in mbufs.
+
+  Introduced new static inline functions ``rte_mbuf_from_indirect()`` and
+  ``rte_mbuf_to_baddr()`` to replace the existing macros, which take the
+  private size into account when attaching and detaching mbufs.
+
+
+* **mbuf: Fix data room size calculation in pool init.**
+
+  Deduct the mbuf data room size from ``mempool->elt_size`` and ``priv_size``,
+  instead of using an hardcoded value that is not related to the real buffer
+  size.
+
+  To use ``rte_pktmbuf_pool_init()``, the user can either:
+
+  * Give a NULL parameter to rte_pktmbuf_pool_init(): in this case, the
+    private size is assumed to be 0, and the room size is ``mp->elt_size`` -
+    ``sizeof(struct rte_mbuf)``.
+  * Give the ``rte_pktmbuf_pool_private`` filled with appropriate
+    data_room_size and priv_size values.
+
+
+* **mbuf: Fix init when private size is not zero.**
+
+  Allow the user to use the default ``rte_pktmbuf_init()`` function even if
+  the mbuf private size is not 0.
+
+
+* **mempool: Add structure for object headers.**
+
+  Each object stored in mempools are prefixed by a header, allowing for
+  instance to retrieve the mempool pointer from the object. When debug is
+  enabled, a cookie is also added in this header that helps to detect
+  corruptions and double-frees.
+
+  Introduced a structure that materializes the content of this header,
+  and will simplify future patches adding things in this header.
+
+
+* **mempool: Fix pages computation to determine number of objects.**
+
+
+* **mempool: Fix returned value after counting objects.**
+
+  Fixes: 148f963fb532 ("xen: core library changes")
+
+
+* **mlx4: Avoid requesting TX completion events to improve performance.**
+
+  Instead of requesting a completion event for each TX burst, request it on a
+  fixed schedule once every MLX4_PMD_TX_PER_COMP_REQ (currently 64) packets to
+  improve performance.
+
+
+* **mlx4: Fix possible crash on scattered mbuf allocation failure.**
+
+  Fixes issue where failing to allocate a segment, ``mlx4_rx_burst_sp()``
+  could call ``rte_pktmbuf_free()`` on an incomplete scattered mbuf whose next
+  pointer in the last segment is not set.
+
+
+* **mlx4: Fix support for multiple vlan filters.**
+
+  This fixes the "Multiple RX VLAN filters can be configured, but only the
+  first one works" bug.
+
+
+* **pcap: Fix storage of name and type in queues.**
+
+  pcap_rx_queue/pcap_tx_queue should store it's own copy of name/type values,
+  not the pointer to temporary allocated space.
+
+
+* **pci: Fix memory leaks and needless increment of map address.**
+
+
+* **pci: Fix uio mapping differences between linux and bsd.**
+
+
+* **port: Fix unaligned access to metadata.**
+
+  Fix RTE_MBUF_METADATA macros to allow for unaligned accesses to meta-data
+  fields.
+
+
+* **ring: Fix return of new port id on creation.**
+
+
+* **timer: Fix race condition.**
+
+  Eliminate problematic race condition in ``rte_timer_manage()`` that can lead
+  to corruption of per-lcore pending-lists (implemented as skip-lists).
+
+
+* **vfio: Fix overflow of BAR region offset and size.**
+
+  Fixes: 90a1633b2347 ("eal/Linux: allow to map BARs with MSI-X tables")
+
+
+* **vhost: Fix enqueue/dequeue to handle chained vring descriptors.**
+
+
+* **vhost: Fix race for connection fd.**
+
+
+* **vhost: Fix virtio freeze due to missed interrupt.**
+
+
+* **virtio: Fix crash if CQ is not negotiated.**
+
+  Fix NULL dereference if virtio control queue is not negotiated.
+
+
+* **virtio: Fix ring size negotiation.**
+
+  Negotiate the virtio ring size. The host may allow for very large rings but
+  application may only want a smaller ring. Conversely, if the number of
+  descriptors requested exceeds the virtio host queue size, then just silently
+  use the smaller host size.
+
+  This fixes issues with virtio in non-QEMU environments. For example Google
+  Compute Engine allows up to 16K elements in ring.
+
+
+* **vmxnet3: Fix link state handling.**
 
 
 Known Issues
 ------------
 
-*   TODO.
+* When running the ``vmdq`` sample or ``vhost`` sample applications with the
+  Intel(R) XL710 (i40e) NIC, the configuration option
+  ``CONFIG_RTE_MAX_QUEUES_PER_PORT`` should be increased from 256 to 1024.
 
 
-API Changes
------------
-
-*   TODO.
+* VM power manager may not work on systems with more than 64 cores.
 
 
 API Changes
 -----------
 
-*   TODO.
+* The order that user supplied RX and TX callbacks are called in has been
+  changed to the order that they were added (fifo) in line with end-user
+  expectations. The previous calling order was the reverse of this (lifo) and
+  was counter intuitive for users. The actual API is unchanged.
 
 
 ABI Changes
 -----------
 
-*   TODO.
+* The ``rte_hash`` structure has been changed to internal use only.
-- 
1.8.1.4

Re: [PATCH] doc: updated release notes for r2.1

[Iremonger, Bernard]

Hi John,

<snip>

> +
> +* **Added additional hotplug support.**
> +
> +  Port hotplug support was added to the following PMDs:
> +
> +  * e1000/igb.
> +  * ixgbe.
> +  * i40e.
> +  * fm10k.
> +  * Ring.
> +  * Bonding.
> +  * Virtio.

ring, bonding and virtio should probably be all lowercase.

> +
> +  Port hotplug support was added to BSD.
> +
> +
<snip>

Regards,

Bernard.

Re: [PATCH] doc: updated release notes for r2.1

[Thomas Monjalon]

2015-08-13 13:02, Iremonger, Bernard:
> > +  Port hotplug support was added to the following PMDs:
> > +
> > +  * e1000/igb.
> > +  * ixgbe.
> > +  * i40e.
> > +  * fm10k.
> > +  * Ring.
> > +  * Bonding.
> > +  * Virtio.
> 
> ring, bonding and virtio should probably be all lowercase.

Applied with few small fixes, thanks for the big work, John

Re: [PATCH] doc: updated release notes for r2.1

[Srikanth Akula]

Hello ,

I am trying to write an application based on DPDK port hotplug feature . My
requirement is to get an event when a new PCI devices gets added to the
system on the go.

Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers ) that i
can use to get notifications when a new device gets added . I know the
alternatives such as inotify etc .

But i am more interested to get equivalent support in dpdk drivers .

Please let me know .

Srikanth



On Thu, Aug 13, 2015 at 6:02 AM, Iremonger, Bernard <
bernard.iremonger@intel.com> wrote:

> Hi John,
>
> <snip>
>
> > +
> > +* **Added additional hotplug support.**
> > +
> > +  Port hotplug support was added to the following PMDs:
> > +
> > +  * e1000/igb.
> > +  * ixgbe.
> > +  * i40e.
> > +  * fm10k.
> > +  * Ring.
> > +  * Bonding.
> > +  * Virtio.
>
> ring, bonding and virtio should probably be all lowercase.
>
> > +
> > +  Port hotplug support was added to BSD.
> > +
> > +
> <snip>
>
> Regards,
>
> Bernard.
>
>

Hotplug

[Stephen Hemminger]

On Mon, 28 Sep 2015 21:12:50 -0700
Srikanth Akula <srikanth044@gmail.com> wrote:

> Hello ,
> 
> I am trying to write an application based on DPDK port hotplug feature . My
> requirement is to get an event when a new PCI devices gets added to the
> system on the go.
> 
> Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers ) that i
> can use to get notifications when a new device gets added . I know the
> alternatives such as inotify etc .
> 
> But i am more interested to get equivalent support in dpdk drivers .
> 
> Please let me know .
> 
> Srikanth

Implementing hotplug requires integration with the OS more than any additional
DPDK support. What the Brocade vRouter does is leverage the existing Linux
udev infrastructure to send a message to the router application which then
initializes and sets up the new hardware. Most of the DPDK changes are upstream
already and involve being able to dynamically add ports on the fly.

Re: Hotplug

[Srikanth Akula]

Thank you for the inputs .

I was able to solve the problem of device notification from my control
plane.

I would like to know if we have any way to know if the PCI device is
already attached before we try to attach it ( if the device is already
attached pci probe will result an error ) .
But i want to know before hand to verify if the device is already attached
or not .

I came with small API which can be used to check if the pci device is
already bound to any driver .

+int
+rte_eal_pci_is_attached(const char *devargs)
+{
+        struct rte_pci_device *dev = NULL;
+        struct rte_pci_addr addr;
+        memset(&addr,0,sizeof(struct rte_pci_addr));
+
+        if (eal_parse_pci_DomBDF(devargs, &addr) == 0)
+          {
+            TAILQ_FOREACH(dev, &pci_device_list, next) {
+            if (!rte_eal_compare_pci_addr(&dev->addr, &addr))
+              {
+                if (dev->driver)
+                  {
+                    /*pci_dump_one_device(stdout,dev);*/
+                    RTE_LOG(WARNING, EAL, "Requested device " PCI_PRI_FMT
+                      " cannot be used\n", dev->addr.domain, dev->addr.bus,
+                    dev->addr.devid, dev->addr.function);
+                   return -1;
+                 }
+              }
+           }
+         }
+   return 0;
+}
+

Could you please let me know if it is good to have such APIs

Regards,
_Srikanth_


On Mon, Sep 28, 2015 at 9:44 PM, Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On Mon, 28 Sep 2015 21:12:50 -0700
> Srikanth Akula <srikanth044@gmail.com> wrote:
>
> > Hello ,
> >
> > I am trying to write an application based on DPDK port hotplug feature .
> My
> > requirement is to get an event when a new PCI devices gets added to the
> > system on the go.
> >
> > Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers ) that
> i
> > can use to get notifications when a new device gets added . I know the
> > alternatives such as inotify etc .
> >
> > But i am more interested to get equivalent support in dpdk drivers .
> >
> > Please let me know .
> >
> > Srikanth
>
> Implementing hotplug requires integration with the OS more than any
> additional
> DPDK support. What the Brocade vRouter does is leverage the existing Linux
> udev infrastructure to send a message to the router application which then
> initializes and sets up the new hardware. Most of the DPDK changes are
> upstream
> already and involve being able to dynamically add ports on the fly.
>
>

Re: Hotplug

[Tetsuya Mukawa]

On 2015/10/07 22:16, Srikanth Akula wrote:
> Thank you for the inputs .
>
> I was able to solve the problem of device notification from my control
> plane.
>
> I would like to know if we have any way to know if the PCI device is
> already attached before we try to attach it ( if the device is already
> attached pci probe will result an error ) .
> But i want to know before hand to verify if the device is already attached
> or not .

Hi  Srikanth,

I guess below API may help you.
(Unfortunately, I am out of office now, so I haven't checked it, but I
guess it works.)

 - struct rte_eth_dev *rte_eth_dev_allocated(const char *name)

If none NULL value is returned, a device has been already attached.
If you want to check a physical NIC, above 'name' parameter will be like
below.

    snprintf(name, size, "%d:%d.%d",
                        pci_dev->addr.bus, pci_dev->addr.devid,
                        pci_dev->addr.function);

Thanks,
Tetsuya

>
> I came with small API which can be used to check if the pci device is
> already bound to any driver .
>
> +int
> +rte_eal_pci_is_attached(const char *devargs)
> +{
> +        struct rte_pci_device *dev = NULL;
> +        struct rte_pci_addr addr;
> +        memset(&addr,0,sizeof(struct rte_pci_addr));
> +
> +        if (eal_parse_pci_DomBDF(devargs, &addr) == 0)
> +          {
> +            TAILQ_FOREACH(dev, &pci_device_list, next) {
> +            if (!rte_eal_compare_pci_addr(&dev->addr, &addr))
> +              {
> +                if (dev->driver)
> +                  {
> +                    /*pci_dump_one_device(stdout,dev);*/
> +                    RTE_LOG(WARNING, EAL, "Requested device " PCI_PRI_FMT
> +                      " cannot be used\n", dev->addr.domain, dev->addr.bus,
> +                    dev->addr.devid, dev->addr.function);
> +                   return -1;
> +                 }
> +              }
> +           }
> +         }
> +   return 0;
> +}
> +
>
> Could you please let me know if it is good to have such APIs
>
> Regards,
> _Srikanth_
>
>
> On Mon, Sep 28, 2015 at 9:44 PM, Stephen Hemminger <
> stephen@networkplumber.org> wrote:
>
>> On Mon, 28 Sep 2015 21:12:50 -0700
>> Srikanth Akula <srikanth044@gmail.com> wrote:
>>
>>> Hello ,
>>>
>>> I am trying to write an application based on DPDK port hotplug feature .
>> My
>>> requirement is to get an event when a new PCI devices gets added to the
>>> system on the go.
>>>
>>> Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers ) that
>> i
>>> can use to get notifications when a new device gets added . I know the
>>> alternatives such as inotify etc .
>>>
>>> But i am more interested to get equivalent support in dpdk drivers .
>>>
>>> Please let me know .
>>>
>>> Srikanth
>> Implementing hotplug requires integration with the OS more than any
>> additional
>> DPDK support. What the Brocade vRouter does is leverage the existing Linux
>> udev infrastructure to send a message to the router application which then
>> initializes and sets up the new hardware. Most of the DPDK changes are
>> upstream
>> already and involve being able to dynamically add ports on the fly.
>>
>>

Re: Hotplug

[Srikanth Akula]

Hi Tetsuya ,

Thank you for your inputs .

I have thought about this API , but looks like it takes interface name as
argument ( which is a unique name from the rte_pci_dev instance) . But i am
looking to check if the device is attached based on the PCI address .

But ,I am going to test this too

Regards,
Srikanth

On Wed, Oct 7, 2015 at 4:45 PM, Tetsuya Mukawa <mukawa@igel.co.jp> wrote:

> On 2015/10/07 22:16, Srikanth Akula wrote:
> > Thank you for the inputs .
> >
> > I was able to solve the problem of device notification from my control
> > plane.
> >
> > I would like to know if we have any way to know if the PCI device is
> > already attached before we try to attach it ( if the device is already
> > attached pci probe will result an error ) .
> > But i want to know before hand to verify if the device is already
> attached
> > or not .
>
> Hi  Srikanth,
>
> I guess below API may help you.
> (Unfortunately, I am out of office now, so I haven't checked it, but I
> guess it works.)
>
>  - struct rte_eth_dev *rte_eth_dev_allocated(const char *name)
>
> If none NULL value is returned, a device has been already attached.
> If you want to check a physical NIC, above 'name' parameter will be like
> below.
>
>     snprintf(name, size, "%d:%d.%d",
>                         pci_dev->addr.bus, pci_dev->addr.devid,
>                         pci_dev->addr.function);
>
> Thanks,
> Tetsuya
>
> >
> > I came with small API which can be used to check if the pci device is
> > already bound to any driver .
> >
> > +int
> > +rte_eal_pci_is_attached(const char *devargs)
> > +{
> > +        struct rte_pci_device *dev = NULL;
> > +        struct rte_pci_addr addr;
> > +        memset(&addr,0,sizeof(struct rte_pci_addr));
> > +
> > +        if (eal_parse_pci_DomBDF(devargs, &addr) == 0)
> > +          {
> > +            TAILQ_FOREACH(dev, &pci_device_list, next) {
> > +            if (!rte_eal_compare_pci_addr(&dev->addr, &addr))
> > +              {
> > +                if (dev->driver)
> > +                  {
> > +                    /*pci_dump_one_device(stdout,dev);*/
> > +                    RTE_LOG(WARNING, EAL, "Requested device "
> PCI_PRI_FMT
> > +                      " cannot be used\n", dev->addr.domain,
> dev->addr.bus,
> > +                    dev->addr.devid, dev->addr.function);
> > +                   return -1;
> > +                 }
> > +              }
> > +           }
> > +         }
> > +   return 0;
> > +}
> > +
> >
> > Could you please let me know if it is good to have such APIs
> >
> > Regards,
> > _Srikanth_
> >
> >
> > On Mon, Sep 28, 2015 at 9:44 PM, Stephen Hemminger <
> > stephen@networkplumber.org> wrote:
> >
> >> On Mon, 28 Sep 2015 21:12:50 -0700
> >> Srikanth Akula <srikanth044@gmail.com> wrote:
> >>
> >>> Hello ,
> >>>
> >>> I am trying to write an application based on DPDK port hotplug feature
> .
> >> My
> >>> requirement is to get an event when a new PCI devices gets added to the
> >>> system on the go.
> >>>
> >>> Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers )
> that
> >> i
> >>> can use to get notifications when a new device gets added . I know the
> >>> alternatives such as inotify etc .
> >>>
> >>> But i am more interested to get equivalent support in dpdk drivers .
> >>>
> >>> Please let me know .
> >>>
> >>> Srikanth
> >> Implementing hotplug requires integration with the OS more than any
> >> additional
> >> DPDK support. What the Brocade vRouter does is leverage the existing
> Linux
> >> udev infrastructure to send a message to the router application which
> then
> >> initializes and sets up the new hardware. Most of the DPDK changes are
> >> upstream
> >> already and involve being able to dynamically add ports on the fly.
> >>
> >>
>
>

Re: Hotplug

[Jens Axboe]

On 4/11/18 10:14 AM, Jan Kara wrote:
> Hello,
> 
> On Wed 11-04-18 08:11:13, Jens Axboe wrote:
>> On 4/11/18 7:58 AM, Jan Kara wrote:
>>> On Tue 10-04-18 11:17:46, Jens Axboe wrote:
>>>> Been running some tests and I keep running into issues with hotplug.
>>>> This looks similar to what Bart posted the other day, but it looks
>>>> more deeply rooted than just having to protect the queue in
>>>> generic_make_request_checks(). The test run is blktests,
>>>> block/001. Current -git doesn't survive it. I've seen at least two
>>>> different oopses, pasted below.
>>>>
>>>> [  102.163442] NULL pointer dereference at 0000000000000010
>>>> [  102.163444] PGD 0 P4D 0 
>>>> [  102.163447] Oops: 0000 [#1] PREEMPT SMP
>>>> [  102.163449] Modules linked in:
>>>> [  102.175540] sr 12:0:0:0: [sr2] scsi-1 drive
>>>> [  102.180112]  scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
>>>> [  102.186934] sr 12:0:0:0: Attached scsi CD-ROM sr2
>>>> [  102.191896]  sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
>>>> [  102.197169] sr 12:0:0:0: Attached scsi generic sg7 type 5
>>>> [  102.203475]  igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
>>>> [  102.203484] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
>>>> [  102.203487] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
>>>> [  102.350882] RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
>>>> [  102.358299] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
>>>> [  102.364734] RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
>>>> [  102.373220] RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
>>>> [  102.381705] RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
>>>> [  102.390185] R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
>>>> [  102.398671] R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
>>>> [  102.407156] FS:  00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
>>>> [  102.417138] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> [  102.424066] CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
>>>> [  102.432545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>> [  102.441024] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>>> [  102.449502] Call Trace:
>>>> [  102.452744]  ? __invalidate_device+0x48/0x60
>>>> [  102.458022]  check_disk_change+0x4c/0x60
>>>> [  102.462900]  sr_block_open+0x16/0xd0 [sr_mod]
>>>> [  102.468270]  __blkdev_get+0xb9/0x450
>>>> [  102.472774]  ? iget5_locked+0x1c0/0x1e0
>>>> [  102.477568]  blkdev_get+0x11e/0x320
>>>> [  102.481969]  ? bdget+0x11d/0x150
>>>> [  102.486083]  ? _raw_spin_unlock+0xa/0x20
>>>> [  102.490968]  ? bd_acquire+0xc0/0xc0
>>>> [  102.495368]  do_dentry_open+0x1b0/0x320
>>>> [  102.500159]  ? inode_permission+0x24/0xc0
>>>> [  102.505140]  path_openat+0x4e6/0x1420
>>>> [  102.509741]  ? cpumask_any_but+0x1f/0x40
>>>> [  102.514630]  ? flush_tlb_mm_range+0xa0/0x120
>>>> [  102.519903]  do_filp_open+0x8c/0xf0
>>>> [  102.524305]  ? __seccomp_filter+0x28/0x230
>>>> [  102.529389]  ? _raw_spin_unlock+0xa/0x20
>>>> [  102.534283]  ? __handle_mm_fault+0x7d6/0x9b0
>>>> [  102.539559]  ? list_lru_add+0xa8/0xc0
>>>> [  102.544157]  ? _raw_spin_unlock+0xa/0x20
>>>> [  102.549047]  ? __alloc_fd+0xaf/0x160
>>>> [  102.553549]  ? do_sys_open+0x1a6/0x230
>>>> [  102.558244]  do_sys_open+0x1a6/0x230
>>>> [  102.562742]  do_syscall_64+0x5a/0x100
>>>> [  102.567336]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
>>>
>>> Interesting. Thinking out loud: This is cd->device dereference I guess
>>> which means disk->private_data was NULL. That gets set in sr_probe()
>>> together with disk->fops which are certainly set as they must have led us
>>> to the crashing function sr_block_revalidate_disk(). So likely
>>> disk->private_data got already cleared. That happens in sr_kref_release()
>>> and the fact that that function got called means struct scsi_cd went away -
>>> so sr_remove() must have been called as well. That all seems possible like:
>>>
>>> CPU1		CPU2
>>> sr_probe()
>>> 		__blkdev_get()
>>> 		  disk = bdev_get_gendisk();
>>> <device removed>
>>> sr_remove()
>>>   del_gendisk()
>>>   ...
>>>   kref_put(&cd->kref, sr_kref_release);
>>>     disk->private_data = NULL;
>>>     put_disk(disk);
>>>     kfree(cd);
>>> 		  if (disk->fops->open) {
>>> 		    ret = disk->fops->open(bdev, mode); => sr_block_open
>>> 		      check_disk_change(bdev);
>>> 		        sr_block_revalidate_disk()
>>> 			  CRASH
>>>
>>> And I think the problem is in sr_block_revalidate_disk() itself as the
>>> scsi_cd() call is not guaranteed that the caller holds reference to 'cd'
>>> and thus that 'cd' does not disappear under it. IMHO it needs to use
>>> scsi_cd_get() to get struct scsi_cd from gendisk. Am I missing something?
>>
>> No I think you are correct, from the revalidate path it should grab/release
>> a reference. Looks like sr_block_check_events() needs the same treatment.
>> How about the below?
>  
> Yeah, that looks good to me except one thing:
> 
>> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
>> index 0cf25d789d05..3f3cb72e0c0c 100644
>> --- a/drivers/scsi/sr.c
>> +++ b/drivers/scsi/sr.c
>>  static int sr_block_revalidate_disk(struct gendisk *disk)
>>  {
>> -	struct scsi_cd *cd = scsi_cd(disk);
>>  	struct scsi_sense_hdr sshdr;
>> +	struct scsi_cd *cd;
>> +
>> +	cd = scsi_cd_get(disk);
>> +	if (!cd)
>> +		return -ENXIO;
> 
> So if this returns -ENXIO I somewhat wonder about the code in
> fs/block_dev.c: revalidate_disk(). Why do we do all the work there and then
> return -ENXIO?

That's a good (but separate) question. I'd have to look deeper, but
it's entirely possible that revalidate could fail for other reasons
and we still want to ensure we reset the size of the device, for
instance.

-- 
Jens Axboe

Re: Hotplug

[Jan Kara]

Hello,

On Wed 11-04-18 08:11:13, Jens Axboe wrote:
> On 4/11/18 7:58 AM, Jan Kara wrote:
> > On Tue 10-04-18 11:17:46, Jens Axboe wrote:
> >> Been running some tests and I keep running into issues with hotplug.
> >> This looks similar to what Bart posted the other day, but it looks
> >> more deeply rooted than just having to protect the queue in
> >> generic_make_request_checks(). The test run is blktests,
> >> block/001. Current -git doesn't survive it. I've seen at least two
> >> different oopses, pasted below.
> >>
> >> [  102.163442] NULL pointer dereference at 0000000000000010
> >> [  102.163444] PGD 0 P4D 0 
> >> [  102.163447] Oops: 0000 [#1] PREEMPT SMP
> >> [  102.163449] Modules linked in:
> >> [  102.175540] sr 12:0:0:0: [sr2] scsi-1 drive
> >> [  102.180112]  scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
> >> [  102.186934] sr 12:0:0:0: Attached scsi CD-ROM sr2
> >> [  102.191896]  sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
> >> [  102.197169] sr 12:0:0:0: Attached scsi generic sg7 type 5
> >> [  102.203475]  igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
> >> [  102.203484] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
> >> [  102.203487] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
> >> [  102.350882] RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
> >> [  102.358299] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
> >> [  102.364734] RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
> >> [  102.373220] RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
> >> [  102.381705] RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
> >> [  102.390185] R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
> >> [  102.398671] R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
> >> [  102.407156] FS:  00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
> >> [  102.417138] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> [  102.424066] CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
> >> [  102.432545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [  102.441024] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >> [  102.449502] Call Trace:
> >> [  102.452744]  ? __invalidate_device+0x48/0x60
> >> [  102.458022]  check_disk_change+0x4c/0x60
> >> [  102.462900]  sr_block_open+0x16/0xd0 [sr_mod]
> >> [  102.468270]  __blkdev_get+0xb9/0x450
> >> [  102.472774]  ? iget5_locked+0x1c0/0x1e0
> >> [  102.477568]  blkdev_get+0x11e/0x320
> >> [  102.481969]  ? bdget+0x11d/0x150
> >> [  102.486083]  ? _raw_spin_unlock+0xa/0x20
> >> [  102.490968]  ? bd_acquire+0xc0/0xc0
> >> [  102.495368]  do_dentry_open+0x1b0/0x320
> >> [  102.500159]  ? inode_permission+0x24/0xc0
> >> [  102.505140]  path_openat+0x4e6/0x1420
> >> [  102.509741]  ? cpumask_any_but+0x1f/0x40
> >> [  102.514630]  ? flush_tlb_mm_range+0xa0/0x120
> >> [  102.519903]  do_filp_open+0x8c/0xf0
> >> [  102.524305]  ? __seccomp_filter+0x28/0x230
> >> [  102.529389]  ? _raw_spin_unlock+0xa/0x20
> >> [  102.534283]  ? __handle_mm_fault+0x7d6/0x9b0
> >> [  102.539559]  ? list_lru_add+0xa8/0xc0
> >> [  102.544157]  ? _raw_spin_unlock+0xa/0x20
> >> [  102.549047]  ? __alloc_fd+0xaf/0x160
> >> [  102.553549]  ? do_sys_open+0x1a6/0x230
> >> [  102.558244]  do_sys_open+0x1a6/0x230
> >> [  102.562742]  do_syscall_64+0x5a/0x100
> >> [  102.567336]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> > 
> > Interesting. Thinking out loud: This is cd->device dereference I guess
> > which means disk->private_data was NULL. That gets set in sr_probe()
> > together with disk->fops which are certainly set as they must have led us
> > to the crashing function sr_block_revalidate_disk(). So likely
> > disk->private_data got already cleared. That happens in sr_kref_release()
> > and the fact that that function got called means struct scsi_cd went away -
> > so sr_remove() must have been called as well. That all seems possible like:
> > 
> > CPU1		CPU2
> > sr_probe()
> > 		__blkdev_get()
> > 		  disk = bdev_get_gendisk();
> > <device removed>
> > sr_remove()
> >   del_gendisk()
> >   ...
> >   kref_put(&cd->kref, sr_kref_release);
> >     disk->private_data = NULL;
> >     put_disk(disk);
> >     kfree(cd);
> > 		  if (disk->fops->open) {
> > 		    ret = disk->fops->open(bdev, mode); => sr_block_open
> > 		      check_disk_change(bdev);
> > 		        sr_block_revalidate_disk()
> > 			  CRASH
> > 
> > And I think the problem is in sr_block_revalidate_disk() itself as the
> > scsi_cd() call is not guaranteed that the caller holds reference to 'cd'
> > and thus that 'cd' does not disappear under it. IMHO it needs to use
> > scsi_cd_get() to get struct scsi_cd from gendisk. Am I missing something?
> 
> No I think you are correct, from the revalidate path it should grab/release
> a reference. Looks like sr_block_check_events() needs the same treatment.
> How about the below?
 
Yeah, that looks good to me except one thing:

> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
> index 0cf25d789d05..3f3cb72e0c0c 100644
> --- a/drivers/scsi/sr.c
> +++ b/drivers/scsi/sr.c
>  static int sr_block_revalidate_disk(struct gendisk *disk)
>  {
> -	struct scsi_cd *cd = scsi_cd(disk);
>  	struct scsi_sense_hdr sshdr;
> +	struct scsi_cd *cd;
> +
> +	cd = scsi_cd_get(disk);
> +	if (!cd)
> +		return -ENXIO;

So if this returns -ENXIO I somewhat wonder about the code in
fs/block_dev.c: revalidate_disk(). Why do we do all the work there and then
return -ENXIO?

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: Hotplug

[Jens Axboe]

On 4/11/18 8:06 AM, Bart Van Assche wrote:
> On Wed, 2018-04-11 at 15:58 +0200, Jan Kara wrote:
>> I'm not really sure where this is crashing and 'Code' line is incomplete to
>> tell me.
> 
> Hello Jan,
> 
> The following patch should fix this crash:
> https://www.mail-archive.com/linux-block@vger.kernel.org/msg20209.html.

Yeah, I forgot the link in my reply, thanks.

-- 
Jens Axboe

Re: Hotplug

[Jens Axboe]

On 4/11/18 7:58 AM, Jan Kara wrote:
> Hi,
> 
> On Tue 10-04-18 11:17:46, Jens Axboe wrote:
>> Been running some tests and I keep running into issues with hotplug.
>> This looks similar to what Bart posted the other day, but it looks
>> more deeply rooted than just having to protect the queue in
>> generic_make_request_checks(). The test run is blktests,
>> block/001. Current -git doesn't survive it. I've seen at least two
>> different oopses, pasted below.
>>
>> [  102.163442] NULL pointer dereference at 0000000000000010
>> [  102.163444] PGD 0 P4D 0 
>> [  102.163447] Oops: 0000 [#1] PREEMPT SMP
>> [  102.163449] Modules linked in:
>> [  102.175540] sr 12:0:0:0: [sr2] scsi-1 drive
>> [  102.180112]  scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
>> [  102.186934] sr 12:0:0:0: Attached scsi CD-ROM sr2
>> [  102.191896]  sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
>> [  102.197169] sr 12:0:0:0: Attached scsi generic sg7 type 5
>> [  102.203475]  igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
>> [  102.203484] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
>> [  102.203487] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
>> [  102.350882] RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
>> [  102.358299] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
>> [  102.364734] RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
>> [  102.373220] RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
>> [  102.381705] RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
>> [  102.390185] R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
>> [  102.398671] R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
>> [  102.407156] FS:  00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
>> [  102.417138] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [  102.424066] CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
>> [  102.432545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [  102.441024] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> [  102.449502] Call Trace:
>> [  102.452744]  ? __invalidate_device+0x48/0x60
>> [  102.458022]  check_disk_change+0x4c/0x60
>> [  102.462900]  sr_block_open+0x16/0xd0 [sr_mod]
>> [  102.468270]  __blkdev_get+0xb9/0x450
>> [  102.472774]  ? iget5_locked+0x1c0/0x1e0
>> [  102.477568]  blkdev_get+0x11e/0x320
>> [  102.481969]  ? bdget+0x11d/0x150
>> [  102.486083]  ? _raw_spin_unlock+0xa/0x20
>> [  102.490968]  ? bd_acquire+0xc0/0xc0
>> [  102.495368]  do_dentry_open+0x1b0/0x320
>> [  102.500159]  ? inode_permission+0x24/0xc0
>> [  102.505140]  path_openat+0x4e6/0x1420
>> [  102.509741]  ? cpumask_any_but+0x1f/0x40
>> [  102.514630]  ? flush_tlb_mm_range+0xa0/0x120
>> [  102.519903]  do_filp_open+0x8c/0xf0
>> [  102.524305]  ? __seccomp_filter+0x28/0x230
>> [  102.529389]  ? _raw_spin_unlock+0xa/0x20
>> [  102.534283]  ? __handle_mm_fault+0x7d6/0x9b0
>> [  102.539559]  ? list_lru_add+0xa8/0xc0
>> [  102.544157]  ? _raw_spin_unlock+0xa/0x20
>> [  102.549047]  ? __alloc_fd+0xaf/0x160
>> [  102.553549]  ? do_sys_open+0x1a6/0x230
>> [  102.558244]  do_sys_open+0x1a6/0x230
>> [  102.562742]  do_syscall_64+0x5a/0x100
>> [  102.567336]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> 
> Interesting. Thinking out loud: This is cd->device dereference I guess
> which means disk->private_data was NULL. That gets set in sr_probe()
> together with disk->fops which are certainly set as they must have led us
> to the crashing function sr_block_revalidate_disk(). So likely
> disk->private_data got already cleared. That happens in sr_kref_release()
> and the fact that that function got called means struct scsi_cd went away -
> so sr_remove() must have been called as well. That all seems possible like:
> 
> CPU1		CPU2
> sr_probe()
> 		__blkdev_get()
> 		  disk = bdev_get_gendisk();
> <device removed>
> sr_remove()
>   del_gendisk()
>   ...
>   kref_put(&cd->kref, sr_kref_release);
>     disk->private_data = NULL;
>     put_disk(disk);
>     kfree(cd);
> 		  if (disk->fops->open) {
> 		    ret = disk->fops->open(bdev, mode); => sr_block_open
> 		      check_disk_change(bdev);
> 		        sr_block_revalidate_disk()
> 			  CRASH
> 
> And I think the problem is in sr_block_revalidate_disk() itself as the
> scsi_cd() call is not guaranteed that the caller holds reference to 'cd'
> and thus that 'cd' does not disappear under it. IMHO it needs to use
> scsi_cd_get() to get struct scsi_cd from gendisk. Am I missing something?

No I think you are correct, from the revalidate path it should grab/release
a reference. Looks like sr_block_check_events() needs the same treatment.
How about the below?

>> [ 4677.146385] Code: 85 f6 74 4e 48 63 05 ab 33 d6 00 4c 8b bc c6 c8 02 00 00 0f b7 43 14 f6 c4 0 
>> [ 4677.168785] RIP: blk_throtl_bio+0x45/0x9b0 RSP: ffff881ff0c8bb38
> 
> I'm not really sure where this is crashing and 'Code' line is incomplete to
> tell me.

This one was already in progress, different fix there.


diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 0cf25d789d05..3f3cb72e0c0c 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -587,18 +587,28 @@ static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,
 static unsigned int sr_block_check_events(struct gendisk *disk,
 					  unsigned int clearing)
 {
-	struct scsi_cd *cd = scsi_cd(disk);
+	unsigned int ret = 0;
+	struct scsi_cd *cd;
 
-	if (atomic_read(&cd->device->disk_events_disable_depth))
+	cd = scsi_cd_get(disk);
+	if (!cd)
 		return 0;
 
-	return cdrom_check_events(&cd->cdi, clearing);
+	if (!atomic_read(&cd->device->disk_events_disable_depth))
+		ret = cdrom_check_events(&cd->cdi, clearing);
+
+	scsi_cd_put(cd);
+	return ret;
 }
 
 static int sr_block_revalidate_disk(struct gendisk *disk)
 {
-	struct scsi_cd *cd = scsi_cd(disk);
 	struct scsi_sense_hdr sshdr;
+	struct scsi_cd *cd;
+
+	cd = scsi_cd_get(disk);
+	if (!cd)
+		return -ENXIO;
 
 	/* if the unit is not ready, nothing more to do */
 	if (scsi_test_unit_ready(cd->device, SR_TIMEOUT, MAX_RETRIES, &sshdr))
@@ -607,6 +617,7 @@ static int sr_block_revalidate_disk(struct gendisk *disk)
 	sr_cd_check(&cd->cdi);
 	get_sectorsize(cd);
 out:
+	scsi_cd_put(cd);
 	return 0;
 }
 

-- 
Jens Axboe

Re: Hotplug

[Bart Van Assche]

T24gV2VkLCAyMDE4LTA0LTExIGF0IDE1OjU4ICswMjAwLCBKYW4gS2FyYSB3cm90ZToNCj4gSSdt
IG5vdCByZWFsbHkgc3VyZSB3aGVyZSB0aGlzIGlzIGNyYXNoaW5nIGFuZCAnQ29kZScgbGluZSBp
cyBpbmNvbXBsZXRlIHRvDQo+IHRlbGwgbWUuDQoNCkhlbGxvIEphbiwNCg0KVGhlIGZvbGxvd2lu
ZyBwYXRjaCBzaG91bGQgZml4IHRoaXMgY3Jhc2g6DQpodHRwczovL3d3dy5tYWlsLWFyY2hpdmUu
Y29tL2xpbnV4LWJsb2NrQHZnZXIua2VybmVsLm9yZy9tc2cyMDIwOS5odG1sLg0KDQpUaGFua3Ms
DQoNCkJhcnQuDQoNCg0K

Re: Hotplug

[Jan Kara]

Hi,

On Tue 10-04-18 11:17:46, Jens Axboe wrote:
> Been running some tests and I keep running into issues with hotplug.
> This looks similar to what Bart posted the other day, but it looks
> more deeply rooted than just having to protect the queue in
> generic_make_request_checks(). The test run is blktests,
> block/001. Current -git doesn't survive it. I've seen at least two
> different oopses, pasted below.
> 
> [  102.163442] NULL pointer dereference at 0000000000000010
> [  102.163444] PGD 0 P4D 0 
> [  102.163447] Oops: 0000 [#1] PREEMPT SMP
> [  102.163449] Modules linked in:
> [  102.175540] sr 12:0:0:0: [sr2] scsi-1 drive
> [  102.180112]  scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
> [  102.186934] sr 12:0:0:0: Attached scsi CD-ROM sr2
> [  102.191896]  sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
> [  102.197169] sr 12:0:0:0: Attached scsi generic sg7 type 5
> [  102.203475]  igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
> [  102.203484] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
> [  102.203487] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
> [  102.350882] RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
> [  102.358299] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
> [  102.364734] RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
> [  102.373220] RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
> [  102.381705] RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
> [  102.390185] R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
> [  102.398671] R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
> [  102.407156] FS:  00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
> [  102.417138] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  102.424066] CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
> [  102.432545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  102.441024] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [  102.449502] Call Trace:
> [  102.452744]  ? __invalidate_device+0x48/0x60
> [  102.458022]  check_disk_change+0x4c/0x60
> [  102.462900]  sr_block_open+0x16/0xd0 [sr_mod]
> [  102.468270]  __blkdev_get+0xb9/0x450
> [  102.472774]  ? iget5_locked+0x1c0/0x1e0
> [  102.477568]  blkdev_get+0x11e/0x320
> [  102.481969]  ? bdget+0x11d/0x150
> [  102.486083]  ? _raw_spin_unlock+0xa/0x20
> [  102.490968]  ? bd_acquire+0xc0/0xc0
> [  102.495368]  do_dentry_open+0x1b0/0x320
> [  102.500159]  ? inode_permission+0x24/0xc0
> [  102.505140]  path_openat+0x4e6/0x1420
> [  102.509741]  ? cpumask_any_but+0x1f/0x40
> [  102.514630]  ? flush_tlb_mm_range+0xa0/0x120
> [  102.519903]  do_filp_open+0x8c/0xf0
> [  102.524305]  ? __seccomp_filter+0x28/0x230
> [  102.529389]  ? _raw_spin_unlock+0xa/0x20
> [  102.534283]  ? __handle_mm_fault+0x7d6/0x9b0
> [  102.539559]  ? list_lru_add+0xa8/0xc0
> [  102.544157]  ? _raw_spin_unlock+0xa/0x20
> [  102.549047]  ? __alloc_fd+0xaf/0x160
> [  102.553549]  ? do_sys_open+0x1a6/0x230
> [  102.558244]  do_sys_open+0x1a6/0x230
> [  102.562742]  do_syscall_64+0x5a/0x100
> [  102.567336]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

Interesting. Thinking out loud: This is cd->device dereference I guess
which means disk->private_data was NULL. That gets set in sr_probe()
together with disk->fops which are certainly set as they must have led us
to the crashing function sr_block_revalidate_disk(). So likely
disk->private_data got already cleared. That happens in sr_kref_release()
and the fact that that function got called means struct scsi_cd went away -
so sr_remove() must have been called as well. That all seems possible like:

CPU1		CPU2
sr_probe()
		__blkdev_get()
		  disk = bdev_get_gendisk();
<device removed>
sr_remove()
  del_gendisk()
  ...
  kref_put(&cd->kref, sr_kref_release);
    disk->private_data = NULL;
    put_disk(disk);
    kfree(cd);
		  if (disk->fops->open) {
		    ret = disk->fops->open(bdev, mode); => sr_block_open
		      check_disk_change(bdev);
		        sr_block_revalidate_disk()
			  CRASH

And I think the problem is in sr_block_revalidate_disk() itself as the
scsi_cd() call is not guaranteed that the caller holds reference to 'cd'
and thus that 'cd' does not disappear under it. IMHO it needs to use
scsi_cd_get() to get struct scsi_cd from gendisk. Am I missing something?

> and this one, similar to Barts:
> 
> [ 4676.738069] NULL pointer dereference at 0000000000000154
> [ 4676.738071] PGD 0 P4D 0 
> [ 4676.738073] Oops: 0000 [#1] PREEMPT SMP
> [ 4676.738075] Modules linked in: scsi_debug crc_t10dif nvme nvme_core loop configfs crct10dif_ge]
> [ 4676.859272] CPU: 10 PID: 16598 Comm: systemd-udevd Not tainted 4.16.0+ #651
> [ 4676.867525] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
> [ 4676.876765] RIP: 0010:blk_throtl_bio+0x45/0x9b0
> [ 4676.882296] RSP: 0018:ffff881ff0c8bb38 EFLAGS: 00010246
> [ 4676.888610] RAX: 0000000000000000 RBX: ffff881ffa273a40 RCX: 0000000000000000
> [ 4676.897059] RDX: ffff881ffa273a40 RSI: 0000000000000000 RDI: 0000000000000000
> [ 4676.905507] RBP: 0000000000000000 R08: ffff881ffa273ac0 R09: ffff881ff123f458
> [ 4676.913955] R10: ffff881ff0c8bc70 R11: 0000000000001000 R12: 0000000000000000
> [ 4676.922402] R13: ffffffff82600980 R14: ffff882081130000 R15: 0000000000000000
> [ 4676.930856] FS:  00007fe63e5228c0(0000) GS:ffff881fff740000(0000) knlGS:0000000000000000
> [ 4676.940773] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 4676.947667] CR2: 0000000000000154 CR3: 0000001fed2a0003 CR4: 00000000003606e0
> [ 4676.956116] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 4676.964568] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 4676.973021] Call Trace:
> [ 4676.976229]  generic_make_request_checks+0x640/0x660
> [ 4676.982245]  ? kmem_cache_alloc+0x37/0x190
> [ 4676.987295]  generic_make_request+0x29/0x2f0
> [ 4676.992534]  ? submit_bio+0x5c/0x110
> [ 4676.996998]  ? bio_alloc_bioset+0x99/0x1c0
> [ 4677.002050]  submit_bio+0x5c/0x110
> [ 4677.006317]  ? guard_bio_eod+0x42/0x120
> [ 4677.011074]  submit_bh_wbc.isra.49+0x132/0x160
> [ 4677.016517]  ? bh_uptodate_or_lock+0x90/0x90
> [ 4677.021757]  block_read_full_page+0x216/0x330
> [ 4677.027095]  ? check_disk_change+0x60/0x60
> [ 4677.032144]  ? __atime_needs_update+0x7f/0x190
> [ 4677.037576]  ? find_get_entry+0x98/0xf0
> [ 4677.042329]  ? pagecache_get_page+0x30/0x220
> [ 4677.047567]  ? touch_atime+0x27/0xb0
> [ 4677.052029]  generic_file_read_iter+0x60b/0x970
> [ 4677.057561]  ? _copy_to_user+0x56/0x70
> [ 4677.062221]  ? __seccomp_filter+0x28/0x230
> [ 4677.067269]  __vfs_read+0xd1/0x120
> [ 4677.071539]  vfs_read+0x9b/0x140
> [ 4677.075614]  ksys_read+0x45/0xa0
> [ 4677.079686]  do_syscall_64+0x5a/0x100
> [ 4677.084241]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [ 4677.090345] RIP: 0033:0x7fe63d6741f0
> [ 4677.094808] RSP: 002b:00007ffcb901f918 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
> [ 4677.104143] RAX: ffffffffffffffda RBX: 000055b1645c33c0 RCX: 00007fe63d6741f0
> [ 4677.112584] RDX: 0000000000000400 RSI: 000055b1645c33e8 RDI: 000000000000000f
> [ 4677.121037] RBP: 000055b1645c32b0 R08: 00007fe63d65f008 R09: 0000000000000430
> [ 4677.129489] R10: 000055b1645c33d8 R11: 0000000000000246 R12: 0000000000000000
> [ 4677.137934] R13: 0000000000000400 R14: 000055b1645c3300 R15: 0000000000000400
> [ 4677.146385] Code: 85 f6 74 4e 48 63 05 ab 33 d6 00 4c 8b bc c6 c8 02 00 00 0f b7 43 14 f6 c4 0 
> [ 4677.168785] RIP: blk_throtl_bio+0x45/0x9b0 RSP: ffff881ff0c8bb38

I'm not really sure where this is crashing and 'Code' line is incomplete to
tell me.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Hotplug

[Jens Axboe]

Hi,

Been running some tests and I keep running into issues with hotplug.
This looks similar to what Bart posted the other day, but it looks
more deeply rooted than just having to protect the queue in
generic_make_request_checks(). The test run is blktests,
block/001. Current -git doesn't survive it. I've seen at least two
different oopses, pasted below.

[  102.163442] NULL pointer dereference at 0000000000000010
[  102.163444] PGD 0 P4D 0 
[  102.163447] Oops: 0000 [#1] PREEMPT SMP
[  102.163449] Modules linked in:
[  102.175540] sr 12:0:0:0: [sr2] scsi-1 drive
[  102.180112]  scsi_debug crc_t10dif crct10dif_generic crct10dif_common nvme nvme_core sb_edac xl
[  102.186934] sr 12:0:0:0: Attached scsi CD-ROM sr2
[  102.191896]  sr_mod cdrom btrfs xor zstd_decompress zstd_compress xxhash lzo_compress zlib_defc
[  102.197169] sr 12:0:0:0: Attached scsi generic sg7 type 5
[  102.203475]  igb ahci libahci i2c_algo_bit libata dca [last unloaded: crc_t10dif]
[  102.203484] CPU: 43 PID: 4629 Comm: systemd-udevd Not tainted 4.16.0+ #650
[  102.203487] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
[  102.350882] RIP: 0010:sr_block_revalidate_disk+0x23/0x190 [sr_mod]
[  102.358299] RSP: 0018:ffff883ff357bb58 EFLAGS: 00010292
[  102.364734] RAX: ffffffffa00b07d0 RBX: ffff883ff3058000 RCX: ffff883ff357bb66
[  102.373220] RDX: 0000000000000003 RSI: 0000000000007530 RDI: ffff881fea631000
[  102.381705] RBP: 0000000000000000 R08: ffff881fe4d38400 R09: 0000000000000000
[  102.390185] R10: 0000000000000000 R11: 00000000000001b6 R12: 000000000800005d
[  102.398671] R13: 000000000800005d R14: ffff883ffd9b3790 R15: 0000000000000000
[  102.407156] FS:  00007f7dc8e6d8c0(0000) GS:ffff883fff340000(0000) knlGS:0000000000000000
[  102.417138] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  102.424066] CR2: 0000000000000010 CR3: 0000003ffda98005 CR4: 00000000003606e0
[  102.432545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  102.441024] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  102.449502] Call Trace:
[  102.452744]  ? __invalidate_device+0x48/0x60
[  102.458022]  check_disk_change+0x4c/0x60
[  102.462900]  sr_block_open+0x16/0xd0 [sr_mod]
[  102.468270]  __blkdev_get+0xb9/0x450
[  102.472774]  ? iget5_locked+0x1c0/0x1e0
[  102.477568]  blkdev_get+0x11e/0x320
[  102.481969]  ? bdget+0x11d/0x150
[  102.486083]  ? _raw_spin_unlock+0xa/0x20
[  102.490968]  ? bd_acquire+0xc0/0xc0
[  102.495368]  do_dentry_open+0x1b0/0x320
[  102.500159]  ? inode_permission+0x24/0xc0
[  102.505140]  path_openat+0x4e6/0x1420
[  102.509741]  ? cpumask_any_but+0x1f/0x40
[  102.514630]  ? flush_tlb_mm_range+0xa0/0x120
[  102.519903]  do_filp_open+0x8c/0xf0
[  102.524305]  ? __seccomp_filter+0x28/0x230
[  102.529389]  ? _raw_spin_unlock+0xa/0x20
[  102.534283]  ? __handle_mm_fault+0x7d6/0x9b0
[  102.539559]  ? list_lru_add+0xa8/0xc0
[  102.544157]  ? _raw_spin_unlock+0xa/0x20
[  102.549047]  ? __alloc_fd+0xaf/0x160
[  102.553549]  ? do_sys_open+0x1a6/0x230
[  102.558244]  do_sys_open+0x1a6/0x230
[  102.562742]  do_syscall_64+0x5a/0x100
[  102.567336]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

and this one, similar to Barts:

[ 4676.738069] NULL pointer dereference at 0000000000000154
[ 4676.738071] PGD 0 P4D 0 
[ 4676.738073] Oops: 0000 [#1] PREEMPT SMP
[ 4676.738075] Modules linked in: scsi_debug crc_t10dif nvme nvme_core loop configfs crct10dif_ge]
[ 4676.859272] CPU: 10 PID: 16598 Comm: systemd-udevd Not tainted 4.16.0+ #651
[ 4676.867525] Hardware name: Dell Inc. PowerEdge T630/0NT78X, BIOS 2.3.4 11/09/2016
[ 4676.876765] RIP: 0010:blk_throtl_bio+0x45/0x9b0
[ 4676.882296] RSP: 0018:ffff881ff0c8bb38 EFLAGS: 00010246
[ 4676.888610] RAX: 0000000000000000 RBX: ffff881ffa273a40 RCX: 0000000000000000
[ 4676.897059] RDX: ffff881ffa273a40 RSI: 0000000000000000 RDI: 0000000000000000
[ 4676.905507] RBP: 0000000000000000 R08: ffff881ffa273ac0 R09: ffff881ff123f458
[ 4676.913955] R10: ffff881ff0c8bc70 R11: 0000000000001000 R12: 0000000000000000
[ 4676.922402] R13: ffffffff82600980 R14: ffff882081130000 R15: 0000000000000000
[ 4676.930856] FS:  00007fe63e5228c0(0000) GS:ffff881fff740000(0000) knlGS:0000000000000000
[ 4676.940773] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4676.947667] CR2: 0000000000000154 CR3: 0000001fed2a0003 CR4: 00000000003606e0
[ 4676.956116] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 4676.964568] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 4676.973021] Call Trace:
[ 4676.976229]  generic_make_request_checks+0x640/0x660
[ 4676.982245]  ? kmem_cache_alloc+0x37/0x190
[ 4676.987295]  generic_make_request+0x29/0x2f0
[ 4676.992534]  ? submit_bio+0x5c/0x110
[ 4676.996998]  ? bio_alloc_bioset+0x99/0x1c0
[ 4677.002050]  submit_bio+0x5c/0x110
[ 4677.006317]  ? guard_bio_eod+0x42/0x120
[ 4677.011074]  submit_bh_wbc.isra.49+0x132/0x160
[ 4677.016517]  ? bh_uptodate_or_lock+0x90/0x90
[ 4677.021757]  block_read_full_page+0x216/0x330
[ 4677.027095]  ? check_disk_change+0x60/0x60
[ 4677.032144]  ? __atime_needs_update+0x7f/0x190
[ 4677.037576]  ? find_get_entry+0x98/0xf0
[ 4677.042329]  ? pagecache_get_page+0x30/0x220
[ 4677.047567]  ? touch_atime+0x27/0xb0
[ 4677.052029]  generic_file_read_iter+0x60b/0x970
[ 4677.057561]  ? _copy_to_user+0x56/0x70
[ 4677.062221]  ? __seccomp_filter+0x28/0x230
[ 4677.067269]  __vfs_read+0xd1/0x120
[ 4677.071539]  vfs_read+0x9b/0x140
[ 4677.075614]  ksys_read+0x45/0xa0
[ 4677.079686]  do_syscall_64+0x5a/0x100
[ 4677.084241]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 4677.090345] RIP: 0033:0x7fe63d6741f0
[ 4677.094808] RSP: 002b:00007ffcb901f918 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 4677.104143] RAX: ffffffffffffffda RBX: 000055b1645c33c0 RCX: 00007fe63d6741f0
[ 4677.112584] RDX: 0000000000000400 RSI: 000055b1645c33e8 RDI: 000000000000000f
[ 4677.121037] RBP: 000055b1645c32b0 R08: 00007fe63d65f008 R09: 0000000000000430
[ 4677.129489] R10: 000055b1645c33d8 R11: 0000000000000246 R12: 0000000000000000
[ 4677.137934] R13: 0000000000000400 R14: 000055b1645c3300 R15: 0000000000000400
[ 4677.146385] Code: 85 f6 74 4e 48 63 05 ab 33 d6 00 4c 8b bc c6 c8 02 00 00 0f b7 43 14 f6 c4 0 
[ 4677.168785] RIP: blk_throtl_bio+0x45/0x9b0 RSP: ffff881ff0c8bb38


-- 
Jens Axboe

Re: Hotplug

[Mark Nelson]

On Thu, Sep 4, 2008 at 8:35 PM, Tejun Heo <tj@kernel.org> wrote:
> Hello,
>
> Mark Nelson wrote:
>> Can you check these too (I'm testing hotplug on the PDC42819 with
>> ahci driver)?
>>
>> after powering up eSATA connected drive:
>>
>>  ata7: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen
>>  ata7: irq_stat 0x00000040, connection status changed
>>  ata7: SError: { PHYRdyChg CommWake DevExch }
>>  ata7: hard resetting link
>>  ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>  ata7.00: ATA-7: HTS721060G9SA00, MC3IC10H, max UDMA/100
>>  ata7.00: 117210240 sectors, multi 0: LBA48
>>  ata7.00: configured for UDMA/100
>>  ata7: EH complete
>>  scsi 6:0:0:0: Direct-Access     ATA      HTS721060G9SA00  MC3I PQ: 0 ANSI: 5
>>  sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
>>  sd 6:0:0:0: [sdb] Write Protect is off
>>  sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
>>  sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
>> support DPO or FUA
>>  sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
>>  sd 6:0:0:0: [sdb] Write Protect is off
>>  sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
>>  sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
>> support DPO or FUA
>>   sdb: sdb1
>>  sd 6:0:0:0: [sdb] Attached SCSI disk
>>  sd 6:0:0:0: Attached scsi generic sg1 type 0
>>  kjournald starting.  Commit interval 5 seconds
>>  EXT3 FS on sdb1, internal journal
>>  EXT3-fs: recovery complete.
>>  EXT3-fs: mounted filesystem with ordered data mode.
>
> Yeap, looks fine.
>
>> after unmounting and executing
>> echo 1 > /sys/class/scsi_device/6\:0\:0\:0/device/delete:
>>
>>  sd 6:0:0:0: [sdb] Synchronizing SCSI cache
>>  sd 6:0:0:0: [sdb] Stopping disk
>>  ata7.00: disabled
>
> Heh.. I usually just pull the power plug doing delete is a good idea.

Well truth be told I just learnt it from Jason's post (prior to that I took
hotplug more literally :) )

>
>> and after removing power from eSATA device:
>>
>>  ata7: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen
>>  ata7: irq_stat 0x00400000, PHY RDY changed
>>  ata7: SError: { PHYRdyChg }
>>  ata7: hard resetting link
>>  ata7: SATA link down (SStatus 0 SControl 300)
>>  ata7: EH complete
>
> This looks fine too.

Excellent.

Thanks!

Mark

Re: Hotplug

[Tejun Heo]

Hello,

Mark Nelson wrote:
> Can you check these too (I'm testing hotplug on the PDC42819 with
> ahci driver)?
> 
> after powering up eSATA connected drive:
> 
>  ata7: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen
>  ata7: irq_stat 0x00000040, connection status changed
>  ata7: SError: { PHYRdyChg CommWake DevExch }
>  ata7: hard resetting link
>  ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>  ata7.00: ATA-7: HTS721060G9SA00, MC3IC10H, max UDMA/100
>  ata7.00: 117210240 sectors, multi 0: LBA48
>  ata7.00: configured for UDMA/100
>  ata7: EH complete
>  scsi 6:0:0:0: Direct-Access     ATA      HTS721060G9SA00  MC3I PQ: 0 ANSI: 5
>  sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
>  sd 6:0:0:0: [sdb] Write Protect is off
>  sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
>  sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
>  sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
>  sd 6:0:0:0: [sdb] Write Protect is off
>  sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
>  sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
>   sdb: sdb1
>  sd 6:0:0:0: [sdb] Attached SCSI disk
>  sd 6:0:0:0: Attached scsi generic sg1 type 0
>  kjournald starting.  Commit interval 5 seconds
>  EXT3 FS on sdb1, internal journal
>  EXT3-fs: recovery complete.
>  EXT3-fs: mounted filesystem with ordered data mode.

Yeap, looks fine.

> after unmounting and executing
> echo 1 > /sys/class/scsi_device/6\:0\:0\:0/device/delete:
> 
>  sd 6:0:0:0: [sdb] Synchronizing SCSI cache
>  sd 6:0:0:0: [sdb] Stopping disk
>  ata7.00: disabled

Heh.. I usually just pull the power plug doing delete is a good idea.

> and after removing power from eSATA device:
> 
>  ata7: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen
>  ata7: irq_stat 0x00400000, PHY RDY changed
>  ata7: SError: { PHYRdyChg }
>  ata7: hard resetting link
>  ata7: SATA link down (SStatus 0 SControl 300)
>  ata7: EH complete

This looks fine too.

-- 
tejun

Re: Hotplug

[Mark Nelson]

On Wed, Sep 3, 2008 at 5:01 PM, Tejun Heo <tj@kernel.org> wrote:
> Jason Davis wrote:
>> Hello,
>>  I'm trying to confirm hot/warm plugging is working on my system. When
>> I plug in the drive shows up as expected. I just want to make sure the
>> stuff I see in the logs is ok.
>
> Yeah, those are as okay as they get.  :-)

Hi Tejun,

Can you check these too (I'm testing hotplug on the PDC42819 with ahci driver)?

after powering up eSATA connected drive:

 ata7: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0xe frozen
 ata7: irq_stat 0x00000040, connection status changed
 ata7: SError: { PHYRdyChg CommWake DevExch }
 ata7: hard resetting link
 ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 ata7.00: ATA-7: HTS721060G9SA00, MC3IC10H, max UDMA/100
 ata7.00: 117210240 sectors, multi 0: LBA48
 ata7.00: configured for UDMA/100
 ata7: EH complete
 scsi 6:0:0:0: Direct-Access     ATA      HTS721060G9SA00  MC3I PQ: 0 ANSI: 5
 sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
 sd 6:0:0:0: [sdb] Write Protect is off
 sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
 sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
 sd 6:0:0:0: [sdb] 117210240 512-byte hardware sectors (60012 MB)
 sd 6:0:0:0: [sdb] Write Protect is off
 sd 6:0:0:0: [sdb] Mode Sense: 00 3a 00 00
 sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
  sdb: sdb1
 sd 6:0:0:0: [sdb] Attached SCSI disk
 sd 6:0:0:0: Attached scsi generic sg1 type 0
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS on sdb1, internal journal
 EXT3-fs: recovery complete.
 EXT3-fs: mounted filesystem with ordered data mode.


after unmounting and executing
echo 1 > /sys/class/scsi_device/6\:0\:0\:0/device/delete:

 sd 6:0:0:0: [sdb] Synchronizing SCSI cache
 sd 6:0:0:0: [sdb] Stopping disk
 ata7.00: disabled


and after removing power from eSATA device:

 ata7: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen
 ata7: irq_stat 0x00400000, PHY RDY changed
 ata7: SError: { PHYRdyChg }
 ata7: hard resetting link
 ata7: SATA link down (SStatus 0 SControl 300)
 ata7: EH complete


Thanks!

Mark

Re: Hotplug

[Tejun Heo]

Jason Davis wrote:
> Hello,
>  I'm trying to confirm hot/warm plugging is working on my system. When
> I plug in the drive shows up as expected. I just want to make sure the
> stuff I see in the logs is ok.

Yeah, those are as okay as they get.  :-)

-- 
tejun

Hotplug

[Jason Davis]

Hello,
 I'm trying to confirm hot/warm plugging is working on my system. When
I plug in the drive shows up as expected. I just want to make sure the
stuff I see in the logs is ok.

Thanks,
jason

jd@linux:~$ uname -a
Linux linux 2.6.18-6-686 #1 SMP Mon Aug 18 08:42:39 UTC 2008 i686 GNU/Linux

from kern.log when I plug in:

Sep  2 15:24:04 linux kernel: ata6: exception Emask 0x10 SAct 0x0 SErr
0x0 action 0x2 frozen
Sep  2 15:24:04 linux kernel: ata6: (irq_stat 0x00b00090, PHY RDY changed)
Sep  2 15:24:05 linux kernel: ata6: waiting for device to spin up (8 secs)
Sep  2 15:24:13 linux kernel: ata6: soft resetting port
Sep  2 15:24:17 linux kernel: ata6: SATA link up 3.0 Gbps (SStatus 123
SControl 300)
Sep  2 15:24:17 linux kernel: ata6.00: ATA-8, max UDMA/133, 1953525168
sectors: LBA48 NCQ (depth 31/32)
Sep  2 15:24:17 linux kernel: ata6.00: ata6: dev 0 multi count 0
Sep  2 15:24:17 linux kernel: ata6.00: configured for UDMA/100
Sep  2 15:24:17 linux kernel: ata6: EH complete
Sep  2 15:24:17 linux kernel:   Vendor: ATA       Model: WDC
WD10EACS-00D  Rev: 01.0
Sep  2 15:24:17 linux kernel:   Type:   Direct-Access
    ANSI SCSI revision: 05
Sep  2 15:24:17 linux kernel: SCSI device sdc: 1953525168 512-byte
hdwr sectors (1000205 MB)
Sep  2 15:24:17 linux kernel: sdc: Write Protect is off
Sep  2 15:24:17 linux kernel: sdc: Mode Sense: 00 3a 00 00
Sep  2 15:24:17 linux kernel: SCSI device sdc: drive cache: write back
Sep  2 15:24:17 linux kernel: SCSI device sdc: 1953525168 512-byte
hdwr sectors (1000205 MB)
Sep  2 15:24:17 linux kernel: sdc: Write Protect is off
Sep  2 15:24:17 linux kernel: sdc: Mode Sense: 00 3a 00 00
Sep  2 15:24:17 linux kernel: SCSI device sdc: drive cache: write back
Sep  2 15:24:17 linux kernel:  sdc: sdc1
Sep  2 15:24:17 linux kernel: sd 5:0:0:0: Attached scsi disk sdc
Sep  2 15:24:47 linux kernel: kjournald starting.  Commit interval 5 seconds
Sep  2 15:24:47 linux kernel: EXT3 FS on sdc1, internal journal
Sep  2 15:24:47 linux kernel: EXT3-fs: mounted filesystem with ordered
data mode.




When I unplug:
root@linux:~# umount /mnt/other
root@linux:~# echo 1 > /sys/class/scsi_device/5\:0\:0\:0/device/delete


Sep  2 15:26:01 linux kernel: ata6.00: disabled
Sep  2 15:26:13 linux kernel: ata6: exception Emask 0x10 SAct 0x0 SErr
0x80000 action 0x2 frozen
Sep  2 15:26:13 linux kernel: ata6: (irq_stat 0x01140010, PHY RDY changed)
Sep  2 15:26:14 linux kernel: ata6: soft resetting port
Sep  2 15:26:14 linux kernel: ata6: SATA link down (SStatus 0 SControl 300)
Sep  2 15:26:14 linux kernel: ata6: EH complete

Re: Hotplug

[Philip MacIver]

 --- MALET JL <malet.jean-luc@laposte.net> wrote: > 
> I remember having such trouble but this was because
> the udev script was 
> run twice...... but I can't remember exactly what
> was the causes and how 
> they disapeard.....
> 
> what I remember is that : I loged into the box,
> noticed that /dev wasn't 
> the right one (a fixed dev tree) so tried to rerun
> the script and only 
> get a partial /dev structure.... looking what was
> mounted told me that 
> /dev was mounted twice with ramfs..... maybe it can
> help :/
> 

Thanks, I have to explore this possibility more when I
get home (they make me use Wind**s at work) :)
 

==Philip MacIver
--
e: pmaciver@arishi.com
e: philipmaciver@yahoo.co.uk


	
	
		
___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Hotplug

[MALET JL]

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

Philip MacIver a écrit :

> --- MALET JL <malet.jean-luc@laposte.net> wrote: >
>Philip MacIver a écrit :
>  
>
>>>I've just read something that may be causing my
>>>problem with udev, and I would just like to confirm
>>>this before I actually go ahead and do any changes.
>>>      
>>>
>>>Running "/proc/sys/kernel/hotplug" on my system
>>>      
>>>
>>prints
>>    
>>
>>>out "/bin/true", I've read that to change this you
>>>      
>>>
>>do
>>    
>>
>>>echo "/sbin/hotplug" > /proc/sys/kernel/hotplug. 
>>>
>>>But what I want to know is, is this the reason that
>>>      
>>>
>>my
>>    
>>
>>>linux system won't boot up when I try and use udev
>>>with /dev as the udev_root. The reason that I ask
>>>      
>>>
>>is
>>    
>>
>>>because when I tested out udev using /udev as the
>>>udev_root and my system started up, the hotplug
>>>      
>>>
>>demon
>>    
>>
>>>started up after the hard disks are mounted. And
>>>      
>>>
>>the
>>    
>>
>>>problem was that the /dev/hda device nodes (and
>>>others) were not being created. 
>>>
>>>Thanks in advanced for any help. 
>>>
>>>=====
>>>Philip MacIver
>>>--
>>>e: pmaciver@arishi.com
>>>e: philipmaciver@yahoo.co.uk
>>> 
>>>
>>>      
>>>
>>what script do you use to start udev?  is this the
>>start_udev one?
>>    
>>
>
>Yes.
>
>  
>
>>when you use /udev : the entries are created? (do an
>>ls don't assume 
>>that they are created because no errors occurs)
>>    
>>
>
>Yes all the enteries are created, I've learnt never to
>assume
>  
>
>>are you mounting a /dev in fstab? (i know someone
>>that did that...)
>>
>>    
>>
>
>Nope I've checked my fstab many times and I don't
>mount a dev.
>
>When I do set the udev_root to /dev some devices get
>created, like fd0 and a few others that I can't
>remember. 
>
>But i'm wondering if where i'm starting udev in my
>rc.sysinit is the problem. Just for your reference I
>start it (and also mount sysfs) right after /proc gets
>mounted (and yes I do mmount sysfs before I run
>start_udev :) )
>
>
> 
>
>=====
>Philip MacIver
>--
>e: pmaciver@arishi.com
>e: philipmaciver@yahoo.co.uk
>
>
>	
>	
>		
>___________________________________________________________
>Yahoo! Messenger - Communicate instantly..."Ping" 
>your friends today! Download Messenger Now 
>http://uk.messenger.yahoo.com/download/index.html
>  
>
I remember having such trouble but this was because the udev script was 
run twice...... but I can't remember exactly what was the causes and how 
they disapeard.....

what I remember is that : I loged into the box, noticed that /dev wasn't 
the right one (a fixed dev tree) so tried to rerun the script and only 
get a partial /dev structure.... looking what was mounted told me that 
/dev was mounted twice with ramfs..... maybe it can help :/

[-- Attachment #2: Type: application/pgp-signature, Size: 250 bytes --]

Re: Hotplug

[Philip MacIver]

 --- MALET JL <malet.jean-luc@laposte.net> wrote: >
Philip MacIver a écrit :
> 
> >I've just read something that may be causing my
> >problem with udev, and I would just like to confirm
> >this before I actually go ahead and do any changes.
> 
> >
> >Running "/proc/sys/kernel/hotplug" on my system
> prints
> >out "/bin/true", I've read that to change this you
> do
> >echo "/sbin/hotplug" > /proc/sys/kernel/hotplug. 
> >
> >But what I want to know is, is this the reason that
> my
> >linux system won't boot up when I try and use udev
> >with /dev as the udev_root. The reason that I ask
> is
> >because when I tested out udev using /udev as the
> >udev_root and my system started up, the hotplug
> demon
> >started up after the hard disks are mounted. And
> the
> >problem was that the /dev/hda device nodes (and
> >others) were not being created. 
> >
> >Thanks in advanced for any help. 
> >
> >==> >Philip MacIver
> >--
> >e: pmaciver@arishi.com
> >e: philipmaciver@yahoo.co.uk
> >  
> >
> what script do you use to start udev?  is this the
> start_udev one?

Yes.

> when you use /udev : the entries are created? (do an
> ls don't assume 
> that they are created because no errors occurs)

Yes all the enteries are created, I've learnt never to
assume
> are you mounting a /dev in fstab? (i know someone
> that did that...)
> 

Nope I've checked my fstab many times and I don't
mount a dev.

When I do set the udev_root to /dev some devices get
created, like fd0 and a few others that I can't
remember. 

But i'm wondering if where i'm starting udev in my
rc.sysinit is the problem. Just for your reference I
start it (and also mount sysfs) right after /proc gets
mounted (and yes I do mmount sysfs before I run
start_udev :) )


 

==Philip MacIver
--
e: pmaciver@arishi.com
e: philipmaciver@yahoo.co.uk


	
	
		
___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Hotplug

[MALET JL]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

Philip MacIver a écrit :

>I've just read something that may be causing my
>problem with udev, and I would just like to confirm
>this before I actually go ahead and do any changes. 
>
>Running "/proc/sys/kernel/hotplug" on my system prints
>out "/bin/true", I've read that to change this you do
>echo "/sbin/hotplug" > /proc/sys/kernel/hotplug. 
>
>But what I want to know is, is this the reason that my
>linux system won't boot up when I try and use udev
>with /dev as the udev_root. The reason that I ask is
>because when I tested out udev using /udev as the
>udev_root and my system started up, the hotplug demon
>started up after the hard disks are mounted. And the
>problem was that the /dev/hda device nodes (and
>others) were not being created. 
>
>Thanks in advanced for any help. 
>
>=====
>Philip MacIver
>--
>e: pmaciver@arishi.com
>e: philipmaciver@yahoo.co.uk
>  
>
what script do you use to start udev?  is this the start_udev one?
when you use /udev : the entries are created? (do an ls don't assume 
that they are created because no errors occurs)
are you mounting a /dev in fstab? (i know someone that did that...)

[-- Attachment #2: Type: application/pgp-signature, Size: 250 bytes --]

Hotplug

[Philip MacIver]

I've just read something that may be causing my
problem with udev, and I would just like to confirm
this before I actually go ahead and do any changes. 

Running "/proc/sys/kernel/hotplug" on my system prints
out "/bin/true", I've read that to change this you do
echo "/sbin/hotplug" > /proc/sys/kernel/hotplug. 

But what I want to know is, is this the reason that my
linux system won't boot up when I try and use udev
with /dev as the udev_root. The reason that I ask is
because when I tested out udev using /udev as the
udev_root and my system started up, the hotplug demon
started up after the hard disks are mounted. And the
problem was that the /dev/hda device nodes (and
others) were not being created. 

Thanks in advanced for any help. 

==Philip MacIver
--
e: pmaciver@arishi.com
e: philipmaciver@yahoo.co.uk


	
	
		
___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

hotplug

[raja sekhar kottapalli]

what are the required rpm's for creating a dynamic
icon on the desktop when an usb is pluged in


________________________________________________________________________
Yahoo! India Mobile: Download the latest polyphonic ringtones.
Go to http://in.mobile.yahoo.com


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel