* Re: [-mm patch] is_broadcast_ether_addr() is still required
From: Andrew Morton @ 2005-07-08 20:45 UTC (permalink / raw)
To: Adrian Bunk; +Cc: bero, linux-kernel, jgarzik, netdev, ipw2100-admin
In-Reply-To: <20050708200704.GH3671@stusta.de>
Adrian Bunk <bunk@stusta.de> wrote:
>
> This patch by Bernhard Rosenkraenzer <bero@arklinux.org> is still
> required to fix the following compile error:
I think this problem is due to my failure to navigate the miasma of Jeff's
git trees. I need to go in and look at all his branches and work out
what's missing.
^ permalink raw reply
* [-mm patch] is_broadcast_ether_addr() is still required
From: Adrian Bunk @ 2005-07-08 20:07 UTC (permalink / raw)
To: akpm; +Cc: Bernhard Rosenkraenzer, linux-kernel, jgarzik, netdev,
ipw2100-admin
This patch by Bernhard Rosenkraenzer <bero@arklinux.org> is still
required to fix the following compile error:
<-- snip -->
...
CC drivers/net/wireless/ipw2200.o
...
drivers/net/wireless/ipw2200.c: In function `ipw_rx':
drivers/net/wireless/ipw2200.c:4937: warning: implicit declaration of function `is_broadcast_ether_addr'
...
CC net/ieee80211/ieee80211_tx.o
net/ieee80211/ieee80211_tx.c: In function `ieee80211_xmit':
net/ieee80211/ieee80211_tx.c:341: warning: implicit declaration of function `is_broadcast_ether_addr'
...
LD .tmp_vmlinux1
drivers/built-in.o(.text+0x422abc): In function `ipw_rx':
: undefined reference to `is_broadcast_ether_addr'
drivers/built-in.o(.text+0x4233f6): In function `ipw_rx':
: undefined reference to `is_broadcast_ether_addr'
drivers/built-in.o(.text+0x426b9f): In function
`ipw_net_hard_start_xmit':
: undefined reference to `is_broadcast_ether_addr'
drivers/built-in.o(.text+0x426f9d): In function
`ipw_net_hard_start_xmit':
: undefined reference to `is_broadcast_ether_addr'
net/built-in.o(.text+0x1e73c6): In function `ieee80211_xmit':
: undefined reference to `is_broadcast_ether_addr'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
is_broadcast_ether_addr() was removed but it's still used.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.13-rc1/include/net/ieee80211.h.ark 2005-07-01 17:46:22.000000000 +0200
+++ linux-2.6.13-rc1/include/net/ieee80211.h 2005-07-01 17:47:26.000000000 +0200
@@ -627,6 +627,11 @@
#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x"
#define MAC_ARG(x) ((u8*)(x))[0],((u8*)(x))[1],((u8*)(x))[2],((u8*)(x))[3],((u8*)(x))[4],((u8*)(x))[5]
+extern inline int is_broadcast_ether_addr(const u8 *addr)
+{
+ return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) &&
+ (addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff));
+}
#define CFG_IEEE80211_RESERVE_FCS (1<<0)
#define CFG_IEEE80211_COMPUTE_FCS (1<<1)
^ permalink raw reply
* RE: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: Ravinandan Arakali @ 2005-07-08 18:17 UTC (permalink / raw)
To: 'Arthur Kepner', 'Raghavendra Koushik'
Cc: jgarzik, netdev, netdev, leonid.grossman, rapuru.sriram
In-Reply-To: <Pine.LNX.4.61.0507080816070.24321@resonance.WorkGroup>
Arthur/David/Jeff,
Thanks for pointing that out. We will wait for any other comments
on our 12 patches. If there are no other, will send out a patch13
to include the mmiowb() change.
Thanks,
Ravi
-----Original Message-----
From: Arthur Kepner [mailto:akepner@sgi.com]
Sent: Friday, July 08, 2005 8:31 AM
To: Raghavendra Koushik
Cc: jgarzik@pobox.com; netdev@oss.sgi.com; netdev@vger.kernel.org;
ravinandan.arakali@neterion.com; leonid.grossman@neterion.com;
rapuru.sriram@neterion.com
Subject: RE: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
On Thu, 7 Jul 2005, Raghavendra Koushik wrote:
> ....
> On an Altix machine I believe the readq was necessary to flush
> the PIO writes. How long did you run the tests? I had seen
> in long duration tests that an occasional write
> (TXDL control word and the address) would be missed and the xmit
> Get's stuck.
>
The most recent tests I did used pktgen, and they ran for a total
time of ~.5 hours (changing pkt_size every 30 seconds or so). The
pktgen tests and other tests (like nttcp) have been run several times,
so I've exercised the card for a total of several hours without
any problems.
>
> >
> > FWIW, I've done quite a few performance measurements with the patch
> > I posted earlier, and it's worked well. For 1500 byte mtus throughput
> > goes up by ~20%. Is even the mmiowb() unnecessary?
> >
>
> Was this on 2.4 kernel because I think the readq would not have a
> significant impact on 2.6 kernels due to TSO.
> (with TSO on the number of packets that actually enter the
> Xmit routine would be reduced apprx 40 times).
> .....
This was with a 2.6 kernel (with TSO on). PIO reads are pretty
expensive on Altix, so eliminating them really helps us.
For big mtus (>=4KBytes) the benefit of replacing the readq()
with mmiowb() in s2io_xmit() is negligible.
--
Arthur
^ permalink raw reply
* RE: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: Raghavendra Koushik @ 2005-07-08 18:16 UTC (permalink / raw)
To: 'Arthur Kepner'
Cc: jgarzik, netdev, netdev, ravinandan.arakali, leonid.grossman,
rapuru.sriram
In-Reply-To: <Pine.LNX.4.61.0507080816070.24321@resonance.WorkGroup>
I'll include this fix in the next patch that incorporates
any other review comments coming my way.. Thanks for pointing
it out.
-Koushik
> -----Original Message-----
> From: Arthur Kepner [mailto:akepner@sgi.com]
> Sent: Friday, July 08, 2005 8:31 AM
> To: Raghavendra Koushik
> Cc: jgarzik@pobox.com; netdev@oss.sgi.com;
> netdev@vger.kernel.org; ravinandan.arakali@neterion.com;
> leonid.grossman@neterion.com; rapuru.sriram@neterion.com
> Subject: RE: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
>
> On Thu, 7 Jul 2005, Raghavendra Koushik wrote:
>
> > ....
> > On an Altix machine I believe the readq was necessary to flush
> > the PIO writes. How long did you run the tests? I had seen
> > in long duration tests that an occasional write
> > (TXDL control word and the address) would be missed and the xmit
> > Get's stuck.
> >
>
> The most recent tests I did used pktgen, and they ran for a total
> time of ~.5 hours (changing pkt_size every 30 seconds or so). The
> pktgen tests and other tests (like nttcp) have been run
> several times,
> so I've exercised the card for a total of several hours without
> any problems.
>
> >
> > >
> > > FWIW, I've done quite a few performance measurements with
> the patch
> > > I posted earlier, and it's worked well. For 1500 byte
> mtus throughput
> > > goes up by ~20%. Is even the mmiowb() unnecessary?
> > >
> >
> > Was this on 2.4 kernel because I think the readq would not have a
> > significant impact on 2.6 kernels due to TSO.
> > (with TSO on the number of packets that actually enter the
> > Xmit routine would be reduced apprx 40 times).
> > .....
>
> This was with a 2.6 kernel (with TSO on). PIO reads are pretty
> expensive on Altix, so eliminating them really helps us.
>
> For big mtus (>=4KBytes) the benefit of replacing the readq()
> with mmiowb() in s2io_xmit() is negligible.
>
> --
> Arthur
>
^ permalink raw reply
* Re: [Bonding-devel] Re: [PATCH 2.6.13-rc1 8/17] bonding: SYSFS INTERFACE (large)
From: Greg KH @ 2005-07-08 17:24 UTC (permalink / raw)
To: Brown, Aaron F
Cc: Williams, Mitch A, John W. Linville, Godse, Radheka, netdev,
bonding-devel, fubar
In-Reply-To: <31F5998A44B92447BD334F8FBBA0B01F099F2656@orsmsx401.amr.corp.intel.com>
On Thu, Jul 07, 2005 at 05:32:03PM -0700, Brown, Aaron F wrote:
> >Why not just put them in /sys/class/bond/ instead?
>
> Bonding creates a virtual network device, it seems to logically fit down
> in /sys/class/net much better then at a level all to itself.
Ok, fair enough, it's up to you all where you want to put it, I was just
offering a suggestion.
> >> The problem, then, becomes one of separating the bond interfaces from
> the
> >> non-bond interfaces.
> >
> >See proposal above.
> >
> >> The bonding_masters file is a simple solution to
> >> this problem. Reading the file gives the set of active bonds, and
> >writing
> >> the file changes the set of active bonds. As I stated before, a
> cursory
> >> reading of Documentation/filesystems/sysfs.txt indicates that such a
> >usage
> >> is "socially acceptable". (Or at least it was to Patrick Mochel back
> in
> >> January of 2003.)
> >
> >Pat was just trying to be nice. I'm not. :)
> >
> >Also, if you have too many bonds, your code will fail.
>
> This is true, but an unlikely event in any real system I am aware of.
> If I use the max_bonds load parameter and create say 600 bonds (which
> will be named bond0, bond1... bond599) then cat out the bonding_masters
> file I only see 524 bonds (bond0...bond523.)
Yup, don't want to have that happen. So I'm glad you agree with me :)
> However, as a bond interface requires at least one but usually more
> physical network devices to be of much benefit I see it unlikely that
> anybody will really ever have a real need for that many bonds. Since
> bonding really is used for combining 2 or more adapters into a single
> logical channel it could handle 1048 ports set up in bonds of 2 before
> this type of failure would appear.
Can you guarantee that no one wants that many bonds? I can't, and I
don't think you want to redo your userinterface some time in the future
when people ask for this. My proposal has no such limitations.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: Arthur Kepner @ 2005-07-08 15:31 UTC (permalink / raw)
To: Raghavendra Koushik
Cc: jgarzik, netdev, netdev, ravinandan.arakali, leonid.grossman,
rapuru.sriram
In-Reply-To: <200507080106.j6816NKP022996@guinness.s2io.com>
On Thu, 7 Jul 2005, Raghavendra Koushik wrote:
> ....
> On an Altix machine I believe the readq was necessary to flush
> the PIO writes. How long did you run the tests? I had seen
> in long duration tests that an occasional write
> (TXDL control word and the address) would be missed and the xmit
> Get's stuck.
>
The most recent tests I did used pktgen, and they ran for a total
time of ~.5 hours (changing pkt_size every 30 seconds or so). The
pktgen tests and other tests (like nttcp) have been run several times,
so I've exercised the card for a total of several hours without
any problems.
>
> >
> > FWIW, I've done quite a few performance measurements with the patch
> > I posted earlier, and it's worked well. For 1500 byte mtus throughput
> > goes up by ~20%. Is even the mmiowb() unnecessary?
> >
>
> Was this on 2.4 kernel because I think the readq would not have a
> significant impact on 2.6 kernels due to TSO.
> (with TSO on the number of packets that actually enter the
> Xmit routine would be reduced apprx 40 times).
> .....
This was with a 2.6 kernel (with TSO on). PIO reads are pretty
expensive on Altix, so eliminating them really helps us.
For big mtus (>=4KBytes) the benefit of replacing the readq()
with mmiowb() in s2io_xmit() is negligible.
--
Arthur
^ permalink raw reply
* Re: [Fwd: [patch 02/15] ppp_mppe: add PPP MPPE encryption module]
From: Paul Mackerras @ 2005-07-08 12:57 UTC (permalink / raw)
To: Jeff Garzik
Cc: akpm-3NddpPZAyC0, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA, Matt_Domsch-8PEkshWhKlo,
Brice.Goglin-vYW+cPY1g1pg9hUCZPvPmw, james.cameron-VXdhtT5mjnY,
pptpclient-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <17102.26269.264419.345257-UYQwCShxghk5kJ7NmlRacFaTQe2KTcn/@public.gmane.org>
To follow up on my comments on the mppe patch, it still misses the
most important thing, which is to make sure you don't send unencrypted
data if CCP should go down. A received CCP TermReq or TermAck will
clear the SC_DECOMP_RUN flag and the code will then ignore the
xcomp->must_compress flag.
I really think there should be another flag bit set by pppd to say
"must compress" rather than relying on the compressor telling you
that.
Paul.
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
^ permalink raw reply
* Re: [Fwd: [patch 02/15] ppp_mppe: add PPP MPPE encryption module]
From: Paul Mackerras @ 2005-07-08 11:42 UTC (permalink / raw)
To: Jeff Garzik, akpm-3NddpPZAyC0
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, jgarzik-e+AXbWqSrlAAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, Matt_Domsch-8PEkshWhKlo,
Brice.Goglin-vYW+cPY1g1pg9hUCZPvPmw, james.cameron-VXdhtT5mjnY,
pptpclient-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <42B747C9.7060901-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
Some comments on the MPPE kernel patch (sorry it's taken me so long):
> +static inline struct sk_buff *
> +pad_compress_skb(struct ppp *ppp, struct sk_buff *skb)
> +{
> + struct sk_buff *new_skb;
> + int len;
> + int new_skb_size = ppp->dev->mtu + ppp->xcomp->comp_skb_extra_space + ppp->dev->hard_header_len;
> + int compressor_skb_size = ppp->dev->mtu + ppp->xcomp->comp_skb_extra_space + PPP_HDRLEN;
This would be nicer if you broke these lines each into two lines. It
would help if you chose shorter names for comp_skb_extra_space and
decomp_skb_extra_space (just comp_extra, for instance). And why do we
need decomp_skb_extra_space anyway? We expect the decompressor to
expand things; if they shrink (as they will with MPPE) we don't have
to do anything special.
> + } else {
> + /*
> + * (len < 0)
> + * MPPE requires that we do not send unencrypted
> + * frames. The compressor will return -1 if we
> + * should drop the frame. We cannot simply test
> + * the compress_proto because MPPE and MPPC share
> + * the same number.
> + */
> + if (net_ratelimit())
> + printk(KERN_ERR "ppp: compressor dropped pkt\n");
> + kfree_skb(new_skb);
> + new_skb = NULL;
I think we just leaked the original skb in this case.
> @@ -1683,7 +1716,7 @@ ppp_decompress_frame(struct ppp *ppp, st
> goto err;
>
> if (proto == PPP_COMP) {
> - ns = dev_alloc_skb(ppp->mru + PPP_HDRLEN);
> + ns = dev_alloc_skb(ppp->mru + ppp->rcomp->decomp_skb_extra_space + PPP_HDRLEN);
> if (ns == 0) {
> printk(KERN_ERR "ppp_decompress_frame: no memory\n");
> goto err;
I don't see where you make sure that you drop any unencrypted received
frames.
> diff -puN /dev/null drivers/net/ppp_mppe.c
I haven't looked at this in detail, presumably it works OK.
Paul.
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Arnaldo Carvalho de Melo @ 2005-07-08 11:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, tgraf, netdev
In-Reply-To: <42CE3722.3070208@cosmosbay.com>
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
On 7/8/05, Eric Dumazet <dada1@cosmosbay.com> wrote:
>
> David S. Miller a écrit :
> > From: Eric Dumazet <dada1@cosmosbay.com>
> > Date: Fri, 08 Jul 2005 08:53:02 +0200
> >
> >
> >>About making sk_buff smaller, I use this patch to declare 'struct
> >>sec_path *sp' only ifdef CONFIG_XFRM, what do you think ? I also
> >>use a patch to declare nfcache, nfctinfo and nfct only if
> >>CONFIG_NETFILTER_CONNTRACK or CONFIG_NETFILTER_CONNTRACK_MODULE are
> >>defined, but thats more intrusive. Also, tc_index is not used if
> >>CONFIG_NET_SCHED only is declared but none of CONFIG_NET_SCH_* In my
> >>case, I am using CONFIG_NET_SCHED only to be able to do : tc -s -d
> >>qdisc
> >
> >
> > Distributions enable all of the ifdefs, and that is thus the
> > size and resultant performance most users see.
>
> Well, I had this idea because I found another similar use in
> include/linux/ip.h
>
> struct inet_sock {
> /* sk and pinet6 has to be the first two members of inet_sock */
> struct sock sk;
> #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> struct ipv6_pinfo *pinet6;
> #endif
/me pleads guilty, Dave, any problem with removing this #ifdef? Humm, I'll
think about using
the skb_alloc_extension() idea for struct sock, but this pinet6 sucker is a
bit more difficult I guess...
- Arnaldo
[-- Attachment #2: Type: text/html, Size: 1903 bytes --]
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Eric Dumazet @ 2005-07-08 8:19 UTC (permalink / raw)
To: David S. Miller; +Cc: tgraf, netdev
In-Reply-To: <20050708.003014.125896217.davem@davemloft.net>
David S. Miller a écrit :
> From: Eric Dumazet <dada1@cosmosbay.com>
> Date: Fri, 08 Jul 2005 08:53:02 +0200
>
>
>>About making sk_buff smaller, I use this patch to declare 'struct
>>sec_path *sp' only ifdef CONFIG_XFRM, what do you think ? I also
>>use a patch to declare nfcache, nfctinfo and nfct only if
>>CONFIG_NETFILTER_CONNTRACK or CONFIG_NETFILTER_CONNTRACK_MODULE are
>>defined, but thats more intrusive. Also, tc_index is not used if
>>CONFIG_NET_SCHED only is declared but none of CONFIG_NET_SCH_* In my
>>case, I am using CONFIG_NET_SCHED only to be able to do : tc -s -d
>>qdisc
>
>
> Distributions enable all of the ifdefs, and that is thus the
> size and resultant performance most users see.
Well, I had this idea because I found another similar use in include/linux/ip.h
struct inet_sock {
/* sk and pinet6 has to be the first two members of inet_sock */
struct sock sk;
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
struct ipv6_pinfo *pinet6;
#endif
You are right such conditions are distributions nightmare :(
Eric
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: David S. Miller @ 2005-07-08 7:30 UTC (permalink / raw)
To: dada1; +Cc: tgraf, netdev
In-Reply-To: <42CE22CE.7030902@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Fri, 08 Jul 2005 08:53:02 +0200
> About making sk_buff smaller, I use this patch to declare 'struct
> sec_path *sp' only ifdef CONFIG_XFRM, what do you think ? I also
> use a patch to declare nfcache, nfctinfo and nfct only if
> CONFIG_NETFILTER_CONNTRACK or CONFIG_NETFILTER_CONNTRACK_MODULE are
> defined, but thats more intrusive. Also, tc_index is not used if
> CONFIG_NET_SCHED only is declared but none of CONFIG_NET_SCH_* In my
> case, I am using CONFIG_NET_SCHED only to be able to do : tc -s -d
> qdisc
Distributions enable all of the ifdefs, and that is thus the
size and resultant performance most users see.
That's why I'm working on shrinking the size assuming all the
config options are enabled, because that is the reality for most
installations.
For all of this stuff we could consider stealing some ideas from BSD,
namely doing something similar to their MBUF tags.
If a subsystem wants to add a cookie to a networking buffer, it
allocates a tag and links it into the struct. So, you basically get
away with only one pointer (a struct hlist_head). We could use this
for the security, netfilter, and TC stuff. I don't know exactly what
our tags would look like, but perhaps:
struct skb_tag;
struct skb_tag_type {
void (*destructor)(struct skb_tag *);
kmem_cache_t *slab_cache;
const char *name;
};
struct skb_tag {
struct hlist_node list;
struct skb_tag_type *owner;
int tag_id;
char data[0];
};
struct sk_buff {
...
struct hlist_head tag_list;
...
};
Then netfilter does stuff like:
struct sk_buff *skb;
struct skb_tag *tag;
struct conntrack_skb_info *info;
tag = skb_find_tag(skb, SKB_TAG_NETFILTER_CONNTRACK);
info = (struct conntrack_skb_info *) tag->data;
etc. etc.
The downsides to this approach are:
1) Tagging an SKB eats a memory allocation, which isn't nice.
This is mainly why I haven't mentioned this idea before.
It may be that, on an active system, the per-cpu SLAB caches
for such tag objects might keep the allocation costs real low.
Another factor is that tags are relatively tiny, so a large
number of them fit in one SLAB.
But on the other hand we've been trying to remove per-packet
kmalloc() counts, see the SKB fast-clone discussions about that.
And people ask for SKB recycling all the time.
2) skb_clone() would get more expensive. This is because you'd
need to clone the SKB tags as well.
There is the possibility to hang the tags off of the
skb_shinfo() area. I know this idea sounds crazy, but
the theory goes that if the netfilter et. al info would
change (and thus, so would the assosciative tags), then
you'd need to COW the SKB anyways.
This is actually an idea worth considering regardless of
whether we do tags or not. It would result in less reference
counting when we clone an SKB with netfilter stuff or
security stuff attached.
Overall I'm not too thrilled with the idea, but I'm enthusiatic
about being convinced otherwise since this would shrink sk_buff
dramatically. :-)
^ permalink raw reply
* Re: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: Jeff Garzik @ 2005-07-08 3:08 UTC (permalink / raw)
To: David S. Miller, raghavendra.koushik
Cc: akepner, netdev, netdev, ravinandan.arakali, leonid.grossman,
rapuru.sriram
In-Reply-To: <20050707.200034.74747399.davem@davemloft.net>
David S. Miller wrote:
> If you need a PIO to complete in a specific order, you
> have to read it back. If you need PIO operations to occur
Correct.
A PCI read is the only way to ensure that all the CPU/PCI bridge buffers
are flushed to the device.
Whenever Arjan and I complain about "PCI posting" problems, we are
indicating a need for additional readl() calls to ensure
ordering/flushing. Delaying immediately after a writel() is a classic
PCI posting mistake. Assuming ordering is another.
Jeff
^ permalink raw reply
* Re: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: David S. Miller @ 2005-07-08 3:00 UTC (permalink / raw)
To: raghavendra.koushik
Cc: akepner, jgarzik, netdev, netdev, ravinandan.arakali,
leonid.grossman, rapuru.sriram
In-Reply-To: <200507080106.j6816NKP022996@guinness.s2io.com>
From: "Raghavendra Koushik" <raghavendra.koushik@neterion.com>
Date: Thu, 7 Jul 2005 18:06:19 -0700
> wmb() is to ensure ordered PIO writes.
wmb() does no such thing. It only has influence on
load and store instructions done by the local processor,
it has no effect on what the PCI bus may do with PIO
writes (ie. post them).
If you need a PIO to complete in a specific order, you
have to read it back. If you need PIO operations to occur
in a specific order wrt. cpu memory operations, mmiowb()
is what you need to use.
^ permalink raw reply
* RE: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: Raghavendra Koushik @ 2005-07-08 1:06 UTC (permalink / raw)
To: 'Arthur Kepner'
Cc: jgarzik, netdev, netdev, ravinandan.arakali, leonid.grossman,
rapuru.sriram
In-Reply-To: <Pine.LNX.4.61.0507071552130.24321@resonance.WorkGroup>
> I thought that an mmiowb() was called for here (to order the PIO
> writes above more cheaply than doing the readq()). I posted a
> patch like this some time ago:
>
> http://marc.theaimsgroup.com/?l=linux-netdev&m=111508292028110&w=2
On an Altix machine I believe the readq was necessary to flush
the PIO writes. How long did you run the tests? I had seen
in long duration tests that an occasional write
(TXDL control word and the address) would be missed and the xmit
Get's stuck.
>
> FWIW, I've done quite a few performance measurements with the patch
> I posted earlier, and it's worked well. For 1500 byte mtus throughput
> goes up by ~20%. Is even the mmiowb() unnecessary?
>
Was this on 2.4 kernel because I think the readq would not have a
significant impact on 2.6 kernels due to TSO.
(with TSO on the number of packets that actually enter the
Xmit routine would be reduced apprx 40 times).
> What is the wmb() above for?
wmb() is to ensure ordered PIO writes.
Thanks
- Koushik
> -----Original Message-----
> From: Arthur Kepner [mailto:akepner@sgi.com]
> Sent: Thursday, July 07, 2005 4:15 PM
> To: raghavendra.koushik@neterion.com
> Cc: jgarzik@pobox.com; netdev@oss.sgi.com;
> netdev@vger.kernel.org; ravinandan.arakali@neterion.com;
> leonid.grossman@neterion.com; rapuru.sriram@neterion.com
> Subject: Re: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
>
>
> On Thu, 7 Jul 2005 raghavendra.koushik@neterion.com wrote:
>
> > .......
> > 2. Removed unnecessary PIOs(read/write of tx_traffic_int and
> > rx_traffic_int) from interrupt handler and removed read of
> > general_int_status register from xmit routine.
>
> > ......
> > @@ -2891,6 +2869,8 @@ int s2io_xmit(struct sk_buff *skb, struc
> > val64 =
> mac_control->fifos[queue].list_info[put_off].list_phy_addr;
> > writeq(val64, &tx_fifo->TxDL_Pointer);
> >
> > + wmb();
> > +
> > val64 = (TX_FIFO_LAST_TXD_NUM(frg_cnt) | TX_FIFO_FIRST_LIST |
> > TX_FIFO_LAST_LIST);
> >
> > @@ -2900,9 +2880,6 @@ int s2io_xmit(struct sk_buff *skb, struc
> > #endif
> > writeq(val64, &tx_fifo->List_Control);
> >
> > - /* Perform a PCI read to flush previous writes */
> > - val64 = readq(&bar0->general_int_status);
> > -
> > put_off++;
>
> I thought that an mmiowb() was called for here (to order the PIO
> writes above more cheaply than doing the readq()). I posted a
> patch like this some time ago:
>
> http://marc.theaimsgroup.com/?l=linux-netdev&m=111508292028110&w=2
>
> FWIW, I've done quite a few performance measurements with the patch
> I posted earlier, and it's worked well. For 1500 byte mtus throughput
> goes up by ~20%. Is even the mmiowb() unnecessary?
>
> What is the wmb() above for?
>
> --
> Arthur
>
^ permalink raw reply
* RE: [Bonding-devel] Re: [PATCH 2.6.13-rc1 8/17] bonding: SYSFS INTERFACE (large)
From: Brown, Aaron F @ 2005-07-08 0:32 UTC (permalink / raw)
To: Greg KH, Williams, Mitch A
Cc: John W. Linville, Godse, Radheka, netdev, bonding-devel, fubar
I'm looking at this from an "end user" perspective. E.g. from the
perspective of somebody writing scripts to manipulate bonds, rather then
from the perspective of how bonding should be implemented.
>-----Original Message-----
>From: bonding-devel-admin@lists.sourceforge.net [mailto:bonding-devel-
>admin@lists.sourceforge.net] On Behalf Of Greg KH
>Sent: Thursday, July 07, 2005 4:15 PM
>To: Williams, Mitch A
>Cc: John W. Linville; Godse, Radheka; netdev@oss.sgi.com; bonding-
>devel@lists.sourceforge.net; fubar@us.ibm.com
>Subject: [Bonding-devel] Re: [PATCH 2.6.13-rc1 8/17] bonding: SYSFS
>INTERFACE (large)
>
>On Thu, Jul 07, 2005 at 04:06:38PM -0700, Mitch Williams wrote:
>> On Thu, 7 Jul 2005, John W. Linville wrote:
>> > On Wed, Jul 06, 2005 at 12:52:32PM -0700, Greg KH wrote:
>> > > On Wed, Jul 06, 2005 at 11:53:13AM -0700, Mitch Williams wrote:
>> >
>> > >
>> > > How about this:
>> > > bond_add - write to this to add a new bond, one value only.
>> > > bond_remove - write to this to remove a bond that is present.
>> > > bonds/bond0
>> > > bonds/bond1
>> > > bonds/bond2
>> > > ...
>> > > - list of bonds currently present. If you want, you
>> > > could make those bondX files directories, and put
>> > > other info about the individual bonds in there, if you
>> > > need it (I know nothing about the bonding intrerface,
>> > > sorry.)
>> > >
>> > > Would that work?
>> >
>> > I like that suggestion. It keeps the interface creation/deletion a
>> > little more independent of each other.
>> >
>>
>> We looked into a scheme much like this, but rejected it early on.
>>
>> Actually, what Greg is proposing is two things: 1) move the
individual
>> bond interface directories down a level, into /sys/class/net, and 2)
>> change bonding_masters into a set of control files, instead of one
file.
>>
>> Moving the individual bond directories to a bonds/ directory
>> is problematic. Because each bond shows up a just another network
>> interface, they show up in /sys/class/net automatically. We'd have
to
>> make a bunch of changes to the device model to account for bonding,
and
>> we'd break the semantics of the /sys/class/net hierarchy.
>
>Why not just put them in /sys/class/bond/ instead?
Bonding creates a virtual network device, it seems to logically fit down
in /sys/class/net much better then at a level all to itself.
>
>> The problem, then, becomes one of separating the bond interfaces from
the
>> non-bond interfaces.
>
>See proposal above.
>
>> The bonding_masters file is a simple solution to
>> this problem. Reading the file gives the set of active bonds, and
>writing
>> the file changes the set of active bonds. As I stated before, a
cursory
>> reading of Documentation/filesystems/sysfs.txt indicates that such a
>usage
>> is "socially acceptable". (Or at least it was to Patrick Mochel back
in
>> January of 2003.)
>
>Pat was just trying to be nice. I'm not. :)
>
>Also, if you have too many bonds, your code will fail.
This is true, but an unlikely event in any real system I am aware of.
If I use the max_bonds load parameter and create say 600 bonds (which
will be named bond0, bond1... bond599) then cat out the bonding_masters
file I only see 524 bonds (bond0...bond523.)
However, as a bond interface requires at least one but usually more
physical network devices to be of much benefit I see it unlikely that
anybody will really ever have a real need for that many bonds. Since
bonding really is used for combining 2 or more adapters into a single
logical channel it could handle 1048 ports set up in bonds of 2 before
this type of failure would appear.
>
>> My other major difficulty with the bond_add/bond_remove scheme is
that
>> these files would act differently than any other sysfs files, in that
>> their read and write semantics are not the same.
>
>Not so at all.
>
>Just don't make them readable. Lots of sysfs files are write only.
>
>> What I mean is that any given sysfs "file" will appear to contain the
>same
>> data for both read and write. Most scripts that handle sysfs do some
>sort
>> of read-modify-write operation. This would not be possible with the
type
>> of scheme Greg KH has outlined.
>
>Again, no, lots of sysfs files work this way today.
>
>> Furthermore, what happens when you read bond_add and bond_remove?
>
>-EPERM is returned? Or is it -EIO, I think it's the later if you just
>don't provide a read function, haven't tried it in a while.
>
>> What do you use to get a list of existing bond interfaces?
>
>ls /sys/bond/bonds/
>
>> Reading a file named "bond_add" to get a list of bonds is
>> counterintuitive at best, and adding an extra read-only file just to
>> get a list of bonds seems cumbersome.
>
>I never suggested reading any files.
>
>> Greg also (in another message) mentioned problems with appending to
>> bonding_masters. This currently is a problem, since sysfs itself
does
>not
>> handle appends properly.
>
>Because you are not supposed to do that.
>
>> Since there is no concept of a file pointer or
>> offset or such when the underlying methods are called, and since
sysfs
>> happily allows seek operations to succeed, appending ends up
destroying
>> the contents of the file. I submitted two patches that addressed
this
>> issue several months ago but got a frosty reception and gave up.
>
>Again, because you are not supposed to do that.
>
>thanks,
>
>greg k-h
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the 'Do More With Dual!' webinar
>happening
>July 14 at 8am PDT/11am EDT. We invite you to explore the latest in
dual
>core and dual graphics technology at this free one hour event hosted by
HP,
>AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
>_______________________________________________
>Bonding-devel mailing list
>Bonding-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bonding-devel
^ permalink raw reply
* Re: [PATCH 2.6.13-rc1 8/17] bonding: SYSFS INTERFACE (large)
From: Mitch Williams @ 2005-07-07 23:32 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Williams, Mitch A, netdev, Godse, Radheka, fubar, bonding-devel
In-Reply-To: <20050706190906.74128.qmail@web81301.mail.yahoo.com>
On Wed, 6 Jul 2005, Dmitry Torokhov wrote:
> Semaphore will not help in scenario you described:
Phooey. You're absolutely right. I'll have to go back and rework this
stuff using the reference count.
Thanks again for your efforts on this.
-Mitch
^ permalink raw reply
* transceiver problem
From: Sebastien Vincent @ 2005-07-07 23:27 UTC (permalink / raw)
To: venza, netdev
[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]
I am having some speed problem with my sis900 card. it
goes at only 1.4MB and 500k download where other
computer with on my ethernet network are going much
faster.
I've attached the dmesg out put but I suspect that it
is a tranceiver problem as I see the following upload.
0000:00:04.0: Unknown PHY transceiver found at address
1.
I am using a recent version of Gentoo:
uname -a
Linux provxtest2 2.6.11-gentoo-r9 #1 SMP Thu Jul 7
23:01:03 GMT 2005 i686 Intel(R) Pentium(R) 4 CPU
3.00GHz GenuineIntel GNU/Linux
the current version of sis900.c in this version is
1.08.06 and I also tried the latest 1.08.08 with same
result.
I've been trying to use sis900-list-phy-ids.diff or a
older patched version of the drivers with no success
with 2.6.11 kernel, and I am wondering if there is an
equivalent patch for this version.
Anyway any help would be welcome, as I am totaly
stuck.
Thks.
____________________________________________________
Sell on Yahoo! Auctions – no fees. Bid on great items.
http://auctions.yahoo.com/
[-- Attachment #2: 4223327508-dmesg.output --]
[-- Type: application/octet-stream, Size: 12958 bytes --]
Linux version 2.6.11-gentoo-r9 (root@provxtest2) (gcc version 3.3.5-20050130 (Gentoo 3.3.5.20050130-r1, ssp-3.3.5.20050130-1, pie-8.7.7.1)) #1 SMP Thu Jul 7 23:01:03 GMT 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001dff0000 (usable)
BIOS-e820: 000000001dff0000 - 000000001dff3000 (ACPI NVS)
BIOS-e820: 000000001dff3000 - 000000001e000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
479MB LOWMEM available.
found SMP MP-table at 000f56e0
On node 0 totalpages: 122864
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 118768 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
DMI 2.2 present.
ACPI: RSDP (v000 AWARD ) @ 0x000f7150
ACPI: RSDT (v001 AWARD AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1dff3000
ACPI: FADT (v001 AWARD AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1dff3040
ACPI: MADT (v001 AWARD AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1dff67c0
ACPI: DSDT (v001 AWARD AWRDACPI 0x00001000 MSFT 0x0100000d) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 20, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 dfl dfl)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 1e000000 (gap: 1e000000:e0c00000)
Built 1 zonelists
Kernel command line: root=/dev/ram0 init=/linuxrc real_root=/dev/hda3 ramdisk=8192
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 3001.009 MHz processor.
Using tsc for high-res timesource
Speakup v-2.00 CVS: Wed Mar 2 20:22:02 EST 2005 : initialized
Speakup: loading module "speakup_n"
request_module: runaway loop modprobe speakup_n
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 480560k/491456k available (2860k kernel code, 10336k reserved, 1057k data, 224k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 5931.00 BogoMIPS (lpj=2965504)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Couldn't initialize miscdevice /dev/synth.
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 0000441d 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 0000441d 00000000 00000000
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 0000441d 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01
per-CPU timeslice cutoff: 2925.05 usecs.
task migration cache decay timeout: 3 msecs.
Booting processor 1/1 eip 3000
Initializing CPU#1
Calibrating delay loop... 5996.54 BogoMIPS (lpj=2998272)
CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 0000441d 00000000 00000000
CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 0000441d 00000000 00000000
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 1024K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 00000000 00000000 00000080 0000441d 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 01
Total of 2 processors activated (11927.55 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ... failed.
...trying to set up timer as Virtual Wire IRQ... works.
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
CPU0 attaching sched-domain:
domain 0: span 3
groups: 1 2
domain 1: span 3
groups: 3
CPU1 attaching sched-domain:
domain 0: span 3
groups: 2 1
domain 1: span 3
groups: 3
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1593k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfbb20, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050211
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:02.5
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
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: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs *3 4 5 6 7 9 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 9 devices
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior. If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
Machine check exception polling timer started.
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
apm: disabled - APM is not SMP safe.
inotify device minor=63
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
SGI XFS with large block numbers, no debug enabled
Initializing Cryptographic API
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
ACPI: Power Button (FF) [PWRF]
ACPI: Fan [FAN] (on)
ACPI: Thermal Zone [THRM] (41 C)
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: PS/2 Generic Mouse on isa0060/serio1
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller at PCI slot 0000:00:02.5
ACPI: PCI interrupt 0000:00:02.5[A] -> GSI 16 (level, low) -> IRQ 16
SIS5513: chipset revision 1
SIS5513: not 100% native mode: will probe irqs later
SIS5513: SiS 962/963 MuTIOL IDE UDMA133 controller
ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: Maxtor 6Y120L0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: COMBO-52X16C, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
Probing IDE interface ide3...
Probing IDE interface ide4...
Probing IDE interface ide5...
hda: max request size: 128KiB
hda: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(133)
hda: cache flushes supported
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3
hdc: ATAPI 52X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
st: Version 20041025, fixed bufsize 32768, s/g segs 256
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
Starting balanced_irq
ACPI wakeup devices:
PCI0 USB0 USB1 USB2 USB3 MAC0 AMR0 UAR1
ACPI: (supports S0 S1 S4 S5)
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 224k freed
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ACPI: PCI interrupt 0000:00:03.3[D] -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:03.3: Silicon Integrated Systems [SiS] USB 2.0 Controller
ehci_hcd 0000:00:03.3: irq 23, pci mem 0xed501000
ehci_hcd 0000:00:03.3: new USB bus registered, assigned bus number 1
PCI: cache line size of 128 is not supported by device 0000:00:03.3
ehci_hcd 0000:00:03.3: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
USB Universal Host Controller Interface driver v2.2
ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI interrupt 0000:00:03.0[A] -> GSI 20 (level, low) -> IRQ 20
ohci_hcd 0000:00:03.0: Silicon Integrated Systems [SiS] USB 1.0 Controller
ohci_hcd 0000:00:03.0: irq 20, pci mem 0xed503000
ohci_hcd 0000:00:03.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ACPI: PCI interrupt 0000:00:03.1[B] -> GSI 21 (level, low) -> IRQ 21
ohci_hcd 0000:00:03.1: Silicon Integrated Systems [SiS] USB 1.0 Controller (#2)
ohci_hcd 0000:00:03.1: irq 21, pci mem 0xed504000
ohci_hcd 0000:00:03.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
ACPI: PCI interrupt 0000:00:03.2[C] -> GSI 22 (level, low) -> IRQ 22
ohci_hcd 0000:00:03.2: Silicon Integrated Systems [SiS] USB 1.0 Controller (#3)
ohci_hcd 0000:00:03.2: irq 22, pci mem 0xed500000
ohci_hcd 0000:00:03.2: new USB bus registered, assigned bus number 4
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
libata version 1.10 loaded.
ReiserFS: hda3: found reiserfs format "3.6" with standard journal
ReiserFS: hda3: using ordered data mode
ReiserFS: hda3: journal params: device hda3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda3: checking transaction log (hda3)
ReiserFS: hda3: Using r5 hash to sort names
Adding 1953496k swap on /dev/hda2. Priority:-1 extents:1
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected SiS 661 chipset
agpgart: Maximum main memory to use for agp memory: 409M
agpgart: AGP aperture is 64M @ 0xe8000000
ACPI: PCI interrupt 0000:00:02.7[C] -> GSI 18 (level, low) -> IRQ 18
intel8x0_measure_ac97_clock: measured 50685 usecs
intel8x0: clocking to 48000
sis900.c: v1.08.07 11/02/2003
ACPI: PCI interrupt 0000:00:04.0[A] -> GSI 19 (level, low) -> IRQ 19
0000:00:04.0: Unknown PHY transceiver found at address 1.
0000:00:04.0: Using transceiver found at address 1 as default
eth0: SiS 900 PCI Fast Ethernet at 0xe800, IRQ 19, 00:01:6c:a0:a8:26.
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
^ permalink raw reply
* Re: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: Arthur Kepner @ 2005-07-07 23:15 UTC (permalink / raw)
To: raghavendra.koushik
Cc: jgarzik, netdev, netdev, ravinandan.arakali, leonid.grossman,
rapuru.sriram
In-Reply-To: <20050707222741.71C3E89826@linux.site>
On Thu, 7 Jul 2005 raghavendra.koushik@neterion.com wrote:
> .......
> 2. Removed unnecessary PIOs(read/write of tx_traffic_int and
> rx_traffic_int) from interrupt handler and removed read of
> general_int_status register from xmit routine.
> ......
> @@ -2891,6 +2869,8 @@ int s2io_xmit(struct sk_buff *skb, struc
> val64 = mac_control->fifos[queue].list_info[put_off].list_phy_addr;
> writeq(val64, &tx_fifo->TxDL_Pointer);
>
> + wmb();
> +
> val64 = (TX_FIFO_LAST_TXD_NUM(frg_cnt) | TX_FIFO_FIRST_LIST |
> TX_FIFO_LAST_LIST);
>
> @@ -2900,9 +2880,6 @@ int s2io_xmit(struct sk_buff *skb, struc
> #endif
> writeq(val64, &tx_fifo->List_Control);
>
> - /* Perform a PCI read to flush previous writes */
> - val64 = readq(&bar0->general_int_status);
> -
> put_off++;
I thought that an mmiowb() was called for here (to order the PIO
writes above more cheaply than doing the readq()). I posted a
patch like this some time ago:
http://marc.theaimsgroup.com/?l=linux-netdev&m=111508292028110&w=2
FWIW, I've done quite a few performance measurements with the patch
I posted earlier, and it's worked well. For 1500 byte mtus throughput
goes up by ~20%. Is even the mmiowb() unnecessary?
What is the wmb() above for?
--
Arthur
^ permalink raw reply
* Re: [PATCH 2.6.13-rc1 8/17] bonding: SYSFS INTERFACE (large)
From: Greg KH @ 2005-07-07 23:14 UTC (permalink / raw)
To: Mitch Williams
Cc: John W. Linville, Radheka Godse, netdev, bonding-devel, fubar
In-Reply-To: <Pine.CYG.4.58.0507071511300.3956@mawilli1-desk2.amr.corp.intel.com>
On Thu, Jul 07, 2005 at 04:06:38PM -0700, Mitch Williams wrote:
> On Thu, 7 Jul 2005, John W. Linville wrote:
> > On Wed, Jul 06, 2005 at 12:52:32PM -0700, Greg KH wrote:
> > > On Wed, Jul 06, 2005 at 11:53:13AM -0700, Mitch Williams wrote:
> >
> > >
> > > How about this:
> > > bond_add - write to this to add a new bond, one value only.
> > > bond_remove - write to this to remove a bond that is present.
> > > bonds/bond0
> > > bonds/bond1
> > > bonds/bond2
> > > ...
> > > - list of bonds currently present. If you want, you
> > > could make those bondX files directories, and put
> > > other info about the individual bonds in there, if you
> > > need it (I know nothing about the bonding intrerface,
> > > sorry.)
> > >
> > > Would that work?
> >
> > I like that suggestion. It keeps the interface creation/deletion a
> > little more independent of each other.
> >
>
> We looked into a scheme much like this, but rejected it early on.
>
> Actually, what Greg is proposing is two things: 1) move the individual
> bond interface directories down a level, into /sys/class/net, and 2)
> change bonding_masters into a set of control files, instead of one file.
>
> Moving the individual bond directories to a bonds/ directory
> is problematic. Because each bond shows up a just another network
> interface, they show up in /sys/class/net automatically. We'd have to
> make a bunch of changes to the device model to account for bonding, and
> we'd break the semantics of the /sys/class/net hierarchy.
Why not just put them in /sys/class/bond/ instead?
> The problem, then, becomes one of separating the bond interfaces from the
> non-bond interfaces.
See proposal above.
> The bonding_masters file is a simple solution to
> this problem. Reading the file gives the set of active bonds, and writing
> the file changes the set of active bonds. As I stated before, a cursory
> reading of Documentation/filesystems/sysfs.txt indicates that such a usage
> is "socially acceptable". (Or at least it was to Patrick Mochel back in
> January of 2003.)
Pat was just trying to be nice. I'm not. :)
Also, if you have too many bonds, your code will fail.
> My other major difficulty with the bond_add/bond_remove scheme is that
> these files would act differently than any other sysfs files, in that
> their read and write semantics are not the same.
Not so at all.
Just don't make them readable. Lots of sysfs files are write only.
> What I mean is that any given sysfs "file" will appear to contain the same
> data for both read and write. Most scripts that handle sysfs do some sort
> of read-modify-write operation. This would not be possible with the type
> of scheme Greg KH has outlined.
Again, no, lots of sysfs files work this way today.
> Furthermore, what happens when you read bond_add and bond_remove?
-EPERM is returned? Or is it -EIO, I think it's the later if you just
don't provide a read function, haven't tried it in a while.
> What do you use to get a list of existing bond interfaces?
ls /sys/bond/bonds/
> Reading a file named "bond_add" to get a list of bonds is
> counterintuitive at best, and adding an extra read-only file just to
> get a list of bonds seems cumbersome.
I never suggested reading any files.
> Greg also (in another message) mentioned problems with appending to
> bonding_masters. This currently is a problem, since sysfs itself does not
> handle appends properly.
Because you are not supposed to do that.
> Since there is no concept of a file pointer or
> offset or such when the underlying methods are called, and since sysfs
> happily allows seek operations to succeed, appending ends up destroying
> the contents of the file. I submitted two patches that addressed this
> issue several months ago but got a frosty reception and gave up.
Again, because you are not supposed to do that.
thanks,
greg k-h
^ permalink raw reply
* Re: netdev @ sgi still processing emails? WAS
From: David S. Miller @ 2005-07-07 23:07 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: netdev
In-Reply-To: <C925F8B43D79CC49ACD0601FB68FF50C045E1103@orsmsx408>
From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
Date: Thu, 7 Jul 2005 16:03:30 -0700
> Is there some reason to keep both lists open? It does appear the
> marc.theaims is getting both.
It might be wise to kill it off in a month or two.
After that much time has passed, there really isn't any
reason not to have moved over to the new list location.
^ permalink raw reply
* Re: [PATCH 2.6.13-rc1 8/17] bonding: SYSFS INTERFACE (large)
From: Mitch Williams @ 2005-07-07 23:06 UTC (permalink / raw)
To: John W. Linville
Cc: Greg KH, Mitch Williams, Radheka Godse, netdev, bonding-devel,
fubar
In-Reply-To: <20050707142544.GA9418@tuxdriver.com>
On Thu, 7 Jul 2005, John W. Linville wrote:
> On Wed, Jul 06, 2005 at 12:52:32PM -0700, Greg KH wrote:
> > On Wed, Jul 06, 2005 at 11:53:13AM -0700, Mitch Williams wrote:
>
> >
> > How about this:
> > bond_add - write to this to add a new bond, one value only.
> > bond_remove - write to this to remove a bond that is present.
> > bonds/bond0
> > bonds/bond1
> > bonds/bond2
> > ...
> > - list of bonds currently present. If you want, you
> > could make those bondX files directories, and put
> > other info about the individual bonds in there, if you
> > need it (I know nothing about the bonding intrerface,
> > sorry.)
> >
> > Would that work?
>
> I like that suggestion. It keeps the interface creation/deletion a
> little more independent of each other.
>
We looked into a scheme much like this, but rejected it early on.
Actually, what Greg is proposing is two things: 1) move the individual
bond interface directories down a level, into /sys/class/net, and 2)
change bonding_masters into a set of control files, instead of one file.
Moving the individual bond directories to a bonds/ directory
is problematic. Because each bond shows up a just another network
interface, they show up in /sys/class/net automatically. We'd have to
make a bunch of changes to the device model to account for bonding, and
we'd break the semantics of the /sys/class/net hierarchy.
Instead, what we do is piggyback on the device model by adding new files
(attributes) to each bond device's directory (kobject).
The problem, then, becomes one of separating the bond interfaces from the
non-bond interfaces. The bonding_masters file is a simple solution to
this problem. Reading the file gives the set of active bonds, and writing
the file changes the set of active bonds. As I stated before, a cursory
reading of Documentation/filesystems/sysfs.txt indicates that such a usage
is "socially acceptable". (Or at least it was to Patrick Mochel back in
January of 2003.)
My other major difficulty with the bond_add/bond_remove scheme is that
these files would act differently than any other sysfs files, in that
their read and write semantics are not the same.
What I mean is that any given sysfs "file" will appear to contain the same
data for both read and write. Most scripts that handle sysfs do some sort
of read-modify-write operation. This would not be possible with the type
of scheme Greg KH has outlined.
Furthermore, what happens when you read bond_add and bond_remove? What do
you use to get a list of existing bond interfaces? Reading a file named
"bond_add" to get a list of bonds is counterintuitive at best, and adding
an extra read-only file just to get a list of bonds seems cumbersome.
Greg also (in another message) mentioned problems with appending to
bonding_masters. This currently is a problem, since sysfs itself does not
handle appends properly. Since there is no concept of a file pointer or
offset or such when the underlying methods are called, and since sysfs
happily allows seek operations to succeed, appending ends up destroying
the contents of the file. I submitted two patches that addressed this
issue several months ago but got a frosty reception and gave up.
Of course, all our discussions don't really mean anything, since none of
us is the bonding maintainer. I'd really like to know what Jay Vosburgh
thinks about all this. Are you there, Jay?
-Mitch
^ permalink raw reply
* netdev @ sgi still processing emails? WAS (RE: [PATCH] loop unrolling in net/sched/sch_generic.c)
From: Brandeburg, Jesse @ 2005-07-07 23:03 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
>From: David S. Miller [mailto:davem@davemloft.net]
>> Arg, this thread wasn't on the new list, is there any chance we can
just
>> get netdev@oss.sgi.com to forward to netdev@vger.kernel.org?
>
>It does already.
Odd, I didn't think it was because I didn't show this thread where I am
only subscribed to netdev@vger
I'm assuming you're correct, but I'm still receiving mail directly from
the reflector at oss.sgi
Received: from oss.sgi.com (oss.sgi.com [192.48.159.27])
by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v
1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j67MPaJF014398
for <jesse.brandeburg@intel.com>; Thu, 7 Jul 2005 22:25:36 GMT
Received: from oss (localhost [127.0.0.1])
by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id
j67MQxH9014528;
Thu, 7 Jul 2005 15:26:59 -0700
Received: with ECARTIS (v1.0.0; list netdev); Thu, 07 Jul 2005 15:26:17
-0700 (PDT)
Received: from sunset.davemloft.net ([216.27.180.168])
by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id
j67MQBH9014292
Is there some reason to keep both lists open? It does appear the
marc.theaims is getting both.
Jesse
^ permalink raw reply
* [PATCH 2.6.12.1 12/12] S2io: Miscellaneous fixes
From: raghavendra.koushik @ 2005-07-07 22:42 UTC (permalink / raw)
To: jgarzik, netdev
Cc: raghavendra.koushik, ravinandan.arakali, leonid.grossman,
rapuru.sriram
Hi,
The last patch in this series fixes the following issues found during
testing.
1. Ensure we don't pass zero sized buffers to the card(which can lockup)
2. Restore the PCI-X parameters(in case of Xframe I adapter) after a reset.
3. Make sure total size of all FIFOs does not exceed 8192.
Signed-off-by: Ravinandan Arakali <ravinandan.arakali@neterion.com>
Signed-off-by: Raghavendra Koushik <raghavendra.koushik@neterion.com>
---
diff -uprN vanilla_kernel/drivers/net/s2io.c linux-2.6.12-rc6/drivers/net/s2io.c
--- vanilla_kernel/drivers/net/s2io.c 2005-06-30 02:26:26.000000000 -0700
+++ linux-2.6.12-rc6/drivers/net/s2io.c 2005-06-30 03:39:18.000000000 -0700
@@ -364,10 +364,9 @@ static int init_shared_mem(struct s2io_n
size += config->tx_cfg[i].fifo_len;
}
if (size > MAX_AVAILABLE_TXDS) {
- DBG_PRINT(ERR_DBG, "%s: Total number of Tx FIFOs ",
- dev->name);
- DBG_PRINT(ERR_DBG, "exceeds the maximum value ");
- DBG_PRINT(ERR_DBG, "that can be used\n");
+ DBG_PRINT(ERR_DBG, "%s: Requested TxDs too high, ",
+ __FUNCTION__);
+ DBG_PRINT(ERR_DBG, "Requested: %d, max supported: 8192\n", size);
return FAILURE;
}
@@ -610,8 +609,9 @@ static void free_shared_mem(struct s2io_
lst_per_page);
for (j = 0; j < page_num; j++) {
int mem_blks = (j * lst_per_page);
- if (!mac_control->fifos[i].list_info[mem_blks].
- list_virt_addr)
+ if ((!mac_control->fifos[i].list_info) ||
+ (!mac_control->fifos[i].list_info[mem_blks].
+ list_virt_addr))
break;
pci_free_consistent(nic->pdev, PAGE_SIZE,
mac_control->fifos[i].
@@ -2595,6 +2595,8 @@ static void tx_intr_handler(fifo_info_t
for (j = 0; j < frg_cnt; j++, txdlp++) {
skb_frag_t *frag =
&skb_shinfo(skb)->frags[j];
+ if (!txdlp->Buffer_Pointer)
+ break;
pci_unmap_page(nic->pdev,
(dma_addr_t)
txdlp->
@@ -2745,6 +2747,10 @@ void s2io_reset(nic_t * sp)
u64 val64;
u16 subid, pci_cmd;
+ /* Back up the PCI-X CMD reg, dont want to lose MMRBC, OST settings */
+ if (sp->device_type == XFRAME_I_DEVICE)
+ pci_read_config_word(sp->pdev, PCIX_COMMAND_REGISTER, &(pci_cmd));
+
val64 = SW_RESET_ALL;
writeq(val64, &bar0->sw_reset);
@@ -2763,8 +2769,10 @@ void s2io_reset(nic_t * sp)
msleep(250);
if (!(sp->device_type & XFRAME_II_DEVICE)) {
- /* Restore the PCI state saved during initializarion. */
+ /* Restore the PCI state saved during initializarion. */
pci_restore_state(sp->pdev);
+ pci_write_config_word(sp->pdev, PCIX_COMMAND_REGISTER,
+ pci_cmd);
} else {
pci_set_master(sp->pdev);
}
@@ -2975,7 +2983,7 @@ int s2io_open(struct net_device *dev)
* Nic is initialized
*/
netif_carrier_off(dev);
- sp->last_link_state = LINK_DOWN;
+ sp->last_link_state = 0;
/* Initialize H/W and enable interrupts */
if (s2io_card_up(sp)) {
@@ -3103,6 +3111,15 @@ int s2io_xmit(struct sk_buff *skb, struc
spin_unlock_irqrestore(&sp->tx_lock, flags);
return 0;
}
+
+ /* A buffer with no data will be dropped */
+ if (!skb->len) {
+ DBG_PRINT(TX_DBG, "%s:Buffer has no data..\n", dev->name);
+ dev_kfree_skb(skb);
+ spin_unlock_irqrestore(&sp->tx_lock, flags);
+ return 0;
+ }
+
#ifdef NETIF_F_TSO
mss = skb_shinfo(skb)->tso_size;
if (mss) {
@@ -3137,6 +3154,9 @@ int s2io_xmit(struct sk_buff *skb, struc
/* For fragmented SKB. */
for (i = 0; i < frg_cnt; i++) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+ /* A '0' length fragment will be ignored */
+ if (!frag->size)
+ continue;
txdp++;
txdp->Buffer_Pointer = (u64) pci_map_page
(sp->pdev, frag->page, frag->page_offset,
@@ -5258,7 +5278,8 @@ s2io_init_nic(struct pci_dev *pdev, cons
config = &sp->config;
/* Tx side parameters. */
- tx_fifo_len[0] = DEFAULT_FIFO_LEN; /* Default value. */
+ if (tx_fifo_len[0] == 0)
+ tx_fifo_len[0] = DEFAULT_FIFO_LEN; /* Default value. */
config->tx_fifo_num = tx_fifo_num;
for (i = 0; i < MAX_TX_FIFOS; i++) {
config->tx_cfg[i].fifo_len = tx_fifo_len[i];
@@ -5281,7 +5302,8 @@ s2io_init_nic(struct pci_dev *pdev, cons
config->max_txds = MAX_SKB_FRAGS;
/* Rx side parameters. */
- rx_ring_sz[0] = SMALL_BLK_CNT; /* Default value. */
+ if (rx_ring_sz[0] == 0)
+ rx_ring_sz[0] = SMALL_BLK_CNT; /* Default value. */
config->rx_ring_num = rx_ring_num;
for (i = 0; i < MAX_RX_RINGS; i++) {
config->rx_cfg[i].num_rxd = rx_ring_sz[i] *
@@ -5311,7 +5333,7 @@ s2io_init_nic(struct pci_dev *pdev, cons
/* initialize the shared memory used by the NIC and the host */
if (init_shared_mem(sp)) {
DBG_PRINT(ERR_DBG, "%s: Memory allocation failed\n",
- dev->name);
+ __FUNCTION__);
ret = -ENOMEM;
goto mem_alloc_failed;
}
@@ -5489,7 +5511,7 @@ s2io_init_nic(struct pci_dev *pdev, cons
sp->def_mac_addr[0].mac_addr[3],
sp->def_mac_addr[0].mac_addr[4],
sp->def_mac_addr[0].mac_addr[5]);
- int mode = s2io_print_pci_mode(sp);
+ mode = s2io_print_pci_mode(sp);
if (mode < 0) {
DBG_PRINT(ERR_DBG, " Unsupported PCI bus mode ");
ret = -EBADSLT;
^ permalink raw reply
* [PATCH 2.6.12.1 11/12] S2io: New link handling scheme for Xframe II
From: raghavendra.koushik @ 2005-07-07 22:40 UTC (permalink / raw)
To: jgarzik, netdev
Cc: raghavendra.koushik, ravinandan.arakali, leonid.grossman,
rapuru.sriram
Hi,
The below patch implements a new "Link state change handling"
scheme supported by the Xframe II adapter. It also bumps up the
driver version to 2.0.2.0.
Signed-off-by: Ravinandan Arakali <ravinandan.arakali@neterion.com>
Signed-off-by: Raghavendra Koushik <raghavendra.koushik@neterion.com>
---
diff -uprN vanilla_kernel/drivers/net/s2io-regs.h linux-2.6.12-rc6/drivers/net/s2io-regs.h
--- vanilla_kernel/drivers/net/s2io-regs.h 2005-06-28 06:00:05.000000000 -0700
+++ linux-2.6.12-rc6/drivers/net/s2io-regs.h 2005-06-28 06:00:14.000000000 -0700
@@ -167,7 +167,11 @@ typedef struct _XENA_dev_config {
u8 unused4[0x08];
u64 gpio_int_reg;
+#define GPIO_INT_REG_LINK_DOWN BIT(1)
+#define GPIO_INT_REG_LINK_UP BIT(2)
u64 gpio_int_mask;
+#define GPIO_INT_MASK_LINK_DOWN BIT(1)
+#define GPIO_INT_MASK_LINK_UP BIT(2)
u64 gpio_alarms;
u8 unused5[0x38];
@@ -279,8 +283,10 @@ typedef struct _XENA_dev_config {
u64 gpio_control;
#define GPIO_CTRL_GPIO_0 BIT(8)
+ u64 misc_control;
+#define MISC_LINK_STABILITY_PRD(val) vBIT(val,29,3)
- u8 unused7_1[0x240 - 0x200];
+ u8 unused7_1[0x240 - 0x208];
u64 wreq_split_mask;
#define WREQ_SPLIT_MASK_SET_MASK(val) vBIT(val, 52, 12)
diff -uprN vanilla_kernel/drivers/net/s2io.c linux-2.6.12-rc6/drivers/net/s2io.c
--- vanilla_kernel/drivers/net/s2io.c 2005-06-28 06:00:05.000000000 -0700
+++ linux-2.6.12-rc6/drivers/net/s2io.c 2005-06-28 06:00:14.000000000 -0700
@@ -66,7 +66,7 @@
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion";
-static char s2io_driver_version[] = "Version 1.7.7";
+static char s2io_driver_version[] = "Version 2.0.2.0";
static inline int RXD_IS_UP2DT(RxD_t *rxdp)
{
@@ -1455,8 +1455,28 @@ static int init_nic(struct s2io_nic *nic
writeq(val64, &bar0->wreq_split_mask);
}
+ /* Setting Link stability period to 64 ms */
+ if (nic->device_type == XFRAME_II_DEVICE) {
+ val64 = MISC_LINK_STABILITY_PRD(3);
+ writeq(val64, &bar0->misc_control);
+ }
+
return SUCCESS;
}
+#define LINK_UP_DOWN_INTERRUPT 1
+#define MAC_RMAC_ERR_TIMER 2
+
+#if defined(CONFIG_MSI_MODE) || defined(CONFIG_MSIX_MODE)
+#define s2io_link_fault_indication(x) MAC_RMAC_ERR_TIMER
+#else
+int s2io_link_fault_indication(nic_t *nic)
+{
+ if (nic->device_type == XFRAME_II_DEVICE)
+ return LINK_UP_DOWN_INTERRUPT;
+ else
+ return MAC_RMAC_ERR_TIMER;
+}
+#endif
/**
* en_dis_able_nic_intrs - Enable or Disable the interrupts
@@ -1484,11 +1504,22 @@ static void en_dis_able_nic_intrs(struct
temp64 &= ~((u64) val64);
writeq(temp64, &bar0->general_int_mask);
/*
- * Disabled all PCIX, Flash, MDIO, IIC and GPIO
+ * If Hercules adapter enable GPIO otherwise
+ * disabled all PCIX, Flash, MDIO, IIC and GPIO
* interrupts for now.
* TODO
*/
- writeq(DISABLE_ALL_INTRS, &bar0->pic_int_mask);
+ if (s2io_link_fault_indication(nic) ==
+ LINK_UP_DOWN_INTERRUPT ) {
+ temp64 = readq(&bar0->pic_int_mask);
+ temp64 &= ~((u64) PIC_INT_GPIO);
+ writeq(temp64, &bar0->pic_int_mask);
+ temp64 = readq(&bar0->gpio_int_mask);
+ temp64 &= ~((u64) GPIO_INT_MASK_LINK_UP);
+ writeq(temp64, &bar0->gpio_int_mask);
+ } else {
+ writeq(DISABLE_ALL_INTRS, &bar0->pic_int_mask);
+ }
/*
* No MSI Support is available presently, so TTI and
* RTI interrupts are also disabled.
@@ -1579,17 +1610,8 @@ static void en_dis_able_nic_intrs(struct
writeq(temp64, &bar0->general_int_mask);
/*
* All MAC block error interrupts are disabled for now
- * except the link status change interrupt.
* TODO
*/
- val64 = MAC_INT_STATUS_RMAC_INT;
- temp64 = readq(&bar0->mac_int_mask);
- temp64 &= ~((u64) val64);
- writeq(temp64, &bar0->mac_int_mask);
-
- val64 = readq(&bar0->mac_rmac_err_mask);
- val64 &= ~((u64) RMAC_LINK_STATE_CHANGE_INT);
- writeq(val64, &bar0->mac_rmac_err_mask);
} else if (flag == DISABLE_INTRS) {
/*
* Disable MAC Intrs in the general intr mask register
@@ -1878,8 +1900,10 @@ static int start_nic(struct s2io_nic *ni
}
/* Enable select interrupts */
- interruptible = TX_TRAFFIC_INTR | RX_TRAFFIC_INTR | TX_MAC_INTR |
- RX_MAC_INTR | MC_INTR;
+ interruptible = TX_TRAFFIC_INTR | RX_TRAFFIC_INTR | MC_INTR;
+ interruptible |= TX_PIC_INTR | RX_PIC_INTR;
+ interruptible |= TX_MAC_INTR | RX_MAC_INTR;
+
en_dis_able_nic_intrs(nic, interruptible, ENABLE_INTRS);
/*
@@ -2003,8 +2027,9 @@ static void stop_nic(struct s2io_nic *ni
config = &nic->config;
/* Disable all interrupts */
- interruptible = TX_TRAFFIC_INTR | RX_TRAFFIC_INTR | TX_MAC_INTR |
- RX_MAC_INTR | MC_INTR;
+ interruptible = TX_TRAFFIC_INTR | RX_TRAFFIC_INTR | MC_INTR;
+ interruptible |= TX_PIC_INTR | RX_PIC_INTR;
+ interruptible |= TX_MAC_INTR | RX_MAC_INTR;
en_dis_able_nic_intrs(nic, interruptible, DISABLE_INTRS);
/* Disable PRCs */
@@ -2619,10 +2644,12 @@ static void alarm_intr_handler(struct s2
register u64 val64 = 0, err_reg = 0;
/* Handling link status change error Intr */
- err_reg = readq(&bar0->mac_rmac_err_reg);
- writeq(err_reg, &bar0->mac_rmac_err_reg);
- if (err_reg & RMAC_LINK_STATE_CHANGE_INT) {
- schedule_work(&nic->set_link_task);
+ if (s2io_link_fault_indication(nic) == MAC_RMAC_ERR_TIMER) {
+ err_reg = readq(&bar0->mac_rmac_err_reg);
+ writeq(err_reg, &bar0->mac_rmac_err_reg);
+ if (err_reg & RMAC_LINK_STATE_CHANGE_INT) {
+ schedule_work(&nic->set_link_task);
+ }
}
/* Handling Ecc errors */
@@ -2948,7 +2975,7 @@ int s2io_open(struct net_device *dev)
* Nic is initialized
*/
netif_carrier_off(dev);
- sp->last_link_state = 0; /* Unkown link state */
+ sp->last_link_state = LINK_DOWN;
/* Initialize H/W and enable interrupts */
if (s2io_card_up(sp)) {
@@ -3160,6 +3187,53 @@ s2io_alarm_handle(unsigned long data)
mod_timer(&sp->alarm_timer, jiffies + HZ / 2);
}
+static void s2io_txpic_intr_handle(nic_t *sp)
+{
+ XENA_dev_config_t *bar0 = (XENA_dev_config_t *) sp->bar0;
+ u64 val64;
+
+ val64 = readq(&bar0->pic_int_status);
+ if (val64 & PIC_INT_GPIO) {
+ val64 = readq(&bar0->gpio_int_reg);
+ if ((val64 & GPIO_INT_REG_LINK_DOWN) &&
+ (val64 & GPIO_INT_REG_LINK_UP)) {
+ val64 |= GPIO_INT_REG_LINK_DOWN;
+ val64 |= GPIO_INT_REG_LINK_UP;
+ writeq(val64, &bar0->gpio_int_reg);
+ goto masking;
+ }
+
+ if (((sp->last_link_state == LINK_UP) &&
+ (val64 & GPIO_INT_REG_LINK_DOWN)) ||
+ ((sp->last_link_state == LINK_DOWN) &&
+ (val64 & GPIO_INT_REG_LINK_UP))) {
+ val64 = readq(&bar0->gpio_int_mask);
+ val64 |= GPIO_INT_MASK_LINK_DOWN;
+ val64 |= GPIO_INT_MASK_LINK_UP;
+ writeq(val64, &bar0->gpio_int_mask);
+ s2io_set_link((unsigned long)sp);
+ }
+masking:
+ if (sp->last_link_state == LINK_UP) {
+ /*enable down interrupt */
+ val64 = readq(&bar0->gpio_int_mask);
+ /* unmasks link down intr */
+ val64 &= ~GPIO_INT_MASK_LINK_DOWN;
+ /* masks link up intr */
+ val64 |= GPIO_INT_MASK_LINK_UP;
+ writeq(val64, &bar0->gpio_int_mask);
+ } else {
+ /*enable UP Interrupt */
+ val64 = readq(&bar0->gpio_int_mask);
+ /* unmasks link up interrupt */
+ val64 &= ~GPIO_INT_MASK_LINK_UP;
+ /* masks link down interrupt */
+ val64 |= GPIO_INT_MASK_LINK_DOWN;
+ writeq(val64, &bar0->gpio_int_mask);
+ }
+ }
+}
+
/**
* s2io_isr - ISR handler of the device .
* @irq: the irq of the device.
@@ -3242,6 +3316,8 @@ static irqreturn_t s2io_isr(int irq, voi
tx_intr_handler(&mac_control->fifos[i]);
}
+ if (reason & GEN_INTR_TXPIC)
+ s2io_txpic_intr_handle(sp);
/*
* If the Rx buffer count is below the panic threshold then
* reallocate the buffers from the interrupt handler itself,
@@ -4645,11 +4721,13 @@ static void s2io_set_link(unsigned long
}
subid = nic->pdev->subsystem_device;
- /*
- * Allow a small delay for the NICs self initiated
- * cleanup to complete.
- */
- msleep(100);
+ if (s2io_link_fault_indication(nic) == MAC_RMAC_ERR_TIMER) {
+ /*
+ * Allow a small delay for the NICs self initiated
+ * cleanup to complete.
+ */
+ msleep(100);
+ }
val64 = readq(&bar0->adapter_status);
if (verify_xena_quiescence(nic, val64, nic->device_enabled_once)) {
@@ -4667,13 +4745,16 @@ static void s2io_set_link(unsigned long
val64 |= ADAPTER_LED_ON;
writeq(val64, &bar0->adapter_control);
}
- val64 = readq(&bar0->adapter_status);
- if (!LINK_IS_UP(val64)) {
- DBG_PRINT(ERR_DBG, "%s:", dev->name);
- DBG_PRINT(ERR_DBG, " Link down");
- DBG_PRINT(ERR_DBG, "after ");
- DBG_PRINT(ERR_DBG, "enabling ");
- DBG_PRINT(ERR_DBG, "device \n");
+ if (s2io_link_fault_indication(nic) ==
+ MAC_RMAC_ERR_TIMER) {
+ val64 = readq(&bar0->adapter_status);
+ if (!LINK_IS_UP(val64)) {
+ DBG_PRINT(ERR_DBG, "%s:", dev->name);
+ DBG_PRINT(ERR_DBG, " Link down");
+ DBG_PRINT(ERR_DBG, "after ");
+ DBG_PRINT(ERR_DBG, "enabling ");
+ DBG_PRINT(ERR_DBG, "device \n");
+ }
}
if (nic->device_enabled_once == FALSE) {
nic->device_enabled_once = TRUE;
^ permalink raw reply
* [PATCH 2.6.12.1 10/12] S2io: Support for Bimodal interrupts
From: raghavendra.koushik @ 2005-07-07 22:37 UTC (permalink / raw)
To: jgarzik, netdev
Cc: raghavendra.koushik, ravinandan.arakali, leonid.grossman,
rapuru.sriram
Hi,
This is a patch to provide bimodal interrupt moderation support for
Xframe II adapter. Basically, in this moderation scheme, the adapter
raises a traffic interrupt if the no. of packets transmitted and/or
received reaches a programmable threshold.
Signed-off-by: Ravinandan Arakali <ravinandan.arakali@neterion.com>
Signed-off-by: Raghavendra Koushik <raghavendra.koushik@neterion.com>
---
diff -urpN vanilla_kernel/drivers/net/s2io.c linux-2.6.12-rc6/drivers/net/s2io.c
--- vanilla_kernel/drivers/net/s2io.c 2005-06-28 03:30:19.000000000 -0700
+++ linux-2.6.12-rc6/drivers/net/s2io.c 2005-06-28 03:30:38.000000000 -0700
@@ -296,6 +296,7 @@ static unsigned int mc_pause_threshold_q
static unsigned int shared_splits;
static unsigned int tmac_util_period = 5;
static unsigned int rmac_util_period = 5;
+static unsigned int bimodal = 0;
#ifndef CONFIG_S2IO_NAPI
static unsigned int indicate_max_pkts;
#endif
@@ -1305,52 +1306,86 @@ static int init_nic(struct s2io_nic *nic
time++;
}
+ if (nic->config.bimodal) {
+ int k = 0;
+ for (k = 0; k < config->rx_ring_num; k++) {
+ val64 = TTI_CMD_MEM_WE | TTI_CMD_MEM_STROBE_NEW_CMD;
+ val64 |= TTI_CMD_MEM_OFFSET(0x38+k);
+ writeq(val64, &bar0->tti_command_mem);
- /* RTI Initialization */
- if (nic->device_type == XFRAME_II_DEVICE) {
/*
- * Programmed to generate Apprx 500 Intrs per
- * second
- */
- int count = (nic->config.bus_speed * 125)/4;
- val64 = RTI_DATA1_MEM_RX_TIMER_VAL(count);
+ * Once the operation completes, the Strobe bit of the command
+ * register will be reset. We poll for this particular condition
+ * We wait for a maximum of 500ms for the operation to complete,
+ * if it's not complete by then we return error.
+ */
+ time = 0;
+ while (TRUE) {
+ val64 = readq(&bar0->tti_command_mem);
+ if (!(val64 & TTI_CMD_MEM_STROBE_NEW_CMD)) {
+ break;
+ }
+ if (time > 10) {
+ DBG_PRINT(ERR_DBG,
+ "%s: TTI init Failed\n",
+ dev->name);
+ return -1;
+ }
+ time++;
+ msleep(50);
+ }
+ }
} else {
- val64 = RTI_DATA1_MEM_RX_TIMER_VAL(0xFFF);
- }
- val64 |= RTI_DATA1_MEM_RX_URNG_A(0xA) |
- RTI_DATA1_MEM_RX_URNG_B(0x10) |
- RTI_DATA1_MEM_RX_URNG_C(0x30) | RTI_DATA1_MEM_RX_TIMER_AC_EN;
-
- writeq(val64, &bar0->rti_data1_mem);
- val64 = RTI_DATA2_MEM_RX_UFC_A(0x1) |
- RTI_DATA2_MEM_RX_UFC_B(0x2) |
- RTI_DATA2_MEM_RX_UFC_C(0x40) | RTI_DATA2_MEM_RX_UFC_D(0x80);
- writeq(val64, &bar0->rti_data2_mem);
+ /* RTI Initialization */
+ if (nic->device_type == XFRAME_II_DEVICE) {
+ /*
+ * Programmed to generate Apprx 500 Intrs per
+ * second
+ */
+ int count = (nic->config.bus_speed * 125)/4;
+ val64 = RTI_DATA1_MEM_RX_TIMER_VAL(count);
+ } else {
+ val64 = RTI_DATA1_MEM_RX_TIMER_VAL(0xFFF);
+ }
+ val64 |= RTI_DATA1_MEM_RX_URNG_A(0xA) |
+ RTI_DATA1_MEM_RX_URNG_B(0x10) |
+ RTI_DATA1_MEM_RX_URNG_C(0x30) | RTI_DATA1_MEM_RX_TIMER_AC_EN;
+
+ writeq(val64, &bar0->rti_data1_mem);
+
+ val64 = RTI_DATA2_MEM_RX_UFC_A(0x1) |
+ RTI_DATA2_MEM_RX_UFC_B(0x2) |
+ RTI_DATA2_MEM_RX_UFC_C(0x40) | RTI_DATA2_MEM_RX_UFC_D(0x80);
+ writeq(val64, &bar0->rti_data2_mem);
- val64 = RTI_CMD_MEM_WE | RTI_CMD_MEM_STROBE_NEW_CMD;
- writeq(val64, &bar0->rti_command_mem);
+ for (i = 0; i < config->rx_ring_num; i++) {
+ val64 = RTI_CMD_MEM_WE | RTI_CMD_MEM_STROBE_NEW_CMD
+ | RTI_CMD_MEM_OFFSET(i);
+ writeq(val64, &bar0->rti_command_mem);
- /*
- * Once the operation completes, the Strobe bit of the
- * command register will be reset. We poll for this
- * particular condition. We wait for a maximum of 500ms
- * for the operation to complete, if it's not complete
- * by then we return error.
- */
- time = 0;
- while (TRUE) {
- val64 = readq(&bar0->rti_command_mem);
- if (!(val64 & RTI_CMD_MEM_STROBE_NEW_CMD)) {
- break;
- }
- if (time > 10) {
- DBG_PRINT(ERR_DBG, "%s: RTI init Failed\n",
- dev->name);
- return -1;
+ /*
+ * Once the operation completes, the Strobe bit of the
+ * command register will be reset. We poll for this
+ * particular condition. We wait for a maximum of 500ms
+ * for the operation to complete, if it's not complete
+ * by then we return error.
+ */
+ time = 0;
+ while (TRUE) {
+ val64 = readq(&bar0->rti_command_mem);
+ if (!(val64 & RTI_CMD_MEM_STROBE_NEW_CMD)) {
+ break;
+ }
+ if (time > 10) {
+ DBG_PRINT(ERR_DBG, "%s: RTI init Failed\n",
+ dev->name);
+ return -1;
+ }
+ time++;
+ msleep(50);
+ }
}
- time++;
- msleep(50);
}
/*
@@ -1788,6 +1823,8 @@ static int start_nic(struct s2io_nic *ni
&bar0->prc_rxd0_n[i]);
val64 = readq(&bar0->prc_ctrl_n[i]);
+ if (nic->config.bimodal)
+ val64 |= PRC_CTRL_BIMODAL_INTERRUPT;
#ifndef CONFIG_2BUFF_MODE
val64 |= PRC_CTRL_RC_ENABLED;
#else
@@ -5031,6 +5068,7 @@ module_param(mc_pause_threshold_q4q7, in
module_param(shared_splits, int, 0);
module_param(tmac_util_period, int, 0);
module_param(rmac_util_period, int, 0);
+module_param(bimodal, bool, 0);
#ifndef CONFIG_S2IO_NAPI
module_param(indicate_max_pkts, int, 0);
#endif
@@ -5398,6 +5436,14 @@ s2io_init_nic(struct pci_dev *pdev, cons
else
strcat(sp->name, ": Neterion Xframe I 10GbE adapter");
+ /* Initialize bimodal Interrupts */
+ sp->config.bimodal = bimodal;
+ if (!(sp->device_type & XFRAME_II_DEVICE) && bimodal) {
+ sp->config.bimodal = 0;
+ DBG_PRINT(ERR_DBG,"%s:Bimodal intr not supported by Xframe I\n",
+ dev->name);
+ }
+
/*
* Make Link state as off at this point, when the Link change
* interrupt comes the state will be automatically changed to
diff -urpN vanilla_kernel/drivers/net/s2io.h linux-2.6.12-rc6/drivers/net/s2io.h
--- vanilla_kernel/drivers/net/s2io.h 2005-06-28 03:30:19.000000000 -0700
+++ linux-2.6.12-rc6/drivers/net/s2io.h 2005-06-28 03:30:38.000000000 -0700
@@ -261,8 +261,6 @@ typedef struct stat_block {
u32 rmac_accepted_ip_oflow;
u32 reserved_14;
u32 link_fault_cnt;
-
-/* Software statistics maintained by driver */
swStat_t sw_stat;
} StatInfo_t;
@@ -349,6 +347,7 @@ struct config_param {
#define MAX_RX_BLOCKS_PER_RING 150
rx_ring_config_t rx_cfg[MAX_RX_RINGS]; /*Per-Rx Ring config */
+ u8 bimodal; /*Flag for setting bimodal interrupts*/
#define HEADER_ETHERNET_II_802_3_SIZE 14
#define HEADER_802_2_SIZE 3
^ 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