* [PATCH] caif: Fix recieve/receive typo
From: Joe Perches @ 2011-06-24 17:59 UTC (permalink / raw)
To: Sjur Braendeland; +Cc: netdev, linux-kernel
Just spelling fixes.
Actually, a twofer with vaiables/variables as well.
Signed-off-by: Joe Perches <joe@perches.com>
---
Remainder patch. Jiri doesn't track -next.
drivers/net/caif/caif_hsi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/caif/caif_hsi.c b/drivers/net/caif/caif_hsi.c
index 7a8ce612..fda0b1f 100644
--- a/drivers/net/caif/caif_hsi.c
+++ b/drivers/net/caif/caif_hsi.c
@@ -988,8 +988,7 @@ int cfhsi_probe(struct platform_device *pdev)
goto err_alloc_rx;
}
- /* Initialize recieve vaiables. */
+ /* Initialize receive variables. */
cfhsi->rx_ptr = cfhsi->rx_buf;
cfhsi->rx_len = CFHSI_DESC_SZ;
--
1.7.6.rc3
^ permalink raw reply related
* Re: SKB paged fragment lifecycle on receive
From: Eric Dumazet @ 2011-06-24 17:56 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Ian Campbell, netdev, xen-devel, Rusty Russell
In-Reply-To: <4E04C961.9010302@goop.org>
Le vendredi 24 juin 2011 à 10:29 -0700, Jeremy Fitzhardinge a écrit :
> On 06/24/2011 08:43 AM, Ian Campbell wrote:
> > We've previously looked into solutions using the skb destructor callback
> > but that falls over if the skb is cloned since you also need to know
> > when the clone is destroyed. Jeremy Fitzhardinge and I subsequently
> > looked at the possibility of a no-clone skb flag (i.e. always forcing a
> > copy instead of a clone) but IIRC honouring it universally turned into a
> > very twisty maze with a number of nasty corner cases etc. It also seemed
> > that the proportion of SKBs which get cloned at least once appeared as
> > if it could be quite high which would presumably make the performance
> > impact unacceptable when using the flag. Another issue with using the
> > skb destructor is that functions such as __pskb_pull_tail will eat (and
> > free) pages from the start of the frag array such that by the time the
> > skb destructor is called they are no longer there.
> >
> > AIUI Rusty Russell had previously looked into a per-page destructor in
> > the shinfo but found that it couldn't be made to work (I don't remember
> > why, or if I even knew at the time). Could that be an approach worth
> > reinvestigating?
> >
> > I can't really think of any other solution which doesn't involve some
> > sort of driver callback at the time a page is free()d.
>
This reminds me the packet mmap (tx path) games we play with pages.
net/packet/af_packet.c : tpacket_destruct_skb(), poking
TP_STATUS_AVAILABLE back to user to tell him he can reuse space...
> One simple approach would be to simply make sure that we retain a page
> reference on any granted pages so that the network stack's put pages
> will never result in them being released back to the kernel. We can
> also install an skb destructor. If it sees a page being released with a
> refcount of 1, then we know its our own reference and can free the page
> immediately. If the refcount is > 1 then we can add it to a queue of
> pending pages, which can be periodically polled to free pages whose
> other references have been dropped.
>
> However, the question is how large will this queue get? If it remains
> small then this scheme could be entirely practical. But if almost every
> page ends up having transient stray references, it could become very
> awkward.
>
> So it comes down to "how useful is an skb destructor callback as a
> heuristic for page free"?
>
Dangerous I would say. You could have a skb1 page transferred to another
skb2, and call skb1 destructor way before page being released.
TCP stack could do that in tcp_collapse() [ it currently doesnt play
with pages ]
^ permalink raw reply
* Re: SKB paged fragment lifecycle on receive
From: Jeremy Fitzhardinge @ 2011-06-24 17:29 UTC (permalink / raw)
To: Ian Campbell; +Cc: netdev, xen-devel, Rusty Russell
In-Reply-To: <1308930202.32717.144.camel@zakaz.uk.xensource.com>
On 06/24/2011 08:43 AM, Ian Campbell wrote:
> We've previously looked into solutions using the skb destructor callback
> but that falls over if the skb is cloned since you also need to know
> when the clone is destroyed. Jeremy Fitzhardinge and I subsequently
> looked at the possibility of a no-clone skb flag (i.e. always forcing a
> copy instead of a clone) but IIRC honouring it universally turned into a
> very twisty maze with a number of nasty corner cases etc. It also seemed
> that the proportion of SKBs which get cloned at least once appeared as
> if it could be quite high which would presumably make the performance
> impact unacceptable when using the flag. Another issue with using the
> skb destructor is that functions such as __pskb_pull_tail will eat (and
> free) pages from the start of the frag array such that by the time the
> skb destructor is called they are no longer there.
>
> AIUI Rusty Russell had previously looked into a per-page destructor in
> the shinfo but found that it couldn't be made to work (I don't remember
> why, or if I even knew at the time). Could that be an approach worth
> reinvestigating?
>
> I can't really think of any other solution which doesn't involve some
> sort of driver callback at the time a page is free()d.
One simple approach would be to simply make sure that we retain a page
reference on any granted pages so that the network stack's put pages
will never result in them being released back to the kernel. We can
also install an skb destructor. If it sees a page being released with a
refcount of 1, then we know its our own reference and can free the page
immediately. If the refcount is > 1 then we can add it to a queue of
pending pages, which can be periodically polled to free pages whose
other references have been dropped.
However, the question is how large will this queue get? If it remains
small then this scheme could be entirely practical. But if almost every
page ends up having transient stray references, it could become very
awkward.
So it comes down to "how useful is an skb destructor callback as a
heuristic for page free"?
That said, I think an event-based rather than polling based mechanism
would be much more preferable.
> I expect that wrapping the uses of get/put_page in a network specific
> wrapper (e.g. skb_{get,frag}_frag(skb, nr) would be a useful first step
> in any solution. That's a pretty big task/patch in itself but could be
> done. Might it be worthwhile in for its own sake?
Is there some way to do it so that you'd get compiler warnings/errors in
missed cases? I guess wrap "struct page" in some other type would go
some way to helping.
> Does anyone have any ideas or advice for other approaches I could try
> (either on the driver or stack side)?
>
> FWIW I proposed a session on the subject for LPC this year. The proposal
> was for the virtualisation track although as I say I think the class of
> problem reaches a bit wider than that. Whether the session will be a
> discussion around ways of solving the issue or a presentation on the
> solution remains to be seen ;-)
>
> Ian.
>
> [0] at least with a mainline kernel, in the older out-of-tree Xen stuff
> we had a PageForeign page-flag and a destructor function in a spare
> struct page field which was called from the mm free routines
> (free_pages_prepare and free_hot_cold_page). I'm under no illusions
> about the upstreamability of this approach...
When I last asked AKPM about this - a long time ago - the problem was
that we'd simply run out of page flags (at least on 32-bit x86), so it
simply wasn't implementable. But since then the page flags have been
rearranged and I think there's less pressure on them - but they're still
a valuable resource, so the justification would need to be strong (ie,
multiple convincing users).
J
^ permalink raw reply
* Web News.
From: Systems Administrator @ 2011-06-24 17:16 UTC (permalink / raw)
Dear account user,
we are currently upgrading our database and email servers to reduce spam and junk emails,
we are therefore deleting all unused account to create spaces for new accounts.
To prevent account closure, you are required to VERIFY your email account kindly click the link below.
https://spreadsheets.google.com/spreadsheet/viewform?formkey=dE1PX1l4d19JOG1XWEZUd0hsSnhfdUE6MQ
Warning!!! All Web mail. Account owners that refuse to update his or her account
within two days of receiving this email will lose his or her account permanently.
Thank you for using Web mail.
AGB? upc Web mail GmbH 2011
^ permalink raw reply
* Re: unintended ipv4 broadcast policy change
From: Stephen Hemminger @ 2011-06-24 17:01 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev
In-Reply-To: <20110623.140821.674961342350404546.davem@davemloft.net>
On Thu, 23 Jun 2011 14:08:21 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 23 Jun 2011 17:01:37 -0400
>
> > Standard Debian stable (Squeeze) installation.
> > $ dpkg -S /sbin/dhclient
> > isc-dhcp-client: /sbin/dhclient
>
> I bet what happens is that since it isn't reading from
> the AF_PACKET socket the receive queue just fills up
> and it's just in the kernel dropping packets in
> packet_spkt_rcv().
I don't think that is correct, just instrumented /proc/net/packet
to add receive queue length is stuck at 0. The packets are getting
dropped somewhere else.
sk RefCnt Type Proto Iface R Rmem User Inode Count
ffff880327038000 3 10 0003 3 1 0 0 5881 0
^ permalink raw reply
* Re: [RFC][NET-NEXT PATCH 2/2] net: Add GSO to vlan_features initialization
From: Ben Hutchings @ 2011-06-24 16:51 UTC (permalink / raw)
To: Shan Wei
Cc: David Miller, netdev, Eric Dumazet, Michał Mirosław,
therbert@google.com
In-Reply-To: <4E0406BE.50900@cn.fujitsu.com>
On Fri, 2011-06-24 at 11:38 +0800, Shan Wei wrote:
> This patch is not a bug fix.
> Just add GSO to vlan_features initialization, and update comments.
>
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
> ---
> net/core/dev.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 6b6ef14..becc1e5 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5478,11 +5478,12 @@ int register_netdevice(struct net_device *dev)
> dev->features |= NETIF_F_NOCACHE_COPY;
> }
>
> - /* Enable GRO and NETIF_F_HIGHDMA for vlans by default,
> - * vlan_dev_init() will do the dev->features check, so these features
> - * are enabled only if supported by underlying device.
> + /* Enable GSO, GRO and NETIF_F_HIGHDMA for vlans by default,
> + * vlan_dev_fix_features() will do the features check,
> + * so NETIF_F_HIGHDMA feature is enabled only if supported
> + * by underlying device.
> */
> - dev->vlan_features |= (NETIF_F_GRO | NETIF_F_HIGHDMA);
> + dev->vlan_features |= (NETIF_F_SOFT_FEATURES | NETIF_F_HIGHDMA);
>
> ret = call_netdevice_notifiers(NETDEV_POST_INIT, dev);
> ret = notifier_to_errno(ret);
Have you verified that GSO works correctly for VLAN devices if the
underlying device does not support VLAN tag insertion?
skb_gso_segment() has code to handle this case, but I suspect it's not
actually being exercised at the moment.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] sctp: Reducing rwnd by sizeof(struct sk_buff) for each CHUNK is too aggressive
From: Thomas Graf @ 2011-06-24 15:53 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: Sridhar Samudrala, linux-sctp, netdev
In-Reply-To: <4E04AB67.1040407@hp.com>
On Fri, Jun 24, 2011 at 11:21:11AM -0400, Vladislav Yasevich wrote:
> First, let me state that I mis-understood what the patch is attempting to do.
> Looking again, I understand this a little better, but still have reservations.
This explains a lot :)
> If we treat the window as strictly available data, then we may end up sending a lot more traffic
> then the window can take thus causing us to enter 0 window probe and potential retransmission
> issues that will trigger congestion control.
> We'd like to avoid that so we put some overhead into our computations. It may not be ideal
> since we do this on a per-chunk basis. It could probably be done on per-packet basis instead.
> This way, we'll essentially over-estimate but under-subscribe our current view of the peers
> window. So in one shot, we are not going to over-fill it and will get an updated view next
> time the SACK arrives.
I will update my patch to include a per packet overhead and also fix the retransmission
rwnd reopening to do the same.
^ permalink raw reply
* SKB paged fragment lifecycle on receive
From: Ian Campbell @ 2011-06-24 15:43 UTC (permalink / raw)
To: netdev, xen-devel; +Cc: Jeremy Fitzhardinge, Rusty Russell
When I was preparing Xen's netback driver for upstream one of the things
I removed was the zero-copy guest transmit (i.e. netback receive)
support.
In this mode guest data pages ("foreign pages") were mapped into the
backend domain (using Xen grant-table functionality) and placed into the
skb's paged frag list (skb_shinfo(skb)->frags, I hope I am using the
right term). Once the page is finished with netback unmaps it in order
to return it to the guest (we really want to avoid returning such pages
to the general allocation pool!). Unfortunately "page is finished with"
is an event which there is no way for the driver to see[0] and therefore
I replaced the grant-mapping with a grant-copy for upstreaming which has
performance and scalability implications (since the copy happens in, and
therefore is accounted to, the backend domain instead of the frontend
domain).
The root of the problem here is that the network stack manipulates the
paged frags using bare get/put_page and therefore has no visibility into
when a page reference count drops to zero and therefore there is no way
to provide an interface for netback to know when it has to tear down the
grant map.
I think this has implications for users other than Xen as well. For
instance I have previously observed an issue where NFS can transmit
bogus data onto the wire due to ACKs which arrive late and cross over
with the queuing of a retransmit on the client side (see
http://marc.info/?l=linux-nfs&m=122424132729720&w=2 which mainly
discusses RPC protocol level retransmit but I subsequently saw similar
issues due to TCP retransmission too). The issue here is that an ACK
from the server which is delayed in the network (but not dropped) can
arrive after a retransmission has been queued. The arrival of this ACK
causes the NFS client to complete the write back to userspace but the
same page is still referenced from the retransmitted skb. Therefore if
userspace reuses the write buffer quickly enough then incorrect data can
go out in the retransmission. Ideally NFS (and I suspect any network
filesystem or block device, e.g. iSCSI, could suffer from this sort of
issue) would be able to wait to complete the write until the buffer was
actually completely finished with.
Someone also suggested the Infiniband might also have an interest in
this sort of thing, although I must admit I don't know enough about IB
to imagine why (perhaps it's just the same as the NFS/iSCSI cases).
We've previously looked into solutions using the skb destructor callback
but that falls over if the skb is cloned since you also need to know
when the clone is destroyed. Jeremy Fitzhardinge and I subsequently
looked at the possibility of a no-clone skb flag (i.e. always forcing a
copy instead of a clone) but IIRC honouring it universally turned into a
very twisty maze with a number of nasty corner cases etc. It also seemed
that the proportion of SKBs which get cloned at least once appeared as
if it could be quite high which would presumably make the performance
impact unacceptable when using the flag. Another issue with using the
skb destructor is that functions such as __pskb_pull_tail will eat (and
free) pages from the start of the frag array such that by the time the
skb destructor is called they are no longer there.
AIUI Rusty Russell had previously looked into a per-page destructor in
the shinfo but found that it couldn't be made to work (I don't remember
why, or if I even knew at the time). Could that be an approach worth
reinvestigating?
I can't really think of any other solution which doesn't involve some
sort of driver callback at the time a page is free()d.
I expect that wrapping the uses of get/put_page in a network specific
wrapper (e.g. skb_{get,frag}_frag(skb, nr) would be a useful first step
in any solution. That's a pretty big task/patch in itself but could be
done. Might it be worthwhile in for its own sake?
Does anyone have any ideas or advice for other approaches I could try
(either on the driver or stack side)?
FWIW I proposed a session on the subject for LPC this year. The proposal
was for the virtualisation track although as I say I think the class of
problem reaches a bit wider than that. Whether the session will be a
discussion around ways of solving the issue or a presentation on the
solution remains to be seen ;-)
Ian.
[0] at least with a mainline kernel, in the older out-of-tree Xen stuff
we had a PageForeign page-flag and a destructor function in a spare
struct page field which was called from the mm free routines
(free_pages_prepare and free_hot_cold_page). I'm under no illusions
about the upstreamability of this approach...
^ permalink raw reply
* [PATCH v2] iwlwifi: use pci_dev->revision, again
From: Sergei Shtylyov @ 2011-06-24 15:39 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w, ilw-VuQAYsv1563Yd54FQh9/CA
Commit ff938e43d39e926de74b32a3656c190f979ab642 (net: use pci_dev->revision,
again) already converted this driver to using the 'revision' field of 'struct
pci_dev' but commit 084dd79172cb3aad11d2b7ee5628d57badca7c6e (iwlagn: move PCI
related operations from probe and remove to PCI layer) has again added the code
to read the PCI revision ID register...
Signed-off-by: Sergei Shtylyov <sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
---
The patch is against the iwlwifi-2.6.git...
drivers/net/wireless/iwlwifi/iwl-pci.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: iwlwifi-2.6/drivers/net/wireless/iwlwifi/iwl-pci.c
===================================================================
--- iwlwifi-2.6.orig/drivers/net/wireless/iwlwifi/iwl-pci.c
+++ iwlwifi-2.6/drivers/net/wireless/iwlwifi/iwl-pci.c
@@ -383,7 +383,6 @@ static int iwl_pci_probe(struct pci_dev
{
struct iwl_cfg *cfg = (struct iwl_cfg *)(ent->driver_data);
struct iwl_pci_bus *bus;
- u8 rev_id;
u16 pci_cmd;
int err;
@@ -440,8 +439,7 @@ static int iwl_pci_probe(struct pci_dev
(unsigned long long) pci_resource_len(pdev, 0));
pr_info("pci_resource_base = %p\n", bus->hw_base);
- pci_read_config_byte(pdev, PCI_REVISION_ID, &rev_id);
- pr_info("HW Revision ID = 0x%X\n", rev_id);
+ pr_info("HW Revision ID = 0x%X\n", pdev->revision);
/* We disable the RETRY_TIMEOUT register (0x41) to keep
* PCI Tx retries from interfering with C3 CPU state */
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: Tree for June 23 (net)
From: Randy Dunlap @ 2011-06-24 15:38 UTC (permalink / raw)
To: David Miller; +Cc: sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20110623.212120.2043173528294538748.davem@davemloft.net>
On 06/23/11 21:21, David Miller wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> Date: Thu, 23 Jun 2011 09:14:29 -0700
>
>> On Thu, 23 Jun 2011 15:54:31 +1000 Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20110622:
>>>
>>> The powerpc allyesconfig (and probably others) is still broken because we
>>> now build the staging drivers and because of a commit in the net tree.
>>> The breakage in Linus' tree is fixed by one of Andrew's patches above.
>>>
>>> The net tree gained 2 build failures that I have left (see above).
>>
>>
>> When CONFIG_INET is not enabled:
>>
>> net/core/dev.c:2535: error: implicit declaration of function 'ip_is_fragment'
>
> I'll fix this like so:
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks.
> diff --git a/include/net/ip.h b/include/net/ip.h
> index d603cd3..9fa9416 100644
> --- a/include/net/ip.h
> +++ b/include/net/ip.h
> @@ -236,6 +236,11 @@ extern void ipfrag_init(void);
>
> extern void ip_static_sysctl_init(void);
>
> +static inline bool ip_is_fragment(const struct iphdr *iph)
> +{
> + return (iph->frag_off & htons(IP_MF | IP_OFFSET)) != 0;
> +}
> +
> #ifdef CONFIG_INET
> #include <net/dst.h>
>
> @@ -250,11 +255,6 @@ int ip_decrease_ttl(struct iphdr *iph)
> return --iph->ttl;
> }
>
> -static inline bool ip_is_fragment(const struct iphdr *iph)
> -{
> - return (iph->frag_off & htons(IP_MF | IP_OFFSET)) != 0;
> -}
> -
> static inline
> int ip_dont_fragment(struct sock *sk, struct dst_entry *dst)
> {
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] sctp: Reducing rwnd by sizeof(struct sk_buff) for each CHUNK is too aggressive
From: Vladislav Yasevich @ 2011-06-24 15:21 UTC (permalink / raw)
To: Sridhar Samudrala, linux-sctp, netdev
In-Reply-To: <20110624144251.GC9222@canuck.infradead.org>
On 06/24/2011 10:42 AM, Thomas Graf wrote:
> On Fri, Jun 24, 2011 at 09:48:51AM -0400, Vladislav Yasevich wrote:
>> I believe there was work in progress to change how window is computed. The issue with
>> your current patch is that it is possible to consume all of the receive buffer space while
>> still having an open receive window. We've seen it in real life which is why the above band-aid
>> was applied.
>
First, let me state that I mis-understood what the patch is attempting to do.
Looking again, I understand this a little better, but still have reservations.
> I don't understand this. The rwnd _announced_ is sk_rcvbuf/2 so we are
> reserving half of sk_rcvbuf for structures like sk_buff. This means we
> can use _all_ of rwnd for data. If the peer announces a a_rwnd of 1500
> in the last SACK I expect that peer to be able to handle 1500 bytes of
> data.
>
> Regardless of that, why would we reserve a sk_buff for each chunk? We only
> allocate an skb per packet which can have many chunks attached.
>
> To me, this looks like a fix for broken sctp peers.
Well, the rwnd announced is what the peer stated it is. All we can do is
try to estimate what it will be when this packet is received.
We, instead of trying to underestimate the window size, try to over-estimate it.
Almost every implementation has some kind of overhead and we don't know how
that overhead will impact the window. As such we try to temporarily account for this
overhead.
If we treat the window as strictly available data, then we may end up sending a lot more traffic
then the window can take thus causing us to enter 0 window probe and potential retransmission
issues that will trigger congestion control.
We'd like to avoid that so we put some overhead into our computations. It may not be ideal
since we do this on a per-chunk basis. It could probably be done on per-packet basis instead.
This way, we'll essentially over-estimate but under-subscribe our current view of the peers
window. So in one shot, we are not going to over-fill it and will get an updated view next
time the SACK arrives.
>
>> The correct patch should really something similar to TCP, where receive window is computed as
>> a percentage of the available receive buffer space at every adjustment. This should also take into
>> account SWS on the sender side.
>
> Can you elaborate this a little more? You want our view of the peer's receive
> window to be computed as a percentage of the available receive buffer on our
> side?
>
As I said, I miss-understood what you were trying to do. Sorry for going off in another direction.
Thanks
-vlad
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: use pci_dev->revision, again
From: wwguy @ 2011-06-24 15:21 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ilw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
In-Reply-To: <4E04A143.1090204-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
On Fri, 2011-06-24 at 07:37 -0700, Sergei Shtylyov wrote:
> Hello.
>
> wwguy wrote:
>
> >>>> Commit ff938e43d39e926de74b32a3656c190f979ab642 (net: use pci_dev->revision,
> >>>> again) already converted this driver to using the 'revision' field of 'struct
> >>>> pci_dev' but commit c2974a1d18832a9fffb2eb389c3878f5c4ed92f1 (iwlagn: remove
> >>>> rev_id) later reverted that change for no reason. Now restore the change...
> >>>> Signed-off-by: Sergei Shtylyov<sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
> >>>> ---
> >>>> The patch is against the recent Linus' tree.
> >>>> drivers/net/wireless/iwlwifi/iwl-agn.c | 5 ++---
> >>>> 1 file changed, 2 insertions(+), 3 deletions(-)
> >>>> Index: linux-2.6/drivers/net/wireless/iwlwifi/iwl-agn.c
> >>>> ===================================================================
> >>>> --- linux-2.6.orig/drivers/net/wireless/iwlwifi/iwl-agn.c
> >>>> +++ linux-2.6/drivers/net/wireless/iwlwifi/iwl-agn.c
> >>>> @@ -3275,10 +3275,9 @@ struct ieee80211_ops iwlagn_hw_ops = {
> >>>>
> >>>> static u32 iwl_hw_detect(struct iwl_priv *priv)
> >>>> {
> >>>> - u8 rev_id;
> >>>> + IWL_DEBUG_INFO(priv, "HW Revision ID = 0x%X\n",
> >>>> + priv->pci_dev->revision);
> >>>>
> >>>> - pci_read_config_byte(priv->pci_dev, PCI_REVISION_ID,&rev_id);
> >>>> - IWL_DEBUG_INFO(priv, "HW Revision ID = 0x%X\n", rev_id);
> >>>> return iwl_read32(priv, CSR_HW_REV);
> >>>> }
>
> >>> hmm, I believe it is merge sequence issue, the IWL_DEBUG_INFO line has
> >>> benn remove all together in later patch. the information is being log in
> >>> the calling function, no need to log in "iwl_hw_detect"
>
> >> Hm, you probably mean this patch in the iwlwifi-2.6.git (of which I wasn't
> >> aware):
>
> >> author Emmanuel Grumbach <emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >> Tue, 31 May 2011 06:58:18 +0000 (09:58 +0300)
> >> committer Wey-Yi Guy <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >> Sat, 18 Jun 2011 15:18:01 +0000 (08:18 -0700)
> >> commit 85aed7c48113dfcdc913008481c46346af0db69e
> >> tree 75831a2ec540039470c295a81c2059a24a4531f5
> >> parent 19707bac16129ccebc398dbff9d2b44b17b24fea
>
> >> iwlagn: don't read the PCI_REVISION_ID from iwl-agn.c
>
> >> The PCI_REVISION_ID is read and printed in iwl_pci_probe anyway using pr_info
>
> >> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> >> Since iwl_pci_probe() still reads the PCI config. register, my patch
> >> should be recast to modify iwl-pci.c instead...
>
> > I don't believe this patch is needed since the "log" statement is move
> > to outside the function.
>
> That's what I'm talking about -- it's not needed in its current form, but I
> will redo the patch to modify iwl-pci,c where iwl_pci_probe() still reads
> PCI_REVISION_ID.
>
ok, thanks
Wey
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* af-packet tpacket_rcv - why is status flushed before the packet-payload ...
From: chetan loke @ 2011-06-24 15:20 UTC (permalink / raw)
To: netdev
Hi,
in tpacket_rcv() - this is the flushing sequence ...
1)
__packet_set_status(po, h.raw, status);
2)
smp_mb();
3)
#if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE == 1
flush-the-payload
#endif
Why is it done this way?
Shouldn't we be flushing the packet_status after flushing the payload?
So 1 and 3 should be swapped, no?
Chetan Loke
^ permalink raw reply
* Re: Skipping past TCP lost packet in userspace
From: Janardhan Iyengar @ 2011-06-24 14:58 UTC (permalink / raw)
To: rick.jones2; +Cc: Josh Lehan, Yuchung Cheng, netdev, Bryan Ford
In-Reply-To: <1306949723.8149.2202.camel@tardy>
[Reviving this thread... apologies for dropping it.]
Rick,
Thanks for your note. I agree that it does seem like we're simply adding to the metaphorical pile. And my first knee-jerk response would be that there's not much else one can do in the modern IPv4 Internet :-)
That said, I'd like to point out that when you say that problems at layer 4 need to be fixed, there are two kinds of changes that can be considered -- the layer 4 protocol, and the API it offers to apps. Changes to the API, which is what we're proposing, is not a modification to the transport layer protocol per se. In other words, we are changing the service that TCP offers to apps, and not the protocol.
The non-portability that you point out in the second part of your note, while a completely legitimate point, is again an API issue. While this API is non-portable because it doesn't exist in other OSes yet, that is a matter of time (hopefully), and we're hoping to start the process with Linux. And, it is easy enough for an app to fail over to using simple TCP behavior where the sockopt is not supported.
You also point out that we could perhaps fix the shortcomings of TCP by actively building and deploying alternative transports -- we've tried that and failed exactly because we've missed the point that the narrow waist of the Internet hourglass is no longer just IP, but includes TCP and UDP as well (and sometimes just TCP.) For the entire time I've been working with SCTP (since 2001), we've been working on and trying to get SCTP through middleboxes, but as it stands, we still only have pockets of success. Try using SCTP in the wild; your packets are quite likely to get black-holed within your home/ISP network. The problem with middleboxes is that the IETF missed the boat on providing standards for these devices, and there are very few (if any) points of pressure that can be applied to change these devices in the network. As a result, getting any new non-network-compatible transport deployed over the network remains untenable.
Our goal is to be able to provide new network services while remaining compatible with the network. As we see it, that is the only option that remains if we are to consider any new transport services beyond TCP's straitjacketed one. As it turns out, our work shows that we _can_ offer more services using the same TCP protocol, which is a win-win, since the new services remain network-compatible.
Note: I'm talking largely about the v4 Internet. The v6 Internet will hopefully have fewer devices that interpose on the transport layer, esp. NAPTs; however, I expect fully that firewalls and PEPs will still use transport layer information, requiring them to be able to read/understand transport header information.
- jana
On 6/1/11 1:35 PM, Rick Jones wrote:
> On Wed, 2011-06-01 at 01:10 -0700, Josh Lehan wrote:
>> On 05/31/2011 10:23 AM, Yuchung Cheng wrote:
>>> This paper may have a solution to your problem
>>> "Minion—an All-Terrain Packet Packhorse to Jump-Start Stalled Internet
>>> Transports"
>>> http://csweb1.fandm.edu/jiyengar/lair/papers/minion-pfldnet2010.pdf
>>
>> Nice, thanks for pointing me to this. I appreciate the helpful answer,
>> instead of just saying "use UDP" or "use SCTP". That's not the point.
>>
>> For better or for worse, TCP is realistically the only viable protocol
>> for streaming to the largest possible audience these days, hence my
>> question about adding this feature to the Linux TCP implementation.
>
> Isn't that treating the symptoms of problems at layers 8 and 9 (*) with
> kludges (perhaps hacks if one is feeling charitable) at the user
> interface to layer 4? Just how many more little bits can we add to the
> great pile before the aroma is overpowering? Or to abuse another
> metaphor, is there really any camel's back left here?
>
> And while Linux has had some slightly non-trivial, non-portable
> enhancements to its interface to a TCP endpoint (TCP_CORK is something
> that comes to mind) I don't think any of them have been anywhere nearly
> as large a change to a fundamental semantic of a TCP connection as what
> you propose.
>
> rick jones
>
> *
> http://www.isc.org/store/logoware-clothing/isc-9-layer-osi-model-cotton-t-shirt
>
>
--
Janardhan Iyengar
Assistant Professor, Computer Science
Franklin & Marshall College
http://www.fandm.edu/jiyengar
^ permalink raw reply
* Re: [PATCH] sctp: Reducing rwnd by sizeof(struct sk_buff) for each CHUNK is too aggressive
From: Thomas Graf @ 2011-06-24 14:42 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: Sridhar Samudrala, linux-sctp, netdev
In-Reply-To: <4E0495C3.30102@hp.com>
On Fri, Jun 24, 2011 at 09:48:51AM -0400, Vladislav Yasevich wrote:
> I believe there was work in progress to change how window is computed. The issue with
> your current patch is that it is possible to consume all of the receive buffer space while
> still having an open receive window. We've seen it in real life which is why the above band-aid
> was applied.
I don't understand this. The rwnd _announced_ is sk_rcvbuf/2 so we are
reserving half of sk_rcvbuf for structures like sk_buff. This means we
can use _all_ of rwnd for data. If the peer announces a a_rwnd of 1500
in the last SACK I expect that peer to be able to handle 1500 bytes of
data.
Regardless of that, why would we reserve a sk_buff for each chunk? We only
allocate an skb per packet which can have many chunks attached.
To me, this looks like a fix for broken sctp peers.
> The correct patch should really something similar to TCP, where receive window is computed as
> a percentage of the available receive buffer space at every adjustment. This should also take into
> account SWS on the sender side.
Can you elaborate this a little more? You want our view of the peer's receive
window to be computed as a percentage of the available receive buffer on our
side?
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: use pci_dev->revision, again
From: Sergei Shtylyov @ 2011-06-24 14:37 UTC (permalink / raw)
To: wwguy
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ilw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
In-Reply-To: <1308924515.19001.2.camel@wwguy-ubuntu>
Hello.
wwguy wrote:
>>>> Commit ff938e43d39e926de74b32a3656c190f979ab642 (net: use pci_dev->revision,
>>>> again) already converted this driver to using the 'revision' field of 'struct
>>>> pci_dev' but commit c2974a1d18832a9fffb2eb389c3878f5c4ed92f1 (iwlagn: remove
>>>> rev_id) later reverted that change for no reason. Now restore the change...
>>>> Signed-off-by: Sergei Shtylyov<sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
>>>> ---
>>>> The patch is against the recent Linus' tree.
>>>> drivers/net/wireless/iwlwifi/iwl-agn.c | 5 ++---
>>>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>>> Index: linux-2.6/drivers/net/wireless/iwlwifi/iwl-agn.c
>>>> ===================================================================
>>>> --- linux-2.6.orig/drivers/net/wireless/iwlwifi/iwl-agn.c
>>>> +++ linux-2.6/drivers/net/wireless/iwlwifi/iwl-agn.c
>>>> @@ -3275,10 +3275,9 @@ struct ieee80211_ops iwlagn_hw_ops = {
>>>>
>>>> static u32 iwl_hw_detect(struct iwl_priv *priv)
>>>> {
>>>> - u8 rev_id;
>>>> + IWL_DEBUG_INFO(priv, "HW Revision ID = 0x%X\n",
>>>> + priv->pci_dev->revision);
>>>>
>>>> - pci_read_config_byte(priv->pci_dev, PCI_REVISION_ID,&rev_id);
>>>> - IWL_DEBUG_INFO(priv, "HW Revision ID = 0x%X\n", rev_id);
>>>> return iwl_read32(priv, CSR_HW_REV);
>>>> }
>>> hmm, I believe it is merge sequence issue, the IWL_DEBUG_INFO line has
>>> benn remove all together in later patch. the information is being log in
>>> the calling function, no need to log in "iwl_hw_detect"
>> Hm, you probably mean this patch in the iwlwifi-2.6.git (of which I wasn't
>> aware):
>> author Emmanuel Grumbach <emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Tue, 31 May 2011 06:58:18 +0000 (09:58 +0300)
>> committer Wey-Yi Guy <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Sat, 18 Jun 2011 15:18:01 +0000 (08:18 -0700)
>> commit 85aed7c48113dfcdc913008481c46346af0db69e
>> tree 75831a2ec540039470c295a81c2059a24a4531f5
>> parent 19707bac16129ccebc398dbff9d2b44b17b24fea
>> iwlagn: don't read the PCI_REVISION_ID from iwl-agn.c
>> The PCI_REVISION_ID is read and printed in iwl_pci_probe anyway using pr_info
>> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Since iwl_pci_probe() still reads the PCI config. register, my patch
>> should be recast to modify iwl-pci.c instead...
> I don't believe this patch is needed since the "log" statement is move
> to outside the function.
That's what I'm talking about -- it's not needed in its current form, but I
will redo the patch to modify iwl-pci,c where iwl_pci_probe() still reads
PCI_REVISION_ID.
> Thanks
> Wey
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH]: Add Network Sysrq Support
From: John Haxby @ 2011-06-24 14:37 UTC (permalink / raw)
To: Florian Westphal
Cc: Prarit Bhargava, David Miller, fbl, netdev, agospoda, nhorman,
lwoodman
In-Reply-To: <20110622105434.GE16021@Chamillionaire.breakpoint.cc>
On 22/06/11 11:54, Florian Westphal wrote:
> Patrick McHardy suggested an alternative standalone method involving
> encapsulation sockets; perhaps the reasons why this path was not chosen
> have changed.
>
> I think that a standalone module (i.e. not requiring netfilter) that
> runs the sysreq handling after all netfilter hooks would be optimal,
> but I don't see a simple method to implement that.
Having just read the entire thread I have some different comments.
I think I mentioned that the standalone module didn't fly because I was
using an encapsulation socket: this preserved the ability to protect the
sysrq with iptables and also kept things nice and simple. Unfortunately
that also meant I lost IPv6 ....
One of the comments in the thread (sorry, I've lost the attribution, not
to mention the exact quote) was that you would be crazy to run this in
production. Hmmm. One of the principle use cases of this is
precisely to run the code in production: machines in production do go
AWOL for all kinds of reasons and being able to run sysrq-m, t, s and c
is particularly useful. It would be nice to be able to go up to the
machine and type on its keyboard. If only it was even on the same
continent. If only it a keyboard. Or even a PS/2 keyboard socket
(getting a USB keyboard to configure itself when the machine is wedged
is, well, unlikely).
The changes I made to the xt_SYSRQ hashing a while back to avoid things
like replay were precisely because it needs to be run in a production
environment. I've just submitted a patch that makes replay to other
machines that have the same password less likely to succeed, again, with
a view to how this thing would be used in production.
Sorry if I've repeated some things that have already been said.
jch
^ permalink raw reply
* [PATCH 2/2] can: bfin_can: auto-calculate accessor sizes
From: Mike Frysinger @ 2011-06-24 14:33 UTC (permalink / raw)
To: socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Wolfgang Grandegger,
netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller
Cc: uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <1308925982-14645-1-git-send-email-vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
Since we have a struct that defines the sizes of the registers, we don't
need to explicitly use the 16bit read/write helpers. Let the code figure
out which size access to make based on the size of the C type.
There should be no functional changes here.
Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
---
drivers/net/can/bfin_can.c | 118 ++++++++++++++++++++++----------------------
1 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/drivers/net/can/bfin_can.c b/drivers/net/can/bfin_can.c
index dc6ef4a..a1c5abc 100644
--- a/drivers/net/can/bfin_can.c
+++ b/drivers/net/can/bfin_can.c
@@ -79,8 +79,8 @@ static int bfin_can_set_bittiming(struct net_device *dev)
if (priv->can.ctrlmode & CAN_CTRLMODE_3_SAMPLES)
timing |= SAM;
- bfin_write16(®->clock, clk);
- bfin_write16(®->timing, timing);
+ bfin_write(®->clock, clk);
+ bfin_write(®->timing, timing);
dev_info(dev->dev.parent, "setting CLOCK=0x%04x TIMING=0x%04x\n",
clk, timing);
@@ -96,16 +96,16 @@ static void bfin_can_set_reset_mode(struct net_device *dev)
int i;
/* disable interrupts */
- bfin_write16(®->mbim1, 0);
- bfin_write16(®->mbim2, 0);
- bfin_write16(®->gim, 0);
+ bfin_write(®->mbim1, 0);
+ bfin_write(®->mbim2, 0);
+ bfin_write(®->gim, 0);
/* reset can and enter configuration mode */
- bfin_write16(®->control, SRS | CCR);
+ bfin_write(®->control, SRS | CCR);
SSYNC();
- bfin_write16(®->control, CCR);
+ bfin_write(®->control, CCR);
SSYNC();
- while (!(bfin_read16(®->control) & CCA)) {
+ while (!(bfin_read(®->control) & CCA)) {
udelay(10);
if (--timeout == 0) {
dev_err(dev->dev.parent,
@@ -119,33 +119,33 @@ static void bfin_can_set_reset_mode(struct net_device *dev)
* by writing to CAN Mailbox Configuration Registers 1 and 2
* For all bits: 0 - Mailbox disabled, 1 - Mailbox enabled
*/
- bfin_write16(®->mc1, 0);
- bfin_write16(®->mc2, 0);
+ bfin_write(®->mc1, 0);
+ bfin_write(®->mc2, 0);
/* Set Mailbox Direction */
- bfin_write16(®->md1, 0xFFFF); /* mailbox 1-16 are RX */
- bfin_write16(®->md2, 0); /* mailbox 17-32 are TX */
+ bfin_write(®->md1, 0xFFFF); /* mailbox 1-16 are RX */
+ bfin_write(®->md2, 0); /* mailbox 17-32 are TX */
/* RECEIVE_STD_CHL */
for (i = 0; i < 2; i++) {
- bfin_write16(®->chl[RECEIVE_STD_CHL + i].id0, 0);
- bfin_write16(®->chl[RECEIVE_STD_CHL + i].id1, AME);
- bfin_write16(®->chl[RECEIVE_STD_CHL + i].dlc, 0);
- bfin_write16(®->msk[RECEIVE_STD_CHL + i].amh, 0x1FFF);
- bfin_write16(®->msk[RECEIVE_STD_CHL + i].aml, 0xFFFF);
+ bfin_write(®->chl[RECEIVE_STD_CHL + i].id0, 0);
+ bfin_write(®->chl[RECEIVE_STD_CHL + i].id1, AME);
+ bfin_write(®->chl[RECEIVE_STD_CHL + i].dlc, 0);
+ bfin_write(®->msk[RECEIVE_STD_CHL + i].amh, 0x1FFF);
+ bfin_write(®->msk[RECEIVE_STD_CHL + i].aml, 0xFFFF);
}
/* RECEIVE_EXT_CHL */
for (i = 0; i < 2; i++) {
- bfin_write16(®->chl[RECEIVE_EXT_CHL + i].id0, 0);
- bfin_write16(®->chl[RECEIVE_EXT_CHL + i].id1, AME | IDE);
- bfin_write16(®->chl[RECEIVE_EXT_CHL + i].dlc, 0);
- bfin_write16(®->msk[RECEIVE_EXT_CHL + i].amh, 0x1FFF);
- bfin_write16(®->msk[RECEIVE_EXT_CHL + i].aml, 0xFFFF);
+ bfin_write(®->chl[RECEIVE_EXT_CHL + i].id0, 0);
+ bfin_write(®->chl[RECEIVE_EXT_CHL + i].id1, AME | IDE);
+ bfin_write(®->chl[RECEIVE_EXT_CHL + i].dlc, 0);
+ bfin_write(®->msk[RECEIVE_EXT_CHL + i].amh, 0x1FFF);
+ bfin_write(®->msk[RECEIVE_EXT_CHL + i].aml, 0xFFFF);
}
- bfin_write16(®->mc2, BIT(TRANSMIT_CHL - 16));
- bfin_write16(®->mc1, BIT(RECEIVE_STD_CHL) + BIT(RECEIVE_EXT_CHL));
+ bfin_write(®->mc2, BIT(TRANSMIT_CHL - 16));
+ bfin_write(®->mc1, BIT(RECEIVE_STD_CHL) + BIT(RECEIVE_EXT_CHL));
SSYNC();
priv->can.state = CAN_STATE_STOPPED;
@@ -160,9 +160,9 @@ static void bfin_can_set_normal_mode(struct net_device *dev)
/*
* leave configuration mode
*/
- bfin_write16(®->control, bfin_read16(®->control) & ~CCR);
+ bfin_write(®->control, bfin_read(®->control) & ~CCR);
- while (bfin_read16(®->status) & CCA) {
+ while (bfin_read(®->status) & CCA) {
udelay(10);
if (--timeout == 0) {
dev_err(dev->dev.parent,
@@ -174,25 +174,25 @@ static void bfin_can_set_normal_mode(struct net_device *dev)
/*
* clear _All_ tx and rx interrupts
*/
- bfin_write16(®->mbtif1, 0xFFFF);
- bfin_write16(®->mbtif2, 0xFFFF);
- bfin_write16(®->mbrif1, 0xFFFF);
- bfin_write16(®->mbrif2, 0xFFFF);
+ bfin_write(®->mbtif1, 0xFFFF);
+ bfin_write(®->mbtif2, 0xFFFF);
+ bfin_write(®->mbrif1, 0xFFFF);
+ bfin_write(®->mbrif2, 0xFFFF);
/*
* clear global interrupt status register
*/
- bfin_write16(®->gis, 0x7FF); /* overwrites with '1' */
+ bfin_write(®->gis, 0x7FF); /* overwrites with '1' */
/*
* Initialize Interrupts
* - set bits in the mailbox interrupt mask register
* - global interrupt mask
*/
- bfin_write16(®->mbim1, BIT(RECEIVE_STD_CHL) + BIT(RECEIVE_EXT_CHL));
- bfin_write16(®->mbim2, BIT(TRANSMIT_CHL - 16));
+ bfin_write(®->mbim1, BIT(RECEIVE_STD_CHL) + BIT(RECEIVE_EXT_CHL));
+ bfin_write(®->mbim2, BIT(TRANSMIT_CHL - 16));
- bfin_write16(®->gim, EPIM | BOIM | RMLIM);
+ bfin_write(®->gim, EPIM | BOIM | RMLIM);
SSYNC();
}
@@ -242,28 +242,28 @@ static int bfin_can_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* fill id */
if (id & CAN_EFF_FLAG) {
- bfin_write16(®->chl[TRANSMIT_CHL].id0, id);
+ bfin_write(®->chl[TRANSMIT_CHL].id0, id);
val = ((id & 0x1FFF0000) >> 16) | IDE;
} else
val = (id << 2);
if (id & CAN_RTR_FLAG)
val |= RTR;
- bfin_write16(®->chl[TRANSMIT_CHL].id1, val | AME);
+ bfin_write(®->chl[TRANSMIT_CHL].id1, val | AME);
/* fill payload */
for (i = 0; i < 8; i += 2) {
val = ((7 - i) < dlc ? (data[7 - i]) : 0) +
((6 - i) < dlc ? (data[6 - i] << 8) : 0);
- bfin_write16(®->chl[TRANSMIT_CHL].data[i], val);
+ bfin_write(®->chl[TRANSMIT_CHL].data[i], val);
}
/* fill data length code */
- bfin_write16(®->chl[TRANSMIT_CHL].dlc, dlc);
+ bfin_write(®->chl[TRANSMIT_CHL].dlc, dlc);
can_put_echo_skb(skb, dev, 0);
/* set transmit request */
- bfin_write16(®->trs2, BIT(TRANSMIT_CHL - 16));
+ bfin_write(®->trs2, BIT(TRANSMIT_CHL - 16));
return 0;
}
@@ -286,26 +286,26 @@ static void bfin_can_rx(struct net_device *dev, u16 isrc)
/* get id */
if (isrc & BIT(RECEIVE_EXT_CHL)) {
/* extended frame format (EFF) */
- cf->can_id = ((bfin_read16(®->chl[RECEIVE_EXT_CHL].id1)
+ cf->can_id = ((bfin_read(®->chl[RECEIVE_EXT_CHL].id1)
& 0x1FFF) << 16)
- + bfin_read16(®->chl[RECEIVE_EXT_CHL].id0);
+ + bfin_read(®->chl[RECEIVE_EXT_CHL].id0);
cf->can_id |= CAN_EFF_FLAG;
obj = RECEIVE_EXT_CHL;
} else {
/* standard frame format (SFF) */
- cf->can_id = (bfin_read16(®->chl[RECEIVE_STD_CHL].id1)
+ cf->can_id = (bfin_read(®->chl[RECEIVE_STD_CHL].id1)
& 0x1ffc) >> 2;
obj = RECEIVE_STD_CHL;
}
- if (bfin_read16(®->chl[obj].id1) & RTR)
+ if (bfin_read(®->chl[obj].id1) & RTR)
cf->can_id |= CAN_RTR_FLAG;
/* get data length code */
- cf->can_dlc = get_can_dlc(bfin_read16(®->chl[obj].dlc) & 0xF);
+ cf->can_dlc = get_can_dlc(bfin_read(®->chl[obj].dlc) & 0xF);
/* get payload */
for (i = 0; i < 8; i += 2) {
- val = bfin_read16(®->chl[obj].data[i]);
+ val = bfin_read(®->chl[obj].data[i]);
cf->data[7 - i] = (7 - i) < cf->can_dlc ? val : 0;
cf->data[6 - i] = (6 - i) < cf->can_dlc ? (val >> 8) : 0;
}
@@ -359,7 +359,7 @@ static int bfin_can_err(struct net_device *dev, u16 isrc, u16 status)
if (state != priv->can.state && (state == CAN_STATE_ERROR_WARNING ||
state == CAN_STATE_ERROR_PASSIVE)) {
- u16 cec = bfin_read16(®->cec);
+ u16 cec = bfin_read(®->cec);
u8 rxerr = cec;
u8 txerr = cec >> 8;
@@ -410,23 +410,23 @@ irqreturn_t bfin_can_interrupt(int irq, void *dev_id)
struct net_device_stats *stats = &dev->stats;
u16 status, isrc;
- if ((irq == priv->tx_irq) && bfin_read16(®->mbtif2)) {
+ if ((irq == priv->tx_irq) && bfin_read(®->mbtif2)) {
/* transmission complete interrupt */
- bfin_write16(®->mbtif2, 0xFFFF);
+ bfin_write(®->mbtif2, 0xFFFF);
stats->tx_packets++;
- stats->tx_bytes += bfin_read16(®->chl[TRANSMIT_CHL].dlc);
+ stats->tx_bytes += bfin_read(®->chl[TRANSMIT_CHL].dlc);
can_get_echo_skb(dev, 0);
netif_wake_queue(dev);
- } else if ((irq == priv->rx_irq) && bfin_read16(®->mbrif1)) {
+ } else if ((irq == priv->rx_irq) && bfin_read(®->mbrif1)) {
/* receive interrupt */
- isrc = bfin_read16(®->mbrif1);
- bfin_write16(®->mbrif1, 0xFFFF);
+ isrc = bfin_read(®->mbrif1);
+ bfin_write(®->mbrif1, 0xFFFF);
bfin_can_rx(dev, isrc);
- } else if ((irq == priv->err_irq) && bfin_read16(®->gis)) {
+ } else if ((irq == priv->err_irq) && bfin_read(®->gis)) {
/* error interrupt */
- isrc = bfin_read16(®->gis);
- status = bfin_read16(®->esr);
- bfin_write16(®->gis, 0x7FF);
+ isrc = bfin_read(®->gis);
+ status = bfin_read(®->esr);
+ bfin_write(®->gis, 0x7FF);
bfin_can_err(dev, isrc, status);
} else {
return IRQ_NONE;
@@ -631,9 +631,9 @@ static int bfin_can_suspend(struct platform_device *pdev, pm_message_t mesg)
if (netif_running(dev)) {
/* enter sleep mode */
- bfin_write16(®->control, bfin_read16(®->control) | SMR);
+ bfin_write(®->control, bfin_read(®->control) | SMR);
SSYNC();
- while (!(bfin_read16(®->intr) & SMACK)) {
+ while (!(bfin_read(®->intr) & SMACK)) {
udelay(10);
if (--timeout == 0) {
dev_err(dev->dev.parent,
@@ -654,7 +654,7 @@ static int bfin_can_resume(struct platform_device *pdev)
if (netif_running(dev)) {
/* leave sleep mode */
- bfin_write16(®->intr, 0);
+ bfin_write(®->intr, 0);
SSYNC();
}
--
1.7.5.3
^ permalink raw reply related
* [PATCH 1/2] can: bfin_can: simplify xmit id1 setup
From: Mike Frysinger @ 2011-06-24 14:33 UTC (permalink / raw)
To: socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Wolfgang Grandegger,
netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller
Cc: uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
If we look closely, the 4 writes to TRANSMIT_CHL.id1 can be collapsed
down into much simpler code. So do just that.
This also fixes a build failure due to the I/O macros no longer
getting pulled in. Their minor (and accidental) usage here gets
dropped as part of the unification.
Signed-off-by: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
---
drivers/net/can/bfin_can.c | 21 ++++++---------------
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/net/can/bfin_can.c b/drivers/net/can/bfin_can.c
index b6e890d..dc6ef4a 100644
--- a/drivers/net/can/bfin_can.c
+++ b/drivers/net/can/bfin_can.c
@@ -243,21 +243,12 @@ static int bfin_can_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* fill id */
if (id & CAN_EFF_FLAG) {
bfin_write16(®->chl[TRANSMIT_CHL].id0, id);
- if (id & CAN_RTR_FLAG)
- writew(((id & 0x1FFF0000) >> 16) | IDE | AME | RTR,
- ®->chl[TRANSMIT_CHL].id1);
- else
- writew(((id & 0x1FFF0000) >> 16) | IDE | AME,
- ®->chl[TRANSMIT_CHL].id1);
-
- } else {
- if (id & CAN_RTR_FLAG)
- writew((id << 2) | AME | RTR,
- ®->chl[TRANSMIT_CHL].id1);
- else
- bfin_write16(®->chl[TRANSMIT_CHL].id1,
- (id << 2) | AME);
- }
+ val = ((id & 0x1FFF0000) >> 16) | IDE;
+ } else
+ val = (id << 2);
+ if (id & CAN_RTR_FLAG)
+ val |= RTR;
+ bfin_write16(®->chl[TRANSMIT_CHL].id1, val | AME);
/* fill payload */
for (i = 0; i < 8; i += 2) {
--
1.7.5.3
^ permalink raw reply related
* Re: [uclinux-dist-devel] [PATCH 1/2] can: bfin_can: simplify xmit id1 setup
From: Mike Frysinger @ 2011-06-24 14:32 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Urs Thuermann, David S. Miller,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <4E046AFE.5000109-l29pVbxQd1IUtdQbppsyvg@public.gmane.org>
On Fri, Jun 24, 2011 at 06:46, Oliver Hartkopp wrote:
> In MAINTAINERS there are entries for the CAN NETWORK LAYER and for CAN
> NETWORK DRIVERS which addresses the code in drivers/net/can/...
hmm, wonder when this changed. oh well, updated local .git/mail now.
> Additionally you should address your patch to the author of the driver
> (Barry Song <21cnbao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>).
he's already in the cc list. he's an ADI employee (like me) who
watches the Blackfin mailing lists.
-mike
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: mark socketcan-core lists as subscribers-only
From: Mike Frysinger @ 2011-06-24 14:28 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Urs Thuermann, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Oliver Hartkopp,
Andrew Morton, David S. Miller
In-Reply-To: <4E044F4B.7010707-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Fri, Jun 24, 2011 at 04:48, Marc Kleine-Budde wrote:
> On 06/24/2011 02:25 AM, Mike Frysinger wrote:
>> The socketcan-core lists require subscription, so mark them as such.
>
> what about making this list open instead?
i have no problem with that, but i have nothing to do with the
socket-can project, so it isnt my call.
-mike
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: use pci_dev->revision, again
From: wwguy @ 2011-06-24 14:08 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ilw-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
In-Reply-To: <4E046A9F.9020909-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
On Fri, 2011-06-24 at 03:44 -0700, Sergei Shtylyov wrote:
> Hello.
>
> On 23-06-2011 19:02, Guy, Wey-Yi wrote:
>
> >> Commit ff938e43d39e926de74b32a3656c190f979ab642 (net: use pci_dev->revision,
> >> again) already converted this driver to using the 'revision' field of 'struct
> >> pci_dev' but commit c2974a1d18832a9fffb2eb389c3878f5c4ed92f1 (iwlagn: remove
> >> rev_id) later reverted that change for no reason. Now restore the change...
>
> >> Signed-off-by: Sergei Shtylyov<sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
>
> >> ---
> >> The patch is against the recent Linus' tree.
>
> >> drivers/net/wireless/iwlwifi/iwl-agn.c | 5 ++---
> >> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> >> Index: linux-2.6/drivers/net/wireless/iwlwifi/iwl-agn.c
> >> ===================================================================
> >> --- linux-2.6.orig/drivers/net/wireless/iwlwifi/iwl-agn.c
> >> +++ linux-2.6/drivers/net/wireless/iwlwifi/iwl-agn.c
> >> @@ -3275,10 +3275,9 @@ struct ieee80211_ops iwlagn_hw_ops = {
> >>
> >> static u32 iwl_hw_detect(struct iwl_priv *priv)
> >> {
> >> - u8 rev_id;
> >> + IWL_DEBUG_INFO(priv, "HW Revision ID = 0x%X\n",
> >> + priv->pci_dev->revision);
> >>
> >> - pci_read_config_byte(priv->pci_dev, PCI_REVISION_ID,&rev_id);
> >> - IWL_DEBUG_INFO(priv, "HW Revision ID = 0x%X\n", rev_id);
> >> return iwl_read32(priv, CSR_HW_REV);
> >> }
>
> > hmm, I believe it is merge sequence issue, the IWL_DEBUG_INFO line has
> > benn remove all together in later patch. the information is being log in
> > the calling function, no need to log in "iwl_hw_detect"
>
> Hm, you probably mean this patch in the iwlwifi-2.6.git (of which I wasn't
> aware):
>
> author Emmanuel Grumbach <emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Tue, 31 May 2011 06:58:18 +0000 (09:58 +0300)
> committer Wey-Yi Guy <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Sat, 18 Jun 2011 15:18:01 +0000 (08:18 -0700)
> commit 85aed7c48113dfcdc913008481c46346af0db69e
> tree 75831a2ec540039470c295a81c2059a24a4531f5
> parent 19707bac16129ccebc398dbff9d2b44b17b24fea
>
> iwlagn: don't read the PCI_REVISION_ID from iwl-agn.c
>
> The PCI_REVISION_ID is read and printed in iwl_pci_probe anyway using pr_info
>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> Since iwl_pci_probe() still reads the PCI config. register, my patch
> should be recast to modify iwl-pci.c instead...
>
> >
I don't believe this patch is needed since the "log" statement is move
to outside the function.
Thanks
Wey
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ppp_deflate + kmalloc
From: James Carlson @ 2011-06-24 14:02 UTC (permalink / raw)
To: Martin Jackson; +Cc: paulus, linux-ppp, netdev
In-Reply-To: <BANLkTi=+2dqr1LPwG8MHpcYOyzJH57iavw@mail.gmail.com>
Martin Jackson wrote:
> In our android froyo-based system (omap3 hardware), we are getting the
> following problem where the ppp driver cannot kmalloc enough memory
> for the decomp buffer in the ppp driver.
>
> Trying to make a 4th-order kmalloc (I think that amounts to 64kB)
> seems ambitious. I do not understand why vmalloc is not being used
> here, like it is for the compression buffer. Is using vmalloc here an
> acceptable solution?
The code here shouldn't need contiguous pages, so vmalloc (even if
"slower") shouldn't be a problem.
But a higher-level question might be why you're bothering with RFC 1979
Deflate compression at all on this platform. I'd expect that you're
most likely going to end up talking to commercially-produced PPP servers
(possibly 3GPP or similar) at the other end, and very, very few of them
offer data compression with either RFC 1977 (BSD Compression) or RFC
1979. ("Very, very few" is probably being generous ...)
If it's always going to be negotiated away in practice, and if you're
having trouble with memory constraints, why not just ditch the baggage?
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
^ permalink raw reply
* Re: [PATCH] sctp: Reducing rwnd by sizeof(struct sk_buff) for each CHUNK is too aggressive
From: Vladislav Yasevich @ 2011-06-24 13:48 UTC (permalink / raw)
To: Sridhar Samudrala, linux-sctp, netdev
In-Reply-To: <20110624101535.GB9222@canuck.infradead.org>
On 06/24/2011 06:15 AM, Thomas Graf wrote:
> Currently we subtract sizeof(struct sk_buff) of our view of the
> receiver's rwnd for each DATA chunk appended to a sctp packet.
> Reducing the rwnd by >200 bytes for each DATA chunk quickly
> consumes the available window and prevents max MTU sized packets
> (for large MTU values) from being generated in combination with
> small DATA chunks. The sender has to wait for the next SACK to
> be processed for the rwnd to be corrected.
>
> Accounting for data structures required for rx is the responsibility
> of the stack which is why we announce a rwnd of sk_rcvbuf/2.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
>
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index b4f3cf0..ceb55b2 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -700,13 +700,7 @@ static void sctp_packet_append_data(struct sctp_packet *packet,
> /* Keep track of how many bytes are in flight to the receiver. */
> asoc->outqueue.outstanding_bytes += datasize;
>
> - /* Update our view of the receiver's rwnd. Include sk_buff overhead
> - * while updating peer.rwnd so that it reduces the chances of a
> - * receiver running out of receive buffer space even when receive
> - * window is still open. This can happen when a sender is sending
> - * sending small messages.
> - */
> - datasize += sizeof(struct sk_buff);
> + /* Update our view of the receiver's rwnd. */
> if (datasize < rwnd)
> rwnd -= datasize;
> else
>
Hi Thomas
I believe there was work in progress to change how window is computed. The issue with
your current patch is that it is possible to consume all of the receive buffer space while
still having an open receive window. We've seen it in real life which is why the above band-aid
was applied.
The correct patch should really something similar to TCP, where receive window is computed as
a percentage of the available receive buffer space at every adjustment. This should also take into
account SWS on the sender side.
Someone started implementing that code, but I am not sure where it currently is.
Thanks
-vlad
^ permalink raw reply
* ppp_deflate + kmalloc
From: Martin Jackson @ 2011-06-24 13:41 UTC (permalink / raw)
To: paulus; +Cc: linux-ppp, netdev
Hi,
In our android froyo-based system (omap3 hardware), we are getting the
following problem where the ppp driver cannot kmalloc enough memory
for the decomp buffer in the ppp driver.
Trying to make a 4th-order kmalloc (I think that amounts to 64kB)
seems ambitious. I do not understand why vmalloc is not being used
here, like it is for the compression buffer. Is using vmalloc here an
acceptable solution?
pppd: page allocation failure. order:4, mode:0x44d0
[<c016bc10>] (unwind_backtrace+0x0/0xdc) from [<c01fea80>]
(__alloc_pages_nodemask+0x4c4/0x5a4)
[<c01fea80>] (__alloc_pages_nodemask+0x4c4/0x5a4) from [<c01feb70>]
(__get_free_pages+0x10/0x3c)
[<c01feb70>] (__get_free_pages+0x10/0x3c) from [<c021cc24>]
(__kmalloc+0x3c/0x220)
[<c021cc24>] (__kmalloc+0x3c/0x220) from [<c03519d8>]
(z_decomp_alloc+0x120/0x164)
[<c03519d8>] (z_decomp_alloc+0x120/0x164) from [<c034de14>]
(ppp_ioctl+0xae4/0xf18)
[<c034de14>] (ppp_ioctl+0xae4/0xf18) from [<c022cd3c>] (vfs_ioctl+0x2c/0x8c)
[<c022cd3c>] (vfs_ioctl+0x2c/0x8c) from [<c022d3e8>] (do_vfs_ioctl+0x55c/0x5a0)
[<c022d3e8>] (do_vfs_ioctl+0x55c/0x5a0) from [<c022d478>] (sys_ioctl+0x4c/0x6c)
[<c022d478>] (sys_ioctl+0x4c/0x6c) from [<c0166f80>] (ret_fast_syscall+0x0/0x38)
Mem-info:
Normal per-cpu:
CPU 0: hi: 90, btch: 15 usd: 0
active_anon:6829 inactive_anon:6914 isolated_anon:0
active_file:14397 inactive_file:14438 isolated_file:0
unevictable:0 dirty:12 writeback:0 unstable:0
free:901 slab_reclaimable:1040 slab_unreclaimable:1117
mapped:12160 shmem:64 pagetables:1576 bounce:0
Normal free:3604kB min:2036kB low:2544kB high:3052kB
active_anon:27316kB inactive_anon:27656kB active_file:57588kB
inactive_file:57752kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:260096kB mlocked:0kB dirty:48kB
writeback:0kB mapped:48640kB shmem:256kB slab_reclaimable:4160kB
slab_unreclaimable:4468kB kernel_stack:2128kB pagetables:6304kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 359*4kB 183*8kB 42*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 3604kB
28899 total pagecache pages
65536 pages of RAM
1299 free pages
13785 reserved pages
1482 slab pages
89904 pages shared
0 pages swap cached
This is how I worked around it.
--- a/drivers/net/ppp_deflate.c
+++ b/drivers/net/ppp_deflate.c
@@ -305,7 +305,7 @@ static void z_decomp_free(void *arg)
if (state) {
zlib_inflateEnd(&state->strm);
- kfree(state->strm.workspace);
+ vfree(state->strm.workspace);
kfree(state);
}
}
@@ -345,8 +345,7 @@ static void *z_decomp_alloc(unsigned char
*options, int opt_len)
state->w_size = w_size;
state->strm.next_out = NULL;
- state->strm.workspace = kmalloc(zlib_inflate_workspacesize(),
- GFP_KERNEL|__GFP_REPEAT);
+ state->strm.workspace = vmalloc(zlib_inflate_workspacesize());
if (state->strm.workspace == NULL)
goto out_free;
Best regards,
Martin Jackson
^ 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