1. 29 10月, 2005 1 次提交
    • A
      [IPv4/IPv6]: UFO Scatter-gather approach · e89e9cf5
      Ananda Raju 提交于
      Attached is kernel patch for UDP Fragmentation Offload (UFO) feature.
      
      1. This patch incorporate the review comments by Jeff Garzik.
      2. Renamed USO as UFO (UDP Fragmentation Offload)
      3. udp sendfile support with UFO
      
      This patches uses scatter-gather feature of skb to generate large UDP
      datagram. Below is a "how-to" on changes required in network device
      driver to use the UFO interface.
      
      UDP Fragmentation Offload (UFO) Interface:
      -------------------------------------------
      UFO is a feature wherein the Linux kernel network stack will offload the
      IP fragmentation functionality of large UDP datagram to hardware. This
      will reduce the overhead of stack in fragmenting the large UDP datagram to
      MTU sized packets
      
      1) Drivers indicate their capability of UFO using
      dev->features |= NETIF_F_UFO | NETIF_F_HW_CSUM | NETIF_F_SG
      
      NETIF_F_HW_CSUM is required for UFO over ipv6.
      
      2) UFO packet will be submitted for transmission using driver xmit routine.
      UFO packet will have a non-zero value for
      
      "skb_shinfo(skb)->ufo_size"
      
      skb_shinfo(skb)->ufo_size will indicate the length of data part in each IP
      fragment going out of the adapter after IP fragmentation by hardware.
      
      skb->data will contain MAC/IP/UDP header and skb_shinfo(skb)->frags[]
      contains the data payload. The skb->ip_summed will be set to CHECKSUM_HW
      indicating that hardware has to do checksum calculation. Hardware should
      compute the UDP checksum of complete datagram and also ip header checksum of
      each fragmented IP packet.
      
      For IPV6 the UFO provides the fragment identification-id in
      skb_shinfo(skb)->ip6_frag_id. The adapter should use this ID for generating
      IPv6 fragments.
      Signed-off-by: NAnanda Raju <ananda.raju@neterion.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (forwarded)
      Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
      e89e9cf5
  2. 28 10月, 2005 28 次提交
  3. 26 10月, 2005 1 次提交
  4. 25 10月, 2005 2 次提交
    • J
      [SERIAL] new hp diva console port · 551f8f0e
      Justin Chen 提交于
      Add the new ID 0x132a and configure the new PCI Diva console port.  This
      device supports only 1 single console UART.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      551f8f0e
    • B
      [SERIAL] support the Exsys EX-4055 4S four-port card · add7b58e
      Bjorn Helgaas 提交于
      Tested by Wolfgang Denk with this device:
      
          00:0f.0 Network controller: PLX Technology, Inc. PCI <-> IOBus Bridge (rev 01)
              Subsystem: Exsys EX-4055 4S(16C550) RS-232
              Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
              Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
              Interrupt: pin A routed to IRQ 10
              Region 0: Memory at 80100000 (32-bit, non-prefetchable) [size=128]
              Region 1: I/O ports at 7080 [size=128]
              Region 2: I/O ports at 7400 [size=32]
      
          00:0f.0 Class 0280: 10b5:9050 (rev 01)
              Subsystem: d84d:4055
      
      Results with this patch:
      
          Serial: 8250/16550 driver $Revision: 1.90 $ 32 ports, IRQ sharing enabled
          ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
          PCI: Found IRQ 10 for device 0000:00:0f.0
          ttyS4 at I/O 0x7400 (irq = 10) is a 16550A
          ttyS5 at I/O 0x7408 (irq = 10) is a 16550A
          ttyS6 at I/O 0x7410 (irq = 10) is a 16550A
          ttyS7 at I/O 0x7418 (irq = 10) is a 16550A
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      add7b58e
  5. 24 10月, 2005 1 次提交
    • A
      [PATCH] inotify/idr leak fix · 8d3b3591
      Andrew Morton 提交于
      Fix a bug which was reported and diagnosed by
      Stefan Jones <stefan.jones@churchillrandoms.co.uk>
      
      IDR trees include a cache of idr_layer objects.  There's no way to destroy
      this cache, so when we discard an overall idr tree we end up leaking some
      memory.
      
      Add and use idr_destroy() for this.  v9fs and infiniband also need to use
      idr_destroy() to avoid leaks.
      
      Or, we make the cache global, like radix_tree_preload().  Which is probably
      better.  Later.
      
      Cc: Eric Van Hensbergen <ericvh@ericvh.myip.org>
      Cc: Roland Dreier <rolandd@cisco.com>
      Cc: Robert Love <rml@novell.com>
      Cc: John McCutchan <ttb@tentacle.dhs.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8d3b3591
  6. 23 10月, 2005 1 次提交
  7. 22 10月, 2005 4 次提交
  8. 21 10月, 2005 1 次提交
  9. 20 10月, 2005 1 次提交
    • Y
      [PATCH] swiotlb: make sure initial DMA allocations really are in DMA memory · 281dd25c
      Yasunori Goto 提交于
      This introduces a limit parameter to the core bootmem allocator; The new
      parameter indicates that physical memory allocated by the bootmem
      allocator should be within the requested limit.
      
      We also introduce alloc_bootmem_low_pages_limit, alloc_bootmem_node_limit,
      alloc_bootmem_low_pages_node_limit apis, but alloc_bootmem_low_pages_limit
      is the only api used for swiotlb.
      
      The existing alloc_bootmem_low_pages() api could instead have been
      changed and made to pass right limit to the core allocator.  But that
      would make the patch more intrusive for 2.6.14, as other arches use
      alloc_bootmem_low_pages().  We may be done that post 2.6.14 as a
      cleanup.
      
      With this, swiotlb gets memory within 4G for both x86_64 and ia64
      arches.
      Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Ravikiran G Thirumalai <kiran@scalex86.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      281dd25c