1. 26 3月, 2008 21 次提交
  2. 24 3月, 2008 1 次提交
  3. 23 3月, 2008 3 次提交
  4. 21 3月, 2008 2 次提交
    • J
      [NET] ifb: set separate lockdep classes for queue locks · 94833dfb
      Jarek Poplawski 提交于
      [   10.536424] =======================================================
      [   10.536424] [ INFO: possible circular locking dependency detected ]
      [   10.536424] 2.6.25-rc3-devel #3
      [   10.536424] -------------------------------------------------------
      [   10.536424] swapper/0 is trying to acquire lock:
      [   10.536424]  (&dev->queue_lock){-+..}, at: [<c0299b4a>] 
      dev_queue_xmit+0x175/0x2f3
      [   10.536424]
      [   10.536424] but task is already holding lock:
      [   10.536424]  (&p->tcfc_lock){-+..}, at: [<f8a67154>] tcf_mirred+0x20/0x178 
      [act_mirred]
      [   10.536424]
      [   10.536424] which lock already depends on the new lock.
      
      lockdep warns of locking order while using ifb with sch_ingress and
      act_mirred: ingress_lock, tcfc_lock, queue_lock (usually queue_lock
      is at the beginning). This patch is only to tell lockdep that ifb is
      a different device (e.g. from eth) and has its own pair of queue
      locks. (This warning is a false-positive in common scenario of using
      ifb; yet there are possible situations, when this order could be
      dangerous; lockdep should warn in such a case.) (With suggestions by
      David S. Miller)
      Reported-and-tested-by: NDenys Fedoryshchenko <denys@visp.net.lb>
      Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
      Acked-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94833dfb
    • D
      [TG3]: Fix build warning on sparc32. · 7582a335
      David S. Miller 提交于
      Sparc MAC address support should be protected consistently
      with CONFIG_SPARC, but there was a stray CONFIG_SPARC64
      case.
      
      Bump driver version and release date.
      
      Reported by Andrew Morton.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7582a335
  5. 19 3月, 2008 1 次提交
  6. 17 3月, 2008 12 次提交
    • J
      ucc_geth: use correct thread number for 10/100Mbps link · ffea31ed
      Joakim Tjernlund 提交于
      Use thread number of 1 for 10/100Mbps link instead of 4.
      Signed-off-by: NJoakim Tjernlund <Joakim.Tjernlund@transmode.se>
      Signed-off-by: NLi Yang <leoli@freescale.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      ffea31ed
    • M
      igb: Correctly get protocol information · 44b0cda3
      Mitch Williams 提交于
      We can't look at the socket to get protocol information. We should
      instead look directly at the packet, and hope there are no IPv6
      option headers.
      Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
      Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      44b0cda3
    • R
      [IOC3] Fix section missmatch · 725e49c5
      Ralf Baechle 提交于
        LD      drivers/net/built-in.o
      WARNING: drivers/net/built-in.o(.text+0x3468): Section mismatch in reference fro
      m the function ioc3_probe() to the function .devinit.text:ioc3_serial_probe()
      The function ioc3_probe() references
      the function __devinit ioc3_serial_probe().
      This is often because ioc3_probe lacks a __devinit
      annotation or the annotation of ioc3_serial_probe is wrong.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      725e49c5
    • G
      2.6.25-rc4 de_stop_rxtx polling wrong · 69cac988
      Grant Grundler 提交于
      This untested patch _should_ fix:
      	"(net de2104x) Kernel panic with de2104x tulip driver on boot"
      	http://bugzilla.kernel.org/show_bug.cgi?id=3156
      
      But the bug submitter isn't responding.  Same fix has been applied
      to tulip.c (several years ago) and uli526x.c (Feb 2008) drivers.
      
      [ The panic reported in the bug report was removed in a recently
        (march 2008) accepted patch from Ondrej Zary. ]
      Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      69cac988
    • A
      forcedeth: limit tx to 16 · 3b446c3e
      Ayaz Abdulla 提交于
      This is a critical patch which adds a workaround for a HW bug. The patch
      will limit the number of outstanding tx packets to 16. Otherwise, the HW
      could send out packets with bad checksums.
      
      The driver will still setup the tx packets into the ring, however, will
      only set the Valid bit on 16 packets at a time.
      Signed-off-by: NAyaz Abdulla <aabdulla@nvidia.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      3b446c3e
    • A
      3c501: Further coding style fixes · ad390d2d
      Alan Cox 提交于
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      ad390d2d
    • D
      cxgb3: Fix transmit queue stop mechanism · cd7e9034
      Divy Le Ray 提交于
      The last change in the Tx queue stop mechanism opens a window
      where the Tx queue might be stopped after pending credits
      returned.
      
      Tx credits are returned via a control message generated by the HW.
      It returns tx credits on demand, triggered by a completion bit
      set in selective transmit packet headers.
      
      The current code can lead to the Tx queue stopped
      with all pending credits returned, and the current frame
      not triggering a credit return. The Tx queue will then never be
      awaken.
      
      The driver could alternatively request a completion for packets
      that stop the queue. It's however safer at this point to go back
      to the pre-existing behaviour.
      Signed-off-by: NDivy Le Ray <divy@chelsio.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      cd7e9034
    • S
      NEWEMAC: Add compatible "ibm,tah" to tah matching table · cdb34697
      Stefan Roese 提交于
      Add "ibm,tah" to the compatible matching table of the ibm_newemac
      tah driver. The type "tah" is still preserved for compatibility reasons.
      New dts files should use the compatible property though.
      Signed-off-by: NStefan Roese <sr@denx.de>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      cdb34697
    • J
      rndis_host: fix transfer size negotiation · 10d0f27c
      Jean-Christophe Dubois 提交于
      This patch should resolve a problem that's troubled support for
      some RNDIS peripherals.  It seems to have boiled down to using a
      variable to establish transfer size limits before it was assigned,
      which caused those devices to fallback to a default "jumbogram"
      mode we don't support.  Fix by assigning it earlier for RNDIS.
      Signed-off-by: NJean-Christophe Dubois <jcd@tribudubois.net>
      [ cleanups ]
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      10d0f27c
    • P
      NEWEMAC: fix support for pause packets · 4373c932
      Pravin M. Bathija 提交于
      Problem Description and Fix
      ---------------------------
      When a pause packet(with destination as reserved Multicast address) is
      received by the EMAC hardware to control the flow of frames being
      transmitted by it, it is dropped by the hardware unless the reserved
      Multicast address is hashed in to the GAHT[1-4] registers. This code fix
      adds the default reserved multicast address to the GAHT[1-4] registers
      in the EMAC(s) present on the chip. The flow control with Pause packets
      will only work if the following register bits are programmed in EMAC:
      EMACx_MR1[APP] = 1
      EMACx_RMR[BAE] = 1
      EMACx_RMR[MAE] = 1
      
      Behavior that may be observed in a running system
      -------------------------------------------------
      A host transferring data from a PPC based system may send a Pause packet
      to the PPC EMAC requesting it to slow down the flow of packets. If the
      default reserved multicast MAC address is not programmed into the
      GAHT[1-4] registers this Pause packet will be dropped by PPC EMAC and no
      Flow Control will be done.
      Signed-off-by: NPravin M. Bathija <pbathija@amcc.com>
      Signed-off-by: NStefan Roese <sr@denx.de>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      4373c932
    • C
      virtio: fix race in enable_cb · 4265f161
      Christian Borntraeger 提交于
      There is a race in virtio_net, dealing with disabling/enabling the callback.
      I saw the following oops:
      
      kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:218!
      illegal operation: 0001 [#1] SMP
      Modules linked in: sunrpc dm_mod
      CPU: 2 Not tainted 2.6.25-rc1zlive-host-10623-gd358142-dirty #99
      Process swapper (pid: 0, task: 000000000f85a610, ksp: 000000000f873c60)
      Krnl PSW : 0404300180000000 00000000002b81a6 (vring_disable_cb+0x16/0x20)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
      Krnl GPRS: 0000000000000001 0000000000000001 0000000010005800 0000000000000001
                 000000000f3a0900 000000000f85a610 0000000000000000 0000000000000000
                 0000000000000000 000000000f870000 0000000000000000 0000000000001237
                 000000000f3a0920 000000000010ff74 00000000002846f6 000000000fa0bcd8
      Krnl Code: 00000000002b819a: a7110001           tmll    %r1,1
                 00000000002b819e: a7840004           brc     8,2b81a6
                 00000000002b81a2: a7f40001           brc     15,2b81a4
                >00000000002b81a6: a51b0001           oill    %r1,1
                 00000000002b81aa: 40102000           sth     %r1,0(%r2)
                 00000000002b81ae: 07fe               bcr     15,%r14
                 00000000002b81b0: eb7ff0380024       stmg    %r7,%r15,56(%r15)
                 00000000002b81b6: a7f13e00           tmll    %r15,15872
      Call Trace:
      ([<000000000fa0bcd0>] 0xfa0bcd0)
       [<00000000002b8350>] vring_interrupt+0x5c/0x6c
       [<000000000010ab08>] do_extint+0xb8/0xf0
       [<0000000000110716>] ext_no_vtime+0x16/0x1a
       [<0000000000107e72>] cpu_idle+0x1c2/0x1e0
      
      The problem can be triggered with a high amount of host->guest traffic.
      I think its the following race:
      
      poll says netif_rx_complete
      poll calls enable_cb
      enable_cb opens the interrupt mask
      a new packet comes, an interrupt is triggered----\
      enable_cb sees that there is more work           |
      enable_cb disables the interrupt                 |
             .                                         V
             .                            interrupt is delivered
             .                            skb_recv_done does atomic napi test, ok
       some waiting                       disable_cb is called->check fails->bang!
             .
      poll would do napi check
      poll would do disable_cb
      
      The fix is to let enable_cb not disable the interrupt again, but expect the
      caller to do the cleanup if it returns false. In that case, the interrupt is
      only disabled, if the napi test_set_bit was successful.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (cleaned up doco)
      4265f161
    • A
      virtio: Enable netpoll interface for netconsole logging · da74e89d
      Amit Shah 提交于
      Add a new poll_controller handler that the netpoll interface needs.
      
      This enables netconsole logging from a kvm guest over the virtio
      net interface.
      Signed-off-by: NAmit Shah <amitshah@gmx.net>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      da74e89d