[PATCH 2/2] bluetooth : do not move child device other than rfcomm
hci conn child devices other than rfcomm tty should not be moved here.
This is my lost, thanks for Barnaby's reporting and testing.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
net/bluetooth/hci_sysfs.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
--- linux/net/bluetooth/hci_sysfs.c 2008-02-16 06:38:56.0 +0800
+++ linux.new/net/bluetooth/hci_sysfs.c 2008-02-17 15:45:15.0 +0800
@@ -320,15 +320,14 @@ void hci_conn_add_sysfs(struct hci_conn
queue_work(btaddconn, &conn->work);
}
+/*
+ * The rfcomm tty device will possibly retain even when conn
+ * is down, and sysfs doesn't support move zombie device,
+ * so we should move the device before conn device is destroyed.
+ */
static int __match_tty(struct device *dev, void *data)
{
- /* The rfcomm tty device will possibly retain even when conn
-* is down, and sysfs doesn't support move zombie device,
-* so we should move the device before conn device is destroyed.
-* Due to the only child device of hci_conn dev is rfcomm
-* tty_dev, here just return 1
-*/
- return 1;
+ return !strncmp(dev->bus_id, "rfcomm", 6);
}
static void del_conn(struct work_struct *work)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] bluetooth : put hci dev after del conn
Move hci_dev_put to del_conn to avoid hci dev going away before hci conn.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
net/bluetooth/hci_conn.c |1 -
net/bluetooth/hci_sysfs.c |5 -
2 files changed, 4 insertions(+), 2 deletions(-)
diff -upr linux/net/bluetooth/hci_conn.c linux.new/net/bluetooth/hci_conn.c
--- linux/net/bluetooth/hci_conn.c 2008-02-16 06:38:56.0 +0800
+++ linux.new/net/bluetooth/hci_conn.c 2008-02-16 06:54:17.0 +0800
@@ -260,7 +260,6 @@ int hci_conn_del(struct hci_conn *conn)
tasklet_enable(&hdev->tx_task);
skb_queue_purge(&conn->data_q);
hci_conn_del_sysfs(conn);
- hci_dev_put(hdev);
return 0;
}
diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
--- linux/net/bluetooth/hci_sysfs.c 2008-02-16 06:38:56.0 +0800
+++ linux.new/net/bluetooth/hci_sysfs.c 2008-02-16 06:54:17.0 +0800
@@ -333,15 +333,18 @@ static int __match_tty(struct device *de
static void del_conn(struct work_struct *work)
{
- struct device *dev;
struct hci_conn *conn = container_of(work, struct hci_conn, work);
+ struct hci_dev *hdev = conn->hdev;
+ struct device *dev;
while (dev = device_find_child(&conn->dev, NULL, __match_tty)) {
device_move(dev, NULL);
put_device(dev);
}
+
device_del(&conn->dev);
put_device(&conn->dev);
+ hci_dev_put(hdev);
}
void hci_conn_del_sysfs(struct hci_conn *conn)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Remove MAC_FMT
From: Joe Perches <[EMAIL PROTECTED]> Date: Fri, 15 Feb 2008 09:42:55 -0800 > MAC_FMT is no longer used > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/8021q/vlan_dev.c - Use print_mac
From: Joe Perches <[EMAIL PROTECTED]> Date: Fri, 15 Feb 2008 09:42:50 -0800 > On Fri, 2008-02-15 at 02:58 -0800, David Miller wrote: > > From: Bruno Randolf <[EMAIL PROTECTED]> > > Date: Fri, 15 Feb 2008 19:48:05 +0900 > > > is there any chance to include a macro like this for printing mac > > addresses? > > > its advantage is that it can be used without the need to declare > > buffers for > > > print_mac(), for example: > > We specifically removed this sort of thing, please don't > > add it back. > > Remove direct use of MAC_FMT > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Support arbitrary initial TCP timestamps
From: Glenn Griffin <[EMAIL PROTECTED]> Date: Fri, 15 Feb 2008 09:47:08 -0800 > Introduce the ability to send arbitrary initial tcp timestamps that are not > tied directly to jiffies. The basic conecpt is every tcp_request_sock and > tcp_sock now has a ts_off offset that represents the difference between > tcp_time_stamp and the timestamp we send and expect to > receive. > > This has the advantage of not divulging system information (uptime) > depending on the policy chosen for the initial timestamps. > > A policy where ts_off is always set to zero should produce no change in > behavior. The policy implemented is not intended for real use, but just as > a simple example. A realistic example would probably be similar to the tcp > init sequence generator. > > Signed-off-by: Glenn Griffin <[EMAIL PROTECTED]> Adding yet another member to the already bloated tcp_sock structure to implement this is too high a cost. I would instead prefer that there be some global random number calculated when the first TCP socket is created, and use that as a global offset. You can even recompute it every few hours if you like. We do similar things already elsewhere. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] [XFRM]: Fix ordering issue in xfrm_dst_hash_transfer().
From: Sebastien Decugis <[EMAIL PROTECTED]> Date: Fri, 15 Feb 2008 14:45:04 +0900 > It works, thank you! > > Acked-by: Sebastien Decugis <[EMAIL PROTECTED]> Patch applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation
From: Martin Devera <[EMAIL PROTECTED]> Date: Fri, 15 Feb 2008 00:02:56 +0100 > From: Martin Devera <[EMAIL PROTECTED]> > > HTB is event driven algorithm and part of its work is to apply > scheduled events at proper times. It tried to defend itself from > livelock by processing only limited number of events per dequeue. > Because of faster computers some users already hit this hardcoded > limit. > This patch uses loops_per_jiffy variable to limit event processing > up to single jiffy interval and then delay remainder to other > jiffy. > > Signed-off-by: Martin Devera <[EMAIL PROTECTED]> I think we would be wise to use something other than loops_per_jiffy. Depending upon the loop calibration method used by a particular architecture it can me one of many different things. Some platforms don't even make use of it and thus leave it at it's default value of "1<<12", so using it as a heuristic here is arbitrary at best. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [IPV6]: Fix hardcoded removing of old module code
From: Wang Chen <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 17:37:47 +0800 > Rusty hardcoded the old module code. > We can remove it now. > > Signed-off-by: Wang Chen <[EMAIL PROTECTED]> Applied, thanks for removing this turd. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2][NETLABEL]: Move some initialization code into __init section.
From: Paul Moore <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 08:37:16 -0500 > On Wednesday 13 February 2008 6:12:06 am Pavel Emelyanov wrote: > > Everything that is called from netlbl_init() can be marked with > > __init. This moves 620 bytes from .text section to .text.init one. > > > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> > > I ran into problems with __init and __exit once because I didn't fully > understand their impact; this caused me to be rather hesitant to make use of > them. However, you seem to know what you are doing and these look like > reasonable changes to me so I'll ack this patch and if we do run into a > problem the fix should be pretty trivial. Yes, this stuff can be non-trivial at best on some days :-) > I appreciate you taking the time to find these optimizations, thanks again. > > Acked-by: Paul Moore <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2][NETLABEL]: Shrink the genl-ops registration code.
From: Paul Moore <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 08:33:08 -0500 > On Wednesday 13 February 2008 6:09:44 am Pavel Emelyanov wrote: > > Turning them to array and registration in a loop saves > > 80 lines of code and ~300 bytes from text section. > > > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> > > Definitely an improvement, thank you. > > Acked-by: Paul Moore <[EMAIL PROTECTED]> Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][AX25] ax25_out: check skb for NULL in ax25_kick()
From: Jarek Poplawski <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 11:56:07 + > [AX25] ax25_out: check skb for NULL in ax25_kick() > > According to some OOPS reports ax25_kick tries to clone NULL skbs > sometimes. It looks like a race with ax25_clear_queues(). Probably > there is no need to add more than a simple check for this yet. > Another report suggested there are probably also cases where ax25 > ->paclen == 0 can happen in ax25_output(); this wasn't confirmed > during testing but let's leave this debugging check for some time. > > Reported-and-tested-by: Jann Traschewski <[EMAIL PROTECTED]> > Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]> Applied, thanks Jarek. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix tcp_v4_send_synack() comment
From: Kris Katterjohn <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 19:03:59 -0600 > Hey everyone, > > I've attached a patch that fixes the comment above tcp_v4_send_synack() > in ipv4/tcp_ipv4.c. > > Signed-off-by: Kris Katterjohn <[EMAIL PROTECTED]> Applied, thanks. Please "-p1" root your patches in the future. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] fib_trie: move statistics to debugfs
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 13 Feb 2008 11:58:06 -0800 > Don't want /proc/net/fib_trie and /proc/net/fib_triestat to become > permanent kernel space ABI issues, so move to the safer confines of debugfs. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Stephen, the cat is already out of the bag. We already export this thing so if you want to export different stuff you'll have to provide it via some other means, somewhere else. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [resend] [PATCH] IPv4: Reset scope when changing address
From: Bjørn_Mork <[EMAIL PROTECTED]> Date: Sat, 16 Feb 2008 12:45:31 +0100 > <#part type=text/plain nofile=yes> > Any comments on this? Apparently introduced in 2.1.68, so there's not > much hurry. But I'd still like to hear whether that analysis is correct > or not... > MIME-Version: 1.0 > Content-Type: multipart/mixed; boundary="==-=-=" Please clear up all of the inline mime tag stuff in your outgoing emails. Your description and patch is very difficult to read because of this. Thank you. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote: > On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote: > > Hello, > > I was having problems with these FreedomLine cards with Linux before but > > tested it thoroughly today. This card uses DEC 21041 chip and has TP and > > BNC connectors: > > > > 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip > > 21041 [Tulip Pass 3] [1011:0014] (rev 21) > > > > > > de2104x driver was loaded automatically by udev and card seemed to work. > > Until I disconnected the TP cable and putting it back after a while. The > > driver then switched to (non-existing) AUI port and remained there. I tried > > to set media to TP using ethtool - and the whole kernel crashed because of > > BUG_ON(de_is_running(de)); > > in de_set_media(). Seems that the driver is unable to stop the DMA in > > de_stop_rxtx(). The BUG_ON() is probably fine normally. But the media selection sounds broken. It's possible to select the wrong media type with 21040 chip but shouldn't be possible with 21041. For 21040 support, see de21040_get_media_info(). But de21041_get_srom_info() is expected to determine which media types are supported from SEPROM "media blocks". My guess is that code is broken since it seems to work with de405 driver. If you care to work the difference, I'd be happy to make a patch to fix that up. Also, from code review, DE2104X driver still has a few places with potential PCI MMIO Write posting issues. Specifically, I was looking in de_stop_hw() and de_set_media(). Several other bits of code correctly flush MMIO writes: e.g. tulip_read_eeprom(). > > I commented out AUI detection in the driver - this time it switched to BNC > > after unplugging the cable and remained there. I also attempted to reset > > the chip when de_stop_rxtx failed but failed to do it. You'd have to basically hardcode only one media type and it's corresponding parameters. > > Then I found that there's de4x5 driver which supports the same cards as > > de2104x (and some other too) - and this one works fine! I can plug and > > unplug the cable and even change between TP and BNC ports just by > > unplugging one and plugging the other cable in. Unfortunately, this driver > > is blacklisted by default - at least in Slackware and Debian. ISTR there was a time when tulip would compete with de4x5 for devices. tulip is the preferred driver. That's clearly no longer the case and perhaps both distro's need to revisit this. > > The question is: why does de2104x exist? Does it work better with some > > hardware? de2104x is a "work in progress". That's why it's marked "EXPERIMENTAL" in the Kconfig file. > > BTW. Found that the problem exist at least since 2003: > > http://oss.sgi.com/archives/netdev/2003-08/msg00951.html > > Does the de2104x driver work correctly for anyone? No idea. I've only used tulip driver. thanks for the bug report, grant -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] IPv6 recursive locking
From: Daniel Lezcano <[EMAIL PROTECTED]> Date: Sun, 17 Feb 2008 19:30:03 +0100 > I think this bug was introduced by the commit: > > 69cc64d8d92bf852f933e90c888dfff083bd4fc9 > "[NDISC]: Fix race in generic address resolution". Yep and I'll revert this for now. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] IPv6 recursive locking
From: Kristof Provost <[EMAIL PROTECTED]>
Date: Sun, 17 Feb 2008 14:12:29 +
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> I'm running the current git (1309d4e68497184d2fd87e892ddf14076c2bda98)
> without problems. While I was toying with IPv6 on my local network I managed
> to completely hang my machine whenever it receives or sends a neighbour
> sollictation. At least, I think that's the cause. It started as soon as I
> installed radvd on the router. The included trace seems to point in the same
> direction.
>
> The machine is a Dell Latitude D505 (so x86). Network interfaces are e100 and
> ipw2200 (firmware not loaded). I'm currently using the e100.
>
> I'll try to bisect it but here's the trace already. Let me know if
> there's anything else you'd like to know.
I've committed the following revert to fix this, the race bug
will need another solution, perhaps the one which uses skb_copy().
commit 9ff566074689e3aed1488780b97714ec43ba361d
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Sun Feb 17 18:39:54 2008 -0800
Revert "[NDISC]: Fix race in generic address resolution"
This reverts commit 69cc64d8d92bf852f933e90c888dfff083bd4fc9.
It causes recursive locking in IPV6 because unlike other
neighbour layer clients, it even needs neighbour cache
entries to send neighbour soliciation messages :-(
We'll have to find another way to fix this race.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 7bb6a9a..a16cf1e 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -834,12 +834,18 @@ static void neigh_timer_handler(unsigned long arg)
}
if (neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) {
struct sk_buff *skb = skb_peek(&neigh->arp_queue);
-
+ /* keep skb alive even if arp_queue overflows */
+ if (skb)
+ skb_get(skb);
+ write_unlock(&neigh->lock);
neigh->ops->solicit(neigh, skb);
atomic_inc(&neigh->probes);
- }
+ if (skb)
+ kfree_skb(skb);
+ } else {
out:
- write_unlock(&neigh->lock);
+ write_unlock(&neigh->lock);
+ }
if (notify)
neigh_update_notify(neigh);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index c663fa5..8e17f65 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -368,6 +368,7 @@ static void arp_solicit(struct neighbour *neigh, struct
sk_buff *skb)
if (!(neigh->nud_state&NUD_VALID))
printk(KERN_DEBUG "trying to ucast probe in
NUD_INVALID\n");
dst_ha = neigh->ha;
+ read_lock_bh(&neigh->lock);
} else if ((probes -= neigh->parms->app_probes) < 0) {
#ifdef CONFIG_ARPD
neigh_app_ns(neigh);
@@ -377,6 +378,8 @@ static void arp_solicit(struct neighbour *neigh, struct
sk_buff *skb)
arp_send(ARPOP_REQUEST, ETH_P_ARP, target, dev, saddr,
dst_ha, dev->dev_addr, NULL);
+ if (dst_ha)
+ read_unlock_bh(&neigh->lock);
}
static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tbench regression in 2.6.25-rc1
On Fri, 2008-02-15 at 15:21 +0100, Eric Dumazet wrote:
> Zhang, Yanmin a écrit :
> > On Fri, 2008-02-15 at 07:05 +0100, Eric Dumazet wrote:
> >
> >> Zhang, Yanmin a �crit :
> >>
> >>> Comparing with kernel 2.6.24, tbench result has regression with
> >>> 2.6.25-rc1.
> >>>
> >>> 1) On 2 quad-core processor stoakley: 4%.
> >>> 2) On 4 quad-core processor tigerton: more than 30%.
> >>>
> >>> bisect located below patch.
> >>>
> >>> b4ce92775c2e7ff9cf79cca4e0a19c8c5fd6287b is first bad commit
> >>> commit b4ce92775c2e7ff9cf79cca4e0a19c8c5fd6287b
> >>> Author: Herbert Xu <[EMAIL PROTECTED]>
> >>> Date: Tue Nov 13 21:33:32 2007 -0800
> >>>
> >>> [IPV6]: Move nfheader_len into rt6_info
> >>>
> >>> The dst member nfheader_len is only used by IPv6. It's also currently
> >>> creating a rather ugly alignment hole in struct dst. Therefore this
> >>> patch
> >>> moves it from there into struct rt6_info.
> >>>
> >>>
> >>> As tbench uses ipv4, so the patch's real impact on ipv4 is it deletes
> >>> nfheader_len in dst_entry. It might change cache line alignment.
> >>>
> >>> To verify my finding, I just added nfheader_len back to dst_entry in
> >>> 2.6.25-rc1
> >>> and reran tbench on the 2 machines. Performance could be recovered
> >>> completely.
> >>>
> >>> I started cpu_number*2 tbench processes. On my 16-core tigerton:
> >>> #./tbench_srv &
> >>> #./tbench 32 127.0.0.1
> >>>
> >>> -yanmin
> >>>
> >> Yup. struct dst is sensitive to alignements, especially for benches.
> >>
> >> In the real world, we need to make sure that next pointer start at a cache
> >> line bondary (or a litle bit after), so that RT cache lookups use one
> >> cache
> >> line per entry instead of two. This permits better behavior in DDOS
> >> attacks.
> >>
> >> (check commit 1e19e02ca0c5e33ea73a25127dbe6c3b8fcaac4b for reference)
> >>
> >> Are you using a 64 or a 32 bit kernel ?
> >>
> > 64bit x86-64 machine. On another 4-way Madison Itanium machine, tbench has
> > the
> > similiar regression.
> >
> >
>
> On linux-2.6.25-rc1 x86_64 :
>
> offsetof(struct dst_entry, lastuse)=0xb0
> offsetof(struct dst_entry, __refcnt)=0xb8
> offsetof(struct dst_entry, __use)=0xbc
> offsetof(struct dst_entry, next)=0xc0
>
> So it should be optimal... I dont know why tbench prefers __refcnt being
> on 0xc0, since in this case lastuse will be on a different cache line...
>
> Each incoming IP packet will need to change lastuse, __refcnt and __use,
> so keeping them in the same cache line is a win.
>
> I suspect then that even this patch could help tbench, since it avoids
> writing lastuse...
>
> diff --git a/include/net/dst.h b/include/net/dst.h
> index e3ac7d0..24d3c4e 100644
> --- a/include/net/dst.h
> +++ b/include/net/dst.h
> @@ -147,7 +147,8 @@ static inline void dst_use(struct dst_entry *dst,
> unsigned long time)
> {
> dst_hold(dst);
> dst->__use++;
> - dst->lastuse = time;
> + if (time != dst->lastuse)
> + dst->lastuse = time;
> }
I did a quick test and this patch doesn't help tbench.
Thanks,
-yanmin
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken link-local multicast?
On Feb 15, Pekka Savola <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED]:~# ping6 -c 1 -I eth1 ff02::1 >> connect: Network is unreachable > > Maybe 'netstat -gn' could give clues, because you should be receiving a > response at least from the loopback address. Maybe your loopback > interface has went down, or ospf6d took it down and back up (at least > some time ago, kernel's v6 got very confused after that). The loopback is up. ospf6d /may/ have done something to it, but I do not know how to check this (and I cannot reboot these servers right now). 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever > You may also want to check out that your link-local address on the > interface you're pinging is still OK. Apparently it is: [EMAIL PROTECTED]:~# netstat -gn | grep eth1 eth11 224.0.0.5 eth11 224.0.0.1 eth11 ff02::6 eth11 ff02::5 eth12 ff02::1:ff00:0 eth11 ff02::2 eth11 ff02::1:ff00:89 eth11 ff02::1:ffd8:7dd eth11 ff02::1 These (except ff02::1:ffd8:7dd, which is different) are the same addresses of eth0, which works. On Feb 15, David Stevens <[EMAIL PROTECTED]> wrote: > Marco, > You called this a "firewall" -- do you get the same thing > when you have no iptables rules? Yes, I double checked again and reproduced these results with totally empty v6 chains. -- ciao, Marco -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH] Revert "[RTNETLINK]: Send a single notification on device state changes."
On Monday, 18 of February 2008, Jiri Kosina wrote:
> This reverts commit 45b503548210fe6f23e92b856421c2a3f05fd034.
>
> It contains deadlock, and breaks userspace applications (wpa_supplicant,
> networkmanager). References:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=10002
> http://bugzilla.kernel.org/show_bug.cgi?id=10002
I think Andrew has already queued this one up.
Thanks,
Rafael
> ---
> net/core/rtnetlink.c | 36 ++--
> 1 files changed, 10 insertions(+), 26 deletions(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index ecb02af..61ac8d0 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -504,7 +504,7 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct
> dst_entry *dst, u32 id,
>
> EXPORT_SYMBOL_GPL(rtnl_put_cacheinfo);
>
> -static int set_operstate(struct net_device *dev, unsigned char transition,
> bool send_notification)
> +static void set_operstate(struct net_device *dev, unsigned char transition)
> {
> unsigned char operstate = dev->operstate;
>
> @@ -527,12 +527,8 @@ static int set_operstate(struct net_device *dev,
> unsigned char transition, bool
> write_lock_bh(&dev_base_lock);
> dev->operstate = operstate;
> write_unlock_bh(&dev_base_lock);
> -
> - if (send_notification)
> - netdev_state_change(dev);
> - return 1;
> - } else
> - return 0;
> + netdev_state_change(dev);
> + }
> }
>
> static void copy_rtnl_link_stats(struct rtnl_link_stats *a,
> @@ -826,7 +822,6 @@ static int do_setlink(struct net_device *dev, struct
> ifinfomsg *ifm,
> if (tb[IFLA_BROADCAST]) {
> nla_memcpy(dev->broadcast, tb[IFLA_BROADCAST], dev->addr_len);
> send_addr_notify = 1;
> - modified = 1;
> }
>
> if (ifm->ifi_flags || ifm->ifi_change) {
> @@ -839,23 +834,16 @@ static int do_setlink(struct net_device *dev, struct
> ifinfomsg *ifm,
> dev_change_flags(dev, flags);
> }
>
> - if (tb[IFLA_TXQLEN]) {
> - if (dev->tx_queue_len != nla_get_u32(tb[IFLA_TXQLEN])) {
> - dev->tx_queue_len = nla_get_u32(tb[IFLA_TXQLEN]);
> - modified = 1;
> - }
> - }
> + if (tb[IFLA_TXQLEN])
> + dev->tx_queue_len = nla_get_u32(tb[IFLA_TXQLEN]);
>
> if (tb[IFLA_OPERSTATE])
> - modified |= set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]),
> false);
> + set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]));
>
> if (tb[IFLA_LINKMODE]) {
> - if (dev->link_mode != nla_get_u8(tb[IFLA_LINKMODE])) {
> - write_lock_bh(&dev_base_lock);
> - dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
> - write_lock_bh(&dev_base_lock);
> - modified = 1;
> - }
> + write_lock_bh(&dev_base_lock);
> + dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
> + write_unlock_bh(&dev_base_lock);
> }
>
> err = 0;
> @@ -869,10 +857,6 @@ errout:
>
> if (send_addr_notify)
> call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
> -
> - if (modified)
> - netdev_state_change(dev);
> -
> return err;
> }
>
> @@ -990,7 +974,7 @@ struct net_device *rtnl_create_link(struct net *net, char
> *ifname,
> if (tb[IFLA_TXQLEN])
> dev->tx_queue_len = nla_get_u32(tb[IFLA_TXQLEN]);
> if (tb[IFLA_OPERSTATE])
> - set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]), true);
> + set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]));
> if (tb[IFLA_LINKMODE])
> dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
>
--
"Premature optimization is the root of all evil." - Donald Knuth
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Subject: [PATCH] Revert "[RTNETLINK]: Send a single notification on device state changes."
This reverts commit 45b503548210fe6f23e92b856421c2a3f05fd034.
It contains deadlock, and breaks userspace applications (wpa_supplicant,
networkmanager). References:
http://bugzilla.kernel.org/show_bug.cgi?id=10002
http://bugzilla.kernel.org/show_bug.cgi?id=10002
---
net/core/rtnetlink.c | 36 ++--
1 files changed, 10 insertions(+), 26 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index ecb02af..61ac8d0 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -504,7 +504,7 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct
dst_entry *dst, u32 id,
EXPORT_SYMBOL_GPL(rtnl_put_cacheinfo);
-static int set_operstate(struct net_device *dev, unsigned char transition,
bool send_notification)
+static void set_operstate(struct net_device *dev, unsigned char transition)
{
unsigned char operstate = dev->operstate;
@@ -527,12 +527,8 @@ static int set_operstate(struct net_device *dev, unsigned
char transition, bool
write_lock_bh(&dev_base_lock);
dev->operstate = operstate;
write_unlock_bh(&dev_base_lock);
-
- if (send_notification)
- netdev_state_change(dev);
- return 1;
- } else
- return 0;
+ netdev_state_change(dev);
+ }
}
static void copy_rtnl_link_stats(struct rtnl_link_stats *a,
@@ -826,7 +822,6 @@ static int do_setlink(struct net_device *dev, struct
ifinfomsg *ifm,
if (tb[IFLA_BROADCAST]) {
nla_memcpy(dev->broadcast, tb[IFLA_BROADCAST], dev->addr_len);
send_addr_notify = 1;
- modified = 1;
}
if (ifm->ifi_flags || ifm->ifi_change) {
@@ -839,23 +834,16 @@ static int do_setlink(struct net_device *dev, struct
ifinfomsg *ifm,
dev_change_flags(dev, flags);
}
- if (tb[IFLA_TXQLEN]) {
- if (dev->tx_queue_len != nla_get_u32(tb[IFLA_TXQLEN])) {
- dev->tx_queue_len = nla_get_u32(tb[IFLA_TXQLEN]);
- modified = 1;
- }
- }
+ if (tb[IFLA_TXQLEN])
+ dev->tx_queue_len = nla_get_u32(tb[IFLA_TXQLEN]);
if (tb[IFLA_OPERSTATE])
- modified |= set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]),
false);
+ set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]));
if (tb[IFLA_LINKMODE]) {
- if (dev->link_mode != nla_get_u8(tb[IFLA_LINKMODE])) {
- write_lock_bh(&dev_base_lock);
- dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
- write_lock_bh(&dev_base_lock);
- modified = 1;
- }
+ write_lock_bh(&dev_base_lock);
+ dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
+ write_unlock_bh(&dev_base_lock);
}
err = 0;
@@ -869,10 +857,6 @@ errout:
if (send_addr_notify)
call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
-
- if (modified)
- netdev_state_change(dev);
-
return err;
}
@@ -990,7 +974,7 @@ struct net_device *rtnl_create_link(struct net *net, char
*ifname,
if (tb[IFLA_TXQLEN])
dev->tx_queue_len = nla_get_u32(tb[IFLA_TXQLEN]);
if (tb[IFLA_OPERSTATE])
- set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]), true);
+ set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]));
if (tb[IFLA_LINKMODE])
dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
--
1.5.2.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] IPv6 recursive locking
On Feb 17, 2008 7:30 PM, Daniel Lezcano <[EMAIL PROTECTED]> wrote:
> Kristof Provost wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Hi,
> >
> > I'm running the current git (1309d4e68497184d2fd87e892ddf14076c2bda98)
> > without problems. While I was toying with IPv6 on my local network I managed
> > to completely hang my machine whenever it receives or sends a neighbour
> > sollictation. At least, I think that's the cause. It started as soon as I
> > installed radvd on the router. The included trace seems to point in the same
> > direction.
> >
> > The machine is a Dell Latitude D505 (so x86). Network interfaces are e100
> > and
> > ipw2200 (firmware not loaded). I'm currently using the e100.
> >
> > I'll try to bisect it but here's the trace already. Let me know if
> > there's anything else you'd like to know.
>
> I think this bug was introduced by the commit:
>
> 69cc64d8d92bf852f933e90c888dfff083bd4fc9
> "[NDISC]: Fix race in generic address resolution".
I confirm this commit is the culprit.
I reported the same bug last Thursday, but it seems I made a mistake: I replied
to the original thread which led to this commit to report it. But as the thread
was a bit old it seems my answer hadn't been noticed.
See http://www.spinics.net/lists/netdev/msg55373.html
The lockup happens very quickly when you have IPv6 configured.
I think we should revert this commit for now.
Benjamin
>
>
>
> > [ 124.439831] =
> > [ 124.443689] [ INFO: possible recursive locking detected ]
> > [ 124.443689] 2.6.25-rc2 #33
> > [ 124.443689] -
> > [ 124.443689] swapper/0 is trying to acquire lock:
> > [ 124.443689] (&n->lock){-+-+}, at: []
> > neigh_resolve_output+0x139/0x290
> > [ 124.443689]
> > [ 124.443689] but task is already holding lock:
> > [ 124.443689] (&n->lock){-+-+}, at: []
> > neigh_timer_handler+0x14/0x280
> > [ 124.443689]
> > [ 124.443689] other info that might help us debug this:
> > [ 124.443689] 1 lock held by swapper/0:
> > [ 124.443689] #0: (&n->lock){-+-+}, at: []
> > neigh_timer_handler+0x14/0x280
> > [ 124.443689]
> > [ 124.443689] stack backtrace:
> > [ 124.443689] Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #33
> > [ 124.443689] [] __lock_acquire+0xd3a/0xf40
> > [ 124.443689] [] __kernel_text_address+0x18/0x30
> > [ 124.443689] [] lock_acquire+0x60/0x80
> > [ 124.443689] [] neigh_resolve_output+0x139/0x290
> > [ 124.443689] [] _write_lock_bh+0x2e/0x40
> > [ 124.443689] [] neigh_resolve_output+0x139/0x290
> > [ 124.443689] [] neigh_resolve_output+0x139/0x290
> > [ 124.443689] [] __lock_acquire+0xf05/0xf40
> > [ 124.443689] [] ndisc_dst_alloc+0xe0/0x170
> > [ 124.443689] [] ip6_output_finish+0xa4/0x110
> > [ 124.443689] [] __lock_acquire+0x11d/0xf40
> > [ 124.443689] [] ip6_output+0x5b9/0xba0
> > [ 124.443689] [] sock_alloc_send_skb+0x176/0x1d0
> > [ 124.443689] [] __ndisc_send+0x33b/0x540
> > [ 124.443690] [] __ndisc_send+0x1fe/0x540
> > [ 124.443690] [] ndisc_send_ns+0x69/0xa0
> > [ 124.443690] [] ndisc_solicit+0xee/0x1b0
> > [ 124.443690] [] mark_held_locks+0x35/0x80
> > [ 124.443690] [] _spin_unlock_irqrestore+0x45/0x60
> > [ 124.443690] [] trace_hardirqs_on+0x79/0x130
> > [ 124.443690] [] __mod_timer+0x9f/0xb0
> > [ 124.443690] [] neigh_timer_handler+0x143/0x280
> > [ 124.443690] [] run_timer_softirq+0x14a/0x1c0
> > [ 124.443690] [] neigh_timer_handler+0x0/0x280
> > [ 124.443690] [] neigh_timer_handler+0x0/0x280
> > [ 124.443690] [] __do_softirq+0x84/0x100
> > [ 124.443690] [] do_softirq+0x55/0x60
> > [ 124.443690] [] irq_exit+0x65/0x80
> > [ 124.443690] [] do_IRQ+0x40/0x70
> > [ 124.443690] [] common_interrupt+0x2e/0x34
> > [ 124.443690] [] acpi_power_on+0x3b/0x104
> > [ 124.443690] [] acpi_idle_enter_simple+0x194/0x1fe
> > [ 124.443690] [] acpi_idle_enter_bm+0xc1/0x2fc
> > [ 124.443690] [] cpuidle_idle_call+0x63/0xb0
> > [ 124.443690] [] cpuidle_idle_call+0x0/0xb0
> > [ 124.443690] [] cpu_idle+0x5d/0xf0
> > [ 124.443690] ===
> >
> > Kristof
> >
> --
>
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.25-rc2] System freezes ca. 1 minute after logging into KDE
On Feb 17, 2008 11:39 AM, Frans Pop <[EMAIL PROTECTED]> wrote: > (resend a third time because previous attempts never reached the lists > due to a bug in my MUA; my apologies to David for spamming his inbox) > > Linus Torvalds wrote: > > But hey, you can try to prove me wrong. I dare you. > Me too, me too! > > Weird issue this. > About a minute after logging into KDE the system freezes, but only > partially. The keyboard is completely dead in all cases (no console > switching, no SysRq), but some tasks stay running. One time music continued > playing, other times it stopped. One time the desktop clock continued > ticking, other times it stopped. One time I could close a window using the > mouse, but other windows were frozen. > It's not just KDE that's frozen; one time I switched to VT1 before the > freeze happened, but that became unusable too. > Zilch in the logs. > > I've bisected it down to: > commit 69cc64d8d92bf852f933e90c888dfff083bd4fc9 > Author: David S. Miller <[EMAIL PROTECTED]> > [NDISC]: Fix race in generic address resolution > > Confirmed that this is really the culprit by reverting this commit on top > of -rc2, which is now running fine. > > I'm using IPv6 (local network only) together with IPv4, use a bridge (br0) > and have an NFS4 mount active. I've encountered the same issue last Thursday. Here, I can hang my machine with ping6. I've also bisected it down to the same commit. I've sent some kernel traces which shows how the soft lock up occurs. See thread: "[PATCH][RFC] race in generic address resolution" http://www.spinics.net/lists/netdev/msg55375.html Benjamin > > Cheers, > FJP > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] New device for DM9601 usb net driver
> "Peter" == Peter Korsgaard <[EMAIL PROTECTED]> writes: > "Robert" == Robert Brockway <[EMAIL PROTECTED]> writes: Robert> Hi Peter. I've verified that the Hirose USB-100 (0x0a47, Robert> 0x9601) is a clone of the DAVICOM DM9601. I patched dm9601.c Robert> to identify this device and now have these in production. Robert> Unified diff against 2.6.24 attached. Peter> Thanks! Could you resend with a proper Signed-off-by: line? (you can add my acked-by) Peter> Acked-by: Peter Korsgaard <[EMAIL PROTECTED]> -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] update TULIP MAINTAINERS
Jeff, Kyle and I are co-maintaining tulip driver. Normally kyle will review my patchs and submit them. I'll deal with bugzilla.kernel.org bugs and try to resolve those bugs. thanks, grant Signed-off-by: Grant Grundler <[EMAIL PROTECTED]> --- linux-2.6.24.1/MAINTAINERS-ORIG 2008-02-17 10:33:52.0 -0800 +++ linux-2.6.24.1/MAINTAINERS 2008-02-17 10:47:01.0 -0800 @@ -3776,10 +3776,13 @@ W: http://www.auk.cx/tms380tr/ S: Maintained -TULIP NETWORK DRIVER -L: [EMAIL PROTECTED] -W: http://sourceforge.net/projects/tulip/ -S: Orphan +TULIP NETWORK DRIVERS +P: Grant Grundler +M: [EMAIL PROTECTED] +P: Kyle McMartin +M: [EMAIL PROTECTED] +L: netdev@vger.kernel.org +S: Maintained TUN/TAP driver P: Maxim Krasnyansky -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] IPv6 recursive locking
Kristof Provost wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm running the current git (1309d4e68497184d2fd87e892ddf14076c2bda98)
without problems. While I was toying with IPv6 on my local network I managed
to completely hang my machine whenever it receives or sends a neighbour
sollictation. At least, I think that's the cause. It started as soon as I
installed radvd on the router. The included trace seems to point in the same
direction.
The machine is a Dell Latitude D505 (so x86). Network interfaces are e100 and
ipw2200 (firmware not loaded). I'm currently using the e100.
I'll try to bisect it but here's the trace already. Let me know if
there's anything else you'd like to know.
I think this bug was introduced by the commit:
69cc64d8d92bf852f933e90c888dfff083bd4fc9
"[NDISC]: Fix race in generic address resolution".
[ 124.439831] =
[ 124.443689] [ INFO: possible recursive locking detected ]
[ 124.443689] 2.6.25-rc2 #33
[ 124.443689] -
[ 124.443689] swapper/0 is trying to acquire lock:
[ 124.443689] (&n->lock){-+-+}, at: []
neigh_resolve_output+0x139/0x290
[ 124.443689]
[ 124.443689] but task is already holding lock:
[ 124.443689] (&n->lock){-+-+}, at: []
neigh_timer_handler+0x14/0x280
[ 124.443689]
[ 124.443689] other info that might help us debug this:
[ 124.443689] 1 lock held by swapper/0:
[ 124.443689] #0: (&n->lock){-+-+}, at: []
neigh_timer_handler+0x14/0x280
[ 124.443689]
[ 124.443689] stack backtrace:
[ 124.443689] Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #33
[ 124.443689] [] __lock_acquire+0xd3a/0xf40
[ 124.443689] [] __kernel_text_address+0x18/0x30
[ 124.443689] [] lock_acquire+0x60/0x80
[ 124.443689] [] neigh_resolve_output+0x139/0x290
[ 124.443689] [] _write_lock_bh+0x2e/0x40
[ 124.443689] [] neigh_resolve_output+0x139/0x290
[ 124.443689] [] neigh_resolve_output+0x139/0x290
[ 124.443689] [] __lock_acquire+0xf05/0xf40
[ 124.443689] [] ndisc_dst_alloc+0xe0/0x170
[ 124.443689] [] ip6_output_finish+0xa4/0x110
[ 124.443689] [] __lock_acquire+0x11d/0xf40
[ 124.443689] [] ip6_output+0x5b9/0xba0
[ 124.443689] [] sock_alloc_send_skb+0x176/0x1d0
[ 124.443689] [] __ndisc_send+0x33b/0x540
[ 124.443690] [] __ndisc_send+0x1fe/0x540
[ 124.443690] [] ndisc_send_ns+0x69/0xa0
[ 124.443690] [] ndisc_solicit+0xee/0x1b0
[ 124.443690] [] mark_held_locks+0x35/0x80
[ 124.443690] [] _spin_unlock_irqrestore+0x45/0x60
[ 124.443690] [] trace_hardirqs_on+0x79/0x130
[ 124.443690] [] __mod_timer+0x9f/0xb0
[ 124.443690] [] neigh_timer_handler+0x143/0x280
[ 124.443690] [] run_timer_softirq+0x14a/0x1c0
[ 124.443690] [] neigh_timer_handler+0x0/0x280
[ 124.443690] [] neigh_timer_handler+0x0/0x280
[ 124.443690] [] __do_softirq+0x84/0x100
[ 124.443690] [] do_softirq+0x55/0x60
[ 124.443690] [] irq_exit+0x65/0x80
[ 124.443690] [] do_IRQ+0x40/0x70
[ 124.443690] [] common_interrupt+0x2e/0x34
[ 124.443690] [] acpi_power_on+0x3b/0x104
[ 124.443690] [] acpi_idle_enter_simple+0x194/0x1fe
[ 124.443690] [] acpi_idle_enter_bm+0xc1/0x2fc
[ 124.443690] [] cpuidle_idle_call+0x63/0xb0
[ 124.443690] [] cpuidle_idle_call+0x0/0xb0
[ 124.443690] [] cpu_idle+0x5d/0xf0
[ 124.443690] ===
Kristof
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [Bug 5839] uli526x partially recognizing interface
Patch fixes: http://bugzilla.kernel.org/show_bug.cgi?id=5839 Init sequence needs to poll phy until phy reset is complete. This is the same problem that I fixed in 2002 in tulip driver. Thanks to [EMAIL PROTECTED] for testing this patch. Thanks to Pozsar Balazs <[EMAIL PROTECTED]> for posting/testing a similar patch before: http://lkml.org/lkml/2006/8/21/45 Signed-off-by: Grant Grundler <[EMAIL PROTECTED]> diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c index ca2548e..1dd8485 100644 --- a/drivers/net/tulip/uli526x.c +++ b/drivers/net/tulip/uli526x.c @@ -484,9 +484,11 @@ static void uli526x_init(struct net_device *dev) struct uli526x_board_info *db = netdev_priv(dev); unsigned long ioaddr = db->ioaddr; u8 phy_tmp; + u8 timeout; u16 phy_value; u16 phy_reg_reset; + ULI526X_DBUG(0, "uli526x_init()", 0); /* Reset M526x MAC controller */ @@ -511,11 +513,19 @@ static void uli526x_init(struct net_device *dev) /* Parser SROM and media mode */ db->media_mode = uli526x_media_mode; - /* Phyxcer capability setting */ + /* phyxcer capability setting */ phy_reg_reset = phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id); phy_reg_reset = (phy_reg_reset | 0x8000); phy_write(db->ioaddr, db->phy_addr, 0, phy_reg_reset, db->chip_id); + + /* See IEEE 802.3-2002.pdf (Section 2, Chapter "22.2.4 Management +* functions") or phy data sheet for details on phy reset +*/ udelay(500); + timeout = 10; + while (timeout-- && + phy_read(db->ioaddr, db->phy_addr, 0, db->chip_id) & 0x8000) + udelay(100); /* Process Phyxcer Media Mode */ uli526x_set_phyxcer(db); -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] IPv6 recursive locking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm running the current git (1309d4e68497184d2fd87e892ddf14076c2bda98)
without problems. While I was toying with IPv6 on my local network I managed
to completely hang my machine whenever it receives or sends a neighbour
sollictation. At least, I think that's the cause. It started as soon as I
installed radvd on the router. The included trace seems to point in the same
direction.
The machine is a Dell Latitude D505 (so x86). Network interfaces are e100 and
ipw2200 (firmware not loaded). I'm currently using the e100.
I'll try to bisect it but here's the trace already. Let me know if
there's anything else you'd like to know.
[ 124.439831] =
[ 124.443689] [ INFO: possible recursive locking detected ]
[ 124.443689] 2.6.25-rc2 #33
[ 124.443689] -
[ 124.443689] swapper/0 is trying to acquire lock:
[ 124.443689] (&n->lock){-+-+}, at: []
neigh_resolve_output+0x139/0x290
[ 124.443689]
[ 124.443689] but task is already holding lock:
[ 124.443689] (&n->lock){-+-+}, at: []
neigh_timer_handler+0x14/0x280
[ 124.443689]
[ 124.443689] other info that might help us debug this:
[ 124.443689] 1 lock held by swapper/0:
[ 124.443689] #0: (&n->lock){-+-+}, at: []
neigh_timer_handler+0x14/0x280
[ 124.443689]
[ 124.443689] stack backtrace:
[ 124.443689] Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #33
[ 124.443689] [] __lock_acquire+0xd3a/0xf40
[ 124.443689] [] __kernel_text_address+0x18/0x30
[ 124.443689] [] lock_acquire+0x60/0x80
[ 124.443689] [] neigh_resolve_output+0x139/0x290
[ 124.443689] [] _write_lock_bh+0x2e/0x40
[ 124.443689] [] neigh_resolve_output+0x139/0x290
[ 124.443689] [] neigh_resolve_output+0x139/0x290
[ 124.443689] [] __lock_acquire+0xf05/0xf40
[ 124.443689] [] ndisc_dst_alloc+0xe0/0x170
[ 124.443689] [] ip6_output_finish+0xa4/0x110
[ 124.443689] [] __lock_acquire+0x11d/0xf40
[ 124.443689] [] ip6_output+0x5b9/0xba0
[ 124.443689] [] sock_alloc_send_skb+0x176/0x1d0
[ 124.443689] [] __ndisc_send+0x33b/0x540
[ 124.443690] [] __ndisc_send+0x1fe/0x540
[ 124.443690] [] ndisc_send_ns+0x69/0xa0
[ 124.443690] [] ndisc_solicit+0xee/0x1b0
[ 124.443690] [] mark_held_locks+0x35/0x80
[ 124.443690] [] _spin_unlock_irqrestore+0x45/0x60
[ 124.443690] [] trace_hardirqs_on+0x79/0x130
[ 124.443690] [] __mod_timer+0x9f/0xb0
[ 124.443690] [] neigh_timer_handler+0x143/0x280
[ 124.443690] [] run_timer_softirq+0x14a/0x1c0
[ 124.443690] [] neigh_timer_handler+0x0/0x280
[ 124.443690] [] neigh_timer_handler+0x0/0x280
[ 124.443690] [] __do_softirq+0x84/0x100
[ 124.443690] [] do_softirq+0x55/0x60
[ 124.443690] [] irq_exit+0x65/0x80
[ 124.443690] [] do_IRQ+0x40/0x70
[ 124.443690] [] common_interrupt+0x2e/0x34
[ 124.443690] [] acpi_power_on+0x3b/0x104
[ 124.443690] [] acpi_idle_enter_simple+0x194/0x1fe
[ 124.443690] [] acpi_idle_enter_bm+0xc1/0x2fc
[ 124.443690] [] cpuidle_idle_call+0x63/0xb0
[ 124.443690] [] cpuidle_idle_call+0x0/0xb0
[ 124.443690] [] cpu_idle+0x5d/0xf0
[ 124.443690] ===
Kristof
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHuEDNUEZ9DhGwDugRAgHaAJ9L6i924sEqim1Ti+rZH2qmGESx6wCfWYIY
PI1kcoY3SWN/O9TOLgGQC20=
=cvKu
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATHCH 0/16] ServerEngines 10Gb NIC driver
On Sun, Feb 17, 2008 at 02:25:36PM +0100, Sam Ravnborg wrote: > On Sat, Feb 16, 2008 at 07:51:13PM -0800, Subbu Seetharaman wrote: > > Patch 0/16 and 15/16 of this series are getting dropped by the > > spam filter. I am trying to get them across with changes > > that will please the spam filter. Sorry about the inconvenience. > > Below is the 0/16 of the series. > > > > -- > > Hi, > > > > > > I am sending a patch for network driver for ServerEngines 10Gb Network > > adapter for review. This patch includes the network driver and the OS > > neutral code that implements the interactions between the host drivers and > > the adapter. The adapter is a dual function device with network and storage > > functions. The network driver is a regular NIC driver. > > > > The low level library that manages the interaction with the adapter is > > common to both storage and network drivers and hence is organized under the > > directory drivers/message/beclib. The storage driver is not part of this > > patch and will be submitted after this review. > > > > This patch is made against 2.6.24.2 version of the kernel source. > > Hi Subbu. > > A few points about your submission (not your code as I have not looked at it). > - Use descriptive subjects - and not the same subject for all patches > - Include in each patch a diffstat - below the '^---' marker so > it is easy to spot what files are touched but so that the diffstat > does not get included in the changelog when applied. > - Do not break the build. Adding Makefile/Kconfig bits as the last patch > usually does the trick here. > - If you have generic funtionality add that first and then add what depnds on > it > later. > > Sam I just tried scripts/checkpatch.pl - it said: total: 250 errors, 837 warnings, 31889 lines checked That was for the full patch-set. I suggest you look into these. The goal is not to get down on 0/0 but close with some common sense applied. Sam -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATHCH 0/16] ServerEngines 10Gb NIC driver
On Sat, Feb 16, 2008 at 07:51:13PM -0800, Subbu Seetharaman wrote: > Patch 0/16 and 15/16 of this series are getting dropped by the > spam filter. I am trying to get them across with changes > that will please the spam filter. Sorry about the inconvenience. > Below is the 0/16 of the series. > > -- > Hi, > > > I am sending a patch for network driver for ServerEngines 10Gb Network > adapter for review. This patch includes the network driver and the OS > neutral code that implements the interactions between the host drivers and > the adapter. The adapter is a dual function device with network and storage > functions. The network driver is a regular NIC driver. > > The low level library that manages the interaction with the adapter is common > to both storage and network drivers and hence is organized under the > directory drivers/message/beclib. The storage driver is not part of this > patch and will be submitted after this review. > > This patch is made against 2.6.24.2 version of the kernel source. Hi Subbu. A few points about your submission (not your code as I have not looked at it). - Use descriptive subjects - and not the same subject for all patches - Include in each patch a diffstat - below the '^---' marker so it is easy to spot what files are touched but so that the diffstat does not get included in the changelog when applied. - Do not break the build. Adding Makefile/Kconfig bits as the last patch usually does the trick here. - If you have generic funtionality add that first and then add what depnds on it later. Sam -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [resend] 3c509: convert to isa_driver and pnp_driver v5
Hello,
this patch converts 3c509 driver to isa_driver and pnp_driver. The result is
that autoloading using udev and hibernation works with ISA PnP cards. It also
adds hibernation support for non-PnP ISA cards.
xcvr module parameter was removed as its value was not used.
Tested using 3 ISA cards in various combinations of PnP and non-PnP modes.
EISA and MCA only compile-tested.
Signed-off-by: Ondrej Zary <[EMAIL PROTECTED]>
--- linux-2.6.24-orig/drivers/net/3c509.c 2008-01-27 19:48:19.0
+0100
+++ linux-2.6.24-pentium/drivers/net/3c509.c2008-02-10 21:52:04.0
+0100
@@ -54,25 +54,24 @@
v1.19a 28Oct2002 Davud Ruggiero <[EMAIL PROTECTED]>
- Increase *read_eeprom udelay to workaround oops with
2 cards.
v1.19b 08Nov2002 Marc Zyngier <[EMAIL PROTECTED]>
- - Introduce driver model for EISA cards.
+ - Introduce driver model for EISA cards.
+ v1.20 04Feb2008 Ondrej Zary <[EMAIL PROTECTED]>
+ - convert to isa_driver and pnp_driver and some cleanups
*/
#define DRV_NAME "3c509"
-#define DRV_VERSION"1.19b"
-#define DRV_RELDATE"08Nov2002"
+#define DRV_VERSION"1.20"
+#define DRV_RELDATE"04Feb2008"
/* A few values that may be tweaked. */
/* Time in jiffies before concluding the transmitter is hung. */
#define TX_TIMEOUT (400*HZ/1000)
-/* Maximum events (Rx packets, etc.) to handle at each interrupt. */
-static int max_interrupt_work = 10;
#include
-#ifdef CONFIG_MCA
#include
-#endif
-#include
+#include
+#include
#include
#include
#include
@@ -97,10 +96,6 @@
static char version[] __initdata = DRV_NAME ".c:" DRV_VERSION " " DRV_RELDATE
" [EMAIL PROTECTED]";
-#if defined(CONFIG_PM) && (defined(CONFIG_MCA) || defined(CONFIG_EISA))
-#define EL3_SUSPEND
-#endif
-
#ifdef EL3_DEBUG
static int el3_debug = EL3_DEBUG;
#else
@@ -111,6 +106,7 @@
* a global variable so that the mca/eisa probe routines can increment
* it */
static int el3_cards = 0;
+#define EL3_MAX_CARDS 8
/* To minimize the size of the driver source I only define operating
constants if they are used several times. You'll need the manual
@@ -119,7 +115,7 @@
#define EL3_DATA 0x00
#define EL3_CMD 0x0e
#define EL3_STATUS 0x0e
-#define EEPROM_READ 0x80
+#defineEEPROM_READ 0x80
#define EL3_IO_EXTENT 16
@@ -168,23 +164,31 @@
*/
#define SKB_QUEUE_SIZE 64
+enum el3_cardtype { EL3_ISA, EL3_PNP, EL3_MCA, EL3_EISA };
+
struct el3_private {
struct net_device_stats stats;
- struct net_device *next_dev;
spinlock_t lock;
/* skb send-queue */
int head, size;
struct sk_buff *queue[SKB_QUEUE_SIZE];
- enum {
- EL3_MCA,
- EL3_PNP,
- EL3_EISA,
- } type; /* type of device */
- struct device *dev;
+ enum el3_cardtype type;
};
-static int id_port __initdata = 0x110; /* Start with 0x110 to avoid new sound
cards.*/
-static struct net_device *el3_root_dev;
+static int id_port;
+static int current_tag;
+static struct net_device *el3_devs[EL3_MAX_CARDS];
+
+/* Parameters that may be passed into the module. */
+static int debug = -1;
+static int irq[] = {-1, -1, -1, -1, -1, -1, -1, -1};
+/* Maximum events (Rx packets, etc.) to handle at each interrupt. */
+static int max_interrupt_work = 10;
+#ifdef CONFIG_PNP
+static int nopnp;
+#endif
+static int __init el3_common_init(struct net_device *dev);
+static void el3_common_remove(struct net_device *dev);
static ushort id_read_eeprom(int index);
static ushort read_eeprom(int ioaddr, int index);
static int el3_open(struct net_device *dev);
@@ -199,23 +203,279 @@
static void el3_down(struct net_device *dev);
static void el3_up(struct net_device *dev);
static const struct ethtool_ops ethtool_ops;
-#ifdef EL3_SUSPEND
+#ifdef CONFIG_PM
static int el3_suspend(struct device *, pm_message_t);
static int el3_resume(struct device *);
-#else
-#define el3_suspend NULL
-#define el3_resume NULL
#endif
/* generic device remove for all device types */
-#if defined(CONFIG_EISA) || defined(CONFIG_MCA)
static int el3_device_remove (struct device *device);
-#endif
#ifdef CONFIG_NET_POLL_CONTROLLER
static void el3_poll_controller(struct net_device *dev);
#endif
+/* Return 0 on success, 1 on error, 2 when found already detected PnP card */
+static int el3_isa_id_sequence(__be16 *phys_addr)
+{
+ short lrs_state = 0xff;
+ int i;
+
+ /* ISA boards are detected by sending the ID sequence to the
+ ID_PORT. We find cards past the first by setting the 'current_tag'
+ on cards as they are found. Cards with their tag set will not
+ respond to subsequent ID sequences. */
+
+ outb(0x00, id_port);
+ outb(0x00, id_port);
+ for (i = 0; i < 255; i++) {
+ outb(lrs_state, id_por
Re: RESEND, HTB(?) softlockup, vanilla 2.6.24
On Sun, Feb 17, 2008 at 02:03:33AM +0200, Denys Fedoryshchenko wrote: > Server is fully redundant now, so i apply patches (but i apply both, probably > it will make system more reliable somehow) and i enable required debug > options in kernel. So i will try to catch this bug few more times, probably > if it will generate more detailed info over netconsole it will be useful. I guess you mean the patches mentioned in the "BUG/ spinlock lockup"; they could be useful, but we are not sure this is the same problem. Anyway, if there are really stack overflows then we don't need any bug report after this: with stack data corrupted they would show some "false" problems. We need to find which code overflows and why. If you want to debug this, then try to make this more reproducible e.g. with CONFIG_4KSTACKS; anyway you should always turn on these options with such problems: CONFIG_DEBUG_STACKOVERFLOW CONFIG_DEBUG_STACK_USAGE. > Is there any project to dump console messages/kernel dump to disk? For ... I don't know, but there is probably something better: a project by Intel to save this in some cpu memory (or something...). But again: we don't need corrupted messages after stack overflow, and, if we don't let for this, maybe these netconsole messages would be properly printed and quite enough... > I notice some code in MTD(CONFIG_MTD_OOPS), but i am not sure it is correct > and will work if i will setup MTD emulation for block device. I'm not sure what do you mean by MTD emulation: it should be used with MTD devices only, I presume? Regards, Jarek P. PS: BTW, for HTB with actions I recommend my "sch_htb: htb_requeue fix", available in 2.6.25-rc. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] remove include/linux/netfilter_ipv4/ipt_SAME.h
This patch removes the no longer used include/linux/netfilter_ipv4/ipt_SAME.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/netfilter_ipv4/Kbuild |1 -
include/linux/netfilter_ipv4/ipt_SAME.h | 19 ---
2 files changed, 20 deletions(-)
553bf355efd03581a094d8a4e0b278e04228aae8 diff --git
a/include/linux/netfilter_ipv4/Kbuild b/include/linux/netfilter_ipv4/Kbuild
index 3a7105b..646d104 100644
--- a/include/linux/netfilter_ipv4/Kbuild
+++ b/include/linux/netfilter_ipv4/Kbuild
@@ -7,7 +7,6 @@ header-y += ipt_LOG.h
header-y += ipt_MARK.h
header-y += ipt_NFQUEUE.h
header-y += ipt_REJECT.h
-header-y += ipt_SAME.h
header-y += ipt_TCPMSS.h
header-y += ipt_TOS.h
header-y += ipt_TTL.h
diff --git a/include/linux/netfilter_ipv4/ipt_SAME.h
b/include/linux/netfilter_ipv4/ipt_SAME.h
deleted file mode 100644
index be6e682..000
--- a/include/linux/netfilter_ipv4/ipt_SAME.h
+++ /dev/null
@@ -1,19 +0,0 @@
-#ifndef _IPT_SAME_H
-#define _IPT_SAME_H
-
-#define IPT_SAME_MAX_RANGE 10
-
-#define IPT_SAME_NODST 0x01
-
-struct ipt_same_info
-{
- unsigned char info;
- u_int32_t rangesize;
- u_int32_t ipnum;
- u_int32_t *iparray;
-
- /* hangs off end. */
- struct nf_nat_range range[IPT_SAME_MAX_RANGE];
-};
-
-#endif /*_IPT_SAME_H*/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
