* Re: [PATCH]iwlwifi not correctly dealing with hotunplug
From: Dan Williams @ 2007-11-13 15:37 UTC (permalink / raw)
To: Oliver Neukum; +Cc: netdev
In-Reply-To: <200711131249.25320.oliver@neukum.org>
On Tue, 2007-11-13 at 12:49 +0100, Oliver Neukum wrote:
> It makes no sense to enable interrupts if a device has been unplugged.
> In addition if in doubt IRQ_HANDLED should be returned.
>
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
Might want to forward to linux-wireless@ ? And maybe cc the ipw2100@
sourceforge upstream lists too.
Dan
> Regards
> Oliver
>
> ----
>
> --- linux-2.6.24-rc1/drivers/net/wireless/iwlwifi/iwl3945-base.c.alt 2007-11-13 12:23:07.000000000 +0100
> +++ linux-2.6.24-rc1/drivers/net/wireless/iwlwifi/iwl3945-base.c 2007-11-13 12:26:00.000000000 +0100
> @@ -4850,7 +4850,7 @@ static irqreturn_t iwl_isr(int irq, void
> if ((inta == 0xFFFFFFFF) || ((inta & 0xFFFFFFF0) == 0xa5a5a5a0)) {
> /* Hardware disappeared */
> IWL_WARNING("HARDWARE GONE?? INTA == 0x%080x\n", inta);
> - goto none;
> + goto unplugged;
> }
>
> IWL_DEBUG_ISR("ISR inta 0x%08x, enabled 0x%08x, fh 0x%08x\n",
> @@ -4858,6 +4858,7 @@ static irqreturn_t iwl_isr(int irq, void
>
> /* iwl_irq_tasklet() will service interrupts and re-enable them */
> tasklet_schedule(&priv->irq_tasklet);
> +unplugged:
> spin_unlock(&priv->lock);
>
> return IRQ_HANDLED;
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/01] ipv6: RFC4214 Support (v2.0)
From: Vlad Yasevich @ 2007-11-13 15:51 UTC (permalink / raw)
To: Templin, Fred L
Cc: netdev, YOSHIFUJI Hideaki / 吉藤英明
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC24@XCH-NW-7V2.nw.nos.boeing.com>
Hi Fred
Some comments.
Templin, Fred L wrote:
> From: Fred L. Templin <fred.l.templin@boeing.com>
>
> This patch includes support for the Intra-Site Automatic Tunnel
> Addressing Protocol (ISATAP) per RFC4214. It uses the SIT
> module, and is configured using extensions to the "iproute2"
> utility.
>
> The following diffs are specific to the Linux 2.6.24-rc2 kernel
> distribution. This message includes the full and patchable diff text;
> please use this version to apply patches.
>
> Signed-off-by: Fred L. Templin <fred.l.templin@boeing.com>
>
> ---
>
> --- linux-2.6.24-rc2/include/linux/if.h.orig 2007-11-08 12:05:47.000000000 -0800
> +++ linux-2.6.24-rc2/include/linux/if.h 2007-11-08 08:26:44.000000000 -0800
> @@ -61,6 +61,7 @@
> #define IFF_MASTER_ALB 0x10 /* bonding master, balance-alb. */
> #define IFF_BONDING 0x20 /* bonding master or slave */
> #define IFF_SLAVE_NEEDARP 0x40 /* need ARPs for validation */
> +#define IFF_ISATAP 0x80 /* ISATAP interface (RFC4214) */
>
> #define IF_GET_IFACE 0x0001 /* for querying only */
> #define IF_GET_PROTO 0x0002
> --- linux-2.6.24-rc2/include/linux/in.h.orig 2007-11-09 08:00:32.000000000 -0800
> +++ linux-2.6.24-rc2/include/linux/in.h 2007-11-12 07:37:05.000000000 -0800
> @@ -253,6 +253,14 @@ struct sockaddr_in {
> #define ZERONET(x) (((x) & htonl(0xff000000)) == htonl(0x00000000))
> #define LOCAL_MCAST(x) (((x) & htonl(0xFFFFFF00)) == htonl(0xE0000000))
>
> +/* Special-Use IPv4 Addresses (RFC3330) */
> +#define PRIVATE_10(x) (((x) & htonl(0xff000000)) == htonl(0x0A000000))
> +#define LINKLOCAL_169(x) (((x) & htonl(0xffff0000)) == htonl(0xA9FE0000))
> +#define PRIVATE_172(x) (((x) & htonl(0xfff00000)) == htonl(0xAC100000))
> +#define TEST_192(x) (((x) & htonl(0xffffff00)) == htonl(0xC0000200))
> +#define ANYCAST_6TO4(x) (((x) & htonl(0xffffff00)) == htonl(0xC0586300))
> +#define PRIVATE_192(x) (((x) & htonl(0xffff0000)) == htonl(0xC0A80000))
> +#define TEST_198(x) (((x) & htonl(0xfffe0000)) == htonl(0xC6120000))
> #endif
>
> #endif /* _LINUX_IN_H */
> --- linux-2.6.24-rc2/include/net/addrconf.h.orig 2007-11-08 12:06:17.000000000 -0800
> +++ linux-2.6.24-rc2/include/net/addrconf.h 2007-11-12 14:29:51.000000000 -0800
> @@ -241,6 +241,12 @@ static inline int ipv6_addr_is_ll_all_ro
> addr->s6_addr32[3] == htonl(0x00000002));
> }
>
> +/* only for IFF_ISATAP interfaces */
> +static inline int ipv6_addr_is_isatap(const struct in6_addr *addr)
> +{
> + return ((addr->s6_addr32[2] | htonl(0x02000000)) == htonl(0x02005EFE));
> +}
> +
> #ifdef CONFIG_PROC_FS
> extern int if6_proc_init(void);
> extern void if6_proc_exit(void);
> --- linux-2.6.24-rc2/net/ipv6/addrconf.c.orig 2007-11-08 11:59:35.000000000 -0800
> +++ linux-2.6.24-rc2/net/ipv6/addrconf.c 2007-11-12 14:32:43.000000000 -0800
> @@ -75,7 +75,7 @@
> #include <net/ip.h>
> #include <net/netlink.h>
> #include <net/pkt_sched.h>
> -#include <linux/if_tunnel.h>
> +#include <net/ipip.h>
> #include <linux/rtnetlink.h>
>
> #ifdef CONFIG_IPV6_PRIVACY
> @@ -1424,6 +1424,20 @@ static int addrconf_ifid_infiniband(u8 *
> return 0;
> }
>
> +static int addrconf_ifid_isatap(u8 *eui, __be32 addr)
> +{
> +
> + eui[0] = 0x02; eui[1] = 0; eui[2] = 0x5E; eui[3] = 0xFE;
> + memcpy (eui+4, &addr, 4);
> +
> + if (ZERONET(addr) || PRIVATE_10(addr) || LOOPBACK(addr) ||
> + LINKLOCAL_169(addr) || PRIVATE_172(addr) || TEST_192(addr) ||
> + ANYCAST_6TO4(addr) || PRIVATE_192(addr) || TEST_198(addr) ||
> + MULTICAST(addr) || BADCLASS(addr)) eui[0] &= ~0x02;
Please put the assignment on its own line.
> +
> + return 0;
> +}
> +
> static int ipv6_generate_eui64(u8 *eui, struct net_device *dev)
> {
> switch (dev->type) {
> @@ -1435,6 +1449,9 @@ static int ipv6_generate_eui64(u8 *eui,
> return addrconf_ifid_arcnet(eui, dev);
> case ARPHRD_INFINIBAND:
> return addrconf_ifid_infiniband(eui, dev);
> + case ARPHRD_SIT:
> + if (dev->priv_flags & IFF_ISATAP)
> + return addrconf_ifid_isatap(eui, *(__be32 *)dev->dev_addr);
> }
> return -1;
> }
> @@ -1470,8 +1487,7 @@ regen:
> *
> * - Reserved subnet anycast (RFC 2526)
> * 11111101 11....11 1xxxxxxx
> - * - ISATAP (draft-ietf-ngtrans-isatap-13.txt) 5.1
> - * 00-00-5E-FE-xx-xx-xx-xx
> + * - ISATAP (RFC4214) 00-00-5E-FE-xx-xx-xx-xx
> * - value 0
> * - XXX: already assigned to an address on the device
> */
> @@ -2201,6 +2217,29 @@ static void addrconf_sit_config(struct n
> return;
> }
>
> + /* ISATAP (RFC4214) - NBMA link */
> + if (dev->priv_flags & IFF_ISATAP) {
> + struct in6_addr addr;
> +
> + addrconf_add_lroute(dev);
> +
> + ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0);
> +
> + if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) {
> + struct inet6_ifaddr *ifp;
> +
> + ifp = ipv6_add_addr(idev, &addr, 64,
> + IFA_LINK, IFA_F_PERMANENT);
> + if (!IS_ERR(ifp)) {
> + addrconf_prefix_route(&ifp->addr,
> + ifp->prefix_len, idev->dev, 0, 0);
> + addrconf_dad_start(ifp, 0);
> + in6_ifa_put(ifp);
> + }
> +
If ipv6_generate_eui64() or ipv6_add_addr() fail, you will still have a link-local
prefix route on the device.
You might want to pull out the above code into a separate function and do correct
clean-ups on failures.
> + return;
> + }
> +
> sit_add_v4_addrs(idev);
>
> if (dev->flags&IFF_POINTOPOINT) {
> @@ -2531,6 +2570,18 @@ static void addrconf_rs_timer(unsigned l
> * Announcement received after solicitation
> * was sent
> */
> +
> + /* ISATAP (RFC4214) - schedule next RS/RA */
> + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> + struct ip_tunnel *t = netdev_priv(ifp->idev->dev);
> + if (t->parms.i_key != INADDR_NONE) {
> + spin_lock(&ifp->lock);
> + ifp->probes = 0;
> + ifp->idev->if_flags &= ~(IF_RS_SENT|IF_RA_RCVD);
> + addrconf_mod_timer(ifp, AC_DAD, t->parms.o_key*HZ);
You are using a DAD timer to schedule RS?
> + spin_unlock(&ifp->lock);
> + }
> + }
> goto out;
> }
>
> @@ -2545,10 +2596,28 @@ static void addrconf_rs_timer(unsigned l
> ifp->idev->cnf.rtr_solicit_interval);
> spin_unlock(&ifp->lock);
>
> - ipv6_addr_all_routers(&all_routers);
> + /* ISATAP (RFC4214) - unicast RS */
> + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> + struct ip_tunnel *t = netdev_priv(ifp->idev->dev);
> +
> + if (t->parms.i_key == INADDR_NONE) goto out;
> +
> + ipv6_addr_set(&all_routers, htonl(0xFE800000), 0, 0, 0);
> + addrconf_ifid_isatap(all_routers.s6_addr + 8, t->parms.i_key);
> + } else
> + ipv6_addr_all_routers(&all_routers);
>
> ndisc_send_rs(ifp->idev->dev, &ifp->addr, &all_routers);
> } else {
> + /* ISATAP (RFC4214) - try again later */
> + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> + struct ip_tunnel *t = netdev_priv(ifp->idev->dev);
> + if (t->parms.i_key != INADDR_NONE) {
> + ifp->probes = 0;
> + ifp->idev->if_flags &= ~(IF_RS_SENT|IF_RA_RCVD);
> + addrconf_mod_timer(ifp, AC_DAD, t->parms.o_key*HZ);
Again, using DAD timer?
> + }
> + }
> spin_unlock(&ifp->lock);
> /*
> * Note: we do not support deprecated "all on-link"
> @@ -2594,6 +2663,7 @@ static void addrconf_dad_start(struct in
> spin_lock_bh(&ifp->lock);
>
> if (dev->flags&(IFF_NOARP|IFF_LOOPBACK) ||
> + dev->priv_flags&IFF_ISATAP ||
> !(ifp->flags&IFA_F_TENTATIVE) ||
> ifp->flags & IFA_F_NODAD) {
> ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
> @@ -2690,7 +2760,16 @@ static void addrconf_dad_completed(struc
> (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
> struct in6_addr all_routers;
>
> - ipv6_addr_all_routers(&all_routers);
> + /* ISATAP (RFC4214) - unicast RS */
> + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> + struct ip_tunnel *t = netdev_priv(ifp->idev->dev);
> +
> + if (t->parms.i_key == INADDR_NONE) return;
> +
> + ipv6_addr_set(&all_routers, htonl(0xFE800000), 0, 0, 0);
> + addrconf_ifid_isatap(all_routers.s6_addr + 8, t->parms.i_key);
> + } else
> + ipv6_addr_all_routers(&all_routers);
>
> /*
> * If a host as already performed a random delay
> --- linux-2.6.24-rc2/net/ipv6/sit.c.orig 2007-11-08 12:03:41.000000000 -0800
> +++ linux-2.6.24-rc2/net/ipv6/sit.c 2007-11-12 14:30:52.000000000 -0800
> @@ -16,6 +16,7 @@
> * Changes:
> * Roger Venning <r.venning@telstra.com>: 6to4 support
> * Nate Thompson <nate@thebog.net>: 6to4 support
> + * Fred L. Templin <fltemplin@acm.org>: isatap support
> */
>
> #include <linux/module.h>
> @@ -182,6 +183,8 @@ static struct ip_tunnel * ipip6_tunnel_l
> dev->init = ipip6_tunnel_init;
> nt->parms = *parms;
>
> + if (parms->i_key) dev->priv_flags |= IFF_ISATAP;
> +
> if (register_netdevice(dev) < 0) {
> free_netdev(dev);
> goto failed;
> @@ -382,6 +385,47 @@ static int ipip6_rcv(struct sk_buff *skb
> IPCB(skb)->flags = 0;
> skb->protocol = htons(ETH_P_IPV6);
> skb->pkt_type = PACKET_HOST;
> +
> + /* ISATAP (RFC4214) - check source address */
> + if (tunnel->dev->priv_flags & IFF_ISATAP) {
> + struct neighbour *neigh;
> + struct dst_entry *dst;
> + struct flowi fl;
> + struct in6_addr *addr6;
> + struct ipv6hdr *iph6;
> +
> + /* from ISATAP router */
> + if ((tunnel->parms.i_key != INADDR_NONE) &&
> + (iph->saddr == tunnel->parms.i_key)) goto accept;
> +
> + iph6 = ipv6_hdr(skb);
> + addr6 = &iph6->saddr;
> +
> + /* from legitimate previous hop */
> + memset(&fl, 0, sizeof(fl));
> + fl.proto = iph6->nexthdr;
> + ipv6_addr_copy(&fl.fl6_dst, addr6);
> + fl.oif = tunnel->dev->ifindex;
> + security_skb_classify_flow(skb, &fl);
> +
> + if (!(dst = ip6_route_output(NULL, &fl)) ||
> + (dst->dev != tunnel->dev) ||
> + ((neigh = dst->neighbour) == NULL)) goto drop;
You are catching the error conditions incorrectly. ip6_route_output will return
a pointer to dst whose error field will be set if the route lookup failed. You need
to do something like:
dst = ip6_route_output(NULL, &fl);
if (dst->error || dst->dev != tunnel->dev || ...)
Also, please put the 'goto' on its own line.
> +
> + addr6 = (struct in6_addr*)&neigh->primary_key;
> +
> + if (!(ipv6_addr_is_isatap(addr6)) ||
> + (addr6->s6_addr32[3] != iph->saddr)) {
> +drop:
> + tunnel->stat.rx_errors++;
> + read_unlock(&ipip6_lock);
> + dst_release(dst);
> + kfree_skb(skb);
> + return 0;
> + }
> + dst_release(dst);
> + }
> +accept:
You never use the 'drop' or 'accept' tags. You can remove them. Also, it appears
that you are doing some validations on the tunnel. Might want to split that out into its
own function and just call that.
-vlad
> tunnel->stat.rx_packets++;
> tunnel->stat.rx_bytes += skb->len;
> skb->dev = tunnel->dev;
> @@ -444,6 +488,29 @@ static int ipip6_tunnel_xmit(struct sk_b
> if (skb->protocol != htons(ETH_P_IPV6))
> goto tx_error;
>
> + /* ISATAP (RFC4214) - must come before 6to4 */
> + if (dev->priv_flags & IFF_ISATAP) {
> + struct neighbour *neigh = NULL;
> +
> + if (skb->dst)
> + neigh = skb->dst->neighbour;
> +
> + if (neigh == NULL) {
> + if (net_ratelimit())
> + printk(KERN_DEBUG "sit: nexthop == NULL\n");
> + goto tx_error;
> + }
> +
> + addr6 = (struct in6_addr*)&neigh->primary_key;
> + addr_type = ipv6_addr_type(addr6);
> +
> + if ((addr_type & IPV6_ADDR_UNICAST) &&
> + ipv6_addr_is_isatap(addr6))
> + dst = addr6->s6_addr32[3];
> + else
> + goto tx_error;
> + }
> +
> if (!dst)
> dst = try_6to4(&iph6->daddr);
>
> @@ -651,6 +718,8 @@ ipip6_tunnel_ioctl (struct net_device *d
> ipip6_tunnel_unlink(t);
> t->parms.iph.saddr = p.iph.saddr;
> t->parms.iph.daddr = p.iph.daddr;
> + t->parms.i_key = p.i_key;
> + t->parms.o_key = p.o_key;
> memcpy(dev->dev_addr, &p.iph.saddr, 4);
> memcpy(dev->broadcast, &p.iph.daddr, 4);
> ipip6_tunnel_link(t);
> @@ -663,6 +732,8 @@ ipip6_tunnel_ioctl (struct net_device *d
> if (cmd == SIOCCHGTUNNEL) {
> t->parms.iph.ttl = p.iph.ttl;
> t->parms.iph.tos = p.iph.tos;
> + t->parms.i_key = p.i_key;
> + t->parms.o_key = p.o_key;
> }
> if (copy_to_user(ifr->ifr_ifru.ifru_data, &t->parms, sizeof(p)))
> err = -EFAULT;
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Benoit Boissinot @ 2007-11-13 15:52 UTC (permalink / raw)
To: Mark Lord
Cc: Ingo Molnar, Andrew Morton, David Miller, protasnb, linux-kernel,
netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input,
bugme-daemon
In-Reply-To: <4739AFE0.20705@rtr.ca>
On Nov 13, 2007 3:08 PM, Mark Lord <liml@rtr.ca> wrote:
>
> Ingo Molnar wrote:
> ..
> > This is all QA-101 that _cannot be argued against on a rational basis_,
> > it's just that these sorts of things have been largely ignored for
> > years, in favor of the all-too-easy "open source means many eyeballs and
> > that is our QA" answer, which is a _good_ answer but by far not the most
> > intelligent answer! Today "many eyeballs" is simply not good enough and
> > nature (and other OS projects) will route us around if we dont change.
> ..
>
> QA-101 and "many eyeballs" are not at all in opposition.
> The latter is how we find out about bugs on uncommon hardware,
> and the former is what we need to track them and overall quality.
>
> A HUGE problem I have with current "efforts", is that once someone
> reports a bug, the onus seems to be 99% on the *reporter* to find
> the exact line of code or commit. Ghad what a repressive method.
>
Btw, I used to test every -mm kernel. But since I've switched distros
(gentoo->ubuntu)
and I have less time, I feel it's harder to test -rc or -mm kernels (I
know this isn't a lkml problem
but more a distro problem, but I would love having an ubuntu blessed
repo with current dev kernel
for the latest stable ubuntu release).
For debugging, maybe it's time someone does an amazon ec2+s3 service
to automate the bisecting
and create .deb/.rpm from git, I don't know how much it would cost though.
regards,
Benoit
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Ray Lee @ 2007-11-13 15:57 UTC (permalink / raw)
To: Giacomo A. Catenazzi
Cc: Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb,
linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia,
linux-input, bugme-daemon
In-Reply-To: <4739C1B0.8000803@cateee.net>
On Nov 13, 2007 7:24 AM, Giacomo A. Catenazzi <cate@cateee.net> wrote:
> As a long time kernel tester, I see some problem with the
> newer "new development model". In the short merge windows,
> after to much time, there are to many patches.
I think the root issue there is that it's hard to get all testers to
run a bisect, but easy to ask them to test snapshots. Right now the
snapshots are generated nightly, but I think it would make more sense
if they were generated every N patches, for some value of N...
Of course, for that to really work, we have to ensure that the result
is always compilable, which has been getting better, but not perfect.
Ray
^ permalink raw reply
* Re: Weird network problems with 2.6.23-rc2
From: Ray Lee @ 2007-11-13 16:03 UTC (permalink / raw)
To: Shish; +Cc: linux-kernel, netdev
In-Reply-To: <20070811083959.305b0421.shish@shishnet.org>
Hello there Shish,
On Aug 10, 2007 11:39 PM, Shish <shish@shishnet.org> wrote:
> Something seems to have broken in 2.6.23-rc2, and I'm not sure what, or
> where I should look for further debugging. The info I have:
>
> On my 2.6.23-rc2 desktop, things run fine.
>
> On my test server, built from the same source tree, networking goes
> strange every few minutes, with the following symptoms:
>
> o) running ping against the server, the first ping goes through;
> further pings go AWOL until about icmp_seq=30, when I get 4-5 icmp
> replies (marked as DUP!), then no pings for a while, then dups, and so
> on.
>
> o) the server doesn't see ARP replies. According to tcpdump, the server
> will send eg "who has 192.168.0.2? tell 192.168.0.1"; the client in
> question will recieve the packet and send a response, but nothing shows
> up in the server-side tcpdump.
>
> o) after a few minutes of random network troubles, everything will work
> fine again, (ping is normal, arp replies are seen, tcp sessions work)
> for a few minutes.
>
> o) The server's dmesg shows lots of "short udp packet" messages
>
> o) ifdown then ifup'ing the interfaces fixes things, temporarily.
>
> Reverting to 2.6.22, everything seems to be running fine (but no lguest,
> which is what I came for :( )
>
> I've also tried with the latest code from git, the behaviour is the same
> as 2.6.23-rc2.
Several questions. What network card do you have on your server? Is
this still reproducible with the latest code from git? If so, it would
be extremely helpful if you could do a bisect between 2.6.22 and
2.6.23-rc2. Feel free to ask for help if you need it.
Ray
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Thomas Gleixner @ 2007-11-13 16:07 UTC (permalink / raw)
To: Mark Lord
Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev,
alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <4739ADA2.4060604@rtr.ca>
On Tue, 13 Nov 2007, Mark Lord wrote:
> Andrew Morton wrote:
> > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich"
> > <protasnb@gmail.com> wrote:
> ..
> > > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't
> > > boot (ARM, Timer)
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9229
> > > Kernel: 2.6.23
> >
> > No response from developers
> ..
The bug report is bogus. ARM has no CONFIG_HPET_TIMER.
> Note: that same bug exists/existed on i386 back when NO_HZ was
> introduced (2.6.21?). I still see it from time to time on my Quad core
> system (very rare), but not any more on my Duo notebook where it used
> to happen about 1 in n boots (n < 10).
>
> AFAICT no fix was ever released for it.
Hmm, at which point does the boot stop ?
> > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9275
> > > Kernel: 2.6.23
> > > This is HP notebook nc6320 T2400 945GM
> > No response from developers
> ..
>
> I *still* get very slow resume-from-RAM quite often here
> (new in 2.6.22 kernel, wasn't there in early 2.6.23-rc*).
Hmm. Which one 22 or 23 ?
> Something eventually times out after a minute or so
> and it comes back. Cannot make it happen reliably,
> unless I'm in a hurry to get something done. :)
> I suspect USB here, probably the same loopy bug that
> we added a "loop limit failsafe" for back in 2.6.21(?).
Do you have a pointer to that please ?
Thanks,
tglx
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Thomas Gleixner @ 2007-11-13 16:08 UTC (permalink / raw)
To: Mark Lord
Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev,
alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <4739B245.9040305@rtr.ca>
On Tue, 13 Nov 2007, Mark Lord wrote:
> Mark Lord wrote:
> > Andrew Morton wrote:
> > > On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich"
> > > <protasnb@gmail.com> wrote:
> > ..
> ..
> > > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=9275
> > > > Kernel: 2.6.23
> > > > This is HP notebook nc6320 T2400 945GM
> > > No response from developers
> > ..
> >
> > I *still* get very slow resume-from-RAM quite often here
> > (new in 2.6.22 kernel, wasn't there in early 2.6.23-rc*).
> ..
>
> Typo. That should have said:
>
> > (new in 2.6.23 kernel, wasn't there in early 2.6.23-rc*).
Just asked that :) Is there a chance to bisect that ?
Thanks,
tglx
^ permalink raw reply
* Re: Strange delays / what usually happens every 10 min?
From: Eric Dumazet @ 2007-11-13 16:23 UTC (permalink / raw)
To: Florian Boelstler; +Cc: linux-kernel, netdev
In-Reply-To: <fhcc39$51b$1@ger.gmane.org>
Florian Boelstler a écrit :
> Hi,
>
> this issue has been already discussed on the kernelnewbies mailing
> list [1],[2] and suggested to be further discussed here.
>
> I am currently working on a MPC8540-based custom board, which runs Linux
> 2.6.15 (arch/ppc). The original Linux sources have been modified to
> support that custom board. (Additional patches to support LTT are
> applied as well, though disabled in the running kernel)
>
> I set up a periodically running kernel thread, which is delayed for a
> single jiffy using schedule_timeout() in an infinite loop. It is used to
> measure delays between invocations of that thread. For measuring the
> distance in time the PPC's time base lower half register is used
> (obtained using get_cycles() defined in asm/timex.h).
>
> The thread calculates the delay to the previous run and only outputs the
> result if a new maximum value has been determined (in respect to all
> previous cycles). Further the thread outputs a warning if a very "high"
> delay was determined. I.e. a delay greater than 5ms.
>
> While running that test driver a delay of about 10ms _exactly_ occurs
> every 10 minutes.
>
> The kernel is configured using CONFIG_HZ=1000 and CONFIG_PREEMPT.
> The CCB is at 333MHz, whereas the TBR update rate is 333 MHz / 8, i.e.
> 41,625 MHz.
> Kernel configuration as a whole is found here:
> http://nopaste.info/5e4d0283bb.html
>
> And now the funny part starts.
> I got a response from Bruce Rowen on kernelnewbies, telling me that he
> came across the same problem. He increased his AMD-Geode-based
> platform to 1GB of RAM (256MB before) and also hit the
> 10-minutes-issue a few month ago (using Linux 2.6.13).
> Going back to 256MB cured the problem. I did the same thing by
> instructing the boot loader in order to only use 256 MB of RAM
> (instead of 512MB) and yes, the 10-minutes-issue was gone as well.
>
> Apart of some kernel threads almost all user processes have been killed
> during the test. Only SSH and a bash were running (whereas a test with
> network interfaces completely disabled and only operated from a serial
> console turned out the same results).
> The kernel comes with compiled in CIFS support, some kernel debugging
> features like soft-lockup detection and preemption debugging. I.e. ps
> lists the kernel threads ksoftirqd, watchdog, events, khelper, kthread,
> kblockd, pdflush, aio, cifsoplockd and cifsdnotifyd.
>
> An appropriate userspace test tool based on nanosleep() determined the
> same results like the kernel thread:
>
> root@mpc0:/# /tmp/wait.rt
> looping 1 milli seconds nanosleep ...
> 15:26:16: #1 FRAME MAX 1996 us (at 4139773004 ticks)
> 15:26:16: #2 FRAME MAX 2002 us (at 4139856360 ticks)
> 15:26:16: #155 FRAME MAX 2102 us (at 4152597854 ticks)
> 15:41:37: #460398 FRAME MAX 8941 us (at 3813406605 ticks)
> 15:41:37: #460398 FRAME HIGH 8941 us (at 3813406605 ticks)
> 15:51:37: #760394 FRAME MAX 9936 us (at 3018602602 ticks)
> 15:51:37: #760394 FRAME HIGH 9936 us (at 3018602602 ticks)
> 16:01:37: #1060390 FRAME HIGH 9935 us (at 2223798809 ticks)
> 16:11:37: #1360386 FRAME HIGH 9934 us (at 1428994989 ticks)
> 16:21:37: #1660382 FRAME HIGH 9935 us (at 634191241 ticks)
> [...]
>
> Thanks for any help!
>
> Cheers,
>
> Florian
>
> [1] http://thread.gmane.org/gmane.linux.kernel.kernelnewbies/23419
> [2] http://thread.gmane.org/gmane.linux.kernel.kernelnewbies/23426
>
Hi Florian
I think you hit the periodic flush of IP route cache, which is fired
every 600 seconds per default.
(Check /proc/sys/net/ipv4/route/secret_interval )
For a 1GB machine, this hash table is so big that a full scan might take
more than 10 ms, even if empty.
Instead of using less RAM, you could just boot with rhash_entries=1024
to lower the size of this table.
Or just change secret_interval to 2000000 for example (not much more
because * HZ could overflow)
Eric
^ permalink raw reply
* RE: [PATCH 01/01] ipv6: RFC4214 Support (v2.0)
From: Templin, Fred L @ 2007-11-13 16:32 UTC (permalink / raw)
To: Vlad Yasevich
Cc: netdev, YOSHIFUJI Hideaki / 吉藤英明
In-Reply-To: <4739C7EA.5070609@hp.com>
HI Vlad,
> -----Original Message-----
> From: Vlad Yasevich [mailto:vladislav.yasevich@hp.com]
> Sent: Tuesday, November 13, 2007 7:51 AM
> To: Templin, Fred L
> Cc: netdev@vger.kernel.org; YOSHIFUJI Hideaki / 吉藤英明
> Subject: Re: [PATCH 01/01] ipv6: RFC4214 Support (v2.0)
>
> Hi Fred
>
> Some comments.
>
> Templin, Fred L wrote:
> > From: Fred L. Templin <fred.l.templin@boeing.com>
> >
> > This patch includes support for the Intra-Site Automatic Tunnel
> > Addressing Protocol (ISATAP) per RFC4214. It uses the SIT
> > module, and is configured using extensions to the "iproute2"
> > utility.
> >
> > The following diffs are specific to the Linux 2.6.24-rc2 kernel
> > distribution. This message includes the full and patchable
> diff text;
> > please use this version to apply patches.
> >
> > Signed-off-by: Fred L. Templin <fred.l.templin@boeing.com>
> >
> > ---
> >
> > --- linux-2.6.24-rc2/include/linux/if.h.orig
> 2007-11-08 12:05:47.000000000 -0800
> > +++ linux-2.6.24-rc2/include/linux/if.h 2007-11-08
> 08:26:44.000000000 -0800
> > @@ -61,6 +61,7 @@
> > #define IFF_MASTER_ALB 0x10 /* bonding
> master, balance-alb. */
> > #define IFF_BONDING 0x20 /* bonding
> master or slave */
> > #define IFF_SLAVE_NEEDARP 0x40 /* need ARPs
> for validation */
> > +#define IFF_ISATAP 0x80 /* ISATAP interface
> (RFC4214) */
> >
> > #define IF_GET_IFACE 0x0001 /* for querying only */
> > #define IF_GET_PROTO 0x0002
> > --- linux-2.6.24-rc2/include/linux/in.h.orig
> 2007-11-09 08:00:32.000000000 -0800
> > +++ linux-2.6.24-rc2/include/linux/in.h 2007-11-12
> 07:37:05.000000000 -0800
> > @@ -253,6 +253,14 @@ struct sockaddr_in {
> > #define ZERONET(x) (((x) & htonl(0xff000000)) == htonl(0x00000000))
> > #define LOCAL_MCAST(x) (((x) & htonl(0xFFFFFF00)) ==
> htonl(0xE0000000))
> >
> > +/* Special-Use IPv4 Addresses (RFC3330) */
> > +#define PRIVATE_10(x) (((x) & htonl(0xff000000)) ==
> htonl(0x0A000000))
> > +#define LINKLOCAL_169(x) (((x) & htonl(0xffff0000)) ==
> htonl(0xA9FE0000))
> > +#define PRIVATE_172(x) (((x) & htonl(0xfff00000)) ==
> htonl(0xAC100000))
> > +#define TEST_192(x) (((x) & htonl(0xffffff00)) ==
> htonl(0xC0000200))
> > +#define ANYCAST_6TO4(x) (((x) & htonl(0xffffff00)) ==
> htonl(0xC0586300))
> > +#define PRIVATE_192(x) (((x) & htonl(0xffff0000)) ==
> htonl(0xC0A80000))
> > +#define TEST_198(x) (((x) & htonl(0xfffe0000)) ==
> htonl(0xC6120000))
> > #endif
> >
> > #endif /* _LINUX_IN_H */
> > --- linux-2.6.24-rc2/include/net/addrconf.h.orig
> 2007-11-08 12:06:17.000000000 -0800
> > +++ linux-2.6.24-rc2/include/net/addrconf.h 2007-11-12
> 14:29:51.000000000 -0800
> > @@ -241,6 +241,12 @@ static inline int ipv6_addr_is_ll_all_ro
> > addr->s6_addr32[3] == htonl(0x00000002));
> > }
> >
> > +/* only for IFF_ISATAP interfaces */
> > +static inline int ipv6_addr_is_isatap(const struct in6_addr *addr)
> > +{
> > + return ((addr->s6_addr32[2] | htonl(0x02000000)) ==
> htonl(0x02005EFE));
> > +}
> > +
> > #ifdef CONFIG_PROC_FS
> > extern int if6_proc_init(void);
> > extern void if6_proc_exit(void);
> > --- linux-2.6.24-rc2/net/ipv6/addrconf.c.orig
> 2007-11-08 11:59:35.000000000 -0800
> > +++ linux-2.6.24-rc2/net/ipv6/addrconf.c 2007-11-12
> 14:32:43.000000000 -0800
> > @@ -75,7 +75,7 @@
> > #include <net/ip.h>
> > #include <net/netlink.h>
> > #include <net/pkt_sched.h>
> > -#include <linux/if_tunnel.h>
> > +#include <net/ipip.h>
> > #include <linux/rtnetlink.h>
> >
> > #ifdef CONFIG_IPV6_PRIVACY
> > @@ -1424,6 +1424,20 @@ static int addrconf_ifid_infiniband(u8 *
> > return 0;
> > }
> >
> > +static int addrconf_ifid_isatap(u8 *eui, __be32 addr)
> > +{
> > +
> > + eui[0] = 0x02; eui[1] = 0; eui[2] = 0x5E; eui[3] = 0xFE;
> > + memcpy (eui+4, &addr, 4);
> > +
> > + if (ZERONET(addr) || PRIVATE_10(addr) || LOOPBACK(addr) ||
> > + LINKLOCAL_169(addr) || PRIVATE_172(addr) ||
> TEST_192(addr) ||
> > + ANYCAST_6TO4(addr) || PRIVATE_192(addr) || TEST_198(addr) ||
> > + MULTICAST(addr) || BADCLASS(addr)) eui[0] &= ~0x02;
>
> Please put the assignment on its own line.
OK.
> > +
> > + return 0;
> > +}
> > +
> > static int ipv6_generate_eui64(u8 *eui, struct net_device *dev)
> > {
> > switch (dev->type) {
> > @@ -1435,6 +1449,9 @@ static int ipv6_generate_eui64(u8 *eui,
> > return addrconf_ifid_arcnet(eui, dev);
> > case ARPHRD_INFINIBAND:
> > return addrconf_ifid_infiniband(eui, dev);
> > + case ARPHRD_SIT:
> > + if (dev->priv_flags & IFF_ISATAP)
> > + return addrconf_ifid_isatap(eui,
> *(__be32 *)dev->dev_addr);
> > }
> > return -1;
> > }
> > @@ -1470,8 +1487,7 @@ regen:
> > *
> > * - Reserved subnet anycast (RFC 2526)
> > * 11111101 11....11 1xxxxxxx
> > - * - ISATAP (draft-ietf-ngtrans-isatap-13.txt) 5.1
> > - * 00-00-5E-FE-xx-xx-xx-xx
> > + * - ISATAP (RFC4214) 00-00-5E-FE-xx-xx-xx-xx
> > * - value 0
> > * - XXX: already assigned to an address on the device
> > */
> > @@ -2201,6 +2217,29 @@ static void addrconf_sit_config(struct n
> > return;
> > }
> >
> > + /* ISATAP (RFC4214) - NBMA link */
> > + if (dev->priv_flags & IFF_ISATAP) {
> > + struct in6_addr addr;
> > +
> > + addrconf_add_lroute(dev);
> > +
> > + ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0);
> > +
> > + if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) {
> > + struct inet6_ifaddr *ifp;
> > +
> > + ifp = ipv6_add_addr(idev, &addr, 64,
> > + IFA_LINK, IFA_F_PERMANENT);
> > + if (!IS_ERR(ifp)) {
> > + addrconf_prefix_route(&ifp->addr,
> > + ifp->prefix_len,
> idev->dev, 0, 0);
> > + addrconf_dad_start(ifp, 0);
> > + in6_ifa_put(ifp);
> > + }
> > +
>
> If ipv6_generate_eui64() or ipv6_add_addr() fail, you will
> still have a link-local
> prefix route on the device.
>
> You might want to pull out the above code into a separate
> function and do correct
> clean-ups on failures.
OK.
> > + return;
> > + }
> > +
> > sit_add_v4_addrs(idev);
> >
> > if (dev->flags&IFF_POINTOPOINT) {
> > @@ -2531,6 +2570,18 @@ static void addrconf_rs_timer(unsigned l
> > * Announcement received after solicitation
> > * was sent
> > */
> > +
> > + /* ISATAP (RFC4214) - schedule next RS/RA */
> > + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> > + struct ip_tunnel *t =
> netdev_priv(ifp->idev->dev);
> > + if (t->parms.i_key != INADDR_NONE) {
> > + spin_lock(&ifp->lock);
> > + ifp->probes = 0;
> > + ifp->idev->if_flags &=
> ~(IF_RS_SENT|IF_RA_RCVD);
> > + addrconf_mod_timer(ifp, AC_DAD,
> t->parms.o_key*HZ);
>
> You are using a DAD timer to schedule RS?
I am using the DAD timer to re-DAD the link local, which
in turn schedules RS.
> > + spin_unlock(&ifp->lock);
> > + }
> > + }
> > goto out;
> > }
> >
> > @@ -2545,10 +2596,28 @@ static void addrconf_rs_timer(unsigned l
> > ifp->idev->cnf.rtr_solicit_interval);
> > spin_unlock(&ifp->lock);
> >
> > - ipv6_addr_all_routers(&all_routers);
> > + /* ISATAP (RFC4214) - unicast RS */
> > + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> > + struct ip_tunnel *t =
> netdev_priv(ifp->idev->dev);
> > +
> > + if (t->parms.i_key == INADDR_NONE) goto out;
> > +
> > + ipv6_addr_set(&all_routers,
> htonl(0xFE800000), 0, 0, 0);
> > +
> addrconf_ifid_isatap(all_routers.s6_addr + 8, t->parms.i_key);
> > + } else
> > + ipv6_addr_all_routers(&all_routers);
> >
> > ndisc_send_rs(ifp->idev->dev, &ifp->addr, &all_routers);
> > } else {
> > + /* ISATAP (RFC4214) - try again later */
> > + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> > + struct ip_tunnel *t =
> netdev_priv(ifp->idev->dev);
> > + if (t->parms.i_key != INADDR_NONE) {
> > + ifp->probes = 0;
> > + ifp->idev->if_flags &=
> ~(IF_RS_SENT|IF_RA_RCVD);
> > + addrconf_mod_timer(ifp, AC_DAD,
> t->parms.o_key*HZ);
>
> Again, using DAD timer?
Same as above.
> > + }
> > + }
> > spin_unlock(&ifp->lock);
> > /*
> > * Note: we do not support deprecated "all on-link"
> > @@ -2594,6 +2663,7 @@ static void addrconf_dad_start(struct in
> > spin_lock_bh(&ifp->lock);
> >
> > if (dev->flags&(IFF_NOARP|IFF_LOOPBACK) ||
> > + dev->priv_flags&IFF_ISATAP ||
> > !(ifp->flags&IFA_F_TENTATIVE) ||
> > ifp->flags & IFA_F_NODAD) {
> > ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
> > @@ -2690,7 +2760,16 @@ static void addrconf_dad_completed(struc
> > (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
> > struct in6_addr all_routers;
> >
> > - ipv6_addr_all_routers(&all_routers);
> > + /* ISATAP (RFC4214) - unicast RS */
> > + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> > + struct ip_tunnel *t =
> netdev_priv(ifp->idev->dev);
> > +
> > + if (t->parms.i_key == INADDR_NONE) return;
> > +
> > + ipv6_addr_set(&all_routers,
> htonl(0xFE800000), 0, 0, 0);
> > +
> addrconf_ifid_isatap(all_routers.s6_addr + 8, t->parms.i_key);
> > + } else
> > + ipv6_addr_all_routers(&all_routers);
> >
> > /*
> > * If a host as already performed a random delay
> > --- linux-2.6.24-rc2/net/ipv6/sit.c.orig 2007-11-08
> 12:03:41.000000000 -0800
> > +++ linux-2.6.24-rc2/net/ipv6/sit.c 2007-11-12
> 14:30:52.000000000 -0800
> > @@ -16,6 +16,7 @@
> > * Changes:
> > * Roger Venning <r.venning@telstra.com>: 6to4 support
> > * Nate Thompson <nate@thebog.net>: 6to4 support
> > + * Fred L. Templin <fltemplin@acm.org>: isatap support
> > */
> >
> > #include <linux/module.h>
> > @@ -182,6 +183,8 @@ static struct ip_tunnel * ipip6_tunnel_l
> > dev->init = ipip6_tunnel_init;
> > nt->parms = *parms;
> >
> > + if (parms->i_key) dev->priv_flags |= IFF_ISATAP;
> > +
> > if (register_netdevice(dev) < 0) {
> > free_netdev(dev);
> > goto failed;
> > @@ -382,6 +385,47 @@ static int ipip6_rcv(struct sk_buff *skb
> > IPCB(skb)->flags = 0;
> > skb->protocol = htons(ETH_P_IPV6);
> > skb->pkt_type = PACKET_HOST;
> > +
> > + /* ISATAP (RFC4214) - check source address */
> > + if (tunnel->dev->priv_flags & IFF_ISATAP) {
> > + struct neighbour *neigh;
> > + struct dst_entry *dst;
> > + struct flowi fl;
> > + struct in6_addr *addr6;
> > + struct ipv6hdr *iph6;
> > +
> > + /* from ISATAP router */
> > + if ((tunnel->parms.i_key != INADDR_NONE) &&
> > + (iph->saddr ==
> tunnel->parms.i_key)) goto accept;
> > +
> > + iph6 = ipv6_hdr(skb);
> > + addr6 = &iph6->saddr;
> > +
> > + /* from legitimate previous hop */
> > + memset(&fl, 0, sizeof(fl));
> > + fl.proto = iph6->nexthdr;
> > + ipv6_addr_copy(&fl.fl6_dst, addr6);
> > + fl.oif = tunnel->dev->ifindex;
> > + security_skb_classify_flow(skb, &fl);
> > +
> > + if (!(dst = ip6_route_output(NULL, &fl)) ||
> > + (dst->dev != tunnel->dev) ||
> > + ((neigh = dst->neighbour) ==
> NULL)) goto drop;
>
> You are catching the error conditions incorrectly.
> ip6_route_output will return
> a pointer to dst whose error field will be set if the route
> lookup failed. You need
> to do something like:
> dst = ip6_route_output(NULL, &fl);
> if (dst->error || dst->dev !=
> tunnel->dev || ...)
OK.
> Also, please put the 'goto' on its own line.
OK.
> > +
> > + addr6 = (struct in6_addr*)&neigh->primary_key;
> > +
> > + if (!(ipv6_addr_is_isatap(addr6)) ||
> > + (addr6->s6_addr32[3] != iph->saddr)) {
> > +drop:
> > + tunnel->stat.rx_errors++;
> > + read_unlock(&ipip6_lock);
> > + dst_release(dst);
> > + kfree_skb(skb);
> > + return 0;
> > + }
> > + dst_release(dst);
> > + }
> > +accept:
>
> You never use the 'drop' or 'accept' tags. You can remove
> them.
OK.
> Also, it appears
> that you are doing some validations on the tunnel. Might
> want to split that out into its
> own function and just call that.
OK.
Fred
fred.l.templin@boeing.com
> -vlad
>
> > tunnel->stat.rx_packets++;
> > tunnel->stat.rx_bytes += skb->len;
> > skb->dev = tunnel->dev;
> > @@ -444,6 +488,29 @@ static int ipip6_tunnel_xmit(struct sk_b
> > if (skb->protocol != htons(ETH_P_IPV6))
> > goto tx_error;
> >
> > + /* ISATAP (RFC4214) - must come before 6to4 */
> > + if (dev->priv_flags & IFF_ISATAP) {
> > + struct neighbour *neigh = NULL;
> > +
> > + if (skb->dst)
> > + neigh = skb->dst->neighbour;
> > +
> > + if (neigh == NULL) {
> > + if (net_ratelimit())
> > + printk(KERN_DEBUG "sit: nexthop
> == NULL\n");
> > + goto tx_error;
> > + }
> > +
> > + addr6 = (struct in6_addr*)&neigh->primary_key;
> > + addr_type = ipv6_addr_type(addr6);
> > +
> > + if ((addr_type & IPV6_ADDR_UNICAST) &&
> > + ipv6_addr_is_isatap(addr6))
> > + dst = addr6->s6_addr32[3];
> > + else
> > + goto tx_error;
> > + }
> > +
> > if (!dst)
> > dst = try_6to4(&iph6->daddr);
> >
> > @@ -651,6 +718,8 @@ ipip6_tunnel_ioctl (struct net_device *d
> > ipip6_tunnel_unlink(t);
> > t->parms.iph.saddr = p.iph.saddr;
> > t->parms.iph.daddr = p.iph.daddr;
> > + t->parms.i_key = p.i_key;
> > + t->parms.o_key = p.o_key;
> > memcpy(dev->dev_addr, &p.iph.saddr, 4);
> > memcpy(dev->broadcast, &p.iph.daddr, 4);
> > ipip6_tunnel_link(t);
> > @@ -663,6 +732,8 @@ ipip6_tunnel_ioctl (struct net_device *d
> > if (cmd == SIOCCHGTUNNEL) {
> > t->parms.iph.ttl = p.iph.ttl;
> > t->parms.iph.tos = p.iph.tos;
> > + t->parms.i_key = p.i_key;
> > + t->parms.o_key = p.o_key;
> > }
> > if
> (copy_to_user(ifr->ifr_ifru.ifru_data, &t->parms, sizeof(p)))
> > err = -EFAULT;
> > -
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
^ permalink raw reply
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: Kok, Auke @ 2007-11-13 16:41 UTC (permalink / raw)
To: Patrick McHardy
Cc: Herbert Xu, e1000-devel, netdev, djohnson+linux-kernel,
linux-kernel, joonwpark81, David Miller, cfriesen, w
In-Reply-To: <4739961E.90708@trash.net>
Patrick McHardy wrote:
> Herbert Xu wrote:
>> On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
>>>> In other words we can make it so that nobody is in promiscuous
>>>> mode and therefore have to disable VLAN acceleration *unless*
>>>> they really want to be in that state. In which case it would
>>>> imply that they wish to see everything and therefore we should
>>>> disable VLAN acceleration.
>>> This is too complicated, we have multiple unicast MAC support
>>> in the driver API already, let's simply use it.
>>
>> Yes I agree. People not using Patrick's new API deserves to
>> get poor performance so they can switch over sooner :)
>>
>> What I was trying to say above is that e1000 currently uses
>> the old set_multicast_list interface (rather than dev_set_rx_mode)
>> so it's not immediately obvious why we're in promiscuous mode.
>> We could look at dev->promiscuity - !!uc_count but that feels a
>> bit fragile.
>>
>> Perhaps those who want to push this patch should be encouraged
>> to convert e1000 to the new interface :)
>
>
> I already posted a patch for this, not sure what happened to it.
> Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for e1000e as well?
Auke
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Randy Dunlap @ 2007-11-13 16:43 UTC (permalink / raw)
To: James Bottomley, mbligh
Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev,
alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon,
linux-scsi
In-Reply-To: <1194968001.3416.12.camel@localhost.localdomain>
On Tue, 13 Nov 2007 09:33:21 -0600 James Bottomley wrote:
> On Tue, 2007-11-13 at 03:15 -0800, Andrew Morton wrote:
> > >
> > SCSI==================================================================
> > >
> > > qla2xxx: driver initialization does not complete when booting with
> > > Port connected
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9267
> > > Kernel: 2.6.23.1
> >
> > No response from developers
>
> Urm, well, if no-one ever tells the SCSI list it's unrealistic to expect
> anyone to be working on it. As far as I can tell, email was sent to
> Andrew Vasquez only on 31 October. However, the fault looks to be
> generic, so he probably just dropped it.
It seems that new SCSI bugs need to be sent to linux-scsi@vger.kernel.org.
Martin, can you arrange that to happen automatically instead of
Andrew having to do it manually?
---
~Randy
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Ingo Molnar @ 2007-11-13 16:46 UTC (permalink / raw)
To: Mark Lord
Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev,
alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <4739AFE0.20705@rtr.ca>
* Mark Lord <liml@rtr.ca> wrote:
> Ingo Molnar wrote:
> ..
>> This is all QA-101 that _cannot be argued against on a rational basis_,
>> it's just that these sorts of things have been largely ignored for years,
>> in favor of the all-too-easy "open source means many eyeballs and that is
>> our QA" answer, which is a _good_ answer but by far not the most
>> intelligent answer! Today "many eyeballs" is simply not good enough and
>> nature (and other OS projects) will route us around if we dont change.
> ..
>
> QA-101 and "many eyeballs" are not at all in opposition.
yes, absolutely so - that's why i used the "good" qualifier. "Good is
not good enough" calls for additional efforts to make it more efficient,
not for the abolition of the many eyeballs concept (which would be
absurd). So what i wanted to say is that _sole_ reliance on the large
numbers of eyeballs is a fundamental mistake. It's even sometimes used
as an excuse to merge questionable stuff. "we'll find any bugs, many
eyeballs will make bugs shallow". In reality the many eyeballs are not
infinite, nor should they be taken for granted if they are used for
bogus things. We have to make sure the eyeballs stay 'many', and we also
have to make sure they are not wasted. It's a physical resource that
must be intelligently handled. Its positive effects can be easily wasted
and we do that today.
for example git-bisect was godsent. I remember that years ago bisection
of a bug was a very laborous task so that it was only used as a final,
last-ditch approach for really nasty bugs. Today we can autonomouly
bisect build bugs via a simple shell command around "git-bisect run",
without any human interaction! This freed up testing resources
enormously and made bisection one of the _first_ things that are tried
when bugs are met. We just need more of this (distros should offer
pre-built kernel rpm 'farms' for every important commit point and
automated tools for users to easily specify breakage points, without
them having to install those kernels individually) , and everyone should
be aware of the fact that we still suck (we merge too much crap and
still dont have good enough tools to de-crappify what we merge) and that
we are losing testers.
Ingo
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Ingo Molnar @ 2007-11-13 16:49 UTC (permalink / raw)
To: Benoit Boissinot
Cc: Mark Lord, Andrew Morton, David Miller, protasnb, linux-kernel,
netdev, alsa-devel, linux-ide, linux-pcmcia, linux-input,
bugme-daemon
In-Reply-To: <40f323d00711130752k19cab8eauc3456721274b3267@mail.gmail.com>
* Benoit Boissinot <bboissin@gmail.com> wrote:
> For debugging, maybe it's time someone does an amazon ec2+s3 service
> to automate the bisecting and create .deb/.rpm from git, I don't know
> how much it would cost though.
a few months ago i estimated the costs of this and it's just a few
terabytes so within arm's reach. As long as the .deb/.rpm's are built by
tracking -git in a rolling fashion CPU time should not be a big issue.
The only limit is download bandwidth - but even that problem might be
solvable via a huge git repository of ready-to-boot .o's that are linked
together on the tester's machine.
Ingo
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Randy Dunlap @ 2007-11-13 16:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev,
alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113134029.GA30978@elte.hu>
On Tue, 13 Nov 2007 14:40:29 +0100 Ingo Molnar wrote:
>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > > > Do you believe that our response to bug reports is adequate?
> > >
> > > Do you feel that making us feel and look like shit helps?
> >
> > That doesn't answer my question.
> >
> > See, first we need to work out whether we have a problem. If we do
> > this, then we can then have a think about what to do about it.
> >
> > I tried to convince the 2006 KS attendees that we have a problem and I
> > resoundingly failed. People seemed to think that we're doing OK.
We were a minority.
> > But it appears that data such as this contradicts that belief.
> >
> > This is not a minor matter. If the kernel _is_ slowly deteriorating
> > then this won't become readily apparent until it has been happening
> > for a number of years. By that stage there will be so much work to do
> > to get us back to an acceptable level that it will take a huge effort.
> > And it will take a long time after that for the kerel to get its
> > reputation back.
> >
> > So it is important that we catch deterioration *early* if it is
> > happening.
>
[agree with most of Ingo's moaning]
> (and this is in no way directed at the networking folks - it holds for
> all of us. I have one main complaint about networking: the separate
> netdev list is a bad idea - networking regressions should be discussed
> and fixed on lkml, like most other subsystems are. Any artificial split
> of the lk discussion space is bad.)
but here I disagree. LKML is already too busy and noisy.
Major subsystems need their own discussion areas.
---
~Randy
^ permalink raw reply
* Re: [PATCH 01/01] ipv6: RFC4214 Support (v2.0)
From: Vlad Yasevich @ 2007-11-13 16:59 UTC (permalink / raw)
To: Templin, Fred L
Cc: netdev, YOSHIFUJI Hideaki / 吉藤英明
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC27@XCH-NW-7V2.nw.nos.boeing.com>
Hi Fred
Templin, Fred L wrote:
>>> + return;
>>> + }
>>> +
>>> sit_add_v4_addrs(idev);
>>>
>>> if (dev->flags&IFF_POINTOPOINT) {
>>> @@ -2531,6 +2570,18 @@ static void addrconf_rs_timer(unsigned l
>>> * Announcement received after solicitation
>>> * was sent
>>> */
>>> +
>>> + /* ISATAP (RFC4214) - schedule next RS/RA */
>>> + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
>>> + struct ip_tunnel *t =
>> netdev_priv(ifp->idev->dev);
>>> + if (t->parms.i_key != INADDR_NONE) {
>>> + spin_lock(&ifp->lock);
>>> + ifp->probes = 0;
>>> + ifp->idev->if_flags &=
>> ~(IF_RS_SENT|IF_RA_RCVD);
>>> + addrconf_mod_timer(ifp, AC_DAD,
>> t->parms.o_key*HZ);
>>
>> You are using a DAD timer to schedule RS?
>
> I am using the DAD timer to re-DAD the link local, which
> in turn schedules RS.
>
Why? Seems to me that using the RS timer (AC_RS) gets you everything you
want and nothing you don't. You set probes to 0, which marks DAD complete,
thus you don't do DAD. You already have code in the addrconf_rs_timer() to
properly send the RS. So, your patch to sending the RS is much shorter if
you use the AC_RS timer.
Am I missing something?
Thanks
-vlad
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Adrian Bunk @ 2007-11-13 17:01 UTC (permalink / raw)
To: Ray Lee
Cc: Giacomo A. Catenazzi, Mark Lord, Ingo Molnar, Andrew Morton,
David Miller, protasnb, linux-kernel, netdev, alsa-devel,
linux-ide, linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <2c0942db0711130757g295add20re0ee423b84921d28@mail.gmail.com>
On Tue, Nov 13, 2007 at 07:57:54AM -0800, Ray Lee wrote:
> On Nov 13, 2007 7:24 AM, Giacomo A. Catenazzi <cate@cateee.net> wrote:
> > As a long time kernel tester, I see some problem with the
> > newer "new development model". In the short merge windows,
> > after to much time, there are to many patches.
>
> I think the root issue there is that it's hard to get all testers to
> run a bisect, but easy to ask them to test snapshots. Right now the
> snapshots are generated nightly, but I think it would make more sense
> if they were generated every N patches, for some value of N...
>...
I don't see a point in doing that - that would be a more manual
bisecting, and the result would not be one guilty commit.
Testers are not expected to be able to hack a kernel, but it's
reasonable to expect testers to be able to build their own kernels
(and your proposal wouldn't change that).
The small instruction below is enough for everyone who is able to
build his own kernel to do a git bisect.
> Ray
cu
Adrian
<-- snip -->
# install git
# clone Linus' tree:
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# start bisecting:
cd linux-2.6
git bisect start
git bisect bad v2.6.21
git bisect good v2.6.20
cp /path/to/.config .
# start a round
make oldconfig
make
# install kernel, check whether it's good or bad, then:
git bisect [bad|good]
# start next round
After at about 10-15 reboots you'll have found the guilty commit
("... is first bad commit").
More information on git bisecting:
man git-bisect
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Theodore Tso @ 2007-11-13 17:13 UTC (permalink / raw)
To: Benoit Boissinot
Cc: Mark Lord, Ingo Molnar, Andrew Morton, David Miller, protasnb,
linux-kernel, netdev, alsa-devel, linux-ide, linux-pcmcia,
linux-input, bugme-daemon
In-Reply-To: <40f323d00711130752k19cab8eauc3456721274b3267@mail.gmail.com>
On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote:
> Btw, I used to test every -mm kernel. But since I've switched distros
> (gentoo->ubuntu)
> and I have less time, I feel it's harder to test -rc or -mm kernels (I
> know this isn't a lkml problem
> but more a distro problem, but I would love having an ubuntu blessed
> repo with current dev kernel
> for the latest stable ubuntu release).
There are two parts to this. One is a Ubuntu development kernel which
we can give to large numbers of people to expand our testing pool.
But if we don't do a better job of responding to bug reports that
would be generated by expanded testing this won't necessarily help us.
The other an automated set of standard pre-built bisection points so
that testers can more easily localize a bug down to a few hundred
commits without needing to learn how to use "git bisect" (think Ubuntu
users).
So for the first, I've actually been playing with some plans to put
together an unofficial kernel that basically "what Ted is using on his
laptop". It generally has emergency bug fixes that haven't made it
into mainline, plus some other trees where I've been more aggressive
since I want to latest in wireless and powersaving technology, etc.
It has the property that "if it breaks, you get to keep both pieces
--- and I've helpfully included the git ID in the package name so you
can do the bisection yourself". If you want to try it, the first such
kernel is here:
http://www.kernel.org/~tytso/tbek
I wasn't planning on talking about it until it was more fully baked,
but if people want something vaguely stable based on 2.6.24-rc2, this
might be interesting.
As for the second, I was just talking to Arjan over pizza and beer
last night, and we reached the same conclusion as Ingo, which is this
really isn't that hard. It wouldn't be that hard to set up
infrastructure to do this, and it's just a matter of getting the disk
space and the network bandwidth togehter in the right place, plus a
relatively small amount of prgramming at least for the simplest
iteration of the idea. (As is quite common when doing designs over
beer, we talked about some more gradious web-based schemes to do
custom built kernels that was tied to the kernel bugzilla, but first
things first. :-)
- Ted
^ permalink raw reply
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: Patrick McHardy @ 2007-11-13 17:26 UTC (permalink / raw)
To: Kok, Auke
Cc: Herbert Xu, e1000-devel, netdev, djohnson+linux-kernel,
linux-kernel, joonwpark81, David Miller, cfriesen, w
In-Reply-To: <4739D3A5.4020503@intel.com>
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
Kok, Auke wrote:
> Patrick McHardy wrote:
>
>> I already posted a patch for this, not sure what happened to it.
>> Auke, any news on merging the secondary unicast address support?
>
> I dropped the ball on that one. Care to resend it and send me one for e1000e as well?
Patch for e1000 attached.
Does e1000e also work with PCI cards if I add the proper IDs?
Otherwise I could only send an untested patch.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 5701 bytes --]
[E1000]: Secondary unicast address support
Add support for configuring secondary unicast addresses. Unicast
addresses take precendece over multicast addresses when filling
the exact address filters to avoid going to promiscous mode.
When more unicast addresses are present than filter slots,
unicast filtering is disabled and all slots can be used for
multicast addresses.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 5d2e80a9c326ca529d278da823c8e4a4da91f612
tree 97a8ac20070b101c250e79912636124167a6dd07
parent 325d22df7b19e0116aff3391d3a03f73d0634ded
author Patrick McHardy <kaber@trash.net> Tue, 13 Nov 2007 18:23:34 +0100
committer Patrick McHardy <kaber@trash.net> Tue, 13 Nov 2007 18:23:34 +0100
drivers/net/e1000/e1000_main.c | 47 ++++++++++++++++++++++++++--------------
1 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 72deff0..5fd5f51 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -153,7 +153,7 @@ static void e1000_clean_tx_ring(struct e1000_adapter *adapter,
struct e1000_tx_ring *tx_ring);
static void e1000_clean_rx_ring(struct e1000_adapter *adapter,
struct e1000_rx_ring *rx_ring);
-static void e1000_set_multi(struct net_device *netdev);
+static void e1000_set_rx_mode(struct net_device *netdev);
static void e1000_update_phy_info(unsigned long data);
static void e1000_watchdog(unsigned long data);
static void e1000_82547_tx_fifo_stall(unsigned long data);
@@ -514,7 +514,7 @@ static void e1000_configure(struct e1000_adapter *adapter)
struct net_device *netdev = adapter->netdev;
int i;
- e1000_set_multi(netdev);
+ e1000_set_rx_mode(netdev);
e1000_restore_vlan(adapter);
e1000_init_manageability(adapter);
@@ -926,7 +926,7 @@ e1000_probe(struct pci_dev *pdev,
netdev->stop = &e1000_close;
netdev->hard_start_xmit = &e1000_xmit_frame;
netdev->get_stats = &e1000_get_stats;
- netdev->set_multicast_list = &e1000_set_multi;
+ netdev->set_rx_mode = &e1000_set_rx_mode;
netdev->set_mac_address = &e1000_set_mac;
netdev->change_mtu = &e1000_change_mtu;
netdev->do_ioctl = &e1000_ioctl;
@@ -2409,21 +2409,22 @@ e1000_set_mac(struct net_device *netdev, void *p)
}
/**
- * e1000_set_multi - Multicast and Promiscuous mode set
+ * e1000_set_rx_mode - Secondary Unicast, Multicast and Promiscuous mode set
* @netdev: network interface device structure
*
- * The set_multi entry point is called whenever the multicast address
- * list or the network interface flags are updated. This routine is
- * responsible for configuring the hardware for proper multicast,
+ * The set_rx_mode entry point is called whenever the unicast or multicast
+ * address lists or the network interface flags are updated. This routine is
+ * responsible for configuring the hardware for proper unicast, multicast,
* promiscuous mode, and all-multi behavior.
**/
static void
-e1000_set_multi(struct net_device *netdev)
+e1000_set_rx_mode(struct net_device *netdev)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
- struct dev_mc_list *mc_ptr;
+ struct dev_addr_list *uc_ptr;
+ struct dev_addr_list *mc_ptr;
uint32_t rctl;
uint32_t hash_value;
int i, rar_entries = E1000_RAR_ENTRIES;
@@ -2446,9 +2447,16 @@ e1000_set_multi(struct net_device *netdev)
rctl |= (E1000_RCTL_UPE | E1000_RCTL_MPE);
} else if (netdev->flags & IFF_ALLMULTI) {
rctl |= E1000_RCTL_MPE;
- rctl &= ~E1000_RCTL_UPE;
} else {
- rctl &= ~(E1000_RCTL_UPE | E1000_RCTL_MPE);
+ rctl &= ~E1000_RCTL_MPE;
+ }
+
+ uc_ptr = NULL;
+ if (netdev->uc_count > rar_entries - 1) {
+ rctl |= E1000_RCTL_UPE;
+ } else if (!(netdev->flags & IFF_PROMISC)) {
+ rctl &= ~E1000_RCTL_UPE;
+ uc_ptr = netdev->uc_list;
}
E1000_WRITE_REG(hw, RCTL, rctl);
@@ -2458,7 +2466,10 @@ e1000_set_multi(struct net_device *netdev)
if (hw->mac_type == e1000_82542_rev2_0)
e1000_enter_82542_rst(adapter);
- /* load the first 14 multicast address into the exact filters 1-14
+ /* load the first 14 addresses into the exact filters 1-14. Unicast
+ * addresses take precedence to avoid disabling unicast filtering
+ * when possible.
+ *
* RAR 0 is used for the station MAC adddress
* if there are not 14 addresses, go ahead and clear the filters
* -- with 82571 controllers only 0-13 entries are filled here
@@ -2466,8 +2477,11 @@ e1000_set_multi(struct net_device *netdev)
mc_ptr = netdev->mc_list;
for (i = 1; i < rar_entries; i++) {
- if (mc_ptr) {
- e1000_rar_set(hw, mc_ptr->dmi_addr, i);
+ if (uc_ptr) {
+ e1000_rar_set(hw, uc_ptr->da_addr, i);
+ uc_ptr = uc_ptr->next;
+ } else if (mc_ptr) {
+ e1000_rar_set(hw, mc_ptr->da_addr, i);
mc_ptr = mc_ptr->next;
} else {
E1000_WRITE_REG_ARRAY(hw, RA, i << 1, 0);
@@ -2476,6 +2490,7 @@ e1000_set_multi(struct net_device *netdev)
E1000_WRITE_FLUSH(hw);
}
}
+ WARN_ON(uc_ptr != NULL);
/* clear the old settings from the multicast hash table */
@@ -2487,7 +2502,7 @@ e1000_set_multi(struct net_device *netdev)
/* load any remaining addresses into the hash table */
for (; mc_ptr; mc_ptr = mc_ptr->next) {
- hash_value = e1000_hash_mc_addr(hw, mc_ptr->dmi_addr);
+ hash_value = e1000_hash_mc_addr(hw, mc_ptr->da_addr);
e1000_mta_set(hw, hash_value);
}
@@ -5104,7 +5119,7 @@ e1000_suspend(struct pci_dev *pdev, pm_message_t state)
if (wufc) {
e1000_setup_rctl(adapter);
- e1000_set_multi(netdev);
+ e1000_set_rx_mode(netdev);
/* turn on all-multi mode if wake on multicast is enabled */
if (wufc & E1000_WUFC_MC) {
[-- Attachment #3: Type: text/plain, Size: 314 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
[-- Attachment #4: Type: text/plain, Size: 164 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
^ permalink raw reply related
* RE: [PATCH 01/01] ipv6: RFC4214 Support (v2.0)
From: Templin, Fred L @ 2007-11-13 17:29 UTC (permalink / raw)
To: Vlad Yasevich
Cc: netdev, YOSHIFUJI Hideaki / 吉藤英明
In-Reply-To: <4739D7F7.90300@hp.com>
Vlad,
> -----Original Message-----
> From: Vlad Yasevich [mailto:vladislav.yasevich@hp.com]
> Sent: Tuesday, November 13, 2007 9:00 AM
> To: Templin, Fred L
> Cc: netdev@vger.kernel.org; YOSHIFUJI Hideaki / 吉藤英明
> Subject: Re: [PATCH 01/01] ipv6: RFC4214 Support (v2.0)
>
> Hi Fred
>
> Templin, Fred L wrote:
> >>> + return;
> >>> + }
> >>> +
> >>> sit_add_v4_addrs(idev);
> >>>
> >>> if (dev->flags&IFF_POINTOPOINT) {
> >>> @@ -2531,6 +2570,18 @@ static void addrconf_rs_timer(unsigned l
> >>> * Announcement received after solicitation
> >>> * was sent
> >>> */
> >>> +
> >>> + /* ISATAP (RFC4214) - schedule next RS/RA */
> >>> + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> >>> + struct ip_tunnel *t =
> >> netdev_priv(ifp->idev->dev);
> >>> + if (t->parms.i_key != INADDR_NONE) {
> >>> + spin_lock(&ifp->lock);
> >>> + ifp->probes = 0;
> >>> + ifp->idev->if_flags &=
> >> ~(IF_RS_SENT|IF_RA_RCVD);
> >>> + addrconf_mod_timer(ifp, AC_DAD,
> >> t->parms.o_key*HZ);
> >>
> >> You are using a DAD timer to schedule RS?
> >
> > I am using the DAD timer to re-DAD the link local, which
> > in turn schedules RS.
> >
>
> Why? Seems to me that using the RS timer (AC_RS) gets you
> everything you
> want and nothing you don't. You set probes to 0, which marks
> DAD complete,
> thus you don't do DAD. You already have code in the
> addrconf_rs_timer() to
> properly send the RS. So, your patch to sending the RS is
> much shorter if
> you use the AC_RS timer.
>
> Am I missing something?
Probably not. "Re-DAD the link-local" just seemed to have a nice
ring about it, but if we don't need it we can just as well go straight
to the RS. I'll take a closer look to verify...
Thanks - Fred
fred.l.templin@boeing.com
^ permalink raw reply
* Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
From: Kok, Auke @ 2007-11-13 17:30 UTC (permalink / raw)
To: Patrick McHardy
Cc: Herbert Xu, e1000-devel, netdev, djohnson+linux-kernel,
linux-kernel, joonwpark81, David Miller, cfriesen, w
In-Reply-To: <4739DE29.2030507@trash.net>
Patrick McHardy wrote:
> Kok, Auke wrote:
>> Patrick McHardy wrote:
>>
>>> I already posted a patch for this, not sure what happened to it.
>>> Auke, any news on merging the secondary unicast address support?
>>
>> I dropped the ball on that one. Care to resend it and send me one for
>> e1000e as well?
>
> Patch for e1000 attached.
>
> Does e1000e also work with PCI cards if I add the proper IDs?
> Otherwise I could only send an untested patch.
>
no, e1000e will only work with pci-e adapters. The code however is largely the
same, so if you can dish me out (off-list) some test cases I can have our labs do
the testing and add this to our test repertoire.
Cheers,
Auke
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Alan Cox @ 2007-11-13 17:30 UTC (permalink / raw)
To: Theodore Tso
Cc: Benoit Boissinot, Mark Lord, Ingo Molnar, Andrew Morton,
David Miller, protasnb, linux-kernel, netdev, alsa-devel,
linux-ide, linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113171356.GA25824@thunk.org>
> The other an automated set of standard pre-built bisection points so
> that testers can more easily localize a bug down to a few hundred
> commits without needing to learn how to use "git bisect" (think Ubuntu
> users).
Before that you want a flowchart or instruction list of boot options to
try. A lot of errors can be localised simply by asking the reported to
boot with things like "iommu=off", "pci=routeirq", "apci=off" etc
That takes a lot less time to run through and can be very informative.
Alan
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Larry Finger @ 2007-11-13 17:33 UTC (permalink / raw)
To: Theodore Tso, Benoit Boissinot, Mark Lord, Ingo Molnar,
Andrew Morton, David Miller <da
In-Reply-To: <20071113171356.GA25824@thunk.org>
Theodore Tso wrote:
> On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote:
>> Btw, I used to test every -mm kernel. But since I've switched distros
>> (gentoo->ubuntu)
>> and I have less time, I feel it's harder to test -rc or -mm kernels (I
>> know this isn't a lkml problem
>> but more a distro problem, but I would love having an ubuntu blessed
>> repo with current dev kernel
>> for the latest stable ubuntu release).
>
> There are two parts to this. One is a Ubuntu development kernel which
> we can give to large numbers of people to expand our testing pool.
> But if we don't do a better job of responding to bug reports that
> would be generated by expanded testing this won't necessarily help us.
I'm very encouraged to read of your expanded testing efforts. As a bcm43xx developer, Ubuntu has
been our problem distro, mostly because your standard kernels have debugging turned off for bcm43xx.
When a Ubuntu user reports a problem and we ask for the relevant output from dmesg, they have no
information. I ask two things of all distros: (1) Turn on debugging - we don't spam the logs that
badly, and (2) forward any bugs found by your testing to the maintainer, and/or the bcm43xx mailing
list.
Thanks,
Larry
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Mark Lord @ 2007-11-13 17:47 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Andrew Morton, Natalie Protasevich, linux-kernel, netdev,
alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <alpine.LFD.0.9999.0711131521590.3265@localhost.localdomain>
Thomas Gleixner wrote:
> On Tue, 13 Nov 2007, Mark Lord wrote:
..
>> I *still* get very slow resume-from-RAM quite often here
>> (new in 2.6.23 kernel, wasn't there in early 2.6.23-rc*).
..
>> Something eventually times out after a minute or so
>> and it comes back. Cannot make it happen reliably,
>> unless I'm in a hurry to get something done. :)
>> I suspect USB here, probably the same loopy bug that
>> we added a "loop limit failsafe" for back in 2.6.21(?).
>
> Do you have a pointer to that please ?
..
The "limit" added in the code below,
which was for messages of this form:
hub 1-1:1.0: hub_port_status failed (err = -71)
last message repeated 347 times
drivers/usb/hub.c:
> static void hub_tt_kevent (struct work_struct *work)
> {
> struct usb_hub *hub =
> container_of(work, struct usb_hub, tt.kevent);
> unsigned long flags;
> int limit = 100;
>
> spin_lock_irqsave (&hub->tt.lock, flags);
> while (--limit && !list_empty (&hub->tt.clear_list)) {
> ...
I'm not yet sure what's happening on resume now,
but there's this huge long pause with a dark screen
and then suddenly the USB subsystem comes to life
(my mouse lights up) and the system finally resumes.
More when I know more. But it doesn't happen every time,
or even most times, so git-bisect is not possible either.
This one actually requires a developer/maintainer to put
in some effort and think about things. Currently, that's me.
-ml
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Jan Kara @ 2007-11-13 17:49 UTC (permalink / raw)
To: Andrew Morton
Cc: Natalie Protasevich, linux-kernel, netdev, alsa-devel, linux-ide,
linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113031553.3c7b5c16.akpm@linux-foundation.org>
> > FILE SYSTEMS=======================================================
> >
> > ext4: delalloc space accounting problem drops data
> > http://bugzilla.kernel.org/show_bug.cgi?id=9329
> > Kernel: 2.6.24-rc1
> No response from developers
Actually, there has been a response (Eric asked in mailing list and
created a bug and got answer to the mailing list):
http://marc.info/?l=linux-ext4&m=119454449014728&w=2
> > POSIX Access Control Lists cause bogus file system check errors
> > http://bugzilla.kernel.org/show_bug.cgi?id=9241
> > Kernel: 2.6.23.1
>
> Andreas did some work, seemed to lose interest.
As I read the bug it seems that the cause was a filesystem with errors
(which were in ACL's and thus kernel didn't boot only with ACL's
enabled) and fsck fixed the problem... I would close this one as
invalid (OK, I know the filesystem had to be corrupted somehow but
unless this is at least occasionally reproducible, there's low chance of
finding the bug).
Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs
^ permalink raw reply
* Re: [BUG] New Kernel Bugs
From: Mark Lord @ 2007-11-13 17:50 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, David Miller, protasnb, linux-kernel, netdev,
alsa-devel, linux-ide, linux-pcmcia, linux-input, bugme-daemon
In-Reply-To: <20071113164650.GA28493@elte.hu>
Ingo Molnar wrote:
>
> for example git-bisect was godsent. I remember that years ago bisection
> of a bug was a very laborous task so that it was only used as a final,
> last-ditch approach for really nasty bugs. Today we can autonomouly
> bisect build bugs via a simple shell command around "git-bisect run",
> without any human interaction! This freed up testing resources
..
It's only a godsend for the few people who happen to be kernel developers
and who happen to already use git.
It's a 540MByte download over a slow link for everyone else.
-ml
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox