[patch 029/101] IPV6: HASHTABLES: Use appropriate seed for caluculating ehash index.

[patch 029/101] IPV6: HASHTABLES: Use appropriate seed for caluculating ehash index.

[Greg KH]

[-- Attachment #1: ipv6-hashtables-use-appropriate-seed-for-caluculating-ehash-index.patch --]
[-- Type: text/plain, Size: 1212 bytes --]

From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

Tetsuo Handa <handat@pm.nttdata.co.jp> told me that connect(2) with TCPv6
socket almost always took a few minutes to return when we did not have any
ports available in the range of net.ipv4.ip_local_port_range.

The reason was that we used incorrect seed for calculating index of
hash when we check established sockets in __inet6_check_established().

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/ipv6/inet6_hashtables.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.20.1.orig/net/ipv6/inet6_hashtables.c
+++ linux-2.6.20.1/net/ipv6/inet6_hashtables.c
@@ -172,7 +172,7 @@ static int __inet6_check_established(str
 	const struct in6_addr *saddr = &np->daddr;
 	const int dif = sk->sk_bound_dev_if;
 	const __portpair ports = INET_COMBINED_PORTS(inet->dport, lport);
-	const unsigned int hash = inet6_ehashfn(daddr, inet->num, saddr,
+	const unsigned int hash = inet6_ehashfn(daddr, lport, saddr,
 						inet->dport);
 	struct inet_ehash_bucket *head = inet_ehash_bucket(hinfo, hash);
 	struct sock *sk2;

--

[patch 097/101] revert "drivers/net/tulip/dmfe: support basic carrier detection"

[Greg KH]

[-- Attachment #1: revert-drivers-net-tulip-dmfe-support-basic-carrier-detection.patch --]
[-- Type: text/plain, Size: 2644 bytes --]


From: Andrew Morton <akpm@linux-foundation.org>

Revert 7628b0a8c01a02966d2228bdf741ddedb128e8f8.  Thomas Bachler
reports:

  Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe:
  support basic carrier detection) breaks networking on my Davicom DM9009. 
  ethtool always reports there is no link.  tcpdump shows incoming packets,
  but TX is disabled.  Reverting the above patch fixes the problem.


Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Valerie Henson <val_henson@linux.intel.com>
Cc: Thomas Bachler <thomas@archlinux.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/tulip/dmfe.c |    9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

--- linux-2.6.20.1.orig/drivers/net/tulip/dmfe.c
+++ linux-2.6.20.1/drivers/net/tulip/dmfe.c
@@ -187,7 +187,7 @@ struct rx_desc {
 struct dmfe_board_info {
 	u32 chip_id;			/* Chip vendor/Device ID */
 	u32 chip_revision;		/* Chip revision */
-	struct DEVICE *dev;		/* net device */
+	struct DEVICE *next_dev;	/* next device */
 	struct pci_dev *pdev;		/* PCI device */
 	spinlock_t lock;
 
@@ -399,8 +399,6 @@ static int __devinit dmfe_init_one (stru
 	/* Init system & device */
 	db = netdev_priv(dev);
 
-	db->dev = dev;
-
 	/* Allocate Tx/Rx descriptor memory */
 	db->desc_pool_ptr = pci_alloc_consistent(pdev, sizeof(struct tx_desc) * DESC_ALL_CNT + 0x20, &db->desc_pool_dma_ptr);
 	db->buf_pool_ptr = pci_alloc_consistent(pdev, TX_BUF_ALLOC * TX_DESC_CNT + 4, &db->buf_pool_dma_ptr);
@@ -428,7 +426,6 @@ static int __devinit dmfe_init_one (stru
 	dev->poll_controller = &poll_dmfe;
 #endif
 	dev->ethtool_ops = &netdev_ethtool_ops;
-	netif_carrier_off(db->dev);
 	spin_lock_init(&db->lock);
 
 	pci_read_config_dword(pdev, 0x50, &pci_pmr);
@@ -1053,7 +1050,6 @@ static void netdev_get_drvinfo(struct ne
 
 static const struct ethtool_ops netdev_ethtool_ops = {
 	.get_drvinfo		= netdev_get_drvinfo,
-	.get_link               = ethtool_op_get_link,
 };
 
 /*
@@ -1148,7 +1144,6 @@ static void dmfe_timer(unsigned long dat
 		/* Link Failed */
 		DMFE_DBUG(0, "Link Failed", tmp_cr12);
 		db->link_failed = 1;
-		netif_carrier_off(db->dev);
 
 		/* For Force 10/100M Half/Full mode: Enable Auto-Nego mode */
 		/* AUTO or force 1M Homerun/Longrun don't need */
@@ -1171,8 +1166,6 @@ static void dmfe_timer(unsigned long dat
 			if ( (db->media_mode & DMFE_AUTO) &&
 				dmfe_sense_speed(db) )
 				db->link_failed = 1;
-			else
-				netif_carrier_on(db->dev);
 			dmfe_process_mode(db);
 			/* SHOW_MEDIA_TYPE(db->op_mode); */
 		}

--

Re: [patch 097/101] revert "drivers/net/tulip/dmfe: support basic carrier detection"

[Stephen Hemminger]

On Wed, 07 Mar 2007 09:12:12 -0800
Greg KH <gregkh@suse.de> wrote:

> 
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> Revert 7628b0a8c01a02966d2228bdf741ddedb128e8f8.  Thomas Bachler
> reports:
> 
>   Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe:
>   support basic carrier detection) breaks networking on my Davicom DM9009. 
>   ethtool always reports there is no link.  tcpdump shows incoming packets,
>   but TX is disabled.  Reverting the above patch fixes the problem.
> 

Carrier detection support is important and should be fixed rather than removed.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [patch 097/101] revert "drivers/net/tulip/dmfe: support basic carrier detection"

[Dan Williams]

On Wed, 2007-03-07 at 10:14 -0800, Stephen Hemminger wrote:
> On Wed, 07 Mar 2007 09:12:12 -0800
> Greg KH <gregkh@suse.de> wrote:
> 
> > 
> > From: Andrew Morton <akpm@linux-foundation.org>
> > 
> > Revert 7628b0a8c01a02966d2228bdf741ddedb128e8f8.  Thomas Bachler
> > reports:
> > 
> >   Commit 7628b0a8c01a02966d2228bdf741ddedb128e8f8 (drivers/net/tulip/dmfe:
> >   support basic carrier detection) breaks networking on my Davicom DM9009. 
> >   ethtool always reports there is no link.  tcpdump shows incoming packets,
> >   but TX is disabled.  Reverting the above patch fixes the problem.
> > 
> 
> Carrier detection support is important and should be fixed rather than removed.

Definitely right.  If it doesn't work for your card, it needs to be
fixed for your card.

Dan

Re: [patch 097/101] revert "drivers/net/tulip/dmfe: support basic carrier detection"

[Linus Torvalds]

On Wed, 7 Mar 2007, Dan Williams wrote:
> 
> Definitely right.  If it doesn't work for your card, it needs to be
> fixed for your card.

Well, regressions are regressions. And they are a *lot* more important 
than any new features. If it doesn't work, it gets reverted.

		Linus