1. 24 Aug, 2008 2 commits
    • Lennert Buytenhek's avatar
      mv643xx_eth: fix double add_timer() on the receive oom timer · 92c70f27
      Lennert Buytenhek authored
      Commit 12e4ab79 ("mv643xx_eth: be
      more agressive about RX refill") changed the condition for the receive
      out-of-memory timer to be scheduled from "the receive ring is empty"
      to "the receive ring is not full".
      
      This can lead to a situation where the receive out-of-memory timer is
      pending because a previous rxq_refill() didn't manage to refill the
      receive ring entirely as a result of being out of memory, and
      rxq_refill() is then called again as a side effect of a packet receive
      interrupt, and that rxq_refill() call then again does not succeed to
      refill the entire receive ring with fresh empty skbuffs because we are
      still out of memory, and then tries to call add_timer() on the already
      scheduled out-of-memory timer.
      
      This patch fixes this issue by changing the add_timer() call in
      rxq_refill() to a mod_timer() call.  If the OOM timer was not already
      scheduled, this will behave as before, whereas if it was already
      scheduled, this patch will push back its firing time a bit, which is
      safe because we've (unsuccessfully) attempted to refill the receive
      ring just before we do this.
      Signed-off-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      92c70f27
    • Lennert Buytenhek's avatar
      mv643xx_eth: fix NAPI 'rotting packet' issue · 819ddcaf
      Lennert Buytenhek authored
      When a receive interrupt occurs, mv643xx_eth would first process the
      receive descriptors and then ACK the receive interrupt, instead of the
      other way round.
      
      This would leave a small race window between processing the last
      receive descriptor and clearing the receive interrupt status in which
      a new packet could come in, which would then 'rot' in the receive
      ring until the next receive interrupt would come in.
      
      Fix this by ACKing (clearing) the receive interrupt condition before
      processing the receive descriptors.
      Signed-off-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      819ddcaf
  2. 21 Aug, 2008 1 commit
  3. 20 Aug, 2008 35 commits
  4. 19 Aug, 2008 2 commits
    • Brian King's avatar
      powerpc: Fix vio_bus_probe oops on probe error · cd5aeb9f
      Brian King authored
      When CMO is enabled and booted on a non CMO system and the VIO
      device's probe function fails, an oops can result since
      vio_cmo_bus_remove is called when it should not.  This fixes it by
      avoiding the vio_cmo_bus_remove call on platforms that don't implement
      CMO.
      
      cpu 0x0: Vector: 300 (Data Access) at [c00000000e13b3d0]
          pc: c000000000020d34: .vio_cmo_bus_remove+0xc0/0x1f4
          lr: c000000000020ca4: .vio_cmo_bus_remove+0x30/0x1f4
          sp: c00000000e13b650
         msr: 8000000000009032
         dar: 0
       dsisr: 40000000
        current = 0xc00000000e0566c0
        paca    = 0xc0000000006f9b80
          pid   = 2428, comm = modprobe
      enter ? for help
      [c00000000e13b6e0] c000000000021d94 .vio_bus_probe+0x2f8/0x33c
      [c00000000e13b7a0] c00000000029fc88 .driver_probe_device+0x13c/0x200
      [c00000000e13b830] c00000000029fdac .__driver_attach+0x60/0xa4
      [c00000000e13b8c0] c00000000029f050 .bus_for_each_dev+0x80/0xd8
      [c00000000e13b980] c00000000029f9ec .driver_attach+0x28/0x40
      [c00000000e13ba00] c00000000029f630 .bus_add_driver+0xd4/0x284
      [c00000000e13baa0] c0000000002a01bc .driver_register+0xc4/0x198
      [c00000000e13bb50] c00000000002168c .vio_register_driver+0x40/0x5c
      [c00000000e13bbe0] d0000000003b3f1c .ibmvfc_module_init+0x70/0x109c [ibmvfc]
      [c00000000e13bc70] c0000000000acf08 .sys_init_module+0x184c/0x1a10
      [c00000000e13be30] c000000000008748 syscall_exit+0x0/0x40
      Signed-off-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      cd5aeb9f
    • Joachim Fenkes's avatar
      powerpc/ibmebus: Restore "name" sysfs attribute on ibmebus devices · 4589f1fe
      Joachim Fenkes authored
      Recent of_platform changes made of_bus_type_init() overwrite the bus
      type's .dev_attrs list, meaning that the "name" attribute that ibmebus
      devices previously had is no longer present.  This is a user-visible
      regression which breaks the userspace eHCA support, since the eHCA
      userspace driver relies on the name attribute to check for valid
      adapters.
      
      This fixes it by providing the "name" attribute in the generic OF
      device code instead.  Tested on POWER.
      Signed-off-by: default avatarJoachim Fenkes <fenkes@de.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      4589f1fe