1. 29 Aug, 2010 1 commit
    • Stefan Richter's avatar
      firewire: ohci: work around VIA and NEC PHY packet reception bug · a4dc090b
      Stefan Richter authored
      VIA VT6306, VIA VT6308, and NEC OrangeLink controllers do not write
      packet event codes for received PHY packets (or perhaps write
      evt_no_status, hard to tell).  Work around it by overwriting the
      packet's ACK by ack_complete, so that upper layers that listen to PHY
      packet reception get to see these packets.
      
      (Also tested:  TI TSB82AA2, TI TSB43AB22/A, TI XIO2213A, Agere FW643,
      JMicron JMB381 --- these do not exhibit this bug.)
      
      Clemens proposed a quirks flag for that, IOW whitelist known misbehaving
      controllers for this workaround.  Though to me it seems harmless enough
      to enable for all controllers.
      
      The log_ar_at_event() debug log will continue to show the original
      status from the DMA unit.
      
      Reported-by: Clemens Ladisch <clemens@ladisch.de> (VT6308)
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      a4dc090b
  2. 19 Aug, 2010 4 commits
    • Clemens Ladisch's avatar
      firewire: core: do not use del_timer_sync() in interrupt context · 2222bcb7
      Clemens Ladisch authored
      Because we might be in interrupt context, replace del_timer_sync() with
      del_timer().  If the timer is already running, we know that it will
      clean up the transaction, so we do not need to do any further processing
      in the normal transaction handler.
      
      Many thanks to Yong Zhang for diagnosing this.
      Reported-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      2222bcb7
    • Stefan Richter's avatar
      firewire: net: fix unicast reception RCODE in failure paths · 1bf145fe
      Stefan Richter authored
      The incoming request hander fwnet_receive_packet() expects subsequent
      datagram handling code to return non-zero on errors.  However, almost
      none of the failure paths did so.  Fix them all.
      
      (This error reporting is used to send and RCODE_CONFLICT_ERROR to the
      sender node in such failure cases.  Two modes of failure exist:  Out of
      memory, or firewire-net is unaware of any peer node to which a fragment
      or an ARP packet belongs.  However, it is unclear whether a sender can
      actually make use of such information.  A Linux peer apparently can't.
      Maybe it should all be simplified to void functions.)
      Reported-by: default avatarJulia Lawall <julia@diku.dk>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      1bf145fe
    • Stefan Richter's avatar
      firewire: sbp2: fix stall with "Unsolicited response" · a481e97d
      Stefan Richter authored
      Fix I/O stalls with some 4-bay RAID enclosures which are based on
      OXUF936QSE:
        - Onnto dataTale RSM4QO, old firmware (not anymore with current
          firmware),
        - inXtron Hydra Super-S LCM, old as well as current firmware
      when used in RAID-5 mode, perhaps also in other RAID modes.
      
      The stalls happen during heavy or moderate disk traffic in periods that
      are a multiple of 5 minutes, roughly twice per hour.  They are caused
      by the target responding too late to an ORB_Pointer register write:
      The target responds after Split_Timeout, hence firewire-core cancels
      the transaction, and firewire-sbp2 fails the SCSI request.  The SCSI
      core retries the request, that fails again (and again), hence SCSI core
      calls firewire-sbp2's abort handler (and even the Management_Agent
      register write in the abort handler has the transaction timeout
      problem).
      
      During all that, the process which issued the I/O is stalled in I/O
      wait state.
      
      Meanwhile, the target actually acts on the first failed SCSI request:
      It responds to the ORB_Pointer write later (seen in the kernel log as
      "firewire_core: Unsolicited response") and also finishes the SCSI
      request with proper status (seen in the kernel log as "firewire_sbp2:
      status write for unknown orb").
      
      So let's just ignore RCODE_CANCELLED in the transaction callback and
      wait for the target to complete the ORB nevertheless.  This requires
      a small modification is sbp2_cancel_orbs(); it now needs to call
      orb->callback() regardless whether fw_cancel_transaction() found the
      transaction unfinished or finished.
      
      A different solution is to increase Split_Timeout on the local node.
      (Tested: 2000ms timeout; maybe 1000ms or something like that works too.
      200ms is insufficient.  Standard is 100ms.)  However, I rather not do
      this because any software on any node could change the Split_Timeout to
      something unsuitable.  Or such a large Split_Timeout may be undesirable
      for other purposes.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      a481e97d
    • Stefan Richter's avatar
      firewire: sbp2: fix memory leak in sbp2_cancel_orbs or at send error · 6c74340b
      Stefan Richter authored
      When an ORB was canceled (Command ORB i.e. SCSI request timed out, or
      Management ORB timed out), or there was a send error in the initial
      transaction, we missed to drop one of the ORB's references and thus
      leaked memory.
      
      Background:
      In total, we hold 3 references to each Operation Request Block:
        - 1 during sbp2_scsi_queuecommand() or sbp2_send_management_orb()
          respectively,
        - 1 for the duration of the write transaction to the ORB_Pointer or
          Management_Agent register of the target,
        - 1 for as long as the ORB stays within the lu->orb_list, until
          the ORB is unlinked from the list and the orb->callback was
          executed.
      
      The latter one of these 3 references is finished
        - normally by sbp2_status_write() when the target wrote status
          for a pending ORB,
        - or by sbp2_cancel_orbs() in case of an ORB time-out,
        - or by complete_transaction() in case of a send error.
      Of them, the latter two lacked the kref_put.
      
      Add the missing kref_put()s.  Add comments to the gets and puts of
      references for transaction callbacks and ORB callbacks so that it is
      easier to see what is supposed to happen.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      6c74340b
  3. 05 Aug, 2010 1 commit
  4. 02 Aug, 2010 2 commits
  5. 01 Aug, 2010 2 commits
  6. 31 Jul, 2010 5 commits
  7. 30 Jul, 2010 8 commits
  8. 29 Jul, 2010 17 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6 · a2dccdb2
      Linus Torvalds authored
      * 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
        [S390] etr: fix clock synchronization race
        [S390] Fix IRQ tracing in case of PER
      a2dccdb2
    • Linus Torvalds's avatar
    • Linus Torvalds's avatar
      Merge branch 'fix/hda' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 · e271e872
      Linus Torvalds authored
      * 'fix/hda' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
        ALSA: hda - Add a PC-beep workaround for ASUS P5-V
        ALSA: hda - Assume PC-beep as default for Realtek
        ALSA: hda - Don't register beep input device when no beep is available
        ALSA: hda - Fix pin-detection of Nvidia HDMI
      e271e872
    • David Howells's avatar
      CRED: Fix __task_cred()'s lockdep check and banner comment · 8f92054e
      David Howells authored
      Fix __task_cred()'s lockdep check by removing the following validation
      condition:
      
      	lockdep_tasklist_lock_is_held()
      
      as commit_creds() does not take the tasklist_lock, and nor do most of the
      functions that call it, so this check is pointless and it can prevent
      detection of the RCU lock not being held if the tasklist_lock is held.
      
      Instead, add the following validation condition:
      
      	task->exit_state >= 0
      
      to permit the access if the target task is dead and therefore unable to change
      its own credentials.
      
      Fix __task_cred()'s comment to:
      
       (1) discard the bit that says that the caller must prevent the target task
           from being deleted.  That shouldn't need saying.
      
       (2) Add a comment indicating the result of __task_cred() should not be passed
           directly to get_cred(), but rather than get_task_cred() should be used
           instead.
      
      Also put a note into the documentation to enforce this point there too.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8f92054e
    • David Howells's avatar
      CRED: Fix get_task_cred() and task_state() to not resurrect dead credentials · de09a977
      David Howells authored
      It's possible for get_task_cred() as it currently stands to 'corrupt' a set of
      credentials by incrementing their usage count after their replacement by the
      task being accessed.
      
      What happens is that get_task_cred() can race with commit_creds():
      
      	TASK_1			TASK_2			RCU_CLEANER
      	-->get_task_cred(TASK_2)
      	rcu_read_lock()
      	__cred = __task_cred(TASK_2)
      				-->commit_creds()
      				old_cred = TASK_2->real_cred
      				TASK_2->real_cred = ...
      				put_cred(old_cred)
      				  call_rcu(old_cred)
      		[__cred->usage == 0]
      	get_cred(__cred)
      		[__cred->usage == 1]
      	rcu_read_unlock()
      							-->put_cred_rcu()
      							[__cred->usage == 1]
      							panic()
      
      However, since a tasks credentials are generally not changed very often, we can
      reasonably make use of a loop involving reading the creds pointer and using
      atomic_inc_not_zero() to attempt to increment it if it hasn't already hit zero.
      
      If successful, we can safely return the credentials in the knowledge that, even
      if the task we're accessing has released them, they haven't gone to the RCU
      cleanup code.
      
      We then change task_state() in procfs to use get_task_cred() rather than
      calling get_cred() on the result of __task_cred(), as that suffers from the
      same problem.
      
      Without this change, a BUG_ON in __put_cred() or in put_cred_rcu() can be
      tripped when it is noticed that the usage count is not zero as it ought to be,
      for example:
      
      kernel BUG at kernel/cred.c:168!
      invalid opcode: 0000 [#1] SMP
      last sysfs file: /sys/kernel/mm/ksm/run
      CPU 0
      Pid: 2436, comm: master Not tainted 2.6.33.3-85.fc13.x86_64 #1 0HR330/OptiPlex
      745
      RIP: 0010:[<ffffffff81069881>]  [<ffffffff81069881>] __put_cred+0xc/0x45
      RSP: 0018:ffff88019e7e9eb8  EFLAGS: 00010202
      RAX: 0000000000000001 RBX: ffff880161514480 RCX: 00000000ffffffff
      RDX: 00000000ffffffff RSI: ffff880140c690c0 RDI: ffff880140c690c0
      RBP: ffff88019e7e9eb8 R08: 00000000000000d0 R09: 0000000000000000
      R10: 0000000000000001 R11: 0000000000000040 R12: ffff880140c690c0
      R13: ffff88019e77aea0 R14: 00007fff336b0a5c R15: 0000000000000001
      FS:  00007f12f50d97c0(0000) GS:ffff880007400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f8f461bc000 CR3: 00000001b26ce000 CR4: 00000000000006f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process master (pid: 2436, threadinfo ffff88019e7e8000, task ffff88019e77aea0)
      Stack:
       ffff88019e7e9ec8 ffffffff810698cd ffff88019e7e9ef8 ffffffff81069b45
      <0> ffff880161514180 ffff880161514480 ffff880161514180 0000000000000000
      <0> ffff88019e7e9f28 ffffffff8106aace 0000000000000001 0000000000000246
      Call Trace:
       [<ffffffff810698cd>] put_cred+0x13/0x15
       [<ffffffff81069b45>] commit_creds+0x16b/0x175
       [<ffffffff8106aace>] set_current_groups+0x47/0x4e
       [<ffffffff8106ac89>] sys_setgroups+0xf6/0x105
       [<ffffffff81009b02>] system_call_fastpath+0x16/0x1b
      Code: 48 8d 71 ff e8 7e 4e 15 00 85 c0 78 0b 8b 75 ec 48 89 df e8 ef 4a 15 00
      48 83 c4 18 5b c9 c3 55 8b 07 8b 07 48 89 e5 85 c0 74 04 <0f> 0b eb fe 65 48 8b
      04 25 00 cc 00 00 48 3b b8 58 04 00 00 75
      RIP  [<ffffffff81069881>] __put_cred+0xc/0x45
       RSP <ffff88019e7e9eb8>
      ---[ end trace df391256a100ebdd ]---
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      de09a977
    • Stefan Richter's avatar
      firewire: add isochronous multichannel reception · 872e330e
      Stefan Richter authored
      This adds the DMA context programming and userspace ABI for multichannel
      reception, i.e. for listening on multiple channel numbers by means of a
      single DMA context.
      
      The use case is reception of more streams than there are IR DMA units
      offered by the link layer.  This is already implemented by the older
      ohci1394 + ieee1394 + raw1394 stack.  And as discussed recently on
      linux1394-devel, this feature is occasionally used in practice.
      
      The big drawbacks of this mode are that buffer layout and interrupt
      generation necessarily differ from single-channel reception:  Headers
      and trailers are not stripped from packets, packets are not aligned with
      buffer chunks, interrupts are per buffer chunk, not per packet.
      
      These drawbacks also cause a rather hefty code footprint to support this
      rarely used OHCI-1394 feature.  (367 lines added, among them 94 lines of
      added userspace ABI documentation.)
      
      This implementation enforces that a multichannel reception context may
      only listen to channels to which no single-channel context on the same
      link layer is presently listening to.  OHCI-1394 would allow to overlay
      single-channel contexts by the multi-channel context, but this would be
      a departure from the present first-come-first-served policy of IR
      context creation.
      
      The implementation is heavily based on an earlier one by Jay Fenlason.
      Thanks Jay.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      872e330e
    • Stefan Richter's avatar
      firewire: core: small clarifications in core-cdev · ae2a9766
      Stefan Richter authored
      Make a note on the seemingly unused linux/sched.h.
      Rename an irritatingly named variable.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      ae2a9766
    • Stefan Richter's avatar
      firewire: core: remove unused code · 69e61d0c
      Stefan Richter authored
      ioctl_create_iso_context enforces ctx->header_size >= 4.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      69e61d0c
    • Stefan Richter's avatar
      firewire: ohci: release channel in error path · e5b06c07
      Stefan Richter authored
      firewire-ohci keeps book of which isochronous channels are occupied by
      IR DMA contexts, so that there cannot be more than one context listening
      to a certain channel.
      
      If IR context creation failed due to an out-of-memory condition, this
      bookkeeping leaked a channel.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      e5b06c07
    • Stefan Richter's avatar
      firewire: ohci: use memory barriers to order descriptor updates · 071595eb
      Stefan Richter authored
      When we append to a DMA program, we need to ensure that the order in
      which initialization of the new descriptors and update of the
      branch_address of the old tail descriptor, as seen by the PCI device,
      happen as intended.
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      071595eb
    • Wim Van Sebroeck's avatar
      watchdog: update MAINTAINERS entry · 230a5cef
      Wim Van Sebroeck authored
      Add Mailing-list and website to watchdog MAINTAINERS entry.
      Signed-off-by: default avatarWim Van Sebroeck <wim@iguana.be>
      230a5cef
    • Takashi Iwai's avatar
      ALSA: hda - Add a PC-beep workaround for ASUS P5-V · dc1eae25
      Takashi Iwai authored
      ASUS P5-V provides a SSID that unexpectedly matches with the value
      compilant with Realtek's specification.  Thus the driver interprets
      it badly, resulting in non-working PC beep.
      
      This patch adds a white-list for such a case; a white-list of known
      devices with working PC beep.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      dc1eae25
    • Russell King's avatar
      ARM: Add barriers to io{read,write}{8,16,32} accessors as well · b92b3612
      Russell King authored
      The ioread/iowrite accessors also need barriers as they're used in
      place of readl/writel et.al. in portable drivers.  Create __iormb()
      and __iowmb() which are conditionally defined to be barriers dependent
      on ARM_DMA_MEM_BUFFERABLE, and always use these macros in the accessors.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b92b3612
    • Catalin Marinas's avatar
      ARM: 6273/1: Add barriers to the I/O accessors if ARM_DMA_MEM_BUFFERABLE · 79f64dbf
      Catalin Marinas authored
      When the coherent DMA buffers are mapped as Normal Non-cacheable
      (ARM_DMA_MEM_BUFFERABLE enabled), buffer accesses are no longer ordered
      with Device memory accesses causing failures in device drivers that do
      not use the mandatory memory barriers before starting a DMA transfer.
      LKML discussions led to the conclusion that such barriers have to be
      added to the I/O accessors:
      
      http://thread.gmane.org/gmane.linux.kernel/683509/focus=686153
      http://thread.gmane.org/gmane.linux.ide/46414
      http://thread.gmane.org/gmane.linux.kernel.cross-arch/5250
      
      This patch introduces a wmb() barrier to the write*() I/O accessors to
      handle the situations where Normal Non-cacheable writes are still in the
      processor (or L2 cache controller) write buffer before a DMA transfer
      command is issued. For the read*() accessors, a rmb() is introduced
      after the I/O to avoid speculative loads where the driver polls for a
      DMA transfer ready bit.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      79f64dbf
    • Catalin Marinas's avatar
      ARM: 6272/1: Convert L2x0 to use the IO relaxed operations · 6775a558
      Catalin Marinas authored
      This patch is in preparation for a subsequent patch which adds barriers
      to the I/O accessors. Since the mandatory barriers may do an L2 cache
      sync, this patch avoids a recursive call into l2x0_cache_sync() via the
      write*() accessors and wmb() and a call into l2x0_cache_sync() with the
      l2x0_lock held.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      6775a558
    • Catalin Marinas's avatar
      ARM: 6271/1: Introduce *_relaxed() I/O accessors · e936771a
      Catalin Marinas authored
      This patch introduces readl*_relaxed()/write*_relaxed() as the main I/O
      accessors (when __mem_pci is defined). The standard read*()/write*()
      macros are now based on the relaxed accessors.
      
      This patch is in preparation for a subsequent patch which adds barriers
      to the I/O accessors.
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      e936771a
    • Rabin Vincent's avatar
      ARM: 6275/1: ux500: don't use writeb() in uncompress.h · 661f10f6
      Rabin Vincent authored
      Don't use writeb() in uncompress.h, to avoid the following build errors
      when the "Add barriers to the I/O accessors" series is applied.  Use
      __raw_writeb() instead.
      
      arch/arm/boot/compressed/misc.o: In function `putc':
      arch/arm/mach-ux500/include/mach/uncompress.h:41:
      undefined reference to `outer_cache'
      Acked-by: default avatarLinus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: default avatarRabin Vincent <rabin.vincent@stericsson.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      661f10f6