Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Nov 26, 2011
  1. @gregkh

    Linux 3.0.11

    gregkh authored
  2. @gregkh

    drm/i915: always set FDI composite sync bit

    Jesse Barnes authored gregkh committed
    commit c4f9c4c upstream.
    
    It's needed for 3 pipe support as well as just regular functionality
    (e.g. DisplayPort).
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Tested-by: Adam Jackson <ajax@redhat.com>
    Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Robert Hooker <robert.hooker@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  3. @gregkh

    drm/i915: fix IVB cursor support

    Jesse Barnes authored gregkh committed
    commit 65a21cd upstream.
    
    The cursor regs have moved around, add the offsets and new macros for
    getting at them.
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Signed-off-by: Robert Hooker <robert.hooker@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  4. @gregkh

    xfs: fix ->write_inode return values

    Christoph Hellwig authored gregkh committed
    patch 58d84c4 upstream.
    
    Currently we always redirty an inode that was attempted to be written out
    synchronously but has been cleaned by an AIL pushed internall, which is
    rather bogus.  Fix that by doing the i_update_core check early on and
    return 0 for it.  Also include async calls for it, as doing any work for
    those is just as pointless.  While we're at it also fix the sign for the
    EIO return in case of a filesystem shutdown, and fix the completely
    non-sensical locking around xfs_log_inode.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  5. @gregkh

    xfs: use doalloc flag in xfs_qm_dqattach_one()

    Mitsuo Hayasaka authored gregkh committed
    commit db3e74b upstream
    
    The doalloc arg in xfs_qm_dqattach_one() is a flag that indicates
    whether a new area to handle quota information will be allocated
    if needed. Originally, it was passed to xfs_qm_dqget(), but has
    been removed by the following commit (probably by mistake):
    
    	commit 8e9b6e7
    	Author: Christoph Hellwig <hch@lst.de>
    	Date:   Sun Feb 8 21:51:42 2009 +0100
    
    	xfs: remove the unused XFS_QMOPT_DQLOCK flag
    
    As the result, xfs_qm_dqget() called from xfs_qm_dqattach_one()
    never allocates the new area even if it is needed.
    
    This patch gives the doalloc arg to xfs_qm_dqget() in
    xfs_qm_dqattach_one() to fix this problem.
    
    Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
    Cc: Alex Elder <aelder@sgi.com>
    Cc: Christoph Hellwig <hch@infradead.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Ben Myers <bpm@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  6. @gregkh

    xfs: Fix possible memory corruption in xfs_readlink

    Carlos Maiolino authored gregkh committed
    commit b52a360 upstream.
    
    Fixes a possible memory corruption when the link is larger than
    MAXPATHLEN and XFS_DEBUG is not enabled. This also remove the
    S_ISLNK assert, since the inode mode is checked previously in
    xfs_readlink_by_handle() and via VFS.
    
    Updated to address concerns raised by Ben Hutchings about the loose
    attention paid to 32- vs 64-bit values, and the lack of handling a
    potentially negative pathlen value:
     - Changed type of "pathlen" to be xfs_fsize_t, to match that of
       ip->i_d.di_size
     - Added checking for a negative pathlen to the too-long pathlen
       test, and generalized the message that gets reported in that case
       to reflect the change
    As a result, if a negative pathlen were encountered, this function
    would return EFSCORRUPTED (and would fail an assertion for a debug
    build)--just as would a too-long pathlen.
    
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  7. @gregkh

    xfs: fix buffer flushing during unmount

    Christoph Hellwig authored gregkh committed
    commit 87c7bec upstream.
    
    The code to flush buffers in the umount code is a bit iffy: we first
    flush all delwri buffers out, but then might be able to queue up a
    new one when logging the sb counts.  On a normal shutdown that one
    would get flushed out when doing the synchronous superblock write in
    xfs_unmountfs_writesb, but we skip that one if the filesystem has
    been shut down.
    
    Fix this by moving the delwri list flushing until just before unmounting
    the log, and while we're at it also remove the superflous delwri list
    and buffer lru flusing for the rt and log device that can never have
    cached or delwri buffers.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reported-by: Amit Sahrawat <amit.sahrawat83@gmail.com>
    Tested-by: Amit Sahrawat <amit.sahrawat83@gmail.com>
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  8. @gregkh

    xfs: Return -EIO when xfs_vn_getattr() failed

    Mitsuo Hayasaka authored gregkh committed
    commit ed32201 upstream.
    
    An attribute of inode can be fetched via xfs_vn_getattr() in XFS.
    Currently it returns EIO, not negative value, when it failed.  As a
    result, the system call returns not negative value even though an
    error occured. The stat(2), ls and mv commands cannot handle this
    error and do not work correctly.
    
    This patch fixes this bug, and returns -EIO, not EIO when an error
    is detected in xfs_vn_getattr().
    
    Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  9. @gregkh

    xfs: avoid direct I/O write vs buffered I/O race

    Christoph Hellwig authored gregkh committed
    commit c58cb16 upstream.
    
    Currently a buffered reader or writer can add pages to the pagecache
    while we are waiting for the iolock in xfs_file_dio_aio_write.  Prevent
    this by re-checking mapping->nrpages after we got the iolock, and if
    nessecary upgrade the lock to exclusive mode.  To simplify this a bit
    only take the ilock inside of xfs_file_aio_write_checks.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  10. @gregkh

    xfs: dont serialise direct IO reads on page cache

    Dave Chinner authored gregkh committed
    commit 0c38a25 upstream.
    
    There is no need to grab the i_mutex of the IO lock in exclusive
    mode if we don't need to invalidate the page cache. Taking these
    locks on every direct IO effective serialises them as taking the IO
    lock in exclusive mode has to wait for all shared holders to drop
    the lock. That only happens when IO is complete, so effective it
    prevents dispatch of concurrent direct IO reads to the same inode.
    
    Fix this by taking the IO lock shared to check the page cache state,
    and only then drop it and take the IO lock exclusively if there is
    work to be done. Hence for the normal direct IO case, no exclusive
    locking will occur.
    
    Signed-off-by: Dave Chinner <dchinner@redhat.com>
    Tested-by: Joern Engel <joern@logfs.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  11. @gregkh

    xfs: fix xfs_mark_inode_dirty during umount

    Christoph Hellwig authored gregkh committed
    commit 866e4ed upstream.
    
    During umount we do not add a dirty inode to the lru and wait for it to
    become clean first, but force writeback of data and metadata with
    I_WILL_FREE set.  Currently there is no way for XFS to detect that the
    inode has been redirtied for metadata operations, as we skip the
    mark_inode_dirty call during teardown.  Fix this by setting i_update_core
    nanually in that case, so that the inode gets flushed during inode reclaim.
    
    Alternatively we could enable calling mark_inode_dirty for inodes in
    I_WILL_FREE state, and let the VFS dirty tracking handle this.  I decided
    against this as we will get better I/O patterns from reclaim compared to
    the synchronous writeout in write_inode_now, and always marking the inode
    dirty in some way from xfs_mark_inode_dirty is a better safetly net in
    either case.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  12. @gregkh

    xfs: fix error handling for synchronous writes

    Christoph Hellwig authored gregkh committed
    If removed storage while synchronous buffer write underway,
    "xfslogd" hangs.
    
    Detailed log http://oss.sgi.com/archives/xfs/2011-07/msg00740.html
    
    Related work bfc6017
    "xfs: fix error handling for synchronous writes"
    
    Given that xfs_bwrite actually does the shutdown already after
    waiting for the b_iodone completion and given that we actually
    found that calling xfs_force_shutdown from inside
    xfs_buf_iodone_callbacks was a major contributor the problem
    it better to drop this call.
    
    Signed-off-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Alex Elder <aelder@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  13. @anbroid @gregkh

    USB: quirks: adding more quirky webcams to avoid squeaky audio

    anbroid authored gregkh committed
    commit 0d145d7 upstream.
    
    The following patch contains additional affected webcam models, on top of the
    patches commited to linux-next 2394d67
    and 5b253d8
    
    Signed-off-by: sordna <sordna@gmail.com>
    Cc: Oliver Neukum <oliver@neukum.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  14. @gregkh

    USB: add quirk for Logitech C600 web cam

    Josh Boyer authored gregkh committed
    commit 60c71ca upstream.
    
    We've had another report of the "chipmunk" sound on a Logitech C600 webcam.
    This patch resolves the issue.
    
    Signed-off-by: Josh Boyer <jwboyer@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  15. @gregkh

    USB: EHCI: fix HUB TT scheduling issue with iso transfer

    Thomas Poussevin authored gregkh committed
    commit 811c926 upstream.
    
    The current TT scheduling doesn't allow to play and then record on a
    full-speed device connected to a high speed hub.
    
    The IN iso stream can only start on the first uframe (0-2 for a 165 us)
    because of CSPLIT transactions.
    For the OUT iso stream there no such restriction. uframe 0-5 are possible.
    
    The idea of this patch is that the first uframe are precious (for IN TT iso
    stream) and we should allocate the last uframes first if possible.
    
    For that we reverse the order of uframe allocation (last uframe first).
    
    Here an example :
    
    hid interrupt stream
    ----------------------------------------------------------------------
    uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
    ----------------------------------------------------------------------
    max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
    ----------------------------------------------------------------------
    used usecs on a frame | 13  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
    ----------------------------------------------------------------------
    
    iso OUT stream
    ----------------------------------------------------------------------
    uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
    ----------------------------------------------------------------------
    max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
    ----------------------------------------------------------------------
    used usecs on a frame | 13  | 125 |  39 |  0  |  0  |  0  |  0  |  0  |
    ----------------------------------------------------------------------
    
    There no place for iso IN stream  (uframe 0-2 are used) and we got "cannot
    submit datapipe for urb 0, error -28: not enough bandwidth" error.
    
    With the patch this become.
    
    iso OUT stream
    ----------------------------------------------------------------------
    uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
    ----------------------------------------------------------------------
    max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
    ----------------------------------------------------------------------
    used usecs on a frame |  13 |  0  |  0  |  0  | 125 |  39 |  0  |  0  |
    ----------------------------------------------------------------------
    
    iso IN stream
    ----------------------------------------------------------------------
    uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
    ----------------------------------------------------------------------
    max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
    ----------------------------------------------------------------------
    used usecs on a frame |  13 |  0  | 125 | 40  | 125 |  39 |  0  |  0  |
    ----------------------------------------------------------------------
    
    Signed-off-by: Matthieu Castet <matthieu.castet@parrot.com>
    Signed-off-by: Thomas Poussevin <thomas.poussevin@parrot.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  16. @gregkh

    usb-storage: Accept 8020i-protocol commands longer than 12 bytes

    Alan Stern authored gregkh committed
    commit 2f640bf upstream.
    
    The 8020i protocol (also 8070i and QIC-157) uses 12-byte commands;
    shorter commands must be padded.  Simon Detheridge reports that his
    3-TB USB disk drive claims to use the 8020i protocol (which is
    normally meant for ATAPI devices like CD drives), and because of its
    large size, the disk drive requires the use of 16-byte commands.
    However the usb_stor_pad12_command() routine in usb-storage always
    sets the command length to 12, making the drive impossible to use.
    
    Since the SFF-8020i specification allows for 16-byte commands in
    future extensions, we may as well accept them.  This patch (as1490)
    changes usb_stor_pad12_command() to leave commands larger than 12
    bytes alone rather than truncating them.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Simon Detheridge <simon@widgit.com>
    CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  17. @amworsley @gregkh

    USB: Fix Corruption issue in USB ftdi driver ftdi_sio.c

    amworsley authored gregkh committed
    commit b1ffb4c upstream.
    
    Fix for ftdi_set_termios() glitching output
    
    ftdi_set_termios() is constantly setting the baud rate, data bits and parity
    unnecessarily on every call, . When called while characters are being
    transmitted can cause the FTDI chip to corrupt the serial port bit stream
    output by stalling the output half a bit during the output of a character.
    Simple fix by skipping this setting if the baud rate/data bits/parity are
    unchanged.
    
    Signed-off-by: Andrew Worsley <amworsley@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  18. @gregkh

    USB: ark3116 initialisation fix

    Bart Hartgers authored gregkh committed
    commit 583182b upstream.
    
    This patch for the usb serial ark3116 driver fixes an initialisation
    ordering bug that gets triggered on hotplug when using at least recent
    debian/ubuntu userspace. Without it, ark3116 serial cables don't work.
    
    Signed-off-by: Bart Hartgers <bart.hartgers@gmail.com>
    Tested-by: law_ence.dev@ntlworld.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  19. @gregkh

    USB: workaround for bug in old version of GCC

    Alan Stern authored gregkh committed
    commit 97ff22e upstream.
    
    This patch (as1491) works around a bug in GCC-3.4.6, which is still
    supposed to be supported.  The number of microseconds in the udelay()
    call in quirk_usb_disable_ehci() is fixed at 100, but the compiler
    doesn't understand this and generates a link-time error.  So we
    replace the otherwise unused variable "delta" with a simple constant
    100.  This same pattern is already used in other delay loops in that
    source file.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Konrad Rzepecki <krzepecki@dentonet.pl>
    Tested-by: Konrad Rzepecki <krzepecki@dentonet.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  20. @gregkh

    USB: cdc-acm: Fix disconnect() vs close() race

    Havard Skinnemoen authored gregkh committed
    commit 5dc2470 upstream.
    
    There's a race between the USB disconnect handler and the TTY close
    handler which may cause the acm object to be freed while it's still
    being used. This may lead to things like
    
    http://article.gmane.org/gmane.linux.usb.general/54250
    
    and
    
    https://lkml.org/lkml/2011/5/29/64
    
    This is the simplest fix I could come up with. Holding on to open_mutex
    while closing the TTY device prevents acm_disconnect() from freeing the
    acm object between acm->port.count drops to 0 and the TTY side of the
    cleanups are finalized.
    
    Signed-off-by: Havard Skinnemoen <hskinnemoen@google.com>
    Cc: Oliver Neukum <oliver@neukum.name>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  21. @udknight @gregkh

    USB: serial: pl2303: rm duplicate id

    udknight authored gregkh committed
    commit 0c16595 upstream.
    
    I get report from customer that his usb-serial
    converter doesn't work well,it sometimes work,
    but sometimes it doesn't.
    
    The usb-serial converter's id:
    vendor_id product_id
    0x4348    0x5523
    
    Then I search the usb-serial codes, and there are
    two drivers announce support this device, pl2303
    and ch341, commit 026dfaf cause it. Through many
    times to test, ch341 works well with this device,
    and pl2303 doesn't work quite often(it just work quite little).
    
    ch341 works well with this device, so we doesn't
    need pl2303 to support.I try to revert 026dfaf first,
    but it failed. So I prepare this patch by hand to revert it.
    
    Signed-off-by: Wang YanQing <Udknight@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  22. @wferi @gregkh

    USB: option: add PID of Huawei E173s 3G modem

    wferi authored gregkh committed
    commit 4aa3648 upstream.
    
    Signed-off-by: Ferenc Wagner <wferi@niif.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  23. @gregkh

    USB: option: release new PID for ZTE 3G modem

    zheng.zhijian@zte.com.cn authored gregkh committed
    commit 46b5a27 upstream.
    
    This patch adds new PIDs for ZTE 3G modem, after we confirm it and tested.
    Thanks for Dan's work at kernel option devier.
    
    Signed-off-by: Alvin.Zheng <zheng.zhijian@zte.com.cn>
    Signed-off-by: wsalvin <wsalvin@yahoo.com.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  24. @gregkh

    USB: XHCI: resume root hubs when the controller resumes

    Alan Stern authored gregkh committed
    commit f69e312 upstream.
    
    This patch (as1494) fixes a problem in xhci-hcd's resume routine.
    When the controller is runtime-resumed, this can only mean that one of
    the two root hubs has made a wakeup request and therefore needs to be
    resumed as well.  Rather than try to determine which root hub requires
    attention (which might be difficult in the case where a new
    non-SuperSpeed device has been plugged in), the patch simply resumes
    both root hubs.
    
    Without this change, there is a race: The controller might be put back
    to sleep before it can activate its IRQ line, and the wakeup condition
    might never get handled.
    
    The patch also simplifies the logic in xhci_resume a little, combining
    some repeated flag settings into a single pair of statements.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  25. @gregkh

    usb, xhci: fix lockdep warning on endpoint timeout

    Don Zickus authored gregkh committed
    commit f43d623 upstream.
    
    While debugging a usb3 problem, I stumbled upon this lockdep warning.
    
    Oct 18 21:41:17 dhcp47-74 kernel: =================================
    Oct 18 21:41:17 dhcp47-74 kernel: [ INFO: inconsistent lock state ]
    Oct 18 21:41:17 dhcp47-74 kernel: 3.1.0-rc4nmi+ #456
    Oct 18 21:41:17 dhcp47-74 kernel: ---------------------------------
    Oct 18 21:41:17 dhcp47-74 kernel: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
    Oct 18 21:41:17 dhcp47-74 kernel: swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
    Oct 18 21:41:17 dhcp47-74 kernel: (&(&xhci->lock)->rlock){?.-...}, at: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
    Oct 18 21:41:17 dhcp47-74 kernel: {IN-HARDIRQ-W} state was registered at:
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8109a941>] __lock_acquire+0x781/0x1660
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8109bed7>] lock_acquire+0x97/0x170
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa02299fa>] xhci_irq+0x3a/0x1960 [xhci_hcd]
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa022b351>] xhci_msi_irq+0x31/0x40 [xhci_hcd]
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d2305>] handle_irq_event_percpu+0x85/0x320
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d25e8>] handle_irq_event+0x48/0x70
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d537d>] handle_edge_irq+0x6d/0x130
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810048c9>] handle_irq+0x49/0xa0
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8150d56d>] do_IRQ+0x5d/0xe0
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff815029b0>] ret_from_intr+0x0/0x13
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81388aca>] usb_set_device_state+0x8a/0x180
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8138f038>] usb_add_hcd+0x2b8/0x730
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa022ed7e>] xhci_pci_probe+0x9e/0xd4 [xhci_hcd]
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127915f>] local_pci_probe+0x5f/0xd0
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127a569>] pci_device_probe+0x119/0x120
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81334473>] driver_probe_device+0xa3/0x2c0
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8133473b>] __driver_attach+0xab/0xb0
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8133373c>] bus_for_each_dev+0x6c/0xa0
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff813341fe>] driver_attach+0x1e/0x20
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81333b88>] bus_add_driver+0x1f8/0x2b0
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81334df6>] driver_register+0x76/0x140
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127a7c6>] __pci_register_driver+0x66/0xe0
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa013c04a>] snd_timer_find+0x4a/0x70 [snd_timer]
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa013c00e>] snd_timer_find+0xe/0x70 [snd_timer]
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810001d3>] do_one_initcall+0x43/0x180
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810a9ed2>] sys_init_module+0x92/0x1f0
    Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8150ab6b>] system_call_fastpath+0x16/0x1b
    Oct 18 21:41:17 dhcp47-74 kernel: irq event stamp: 631984
    Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last  enabled at (631984): [<ffffffff81502720>] _raw_spin_unlock_irq+0x30/0x50
    Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last disabled at (631983): [<ffffffff81501c49>] _raw_spin_lock_irq+0x19/0x90
    Oct 18 21:41:17 dhcp47-74 kernel: softirqs last  enabled at (631980): [<ffffffff8105ff63>] _local_bh_enable+0x13/0x20
    Oct 18 21:41:17 dhcp47-74 kernel: softirqs last disabled at (631981): [<ffffffff8150ce6c>] call_softirq+0x1c/0x30
    Oct 18 21:41:17 dhcp47-74 kernel:
    Oct 18 21:41:17 dhcp47-74 kernel: other info that might help us debug this:
    Oct 18 21:41:17 dhcp47-74 kernel: Possible unsafe locking scenario:
    Oct 18 21:41:17 dhcp47-74 kernel:
    Oct 18 21:41:17 dhcp47-74 kernel:       CPU0
    Oct 18 21:41:17 dhcp47-74 kernel:       ----
    Oct 18 21:41:17 dhcp47-74 kernel:  lock(&(&xhci->lock)->rlock);
    Oct 18 21:41:17 dhcp47-74 kernel:  <Interrupt>
    Oct 18 21:41:17 dhcp47-74 kernel:    lock(&(&xhci->lock)->rlock);
    Oct 18 21:41:17 dhcp47-74 kernel:
    Oct 18 21:41:17 dhcp47-74 kernel: *** DEADLOCK ***
    Oct 18 21:41:17 dhcp47-74 kernel:
    Oct 18 21:41:17 dhcp47-74 kernel: 1 lock held by swapper/0:
    Oct 18 21:41:17 dhcp47-74 kernel: #0:  (&ep->stop_cmd_timer){+.-...}, at: [<ffffffff8106abf2>] run_timer_softirq+0x162/0x570
    Oct 18 21:41:17 dhcp47-74 kernel:
    Oct 18 21:41:17 dhcp47-74 kernel: stack backtrace:
    Oct 18 21:41:17 dhcp47-74 kernel: Pid: 0, comm: swapper Tainted: G        W   3.1.0-rc4nmi+ #456
    Oct 18 21:41:17 dhcp47-74 kernel: Call Trace:
    Oct 18 21:41:17 dhcp47-74 kernel: <IRQ>  [<ffffffff81098ed7>] print_usage_bug+0x227/0x270
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810999c6>] mark_lock+0x346/0x410
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109a7de>] __lock_acquire+0x61e/0x1660
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81099893>] ? mark_lock+0x213/0x410
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109bed7>] lock_acquire+0x97/0x170
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106ac9d>] run_timer_softirq+0x20d/0x570
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228960>] ? xhci_queue_isoc_tx_prepare+0x8e0/0x8e0 [xhci_hcd]
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810604d2>] __do_softirq+0xf2/0x3f0
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81020edd>] ? lapic_next_event+0x1d/0x30
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81090d4e>] ? clockevents_program_event+0x5e/0x90
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150ce6c>] call_softirq+0x1c/0x30
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8100484d>] do_softirq+0x8d/0xc0
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8105ff35>] irq_exit+0xe5/0x100
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150d65e>] smp_apic_timer_interrupt+0x6e/0x99
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150b6f0>] apic_timer_interrupt+0x70/0x80
    Oct 18 21:41:17 dhcp47-74 kernel: <EOI>  [<ffffffff81095d8d>] ? trace_hardirqs_off+0xd/0x10
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb76>] ? acpi_idle_enter_bm+0x227/0x25b
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb71>] ? acpi_idle_enter_bm+0x222/0x25b
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff813eda63>] cpuidle_idle_call+0x103/0x290
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81002155>] cpu_idle+0xe5/0x160
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7f50>] rest_init+0xe0/0xf0
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7e70>] ? csum_partial_copy_generic+0x170/0x170
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8e23>] start_kernel+0x3fc/0x407
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8321>] x86_64_start_reservations+0x131/0x135
    Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8412>] x86_64_start_kernel+0xed/0xf4
    Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
    Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
    Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
    Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -110
    Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -22
    Oct 18 21:41:17 dhcp47-74 kernel: hub 3-0:1.0: cannot disable port 4 (err = -19)
    
    Basically what is happening is in xhci_stop_endpoint_command_watchdog()
    the xhci->lock is grabbed with just spin_lock.  What lockdep deduces is
    that if an interrupt occurred while in this function it would deadlock
    with xhci_irq because that function also grabs the xhci->lock.
    
    Fixing it is trivial by using spin_lock_irqsave instead.
    
    This should be queued to stable kernels as far back as 2.6.33.
    
    Signed-off-by: Don Zickus <dzickus@redhat.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  26. @gregkh

    usb, xhci: Clear warm reset change event during init

    Don Zickus authored gregkh committed
    commit 79c3dd8 upstream.
    
    I noticed on my Panther Point system that I wasn't getting hotplug events
    for my usb3.0 disk on a usb3 port.  I tracked it down to the fact that the
    system had the warm reset change bit still set.  This seemed to block future
    events from being received, including a hotplug event.
    
    Clearing this bit during initialization allowed the hotplug event to be
    received and the disk to be recognized correctly.
    
    This patch should be backported to kernels as old as 2.6.39.
    
    Signed-off-by: Don Zickus <dzickus@redhat.com>
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  27. @gregkh

    xhci: Set slot and ep0 flags for address command.

    Sarah Sharp authored gregkh committed
    commit d31c285 upstream.
    
    Matt's AsMedia xHCI host controller was responding with a Context Error
    to an address device command after a configured device reset.  Some
    sequence of events leads both the slot and endpoint zero add flags
    cleared to zero, which the AsMedia host doesn't like:
    
    [  223.701839] xhci_hcd 0000:03:00.0: Slot ID 1 Input Context:
    [  223.701841] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc00 (dma) 0x000000 - drop flags
    [  223.701843] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc00 (dma) 0x000000 - add flags
    [  223.701846] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc00 (dma) 0x000000 - rsvd2[0]
    [  223.701848] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc00 (dma) 0x000000 - rsvd2[1]
    [  223.701850] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc01 (dma) 0x000000 - rsvd2[2]
    [  223.701852] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc01 (dma) 0x000000 - rsvd2[3]
    [  223.701854] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc01 (dma) 0x000000 - rsvd2[4]
    [  223.701857] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc01 (dma) 0x000000 - rsvd2[5]
    [  223.701858] xhci_hcd 0000:03:00.0: Slot Context:
    [  223.701860] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc02 (dma) 0x8400000 - dev_info
    [  223.701862] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc02 (dma) 0x010000 - dev_info2
    [  223.701864] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc02 (dma) 0x000000 - tt_info
    [  223.701866] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc02 (dma) 0x000000 - dev_state
    [  223.701869] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc03 (dma) 0x000000 - rsvd[0]
    [  223.701871] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc03 (dma) 0x000000 - rsvd[1]
    [  223.701873] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc03 (dma) 0x000000 - rsvd[2]
    [  223.701875] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc03 (dma) 0x000000 - rsvd[3]
    [  223.701877] xhci_hcd 0000:03:00.0: Endpoint 00 Context:
    [  223.701879] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc04 (dma) 0x000000 - ep_info
    [  223.701881] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc04 (dma) 0x2000026 - ep_info2
    [  223.701883] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc04 (dma) 0xffffe8e0 - deq
    [  223.701885] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc05 (dma) 0x000000 - tx_info
    [  223.701887] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc05 (dma) 0x000000 - rsvd[0]
    [  223.701889] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc05 (dma) 0x000000 - rsvd[1]
    [  223.701892] xhci_hcd 0000:03:00.0: @ffff880 (virt) @ffffc05 (dma) 0x000000 - rsvd[2]
    ...
    [  223.701927] xhci_hcd 0000:03:00.0: // Ding dong!
    [  223.701992] xhci_hcd 0000:03:00.0: Setup ERROR: address device command for slot 1.
    
    The xHCI spec says that both flags must be set to one for the Address
    Device command.  When the device is first enumerated,
    xhci_setup_addressable_virt_dev() does set those flags.  However, when
    the device is addressed after it has been reset in the configured state,
    xhci_setup_addressable_virt_dev() is not called, and
    xhci_copy_ep0_dequeue_into_input_ctx() is called instead.  That function
    relies on the flags being set up by previous commands, which apparently
    isn't a good assumption.
    
    Move the setting of the flags into the common parent function.
    
    This should be queued for stable kernels as old as 2.6.35, since that
    was the first introduction of xhci_copy_ep0_dequeue_into_input_ctx.
    
    Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Tested-by: Matt <mdm@iinet.net.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  28. @claudioscordino @gregkh

    drivers/base/node.c: fix compilation error with older versions of gcc

    claudioscordino authored gregkh committed
    commit 91a13c2 upstream.
    
    Patch to fix the error message "directives may not be used inside a macro
    argument" which appears when the kernel is compiled for the cris architecture.
    
    Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  29. @AxelLin @gregkh

    pcie-gadget-spear: Add "platform:" prefix for platform modalias

    AxelLin authored gregkh committed
    commit 161f141 upstream.
    
    Since 43cc71e (platform: prefix MODALIAS
    with "platform:"), the platform modalias is prefixed with "platform:".
    
    Signed-off-by: Axel Lin <axel.lin@gmail.com>
    Acked-by: Pratyush Anand <pratyush.anand@st.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  30. @gregkh

    nfs: when attempting to open a directory, fall back on normal lookup …

    Jeff Layton authored gregkh committed
    …(try #5)
    
    commit 1788ea6 upstream.
    
    commit d953126 changed how nfs_atomic_lookup handles an -EISDIR return
    from an OPEN call. Prior to that patch, that caused the client to fall
    back to doing a normal lookup. When that patch went in, the code began
    returning that error to userspace. The d_revalidate codepath however
    never had the corresponding change, so it was still possible to end up
    with a NULL ctx->state pointer after that.
    
    That patch caused a regression. When we attempt to open a directory that
    does not have a cached dentry, that open now errors out with EISDIR. If
    you attempt the same open with a cached dentry, it will succeed.
    
    Fix this by reverting the change in nfs_atomic_lookup and allowing
    attempts to open directories to fall back to a normal lookup
    
    Also, add a NFSv4-specific f_ops->open routine that just returns
    -ENOTDIR. This should never be called if things are working properly,
    but if it ever is, then the dprintk may help in debugging.
    
    To facilitate this, a new file_operations field is also added to the
    nfs_rpc_ops struct.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  31. @gregkh

    TTY: ldisc, wait for ldisc infinitely in hangup

    Jiri Slaby authored gregkh committed
    commit 0c73c08 upstream.
    
    For /dev/console case, we do not kill all ldisc users. It's due to
    redirected_tty_write test in __tty_hangup. In that case there still
    might be a process waiting e.g. in n_tty_read for input.
    
    We wait for such processes to disappear. The problem is that we use a
    timeout. After this timeout, we continue closing the ldisc and start
    freeing tty resources. It obviously leads to crashes when the other
    process is woken.
    
    So to fix this, we wait infinitely before reiniting the ldisc. (The
    tiocsetd remains untouched -- times out after 5s.)
    
    This is nicely reproducible with this run from shell:
      exec 0<>/dev/console 1<>/dev/console 2<>/dev/console
    and stopping a getty like:
      systemctl stop serial-getty@ttyS0.service
    
    The crash proper may be produced only under load or with constified
    timing the same as for 92f6fa0.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Dave Young <hidave.darkstar@gmail.com>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Dmitriy Matrosov <sgf.dma@gmail.com>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  32. @gregkh

    TTY: ldisc, move wait idle to caller

    Jiri Slaby authored gregkh committed
    commit 3004207 upstream.
    
    It is the only place where reinit is called from. And we really need
    to wait for the old ldisc to go once. Actually this is the place where
    the waiting originally was (before removed and re-added later).
    
    This will make the fix in the following patch easier to implement.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Dave Young <hidave.darkstar@gmail.com>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Dmitriy Matrosov <sgf.dma@gmail.com>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  33. @gregkh

    TTY: ldisc, allow waiting for ldisc arbitrarily long

    Jiri Slaby authored gregkh committed
    commit df92d05 upstream.
    
    To fix a nasty bug in ldisc hup vs. reinit we need to wait infinitely
    long for ldisc to be gone. So here we add a parameter to
    tty_ldisc_wait_idle to allow that.
    
    This is only a preparation for the real fix which is done in the
    following patches.
    
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Dave Young <hidave.darkstar@gmail.com>
    Cc: Dave Jones <davej@redhat.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Dmitriy Matrosov <sgf.dma@gmail.com>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  34. @bebarino @gregkh

    tty: hvc_dcc: Fix duplicate character inputs

    bebarino authored gregkh committed
    commit c2a3e84 upstream.
    
    Reading from the DCC grabs a character from the buffer and
    clears the status bit. Since this is a context-changing
    operation, instructions following the character read that rely on
    the status bit being accurate need to be synchronized with an
    ISB.
    
    In this case, the status bit check needs to execute after the
    character read otherwise we run the risk of reading the character
    and checking the status bit before the read can clear the status
    bit in the first place. When this happens, the user will see the
    same character they typed twice, instead of once.
    
    Add an ISB after the read and the write, so that the status check
    is synchronized with the read/write operations.
    
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
  35. @gregkh

    pch_uart: Support new device LAPIS Semiconductor ML7831 IOH

    Tomoya MORINAGA authored gregkh committed
    commit 8249f74 upstream.
    
    ML7831 is companion chip for Intel Atom E6xx series.
    
    Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
    Acked-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Something went wrong with that request. Please try again.