* [TG3]: Fix performance regression on 5705.
From: Michael Chan @ 2007-10-12 19:39 UTC (permalink / raw)
To: davem; +Cc: netdev, mcarlson, andy
[TG3]: Fix performance regression on 5705.
A performance regression was introduced by the following commit:
commit ee6a99b539a50b4e9398938a0a6d37f8bf911550
Author: Michael Chan <mchan@broadcom.com>
Date: Wed Jul 18 21:49:10 2007 -0700
[TG3]: Fix msi issue with kexec/kdump.
In making that change, the PCI latency timer and cache line size
registers were not restored after chip reset. On the 5705, the
latency timer gets reset to 0 during chip reset and this causes
very poor performance.
Update version to 3.84.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 30b1cca..b9e1dc6 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -64,8 +64,8 @@
#define DRV_MODULE_NAME "tg3"
#define PFX DRV_MODULE_NAME ": "
-#define DRV_MODULE_VERSION "3.83"
-#define DRV_MODULE_RELDATE "October 10, 2007"
+#define DRV_MODULE_VERSION "3.84"
+#define DRV_MODULE_RELDATE "October 12, 2007"
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE 0
@@ -5056,6 +5056,12 @@ static void tg3_restore_pci_state(struct tg3 *tp)
pci_write_config_dword(tp->pdev, TG3PCI_COMMAND, tp->pci_cmd);
+ if (!(tp->tg3_flags2 & TG3_FLG2_PCI_EXPRESS)) {
+ pci_write_config_byte(tp->pdev, PCI_CACHE_LINE_SIZE,
+ tp->pci_cacheline_sz);
+ pci_write_config_byte(tp->pdev, PCI_LATENCY_TIMER,
+ tp->pci_lat_timer);
+ }
/* Make sure PCI-X relaxed ordering bit is clear. */
if (tp->pcix_cap) {
u16 pcix_cmd;
^ permalink raw reply related
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Andi Kleen @ 2007-10-12 18:29 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Brandeburg, Jesse, Andi Kleen, David Miller, hadi, jeff, johnpol,
herbert, gaagaan, Robert.Olsson, netdev, rdreier,
Waskiewicz Jr, Peter P, mcarlson, jagana, general, mchan, tgraf,
randy.dunlap, sri, kaber
In-Reply-To: <20071012100500.02255243@freepuppy.rosehill>
> Use RCU? or write a generic version and get it reviewed. You really
> want someone with knowledge of all the possible barrier impacts to
> review it.
I guess he was thinking of using cmpxchg; but we don't support this
in portable code.
RCU is not really suitable for this because it assume
writing is relatively rare which is definitely not the case for a qdisc.
Also general list management with RCU is quite expensive anyways --
it would require a full copy (that is the 'C' in RCU which Linux
generally doesn't use at all)
-Andi
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Andi Kleen @ 2007-10-12 18:27 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: Andi Kleen, David Miller, hadi, shemminger, jeff, johnpol,
herbert, gaagaan, Robert.Olsson, netdev, rdreier,
Waskiewicz Jr, Peter P, mcarlson, jagana, general, mchan, tgraf,
randy.dunlap, sri, kaber
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F5203887DD1@orsmsx418.amr.corp.intel.com>
> related to this comment, does Linux have a lockless (using atomics)
> singly linked list element? That would be very useful in a driver hot
> path.
No; it doesn't. At least not a portable one.
Besides they tend to be not faster anyways because e.g. cmpxchg tends
to be as slow as an explicit spinlock.
-Andi
^ permalink raw reply
* [PATCH net-2.6] uml: hard_header fix
From: Stephen Hemminger @ 2007-10-12 18:06 UTC (permalink / raw)
To: Andrew Morton, David S. Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20071012001325.ba02a6f0.akpm@linux-foundation.org>
Fix hard_header for net-2.6 (2.6.23-mm1).
Please test this patch, unfortunately the tree it came from won't
build UML, so it isn't possible to give it a proper check.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/arch/um/drivers/slip_kern.c 2007-10-11 13:16:07.000000000 -0700
+++ b/arch/um/drivers/slip_kern.c 2007-10-12 11:06:00.000000000 -0700
@@ -30,9 +30,7 @@ void slip_init(struct net_device *dev, v
slip_proto_init(&spri->slip);
dev->init = NULL;
- dev->header_cache_update = NULL;
- dev->hard_header_cache = NULL;
- dev->hard_header = NULL;
+ dev->hard_header_ops = NULL;
dev->hard_header_len = 0;
dev->addr_len = 0;
dev->type = ARPHRD_SLIP;
--- a/arch/um/drivers/slirp_kern.c 2007-10-11 13:16:07.000000000 -0700
+++ b/arch/um/drivers/slirp_kern.c 2007-10-12 11:05:52.000000000 -0700
@@ -31,9 +31,7 @@ void slirp_init(struct net_device *dev,
dev->init = NULL;
dev->hard_header_len = 0;
- dev->header_cache_update = NULL;
- dev->hard_header_cache = NULL;
- dev->hard_header = NULL;
+ dev->hard_header_ops = NULL;
dev->addr_len = 0;
dev->type = ARPHRD_SLIP;
dev->tx_queue_len = 256;
^ permalink raw reply
* Re: [PATCH 03/12] Prevent renaming interfaces to empty string.
From: Andreas Henriksson @ 2007-10-12 17:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Alexander Wirt
In-Reply-To: <20071012100743.0c1a11f8@freepuppy.rosehill>
On fre, 2007-10-12 at 10:07 -0700, Stephen Hemminger wrote:
> > if (newname && strcmp(dev, newname)) {
> > + if (strlen(newname) == 0) {
> > + printf("\"\" is not valid device identifier\n");
> > + return -1;
> > + }
> > if (do_changename(dev, newname) < 0)
> > return -1;
> > dev = newname;
>
> The kernel should already be preventing this?
Looks like something prevents the interface to end up with no name, but
there's no error message...
./ip/ip is the "vanilla" and /sbin/ip is debians version.
$ sudo ./ip/ip link set skif name ""
$ echo $?
0
$ sudo /sbin/ip link set skif name ""
"" is not valid device identifier
$ echo $?
255
Reporting the error is probably the preferred behaviour (and return code
set to error is most likely helpful for scripts).
--
Regards,
Andreas Henriksson
^ permalink raw reply
* Re: [PATCH 04/12] Fix up various problems in netbug script.
From: Andreas Henriksson @ 2007-10-12 17:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Javier Fernández-Sanguino Peña
In-Reply-To: <20071012101456.6d092f74@freepuppy.rosehill>
On fre, 2007-10-12 at 10:14 -0700, Stephen Hemminger wrote:
> Does anyone ever use this script? Maybe it should just be pulled?
Looks like something more closely related to reporting bugs directly to
you upstream guys rather then any distribution would use, so if you
don't have a need for it then feel free to remove it.
--
Regards,
Andreas Henriksson
^ permalink raw reply
* Re: Kernel panic (network stack)
From: Stephen Hemminger @ 2007-10-12 17:20 UTC (permalink / raw)
To: xeb; +Cc: netdev
In-Reply-To: <200710121635.40414.xeb@mail.ru>
On Fri, 12 Oct 2007 16:35:40 +0400
xeb@mail.ru wrote:
>
> ---------- Пересланное сообщение ----------
>
> Тема: Kernel panic (network stack)
> Дата: 12 октября 2007
> Отправитель: xeb@mail.ru
> получатель: linux-kernel@vger.kernel.org
>
> Hello!
> I develop network driver.
> It works fine while less then 100 network interfaces exists.
> Then i give kernel panic. What could cause it ?
>
Since it probably in your code. Please code (or place to download)
the driver code.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: "ping6 -M do" fragments packets
From: Patrick McHardy @ 2007-10-12 17:17 UTC (permalink / raw)
To: Chuck Anderson; +Cc: netdev
In-Reply-To: <20071012163202.GW4751@angus.ind.WPI.EDU>
Chuck Anderson wrote:
> On Fri, Oct 12, 2007 at 06:00:12PM +0200, Patrick McHardy wrote:
>
>>>>ping6 -M do -s 65527 www.kame.net
>>>
>>>Sure enough, wireshark reports fragments:
>>>
>>>No. Time Source Destination Protocol Info
>>> 1 0.000000 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=0 id=0x79)
>>> 2 0.000007 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=1448 id=0x79)
>>
>>Are you using nf_conntrack_ipv6?
>
>
> No:
>
> [...]
Works for me:
$ ping6 -M do -s 65527 www.kame.net -n -c 1
PING www.kame.net(2001:200:0:8002:203:47ff:fea5:3085) 65527 data bytes
>From 2001:6f8:974:0:21b:21ff:fe02:6fad icmp_seq=1 Packet too big: mtu=1500
--- www.kame.net ping statistics ---
0 packets transmitted, 0 received, +1 errors
^ permalink raw reply
* Re: [PATCH 04/12] Fix up various problems in netbug script.
From: Stephen Hemminger @ 2007-10-12 17:14 UTC (permalink / raw)
To: Andreas Henriksson
Cc: netdev, Javier Fernández-Sanguino Peña,
Andreas Henriksson
In-Reply-To: <1192179407-22461-4-git-send-email-andreas@fatal.se>
On Fri, 12 Oct 2007 10:56:39 +0200
Andreas Henriksson <andreas@fatal.se> wrote:
> From: Javier Fernández-Sanguino Peña <jfs@computer.org>
>
> Fix race conditions and temporary file symlink attacks.
> See http://bugs.debian.org/289541
>
> Additional improvements by Allard Hoeve <allard@byte.nl> and others.
> See http://bugs.debian.org/313540, http://bugs.debian.org/313541,
> and http://bugs.debian.org/313544.
>
> Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Does anyone ever use this script? Maybe it should just be pulled?
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Stephen Hemminger @ 2007-10-12 17:05 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: Andi Kleen, David Miller, hadi, jeff, johnpol, herbert, gaagaan,
Robert.Olsson, netdev, rdreier, Waskiewicz Jr, Peter P, mcarlson,
jagana, general, mchan, tgraf, randy.dunlap, sri, kaber
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F5203887DD1@orsmsx418.amr.corp.intel.com>
On Fri, 12 Oct 2007 09:08:58 -0700
"Brandeburg, Jesse" <jesse.brandeburg@intel.com> wrote:
> Andi Kleen wrote:
> >> When the hw TX queue gains space, the driver self-batches packets
> >> from the sw queue to the hw queue.
> >
> > I don't really see the advantage over the qdisc in that scheme.
> > It's certainly not simpler and probably more code and would likely
> > also not require less locks (e.g. a currently lockless driver
> > would need a new lock for its sw queue). Also it is unclear to me
> > it would be really any faster.
>
> related to this comment, does Linux have a lockless (using atomics)
> singly linked list element? That would be very useful in a driver hot
> path.
Use RCU? or write a generic version and get it reviewed. You really
want someone with knowledge of all the possible barrier impacts to
review it.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH 03/12] Prevent renaming interfaces to empty string.
From: Stephen Hemminger @ 2007-10-12 17:07 UTC (permalink / raw)
To: Andreas Henriksson; +Cc: netdev, Alexander Wirt, Andreas Henriksson
In-Reply-To: <1192179407-22461-3-git-send-email-andreas@fatal.se>
On Fri, 12 Oct 2007 10:56:38 +0200
Andreas Henriksson <andreas@fatal.se> wrote:
> From: Alexander Wirt <formorer@debian.org>
>
>
> Signed-off-by: Andreas Henriksson <andreas@fatal.se>
> ---
> ip/iplink.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/ip/iplink.c b/ip/iplink.c
> index 4060845..da1f64e 100644
> --- a/ip/iplink.c
> +++ b/ip/iplink.c
> @@ -670,6 +670,10 @@ static int do_set(int argc, char **argv)
> }
>
> if (newname && strcmp(dev, newname)) {
> + if (strlen(newname) == 0) {
> + printf("\"\" is not valid device identifier\n");
> + return -1;
> + }
> if (do_changename(dev, newname) < 0)
> return -1;
> dev = newname;
The kernel should already be preventing this?
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: e100 problems in .23rc8 ?
From: Kok, Auke @ 2007-10-12 17:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Mack, Dave Jones, netdev, esandeen
In-Reply-To: <20071012153550.GB28708@gondor.apana.org.au>
Herbert Xu wrote:
> On Fri, Oct 12, 2007 at 07:54:33AM -0700, David Mack wrote:
>> Still no joy here. See attached capture. What's really weird is that it
>> shows *two* kernel panics, one in e100_poll and one in _list_add.
>
> Yes that's the symptom one would expect from that bug. We really
> need to apply the same fix that was done for e1000.
I feared that. its not the same as that commit that floated around in this thread
and involves some reorganization in the init/probe code, so it's a bit more
involved than just a few lines. I'll need a little bit of time to generate this fix.
Auke
^ permalink raw reply
* Re: [Bugme-new] [Bug 9149] New: accept() doesn't wake with error when socket descriptor closed
From: Andrew Morton @ 2007-10-12 17:06 UTC (permalink / raw)
To: mkielar; +Cc: bugme-daemon, netdev
In-Reply-To: <bug-9149-10286@http.bugzilla.kernel.org/>
On Fri, 12 Oct 2007 07:42:06 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9149
>
> Summary: accept() doesn't wake with error when socket descriptor
> closed
> Product: Networking
> Version: 2.5
> KernelVersion: 2.6.18
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: mkielar@go2.pl
>
>
> Most recent kernel where this bug did not occur: no idea
> Distribution: no idea - remote server
> Hardware Environment: i686
> Software Environment: no idea - probably pure console server
>
> Problem Description:
> In multithreaded process, one thread launches accept() on a valid-so-far
> listening socket file descriptor sockfd and waits on it. After this second
> thread launches close( sockfd ). First thread further waits on accept() even
> though the descriptor is now invalid. accept() should wake up and return with
> -1 and errno EBADF.
>
I have a feeling this is an FAQ, but I forget what the answer is?
^ permalink raw reply
* Re: [PATCH] tg3: add PCI error recovery support
From: Michael Chan @ 2007-10-12 17:46 UTC (permalink / raw)
To: linas; +Cc: mcarlson, netdev, linux-pci
In-Reply-To: <20071012163821.GA11913@austin.ibm.com>
On Fri, 2007-10-12 at 11:38 -0500, linas@austin.ibm.com wrote:
> Hi,
>
> On Thu, Aug 02, 2007 at 05:13:39PM -0700, Michael Chan wrote:
> > On Thu, 2007-08-02 at 18:12 -0500, linas@austin.ibm.com wrote:
> > > On Thu, Jul 26, 2007 at 06:12:00PM -0700, Michael Chan wrote:
> > > > On Thu, 2007-07-26 at 17:57 -0500, linas@austin.ibm.com wrote:
> > > > > [... PCI error recovery patches for tg3 ...]
> > > >
> > > > Thanks. We will review and submit probably in 2.6.24.
> > >
> > > OK, thanks. Not to nag, but it helps to get these into susbsystem
> > > maintainer trees well before then, as otherwise the 2.6.24 window
> > > will get missed (seeing how I just missed 2.6.23 ..)
> >
> > Yes, I know. David Miller hasn't opened up a 2.6.24 tree yet. We'll
> > probably have a number of patches to be submitted for 2.6.24, and we'll
> > add this one to the set. Thanks.
>
> Did the patch make it in? Now seems to be the time ...
>
> --linas
>
> p.s. I'll send a generic MSI patch to the PCI mailing list; it appears
> the MSI issue is generic, affecting lots of adapters.
>
We'll rediff the patch against the latest net-2.6 tree once you post the
MSI patch. We'll also need IBM to do some testing on it.
Thanks.
^ permalink raw reply
* Re: [PATCH] tg3: add PCI error recovery support
From: Linas Vepstas @ 2007-10-12 16:38 UTC (permalink / raw)
To: Michael Chan; +Cc: mcarlson, netdev, linux-pci
In-Reply-To: <1186100019.18322.77.camel@dell>
Hi,
On Thu, Aug 02, 2007 at 05:13:39PM -0700, Michael Chan wrote:
> On Thu, 2007-08-02 at 18:12 -0500, linas@austin.ibm.com wrote:
> > On Thu, Jul 26, 2007 at 06:12:00PM -0700, Michael Chan wrote:
> > > On Thu, 2007-07-26 at 17:57 -0500, linas@austin.ibm.com wrote:
> > > > [... PCI error recovery patches for tg3 ...]
> > >
> > > Thanks. We will review and submit probably in 2.6.24.
> >
> > OK, thanks. Not to nag, but it helps to get these into susbsystem
> > maintainer trees well before then, as otherwise the 2.6.24 window
> > will get missed (seeing how I just missed 2.6.23 ..)
>
> Yes, I know. David Miller hasn't opened up a 2.6.24 tree yet. We'll
> probably have a number of patches to be submitted for 2.6.24, and we'll
> add this one to the set. Thanks.
Did the patch make it in? Now seems to be the time ...
--linas
p.s. I'll send a generic MSI patch to the PCI mailing list; it appears
the MSI issue is generic, affecting lots of adapters.
^ permalink raw reply
* Re: "ping6 -M do" fragments packets
From: Chuck Anderson @ 2007-10-12 16:32 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <470F9A0C.4080107@trash.net>
On Fri, Oct 12, 2007 at 06:00:12PM +0200, Patrick McHardy wrote:
> >>ping6 -M do -s 65527 www.kame.net
> >
> > Sure enough, wireshark reports fragments:
> >
> > No. Time Source Destination Protocol Info
> > 1 0.000000 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=0 id=0x79)
> > 2 0.000007 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=1448 id=0x79)
>
> Are you using nf_conntrack_ipv6?
No:
nf_conntrack_tftp 9813 0
nf_conntrack_netbios_ns 7105 0
ipt_LOG 10305 1
nf_conntrack_ipv4 15049 6
xt_state 6593 6
nf_conntrack 61001 4 nf_conntrack_tftp,nf_conntrack_netbios_ns,nf_conntrack_ipv4,xt_state
nfnetlink 10841 2 nf_conntrack_ipv4,nf_conntrack
ipt_REJECT 8641 4
iptable_filter 6977 1
ip_tables 16389 1 iptable_filter
ip6t_LOG 10945 1
ip6t_REJECT 9537 2
ip6table_filter 6849 1
ip6_tables 17541 2 ip6t_LOG,ip6table_filter
x_tables 18757 8 ipt_LOG,xt_state,ipt_REJECT,ip_tables,ip6t_LOG,ip6t_REJECT,ip6_tables,xt_tcpudp
ipv6 276673 51 ip6t_REJECT
^ permalink raw reply
* RE: e100 problems in .23rc8 ?
From: David Mack @ 2007-10-12 14:54 UTC (permalink / raw)
To: Dave Jones, Kok, Auke; +Cc: Herbert Xu, netdev, esandeen
In-Reply-To: <20071011172551.GA21339@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]
Still no joy here. See attached capture. What's really weird is that it
shows *two* kernel panics, one in e100_poll and one in _list_add.
Dave
> -----Original Message-----
> From: Dave Jones [mailto:davej@redhat.com]
> Sent: Thursday, October 11, 2007 10:26 AM
> To: Kok, Auke
> Cc: Herbert Xu; netdev@vger.kernel.org; esandeen@redhat.com;
> David Mack
> Subject: Re: e100 problems in .23rc8 ?
>
> On Thu, Oct 11, 2007 at 09:10:34AM -0700, Kok, Auke wrote:
> > Herbert Xu wrote:
> > > On Wed, Oct 10, 2007 at 08:36:38PM -0400, Dave Jones wrote:
> > >> The e1000 changes you reference above, is this the
> changeset you mean?
> > >>
> > >> commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
> > >> Author: Auke Kok <auke-jan.h.kok@intel.com>
> > >> Date: Fri Jun 1 10:22:39 2007 -0700
> > >>
> > >> e1000: disable polling before registering netdevice
> > >
> > > Yep.
> >
> > this patch actually called napi_disable() in the probe
> routine which was wrong,
> > but e100 does not do that. Nonetheless e100 doesn't call
> netif_carrier_off() and
> > netif_stop_queue(), so to make e100 the same as e1000 we
> should probably do this,
> > see below.
> >
> > Dave, can you see if this resolves the issue for you? If
> so then we might want to
> > push this to -stable.
>
> Will do, thanks Auke.
>
> Eric/David, the Fedora 8 RPM version 2.6.23-6.fc8 will have
> this if you
> want to give it a shot too. It'll be at
> http://people.redhat.com/davej/kernels/Fedora/f7.92/ when it's done
> building in an hour or so.
>
> Dave
>
> --
> http://www.codemonkey.org.uk
>
[-- Attachment #2: capture.txt --]
[-- Type: text/plain, Size: 18055 bytes --]
Linux version 2.6.23-6.fc8 (kojibuilder@) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-31)) #1 SMP Thu Oct 11 14:54:16 EDT 2007
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000ec000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
BIOS-e820: 000000003fff0000 - 000000003fff8000 (ACPI data)
BIOS-e820: 000000003fff8000 - 0000000040000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
Using x86 segment limits to approximate NX protection
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 229376
HighMem 229376 -> 262128
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 262128
DMI 2.3 present.
Using APIC driver default
ACPI: RSDP 000FA8D0, 0014 (r0 AMI )
ACPI: RSDT 3FFF0000, 0028 (r1 AMIINT 10 MSFT 97)
ACPI: FACP 3FFF0030, 0074 (r1 AMIINT 10 MSFT 97)
ACPI: DSDT 3FFF00B0, 2AE4 (r1 VIA VT8371 1000 MSFT 100000B)
ACPI: FACS 3FFF8000, 0040
ACPI: PM-Timer IO Port: 0x808
Allocating PCI resources starting at 50000000 (gap: 40000000:bfff0000)
swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000
swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000ec000
swsusp: Registered nosave memory region: 00000000000ec000 - 0000000000100000
Built 1 zonelists in Zone order. Total pages: 258545
Kernel command line: ro root=LABEL=/1 console=ttyS0,9600n8
Local APIC disabled by BIOS -- you can enable it with "lapic"
Enabling fast FPU save and restore... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0814000 soft=c07f4000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 952.200 MHz processor.
Console: colour VGA+ 80x25
console [ttyS0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS: 16384
... CHAINHASH_SIZE: 8192
memory used by lock dependency info: 1024 kB
per task-struct memory footprint: 1680 bytes
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1022396k/1048512k available (2271k kernel code, 25372k reserved, 1174k data, 568k init, 131008k highmem)
virtual kernel memory layout:
fixmap : 0xffc53000 - 0xfffff000 (3760 kB)
pkmap : 0xff800000 - 0xffc00000 (4096 kB)
vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB)
lowmem : 0xc0000000 - 0xf8000000 ( 896 MB)
.init : 0xc0763000 - 0xc07f1000 ( 568 kB)
.data : 0xc0637e5f - 0xc075da44 (1174 kB)
.text : 0xc0400000 - 0xc0637e5f (2271 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay using timer specific routine.. 1907.59 BogoMIPS (lpj=953797)
Security Framework v1.0.0 initialized
SELinux: Initializing.
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 12k freed
ACPI: Core revision 20070126
ACPI: setting ELCR to 0800 (from 0e00)
CPU0: AMD Athlon(tm) Processor stepping 01
SMP motherboard not detected.
Local APIC not detected. Using dummy APIC emulation.
Brought up 1 CPUs
khelper used greatest stack depth: 3160 bytes left
Booting paravirtualized kernel on bare hardware
Time: 7:47:03 Date: 10/12/07
NET: Registered protocol family 16
khelper used greatest stack depth: 3084 bytes left
No dock devices found.
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfdb71, last bus=1
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S4 S5)
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
Disabling VIA memory write queue (PCI ID 0305, rev 03): [55] 89 & 1f -> 09
PCI quirk: region 0800-08ff claimed by vt82c586 ACPI
PCI quirk: region 0c00-0c7f claimed by vt82c686 HW-mon
PCI quirk: region 0400-040f claimed by vt82c686 SMB
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 11 devices
ACPI: ACPI bus type pnp unregistered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
Time: tsc clocksource has been installed.
PCI: Bridge: 0000:00:01.0
IO window: 8000-8fff
MEM window: dde00000-dfefffff
PREFETCH window: cdc00000-ddcfffff
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 65536 (order: 9, 2621440 bytes)
TCP bind hash table entries: 65536 (order: 9, 2359296 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Switched to high resolution mode on CPU 0
Freeing initrd memory: 2921k freed
khelper used greatest stack depth: 2956 bytes left
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
audit: initializing netlink socket (disabled)
audit(1192175220.146:1): initialized
highmem bounce pool size: 64 pages
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
ksign: Installing public key data
Loading keyring
- Added public key BA5046002C6A482A
- User ID: Red Hat, Inc. (Kernel Module GPG key)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: VIA PCI bridge detected. Disabling DAC.
PCI: Disabling Via external APIC routing
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: Thermal Zone [THRM] (30 C)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.102
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ÿserial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
input: Macintosh mouse button emulation as /class/input/input0
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input1
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
powernow-k8: Processor cpuid 631 not supported
Using IPI No-Shortcut mode
Magic number: 11:900:773
Freeing unused kernel memory: 568k freed
Write protecting the kernel read-only data: 877k
Red Hat nash version 6.0.19 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loinsmod used greatest stack depth: 2696 bytes left
ading ehci-hcd.ko module
Loading ohci-hcd.ko module
Loading uhUSB Universal Host Controller Interface driver v3.0
ci-hcd.ko moduleACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9
ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:07.2: irq 9, io base 0x0000b800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
uhci_hcd 0000:00:07.3: UHCI Host Controller
uhci_hcd 0000:00:07.3: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:07.3: irq 9, io base 0x0000bc00
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
insmod used greatest stack depth: 1892 bytes left
Loading mbcache.ko module
Loading jbd.ko minput: ImPS/2 Generic Wheel Mouse as /class/input/input2
odule
Loading ext3.ko module
Loading scsi_mod.ko module
SCSI subsystem initialized
Loading sd_mod.ko module
Loading libata.ko module
Loading ata_generic.ko module
Loading pata_via.ko module
scsi0 : pata_via
scsi1 : pata_via
ata1: PATA max UDMA/66 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14
ata2: PATA max UDMA/66 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15
ata1.00: ATA-5: IC35L060AVER07-0, ER6OA41A, max UDMA/100
ata1.00: 120103200 sectors, multi 16: LBA
ata1.01: ATA-7: Maxtor 6Y250P0, YAR41BW0, max UDMA/133
ata1.01: 490234752 sectors, multi 16: LBA48
ata1.00: configured for UDMA/66
ata1.01: configured for UDMA/66
ata2.00: ATAPI: PIONEER DVD-RW DVR-106D, 1.05, max UDMA/33
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA IC35L060AVER07-0 ER6O PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 120103200 512-byte hardware sectors (61493 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 120103200 512-byte hardware sectors (61493 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y250P0 YAR4 PQ: 0 ANSI: 5
sd 0:0:1:0: [sdb] 490234752 512-byte hardware sectors (251000 MB)
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:1:0: [sdb] 490234752 512-byte hardware sectors (251000 MB)
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: sdb1
sd 0:0:1:0: [sdb] Attached SCSI disk
scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-106D 1.05 PQ: 0 ANSI: 5
insmod used greatest stack depth: 820 bytes left
Waiting for driver initialization.
Trying to resume from LABEL=SWAP-sda2
No suspend signature on swap, not resuming.
Creating root device.
Mounting root filesystem.
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
SELinux: Disabled at runtime.
audit(1192175231.628:2): selinux=0 auid=4294967295
\rINIT: version 2.86 booting
Welcome to Fedora
Press 'I' to enter interactive startup.
Setting clock (localtime): Fri Oct 12 07:47:21 PDT 2007 [ OK ]
Starting udev: [ OK ]
Loading default keymap (us): [ OK ]
Setting hostname garnet.leviatron.com: [ OK ]
No devices found
Setting up Logical Volume Management: No volume groups found
[ OK ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda3
/1: clean, 269209/14731200 files, 2239016/14725580 blocks
[/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/sda1
/boot: recovering journal
/boot: clean, 50/26104 files, 42169/104388 blocks
[ OK ]
Remounting root filesystem in read-write mode: [ OK ]
Mounting local filesystems: [ OK ]
Enabling local filesystem quotas: [ OK ]
Enabling /etc/fstab swaps: [ OK ]
\rINIT: Entering runlevel: 3
Entering non-interactive startup
Checking for hardware changes [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0:
Determining IP information for eth0...------------[ cut here ]------------
kernel BUG at include/linux/netdevice.h:1008!
invalid opcode: 0000 [#1] SMP
Modules linked in: ipv6 dm_mirror dm_multipath dm_mod floppy snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_via82xx gameport snd_via82xx_modem snd_seq_dummy snd_emu10k1 snd_hwdep snd_ac97_codec ac97_bus snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart via686a hwmon snd_rawmidi i2c_viapro snd_timer e100 snd_util_mem snd_seq_device mii button parport_pc snd snd_page_alloc i2c_core soundcore parport sr_mod sg cdrom pata_via ata_generic libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
CPU: 0
EIP: 0060:[<f8936cff>] Not tainted VLI
EFLAGS: 00210046 (2.6.23-6.fc8 #1)
EIP is at e100_poll+0x24e/0x2ba [e100]
eax: 00000016 ebx: 00200246 ecx: 00000234 edx: f7b26000
esi: f7b26600 edi: 00000000 ebp: c07f4fc0 esp: c07f4f84
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process ip (pid: 1487, ti=c07f4000 task=f73fed60 task.ti=f6c3b000)
Stack: c07f4f9c c0449484 00000001 f73fed60 c07f4fd0 f7b26000 00000010 00000000
00000000 00000046 f6c1e000 007f4fbc f7b26000 00000000 c1e588b0 c07f4fe0
c05d05fb c1e58880 fffbf2ec 0000012c 00000001 c0751b18 0000000a c07f4ff8
Call Trace:
[<c0406463>] show_trace_log_lvl+0x1a/0x2f
[<c0406513>] show_stack_log_lvl+0x9b/0xa3
[<c04066d3>] show_registers+0x1b8/0x289
[<c04068af>] die+0x10b/0x23e
[<c0634ce8>] do_trap+0x8a/0xa3
[<c0406ca1>] do_invalid_op+0x88/0x92
[<c0634ab2>] error_code+0x72/0x78
[<c05d05fb>] net_rx_action+0xa4/0x1bc
[<c0432a39>] __do_softirq+0x78/0xff
[<c04075d4>] do_softirq+0x74/0xf7
=======================
Code: 42 2c a8 02 75 73 9c 58 8d 04 05 00 00 00 00 90 89 c3 fa 8d 04 05 00 00 00 00 90 90 e8 7d 0a b1 c7 8b 55 d8 8b 42 2c a8 20 75 04 <0f> 0b eb fe 8b 45 d8 05 80 01 00 00 e8 b4 de bc c7 8b 45 d8 90
EIP: [<f8936cff>] e100_poll+0x24e/0x2ba [e100] SS:ESP 0068:c07f4f84
Kernel panic - not syncing: Fatal exception in interrupt
list_add corruption. prev->next should be next (c1e588b0), but was 00100100. (prev=f7b26180).
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:33!
invalid opcode: 0000 [#2] SMP
Modules linked in: ipv6 dm_mirror dm_multipath dm_mod floppy snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_via82xx gameport snd_via82xx_modem snd_seq_dummy snd_emu10k1 snd_hwdep snd_ac97_codec ac97_bus snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart via686a hwmon snd_rawmidi i2c_viapro snd_timer e100 snd_util_mem snd_seq_device mii button parport_pc snd snd_page_alloc i2c_core soundcore parport sr_mod sg cdrom pata_via ata_generic libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
CPU: 0
EIP: 0060:[<c0504c70>] Tainted: G D VLI
EFLAGS: 00210082 (2.6.23-6.fc8 #1)
EIP is at __list_add+0x4b/0x60
eax: 00000061 ebx: f7b26180 ecx: c042e1f4 edx: f73fed60
esi: 00100100 edi: f7b26600 ebp: c0814f94 esp: c0814f7c
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process ip (pid: 1487, ti=c0814000 task=f73fed60 task.ti=f6c3b000)
Stack: c06dab51 c1e588b0 00100100 f7b26180 f7b26000 00200046 c0814fa4 c05cd3a7
00000000 f7b26000 c0814fc8 f89355c4 00000000 c0814fc0 c052b9d1 f7ffd870
f70c6d70 00000000 00000000 c0814fe0 c046214e 0000000b c0752380 0000000b
Call Trace:
[<c0406463>] show_trace_log_lvl+0x1a/0x2f
[<c0406513>] show_stack_log_lvl+0x9b/0xa3
[<c04066d3>] show_registers+0x1b8/0x289
[<c04068af>] die+0x10b/0x23e
[<c0634ce8>] do_trap+0x8a/0xa3
[<c0406ca1>] do_invalid_op+0x88/0x92
[<c0634ab2>] error_code+0x72/0x78
[<c05cd3a7>] __netif_rx_schedule+0x47/0xab
[<f89355c4>] e100_intr+0x96/0xa5 [e100]
[<c046214e>] handle_IRQ_event+0x1a/0x4f
[<c0463696>] handle_level_irq+0x7f/0xc9
[<c04076e8>] do_IRQ+0x91/0xbd
=======================
Code: 01 ab 6d c0 e8 88 9a f2 ff 0f 0b eb fe 8b 32 39 ce 74 1c 89 54 24 0c 89 74 24 08 89 4c 24 04 c7 04 24 51 ab 6d c0 e8 66 9a f2 ff <0f> 0b eb fe 89 59 04 89 0b 89 43 04 89 18 83 c4 10 5b 5e 5d c3
EIP: [<c0504c70>] __list_add+0x4b/0x60 SS:ESP 0068:c0814f7c
Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* RE: [ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching
From: Brandeburg, Jesse @ 2007-10-12 16:08 UTC (permalink / raw)
To: Andi Kleen, David Miller
Cc: hadi, shemminger, jeff, johnpol, herbert, gaagaan, Robert.Olsson,
netdev, rdreier, Waskiewicz Jr, Peter P, mcarlson, jagana,
general, mchan, tgraf, randy.dunlap, sri, kaber
In-Reply-To: <20071010003716.GB552@one.firstfloor.org>
Andi Kleen wrote:
>> When the hw TX queue gains space, the driver self-batches packets
>> from the sw queue to the hw queue.
>
> I don't really see the advantage over the qdisc in that scheme.
> It's certainly not simpler and probably more code and would likely
> also not require less locks (e.g. a currently lockless driver
> would need a new lock for its sw queue). Also it is unclear to me
> it would be really any faster.
related to this comment, does Linux have a lockless (using atomics)
singly linked list element? That would be very useful in a driver hot
path.
^ permalink raw reply
* Re: [PATCH 2/2] NFS: handle IPv6 addresses in nfs ctl
From: Brian Haley @ 2007-10-12 16:07 UTC (permalink / raw)
To: Aurélien Charbon; +Cc: Mailing list NFSv4, netdev ML
In-Reply-To: <470F3AF9.4050705@ext.bull.net>
Hi Aurelien,
Comments in-line.
Aurélien Charbon wrote:
> Here is a second missing part of the IPv6 support in NFS server code
> concerning knfd syscall interface.
> - struct sockaddr_in *sin;
> + struct sockaddr_in6 *sin, sin6_storage;
Nit, should call this sin6 now.
> @@ -228,9 +228,20 @@ static ssize_t write_getfs(struct file *
> return -EINVAL;
> data = (struct nfsctl_fsparm*)buf;
> err = -EPROTONOSUPPORT;
> - if (data->gd_addr.sa_family != AF_INET)
> + sin = &sin6_storage;
This should be moved in the AF_INET case.
> + switch (data->gd_addr.sa_family) {
> + case AF_INET6:
> + sin = (struct sockaddr_in6 *)&data->gd_addr;
> + in6 = sin->sin6_addr;
in6 is a structure, not a pointer. If you want it do this you have to
use ipv6_addr_copy().
> + case AF_INET:
> + /* Map v4 address into v6 structure */
> + ipv6_addr_v4map(((struct sockaddr_in
> *)&data->gd_addr)->sin_addr, in6);
ipv6_addr_set(...)
> @@ -257,7 +265,7 @@ static ssize_t write_getfs(struct file *
> static ssize_t write_getfd(struct file *file, char *buf, size_t size)
> {
> struct nfsctl_fdparm *data;
> - struct sockaddr_in *sin;
> + struct sockaddr_in6 *sin, sin6_storage;
Nit, sin -> sin6.
> @@ -268,18 +276,29 @@ static ssize_t write_getfd(struct file *
> return -EINVAL;
> data = (struct nfsctl_fdparm*)buf;
> err = -EPROTONOSUPPORT;
> - if (data->gd_addr.sa_family != AF_INET)
> + if (data->gd_addr.sa_family != AF_INET &&
> + data->gd_addr.sa_family != AF_INET6)
> goto out;
> err = -EINVAL;
> if (data->gd_version < 2 || data->gd_version > NFSSVC_MAXVERS)
> goto out;
>
> res = buf;
> - sin = (struct sockaddr_in *)&data->gd_addr;
> + sin = &sin6_storage;
Move in AF_INET case.
> - /* IPv6 address mapping */
> - ipv6_addr_v4map(sin->sin_addr, in6);
> + switch (data->gd_addr.sa_family) {
> + case AF_INET:
> + /* IPv6 address mapping */
> + ipv6_addr_v4map(((struct sockaddr_in
> *)&data->gd_addr)->sin_addr, in6);
Use ipv6_set_addr(...)
> + break;
> + case AF_INET6:
> + sin = (struct sockaddr_in6 *)&data->gd_addr;
> + in6 = sin->sin6_addr;
Must use ipv6_addr_copy() here too.
-Brian
^ permalink raw reply
* Re: [PATCH 1/2] NFS: change the ip_map cache code to handle IPv6 addresses
From: Brian Haley @ 2007-10-12 16:07 UTC (permalink / raw)
To: Aurélien Charbon; +Cc: Mailing list NFSv4, netdev ML
In-Reply-To: <470F3AF2.8000706@ext.bull.net>
Hi Aurelien,
There were some of my comments you haven't addressed yet, comments in-line.
Aurélien Charbon wrote:
> Here is a patch for the ip_map caching code part in nfs server.
> + for (i = 0; i < ncp->cl_naddr; i++) {
> + /* Mapping address */
> + ipv6_addr_v4map(ncp->cl_addrlist[i], addr6);
ipv6_addr_set(&addr6, 0, 0, htonl(0x0000FFFF), ncp->cl_addrlist[i]);
> + /* IPv6 address mapping */
> + ipv6_addr_v4map(sin->sin_addr, in6);
ipv6_addr_set(&in6, 0, 0, htonl(0x0000FFFF), sin->sin_addr);
> + /* IPv6 address mapping */
> + ipv6_addr_v4map(sin->sin_addr, in6);
ipv6_addr_set(&in6, 0, 0, htonl(0x0000FFFF), sin->sin_addr);
> +#define IS_ADDR_MAPPED(a) \
> + (((uint32_t *) (a))[0] == 0 \
> + && ((uint32_t *) (a))[1] == 0 \
> + && (((uint32_t *) (a))[2] == 0 \
> + || ((uint32_t *) (a))[2] == htonl(0xffff)))
This is unused, can go away.
> +static inline void ipv6_addr_v4map(const struct in_addr a1, struct
> in6_addr a2)
> +{
> + a2.s6_addr32[0] = 0;
> + a2.s6_addr32[1] = 0;
> + a2.s6_addr32[2] = htonl(0xffff);
> + a2.s6_addr32[3] = (uint32_t)a1.s_addr;
> +}
If you use ipv6_addr_set() everywhere you don't need this.
> static inline int ipv6_addr_v4mapped(const struct in6_addr *a)
> {
> return ((a->s6_addr32[0] | a->s6_addr32[1]) == 0 &&
> - a->s6_addr32[2] == htonl(0x0000ffff));
> + a->s6_addr32[2] == htonl(0x0000ffff));
> }
Guessing you changed a tab to a space, unnecessary.
> -static struct ip_map *ip_map_lookup(char *class, struct in_addr addr);
> +static struct ip_map *ip_map_lookup(char *class, struct in6_addr addr);
I still think you should pass a pointer here.
> -int auth_unix_add_addr(struct in_addr addr, struct auth_domain *dom)
> +int auth_unix_add_addr(struct in6_addr addr, struct auth_domain *dom)
And here.
> -struct auth_domain *auth_unix_lookup(struct in_addr addr)
> +struct auth_domain *auth_unix_lookup(struct in6_addr addr)
And here.
-Brian
^ permalink raw reply
* Re: [NET] MIPSsim: General cleanup
From: Ilpo Järvinen @ 2007-10-12 16:05 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Andrew Morton, Jeff Garzik, Netdev
In-Reply-To: <20071012135956.GA16163@linux-mips.org>
On Fri, 12 Oct 2007, Ralf Baechle wrote:
> General cleanups mostly as suggested by checkpatch plus getting rid of
> homebrew version of offsetof().
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> ---
>
> drivers/net/mipsnet.c | 63 ++++++++++++++++++-------------------
> drivers/net/mipsnet.h | 83 ++++++++++++++++++++++++++------------------------
> 2 files changed, 75 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/net/mipsnet.h b/drivers/net/mipsnet.h
> index 026c732..0132c67 100644
> --- a/drivers/net/mipsnet.h
> +++ b/drivers/net/mipsnet.h
>
> #define MIPSNET_IO_EXTENT 0x40 /* being generous */
>
> -#define field_offset(field) ((int)&((MIPS_T_NetControl*)(0))->field)
> +#define field_offset(field) (offsetof(struct net_control_block, field))
Is there any value in keeping this macro... why don't you just remote it?
There's seems to be just one user of it anyway:
drivers/net/mipsnet.c:#define mipsnet_reg_address(dev, field) (dev->base_addr + field_offset(field))
--
i.
^ permalink raw reply
* Re: "ping6 -M do" fragments packets
From: Patrick McHardy @ 2007-10-12 16:00 UTC (permalink / raw)
To: Chuck Anderson; +Cc: netdev
In-Reply-To: <20071012151841.GE3789@angus.ind.WPI.EDU>
Chuck Anderson wrote:
> I'm not subscribed, so please Cc: me on any responses. Thanks.
>
> According to the man page, ping6 should support the "-M do" option so
> never fragment packets, which I'd like to use for testing the MTU of a
> path. This option works fine for IPv4 ping, but doesn't work with
> IPv6 ping6. I can guarantee that I don't have an MTU of 63356 :-)
>
>
>>ping6 -M do -s 65527 www.kame.net
>
> Sure enough, wireshark reports fragments:
>
> No. Time Source Destination Protocol Info
> 1 0.000000 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=0 id=0x79)
> 2 0.000007 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=1448 id=0x79)
Are you using nf_conntrack_ipv6?
^ permalink raw reply
* "ping6 -M do" fragments packets
From: Chuck Anderson @ 2007-10-12 15:18 UTC (permalink / raw)
To: netdev
I'm not subscribed, so please Cc: me on any responses. Thanks.
According to the man page, ping6 should support the "-M do" option so
never fragment packets, which I'd like to use for testing the MTU of a
path. This option works fine for IPv4 ping, but doesn't work with
IPv6 ping6. I can guarantee that I don't have an MTU of 63356 :-)
>ping6 -M do -s 65527 www.kame.net
PING www.kame.net(orange.kame.net) 65527 data bytes
65535 bytes from orange.kame.net: icmp_seq=1 ttl=49 time=224 ms
65535 bytes from orange.kame.net: icmp_seq=2 ttl=49 time=226 ms
65535 bytes from orange.kame.net: icmp_seq=3 ttl=49 time=224 ms
--- www.kame.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 224.118/225.270/226.909/1.251 ms
Sure enough, wireshark reports fragments:
No. Time Source Destination Protocol Info
1 0.000000 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=0 id=0x79)
2 0.000007 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=1448 id=0x79)
3 0.000010 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=2896 id=0x79)
4 0.000013 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=4344 id=0x79)
5 0.000015 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=5792 id=0x79)
6 0.000018 2001:468:616:8c9:213:72ff:fe74:da15 2001:200:0:8002:203:47ff:fea5:3085 IPv6 IPv6 fragment (nxt=ICMPv6 (0x3a) off=7240 id=0x79)
Is this a known issue, or some issue with the Fedora build I'm using?
iputils-20070202-3.fc7
Thanks.
^ permalink raw reply
* RE: e100 problems in .23rc8 ?
From: David Mack @ 2007-10-12 15:51 UTC (permalink / raw)
To: Herbert Xu; +Cc: Dave Jones, Kok, Auke, netdev, esandeen
In-Reply-To: <20071012153550.GB28708@gondor.apana.org.au>
If I understand the message Dave Jones sent yesterday, the patch you
mention *was* applied to the e100 driver in 2.6.23-6.fc8?
Dave
> -----Original Message-----
> From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
> Sent: Friday, October 12, 2007 8:36 AM
> To: David Mack
> Cc: Dave Jones; Kok, Auke; netdev@vger.kernel.org; esandeen@redhat.com
> Subject: Re: e100 problems in .23rc8 ?
>
> On Fri, Oct 12, 2007 at 07:54:33AM -0700, David Mack wrote:
> > Still no joy here. See attached capture. What's really
> weird is that it
> > shows *two* kernel panics, one in e100_poll and one in _list_add.
>
> Yes that's the symptom one would expect from that bug. We really
> need to apply the same fix that was done for e1000.
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
^ permalink raw reply
* Re: e100 problems in .23rc8 ?
From: Herbert Xu @ 2007-10-12 15:35 UTC (permalink / raw)
To: David Mack; +Cc: Dave Jones, Kok, Auke, netdev, esandeen
In-Reply-To: <7DCDA0F058071B49AED9D3D7886C41BE0A43AD1D@muon.jnpr.net>
On Fri, Oct 12, 2007 at 07:54:33AM -0700, David Mack wrote:
> Still no joy here. See attached capture. What's really weird is that it
> shows *two* kernel panics, one in e100_poll and one in _list_add.
Yes that's the symptom one would expect from that bug. We really
need to apply the same fix that was done for e1000.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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