1. 17 7月, 2007 1 次提交
  2. 21 6月, 2007 4 次提交
  3. 09 5月, 2007 1 次提交
  4. 08 5月, 2007 3 次提交
  5. 05 5月, 2007 1 次提交
  6. 26 4月, 2007 8 次提交
  7. 03 3月, 2007 1 次提交
  8. 06 2月, 2007 1 次提交
  9. 09 1月, 2007 3 次提交
  10. 08 1月, 2007 1 次提交
    • H
      qeth: fix uaccess handling and get rid of unused variable · 3a6b95c8
      Heiko Carstens 提交于
      [patch] qeth: fix uaccess handling and get rid of unused variable
      
      drivers/s390/net/qeth_main.c: In function `qeth_process_inbound_buffer':
      drivers/s390/net/qeth_main.c:2563: warning: unused variable `vlan_addr'
      
      include/asm/uaccess.h: In function `qeth_do_ioctl':
      drivers/s390/net/qeth_main.c:4847: warning:
       ignoring return value of `copy_to_user'
      drivers/s390/net/qeth_main.c:4849: warning:
       ignoring return value of `copy_to_user'
      drivers/s390/net/qeth_main.c:4996: warning:
       ignoring return value of `copy_to_user'
      
      Cc: Frank Pavlic <fpavlic@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      3a6b95c8
  11. 07 12月, 2006 1 次提交
  12. 04 12月, 2006 1 次提交
  13. 29 9月, 2006 1 次提交
  14. 17 9月, 2006 5 次提交
    • F
      [PATCH] s390: qeth driver fixes [6/6] · 8b98a37c
      Frank Pavlic 提交于
      [PATCH 9/9] s390: qeth driver fixes [6/6]
      
      From: Frank Pavlic <fpavlic@de.ibm.com>
      	- Hipersockets has no IPV6 support, thus prevent issueing
      	  SETRTG_IPV6 control commands on Hipersockets devices.
      	- fixed error handling in qeth_sysfs_(un)register
      Signed-off-by: NFrank Pavlic <fpavlic@de.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      8b98a37c
    • F
      [PATCH] s390: qeth driver fixes [5/6] · f956b690
      Frank Pavlic 提交于
      [PATCH 8/9] s390: qeth driver fixes [5/6]
      
      From: Frank Pavlic <fpavlic@de.ibm.com>
      	fix kernel panic in qdio queue handling.
      	qeth_qdio_clear_card() could be invoked by 2 CPUs
      	simultaneously (for example reboot event and recovery).
      Signed-off-by: NFrank Pavlic <fpavlic@de.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      f956b690
    • F
      [PATCH] s390: qeth driver fixes [4/6] · 09d2d38a
      Frank Pavlic 提交于
      [PATCH 7/9] s390: qeth driver fixes [4/6]
      
      From: Frank Pavlic <fpavlic@de.ibm.com>
      	- fix kernel crash due to race,
      	  set card->state to SOFTSETUP after
      	  card and card->dev are initialized properly.
      	- remove CONFIG_QETH_PERF_STATS, use sysfs attribute instead,
      	  as we want to have the ability to turn on/off the
      	  statistics at runtime.
      Signed-off-by: NFrank Pavlic <fpavlic@de.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      09d2d38a
    • F
      [PATCH] s390: qeth driver fixes [3/6] · f7b65d70
      Frank Pavlic 提交于
      [PATCH 6/9] s390: qeth driver fixes [3/6]
      
      From: Frank Pavlic <fpavlic@de.ibm.com>
             	fixed kernel panic caused by qeth driver:
              Using a bonding device qeth driver will realloc
              headroom for every skb coming from the bond device.
              Once this happens qeth frees the original skb and
              set the skb pointer to the new realloced skb.
              Under heavy transmit workload (e.g.UDP streams) through bond
              network device the qdio output queue might get full.
              In this case we return with EBUSY from qeth_send_packet.
              Returning to qeth_hard_start_xmit routine
              the skb address on the stack still points to the old address,
              which has been freed before.
              Returning from qeth_hard_start_xmit with EBUSY results in
              requeuing the skb. In this case it corrupts the qdisc queue
              and results in kernel panic.
      Signed-off-by: NFrank Pavlic <fpavlic@de.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      f7b65d70
    • F
      [PATCH] s390: qeth driver fixes [1/6] · 330b6369
      Frank Pavlic 提交于
      [PATCH 4/9] s390: qeth driver fixes [1/6]
      
      From: Frank Pavlic <fpavlic@de.ibm.com>
      	- Drop incoming packets with vlan_tag set
                if card->vlangrp is not set.
              - use always vlan_hwaccel_rx to pass
      	  vlan frames to the stack.
              - fix recovery problem. Device was recovered
      	  properly but still not working.
      	  netif_carrier_on call right before
                recovery start fixes it.
      Signed-off-by: NFrank Pavlic <fpavlic@de.ibm.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      330b6369
  15. 20 8月, 2006 1 次提交
  16. 18 7月, 2006 1 次提交
  17. 12 7月, 2006 1 次提交
  18. 11 7月, 2006 1 次提交
  19. 09 7月, 2006 1 次提交
  20. 04 7月, 2006 1 次提交
  21. 01 7月, 2006 1 次提交
  22. 23 6月, 2006 1 次提交
    • H
      [NET]: Merge TSO/UFO fields in sk_buff · 7967168c
      Herbert Xu 提交于
      Having separate fields in sk_buff for TSO/UFO (tso_size/ufo_size) is not
      going to scale if we add any more segmentation methods (e.g., DCCP).  So
      let's merge them.
      
      They were used to tell the protocol of a packet.  This function has been
      subsumed by the new gso_type field.  This is essentially a set of netdev
      feature bits (shifted by 16 bits) that are required to process a specific
      skb.  As such it's easy to tell whether a given device can process a GSO
      skb: you just have to and the gso_type field and the netdev's features
      field.
      
      I've made gso_type a conjunction.  The idea is that you have a base type
      (e.g., SKB_GSO_TCPV4) that can be modified further to support new features.
      For example, if we add a hardware TSO type that supports ECN, they would
      declare NETIF_F_TSO | NETIF_F_TSO_ECN.  All TSO packets with CWR set would
      have a gso_type of SKB_GSO_TCPV4 | SKB_GSO_TCPV4_ECN while all other TSO
      packets would be SKB_GSO_TCPV4.  This means that only the CWR packets need
      to be emulated in software.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7967168c