* Re: [net-next-2.6 PATCH 20/20] ixgbe: rewrite ethtool test to use standard config functions
From: David Miller @ 2010-08-19 23:47 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, alexander.h.duyck
In-Reply-To: <20100819234052.10335.57519.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 19 Aug 2010 16:40:54 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change makes it so that the ethtool loopback test uses the standard
> ring configuration and allocation functions. As a result the loopback test
> will be much more effective at testing core driver functionality.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH NEXT 0/12]qlcnic: driver update
From: David Miller @ 2010-08-19 23:53 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1282230513-25286-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Thu, 19 Aug 2010 08:08:21 -0700
> Series of 12 patches to configure eswitch features and driver updates.
All applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-08-19
From: David Miller @ 2010-08-19 23:59 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100819174638.GC2672-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Thu, 19 Aug 2010 13:46:38 -0400
> This collection of fixes intended for 2.6.36 includes a few that look
> bigger than they really are. The one from Joe Perches corrects a number
> of inadvertant upper->lower case conversion from an earlier patch
> already in 2.6.36. The ones from Wey-Yi Guy change a timer value in a
> number of device-dependent data structures in order to avoid excessive
> firmware resets for those devices.
>
> In addition to those, the one from Johannes Berg gives iwl3945 its own
> filter flag function since sharing the iwlagn version has created
> regressions for iwl3945. The one from me corrects a DMA API misuse in
> ipw2100 that results in warning backtraces.
>
> Please let me know if there are problems!
Pulled, thanks.
--
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: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel
From: David Miller @ 2010-08-20 0:06 UTC (permalink / raw)
To: schen; +Cc: brian.haley, usagi-users-ctl, netdev
In-Reply-To: <AANLkTim+1=4VCmY=fO5HTvDwKnveGEPsY1h1O64vnT6L@mail.gmail.com>
From: Steve Chen <schen@mvista.com>
Date: Thu, 19 Aug 2010 13:35:14 -0500
> I trace through the code. It appears that the network driver (e1000e
> for my setup) always set ip_summed to CHECKSUM_UNNECESSARY. I have
> been unsuccessful to get the driver to take the other branch where
> ip_summed is set to CHECKSUM_COMPLETE. Even when I hard code
> ip_summed to CHECKSUM_COMPLETE, __skb_checksum_complete_head set
> ip_summed to CHECKSUM_UNNECESSARY after recomputing the checksum.
>
> So far the only way I'm able to get ICMP to recompute checksum is
> through the attached hack. Even though I can get all the tests to
> pass, but it just seem wrong.
If turning off hardware RX checksumming with ethtool has no effect,
and the problem is seen with multiple ethernet cards, the problem
is elsewhere.
First of all, if you turn RX checksumming off, the checksum field
of the SKB should always be skb->ip_summed = 0. If this is not
happening, find out why.
Put diagnostics into drivers/net/e1000e/netdev.c:e1000_rx_checksum()
and see what's happening.
If that code isn't setting ->ip_summed, then something else is,
perhaps some decapsulation code? Do these packets get embedded
in a tunnel or other kind of transport? I see that this test
has IPSEC disabled, so it can't be that.
^ permalink raw reply
* Re: [PATCH 1/8]: net: rps: reset network header before calling skb_get_rxhash()
From: David Miller @ 2010-08-20 0:08 UTC (permalink / raw)
To: xiaosuo; +Cc: netdev
In-Reply-To: <1282107656-3386-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 18 Aug 2010 13:00:56 +0800
> skb_get_rxhash() assumes the network header pointer of the skb is set
> properly after the commit:
>
> commit bfb564e7391340638afe4ad67744a8f3858e7566
> Author: Krishna Kumar <krkumar2@in.ibm.com>
> Date: Wed Aug 4 06:15:52 2010 +0000
>
> core: Factor out flow calculation from get_rps_cpu
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/8] net: rps: skip fragment when computing rxhash
From: David Miller @ 2010-08-20 0:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, netdev
In-Reply-To: <1282112701.2456.15.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Aug 2010 08:25:01 +0200
> Le mercredi 18 août 2010 à 13:01 +0800, Changli Gao a écrit :
>> Fragmented IP packets may have no transfer header, so when computing
>> rxhash, we should skip them.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
...
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
> BTW, it is nicer to add some spaces :
>
> if (ip->frag_off & htons(IP_MF | IP_OFFSET))
I took care of this.
^ permalink raw reply
* Re: [PATCH 3/8] net: introduce proto_ports_offset()
From: David Miller @ 2010-08-20 0:16 UTC (permalink / raw)
To: xiaosuo; +Cc: kaber, hadi, netdev, netfilter-devel
In-Reply-To: <1282107824-3507-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 18 Aug 2010 13:03:44 +0800
> Introduce proto_ports_offset() for getting the position of the ports or
> SPI in the message of a protocol.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/8] net: rps: use proto_ports_offset() to handle the AH message correctly
From: David Miller @ 2010-08-20 0:16 UTC (permalink / raw)
To: xiaosuo; +Cc: netdev
In-Reply-To: <1282107872-3546-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 18 Aug 2010 13:04:32 +0800
> The SPI isn't at the beginning of an AH message.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 5/8] net_sched: cls_flow: use proto_ports_offset() to support AH message
From: David Miller @ 2010-08-20 0:17 UTC (permalink / raw)
To: hadi; +Cc: xiaosuo, netdev
In-Reply-To: <1282139589.23601.38.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Wed, 18 Aug 2010 09:53:09 -0400
> On Wed, 2010-08-18 at 21:18 +0800, Changli Gao wrote:
>
>> I had gone through the code before submitting this code. But it isn't
>> easy to test if it breaks sth.
>
> That works well actually and it is the LinuxWay(tm);->
>
>> Would you please give a case to test ?
>
> Just conformance testing. Since you added new AH SPI behavior
> at least find some use case of what people normally use and make sure it
> isnt broken. But if youve looked at code sufficiently i think thats good
> enough.
I agree and I've applied his patch.
^ permalink raw reply
* Re: [PATCH 7/8] netfilter: xt_hashlimit: use proto_ports_offset() to support AH message
From: David Miller @ 2010-08-20 0:17 UTC (permalink / raw)
To: xiaosuo; +Cc: kaber, netfilter-devel, netdev
In-Reply-To: <1282107999-3663-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 18 Aug 2010 13:06:39 +0800
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 8/8] net_sched: sch_sfq: use proto_ports_offset() to support AH message
From: David Miller @ 2010-08-20 0:17 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, netdev
In-Reply-To: <1282108055-3702-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 18 Aug 2010 13:07:35 +0800
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 6/8] netfilter: ipt_CLUSTERIP: use proto_ports_offset() to support AH message
From: David Miller @ 2010-08-20 0:17 UTC (permalink / raw)
To: xiaosuo; +Cc: kaber, netfilter-devel, netdev
In-Reply-To: <1282107952-3624-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 18 Aug 2010 13:05:52 +0800
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
I applied the updated v2 version of this patch.
^ permalink raw reply
* Re: [PATCH v2] ep93xx_eth: Use net_device_stats from struct net_device
From: David Miller @ 2010-08-20 0:19 UTC (permalink / raw)
To: tklauser; +Cc: kernel, netdev, kernel-janitors
In-Reply-To: <1282205434-9601-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 19 Aug 2010 10:10:34 +0200
> struct net_device has its own struct net_device_stats member, so use
> this one instead of a private copy in the ep93xx_priv struct. As the new
> ndo_get_stats function would just return dev->stats we can omit it.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH v2] tehuti: Use net_device_stats from struct net_device
From: David Miller @ 2010-08-20 0:19 UTC (permalink / raw)
To: tklauser; +Cc: baum, andy, netdev, kernel-janitors
In-Reply-To: <1282205485-9652-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Thu, 19 Aug 2010 10:11:25 +0200
> struct net_device has its own struct net_device_stats member, so use
> this one instead of a private copy in the bdx_priv struct.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] xen: netfront: support the ethtool drvinfo hook.
From: Ben Hutchings @ 2010-08-20 0:51 UTC (permalink / raw)
To: Ian Campbell; +Cc: netdev, xen-devel, Jeremy Fitzhardinge, David S. Miller
In-Reply-To: <1282210070-7745-2-git-send-email-ian.campbell@citrix.com>
On Thu, 2010-08-19 at 10:27 +0100, Ian Campbell wrote:
> Causes "ethtool -i" to report something useful:
> # ethtool -i eth0
> driver: xen-netfront
> version:
> firmware-version:
> bus-info: vif-0
[...]
This should already be covered by:
commit 01414802054c382072b6cb9a1bdc6e243c74b2d5
Author: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue Aug 17 02:31:15 2010 -0700
ethtool: Provide a default implementation of ethtool_ops::get_drvinfo
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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
* (unknown),
From: Oskar M. Grande @ 2010-08-20 0:58 UTC (permalink / raw)
To: netdev
subscribe netdev
^ permalink raw reply
* Re: [patch v2] qlge: pull NULL check ahead of dereference
From: David Miller @ 2010-08-20 3:48 UTC (permalink / raw)
To: ron.mercer; +Cc: error27, Linux-Driver, leitao, netdev, kernel-janitors
In-Reply-To: <20100819202836.GD17233@linux-ox1b.qlogic.org>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Thu, 19 Aug 2010 13:28:36 -0700
> On Thu, Aug 19, 2010 at 11:52:44AM -0700, Dan Carpenter wrote:
>> There was a dereference before NULL check issue introduced in 1e213303d
>> "qlge: Add tx multiqueue support." I've pulled the NULL check of
>> "net_rsp" forward a couple lines to avoid that.
>>
>> Also Ron Mercer says that the early exit should be above the index
>> write. ql_write_cq_idx(rx_ring);
>>
>
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Applied to net-next-2.6, thanks guys.
^ permalink raw reply
* [PATCH] bridge: netfilter: fix a memory leak
From: Changli Gao @ 2010-08-20 5:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, bridge, netdev, Changli Gao
nf_bridge_alloc() always reset the skb->nf_bridge, so we should always
put the old one. skb->nf_bridge->use is initialized in nf_bridge_alloc(),
so we don't need to initialize it again.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/bridge/br_netfilter.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 2c911c0..7fde554 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -159,11 +159,9 @@ static inline struct nf_bridge_info *nf_bridge_unshare(struct sk_buff *skb)
if (atomic_read(&nf_bridge->use) > 1) {
struct nf_bridge_info *tmp = nf_bridge_alloc(skb);
- if (tmp) {
+ if (tmp)
memcpy(tmp, nf_bridge, sizeof(struct nf_bridge_info));
- atomic_set(&tmp->use, 1);
- nf_bridge_put(nf_bridge);
- }
+ nf_bridge_put(nf_bridge);
nf_bridge = tmp;
}
return nf_bridge;
^ permalink raw reply related
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-20 5:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20100819152143.8a57c465.akpm@linux-foundation.org>
(responding via emailed reply-to-all)
На 20.8.2010 г. 01:21, Andrew Morton написа:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 19 Aug 2010 09:57:25 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=16626
>>
>> Summary: Machine hangs with EIP at skb_copy_and_csum_dev
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 2.6.36-rc1-00127-g763008c
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: blocking
>> Priority: P1
>> Component: PCI
>> AssignedTo: drivers_pci@kernel-bugs.osdl.org
>> ReportedBy: pvp-lsts@fs.uni-ruse.bg
>> Regression: Yes
>
> A post-2.6.35 regression.
>
>>
>> After upgrade from 2.6.33.7 to 2.6.35.2 a server hanged twice, so
>> continued on 2.6.33.7.
>>
>> Today decided to try lates Linus' tree with no luck.
>>
>> The first time I started on 2.6.36-rc1-00127-g763008c it ran for a few
>> minutes, then whent dead with this on the screen:
>> [picture 1]
>> http://picpaste.com/9cfb03116d41f27568e1bb2a67b7f4dc.jpg
>>
>> [picture 2]
>> Then I power-cycled the machine, only two get this:
>> http://picpaste.com/6d70f453e462d1aed038781ad4bdb741.jpg
>>
>> And because [picture 2] seemed too bad on the lower half of the screen,
>> here is
>> [picture 3]
>> http://picpaste.com/0a51ae079ace2e4abd9e9d29226069f7.jpg
>
> Might have triggered the BUG_ON() in skb_copy_and_csum_dev(). Might be
> a tg3 thing. Hard to tell.
>
> It'd be really nice to get that first screenful. Sigh. How long have
> we had this oops-scrolls-off problem?? Perhaps you could set
> /proc/sys/kernel/printk_delay to 100 (it's in milliseconds) so that the
> oops scrolls past nice and slowly?
>
So you need the begining of the oops screen - I will try to get that
with the proposed pirntk_delay setting.
But wich kernel should I use? Linus' latest tree or 2.6.35.2 ? They
both fail the same way here, as far as I can say.
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Andrew Morton @ 2010-08-20 5:11 UTC (permalink / raw)
To: Plamen Petrov; +Cc: netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4C6E0C99.2060407@fs.uni-ruse.bg>
On Fri, 20 Aug 2010 08:03:21 +0300 Plamen Petrov <pvp-lsts@fs.uni-ruse.bg> wrote:
> (responding via emailed reply-to-all)
>
> ____ 20.8.2010 __. 01:21, Andrew Morton ____________:
> >
> > (switched to email. Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
> >
> > On Thu, 19 Aug 2010 09:57:25 GMT
> > bugzilla-daemon@bugzilla.kernel.org wrote:
> >
> >> https://bugzilla.kernel.org/show_bug.cgi?id=16626
> >>
> >> Summary: Machine hangs with EIP at skb_copy_and_csum_dev
> >> Product: Drivers
> >> Version: 2.5
> >> Kernel Version: 2.6.36-rc1-00127-g763008c
> >> Platform: All
> >> OS/Version: Linux
> >> Tree: Mainline
> >> Status: NEW
> >> Severity: blocking
> >> Priority: P1
> >> Component: PCI
> >> AssignedTo: drivers_pci@kernel-bugs.osdl.org
> >> ReportedBy: pvp-lsts@fs.uni-ruse.bg
> >> Regression: Yes
> >
> > A post-2.6.35 regression.
> >
> >>
> >> After upgrade from 2.6.33.7 to 2.6.35.2 a server hanged twice, so
> >> continued on 2.6.33.7.
> >>
> >> Today decided to try lates Linus' tree with no luck.
> >>
> >> The first time I started on 2.6.36-rc1-00127-g763008c it ran for a few
> >> minutes, then whent dead with this on the screen:
> >> [picture 1]
> >> http://picpaste.com/9cfb03116d41f27568e1bb2a67b7f4dc.jpg
> >>
> >> [picture 2]
> >> Then I power-cycled the machine, only two get this:
> >> http://picpaste.com/6d70f453e462d1aed038781ad4bdb741.jpg
> >>
> >> And because [picture 2] seemed too bad on the lower half of the screen,
> >> here is
> >> [picture 3]
> >> http://picpaste.com/0a51ae079ace2e4abd9e9d29226069f7.jpg
> >
> > Might have triggered the BUG_ON() in skb_copy_and_csum_dev(). Might be
> > a tg3 thing. Hard to tell.
> >
> > It'd be really nice to get that first screenful. Sigh. How long have
> > we had this oops-scrolls-off problem?? Perhaps you could set
> > /proc/sys/kernel/printk_delay to 100 (it's in milliseconds) so that the
> > oops scrolls past nice and slowly?
> >
> So you need the begining of the oops screen - I will try to get that
> with the proposed pirntk_delay setting.
Thanks.
> But wich kernel should I use? Linus' latest tree or 2.6.35.2 ? They
> both fail the same way here, as far as I can say.
Current mainline would be best, because we'd fix the bug there first
then backport the fix into -stable. But it doesn't matter a lot in
this case - whatever's most convenient for you, I'd say.
^ permalink raw reply
* Re: dccp test-tree [PATCH 0/3] ccid-2: Congestion Window Validation, TCP code sharing
From: Gerrit Renker @ 2010-08-20 5:38 UTC (permalink / raw)
To: David Miller; +Cc: dccp, netdev
In-Reply-To: <20100818.232805.241450746.davem@davemloft.net>
Dave,
| Ok, these obviously have dependencies with things in your dccp
| trees that are not upstream yet, my bad :-)
|
thank you very much for looking through these and apologies for not making it
fully clear that the patches sat somewhere in the middle of the test tree.
We normally cross-post from dccp@vger also to netdev@vger, in the hope that a
few more people do review.
I would like to (slowly, as we have been doing at the begin of this year)
submit patches from the test tree to netdev, to synchronize the development.
Most patches in the test tree have been there for 2..3 years, hence I would
have a good confidence submitting them.
If you are ok with this, I would submit a small bunch of 4..5 per week, which
would allow to keep this going as a background process.
Thanks again
Gerrit
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Masayuki Ohtake @ 2010-08-20 6:01 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Wang, Qi, arjan, meego-dev, Wang, Yong Y, gregkh, netdev,
socketcan-core, Khor, Andrew Chih Howe, Morinaga
In-Reply-To: <4C65255F.4010709@grandegger.com>
Hi Wolfgang,
> >>>> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> >>> Just take a look at kfifo.h. This structure has been changed. I remembered
> >> there was a spin_lock from kfifo previously. Currently it's been removed, good.
> >>> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to
> >> use this structure and APIs?
> >>
> >> As I see it, the code related to that fifo is not used (== dead code)?
> > I'm not familiar with kfifo structure, and I didn't like it because there need a spin_lock to use it.
We are about to study kfifo infra structure.
I have a question.
It seems all CAN drivers accepted by upstream don't use kfifo infrastructure, right ?
(I couldn't see message with "grep kfifo * in drivers/net/can")
If yes, why should we use the kfifo ?
If no, please show me the kfifo reference driver
Thanks, Ohtake(OKISEMI)
----- Original Message -----
From: "Wolfgang Grandegger" <wg@grandegger.com>
To: "Wang, Qi" <qi.wang@intel.com>
Cc: "Khor, Andrew Chih Howe" <andrew.chih.howe.khor@intel.com>; <socketcan-core@lists.berlios.de>;
<netdev@vger.kernel.org>; <gregkh@suse.de>; "Wang, Yong Y" <yong.y.wang@intel.com>; "Masayuki Ohtak"
<masa-korg@dsn.okisemi.com>; <meego-dev@meego.com>; <arjan@linux.intel.com>
Sent: Friday, August 13, 2010 7:58 PM
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> On 08/13/2010 02:23 AM, Wang, Qi wrote:
> >> -----Original Message-----
> >> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
> >> Sent: Thursday, August 12, 2010 5:04 PM
> >> To: Wang, Qi
> >> Cc: Daniel Baluta; Masayuki Ohtak; meego-dev@meego.com;
> >> socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor, Andrew Chih
> >> Howe; gregkh@suse.de; arjan@linux.intel.com; Wang, Yong Y
> >> Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> >>
> >> On 08/12/2010 03:42 AM, Wang, Qi wrote:
> >>>> -----Original Message-----
> >>>> From: Daniel Baluta [mailto:daniel.baluta@gmail.com]
> >>>> Sent: Wednesday, August 11, 2010 6:37 PM
> >>>> To: Masayuki Ohtak
> >>>> Cc: meego-dev@meego.com; Wolfgang Grandegger;
> >>>> socketcan-core@lists.berlios.de; netdev@vger.kernel.org; Khor, Andrew
> >> Chih
> >>>> Howe; gregkh@suse.de; arjan@linux.intel.com; Wang, Qi; Wang, Yong Y
> >>>> Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> >>>>
> >>>> Hi,
> >>>>
> >>>> 2010/8/11 Masayuki Ohtak <masa-korg@dsn.okisemi.com>:
> >>>>> CAN driver of Topcliff PCH
> >>>>>
> >>>>> Topcliff PCH is the platform controller hub that is going to be used in
> >>>>> Intel's upcoming general embedded platform. All IO peripherals in
> >>>>> Topcliff PCH are actually devices sitting on AMBA bus.
> >>>>> Topcliff PCH has CAN I/F. This driver enables CAN function.
> >>>>>
> >>>>> Signed-off-by: Masayuki Ohtake <masa-korg@dsn.okisemi.com>
> >>>>
> >>>> I have a few questions:
> >>>>
> >>>> 1. Is your code based on Intel's CAN EP80579 ([1]) ?
> >>> No.
> >>
> >> For curiosity, is the controller similar to the OKI MSM9225 or ML9620?
> > The Topcliff IOH is developed by OKI actually.
> >
> >>
> >>>> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> >>> Just take a look at kfifo.h. This structure has been changed. I remembered
> >> there was a spin_lock from kfifo previously. Currently it's been removed, good.
> >>> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to
> >> use this structure and APIs?
> >>
> >> As I see it, the code related to that fifo is not used (== dead code)?
> > I'm not familiar with kfifo structure, and I didn't like it because there need a spin_lock to use it.
> >>
> >>> Daniel,
> >>>
> >>> We're anxious to integrate those codes now. Perhaps it'll take us quite a long
> >> time to use kfifo. How about implementing it with the next version?
> >>
> >> See above. What do you mean with the next version. The driver posted by
> >> Masayuki is far away from being accepted as it does not yet comply with
> >> the Socket-CAN driver API, to say the least.
> > I've few experience on CAN driver and it's also the first time for OKI-san to write Can driver. Would you please
give us a reference and we'll follow it up. We only read 'can.txt' from kernel document. Thank you for your help in
advance.
>
> You are welcome. I think I/we already gave useful hints on what is
> missing and what examples to follow.
>
> Wolfgang.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-20 6:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20100819221142.b8f6a70a.akpm@linux-foundation.org>
На 20.8.2010 г. 08:11, Andrew Morton написа:
> On Fri, 20 Aug 2010 08:03:21 +0300 Plamen Petrov<pvp-lsts@fs.uni-ruse.bg> wrote:
>
>> (responding via emailed reply-to-all)
>>
>> ____ 20.8.2010 __. 01:21, Andrew Morton ____________:
>>>
>>> (switched to email. Please respond via emailed reply-to-all, not via the
>>> bugzilla web interface).
>>>
>>> On Thu, 19 Aug 2010 09:57:25 GMT
>>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>>
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16626
>>>>
>>>> Summary: Machine hangs with EIP at skb_copy_and_csum_dev
>>>> Product: Drivers
>>>> Version: 2.5
>>>> Kernel Version: 2.6.36-rc1-00127-g763008c
>>>> Platform: All
>>>> OS/Version: Linux
>>>> Tree: Mainline
>>>> Status: NEW
>>>> Severity: blocking
>>>> Priority: P1
>>>> Component: PCI
>>>> AssignedTo: drivers_pci@kernel-bugs.osdl.org
>>>> ReportedBy: pvp-lsts@fs.uni-ruse.bg
>>>> Regression: Yes
>>>
>>> A post-2.6.35 regression.
>>>
>>>>
>>>> After upgrade from 2.6.33.7 to 2.6.35.2 a server hanged twice, so
>>>> continued on 2.6.33.7.
>>>>
>>>> Today decided to try lates Linus' tree with no luck.
>>>>
>>>> The first time I started on 2.6.36-rc1-00127-g763008c it ran for a few
>>>> minutes, then whent dead with this on the screen:
>>>> [picture 1]
>>>> http://picpaste.com/9cfb03116d41f27568e1bb2a67b7f4dc.jpg
>>>>
>>>> [picture 2]
>>>> Then I power-cycled the machine, only two get this:
>>>> http://picpaste.com/6d70f453e462d1aed038781ad4bdb741.jpg
>>>>
>>>> And because [picture 2] seemed too bad on the lower half of the screen,
>>>> here is
>>>> [picture 3]
>>>> http://picpaste.com/0a51ae079ace2e4abd9e9d29226069f7.jpg
>>>
>>> Might have triggered the BUG_ON() in skb_copy_and_csum_dev(). Might be
>>> a tg3 thing. Hard to tell.
>>>
>>> It'd be really nice to get that first screenful. Sigh. How long have
>>> we had this oops-scrolls-off problem?? Perhaps you could set
>>> /proc/sys/kernel/printk_delay to 100 (it's in milliseconds) so that the
>>> oops scrolls past nice and slowly?
>>>
>> So you need the begining of the oops screen - I will try to get that
>> with the proposed pirntk_delay setting.
>
> Thanks.
>
>> But wich kernel should I use? Linus' latest tree or 2.6.35.2 ? They
>> both fail the same way here, as far as I can say.
>
> Current mainline would be best, because we'd fix the bug there first
> then backport the fix into -stable. But it doesn't matter a lot in
> this case - whatever's most convenient for you, I'd say.
>
With the "echo 100 > /proc/sys/kernel/printk_delay" command run by
/etc/rc.d/rc.local, while still on 2.6.36-rc1-00127-g763008c, I got
these:
[picture 4]
http://picpaste.com/aa3e373e894179e8ba19587ed63d8104.jpg
[picture 5]
http://picpaste.com/9bc4bdc04f5a84fdaf49d6e1db23ede8.jpg
[picture 6]
http://picpaste.com/da3ccd69a0a1221bb55f48b39c4ad950.jpg
Hope the above help.
And by the way, I think you are correct that this is a
post-2.6.35 thing, because 2.6.35.2 was the first to give
me this kind of problems, and I can confirm that 2.6.34
does not have it, because the system was on 2.6.34.4 for
the last 12 hours without problems, then just a moment ago
crashed on 2.6.36-rc1-00127-g763008c, and now back on
2.6.34.4
P.S. Shouldn't "echo 100 > /proc/sys/kernel/printk_delay" be
somewhere on the "How to debug a crashing kernel guide"
somewhere?
Thanks!
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Andrew Morton @ 2010-08-20 6:20 UTC (permalink / raw)
To: Plamen Petrov; +Cc: netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4C6E1CBA.2060605@fs.uni-ruse.bg>
On Fri, 20 Aug 2010 09:12:10 +0300 Plamen Petrov <pvp-lsts@fs.uni-ruse.bg> wrote:
> With the "echo 100 > /proc/sys/kernel/printk_delay" command run by
> /etc/rc.d/rc.local, while still on 2.6.36-rc1-00127-g763008c, I got
> these:
>
> [picture 4]
> http://picpaste.com/aa3e373e894179e8ba19587ed63d8104.jpg
bewdy, thanks.
BUG_ON(csstart > skb_headlen(skb));
Hopefully that's enough for the net guys to work with.
> [picture 5]
> http://picpaste.com/9bc4bdc04f5a84fdaf49d6e1db23ede8.jpg
>
> [picture 6]
> http://picpaste.com/da3ccd69a0a1221bb55f48b39c4ad950.jpg
>
> Hope the above help.
>
> And by the way, I think you are correct that this is a
> post-2.6.35 thing, because 2.6.35.2 was the first to give
> me this kind of problems, and I can confirm that 2.6.34
> does not have it, because the system was on 2.6.34.4 for
> the last 12 hours without problems, then just a moment ago
> crashed on 2.6.36-rc1-00127-g763008c, and now back on
> 2.6.34.4
OK.
> P.S. Shouldn't "echo 100 > /proc/sys/kernel/printk_delay" be
> somewhere on the "How to debug a crashing kernel guide"
> somewhere?
I only just thought of it ;)
I'm thinking perhaps that we should have a lines_after_oops boot
parameter which makes the console shut up N lines after someone called
oops_enter().
^ permalink raw reply
* Re: [PATCH v7] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: Eric Dumazet @ 2010-08-20 6:24 UTC (permalink / raw)
To: Dmitry Kozlov; +Cc: netdev
In-Reply-To: <E1Om1Q6-0005Fm-00.xeb-mail-ru@f239.mail.ru>
Le jeudi 19 août 2010 à 13:28 +0400, Dmitry Kozlov a écrit :
> Ang again...
> This patch contains:
> 1. pptp driver
> 2. gre demultiplexer driver for demultiplexing gre packets with different gre version
> so ip_gre and pptp may coexists
> 3. ip_gre modification
> 4. other stuff
>
> Changes from v6:
> 1. memory allocation moved to begin of module initialization
> 2. fixed coding style issues
> Thanks to Eric Dumazet.
>
> --
> MAINTAINERS | 14 +
> drivers/net/Kconfig | 11 +
> drivers/net/Makefile | 1 +
> drivers/net/pptp.c | 726 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/if_pppox.h | 59 +++--
> include/net/gre.h | 18 ++
> net/ipv4/Kconfig | 7 +
> net/ipv4/Makefile | 1 +
> net/ipv4/gre.c | 151 ++++++++++
> net/ipv4/ip_gre.c | 14 +-
> 10 files changed, 975 insertions(+), 27 deletions(-)
Seems fine to me, but you need to make a nice looking Changelog and add
your "Signed-off-by: ...." signature.
Thanks
^ 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