* Re: pskb_copy() in tcp_transmit_skb()
From: Gao feng @ 2011-09-13 12:00 UTC (permalink / raw)
To: christoph.paasch; +Cc: netdev
In-Reply-To: <201109131355.55588.christoph.paasch@uclouvain.be>
于 11-9-13 下午6:55, Christoph Paasch 写道:
> Hi,
>
> On Tuesday 13 September 2011 wrote Gaofeng:
>>> I'm trying to understand the reason for the possible call to pskb_copy()
>>> in tcp_transmit_skb().
>>> I don't find, where we may have a cloned skb entering tcp_transmit_skb().
>>>
>>> The original pskb_copy() came from tcp_retransmit_skb() (commit
>>> dfb4b9dceb35c567a595ae5e9d035cfda044a103).
>>> But from that point, the git-history does not show where the pskb_copy()
>>> is coming from.
>>>
>>>
>>> Does somebody has an idea, how a cloned skb can be passed to
>>> tcp_transmit_skb() and thus trigger this call to pskb_copy().
>>
>> maybe nat,nat can change the tcp packet header
>
> although NAT may change the TCP header, it is not doing an skb_clone() - (at
> least I don't find it).
> Thus, we will not call pskb_copy() in tcp_transmit_skb() due to NAT.
>
> Christoph
>
> --
> Christoph Paasch
> PhD Student
>
> IP Networking Lab --- http://inl.info.ucl.ac.be
> MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
> Université Catholique de Louvain
>
> www.rollerbulls.be
> --
> --
> 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
>
maybe this.
if the nic driver has not transmit the cloned skb to the network yet.
then tcp_retransmit_skb is called by some logical.
if dont use pskb_copy here,it will make the nat or some header operation
error.
^ permalink raw reply
* Re: pskb_copy() in tcp_transmit_skb()
From: Eric Dumazet @ 2011-09-13 12:02 UTC (permalink / raw)
To: christoph.paasch; +Cc: Gaofeng, netdev
In-Reply-To: <201109131355.55588.christoph.paasch@uclouvain.be>
Le 13 septembre 2011 12:55, Christoph Paasch
<christoph.paasch@uclouvain.be> a écrit :
>
> Hi,
>
> On Tuesday 13 September 2011 wrote Gaofeng:
> > > I'm trying to understand the reason for the possible call to pskb_copy()
> > > in tcp_transmit_skb().
> > > I don't find, where we may have a cloned skb entering tcp_transmit_skb().
> > >
> > > The original pskb_copy() came from tcp_retransmit_skb() (commit
> > > dfb4b9dceb35c567a595ae5e9d035cfda044a103).
> > > But from that point, the git-history does not show where the pskb_copy()
> > > is coming from.
> > >
> > >
> > > Does somebody has an idea, how a cloned skb can be passed to
> > > tcp_transmit_skb() and thus trigger this call to pskb_copy().
> >
> > maybe nat,nat can change the tcp packet header
>
> although NAT may change the TCP header, it is not doing an skb_clone() - (at
> least I don't find it).
> Thus, we will not call pskb_copy() in tcp_transmit_skb() due to NAT.
>
I suggest you read dev_queue_xmit_nit() : Every xmit packet can be
cloned right here.
By the time tcp_retransmit_skb() is called, cloned skb might still be
in a AF_PACKET queue (or even a device TX queue)
^ permalink raw reply
* Re: [PATCH v2 3/5] SUNRPC: make RPC service dependable on rpcbind clients creation
From: Stanislav Kinsbursky @ 2011-09-13 11:09 UTC (permalink / raw)
To: Trond Myklebust
Cc: Jeff Layton, linux-nfs@vger.kernel.org, Pavel Emelianov,
neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, bfields@fieldses.org,
davem@davemloft.net
In-Reply-To: <4E6DEB89.7080407@parallels.com>
12.09.2011 15:22, Stanislav Kinsbursky пишет:
> 09.09.2011 23:25, Trond Myklebust пишет:
>> On Fri, 2011-09-09 at 15:01 -0400, Jeff Layton wrote:
>>> On Fri, 09 Sep 2011 14:44:34 -0400
>>> Trond Myklebust<Trond.Myklebust@netapp.com> wrote:
>>>
>>>> On Fri, 2011-09-09 at 20:41 +0400, Stanislav Kinsbursky wrote:
>>>>> 09.09.2011 18:07, Jeff Layton пишет:
>>>>>> On Fri, 09 Sep 2011 16:08:44 +0400
>>>>>> Stanislav Kinsbursky<skinsbursky@parallels.com> wrote:
>>>>>>
>>>>>>> Create rcbind clients or increase rpcbind users counter during RPC service
>>>>>>> creation and decrease this counter (and possibly destroy those clients) on RPC
>>>>>>> service destruction.
>>>>>>>
>>>>>>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
>>>>>>>
>>>>>>> ---
>>>>>>> include/linux/sunrpc/clnt.h | 2 ++
>>>>>>> net/sunrpc/rpcb_clnt.c | 2 +-
>>>>>>> net/sunrpc/svc.c | 13 +++++++++++--
>>>>>>> 3 files changed, 14 insertions(+), 3 deletions(-)
>>>>>>>
>>>>>>> diff --git a/include/linux/sunrpc/clnt.h b/include/linux/sunrpc/clnt.h
>>>>>>> index db7bcaf..65a8115 100644
>>>>>>> --- a/include/linux/sunrpc/clnt.h
>>>>>>> +++ b/include/linux/sunrpc/clnt.h
>>>>>>> @@ -135,10 +135,12 @@ void rpc_shutdown_client(struct rpc_clnt *);
>>>>>>> void rpc_release_client(struct rpc_clnt *);
>>>>>>> void rpc_task_release_client(struct rpc_task *);
>>>>>>>
>>>>>>> +int rpcb_create_local(void);
>>>>>>> int rpcb_register(u32, u32, int, unsigned short);
>>>>>>> int rpcb_v4_register(const u32 program, const u32 version,
>>>>>>> const struct sockaddr *address,
>>>>>>> const char *netid);
>>>>>>> +void rpcb_put_local(void);
>>>>>>> void rpcb_getport_async(struct rpc_task *);
>>>>>>>
>>>>>>> void rpc_call_start(struct rpc_task *);
>>>>>>> diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
>>>>>>> index b4cc0f1..437ec60 100644
>>>>>>> --- a/net/sunrpc/rpcb_clnt.c
>>>>>>> +++ b/net/sunrpc/rpcb_clnt.c
>>>>>>> @@ -318,7 +318,7 @@ out:
>>>>>>> * Returns zero on success, otherwise a negative errno value
>>>>>>> * is returned.
>>>>>>> */
>>>>>>> -static int rpcb_create_local(void)
>>>>>>> +int rpcb_create_local(void)
>>>>>>> {
>>>>>>> static DEFINE_MUTEX(rpcb_create_local_mutex);
>>>>>>> int result = 0;
>>>>>>> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
>>>>>>> index 6a69a11..9095c0e 100644
>>>>>>> --- a/net/sunrpc/svc.c
>>>>>>> +++ b/net/sunrpc/svc.c
>>>>>>> @@ -367,8 +367,11 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>>>>>>> unsigned int xdrsize;
>>>>>>> unsigned int i;
>>>>>>>
>>>>>>> - if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
>>>>>>> + if (rpcb_create_local()< 0)
>>>>>>> return NULL;
>>>>>>> +
>>>>>>> + if (!(serv = kzalloc(sizeof(*serv), GFP_KERNEL)))
>>>>>>> + goto out_err;
>>>>>>> serv->sv_name = prog->pg_name;
>>>>>>> serv->sv_program = prog;
>>>>>>> serv->sv_nrthreads = 1;
>>>>>>> @@ -403,7 +406,7 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>>>>>>> GFP_KERNEL);
>>>>>>> if (!serv->sv_pools) {
>>>>>>> kfree(serv);
>>>>>>> - return NULL;
>>>>>>> + goto out_err;
>>>>>>> }
>>>>>>>
>>>>>>> for (i = 0; i< serv->sv_nrpools; i++) {
>>>>>>> @@ -423,6 +426,10 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
>>>>>>> svc_unregister(serv);
>>>>>>>
>>>>>>> return serv;
>>>>>>> +
>>>>>>> +out_err:
>>>>>>> + rpcb_put_local();
>>>>>>> + return NULL;
>>>>>>> }
>>>>>>>
>>>>>>> struct svc_serv *
>>>>>>> @@ -491,6 +498,8 @@ svc_destroy(struct svc_serv *serv)
>>>>>>> svc_unregister(serv);
>>>>>>> kfree(serv->sv_pools);
>>>>>>> kfree(serv);
>>>>>>> +
>>>>>>> + rpcb_put_local();
>>>>>>> }
>>>>>>> EXPORT_SYMBOL_GPL(svc_destroy);
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I don't get it -- what's the advantage of creating rpcbind clients in
>>>>>> __svc_create vs. the old way of creating them just before we plan to
>>>>>> use them?
>>>>>>
>>>>>
>>>>> The main problem here is not in creation, but in destroying those clients.
>>>>> Now rpcbind clients are created during rpcb_register(). I.e. once per every family, program version and so on.
>>>>> But can be unregistered for all protocol families by one call. So it's impossible to put reference counting for those clients in the place, where they are created now.
>>>>
>>>> Could we perhaps set up a 'struct pernet_operations' to create a
>>>> destructor for them?
>>>>
>>>
>>> An even easier idea might be to just not take a reference to the
>>> rpcbind client for svc_programs that have vs_hidden set on every
>>> version.
>>
>> Isn't the problem that Stanislav is trying to solve that we need to be
>> able to register and unregister RPC services to the correct rpcbind
>> server, depending on which net namespace we are in?
>>
>
> Yes, it is.
> I'm going to make rpcbind clients per net namespace.
>
>> My understanding is that the current code will register everything to
>> whatever rpcbind server is running in the init net namespace because
>> that's what rpcb_create_local() uses.
>>
>> My suggestion is to use a struct pernet_operations to detect when a net
>> namespace is being created or destroyed, so that the rpcbind client code
>> knows when to create or destroy a connection to the server that is
>> running in that namespace.
>>
>
> But as Pavel mentioned already, we can't use netns destructor for rpcbind
> clients because they holds netns reference.
> That's why we have to untie netns from rpbind clients first.
> Another solution is to not increment netns ref counter for rpcbind sockets as,
> again, Pavel already mentioned.
> But first approach looks clearer from my pow. That's why I'm trying to make
> rcpbind client's self-destructible.After achieving this we can just make this
> rpcbind clients per netns and then we can virtualize lockd.
>
> I've tried to find some better place for creating rpcbind clients (instead of
> __svc_create()). But this place looks like the best one for current solution.
>
> About avoiding of creation of rpcbind clients for nfs 4.* callbacks.
> Probably, we can implement init-fini calls for svc_program structure
> (rpcb_create_local() and rpcb_put_local() will be used in our case) and then
> inherit them for svc_serv. This will allow us to call this hooks only if they
> defined and thus avoid rpcbind clients creation for nfs callbacks.
>
> What all of you think about this hook's idea?
>
Since we already have sv_shutdown callback, we can use it to put rpcbind clients.
Creation of rpcbind clients can be performed in lockd_up() and
nfsd_create_serv() before calling svc_create(_pooled)().
>> Cheers
>> Trond
>
>
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* HELLO FROM BELDORIN..
From: Beldorin Duke @ 2011-09-13 10:00 UTC (permalink / raw)
Hello,it is my pleasure and desire to contact you and make a formal
introduction of myself to you.how are you doing today,i hope that you are
fine and my little note finds you in good health and proper state of
mind.my name is Beldorin Duke i am 24years old single and i have no kid,i
am in search of true love,friendship and a real trustworthy business
partner that i think we can be of benefit to each other,upon the reciept
of your email i will explain myself more clearly and better to you,feel
free to contact me at (beldorinminu@yahoo.com) for further discussion with
me.
I wish you a pleasant and favourable day there as i hope to read from you
soon,i will send you my details togather with pictures of me in my next
email to you,be assured of my warm regards and best of wishes.
Beldorin Duke
^ permalink raw reply
* Re: pskb_copy() in tcp_transmit_skb()
From: Christoph Paasch @ 2011-09-13 10:55 UTC (permalink / raw)
To: Gaofeng; +Cc: netdev
In-Reply-To: <4E6F2275.2050902@cn.fujitsu.com>
Hi,
On Tuesday 13 September 2011 wrote Gaofeng:
> > I'm trying to understand the reason for the possible call to pskb_copy()
> > in tcp_transmit_skb().
> > I don't find, where we may have a cloned skb entering tcp_transmit_skb().
> >
> > The original pskb_copy() came from tcp_retransmit_skb() (commit
> > dfb4b9dceb35c567a595ae5e9d035cfda044a103).
> > But from that point, the git-history does not show where the pskb_copy()
> > is coming from.
> >
> >
> > Does somebody has an idea, how a cloned skb can be passed to
> > tcp_transmit_skb() and thus trigger this call to pskb_copy().
>
> maybe nat,nat can change the tcp packet header
although NAT may change the TCP header, it is not doing an skb_clone() - (at
least I don't find it).
Thus, we will not call pskb_copy() in tcp_transmit_skb() due to NAT.
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* Re: [PATCH] ixgbe: drop zero length frame segments during a packet split rx
From: Neil Horman @ 2011-09-13 10:50 UTC (permalink / raw)
To: netdev
Cc: Thadeu Lima de Souza Cascardo, Jesse Brandeburg, Alexander Duyck,
John Fastabend, Jeff Kirsher, David S. Miller
In-Reply-To: <1314972197-31557-1-git-send-email-nhorman@tuxdriver.com>
On Fri, Sep 02, 2011 at 10:03:17AM -0400, Neil Horman wrote:
> This oops was reported recently no ppc64 hardware:
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc0000000004dda0c
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
> iptable_fi
> lter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
> nf_conntrack ip6table_filter ip6_tables ipv6 jsm ses enclosure sg ixgbe
> mdio e1000 ehea ext4 jbd2 mbcache sd_mod crc_t10dif ipr dm_mod
> NIP: c0000000004dda0c LR: c0000000004e3e50 CTR: c0000000004e3e20
> REGS: c0000001bffeb8d0 TRAP: 0300 Not tainted (3.1.0-rc2-10121-gab7e2db)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 28002042 XER: 20000000
> CFAR: c000000000004d70
> DAR: 0000000000000000, DSISR: 40000000
> TASK = c000000000d548e0[0] 'swapper' THREAD: c000000000dfc000 CPU: 0
> GPR04: c0000000010f4d80 c0000001bffebd80 0000000000000000 c0000001b18a8200
> GPR08: 0000000000000280 c0000001bcc517a8 c0000001b18a7f80 0000000000000000
> GPR12: d0000000047e5bb0 c000000001f10000 c0000001b19c8700 0000000000000000
> GPR16: c0000001bffebd80 0000000000000083 c00000018f2447a0 0000000000000002
> GPR20: 0000000000000000 c0000001ba860010 c0000001ba860000 d000000003d40000
> GPR24: 0000000000000000 0000000000000083 d000000003d40000 0000000000000001
> GPR28: c00000018f244780 c0000001b2b94310 c000000000da95f0 c0000001bcc51780
> NIP [c0000000004dda0c] .skb_gro_reset_offset+0x5c/0xe0
> LR [c0000000004e3e50] .napi_gro_receive+0x30/0x120
> Call Trace:
> [c0000001bffebb50] [c000000000da95f0] perf_callchain_user+0x0/0x10 (unreliable)
> [c0000001bffebbf0] [d0000000047bd118] .ixgbe_clean_rx_irq+0x7a8/0x8a0 [ixgbe]
> [c0000001bffebd10] [d0000000047bd414] .ixgbe_poll+0x64/0x160 [ixgbe]
> [c0000001bffebdd0] [c0000000004e3358] .net_rx_action+0x108/0x2a0
> [c0000001bffebea0] [c00000000009b220] .__do_softirq+0x110/0x2a0
> [c0000001bffebf90] [c000000000023798] .call_do_softirq+0x14/0x24
> [c000000000dff830] [c000000000011148] .do_softirq+0xf8/0x130
> [c000000000dff8d0] [c00000000009aeb4] .irq_exit+0xb4/0xc0
> [c000000000dff950] [c000000000011254] .do_IRQ+0xd4/0x300
> [c000000000dffa10] [c000000000005024] hardware_interrupt_entry+0x18/0x74
> --- Exception: 501 at .pseries_dedicated_idle_sleep+0xe4/0x210
> LR = .pseries_dedicated_idle_sleep+0x8c/0x210
> [c000000000dffd00] [c00000000005b194] .pseries_dedicated_idle_sleep+0x194/0x210
> (unreliable)
> [c000000000dffdc0] [c000000000018c84] .cpu_idle+0x164/0x210
> [c000000000dffe70] [c00000000000b0d0] .rest_init+0x90/0xb0
> [c000000000dffef0] [c000000000830bc0] .start_kernel+0x54c/0x56c
> [c000000000dfff90] [c00000000000953c] .start_here_common+0x1c/0x60
>
> Its caused when skb_gro_reset_offset attempts to call PageHighMem on
> skb_shinfo(skb)->frags[0].page, when the frags array was left uninitalized.
> This can happen in the ixgbe driver if the hardware reports a zero length rx
> descriptor ni the middle of a packet split receive transaction. I've consulted
> with Jesse Brandeburg on this, who is attempting to root cause the issue at
> Intel, but it seems prudent to add this check to the driver to discard frames of
> that encounter this error to avoid the opps
>
Sorry, I need to rescind this patch. Looks like this is turning out to be an
issue with an ideosyncracy in the dma hardware on this platform.
Thanks
Neil
^ permalink raw reply
* [PATCH] net/smsc911x: Correctly configure 16-bit register access from DT
From: Dave Martin @ 2011-09-13 10:49 UTC (permalink / raw)
To: netdev
Cc: patches, Steve Glendinning, Shawn Guo, devicetree-discuss,
Dave Martin
The SMSC911X_USE_16BIT needs to be set when using 16-bit register
access. However, currently no flag is set if the device tree
doesn't specify 32-bit access, resulting in a BUG() and a non-
working driver when 16-bit register access is configured for
smsc911x in the DT.
This patch should set the SMSC911X_USE_16BIT flag in a manner
consistent with the documented DT bindings.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
drivers/net/ethernet/smsc/smsc911x.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index 788c4fd..a3aa4c0 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2121,6 +2121,8 @@ static int __devinit smsc911x_probe_config_dt(
of_property_read_u32(np, "reg-io-width", &width);
if (width == 4)
config->flags |= SMSC911X_USE_32BIT;
+ else
+ config->flags |= SMSC911X_USE_16BIT;
if (of_get_property(np, "smsc,irq-active-high", NULL))
config->irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH;
--
1.7.4.1
^ permalink raw reply related
* Re: pskb_copy() in tcp_transmit_skb()
From: Gaofeng @ 2011-09-13 9:29 UTC (permalink / raw)
To: christoph.paasch; +Cc: netdev
In-Reply-To: <201109131221.37561.christoph.paasch@uclouvain.be>
于 2011年09月13日 17:21, Christoph Paasch 写道:
> Hi,
>
> I'm trying to understand the reason for the possible call to pskb_copy() in
> tcp_transmit_skb().
> I don't find, where we may have a cloned skb entering tcp_transmit_skb().
>
> The original pskb_copy() came from tcp_retransmit_skb() (commit
> dfb4b9dceb35c567a595ae5e9d035cfda044a103).
> But from that point, the git-history does not show where the pskb_copy() is
> coming from.
>
>
> Does somebody has an idea, how a cloned skb can be passed to
> tcp_transmit_skb() and thus trigger this call to pskb_copy().
>
>
> Thanks for your help,
> Christoph
>
>
> --
> Christoph Paasch
> PhD Student
>
> IP Networking Lab --- http://inl.info.ucl.ac.be
> MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
> Université Catholique de Louvain
>
> www.rollerbulls.be
> --
> --
> 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
>
maybe nat,nat can change the tcp packet header
^ permalink raw reply
* pskb_copy() in tcp_transmit_skb()
From: Christoph Paasch @ 2011-09-13 9:21 UTC (permalink / raw)
To: netdev
Hi,
I'm trying to understand the reason for the possible call to pskb_copy() in
tcp_transmit_skb().
I don't find, where we may have a cloned skb entering tcp_transmit_skb().
The original pskb_copy() came from tcp_retransmit_skb() (commit
dfb4b9dceb35c567a595ae5e9d035cfda044a103).
But from that point, the git-history does not show where the pskb_copy() is
coming from.
Does somebody has an idea, how a cloned skb can be passed to
tcp_transmit_skb() and thus trigger this call to pskb_copy().
Thanks for your help,
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* End of Year Promo
From: Pepsi Bottling Company Plc @ 2011-09-13 9:06 UTC (permalink / raw)
Your email has won £520,000.00 POUNDS (Five Hundred and Twenty
Thousand Pounds) from Pepsi online promotions2011,send your Full
names, Age, Sex,Occupation,Phone number and Home Address to the promo
Manager, Mrs. Francess Dave Tel:+447011150911
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [PATCH -v2] netconsole: switch init_netconsole() to late_initcall if build-in
From: Lin Ming @ 2011-09-13 8:38 UTC (permalink / raw)
To: Andrew Morton
Cc: David S. Miller, lkml, netdev@vger.kernel.org, Kirsher, Jeffrey T
In-Reply-To: <20110913010158.1652cdee.akpm@linux-foundation.org>
On Tue, 2011-09-13 at 16:01 +0800, Andrew Morton wrote:
> On Tue, 13 Sep 2011 15:45:39 +0800 Lin Ming <ming.m.lin@intel.com> wrote:
>
> > Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
> > regression that netconsole does not work if netconsole and network
> > device driver are build into kernel, because netconsole is linked
> > before network device driver.
> >
> > Andrew Morton suggested to fix this with initcall ordering.
> > Fixes it by switching init_netconsole() to late_initcall if build-in.
> >
> > Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> > ---
> > drivers/net/netconsole.c | 4 ++++
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> > index dfc8272..914be29 100644
> > --- a/drivers/net/netconsole.c
> > +++ b/drivers/net/netconsole.c
> > @@ -799,5 +799,9 @@ static void __exit cleanup_netconsole(void)
> > }
> > }
> >
> > +#ifdef MODULE
> > module_init(init_netconsole);
> > module_exit(cleanup_netconsole);
> > +#else
> > +late_initcall(init_netconsole);
> > +#endif /* !MODULE */
>
> The ifdefs (which should have used CONFIG_MODULE) aren't needed.
> Because late_initcall() and module_init() are identical if
> CONFIG_MODULE, and because one day we might want to run the exitcalls
> for built-in code (UML actually does this at present).
Thanks for comments.
Updated as below.
>From 035af5dca36a3b9e255758a46214e0e6d2b5b6a3 Mon Sep 17 00:00:00 2001
From: Lin Ming <ming.m.lin@intel.com>
Date: Tue, 13 Sep 2011 16:35:46 +0800
Subject: [PATCH -v3] netconsole: switch init_netconsole() to late_initcall
Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
regression that netconsole does not work if netconsole and network
device driver are build into kernel, because netconsole is linked
before network device driver.
Andrew Morton suggested to fix this with initcall ordering.
Fixes it by switching init_netconsole() to late_initcall.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
drivers/net/netconsole.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index dfc8272..ed2a397 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -799,5 +799,11 @@ static void __exit cleanup_netconsole(void)
}
}
-module_init(init_netconsole);
+/*
+ * Use late_initcall to ensure netconsole is
+ * initialized after network device driver if built-in.
+ *
+ * late_initcall() and module_init() are identical if built as module.
+ */
+late_initcall(init_netconsole);
module_exit(cleanup_netconsole);
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH -v2] netconsole: switch init_netconsole() to late_initcall if build-in
From: Lin Ming @ 2011-09-13 8:26 UTC (permalink / raw)
To: Américo Wang
Cc: David S. Miller, Andrew Morton, lkml, netdev@vger.kernel.org,
Kirsher, Jeffrey T
In-Reply-To: <CAM_iQpVsKXn3ZMygOKc699KQPXbt=-yEWMdKFLqYGVucoJ874w@mail.gmail.com>
On Tue, 2011-09-13 at 15:55 +0800, Américo Wang wrote:
> On Tue, Sep 13, 2011 at 3:45 PM, Lin Ming <ming.m.lin@intel.com> wrote:
> > Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
> > regression that netconsole does not work if netconsole and network
> > device driver are build into kernel, because netconsole is linked
> > before network device driver.
> >
> > Andrew Morton suggested to fix this with initcall ordering.
> > Fixes it by switching init_netconsole() to late_initcall if build-in.
> >
>
> Putting one or two lines of comments into the code would
> be nicer, otherwise people have to dig git log to see why. ;-)
Will add.
Thanks.
^ permalink raw reply
* Re: r8169 hard-freezes the system on big network loads
From: Francois Romieu @ 2011-09-13 8:11 UTC (permalink / raw)
To: Michael Brade; +Cc: netdev, nic_swsd, Hayes
In-Reply-To: <201109112216.33579.brade@informatik.uni-muenchen.de>
[-- Attachment #1: Type: text/plain, Size: 3204 bytes --]
Michael Brade <brade@informatik.uni-muenchen.de> :
[...]
> Does it have to be 3.1.0-rc3 or is 3.0.1 ok as well ?
:o(
Almost any release may exhibit the bug. The attached patch (#0003)
should be a better candidate as an official fix though.
> If so, I have another bad news: 3.0.1 still crashes with this patch.
> It took me a lot longer to crash it but eventually it did happen.
> Not sure why it took longer, I guess I didn't generate enough throughput.
It sure sucks from a user experience viewpoint but it is not _that_ bad.
Are the symptoms in any way different or do you still notice more-or-less
periodic link-up messages and no real network traffic ?
> If you want me to use 3.1.0 then we'll have to wait until git.kernel.org is
> back...
https://github.com/torvalds/linux.git is available in the meantime.
You will want the patch below as well if you try 3.1-rc6.
[PATCH] r8169: don't reset software ring indexes after disabling hardware Rx.
Bad things happen when the driver resets ring indexes after disabling
hardware Rx (and Tx) in the RxFIFOOver event recovery path of the irq
handler while it races with the NAPI Rx processing method.
Ring indexes init is now done before enabling hardware Rx / Tx.
NB: this is not a straight candidate for -stable since it is coupled
with commit 92fc43b4159b518f5baae57301f26d770b0834c9 (July 11).
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes <hayeswang@realtek.com>
---
drivers/net/r8169.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 05566b1..22b9c7a 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -717,7 +717,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
struct net_device *dev);
static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance);
static int rtl8169_init_ring(struct net_device *dev);
-static void rtl_hw_start(struct net_device *dev);
+static void rtl_start(struct net_device *dev);
static int rtl8169_close(struct net_device *dev);
static void rtl_set_rx_mode(struct net_device *dev);
static void rtl8169_tx_timeout(struct net_device *dev);
@@ -3589,8 +3589,6 @@ static void rtl_hw_reset(struct rtl8169_private *tp)
break;
udelay(100);
}
-
- rtl8169_init_ring_indexes(tp);
}
static int __devinit
@@ -3948,7 +3946,7 @@ static int rtl8169_open(struct net_device *dev)
rtl_pll_power_up(tp);
- rtl_hw_start(dev);
+ rtl_start(dev);
tp->saved_wolopts = 0;
pm_runtime_put_noidle(&pdev->dev);
@@ -4014,10 +4012,14 @@ static void rtl_set_rx_tx_config_registers(struct rtl8169_private *tp)
(InterFrameGap << TxInterFrameGapShift));
}
-static void rtl_hw_start(struct net_device *dev)
+static void rtl_start(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
+ rtl8169_init_ring_indexes(tp);
+
+ smp_mb();
+
tp->hw_start(dev);
netif_start_queue(dev);
@@ -4997,7 +4999,7 @@ static void rtl8169_reset_task(struct work_struct *work)
rtl8169_tx_clear(tp);
rtl8169_hw_reset(tp);
- rtl_hw_start(dev);
+ rtl_start(dev);
netif_wake_queue(dev);
rtl8169_check_link_status(dev, tp, tp->mmio_addr);
--
1.7.6
[-- Attachment #2: 0003-r8169-remove-erroneous-processing-of-always-set-bit.patch --]
[-- Type: text/plain, Size: 1589 bytes --]
>From 44071c614418d9cae2faab8307307578d104065b Mon Sep 17 00:00:00 2001
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 25 Aug 2011 18:47:24 +0200
Subject: [PATCH 3/3] r8169: remove erroneous processing of always set bit.
When set, RxFOVF (resp. RxBOVF) is always 1 (resp. 0).
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes <hayeswang@realtek.com>
---
drivers/net/r8169.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 22b9c7a..19b91a8 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -407,6 +407,7 @@ enum rtl_register_content {
RxOK = 0x0001,
/* RxStatusDesc */
+ RxBOVF = (1 << 24),
RxFOVF = (1 << 23),
RxRWT = (1 << 22),
RxRES = (1 << 21),
@@ -682,6 +683,7 @@ struct rtl8169_private {
struct mii_if_info mii;
struct rtl8169_counters counters;
u32 saved_wolopts;
+ u32 opts1_mask;
struct rtl_fw {
const struct firmware *fw;
@@ -3782,6 +3784,9 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->intr_event = cfg->intr_event;
tp->napi_event = cfg->napi_event;
+ tp->opts1_mask = (tp->mac_version != RTL_GIGA_MAC_VER_01) ?
+ ~(RxBOVF | RxFOVF) : ~0;
+
init_timer(&tp->timer);
tp->timer.data = (unsigned long) dev;
tp->timer.function = rtl8169_phy_timer;
@@ -5323,7 +5328,7 @@ static int rtl8169_rx_interrupt(struct net_device *dev,
u32 status;
rmb();
- status = le32_to_cpu(desc->opts1);
+ status = le32_to_cpu(desc->opts1) & tp->opts1_mask;
if (status & DescOwn)
break;
--
1.7.6
^ permalink raw reply related
* Re: [PATCH -v2] netconsole: switch init_netconsole() to late_initcall if build-in
From: Andrew Morton @ 2011-09-13 8:01 UTC (permalink / raw)
To: Lin Ming; +Cc: David S. Miller, lkml, netdev, Jeff Kirsher
In-Reply-To: <1315899939.3402.2.camel@snb>
On Tue, 13 Sep 2011 15:45:39 +0800 Lin Ming <ming.m.lin@intel.com> wrote:
> Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
> regression that netconsole does not work if netconsole and network
> device driver are build into kernel, because netconsole is linked
> before network device driver.
>
> Andrew Morton suggested to fix this with initcall ordering.
> Fixes it by switching init_netconsole() to late_initcall if build-in.
>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> ---
> drivers/net/netconsole.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
> index dfc8272..914be29 100644
> --- a/drivers/net/netconsole.c
> +++ b/drivers/net/netconsole.c
> @@ -799,5 +799,9 @@ static void __exit cleanup_netconsole(void)
> }
> }
>
> +#ifdef MODULE
> module_init(init_netconsole);
> module_exit(cleanup_netconsole);
> +#else
> +late_initcall(init_netconsole);
> +#endif /* !MODULE */
The ifdefs (which should have used CONFIG_MODULE) aren't needed.
Because late_initcall() and module_init() are identical if
CONFIG_MODULE, and because one day we might want to run the exitcalls
for built-in code (UML actually does this at present).
^ permalink raw reply
* Re: [PATCH -v2] netconsole: switch init_netconsole() to late_initcall if build-in
From: Américo Wang @ 2011-09-13 7:55 UTC (permalink / raw)
To: Lin Ming; +Cc: David S. Miller, Andrew Morton, lkml, netdev, Jeff Kirsher
In-Reply-To: <1315899939.3402.2.camel@snb>
On Tue, Sep 13, 2011 at 3:45 PM, Lin Ming <ming.m.lin@intel.com> wrote:
> Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
> regression that netconsole does not work if netconsole and network
> device driver are build into kernel, because netconsole is linked
> before network device driver.
>
> Andrew Morton suggested to fix this with initcall ordering.
> Fixes it by switching init_netconsole() to late_initcall if build-in.
>
Putting one or two lines of comments into the code would
be nicer, otherwise people have to dig git log to see why. ;-)
Thanks!
^ permalink raw reply
* [PATCH -v2] netconsole: switch init_netconsole() to late_initcall if build-in
From: Lin Ming @ 2011-09-13 7:45 UTC (permalink / raw)
To: David S. Miller; +Cc: Andrew Morton, lkml, netdev, Jeff Kirsher
Commit 88491d8(drivers/net: Kconfig & Makefile cleanup) causes a
regression that netconsole does not work if netconsole and network
device driver are build into kernel, because netconsole is linked
before network device driver.
Andrew Morton suggested to fix this with initcall ordering.
Fixes it by switching init_netconsole() to late_initcall if build-in.
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
---
drivers/net/netconsole.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index dfc8272..914be29 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -799,5 +799,9 @@ static void __exit cleanup_netconsole(void)
}
}
+#ifdef MODULE
module_init(init_netconsole);
module_exit(cleanup_netconsole);
+#else
+late_initcall(init_netconsole);
+#endif /* !MODULE */
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH net-next-2.6] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Wolfgang Grandegger @ 2011-09-13 7:38 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: SocketCAN Core Mailing List, Netdev-u79uwXL29TY76Z2rM5mHXA,
linux-g4cQ8AsIbFbL9ATBNaCtXw, Thomas Wiedemann
In-Reply-To: <4E6E2A21.7010701-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Hi Oliver,
On 09/12/2011 05:49 PM, Oliver Hartkopp wrote:
> On 09/09/11 17:20, Wolfgang Grandegger wrote:
>
>
>>
>>> I'll also test your driver on Monday.
>>
>> Thanks,
>
>
> Hi Wolfgang,
>
> even if i only had my hardware-patched PEAK PCI ExpressCard hardware here
> (which is to be removed in the supported PCI device list due to the missing
> I2C initialization), i successfully tested your driver.
>
> Tested-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Thanks, I have just sent v2.
> So let's wait for some feedback from Thomas, when he's back to the office ;-)
Yep, some testing on a 4 channel card would be nice.
Wolfgang.
^ permalink raw reply
* Build-a-home-based-business-on-Auto-Pilot-
From: Dan Pereira @ 2011-09-12 16:25 UTC (permalink / raw)
To: netdev
Hello Everyone,
Discover how average people who have never made a cent in the past
Are now making $1,000+ every month,
With the Potential of making $50,000 a month
Just "Plug In"... to Your
Own Fully Automated
Turn Key...Global Marketing $ystem
Receive $500-$3,500 Monthly or MORE
Not MLM...and
No Selling...
No Cold Phone Calling.
Complete plug-in-system!
Check-it-Out!
http://trckrs.com/48184/rc1
It’s surprisingly cool!
Dan and Noel
His was a Com.Merical adv.Sent to you by:Dan Pereira, 11383 Golf Road, Turlock, CA 95380
In compliance with Federal law, should you choose to Un.Subscribe from our network, you may do so using theUn.Subscribe instruction found below. We are fully compliant with CAN-SPAM Act of 2005-Please use the Un.Subscribe link provided:
To remove this email address from further mailings click on the link below while connected to the internet.
http://www.reliablecontact.com/cgi-bin/maxsponder/maxuseradmin.cgi?function=manualdelete3&email=netdev*vger.kernel.org&un=richardpereira
^ permalink raw reply
* Re: [PATCH] MAINTANERS: update Qualcomm Atheros addresses
From: Kalle Valo @ 2011-09-13 7:17 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville, linux-wireless, linux-kernel, yangjie,
Luis R. Rodriguez, stable, netdev, jouni, vthiagar, senthilb
In-Reply-To: <1314137251-32096-1-git-send-email-lrodriguez@qca.qualcomm.com>
On 08/24/2011 01:07 AM, Luis R. Rodriguez wrote:
> From: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
>
> Qualcomm ate up Atheros, all of the old e-mail addresses
> no longer work and e-mails sent to it will bounce. Update
> the addresses to the new shiny Qualcomm Atheros (QCA) ones.
>
> Cc: stable@kernel.org
> Cc: netdev@vger.kernel.org
> Cc: jouni@qca.qualcomm.com
> Cc: yangjie@qca.qualcomm.com
> Cc: vthiagar@qca.qualcomm.com
> Cc: senthilb@qca.qualcomm.com
> Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
> ---
>
> John, I've left out ath6kl as you removed that so I take it
> the respective MAINTAINERS entry was deleted as well (although
> I do not see this on wireless-testing.git)
Actually I forgot the MAINTAINERS file altogether, thanks for reminding.
Shortly I'll send a patch to linux-wireless which updates the ath6kl entry.
Kalle
^ permalink raw reply
* [PATCH net-next-2.6 v2] can/sja1000: driver for PEAK PCAN PCI/PCIe cards
From: Wolfgang Grandegger @ 2011-09-13 7:16 UTC (permalink / raw)
To: Netdev-u79uwXL29TY76Z2rM5mHXA
Cc: SocketCAN Core Mailing List, Oliver Hartkopp, Thomas Wiedemann,
Marc Kleine-Budde
This patch add the peak_pci driver for the PCAN PCI/PCIe cards (1, 2, 3
or 4 channels) from PEAK Systems (http://www.peak-system.com).
Signed-off-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Tested-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
---
Changes since v1:
- Remove support for the PCAN ExpressCards (device ID 0x0002) as it
is not yet complete, e.g. I2C initialisations to enable the CAN
transceiver (and the funky status LEDs) is missing.
drivers/net/can/sja1000/Kconfig | 7 +
drivers/net/can/sja1000/Makefile | 1 +
drivers/net/can/sja1000/peak_pci.c | 291 ++++++++++++++++++++++++++++++++++++
3 files changed, 299 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/can/sja1000/peak_pci.c
diff --git a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
index 6fdc031..72b637d 100644
--- a/drivers/net/can/sja1000/Kconfig
+++ b/drivers/net/can/sja1000/Kconfig
@@ -37,6 +37,13 @@ config CAN_EMS_PCI
CPC-PCIe and CPC-104P cards from EMS Dr. Thomas Wuensche
(http://www.ems-wuensche.de).
+config CAN_PEAK_PCI
+ tristate "PEAK PCAN PCI/PCIe Cards"
+ depends on PCI
+ ---help---
+ This driver is for the PCAN PCI/PCIe cards (1, 2, 3 or 4 channels)
+ from PEAK Systems (http://www.peak-system.com).
+
config CAN_KVASER_PCI
tristate "Kvaser PCIcanx and Kvaser PCIcan PCI Cards"
depends on PCI
diff --git a/drivers/net/can/sja1000/Makefile b/drivers/net/can/sja1000/Makefile
index 2c591eb..428f5cf 100644
--- a/drivers/net/can/sja1000/Makefile
+++ b/drivers/net/can/sja1000/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CAN_SJA1000_PLATFORM) += sja1000_platform.o
obj-$(CONFIG_CAN_SJA1000_OF_PLATFORM) += sja1000_of_platform.o
obj-$(CONFIG_CAN_EMS_PCI) += ems_pci.o
obj-$(CONFIG_CAN_KVASER_PCI) += kvaser_pci.o
+obj-$(CONFIG_CAN_PEAK_PCI) += peak_pci.o
obj-$(CONFIG_CAN_PLX_PCI) += plx_pci.o
obj-$(CONFIG_CAN_TSCAN1) += tscan1.o
diff --git a/drivers/net/can/sja1000/peak_pci.c b/drivers/net/can/sja1000/peak_pci.c
new file mode 100644
index 0000000..905bce0
--- /dev/null
+++ b/drivers/net/can/sja1000/peak_pci.c
@@ -0,0 +1,291 @@
+/*
+ * Copyright (C) 2007, 2011 Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
+ *
+ * Derived from the PCAN project file driver/src/pcan_pci.c:
+ *
+ * Copyright (C) 2001-2006 PEAK System-Technik GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the version 2 of the GNU General Public License
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/netdevice.h>
+#include <linux/delay.h>
+#include <linux/pci.h>
+#include <linux/io.h>
+#include <linux/can.h>
+#include <linux/can/dev.h>
+
+#include "sja1000.h"
+
+MODULE_AUTHOR("Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>");
+MODULE_DESCRIPTION("Socket-CAN driver for PEAK PCAN PCI/PCIe cards");
+MODULE_SUPPORTED_DEVICE("PEAK PCAN PCI/PCIe CAN card");
+MODULE_LICENSE("GPL v2");
+
+#define DRV_NAME "peak_pci"
+
+struct peak_pci_chan {
+ void __iomem *cfg_base; /* Common for all channels */
+ struct net_device *next_dev; /* Chain of network devices */
+ u16 icr_mask; /* Interrupt mask for fast ack */
+};
+
+#define PEAK_PCI_CAN_CLOCK (16000000 / 2)
+
+#define PEAK_PCI_CDR (CDR_CBP | CDR_CLKOUT_MASK)
+#define PEAK_PCI_OCR OCR_TX0_PUSHPULL
+
+/*
+ * Important PITA registers
+ */
+#define PITA_ICR 0x00 /* Interrupt control register */
+#define PITA_GPIOICR 0x18 /* GPIO interface control register */
+#define PITA_MISC 0x1C /* Miscellaneous register */
+
+#define PEAK_PCI_CFG_SIZE 0x1000 /* Size of the config PCI bar */
+#define PEAK_PCI_CHAN_SIZE 0x0400 /* Size used by the channel */
+
+#define PEAK_PCI_VENDOR_ID 0x001C /* The PCI device and vendor IDs */
+#define PEAK_PCI_DEVICE_ID 0x0001 /* for PCI/PCIe slot cards */
+
+static const u16 peak_pci_icr_masks[] = {0x02, 0x01, 0x40, 0x80};
+
+static DEFINE_PCI_DEVICE_TABLE(peak_pci_tbl) = {
+ {PEAK_PCI_VENDOR_ID, PEAK_PCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {0,}
+};
+
+MODULE_DEVICE_TABLE(pci, peak_pci_tbl);
+
+static u8 peak_pci_read_reg(const struct sja1000_priv *priv, int port)
+{
+ return readb(priv->reg_base + (port << 2));
+}
+
+static void peak_pci_write_reg(const struct sja1000_priv *priv,
+ int port, u8 val)
+{
+ writeb(val, priv->reg_base + (port << 2));
+}
+
+static void peak_pci_post_irq(const struct sja1000_priv *priv)
+{
+ struct peak_pci_chan *chan = priv->priv;
+ u16 icr;
+
+ /* Select and clear in PITA stored interrupt */
+ icr = readw(chan->cfg_base + PITA_ICR);
+ if (icr & chan->icr_mask)
+ writew(chan->icr_mask, chan->cfg_base + PITA_ICR);
+}
+
+static int __devinit peak_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ struct sja1000_priv *priv;
+ struct peak_pci_chan *chan;
+ struct net_device *dev, *dev0 = NULL;
+ void __iomem *cfg_base, *reg_base;
+ u16 sub_sys_id, icr;
+ int i, err, channels;
+
+ err = pci_enable_device(pdev);
+ if (err)
+ return err;
+
+ err = pci_request_regions(pdev, DRV_NAME);
+ if (err)
+ goto failure_disable_pci;
+
+ err = pci_read_config_word(pdev, 0x2e, &sub_sys_id);
+ if (err)
+ goto failure_release_regions;
+
+ dev_dbg(&pdev->dev, "probing device %04x:%04x:%04x\n",
+ pdev->vendor, pdev->device, sub_sys_id);
+
+ err = pci_write_config_word(pdev, 0x44, 0);
+ if (err)
+ goto failure_release_regions;
+
+ if (sub_sys_id >= 12)
+ channels = 4;
+ else if (sub_sys_id >= 10)
+ channels = 3;
+ else if (sub_sys_id >= 4)
+ channels = 2;
+ else
+ channels = 1;
+
+ cfg_base = pci_iomap(pdev, 0, PEAK_PCI_CFG_SIZE);
+ if (!cfg_base) {
+ dev_err(&pdev->dev, "failed to map PCI resource #0\n");
+ goto failure_release_regions;
+ }
+
+ reg_base = pci_iomap(pdev, 1, PEAK_PCI_CHAN_SIZE * channels);
+ if (!reg_base) {
+ dev_err(&pdev->dev, "failed to map PCI resource #1\n");
+ goto failure_unmap_cfg_base;
+ }
+
+ /* Set GPIO control register */
+ writew(0x0005, cfg_base + PITA_GPIOICR + 2);
+ /* Enable all channels of this card */
+ writeb(0x00, cfg_base + PITA_GPIOICR);
+ /* Toggle reset */
+ writeb(0x05, cfg_base + PITA_MISC + 3);
+ mdelay(5);
+ /* Leave parport mux mode */
+ writeb(0x04, cfg_base + PITA_MISC + 3);
+
+ icr = readw(cfg_base + PITA_ICR + 2);
+
+ for (i = 0; i < channels; i++) {
+ dev = alloc_sja1000dev(sizeof(struct peak_pci_chan));
+ if (!dev) {
+ err = -ENOMEM;
+ goto failure_remove_channels;
+ }
+
+ priv = netdev_priv(dev);
+ chan = priv->priv;
+
+ chan->cfg_base = cfg_base;
+ priv->reg_base = reg_base + i * PEAK_PCI_CHAN_SIZE;
+
+ priv->read_reg = peak_pci_read_reg;
+ priv->write_reg = peak_pci_write_reg;
+ priv->post_irq = peak_pci_post_irq;
+
+ priv->can.clock.freq = PEAK_PCI_CAN_CLOCK;
+ priv->ocr = PEAK_PCI_OCR;
+ priv->cdr = PEAK_PCI_CDR;
+ /* Neither a slave nor a single device distributes the clock */
+ if (channels == 1 || i > 0)
+ priv->cdr |= CDR_CLK_OFF;
+
+ /* Setup interrupt handling */
+ priv->irq_flags = IRQF_SHARED;
+ dev->irq = pdev->irq;
+
+ chan->icr_mask = peak_pci_icr_masks[i];
+ icr |= chan->icr_mask;
+
+ SET_NETDEV_DEV(dev, &pdev->dev);
+
+ err = register_sja1000dev(dev);
+ if (err) {
+ dev_err(&pdev->dev, "failed to register device\n");
+ free_sja1000dev(dev);
+ goto failure_remove_channels;
+ }
+
+ /* Create chain of SJA1000 devices */
+ if (i == 0)
+ dev0 = dev;
+ else
+ chan->next_dev = dev;
+
+ dev_info(&pdev->dev,
+ "%s at reg_base=0x%p cfg_base=0x%p irq=%d\n",
+ dev->name, priv->reg_base, chan->cfg_base, dev->irq);
+ }
+
+ pci_set_drvdata(pdev, dev0);
+
+ /* Enable interrupts */
+ writew(icr, cfg_base + PITA_ICR + 2);
+
+ return 0;
+
+failure_remove_channels:
+ /* Disable interrupts */
+ writew(0x0, cfg_base + PITA_ICR + 2);
+
+ for (dev = dev0; dev; dev = chan->next_dev) {
+ unregister_sja1000dev(dev);
+ free_sja1000dev(dev);
+ priv = netdev_priv(dev);
+ chan = priv->priv;
+ dev = chan->next_dev;
+ }
+
+ pci_iounmap(pdev, reg_base);
+
+failure_unmap_cfg_base:
+ pci_iounmap(pdev, cfg_base);
+
+failure_release_regions:
+ pci_release_regions(pdev);
+
+failure_disable_pci:
+ pci_disable_device(pdev);
+
+ return err;
+}
+
+static void __devexit peak_pci_remove(struct pci_dev *pdev)
+{
+ struct net_device *dev = pci_get_drvdata(pdev); /* First device */
+ struct sja1000_priv *priv = netdev_priv(dev);
+ struct peak_pci_chan *chan = priv->priv;
+ void __iomem *cfg_base = chan->cfg_base;
+ void __iomem *reg_base = priv->reg_base;
+
+ /* Disable interrupts */
+ writew(0x0, cfg_base + PITA_ICR + 2);
+
+ /* Loop over all registered devices */
+ while (1) {
+ dev_info(&pdev->dev, "removing device %s\n", dev->name);
+ unregister_sja1000dev(dev);
+ free_sja1000dev(dev);
+ dev = chan->next_dev;
+ if (!dev)
+ break;
+ priv = netdev_priv(dev);
+ chan = priv->priv;
+ }
+
+ pci_iounmap(pdev, reg_base);
+ pci_iounmap(pdev, cfg_base);
+ pci_release_regions(pdev);
+ pci_disable_device(pdev);
+
+ pci_set_drvdata(pdev, NULL);
+}
+
+static struct pci_driver peak_pci_driver = {
+ .name = DRV_NAME,
+ .id_table = peak_pci_tbl,
+ .probe = peak_pci_probe,
+ .remove = __devexit_p(peak_pci_remove),
+};
+
+static int __init peak_pci_init(void)
+{
+ return pci_register_driver(&peak_pci_driver);
+}
+module_init(peak_pci_init);
+
+static void __exit peak_pci_exit(void)
+{
+ pci_unregister_driver(&peak_pci_driver);
+}
+module_exit(peak_pci_exit);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] per-cgroup tcp buffer limitation
From: Greg Thelen @ 2011-09-13 6:56 UTC (permalink / raw)
To: Glauber Costa
Cc: Paul Menage, linux-kernel, linux-mm, containers, netdev, xemul,
David S. Miller, Hiroyouki Kamezawa, Eric W. Biederman,
Suleiman Souhlal, Lennart Poettering
In-Reply-To: <4E6E39DD.2040102@parallels.com>
On Mon, Sep 12, 2011 at 9:57 AM, Glauber Costa <glommer@parallels.com> wrote:
> On 09/12/2011 02:03 AM, Paul Menage wrote:
>> I definitely think that there was no consensus reached on unified
>> versus split charging - but I think that we can work around that and
>> keep everyone happy, see below.
>
> I think at this point there is at least consensus that this could very well
> live in memcg, right ?
Yes, I think it should live in memcg.
>> On the subject of filesystems specifically, see Greg Thelen's proposal
>> for using bind mounts to account on a bind mount to a given cgroup -
>> that could apply to dentries, page tables and other kernel memory as
>> well as page cache.
>
> Care to point me to it ?
http://marc.info/?t=127749867100004&r=1&w=2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH net-next] tcp: md5: remove one indirection level in tcp_md5sig_pool
From: Eric Dumazet @ 2011-09-13 6:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
tcp_md5sig_pool is currently an 'array' (a percpu object) of pointers to
struct tcp_md5sig_pool. Only the pointers are NUMA aware, but objects
themselves are all allocated on a single node.
Remove this extra indirection to get proper percpu memory (NUMA aware)
and make code simpler.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
Note: crypto_alloc_hash() is still not NUMA aware...
include/net/tcp.h | 2 +-
net/ipv4/tcp.c | 41 +++++++++++++++++------------------------
2 files changed, 18 insertions(+), 25 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 149a415..d6ca000 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1180,7 +1180,7 @@ extern int tcp_v4_md5_do_del(struct sock *sk, __be32 addr);
#define tcp_twsk_md5_key(twsk) NULL
#endif
-extern struct tcp_md5sig_pool * __percpu *tcp_alloc_md5sig_pool(struct sock *);
+extern struct tcp_md5sig_pool __percpu *tcp_alloc_md5sig_pool(struct sock *);
extern void tcp_free_md5sig_pool(void);
extern struct tcp_md5sig_pool *tcp_get_md5sig_pool(void);
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 46febca..6508115 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2857,26 +2857,25 @@ EXPORT_SYMBOL(tcp_gro_complete);
#ifdef CONFIG_TCP_MD5SIG
static unsigned long tcp_md5sig_users;
-static struct tcp_md5sig_pool * __percpu *tcp_md5sig_pool;
+static struct tcp_md5sig_pool __percpu *tcp_md5sig_pool;
static DEFINE_SPINLOCK(tcp_md5sig_pool_lock);
-static void __tcp_free_md5sig_pool(struct tcp_md5sig_pool * __percpu *pool)
+static void __tcp_free_md5sig_pool(struct tcp_md5sig_pool __percpu *pool)
{
int cpu;
+
for_each_possible_cpu(cpu) {
- struct tcp_md5sig_pool *p = *per_cpu_ptr(pool, cpu);
- if (p) {
- if (p->md5_desc.tfm)
- crypto_free_hash(p->md5_desc.tfm);
- kfree(p);
- }
+ struct tcp_md5sig_pool *p = per_cpu_ptr(pool, cpu);
+
+ if (p->md5_desc.tfm)
+ crypto_free_hash(p->md5_desc.tfm);
}
free_percpu(pool);
}
void tcp_free_md5sig_pool(void)
{
- struct tcp_md5sig_pool * __percpu *pool = NULL;
+ struct tcp_md5sig_pool __percpu *pool = NULL;
spin_lock_bh(&tcp_md5sig_pool_lock);
if (--tcp_md5sig_users == 0) {
@@ -2889,30 +2888,24 @@ void tcp_free_md5sig_pool(void)
}
EXPORT_SYMBOL(tcp_free_md5sig_pool);
-static struct tcp_md5sig_pool * __percpu *
+static struct tcp_md5sig_pool __percpu *
__tcp_alloc_md5sig_pool(struct sock *sk)
{
int cpu;
- struct tcp_md5sig_pool * __percpu *pool;
+ struct tcp_md5sig_pool __percpu *pool;
- pool = alloc_percpu(struct tcp_md5sig_pool *);
+ pool = alloc_percpu(struct tcp_md5sig_pool);
if (!pool)
return NULL;
for_each_possible_cpu(cpu) {
- struct tcp_md5sig_pool *p;
struct crypto_hash *hash;
- p = kzalloc(sizeof(*p), sk->sk_allocation);
- if (!p)
- goto out_free;
- *per_cpu_ptr(pool, cpu) = p;
-
hash = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
if (!hash || IS_ERR(hash))
goto out_free;
- p->md5_desc.tfm = hash;
+ per_cpu_ptr(pool, cpu)->md5_desc.tfm = hash;
}
return pool;
out_free:
@@ -2920,9 +2913,9 @@ out_free:
return NULL;
}
-struct tcp_md5sig_pool * __percpu *tcp_alloc_md5sig_pool(struct sock *sk)
+struct tcp_md5sig_pool __percpu *tcp_alloc_md5sig_pool(struct sock *sk)
{
- struct tcp_md5sig_pool * __percpu *pool;
+ struct tcp_md5sig_pool __percpu *pool;
int alloc = 0;
retry:
@@ -2941,7 +2934,7 @@ retry:
if (alloc) {
/* we cannot hold spinlock here because this may sleep. */
- struct tcp_md5sig_pool * __percpu *p;
+ struct tcp_md5sig_pool __percpu *p;
p = __tcp_alloc_md5sig_pool(sk);
spin_lock_bh(&tcp_md5sig_pool_lock);
@@ -2974,7 +2967,7 @@ EXPORT_SYMBOL(tcp_alloc_md5sig_pool);
*/
struct tcp_md5sig_pool *tcp_get_md5sig_pool(void)
{
- struct tcp_md5sig_pool * __percpu *p;
+ struct tcp_md5sig_pool __percpu *p;
local_bh_disable();
@@ -2985,7 +2978,7 @@ struct tcp_md5sig_pool *tcp_get_md5sig_pool(void)
spin_unlock(&tcp_md5sig_pool_lock);
if (p)
- return *this_cpu_ptr(p);
+ return this_cpu_ptr(p);
local_bh_enable();
return NULL;
^ permalink raw reply related
* Re: [PATCH] net: change capability used by socket options IP{,V6}_TRANSPARENT
From: Maciej Żenczykowski @ 2011-09-13 5:55 UTC (permalink / raw)
To: Balazs Scheidler; +Cc: netdev
In-Reply-To: <1314990654-32252-1-git-send-email-zenczykowski@gmail.com>
Comments?
^ permalink raw reply
* Uw mailbox is bijna vol.
From: De beheerder van het systeem. @ 2011-09-13 5:22 UTC (permalink / raw)
System Administrator
Uw mailbox is bijna vol.
23 GB 20 GB
Uw mailbox heeft overschreden de opslag limiet van 20 GB
wordt bepaald door de beheerder, het werk 20.9GB, die
misschien niet in staat zijn om berichten verzenden of ontvangen
totdat u een upgrade
mailbox. Te valideren uw mailbox, vul dan onderstaand klik op de link
en bevestig
hun gegevens voor de upgrade:
http://buzurl.com/bi01
Vul uw gegevens in de bovenstaande link en klik op SUBMIT
-Send File
bedankt
De beheerder van het systeem.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: 3.1-rc4: spectacular kernel errors / filesystem crash
From: Eric Dumazet @ 2011-09-13 4:05 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Justin Piszcz, linux-kernel, xfs, Alan Piszcz, NetDEV list
In-Reply-To: <CAEuXFEzs1f7n5taYzupux3AtKmRcY4P0m7yjkUQA8aLyS8eujw@mail.gmail.com>
Le lundi 12 septembre 2011 à 20:59 -0700, Jesse Brandeburg a écrit :
> added netdev because it appears to start with an igb tx hang
>
> On Sun, Sep 11, 2011 at 2:40 AM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
> > Hi,
> >
> > Over the past 24-48 hours I was running some CPU-intenstive jobs and there
> > was heavy I/O on the RAID (9750-24i4e + a RAID6)..
> >
> > I believe most of the problem started when I included many kernel options as
> > modules (before I only compiled in [*] the drivers I used), there appears to
> > have something to gone awry in the kernel and then afterwards, disks started
> > going in and out, XFS shut down, etcera.
> >
> > I'm opening a case with LSI to see what happened with the 3ware card;
> > however, after a power cycle, everything came back OK (the drives and HW) is
> > physically OK, it is rebuilding onto those two drives with CFG-OP-FAIL but
> > other than that, everything 'seems' OK, still need to do an fsck.
> >
> > Something went wrong in the kernel and caused a cascading effect of errors,
> > this occurred (I believe) when I started to run a lot of encoding jobs;
> > however, I was doing a lot of data transfer for the past 24-48 hours on the
> > RAID array, the system (separate SSD/EXT4) remained unaffected but other
> > weird stuff happened as well..
> >
> > I still see these in the logs as well after the reboot (not often; but e.g.,
> > the RAID controller is rebuilding from the two drives with CFG-OPT-FAIL (the
> > physical drives are 100% healthy):
> >
> > [ 1062.925904] 3w-sas 0000:83:00.0: vpd r/w failed. This is likely a
> > firmware bug on this device. Contact the card vendor for a firmware update.
> >
> > So, my plan:
> >
> > 1. Report this error to LKML+XFS mailing lists.
> > 2. Open case with LSI support.
> > 3. Recompile the kernel how I used for many years [only compile in options
> > that you need [*] and do not compile drivers as modules]
> > 4. Reboot Linux systems and see if this recurs again under the same
> > workload, after the RAID is done rebuilding.
> >
> > --
> >
> > So these errors are quite long, will upload to HTTP and paste the relevant
> > bits below.
> >
> > --
> >
> > URLs for FULL logs:
> >
> > 1. tw_cli /cX show diag:
> > http://home.comcast.net/~jpiszcz/20110911/show_diag.txt
> >
> > 2. Full kernel log (and previous morning of kernel crash)
> > http://home.comcast.net/~jpiszcz/20110911/kern.log.txt
> >
> > 3. tw_cli /cX show all
> > http://home.comcast.net/~jpiszcz/20110911/cfg-fail.txt
> >
> > --
> >
> > Summary (what seems to have occurred, have not done a full analysis yet)
> >
> > 1. 3ware card freaked out due to kernel/RCU/APIC(?) errors
> >
> > 2. Then, the time source went unstable (this happens with weird kernel bugs
> > on many different hosts, I have seen this over time).
> >
> > 3. Then, on the 3ward carde, drives started leaving and being re-inserted
> > by themsevles, XFS went off-line to protect the filesystem due to the
> > 3ware issues
> >
> > --
> >
> > 3ware/RAID-- Interesting errors:
> >
> > I've never seen this before on a 3ware RAID controller, at least from what
> > I can remember and I've been using 3ware cards for many years..
> >
> > p2 CFG-OP-FAIL - 2.73 TB SATA 2 - Hitachi
> > HDS723030AL p3 CFG-OP-FAIL - 2.73 TB SATA 3 -
> > Hitachi HDS723030AL
> >
> > --
> >
> > Kernel/ERRORS:
> >
> > FWIW it all seem to start during an encoding job around 21:00:
> >
> > Sep 10 18:00:00 p34 kernel: [520427.143054] ixgbe 0000:03:00.0: eth6: NIC
> > Link is Down
> > Sep 10 19:20:04 p34 kernel: [525223.256098] 3w-sas: scsi1: AEN: INFO
> > (0x04:0x002B): Verify completed:unit=0.
> > Sep 10 20:59:39 p34 kernel: [531189.671361] ------------[ cut here
> > ]------------
> > Sep 10 20:59:39 p34 kernel: [531189.671376] WARNING: at
> > net/sched/sch_generic.c:255 dev_watchdog+0x23f/0x250()
> > Sep 10 20:59:39 p34 kernel: [531189.671378] Hardware name: X8DTH-i/6/iF/6F
> > Sep 10 20:59:39 p34 kernel: [531189.671380] NETDEV WATCHDOG: eth1 (igb):
> > transmit queue 5 timed out
> > Sep 10 20:59:39 p34 kernel: [531189.671382] Modules linked in: dm_mod
> > tcp_diag parport_pc ppdev lp parport inet_diag pl2303 ftdi_sio snd_usb_audio
> > snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_usbmidi_lib
> > snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event
> > snd_seq snd_timer snd_seq_device snd soundcore ub cdc_acm usbserial joydev
> > serio_raw nouveau ttm drm_kms_helper drm agpgart i2c_algo_bit mxm_wmi wmi
> > i7core_edac edac_core video
> > Sep 10 20:59:39 p34 kernel: [531189.671414] Pid: 83, comm: ksoftirqd/19 Not
> > tainted 3.1.0-rc4 #1
> > Sep 10 20:59:39 p34 kernel: [531189.671415] Call Trace:
> > Sep 10 20:59:39 p34 kernel: [531189.671424] [<ffffffff810379ba>]
> > warn_slowpath_common+0x7a/0xb0
> > Sep 10 20:59:39 p34 kernel: [531189.671427] [<ffffffff81037a91>]
> > warn_slowpath_fmt+0x41/0x50
> > Sep 10 20:59:39 p34 kernel: [531189.671433] [<ffffffff815d7874>] ?
> > schedule+0x2e4/0x950
> > Sep 10 20:59:39 p34 kernel: [531189.671436] [<ffffffff814e5aff>]
> > dev_watchdog+0x23f/0x250
> > Sep 10 20:59:39 p34 kernel: [531189.671440] [<ffffffff81043872>]
> > run_timer_softirq+0xf2/0x220
> > Sep 10 20:59:39 p34 kernel: [531189.671443] [<ffffffff814e58c0>] ?
> > qdisc_reset+0x50/0x50
> > Sep 10 20:59:39 p34 kernel: [531189.671446] [<ffffffff8103d208>]
> > __do_softirq+0x98/0x120
> > Sep 10 20:59:39 p34 kernel: [531189.671448] [<ffffffff8103d345>]
> > run_ksoftirqd+0xb5/0x160
> > Sep 10 20:59:39 p34 kernel: [531189.671454] [<ffffffff8103d290>] ?
> > __do_softirq+0x120/0x120
> > Sep 10 20:59:39 p34 kernel: [531189.671458] [<ffffffff810523b7>]
> > kthread+0x87/0x90
> > Sep 10 20:59:39 p34 kernel: [531189.671462] [<ffffffff815dbdb4>]
> > kernel_thread_helper+0x4/0x10
> > Sep 10 20:59:39 p34 kernel: [531189.671465] [<ffffffff81052330>] ?
> > kthread_worker_fn+0x130/0x130
> > Sep 10 20:59:39 p34 kernel: [531189.671467] [<ffffffff815dbdb0>] ?
> > gs_change+0xb/0xb
> > Sep 10 20:59:39 p34 kernel: [531189.671468] ---[ end trace 553dfe731fce91ba
> > ]---
> > Sep 10 20:59:39 p34 kernel: [531189.671478] igb 0000:01:00.1: eth1: Reset
> > adapter
> > Sep 10 20:59:42 p34 kernel: [531192.826058] igb: eth1 NIC Link is Up 1000
> > Mbps Full Duplex, Flow Control: RX/TX
> > Sep 10 21:00:00 p34 kernel: [531210.034506] BUG: soft lockup - CPU#0 stuck
> > for 22s! [kswapd0:947]
> >
> > --
> >
> > URLs for FULL logs:
> >
> > 1. tw_cli /cX show diag:
> > http://home.comcast.net/~jpiszcz/20110911/show_diag.txt
> >
> > 2. Full kernel log (and previous morning of kernel crash)
> > http://home.comcast.net/~jpiszcz/20110911/kern.log.txt
> >
> > 3. tw_cli /cX show all
> > http://home.comcast.net/~jpiszcz/20110911/cfg-fail.txt
> >
> > --
> >
> > Currently...
> >
> > After all of this happened, I stopped all I/O on the system/all processes,
> > etc
> > I shutdown the host, removed the power, powered it back up, now the drives
> > that showed CFG-OP-FAIL before now show as REBUILDING, I am waiting for them
> > to rebuild before doing anything else.
> >
> > Justin.
> >
> >
Please Justin make sure you pulled commit
commit ed2888e906b56769b4ffabb9c577190438aa68b8
Author: Jon Mason <mason@myri.com>
Date: Thu Sep 8 16:41:18 2011 -0500
PCI: Remove MRRS modification from MPS setting code
Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has
massive negative ramifications on some devices. Without knowing which
devices have this issue, do not modify from the default value when
walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe
the default procedure.
Tested-by: Sven Schnelle <svens@stackframe.org>
Tested-by: Simon Kirby <sim@hostway.ca>
Tested-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reported-and-tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Reported-and-tested-by: Niels Ole Salscheider <niels_ole@salscheider-online.
References: https://bugzilla.kernel.org/show_bug.cgi?id=42162
Signed-off-by: Jon Mason <mason@myri.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
^ 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