1. 27 Sep, 2009 4 commits
  2. 26 Sep, 2009 4 commits
  3. 25 Sep, 2009 29 commits
  4. 24 Sep, 2009 3 commits
    • Anton Vorontsov's avatar
      3c59x: Get rid of "Trying to free already-free IRQ" · 704cc92e
      Anton Vorontsov authored
      Following trace pops up if we try to suspend with 3c59x ethernet NIC
      brought down:
        root@b1:~# ifconfig eth16 down
        root@b1:~# echo mem > /sys/power/state
        3c59x 0000:00:10.0: suspend
        3c59x 0000:00:10.0: PME# disabled
        Trying to free already-free IRQ 48
        ------------[ cut here ]------------
        Badness at c00554e4 [verbose debug info unavailable]
        NIP: c00554e4 LR: c00554e4 CTR: c019a098
        REGS: c7975c60 TRAP: 0700   Not tainted  (2.6.31-rc4)
        MSR: 00021032 <ME,CE,IR,DR>  CR: 28242422  XER: 20000000
        TASK = c79cb0c0[1746] 'bash' THREAD: c7974000
        NIP [c00554e4] __free_irq+0x108/0x1b0
        LR [c00554e4] __free_irq+0x108/0x1b0
        Call Trace:
        [c7975d10] [c00554e4] __free_irq+0x108/0x1b0 (unreliable)
        [c7975d30] [c005559c] free_irq+0x10/0x24
        [c7975d40] [c01e21ec] vortex_suspend+0x70/0xc4
        [c7975d60] [c017e584] pci_legacy_suspend+0x58/0x100
      This is because the driver manages interrupts without checking for
      Though, there are few other issues with suspend/resume in this driver.
      The intention of calling free_irq() in suspend() was to avoid any
      possible spurious interrupts (see commit 5b039e68
      "3c59x PM fixes"). But,
      - On resume, the driver was requesting IRQ just after pci_set_master(),
        but before vortex_up() (which actually resets 3c59x chips).
      - Issuing free_irq() on a shared IRQ doesn't guarantee that a buggy
        HW won't trigger spurious interrupts in another driver that
        requested the same interrupt. So, if we want to protect from
        unexpected interrupts, then on suspend we should issue disable_irq(),
        not free_irq().
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Sebastian Haas's avatar
      ems_pci: fix size of CAN controllers BAR mapping for CPC-PCI v2 · edf42a27
      Sebastian Haas authored
      The driver mapped only 128 bytes of the CAN controller address space when a
      CPC-PCI v2 was detected (incl. CPC-104P). This patch will fix it by always
      mapping the whole address space (4096 bytes on all boards) of the
      corresponding PCI BAR.
      Signed-off-by: default avatarSebastian Haas <haas@ems-wuensche.com>
      Signed-off-by: default avatarWolfgang Grandegger <wg@grandegger.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Moni Shoua's avatar
      IPoIB: Don't turn on carrier for a non-active port · 5ee95120
      Moni Shoua authored
      Multicast joins can succeed even if the IB port is down.  This happens
      when the SM runs on the same port with the requesting port.  However,
      IPoIB calls netif_carrier_on() when the join of the broadcast group
      succeeds, without caring about the state of the IB port.  The result
      is an IPoIB interface in RUNNING state but without an active IB port
      to support it.
      If a bonding interface uses this IPoIB interface as a slave it might
      not detect that this slave is almost useless and failover
      functionality will be damaged.  The fix checks the state of the IB
      port in the carrier_task before calling netif_carrier_on().
      Adresses: https://bugs.openfabrics.org/show_bug.cgi?id=1726Signed-off-by: default avatarMoni Shoua <monis@voltaire.com>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>