1. 22 May, 2009 9 commits
  2. 21 May, 2009 1 commit
  3. 20 May, 2009 3 commits
  4. 19 May, 2009 13 commits
    • Benjamin Herrenschmidt's avatar
      drm: Round size of SHM maps to PAGE_SIZE · b6741377
      Benjamin Herrenschmidt authored
      Currently, userspace can fail to obtain the SAREA mapping (among other
      reasons) if it passes SAREA_MAX to drmAddMap without aligning it to the
      page size. This breaks for example on PowerPC with 64K pages and radeon
      despite the kernel radeon actually doing the right rouding in the first
      place.
      
      The way SAREA_MAX is defined with a bunch of ifdef's and duplicated
      between libdrm and the X server is gross, ultimately it should be
      retrieved by userspace from the kernel, but in the meantime, we have
      plenty of existing userspace built with bad values that need to work.
      
      This patch works around broken userspace by rounding the requested size
      in drm_addmap_core() of any SHM map to the page size. Since the backing
      memory for SHM maps is also allocated within addmap_core, there is no
      danger of adjacent memory being exposed due to the increased map size.
      The only side effect is that drivers that previously tried to create or
      access SHM maps using a size < PAGE_SIZE and failed (getting -EINVAL),
      will now succeed at the cost of a little bit more memory used if that
      happens to be when the map is created.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      b6741377
    • Eric Paris's avatar
      TPM: get_event_name stack corruption · fbaa5869
      Eric Paris authored
      get_event_name uses sprintf to fill a buffer declared on the stack.  It fills
      the buffer 2 bytes at a time.  What the code doesn't take into account is that
      sprintf(buf, "%02x", data) actually writes 3 bytes.  2 bytes for the data and
      then it nul terminates the string.  Since we declare buf to be 40 characters
      long and then we write 40 bytes of data into buf sprintf is going to write 41
      characters.  The fix is to leave room in buf for the nul terminator.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      fbaa5869
    • Rafael J. Wysocki's avatar
      PCI PM: Fix initialization and kexec breakage for some devices · b3bad72e
      Rafael J. Wysocki authored
      Recent PCI PM changes introduced a bug that causes some devices to be
      mishandled after kexec and during early initialization.  The failure
      scenario in the kexec case is the following:
      
      * Assume a PCI device is not power-manageable by the platform and has
        PCI_PM_CTRL_NO_SOFT_RESET set in PMCSR.
      * The device is put into D3 before kexec (using the native PCI PM).
      * After kexec, pci_setup_device() sets the device's power state to
        PCI_UNKNOWN.
      * pci_set_power_state(dev, PCI_D0) is called by the device's driver.
      * __pci_start_power_transition(dev, PCI_D0) is called and since the
        device is not power-manageable by the platform, it causes
        pci_update_current_state(dev, PCI_D0) to be called.  As a result
        the device's current_state field is updated to PCI_D3, in
        accordance with the contents of its PCI PM registers.
      * pci_raw_set_power_state() is called and it changes the device power
        state to D0.  *However*, it should also call pci_restore_bars() to
        reinitialize the device, but it doesn't, because the device's
        current_state field has been modified earlier.
      
      To prevent this from happening, modify pci_platform_power_transition()
      so that it doesn't use pci_update_current_state() to update the
      current_state field for devices that aren't power-manageable by the
      platform.  Instead, this field should be updated directly for devices
      that don't support the native PCI PM.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      b3bad72e
    • Nelson Castillo's avatar
      mfd: pcf50633: fix unsafe disable_irq() · f43ab901
      Nelson Castillo authored
      Without this change Openmoko Freerunner (GTA02) bootstrap will deadlock.
      As pointed out in other patches this issue is in the wild since the merge
      of:
      
      : commit 3aa551c9
      : Author: Thomas Gleixner <tglx@linutronix.de>
      : Date:   Mon Mar 23 18:28:15 2009 +0100
      :
      :    genirq: add threaded interrupt handler support
      :
      :    Add support for threaded interrupt handlers
      Signed-off-by: default avatarNelson Castillo <arhuaco@freaks-unidos.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: <balajirrao@openmoko.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      f43ab901
    • Mark Brown's avatar
      mfd: Keep a cache of WM8350 volatile values · b126d113
      Mark Brown authored
      Due to the way that the WM8350 audio driver handles CODEC_ENA many of
      the WM8350 audio registers are marked as volatile when they aren't
      actually so. Allow the audio driver to see a cache of these values for
      inspection during interrupt context.
      
      To do this we need to stop satisfying any bits from volatile registers
      from cache - there's no real benefit from doing so anyway, we did the
      read already.
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      b126d113
    • Linus Torvalds's avatar
      Avoid ICE in get_random_int() with gcc-3.4.5 · 26a9a418
      Linus Torvalds authored
      Martin Knoblauch reports that trying to build 2.6.30-rc6-git3 with
      RHEL4.3 userspace (gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)) causes an
      internal compiler error (ICE):
      
          drivers/char/random.c: In function `get_random_int':
          drivers/char/random.c:1672: error: unrecognizable insn:
          (insn 202 148 150 0 /scratch/build/linux-2.6.30-rc6-git3/arch/x86/include/asm/tsc.h:23 (set (reg:SI 0 ax [91])
                  (subreg:SI (plus:DI (plus:DI (reg:DI 0 ax [88])
                              (subreg:DI (reg:SI 6 bp) 0))
                          (const_int -4 [0xfffffffffffffffc])) 0)) -1 (nil)
              (nil))
          drivers/char/random.c:1672: internal compiler error: in extract_insn, at recog.c:2083
      
      and after some debugging it turns out that it's due to the code trying
      to figure out the rough value of the current stack pointer by taking an
      address of an uninitialized variable and casting that to an integer.
      
      This is clearly a compiler bug, but it's not worth fighting - while the
      current stack kernel pointer might be somewhat hard to predict in user
      space, it's also not generally going to change for a lot of the call
      chains for a particular process.
      
      So just drop it, and mumble some incoherent curses at the compiler.
      Tested-by: default avatarMartin Knoblauch <spamtrap@knobisoft.de>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      26a9a418
    • Boaz Harrosh's avatar
      scsi_lib: remove unused variable · ac36552a
      Boaz Harrosh authored
      The last request completion cleanup in scsi_lib left an unused
      this_count variable in scsi_io_completion().
      (It was used before in a code segment that now uses blk_end_request_all())
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      ac36552a
    • Boaz Harrosh's avatar
      libosd: Use of new blk_make_request · c29b70f6
      Boaz Harrosh authored
      Use new blk_make_request() to allocate a request from bio
      and avoid using deprecated blk_rq_append_bio().
      
      This patch is dependent on a block layer patch titled:
          [BLOCK] New blk_make_request() takes bio returns request
      
      This is the last usage of blk_rq_append_bio in osd, it can now
      be un-exported.
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      CC: Jeff Garzik <jeff@garzik.org>
      CC: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      c29b70f6
    • Boaz Harrosh's avatar
      libosd: Use new blk_rq_map_kern · bc38bf10
      Boaz Harrosh authored
      Now that blk_rq_map_kern will append the buffer onto the
      request we can use it easily for adding extra segments
      (eg. attributes)
      
      This patch is dependent on a block layer patch titled:
         [BLOCK] allow blk_rq_map_kern to append to requests
      Signed-off-by: default avatarBoaz Harrosh <bharrosh@panasas.com>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      bc38bf10
    • Tejun Heo's avatar
      block: set rq->resid_len to blk_rq_bytes() on issue · 5f49f631
      Tejun Heo authored
      In commit c3a4d78c, while introducing
      rq->resid_len, the default value of residue count was changed from
      full count to zero.  The conversion was done under the assumption that
      when a request fails residue count wasn't defined.  However, Boaz and
      James pointed out that this wasn't true and the residue count should
      be preserved for failed requests too.
      
      This patchset restores the original behavior by setting rq->resid_len
      to blk_rq_bytes(rq) on request start and restoring explicit clearing
      in affected drivers.  While at it, take advantage of the fact that
      rq->resid_len is set to full count where applicable.
      
      * ide-cd: rq->resid_len cleared on pc success
      
      * mptsas: req->resid_len cleared on success
      
      * sas_expander: rsp/req->resid_len cleared on success
      
      * mpt2sas_transport: req->resid_len cleared on success
      
      * ide-cd, ide-tape, mptsas, sas_host_smp, mpt2sas_transport, ub: take
        advantage of initial full count to simplify code
      
      Boaz Harrosh spotted bug in resid_len initialization.  Fixed as
      suggested.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarBorislav Petkov <petkovbb@googlemail.com>
      Cc: Boaz Harrosh <bharrosh@panasas.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Pete Zaitcev <zaitcev@redhat.com>
      Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: Eric Moore <Eric.Moore@lsi.com>
      Cc: Darrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      5f49f631
    • Tejun Heo's avatar
      ub: use __blk_end_request_all() · 3755100d
      Tejun Heo authored
      ub_end_rq() always tries to complete full request.  The @cmd_len
      parameter was there because rq->data_len used to be overwritten with
      residue count.  Drop @cmd_len and use __blk_end_request_all().
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Pete Zaitcev <zaitcev@redhat.com>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      3755100d
    • Ian Campbell's avatar
      xen/blkfront: fix warning when deleting gendisk on unplug/shutdown · 31a14400
      Ian Campbell authored
      Currently blkfront gives a warning when hot unplugging due to calling
      del_gendisk() with interrupts disabled (due to blkif_io_lock).
      
      WARNING: at kernel/softirq.c:124 local_bh_enable+0x36/0x84()
      Modules linked in: xenfs xen_netfront ext3 jbd mbcache xen_blkfront
      Pid: 13, comm: xenwatch Not tainted 2.6.29-xs5.5.0.13 #3
      Call Trace:
       [<c012611c>] warn_slowpath+0x80/0xb6
       [<c0104cf1>] xen_sched_clock+0x16/0x63
       [<c0104710>] xen_force_evtchn_callback+0xc/0x10
       [<c0104e32>] check_events+0x8/0xe
       [<c0104d9b>] xen_restore_fl_direct_end+0x0/0x1
       [<c0103749>] xen_mc_flush+0x10a/0x13f
       [<c0105bd2>] __switch_to+0x114/0x14e
       [<c011d92b>] dequeue_task+0x62/0x70
       [<c0123b6f>] finish_task_switch+0x2b/0x84
       [<c0299877>] schedule+0x66d/0x6e7
       [<c0104710>] xen_force_evtchn_callback+0xc/0x10
       [<c0104710>] xen_force_evtchn_callback+0xc/0x10
       [<c012a642>] local_bh_enable+0x36/0x84
       [<c022f9a7>] sk_filter+0x57/0x5c
       [<c0233dae>] netlink_broadcast+0x1d5/0x315
       [<c01c6371>] kobject_uevent_env+0x28d/0x331
       [<c01e7ead>] device_del+0x10f/0x120
       [<c01e7ec6>] device_unregister+0x8/0x10
       [<c015f86d>] bdi_unregister+0x2d/0x39
       [<c01bf6f4>] unlink_gendisk+0x23/0x3e
       [<c01ac946>] del_gendisk+0x7b/0xe7
       [<d0828c19>] blkfront_closing+0x28/0x6e [xen_blkfront]
       [<d082900c>] backend_changed+0x3ad/0x41d [xen_blkfront]
      
      We can fix this by calling del_gendisk() later in blkfront_closing, after
      releasing blkif_io_lock. Since the queue is stopped during the interrupts
      disabled phase I don't think there is any danger of an event occuring between
      releasing the blkif_io_lock and deleting the disk.
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      31a14400
    • Ian Campbell's avatar
      xen/blkfront: allow xenbus state transition to Closing->Closed when not Connected · 28afea5b
      Ian Campbell authored
      This situation can occur when attempting to attach a block device whose
      backend is an empty physical CD-ROM driver. The backend in this case
      will go directly from the Initialising state to Closing->Closed.
      Previously this would result in a NULL pointer deref on info->gd
      (xenbus_dev_fatal does not return as a1a15ac5 seems to expect)
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Acked-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      28afea5b
  5. 18 May, 2009 7 commits
  6. 17 May, 2009 5 commits
    • roel kluin's avatar
      Neterion: *FIFO1_DMA_ERR set twice, should 2nd be *FIFO2_DMA_ERR? · d77dd8d2
      roel kluin authored
      FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR.
      Signed-off-by: default avatarRoel Kluin <roel.kluin@gmail.com>
      Acked-by: default avatarRam Vepa <ram.vepa@neterion.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d77dd8d2
    • Gabriel Paubert's avatar
      mv643xx_eth: fix PPC DMA breakage · eb0519b5
      Gabriel Paubert authored
      After 2.6.29, PPC no more admits passing NULL to the dev parameter of
      the DMA API. The result is a BUG followed by solid lock-up when the 
      mv643xx_eth driver brings an interface up. The following patch makes 
      the driver work on my Pegasos again; it is mostly a search and replace 
      of NULL by mp->dev->dev.parent in dma allocation/freeing/mapping/unmapping
      functions.
      Signed-off-by: default avatarGabriel Paubert <paubert@iram.es>
      Acked-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb0519b5
    • Stephen Hemminger's avatar
      bonding: fix link down handling in 802.3ad mode · 4cd6fe1c
      Stephen Hemminger authored
      One of the purposes of bonding is to allow for redundant links, and failover
      correctly if the cable is pulled. If all the members of a bonded device have
      no carrier present, the bonded device itself needs to report no carrier present
      to user space so management tools (like routing daemons) can respond.
      
      Bonding in 802.3ad mode does not work correctly for this because it incorrectly
      chooses a link that is down as a possible aggregator.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4cd6fe1c
    • Ralf Baechle's avatar
      NET: Meth: Fix unsafe mix of irq and non-irq spinlocks. · a8f492c6
      Ralf Baechle authored
      Mixing of normal and irq spinlocks results in the following lockdep messages
      on bootup on IP32:
      
      [...]
      Sending DHCP requests .
      ======================================================
      [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
      2.6.30-rc5-00164-g41baeef #30
      ------------------------------------------------------
      swapper/1 [HC0[0]:SC0[1]:HE0:SE0] is trying to acquire:
       (&priv->meth_lock){+.+...}, at: [<ffffffff8026388c>] meth_tx+0x48/0x43c
      
      and this task is already holding:
       (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
      which would create a new lock dependency:
       (_xmit_ETHER#2){+.-...} -> (&priv->meth_lock){+.+...}
      
      but this new dependency connects a SOFTIRQ-irq-safe lock:
       (_xmit_ETHER#2){+.-...}
      ... which became SOFTIRQ-irq-safe at:
        [<ffffffff80061458>] __lock_acquire+0x784/0x1a14
        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
        [<ffffffff800128d0>] _spin_lock+0x30/0x44
        [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
        [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
        [<ffffffff8003da5c>] __do_softirq+0xec/0x208
        [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
        [<ffffffff8003dda0>] irq_exit+0x54/0x9c
        [<ffffffff80004420>] ret_from_irq+0x0/0x4
        [<ffffffff80004720>] r4k_wait+0x20/0x40
        [<ffffffff80015418>] cpu_idle+0x30/0x60
        [<ffffffff804cd934>] start_kernel+0x3ec/0x404
      
      to a SOFTIRQ-irq-unsafe lock:
       (&priv->meth_lock){+.+...}
      ... which became SOFTIRQ-irq-unsafe at:
      ...  [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
        [<ffffffff800128d0>] _spin_lock+0x30/0x44
        [<ffffffff80263f20>] meth_reset+0x118/0x2d8
        [<ffffffff8026424c>] meth_open+0x28/0x140
        [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
        [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
        [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
        [<ffffffff80012e68>] do_one_initcall+0x58/0x170
        [<ffffffff804cd190>] kernel_init+0x98/0x104
        [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
      
      other info that might help us debug this:
      
      2 locks held by swapper/1:
       #0:  (rcu_read_lock){.+.+..}, at: [<ffffffff802c0954>] dev_queue_xmit+0x1e0/0x4b0
       #1:  (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
      
      the SOFTIRQ-irq-safe lock's dependencies:
      -> (_xmit_ETHER#2){+.-...} ops: 0 {
         HARDIRQ-ON-W at:
                              [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                              [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                              [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                              [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                              [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                              [<ffffffff80004420>] ret_from_irq+0x0/0x4
                              [<ffffffff80004720>] r4k_wait+0x20/0x40
                              [<ffffffff80015418>] cpu_idle+0x30/0x60
                              [<ffffffff804cd934>] start_kernel+0x3ec/0x404
         IN-SOFTIRQ-W at:
                              [<ffffffff80061458>] __lock_acquire+0x784/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                              [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                              [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                              [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                              [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                              [<ffffffff80004420>] ret_from_irq+0x0/0x4
                              [<ffffffff80004720>] r4k_wait+0x20/0x40
                              [<ffffffff80015418>] cpu_idle+0x30/0x60
                              [<ffffffff804cd934>] start_kernel+0x3ec/0x404
         INITIAL USE at:
                             [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
                             [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                             [<ffffffff800128d0>] _spin_lock+0x30/0x44
                             [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                             [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                             [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                             [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                             [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                             [<ffffffff80004420>] ret_from_irq+0x0/0x4
                             [<ffffffff80004720>] r4k_wait+0x20/0x40
                             [<ffffffff80015418>] cpu_idle+0x30/0x60
                             [<ffffffff804cd934>] start_kernel+0x3ec/0x404
       }
       ... key      at: [<ffffffff80cf93f0>] netdev_xmit_lock_key+0x8/0x1c8
      
      the SOFTIRQ-irq-unsafe lock's dependencies:
      -> (&priv->meth_lock){+.+...} ops: 0 {
         HARDIRQ-ON-W at:
                              [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                              [<ffffffff8026424c>] meth_open+0x28/0x140
                              [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                              [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                              [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                              [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                              [<ffffffff804cd190>] kernel_init+0x98/0x104
                              [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
         SOFTIRQ-ON-W at:
                              [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                              [<ffffffff8026424c>] meth_open+0x28/0x140
                              [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                              [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                              [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                              [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                              [<ffffffff804cd190>] kernel_init+0x98/0x104
                              [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
         INITIAL USE at:
                             [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
                             [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                             [<ffffffff800128d0>] _spin_lock+0x30/0x44
                             [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                             [<ffffffff8026424c>] meth_open+0x28/0x140
                             [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                             [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                             [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                             [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                             [<ffffffff804cd190>] kernel_init+0x98/0x104
                             [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
       }
       ... key      at: [<ffffffff80cf6ce8>] __key.32424+0x0/0x8
      
      stack backtrace:
      Call Trace:
      [<ffffffff8000ed0c>] dump_stack+0x8/0x34
      [<ffffffff80060b74>] check_usage+0x470/0x4a0
      [<ffffffff80060c34>] check_irq_usage+0x90/0x130
      [<ffffffff80061f78>] __lock_acquire+0x12a4/0x1a14
      [<ffffffff800627e0>] lock_acquire+0xf8/0x150
      [<ffffffff80012a0c>] _spin_lock_irqsave+0x60/0x84
      [<ffffffff8026388c>] meth_tx+0x48/0x43c
      [<ffffffff802d3a38>] __qdisc_run+0x150/0x30c
      [<ffffffff802c0aa8>] dev_queue_xmit+0x334/0x4b0
      [<ffffffff804e7e6c>] ip_auto_config+0x8d0/0xf28
      [<ffffffff80012e68>] do_one_initcall+0x58/0x170
      [<ffffffff804cd190>] kernel_init+0x98/0x104
      [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
      
      ..... timed out!
      IP-Config: Retrying forever (NFS root)...
      Sending DHCP requests ., OK
      [...]
      
      Fixed by converting all locks to irq locks.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Tested-by: default avatarAndrew Randrianasulu <randrik_a@yahoo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8f492c6
    • Yevgeny Petrilin's avatar
      mlx4_en: Fix not deleted napi structures · 72876a60
      Yevgeny Petrilin authored
      Napi structures are being created each time we open a port, but when
      the port is closed the napi structure is only disabled but not removed.
      This bug caused hang while removing the driver.
      Signed-off-by: default avatarYevgeny Petrilin <yevgenyp@mellanox.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72876a60
  7. 16 May, 2009 2 commits