* [PATCH 0/2] qla3xxx: bugfixes to link management.
From: Ron Mercer @ 2007-11-07 21:56 UTC (permalink / raw)
To: jeff; +Cc: netdev
Hi Jeff,
The attached two patches fix a couple of problems in the link management.
Built and tested on today's netdev/upstream.
Regards,
Ron Mercer
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
^ permalink raw reply
* [PATCH] PCI: export pci_restore_msi_state()
From: Linas Vepstas @ 2007-11-07 21:43 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-pci, netdev, mcarlson, wenxiong, mchan, Kok, Auke
PCI error recovery usually involves the PCI adapter being reset.
If the device is using MSI, the reset will cause the MSI state
to be lost; the device driver needs to restore the MSI state.
The pci_restore_msi_state() routine is currently protected
by CONFIG_PM; remove this, and also export the symbol, so
that it can be used in a modle.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
I am so sorry I wasn't able to send this 3 weeks ago, when
I first wrote the patch. There was simply no functional
hardware available to actually run this stuff :-(
Patches that use this, including those for tg3 and e1000e and ixgbe
i.e. MSI-using drivers, are to follow "real soon now".
drivers/pci/msi.c | 3 +--
drivers/pci/pci.h | 6 ------
include/linux/pci.h | 2 ++
3 files changed, 3 insertions(+), 8 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/pci/msi.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/msi.c 2007-10-16 15:14:20.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/msi.c 2007-10-16 15:14:42.000000000 -0500
@@ -224,7 +224,6 @@ static struct msi_desc* alloc_msi_entry(
return entry;
}
-#ifdef CONFIG_PM
static void __pci_restore_msi_state(struct pci_dev *dev)
{
int pos;
@@ -282,7 +281,7 @@ void pci_restore_msi_state(struct pci_de
__pci_restore_msi_state(dev);
__pci_restore_msix_state(dev);
}
-#endif /* CONFIG_PM */
+EXPORT_SYMBOL_GPL(pci_restore_msi_state);
/**
* msi_capability_init - configure device's MSI capability structure
Index: linux-2.6.23-rc8-mm1/drivers/pci/pci.h
===================================================================
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/pci.h 2007-10-16 15:14:20.000000000 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/pci.h 2007-10-16 15:19:33.000000000 -0500
@@ -45,12 +45,6 @@ static inline void pci_no_msi(void) { }
static inline void pci_msi_init_pci_dev(struct pci_dev *dev) { }
#endif
-#if defined(CONFIG_PCI_MSI) && defined(CONFIG_PM)
-void pci_restore_msi_state(struct pci_dev *dev);
-#else
-static inline void pci_restore_msi_state(struct pci_dev *dev) {}
-#endif
-
static inline int pci_no_d1d2(struct pci_dev *dev)
{
unsigned int parent_dstates = 0;
Index: linux-2.6.23-rc8-mm1/include/linux/pci.h
===================================================================
--- linux-2.6.23-rc8-mm1.orig/include/linux/pci.h 2007-10-01 13:26:38.000000000 -0500
+++ linux-2.6.23-rc8-mm1/include/linux/pci.h 2007-10-16 15:19:07.000000000 -0500
@@ -665,6 +665,7 @@ static inline int pci_enable_msix(struct
struct msix_entry *entries, int nvec) {return -1;}
static inline void pci_disable_msix(struct pci_dev *dev) {}
static inline void msi_remove_pci_irq_vectors(struct pci_dev *dev) {}
+static inline void pci_restore_msi_state(struct pci_dev *dev) {}
#else
extern int pci_enable_msi(struct pci_dev *dev);
extern void pci_disable_msi(struct pci_dev *dev);
@@ -672,6 +673,7 @@ extern int pci_enable_msix(struct pci_de
struct msix_entry *entries, int nvec);
extern void pci_disable_msix(struct pci_dev *dev);
extern void msi_remove_pci_irq_vectors(struct pci_dev *dev);
+extern void pci_restore_msi_state(struct pci_dev *dev);
#endif
#ifdef CONFIG_HT_IRQ
^ permalink raw reply
* Re: [PATCH] Read back MSI message in rtas_setup_msi_irqs() so restore works
From: Linas Vepstas @ 2007-11-07 21:29 UTC (permalink / raw)
To: Michael Ellerman
Cc: Paul Mackerras, linuxppc-dev, netdev, David S. Miller, mchan,
mcarlson, linux-pci, Benjamin Herrenschmidt
In-Reply-To: <5f47235ce3542c80e043f7f183400ab3d576f1dd.1193113342.git.michael@ellerman.id.au>
On Tue, Oct 23, 2007 at 02:23:44PM +1000, Michael Ellerman wrote:
> There are plans afoot to use pci_restore_msi_state() to restore MSI
> state after a device reset. In order for this to work for the RTAS MSI
> backend, we need to read back the MSI message from config space after
> it has been setup by firmware.
>
> This should be sufficient for restoring the MSI state after a device
> reset, however we will need to revisit this for suspend to disk if that
> is ever implemented on pseries.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>
> Linas, can you test this on your setup with your EEH stuff? I haven't got
> any MSI supporting hardware/firmware combination.
Acked-by: Linas Vepstas <linas@austin.ibm.com>
I *finally* was able to get onto some hardware long enough to run this.
And that took a lot of work. Sigh. Yes, this is exactly what I'd wanted.
--linas
^ permalink raw reply
* Re: 2.6.23.1-smp kernel panic (network-related)
From: Andrew Morton @ 2007-11-07 20:23 UTC (permalink / raw)
To: Marek Kierdelewicz; +Cc: linux-kernel, netdev
In-Reply-To: <20071107175211.1a12c8c9@catlap>
(cc netdev)
> On Wed, 7 Nov 2007 17:52:11 +0100 Marek Kierdelewicz <marek@koba.pl> wrote:
> Hi there,
>
> My company's (ISP) bussines model requires dynamic resizing of the
> client queues. It's achieved by regenerating shaping rules and loading
> then using batch mode of a tc binary. On production systems it's done
> once every 1 or 2 minutes. Unfortunately this causes smp kernels to
> panic. Non-smp kernels don't have such problems. Bug is around a long
> time. I first noticed it after migrating to shaping configs that use
> IFB, it might have been 2.6.18 "era".
>
> Test scenario:
>
> I've put together a test machine with configuration copied from
> production router. I'm feeding the machine with production traffic
> by means of port mirroring. Test machine has the same config as
> production one (including mac addresses), so it tries to route the
> incoming traffic.
>
> Tested kernels were 2.6.31.1 and 2.6.20.6 (config from 2.6.20.6 is in
> attachment). Both panicked if compiled with SMP support and work stable
> otherwise. Problem occurs only with cyclic "shaping restarts". For the
> test, reload operation using "tc -b ..." was executed in an infinite
> loop.
>
> Box's CPU usage was approximately 15%. Panics occur with few hours -
> one day intervals.
>
>
> Below I attach the panic message captured via serial console:
> ----------------------------------------------------------------------
> printk: 63 messages suppressed.
> dst cache overflow
> SMP
> Modules linked in: ipt_LOG xt_hashlimit ipt_MASQUERADE ip_set_macipmap
> ip_set_ipmap xt_state w83627hf hwmon_vid eeprom ifb ipt_SET ipt_set
> ip_set ipip tunnel4 ip_gre e1000 i2c_i801 i2c_core CPU: 1 EIP:
> 0060:[<f255c08f>] Not tainted VLI EFLAGS: 00010202 (2.6.23.1-smp
> #2) EIP is at 0xf255c08f
> eax: c196a000 ebx: 00000100 ecx: ef2f408c edx: f3630000
> esi: f0332029 edi: f255c08c ebp: 00000001 esp: f3631ea8
> ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
> Process tc (pid: 27695, ti=f3630000 task=f26a9560 task.ti=f3630000)
> Stack: c01280ad f26a9560 00000001 f3631eb4 c0106f57 ef2f408c f0e8c08c
> 00000031 c0495308 0000000a c0124eb6 00000046 00000000 f7657740 f3630000
> c0124f4c c180f120 c0114e62 00000000 00000000 f7bfd224 f74ed95c c01047e0
> f7bfd224 Call Trace:
> [<c01280ad>] run_timer_softirq+0xf5/0x154
> [<c0106f57>] profile_pc+0x21/0x4a
> [<c0124eb6>] __do_softirq+0x5d/0xc1
> [<c0124f4c>] do_softirq+0x32/0x36
> [<c0114e62>] smp_apic_timer_interrupt+0x74/0x80
> [<c01047e0>] apic_timer_interrupt+0x28/0x30
> [<c014c82e>] remove_vma+0x1c/0x36
> [<c014c912>] exit_mmap+0xca/0xe1
> [<c011eedc>] mmput+0x1d/0x75
> [<c0123688>] do_exit+0x1be/0x68a
> [<c0123bc0>] sys_exit_group+0x0/0xd
> [<c0103d12>] sysenter_past_esp+0x5f/0x85
> =======================
> Code: 00 52 41 f7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 fa 00 00 00 ea 05 00 00 7f 00 00 00 34 a5 96 <c1> 8c
> 00 fd f3 a5 2b 09 00 d1 d8 32 c0 00 c0 55 f2 00 a0 96 c1 EIP:
> [<f255c08f>] 0xf255c08f SS:ESP 0068:f3631ea8 Kernel panic - not
> syncing: Fatal exception in interrupt
> ----------------------------------------------------------------------
>
>
> --
> Marek Kierdelewicz
> Kierownik Działu Systemów Sieciowych, KoBa
> Manager of Network Systems Department, KoBa
> tel. (85) 7406466; fax. (85) 7406467
> e-mail: admin@koba.pl
>
^ permalink raw reply
* Re: Why does a connect to IPv6 LLA address fail ?
From: Vlad Yasevich @ 2007-11-07 19:42 UTC (permalink / raw)
To: Jiri Bohac; +Cc: netdev, yoshfuji, kkeil
In-Reply-To: <20071107112838.GA22180@dhcp79.suse.cz>
Jiri Bohac wrote:
> Hi,
>
>> For this it create a socket for datagram and
>> protocol IPPROTO_IP and then try to connect it with the destination
>> address. This fails in the case of a LLA, because connect returns EINVAL,
>> since here is no device bind to this socket at this time.
>
> [snip]
>
>> Why do we have this check in ip6_datagram_connect() ?
>
> This problem has been nicely described in
> http://www.linux-ipv6.org/ml/usagi-users/msg03062.html
> without any response.
>
> RFC2461, Appendix A, really suggests performing neighbour
> discovery on all the links. I like the idea, it would make LLAs
> much more useful.
The reason this is in an Appendix is because it doesn't work all
the time. It was there to document some experiments that were going
on.
>
> Has anyone experimented with this? Is there any good reason why
> we don't send NSs to all the links to find out which link the
> destination LLA is on?
The reason is that 2 different hosts may have the same link-local
address as long as they are on different links. If the sender is
connected to both links then it may send the packet to the wrong
destination.
Link local addresses are unqualified without the scope/zone id.
The application must pass this information to the kernel as part of
the connect() call.
A different and some might say 'better' alternative is to define a
default link. Thus when the zone id is not specified the default is used.
This will work fine for link-scoped addresses. A default zone would also
need to be defined for other scopes as well. That's just one idea.
-vlad
^ permalink raw reply
* Re: [PATCH 02/05] ipv6: RFC4214 Support
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-11-07 19:47 UTC (permalink / raw)
To: Fred.L.Templin; +Cc: netdev, netdev, yoshfuji
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDBF4@XCH-NW-7V2.nw.nos.boeing.com>
In article <39C363776A4E8C4A94691D2BD9D1C9A1029EDBF4@XCH-NW-7V2.nw.nos.boeing.com> (at Wed, 7 Nov 2007 10:52:47 -0800), "Templin, Fred L" <Fred.L.Templin@boeing.com> says:
> > > > > > + if (((ipv4 >= 0x01000000) && (ipv4 < 0x0a000000)) ||
> > > > > > + ((ipv4 >= 0x0b000000) && (ipv4 < 0x7f000000)) ||
> > > > > > + ((ipv4 >= 0x80000000) && (ipv4 < 0xa9fe0000)) ||
> > > > > > + ((ipv4 >= 0xa9ff0000) && (ipv4 < 0xac100000)) ||
> > > > > > + ((ipv4 >= 0xac200000) && (ipv4 < 0xc0a80000)) ||
> > > > > > + ((ipv4 >= 0xc0a90000) && (ipv4 < 0xc6120000)) ||
> > > > > > + ((ipv4 >= 0xc6140000) && (ipv4 <
> > 0xe0000000))) eui[0] |=
> > > > > > 0x2;
> Maybe it is I who did not understand. Can you suggest a clean solution?
You could write each element as LOOPBACK(), MULTICAST()
etc.
eui[0] = (!ZERONETO(a) &&
!PRIVATE_10(a) &&
!LINKLOCAL(a) &&
!PRIVATE_172(a) &&
!PRIVATE_192(a) &&
!NETICDEVBENCH(a) &&
!MULTICAST(a)) ? 2 : 0;
--yoshfuji
^ permalink raw reply
* Re: [PATCH 02/05] ipv6: RFC4214 Support
From: Simon Arlott @ 2007-11-07 19:38 UTC (permalink / raw)
To: Templin, Fred L
Cc: YOSHIFUJI Hideaki / 吉藤英明, netdev,
netdev
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDBF9@XCH-NW-7V2.nw.nos.boeing.com>
On 07/11/07 19:32, Templin, Fred L wrote:
>
>
>> -----Original Message-----
>> From: Simon Arlott [mailto:simon@fire.lp0.eu]
>> Sent: Wednesday, November 07, 2007 11:02 AM
>> To: Templin, Fred L
>> Cc: YOSHIFUJI Hideaki / 吉藤英明; netdev@axxeo.de; netdev@vger.kernel.org
>> Subject: Re: [PATCH 02/05] ipv6: RFC4214 Support
>>
>> On 07/11/07 18:52, Templin, Fred L wrote:
>> >> > > > > + eui[0] = 0;
>> >> > > > > +
>> >> > > > > + /* Check for RFC3330 global address ranges */
>> >> > > > > + if (((ipv4 >= 0x01000000) && (ipv4 < 0x0a000000)) ||
>> >> > > > > + ((ipv4 >= 0x0b000000) && (ipv4 < 0x7f000000)) ||
>> >> > > > > + ((ipv4 >= 0x80000000) && (ipv4 < 0xa9fe0000)) ||
>> >> > > > > + ((ipv4 >= 0xa9ff0000) && (ipv4 < 0xac100000)) ||
>> >> > > > > + ((ipv4 >= 0xac200000) && (ipv4 < 0xc0a80000)) ||
>> >> > > > > + ((ipv4 >= 0xc0a90000) && (ipv4 < 0xc6120000)) ||
>> >> > > > > + ((ipv4 >= 0xc6140000) && (ipv4 <
>> >> 0xe0000000))) eui[0] |=
>> >> > > > > 0x2;
>> >> I don't understand.
>> >>
>> >> For example, 1.0.0.11 is valid IPv4 global address.
>> >> In little-endian, this is not in the range of
>> >> 0x00000001 <= addr <= 0x0000000a (addr is 0x0b000001).
>> >
>> > Maybe it is I who did not understand. Can you suggest a
>> clean solution?
>>
>> ((ipv4 & htonl(0xFF000000)) == htonl(0x0A000000)) etc.?
>
> I'm not sure this works when we consider disjoint ranges
> of globally-unique IP prefixes. Do you have a vision for
> how the entire conditional would look like?
You need to match RFC3330 addresses, not anything that isn't.
((ipv4 & htonl(0xFF000000)) == htonl(0x0A000000))
|| ((ipv4 & htonl(0xFFFF0000)) == htonl(0xC0A80000))
|| ((ipv4 & htonl(0xFF000000)) == htonl(0x80000000))
etc.
--
Simon Arlott
^ permalink raw reply
* RE: [PATCH 02/05] ipv6: RFC4214 Support
From: Templin, Fred L @ 2007-11-07 19:32 UTC (permalink / raw)
To: Simon Arlott
Cc: YOSHIFUJI Hideaki / 吉藤英明, netdev,
netdev
In-Reply-To: <47320B9B.6050301@simon.arlott.org.uk>
> -----Original Message-----
> From: Simon Arlott [mailto:simon@fire.lp0.eu]
> Sent: Wednesday, November 07, 2007 11:02 AM
> To: Templin, Fred L
> Cc: YOSHIFUJI Hideaki / 吉藤英明; netdev@axxeo.de; netdev@vger.kernel.org
> Subject: Re: [PATCH 02/05] ipv6: RFC4214 Support
>
> On 07/11/07 18:52, Templin, Fred L wrote:
> >> > > > > + eui[0] = 0;
> >> > > > > +
> >> > > > > + /* Check for RFC3330 global address ranges */
> >> > > > > + if (((ipv4 >= 0x01000000) && (ipv4 < 0x0a000000)) ||
> >> > > > > + ((ipv4 >= 0x0b000000) && (ipv4 < 0x7f000000)) ||
> >> > > > > + ((ipv4 >= 0x80000000) && (ipv4 < 0xa9fe0000)) ||
> >> > > > > + ((ipv4 >= 0xa9ff0000) && (ipv4 < 0xac100000)) ||
> >> > > > > + ((ipv4 >= 0xac200000) && (ipv4 < 0xc0a80000)) ||
> >> > > > > + ((ipv4 >= 0xc0a90000) && (ipv4 < 0xc6120000)) ||
> >> > > > > + ((ipv4 >= 0xc6140000) && (ipv4 <
> >> 0xe0000000))) eui[0] |=
> >> > > > > 0x2;
> >> I don't understand.
> >>
> >> For example, 1.0.0.11 is valid IPv4 global address.
> >> In little-endian, this is not in the range of
> >> 0x00000001 <= addr <= 0x0000000a (addr is 0x0b000001).
> >
> > Maybe it is I who did not understand. Can you suggest a
> clean solution?
>
> ((ipv4 & htonl(0xFF000000)) == htonl(0x0A000000)) etc.?
I'm not sure this works when we consider disjoint ranges
of globally-unique IP prefixes. Do you have a vision for
how the entire conditional would look like?
Thanks - Fred
fred.l.templin@boeing.com
> Simon Arlott
^ permalink raw reply
* Re: Please pull 'fixes-jgarzik' branch of wireless-2.6
From: Jeff Garzik @ 2007-11-07 19:24 UTC (permalink / raw)
To: John W. Linville
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071107191329.GC30169-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Wed, Nov 07, 2007 at 02:13:29PM -0500, John W. Linville wrote:
> Jeff,
>
> If you haven't already pulled this then please hold-off. I'll post
> a new request soon.
Haven't pulled yet...
Jeff
^ permalink raw reply
* [PATCH 1/1] [INET]: Remove leftover prototypes from include/net/inet_common.h
From: Arnaldo Carvalho de Melo @ 2007-11-07 19:20 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
include/net/inet_common.h | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/include/net/inet_common.h b/include/net/inet_common.h
index 227adcb..38d5a1e 100644
--- a/include/net/inet_common.h
+++ b/include/net/inet_common.h
@@ -13,9 +13,6 @@ struct sock;
struct sockaddr;
struct socket;
-extern void inet_remove_sock(struct sock *sk1);
-extern void inet_put_sock(unsigned short num,
- struct sock *sk);
extern int inet_release(struct socket *sock);
extern int inet_stream_connect(struct socket *sock,
struct sockaddr * uaddr,
@@ -30,7 +27,6 @@ extern int inet_sendmsg(struct kiocb *iocb,
struct msghdr *msg,
size_t size);
extern int inet_shutdown(struct socket *sock, int how);
-extern unsigned int inet_poll(struct file * file, struct socket *sock, struct poll_table_struct *wait);
extern int inet_listen(struct socket *sock, int backlog);
extern void inet_sock_destruct(struct sock *sk);
--
1.5.3.4
^ permalink raw reply related
* RE: [PATCH 04/05] ipv6: RFC4214 Support
From: Templin, Fred L @ 2007-11-07 19:12 UTC (permalink / raw)
To: Stephen Hemminger
Cc: YOSHIFUJI Hideaki / 吉藤英明, netdev
In-Reply-To: <20071107104524.2bd738cb@freepuppy.rosehill>
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@linux-foundation.org]
> Sent: Wednesday, November 07, 2007 10:45 AM
> To: Templin, Fred L
> Cc: YOSHIFUJI Hideaki / 吉藤英明; netdev@vger.kernel.org
> Subject: Re: [PATCH 04/05] ipv6: RFC4214 Support
>
> On Wed, 7 Nov 2007 10:41:49 -0800
> "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
>
> > Yoshifuji,
> >
> > > -----Original Message-----
> > > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:yoshfuji@linux-ipv6.org]
> > > Sent: Wednesday, November 07, 2007 10:37 AM
> > > To: Templin, Fred L
> > > Cc: netdev@vger.kernel.org; yoshfuji@linux-ipv6.org
> > > Subject: Re: [PATCH 04/05] ipv6: RFC4214 Support
> > >
> > > Hello.
> > >
> > > In article
> > > <39C363776A4E8C4A94691D2BD9D1C9A1029EDBE5@XCH-NW-7V2.nw.nos.bo
> > > eing.com> (at Tue, 6 Nov 2007 17:16:11 -0800), "Templin, Fred
> > > L" <Fred.L.Templin@boeing.com> says:
> > >
> > > > @@ -154,6 +155,14 @@ static struct ip_tunnel * ipip6_tunnel_l
> > > > struct net_device *dev;
> > > > char name[IFNAMSIZ];
> > > >
> > > > +#if defined(CONFIG_IPV6_ISATAP)
> > > > + /* ISATAP (RFC4214) - router address in daddr */
> > > > + if (!strncmp(parms->name, "isatap", 6)) {
> > > > + parms->i_key = parms->iph.daddr;
> > > > + parms->iph.daddr = remote = 0;
> > > > + }
> > > > +#endif
> > > > +
> > > > for (tp = __ipip6_bucket(parms); (t = *tp) != NULL; tp =
> > > > &t->next) {
> > > > if (local == t->parms.iph.saddr && remote ==
> > > > t->parms.iph.daddr)
> > > > return t;
> > >
> > > I do not think it is a good idea to change the behavior based on
> > > the interface name.
> >
> > The goal was to avoid requiring changes to applications such as
> > 'iproute2', i.e., the intention was for a standalone code
> insertion point
> > within the kernel itself. What do you suggest?
>
> Agreed, magic names are evil.
>
> Change iproute2 utilities, if it is more logical for administration.
This being an experimental release, I would prefer to go
forward with a standalone kernel solution for the first
iteration then come back with the iproute2 changes at a
later time. IMHO, we should only touch iproute2 once, and
it should be an architected solution - not just a quick
hack. For the short term, timeliness of interoperability testing
with the other major OS's should be the highest priority, IMHO.
Other opinions?
Fred
fred.l.templin@boeing.com
^ permalink raw reply
* Re: Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2007-11-07 19:13 UTC (permalink / raw)
To: jeff-o2qLIJkoznsdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071106200700.GF4440-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Jeff,
If you haven't already pulled this then please hold-off. I'll post
a new request soon.
Thanks,
John
On Tue, Nov 06, 2007 at 03:07:00PM -0500, John W. Linville wrote:
> Jeff,
>
> Here are a few fixes for 2.6.24. The iwlwifi "is_power_of_2" patch is
> a little questionable as a fix. But it does bring the buildtime check
> in iwl_tx_queue_init in-line with the runtime check in iwl_queue_init,
> and it is 2x a one-liner -- so I think it is worthwhile.
>
> Thanks,
>
> John
>
> ---
>
> Individual patches available here:
>
> http://www.kernel.org/pub//linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
>
> ---
>
> The following changes since commit 2655e2cee2d77459fcb7e10228259e4ee0328697:
> Alan Cox (1):
> ata_piix: Add additional PCI identifier for 40 wire short cable
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
>
> Holger Schurig (1):
> libertas: fixes for slow hardware
>
> Ivo van Doorn (1):
> rt2x00: Block adhoc & master mode
>
> John W. Linville (1):
> hermes: clarify Intel reference in Kconfig help
>
> Marcelo Tosatti (1):
> libertas: properly account for queue commands
>
> Michael Buesch (1):
> b43: pcmcia-host initialization bugfixes
>
> Pierre Ossman (1):
> libertas: make if_sdio align packets
>
> Randy Dunlap (1):
> hostap: fix section mismatch warning
>
> Robert P. J. Day (1):
> iwlwifi: Use more obvious "is_power_of_2" macro.
>
> Roel Kluin (1):
> ipw2100: fix postfix decrement errors
>
> drivers/net/wireless/Kconfig | 2 +-
> drivers/net/wireless/b43/pcmcia.c | 44 +++++++++++++++-----------
> drivers/net/wireless/hostap/hostap_pci.c | 6 ++--
> drivers/net/wireless/ipw2100.c | 4 +-
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 3 +-
> drivers/net/wireless/iwlwifi/iwl4965-base.c | 3 +-
> drivers/net/wireless/libertas/cmd.c | 10 ++++--
> drivers/net/wireless/libertas/if_cs.c | 7 +++-
> drivers/net/wireless/libertas/if_sdio.c | 4 ++-
> drivers/net/wireless/rt2x00/rt2x00mac.c | 8 +++++
> 10 files changed, 58 insertions(+), 33 deletions(-)
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* Re: [PATCH 02/05] ipv6: RFC4214 Support
From: Simon Arlott @ 2007-11-07 19:01 UTC (permalink / raw)
To: Templin, Fred L
Cc: YOSHIFUJI Hideaki / 吉藤英明, netdev,
netdev
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDBF4@XCH-NW-7V2.nw.nos.boeing.com>
On 07/11/07 18:52, Templin, Fred L wrote:
>> > > > > + eui[0] = 0;
>> > > > > +
>> > > > > + /* Check for RFC3330 global address ranges */
>> > > > > + if (((ipv4 >= 0x01000000) && (ipv4 < 0x0a000000)) ||
>> > > > > + ((ipv4 >= 0x0b000000) && (ipv4 < 0x7f000000)) ||
>> > > > > + ((ipv4 >= 0x80000000) && (ipv4 < 0xa9fe0000)) ||
>> > > > > + ((ipv4 >= 0xa9ff0000) && (ipv4 < 0xac100000)) ||
>> > > > > + ((ipv4 >= 0xac200000) && (ipv4 < 0xc0a80000)) ||
>> > > > > + ((ipv4 >= 0xc0a90000) && (ipv4 < 0xc6120000)) ||
>> > > > > + ((ipv4 >= 0xc6140000) && (ipv4 <
>> 0xe0000000))) eui[0] |=
>> > > > > 0x2;
>> I don't understand.
>>
>> For example, 1.0.0.11 is valid IPv4 global address.
>> In little-endian, this is not in the range of
>> 0x00000001 <= addr <= 0x0000000a (addr is 0x0b000001).
>
> Maybe it is I who did not understand. Can you suggest a clean solution?
((ipv4 & htonl(0xFF000000)) == htonl(0x0A000000)) etc.?
--
Simon Arlott
^ permalink raw reply
* RE: [PATCH 02/05] ipv6: RFC4214 Support
From: Templin, Fred L @ 2007-11-07 18:52 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev, netdev
In-Reply-To: <20071108.034840.124896893.yoshfuji@linux-ipv6.org>
> -----Original Message-----
> From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:yoshfuji@linux-ipv6.org]
> Sent: Wednesday, November 07, 2007 10:49 AM
> To: Templin, Fred L
> Cc: netdev@axxeo.de; netdev@vger.kernel.org; yoshfuji@linux-ipv6.org
> Subject: Re: [PATCH 02/05] ipv6: RFC4214 Support
>
> In article
> <39C363776A4E8C4A94691D2BD9D1C9A1029EDBF2@XCH-NW-7V2.nw.nos.bo
> eing.com> (at Wed, 7 Nov 2007 10:24:50 -0800), "Templin, Fred
> L" <Fred.L.Templin@boeing.com> says:
>
> >
> >
> > > -----Original Message-----
> > > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:yoshfuji@linux-ipv6.org]
> > > Sent: Wednesday, November 07, 2007 10:12 AM
> > > To: netdev@axxeo.de
> > > Cc: Templin, Fred L; netdev@vger.kernel.org;
> yoshfuji@linux-ipv6.org
> > > Subject: Re: [PATCH 02/05] ipv6: RFC4214 Support
> > >
> > > Hello.
> > >
> > > In article <200711071658.59478.netdev@axxeo.de> (at Wed, 7
> > > Nov 2007 16:58:59 +0100), Ingo Oeser <netdev@axxeo.de> says:
> > >
> > > > > + eui[0] = 0;
> > > > > +
> > > > > + /* Check for RFC3330 global address ranges */
> > > > > + if (((ipv4 >= 0x01000000) && (ipv4 < 0x0a000000)) ||
> > > > > + ((ipv4 >= 0x0b000000) && (ipv4 < 0x7f000000)) ||
> > > > > + ((ipv4 >= 0x80000000) && (ipv4 < 0xa9fe0000)) ||
> > > > > + ((ipv4 >= 0xa9ff0000) && (ipv4 < 0xac100000)) ||
> > > > > + ((ipv4 >= 0xac200000) && (ipv4 < 0xc0a80000)) ||
> > > > > + ((ipv4 >= 0xc0a90000) && (ipv4 < 0xc6120000)) ||
> > > > > + ((ipv4 >= 0xc6140000) && (ipv4 <
> 0xe0000000))) eui[0] |=
> > > > > 0x2;
> > > > > +
> > > >
> > > > Instead of converting network to host byte order at runtime
> > > > and comparing the results to constants, let the compiler convert
> > > > the constants to network byte order and compare in
> network order.
> > > >
> > > > so use:
> > > >
> > > > if (((*addr >= htonl(0x01000000)) && (*addr <
> > > htonl(0x0a000000))) || ....
> > > >
> > > > instead. The compiler will notice that "0x01000000" is a
> > > constant and will
> > > > use "_constant_htonl()" automatically.
> > >
> > > No, you cannot do this.
> > > When you check the "range", you need to use host-byte order.
> >
> > I think the original poster was correct on this one; the addr comes
> > in in network byte order, and the constants are depicted in host
> > byte order. So, the suggested fix was to have htonl(const) to make
> > all of the constants into network byte order while leaving addr
> > alone.
>
> I don't understand.
>
> For example, 1.0.0.11 is valid IPv4 global address.
> In little-endian, this is not in the range of
> 0x00000001 <= addr <= 0x0000000a (addr is 0x0b000001).
Maybe it is I who did not understand. Can you suggest a clean solution?
Fred
fred.l.templin@boeing.com
^ permalink raw reply
* Re: Please pull 'fixes-davem' branch of wireless-2.6
From: John W. Linville @ 2007-11-07 18:51 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071107001314.GH4440-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Dave,
Hold-off on this one for now if -- clearly Johannes and I need to
brush-up on our Kconfig skills... :-(
I'll post a new pull request soon.
Thanks,
John
On Tue, Nov 06, 2007 at 07:13:14PM -0500, John W. Linville wrote:
> Dave,
>
> Here are some fixes for 2.6.24...
>
> The iwlwifi patch is needed because the iwlwifi drivers routinely end-up
> associated with the "simple" rate control algorithm, yet those drivers
> really only work with their own custom algorithms. The other rate
> control patches are there to satisfy dependencies for this patch.
>
> "mac80211: remove ieee80211_common.h" cleans-up an unused file left
> hanging-around after an earlier patch already in 2.6.24.
>
> "mac80211: remove unused driver ops" is really a clean-up, but
> "mac80211: use IW_AUTH_PRIVACY_INVOKED rather than IW_AUTH_KEY_MGMT"
> depends on it.
>
> "ssb: Fix initcall ordering" changes a subsys_initcall to an
> fs_initcall. This seems like a bit of a hack, but it fixes a real
> problem and I'm not sure what cleaner solution is either reasonable
> or available. The comment in the patch explains the reasoning for this
> somewhat unique situation.
>
> I think the other patches are plain enough to not require further
> comment. Let me know if there are any problems!
>
> Thanks,
>
> John
>
> ---
>
> Individual patches are available here:
>
> http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-davem/
>
> ---
>
> The following changes since commit 2655e2cee2d77459fcb7e10228259e4ee0328697:
> Alan Cox (1):
> ata_piix: Add additional PCI identifier for 40 wire short cable
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-davem
>
> Johannes Berg (9):
> softmac: fix wext MLME request reason code endianness
> mac80211: make simple rate control algorithm built-in
> mac80211: don't allow registering the same rate control twice
> mac80211: allow driver to ask for a rate control algorithm
> iwlwifi: select proper rate control algorithm
> softmac: MAINTAINERS update
> mac80211: remove ieee80211_common.h
> mac80211: remove unused driver ops
> mac80211: use IW_AUTH_PRIVACY_INVOKED rather than IW_AUTH_KEY_MGMT
>
> John W. Linville (1):
> mac80211: make "decrypt failed" messages conditional upon MAC80211_DEBUG
>
> Michael Buesch (5):
> ssb: Fix initcall ordering
> rfkill: Register LED triggers before registering switch
> rfkill: Use subsys_initcall
> rfkill: Use mutex_lock() at register and add sanity check
> rfkill: Fix sparse warning
>
> MAINTAINERS | 7 +--
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +
> drivers/net/wireless/iwlwifi/iwl4965-base.c | 2 +
> drivers/ssb/main.c | 5 +-
> include/net/mac80211.h | 26 ++------
> net/ieee80211/softmac/ieee80211softmac_wx.c | 2 +-
> net/mac80211/Kconfig | 12 ++++
> net/mac80211/Makefile | 3 +-
> net/mac80211/ieee80211.c | 16 +++++-
> net/mac80211/ieee80211_common.h | 91 ---------------------------
> net/mac80211/ieee80211_i.h | 2 +-
> net/mac80211/ieee80211_ioctl.c | 21 +++----
> net/mac80211/ieee80211_rate.c | 24 ++++++-
> net/mac80211/ieee80211_rate.h | 3 +
> net/mac80211/ieee80211_sta.c | 18 +++--
> net/mac80211/rc80211_simple.c | 25 +-------
> net/mac80211/rx.c | 2 +
> net/mac80211/wep.c | 2 +
> net/mac80211/wpa.c | 18 ++++--
> net/rfkill/rfkill.c | 37 ++++++-----
> 20 files changed, 126 insertions(+), 192 deletions(-)
> delete mode 100644 net/mac80211/ieee80211_common.h
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* Re: [PATCH 02/05] ipv6: RFC4214 Support
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-11-07 18:48 UTC (permalink / raw)
To: Fred.L.Templin; +Cc: netdev, netdev, yoshfuji
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDBF2@XCH-NW-7V2.nw.nos.boeing.com>
In article <39C363776A4E8C4A94691D2BD9D1C9A1029EDBF2@XCH-NW-7V2.nw.nos.boeing.com> (at Wed, 7 Nov 2007 10:24:50 -0800), "Templin, Fred L" <Fred.L.Templin@boeing.com> says:
>
>
> > -----Original Message-----
> > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:yoshfuji@linux-ipv6.org]
> > Sent: Wednesday, November 07, 2007 10:12 AM
> > To: netdev@axxeo.de
> > Cc: Templin, Fred L; netdev@vger.kernel.org; yoshfuji@linux-ipv6.org
> > Subject: Re: [PATCH 02/05] ipv6: RFC4214 Support
> >
> > Hello.
> >
> > In article <200711071658.59478.netdev@axxeo.de> (at Wed, 7
> > Nov 2007 16:58:59 +0100), Ingo Oeser <netdev@axxeo.de> says:
> >
> > > > + eui[0] = 0;
> > > > +
> > > > + /* Check for RFC3330 global address ranges */
> > > > + if (((ipv4 >= 0x01000000) && (ipv4 < 0x0a000000)) ||
> > > > + ((ipv4 >= 0x0b000000) && (ipv4 < 0x7f000000)) ||
> > > > + ((ipv4 >= 0x80000000) && (ipv4 < 0xa9fe0000)) ||
> > > > + ((ipv4 >= 0xa9ff0000) && (ipv4 < 0xac100000)) ||
> > > > + ((ipv4 >= 0xac200000) && (ipv4 < 0xc0a80000)) ||
> > > > + ((ipv4 >= 0xc0a90000) && (ipv4 < 0xc6120000)) ||
> > > > + ((ipv4 >= 0xc6140000) && (ipv4 < 0xe0000000))) eui[0] |=
> > > > 0x2;
> > > > +
> > >
> > > Instead of converting network to host byte order at runtime
> > > and comparing the results to constants, let the compiler convert
> > > the constants to network byte order and compare in network order.
> > >
> > > so use:
> > >
> > > if (((*addr >= htonl(0x01000000)) && (*addr <
> > htonl(0x0a000000))) || ....
> > >
> > > instead. The compiler will notice that "0x01000000" is a
> > constant and will
> > > use "_constant_htonl()" automatically.
> >
> > No, you cannot do this.
> > When you check the "range", you need to use host-byte order.
>
> I think the original poster was correct on this one; the addr comes
> in in network byte order, and the constants are depicted in host
> byte order. So, the suggested fix was to have htonl(const) to make
> all of the constants into network byte order while leaving addr
> alone.
I don't understand.
For example, 1.0.0.11 is valid IPv4 global address.
In little-endian, this is not in the range of
0x00000001 <= addr <= 0x0000000a (addr is 0x0b000001).
--yoshfuji
^ permalink raw reply
* Re: 2.6.23.1-smp kernel panic (network-related)
From: Stephen Hemminger @ 2007-11-07 18:47 UTC (permalink / raw)
To: Marek Kierdelewicz; +Cc: netdev
In-Reply-To: <20071107193843.1f3fa2f4@catlap>
On Wed, 7 Nov 2007 19:38:43 +0100
Marek Kierdelewicz <marek@koba.pl> wrote:
> >What is the test input that causes the crash??
>
> Test box is treated with mirrored traffic that is routed by production
> linux router (with non-smp kernel). It's usual traffic generated by
> broadband clients. Some of the characteristics:
>
> bandwidth used: ~40/40 Mbit (up/down)
> pps: ~15k
>
> number of clients: ~550
>
> dump of packet sizes:
> Packet size | Count
> 1 to 75: 186501
> 76 to 150: 14145
> 151 to 225: 3285
> 226 to 300: 2088
> 301 to 375: 3632
> 376 to 450: 2097
> 451 to 525: 1513
> 526 to 600: 3069
> 601 to 675: 20081
> 676 to 750: 1294
> 751 to 825: 1189
> 826 to 900: 885
> 901 to 975: 2207
> 976 to 1050: 1333
> 1051 to 1125: 1192
> 1201 to 1275: 3036
> 1276 to 1350: 3709
> 1351 to 1425: 3453
> 1426 to 1500+: 185318
>
> protocol breakdown:
> most of the traffic is IPv4, some UDP and a little bit of ICMP
>
> Don't know if it's important, but box is connected to switch by a
> 802.1q trunk. Each of vlan interfaces has egress shaping on it +
> dedicated ifb device attached to ingress qdisc and ingress shaping on
> ifb device.
>
> Is any additional information needed?
Could you get 'ethtool -S' output after it hangs.
I think there is a problem with fifo overflow. I can cause board
to latch if enough traffic arrives on both ports.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: 2.6.23.1-smp kernel panic (network-related)
From: Marek Kierdelewicz @ 2007-11-07 18:38 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20071107095120.237366d2@freepuppy.rosehill>
>What is the test input that causes the crash??
Test box is treated with mirrored traffic that is routed by production
linux router (with non-smp kernel). It's usual traffic generated by
broadband clients. Some of the characteristics:
bandwidth used: ~40/40 Mbit (up/down)
pps: ~15k
number of clients: ~550
dump of packet sizes:
Packet size | Count
1 to 75: 186501
76 to 150: 14145
151 to 225: 3285
226 to 300: 2088
301 to 375: 3632
376 to 450: 2097
451 to 525: 1513
526 to 600: 3069
601 to 675: 20081
676 to 750: 1294
751 to 825: 1189
826 to 900: 885
901 to 975: 2207
976 to 1050: 1333
1051 to 1125: 1192
1201 to 1275: 3036
1276 to 1350: 3709
1351 to 1425: 3453
1426 to 1500+: 185318
protocol breakdown:
most of the traffic is IPv4, some UDP and a little bit of ICMP
Don't know if it's important, but box is connected to switch by a
802.1q trunk. Each of vlan interfaces has egress shaping on it +
dedicated ifb device attached to ingress qdisc and ingress shaping on
ifb device.
Is any additional information needed?
--
Marek Kierdelewicz
Kierownik Działu Systemów Sieciowych, KoBa
Manager of Network Systems Department, KoBa
tel. (85) 7406466; fax. (85) 7406467
e-mail: admin@koba.pl
^ permalink raw reply
* Re: [PATCH 04/05] ipv6: RFC4214 Support
From: Stephen Hemminger @ 2007-11-07 18:45 UTC (permalink / raw)
To: Templin, Fred L
Cc: YOSHIFUJI Hideaki / 吉藤英明, netdev
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDBF3@XCH-NW-7V2.nw.nos.boeing.com>
On Wed, 7 Nov 2007 10:41:49 -0800
"Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
> Yoshifuji,
>
> > -----Original Message-----
> > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:yoshfuji@linux-ipv6.org]
> > Sent: Wednesday, November 07, 2007 10:37 AM
> > To: Templin, Fred L
> > Cc: netdev@vger.kernel.org; yoshfuji@linux-ipv6.org
> > Subject: Re: [PATCH 04/05] ipv6: RFC4214 Support
> >
> > Hello.
> >
> > In article
> > <39C363776A4E8C4A94691D2BD9D1C9A1029EDBE5@XCH-NW-7V2.nw.nos.bo
> > eing.com> (at Tue, 6 Nov 2007 17:16:11 -0800), "Templin, Fred
> > L" <Fred.L.Templin@boeing.com> says:
> >
> > > @@ -154,6 +155,14 @@ static struct ip_tunnel * ipip6_tunnel_l
> > > struct net_device *dev;
> > > char name[IFNAMSIZ];
> > >
> > > +#if defined(CONFIG_IPV6_ISATAP)
> > > + /* ISATAP (RFC4214) - router address in daddr */
> > > + if (!strncmp(parms->name, "isatap", 6)) {
> > > + parms->i_key = parms->iph.daddr;
> > > + parms->iph.daddr = remote = 0;
> > > + }
> > > +#endif
> > > +
> > > for (tp = __ipip6_bucket(parms); (t = *tp) != NULL; tp =
> > > &t->next) {
> > > if (local == t->parms.iph.saddr && remote ==
> > > t->parms.iph.daddr)
> > > return t;
> >
> > I do not think it is a good idea to change the behavior based on
> > the interface name.
>
> The goal was to avoid requiring changes to applications such as
> 'iproute2', i.e., the intention was for a standalone code insertion point
> within the kernel itself. What do you suggest?
Agreed, magic names are evil.
Change iproute2 utilities, if it is more logical for administration.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* RE: [PATCH 04/05] ipv6: RFC4214 Support
From: Templin, Fred L @ 2007-11-07 18:41 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev
In-Reply-To: <20071108.033650.113099372.yoshfuji@linux-ipv6.org>
Yoshifuji,
> -----Original Message-----
> From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:yoshfuji@linux-ipv6.org]
> Sent: Wednesday, November 07, 2007 10:37 AM
> To: Templin, Fred L
> Cc: netdev@vger.kernel.org; yoshfuji@linux-ipv6.org
> Subject: Re: [PATCH 04/05] ipv6: RFC4214 Support
>
> Hello.
>
> In article
> <39C363776A4E8C4A94691D2BD9D1C9A1029EDBE5@XCH-NW-7V2.nw.nos.bo
> eing.com> (at Tue, 6 Nov 2007 17:16:11 -0800), "Templin, Fred
> L" <Fred.L.Templin@boeing.com> says:
>
> > @@ -154,6 +155,14 @@ static struct ip_tunnel * ipip6_tunnel_l
> > struct net_device *dev;
> > char name[IFNAMSIZ];
> >
> > +#if defined(CONFIG_IPV6_ISATAP)
> > + /* ISATAP (RFC4214) - router address in daddr */
> > + if (!strncmp(parms->name, "isatap", 6)) {
> > + parms->i_key = parms->iph.daddr;
> > + parms->iph.daddr = remote = 0;
> > + }
> > +#endif
> > +
> > for (tp = __ipip6_bucket(parms); (t = *tp) != NULL; tp =
> > &t->next) {
> > if (local == t->parms.iph.saddr && remote ==
> > t->parms.iph.daddr)
> > return t;
>
> I do not think it is a good idea to change the behavior based on
> the interface name.
The goal was to avoid requiring changes to applications such as
'iproute2', i.e., the intention was for a standalone code insertion point
within the kernel itself. What do you suggest?
> > @@ -182,6 +191,11 @@ static struct ip_tunnel * ipip6_tunnel_l
> > dev->init = ipip6_tunnel_init;
> > nt->parms = *parms;
> >
> > +#if defined(CONFIG_IPV6_ISATAP)
> > + if (!strncmp(dev->name, "isatap", 6))
> > + dev->priv_flags |= IFF_ISATAP;
> > +#endif
> > +
>
> ditto.
Same as above, but note that the name check is confined to these
two places.
>
> > + if (!(ipv6_addr_is_isatap(addr6)) ||
> > + (addr6->s6_addr32[3] != iph->saddr)) {
> > +drop:
> > + tunnel->stat.rx_errors++;
>
> you can unlock here.
OK; will fix.
Fred
fred.l.templin@boeing.com
> > + dst_release(dst);
> > + kfree_skb(skb);
> > + read_unlock(&ipip6_lock);
> > + return 0;
> > + }
> > + dst_release(dst);
> > + }
> > +accept:
> > +#endif
>
> --yoshfuji
>
^ permalink raw reply
* Re: [PATCH 04/05] ipv6: RFC4214 Support
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-11-07 18:36 UTC (permalink / raw)
To: Fred.L.Templin; +Cc: netdev, yoshfuji
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029EDBE5@XCH-NW-7V2.nw.nos.boeing.com>
Hello.
In article <39C363776A4E8C4A94691D2BD9D1C9A1029EDBE5@XCH-NW-7V2.nw.nos.boeing.com> (at Tue, 6 Nov 2007 17:16:11 -0800), "Templin, Fred L" <Fred.L.Templin@boeing.com> says:
> @@ -154,6 +155,14 @@ static struct ip_tunnel * ipip6_tunnel_l
> struct net_device *dev;
> char name[IFNAMSIZ];
>
> +#if defined(CONFIG_IPV6_ISATAP)
> + /* ISATAP (RFC4214) - router address in daddr */
> + if (!strncmp(parms->name, "isatap", 6)) {
> + parms->i_key = parms->iph.daddr;
> + parms->iph.daddr = remote = 0;
> + }
> +#endif
> +
> for (tp = __ipip6_bucket(parms); (t = *tp) != NULL; tp =
> &t->next) {
> if (local == t->parms.iph.saddr && remote ==
> t->parms.iph.daddr)
> return t;
I do not think it is a good idea to change the behavior based on
the interface name.
> @@ -182,6 +191,11 @@ static struct ip_tunnel * ipip6_tunnel_l
> dev->init = ipip6_tunnel_init;
> nt->parms = *parms;
>
> +#if defined(CONFIG_IPV6_ISATAP)
> + if (!strncmp(dev->name, "isatap", 6))
> + dev->priv_flags |= IFF_ISATAP;
> +#endif
> +
ditto.
> + if (!(ipv6_addr_is_isatap(addr6)) ||
> + (addr6->s6_addr32[3] != iph->saddr)) {
> +drop:
> + tunnel->stat.rx_errors++;
you can unlock here.
> + dst_release(dst);
> + kfree_skb(skb);
> + read_unlock(&ipip6_lock);
> + return 0;
> + }
> + dst_release(dst);
> + }
> +accept:
> +#endif
--yoshfuji
^ permalink raw reply
* RE: [PATCH 02/05] ipv6: RFC4214 Support
From: Templin, Fred L @ 2007-11-07 18:24 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明, netdev; +Cc: netdev
In-Reply-To: <20071108.031214.124029872.yoshfuji@linux-ipv6.org>
> -----Original Message-----
> From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:yoshfuji@linux-ipv6.org]
> Sent: Wednesday, November 07, 2007 10:12 AM
> To: netdev@axxeo.de
> Cc: Templin, Fred L; netdev@vger.kernel.org; yoshfuji@linux-ipv6.org
> Subject: Re: [PATCH 02/05] ipv6: RFC4214 Support
>
> Hello.
>
> In article <200711071658.59478.netdev@axxeo.de> (at Wed, 7
> Nov 2007 16:58:59 +0100), Ingo Oeser <netdev@axxeo.de> says:
>
> > > + eui[0] = 0;
> > > +
> > > + /* Check for RFC3330 global address ranges */
> > > + if (((ipv4 >= 0x01000000) && (ipv4 < 0x0a000000)) ||
> > > + ((ipv4 >= 0x0b000000) && (ipv4 < 0x7f000000)) ||
> > > + ((ipv4 >= 0x80000000) && (ipv4 < 0xa9fe0000)) ||
> > > + ((ipv4 >= 0xa9ff0000) && (ipv4 < 0xac100000)) ||
> > > + ((ipv4 >= 0xac200000) && (ipv4 < 0xc0a80000)) ||
> > > + ((ipv4 >= 0xc0a90000) && (ipv4 < 0xc6120000)) ||
> > > + ((ipv4 >= 0xc6140000) && (ipv4 < 0xe0000000))) eui[0] |=
> > > 0x2;
> > > +
> >
> > Instead of converting network to host byte order at runtime
> > and comparing the results to constants, let the compiler convert
> > the constants to network byte order and compare in network order.
> >
> > so use:
> >
> > if (((*addr >= htonl(0x01000000)) && (*addr <
> htonl(0x0a000000))) || ....
> >
> > instead. The compiler will notice that "0x01000000" is a
> constant and will
> > use "_constant_htonl()" automatically.
>
> No, you cannot do this.
> When you check the "range", you need to use host-byte order.
I think the original poster was correct on this one; the addr comes
in in network byte order, and the constants are depicted in host
byte order. So, the suggested fix was to have htonl(const) to make
all of the constants into network byte order while leaving addr
alone.
> > > +
> > > +static inline int ipv6_addr_is_isatap(const struct
> in6_addr *addr)
> > > +{
> > > + return (addr->s6_addr32[2] ==
> __constant_htonl(0x02005EFE) ||
> > > + addr->s6_addr32[2] ==
> __constant_htonl(0x00005EFE));
> > > +}
> > > +#endif
> >
> > The compiler will notice that "0x01000000" is a constant and will
> > use "_constant_htonl()" automatically. Please use simply htonl().
>
> Right. And, maybe, you can write as follows:
> return ((addr->s6_addr32[2] | htonl(0x02000000)) == htonl(0x02005EFE));
This looks good, and the change will be made.
Fred
fred.l.templin@boeing.com
>
> --yoshfuji
> -
> 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] ethtool: add support for supporting 10000baseT
From: Ben Hutchings @ 2007-11-07 18:25 UTC (permalink / raw)
To: Kok, Auke; +Cc: netdev
In-Reply-To: <4731FEC0.4020803@intel.com>
Kok, Auke wrote:
> Ben Hutchings wrote:
> > Auke Kok wrote:
> >> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
> >>
> >> there is missing support in ethtool for reporting 10000baseT
> >> as SUPPORTED_10000baseT_Full. The code seems to be half
> >> implemented because the "advertising" field has the implementation.
> >
> > I reported this lack on Sourceforge a while back:
> > <http://sourceforge.net/tracker/index.php?func=detail&aid=1798807&group_id=3242&atid=103242>
> > Is anyone reading bugs reported there?
>
> not really. However with plenty of new 10gig hardware going through
> here we're currently looking at ethtool support and seeing if it
> misses anything.
I think that's the only remaining issue we have with ethtool itself.
There's a wider issue of clause 45 MDIO for 10G Ethernet though.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
^ permalink raw reply
* RE: [PATCH 03/05] ipv6: RFC4214 Support
From: Templin, Fred L @ 2007-11-07 18:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20071107093726.3c31055b@freepuppy.rosehill>
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@linux-foundation.org]
> Sent: Wednesday, November 07, 2007 9:37 AM
> To: Templin, Fred L
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH 03/05] ipv6: RFC4214 Support
>
> On Tue, 6 Nov 2007 17:16:07 -0800
> "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
>
> > From: Fred L. Templin <fred.l.templin@boeing.com>
> >
> > This is experimental support for the Intra-Site Automatic
> > Tunnel Addressing Protocol (ISATAP) per RFC4214. It uses
> > the SIT module, and is configured using the unmodified
> > "ip" utility with device names beginning with: "isatap".
> >
> > The following diffs are specific to the Linux 2.6.23
> > kernel distribution.
> >
> > Signed-off-by: Fred L. Templin <fred.l.templin@boeing.com>
> >
> > ---
> >
> > --- linux-2.6.23/net/ipv6/addrconf.c.orig 2007-10-09
> > 13:31:38.000000000 -0700
> > +++ linux-2.6.23/net/ipv6/addrconf.c 2007-10-31
> 13:08:45.000000000
> > -0700
> > @@ -73,7 +73,11 @@
> > #include <net/tcp.h>
> > #include <net/ip.h>
> > #include <net/netlink.h>
> > +#if defined(CONFIG_IPV6_ISATAP)
> > +#include <net/ipip.h>
> > +#else
> > #include <linux/if_tunnel.h>
> > +#endif
>
> That seems odd, changing includes used based on config option.
The change was to remove the conditional and simply
include <net/ipip.h>, since it also includes
<linux/if_tunnel.h>.
> > #include <linux/rtnetlink.h>
> >
> > #ifdef CONFIG_IPV6_PRIVACY
> > @@ -1426,6 +1430,11 @@ static int ipv6_generate_eui64(u8 *eui,
> > return addrconf_ifid_arcnet(eui, dev);
> > case ARPHRD_INFINIBAND:
> > return addrconf_ifid_infiniband(eui, dev);
> > +#if defined(CONFIG_IPV6_ISATAP)
> > + case ARPHRD_SIT:
> > + if (dev->priv_flags&IFF_ISATAP)
> > + return ipv6_isatap_eui64(eui, (__be32 *)dev->dev_addr);
> > +#endif
> Missing indentation
Fixed.
> > }
> > return -1;
> > }
> > @@ -2138,7 +2147,6 @@ static void addrconf_add_linklocal(struc
> > addr_flags |= IFA_F_OPTIMISTIC;
> > #endif
> >
> > -
>
> avoid random whitespace changes
Fixed.
> > ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, addr_flags);
> > if (!IS_ERR(ifp)) {
> > addrconf_prefix_route(&ifp->addr, ifp->prefix_len,
> > idev->dev, 0, 0);
> > @@ -2192,6 +2200,32 @@ static void addrconf_sit_config(struct n
> > return;
> > }
> >
> > +#if defined(CONFIG_IPV6_ISATAP)
> > + /* ISATAP (RFC4214) - configure as NBMA link */
> > + if (dev->priv_flags&IFF_ISATAP) {
>
> missing spaces around & operator
Fixed.
> > + struct in6_addr addr;
> > +
> > + addrconf_add_lroute(dev);
> > +
> > + addr.s6_addr32[0] = htonl(0xFE800000);
>
> shouldn't this be defined somewhere rather than hardcoded
> magic constant?
Well, I see this occurring elsewhere within addrconf.c.
I did however change:
- addr.s6_addr32[0] = htonl(0xFE800000);
- addr.s6_addr32[1] = 0;
to:
+ ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0);
(Similar change occurred in 2 other places.)
> > + addr.s6_addr32[1] = 0;
> > +
> > + if (ipv6_generate_eui64(addr.s6_addr + 8, dev) == 0) {
> > + struct inet6_ifaddr *ifp;
> > +
> > + if (!IS_ERR(ifp = ipv6_add_addr(idev, &addr, 64,
> > + IFA_LINK, IFA_F_PERMANENT))) {
>
> split assignment and conditional please
Fixed.
> > + addrconf_prefix_route(&ifp->addr,
> > ifp->prefix_len,
> > + idev->dev, 0, 0);
> > + addrconf_dad_start(ifp, 0);
> > + in6_ifa_put(ifp);
> > + }
> > + }
> > +
> > + return;
> > + }
> > +#endif
> > +
> > sit_add_v4_addrs(idev);
> >
> > if (dev->flags&IFF_POINTOPOINT) {
> > @@ -2521,6 +2555,16 @@ static void addrconf_rs_timer(unsigned l
> > * Announcement received after solicitation
> > * was sent
> > */
> > +#if defined(CONFIG_IPV6_ISATAP)
> > + /* ISATAP (RFC4214) - Re-DAD to trigger new RS/RA */
> > + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> > + spin_lock(&ifp->lock);
> > + ifp->probes = 0;
> > + ifp->idev->if_flags &= ~(IF_RS_SENT|IF_RA_RCVD);
> > + addrconf_mod_timer(ifp, AC_DAD, HZ*120);
> > + spin_unlock(&ifp->lock);
> > + }
> > +#endif
> > goto out;
> > }
> >
> > @@ -2535,10 +2579,32 @@ static void addrconf_rs_timer(unsigned l
> > ifp->idev->cnf.rtr_solicit_interval);
> > spin_unlock(&ifp->lock);
> >
> > +#if defined(CONFIG_IPV6_ISATAP)
> > + /* ISATAP (RFC4214) - unicast RS */
> > + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> > + struct ip_tunnel *t = netdev_priv(ifp->idev->dev);
>
> Please follow kernel indentation standard of tabs (not 4 spaces).
Fixed everywhere in addrconf.c, and also in sit.c.
Fred
fred.l.templin@boeing.com
> > + __be32 rtr = t->parms.i_key;
> > +
> > + if (!rtr) goto out;
> > +
> > + all_routers.s6_addr32[0] = htonl(0xFE800000);
> > + all_routers.s6_addr32[1] = 0;
> > + ipv6_isatap_eui64(all_routers.s6_addr + 8, &rtr);
> > +
> > + } else
> > +#endif
> > ipv6_addr_all_routers(&all_routers);
> >
> > ndisc_send_rs(ifp->idev->dev, &ifp->addr, &all_routers);
> > } else {
> > +#if defined(CONFIG_IPV6_ISATAP)
> > + /* ISATAP (RFC4214) - Re-DAD to trigger new RS/RA */
> > + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> > + ifp->probes = 0;
> > + ifp->idev->if_flags &= ~(IF_RS_SENT|IF_RA_RCVD);
> > + addrconf_mod_timer(ifp, AC_DAD, HZ*120);
> > + }
> > +#endif
> > spin_unlock(&ifp->lock);
> > /*
> > * Note: we do not support deprecated "all on-link"
> > @@ -2584,6 +2650,9 @@ static void addrconf_dad_start(struct in
> > spin_lock_bh(&ifp->lock);
> >
> > if (dev->flags&(IFF_NOARP|IFF_LOOPBACK) ||
> > +#if defined(CONFIG_IPV6_ISATAP)
> > + dev->priv_flags&IFF_ISATAP ||
> > +#endif
> > !(ifp->flags&IFA_F_TENTATIVE) ||
> > ifp->flags & IFA_F_NODAD) {
> > ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
> > @@ -2680,6 +2749,20 @@ static void addrconf_dad_completed(struc
> > (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
> > struct in6_addr all_routers;
> >
> > +#if defined(CONFIG_IPV6_ISATAP)
> > + /* ISATAP (RFC4214) - unicast RS */
> > + if (ifp->idev->dev->priv_flags & IFF_ISATAP) {
> > + struct ip_tunnel *t = netdev_priv(ifp->idev->dev);
> > + __be32 rtr = t->parms.i_key;
> > +
> > + if (!rtr) return;
> > +
> > + all_routers.s6_addr32[0] = htonl(0xFE800000);
> > + all_routers.s6_addr32[1] = 0;
> > + ipv6_isatap_eui64(all_routers.s6_addr + 8, &rtr);
> > +
> > + } else
> > +#endif
> > ipv6_addr_all_routers(&all_routers);
> >
> > /*
> > -
> > 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
>
>
> --
> Stephen Hemminger <shemminger@linux-foundation.org>
>
^ permalink raw reply
* Re: [PATCH 02/05] ipv6: RFC4214 Support
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-11-07 18:12 UTC (permalink / raw)
To: netdev; +Cc: Fred.L.Templin, netdev, yoshfuji
In-Reply-To: <200711071658.59478.netdev@axxeo.de>
Hello.
In article <200711071658.59478.netdev@axxeo.de> (at Wed, 7 Nov 2007 16:58:59 +0100), Ingo Oeser <netdev@axxeo.de> says:
> > + eui[0] = 0;
> > +
> > + /* Check for RFC3330 global address ranges */
> > + if (((ipv4 >= 0x01000000) && (ipv4 < 0x0a000000)) ||
> > + ((ipv4 >= 0x0b000000) && (ipv4 < 0x7f000000)) ||
> > + ((ipv4 >= 0x80000000) && (ipv4 < 0xa9fe0000)) ||
> > + ((ipv4 >= 0xa9ff0000) && (ipv4 < 0xac100000)) ||
> > + ((ipv4 >= 0xac200000) && (ipv4 < 0xc0a80000)) ||
> > + ((ipv4 >= 0xc0a90000) && (ipv4 < 0xc6120000)) ||
> > + ((ipv4 >= 0xc6140000) && (ipv4 < 0xe0000000))) eui[0] |=
> > 0x2;
> > +
>
> Instead of converting network to host byte order at runtime
> and comparing the results to constants, let the compiler convert
> the constants to network byte order and compare in network order.
>
> so use:
>
> if (((*addr >= htonl(0x01000000)) && (*addr < htonl(0x0a000000))) || ....
>
> instead. The compiler will notice that "0x01000000" is a constant and will
> use "_constant_htonl()" automatically.
No, you cannot do this.
When you check the "range", you need to use host-byte order.
> > +
> > +static inline int ipv6_addr_is_isatap(const struct in6_addr *addr)
> > +{
> > + return (addr->s6_addr32[2] == __constant_htonl(0x02005EFE) ||
> > + addr->s6_addr32[2] == __constant_htonl(0x00005EFE));
> > +}
> > +#endif
>
> The compiler will notice that "0x01000000" is a constant and will
> use "_constant_htonl()" automatically. Please use simply htonl().
Right. And, maybe, you can write as follows:
return ((addr->s6_addr32[2] | htonl(0x02000000)) == htonl(0x02005EFE));
--yoshfuji
^ 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