Prev: Another set of nested svm fixes and optimizations
Next: Affordable Loan
From: Anton Vorontsov on 26 Feb 2010 09:40
On Fri, Feb 26, 2010 at 12:06:15PM +0000, Martyn Welch wrote:
> Anton Vorontsov wrote:
> > On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
> > [...]
> >
> >> I was able to reproduce it on an 8641D and bisected it down to this:
> >>
> >> -----------
> >> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
> >> Author: Anton Vorontsov <avorontsov(a)ru.mvista.com>
> >> Date: Tue Nov 10 14:11:10 2009 +0000
> >>
> >> gianfar: Revive SKB recycling
> >>
> >
> > Thanks for the bisect. I have a guess why tx hangs in
> > SMP case. Could anyone try the patch down below?
> >
>
> Yup, no problem. I'm afraid it doesn't resolve the problem for me.

Hm.. I found a p2020 board and I was able to reproduce the issue.
The patch down below fixed it completely for me... hm.

I'll look further, thanks!

> > [...]
> >
> >> ...which probably explains why you weren't seeing it on non-SMP.
> >> I'd imagine it would show up on any of the e500mc boards too.
> >>
> >
> > Yeah.. Pity, I don't have SMP boards anymore. I'll try
> > to get one though.
> >
> >
> > diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> > index 8bd3c9f..3ff3bd0 100644
> > --- a/drivers/net/gianfar.c
> > +++ b/drivers/net/gianfar.c
> > @@ -2614,6 +2614,8 @@ static int gfar_poll(struct napi_struct *napi, int budget)
> > tx_queue = priv->tx_queue[rx_queue->qindex];
> >
> > tx_cleaned += gfar_clean_tx_ring(tx_queue);
> > + if (!tx_cleaned && !tx_queue->num_txbdfree)
> > + tx_cleaned += 1; /* don't complete napi */
> > rx_cleaned_per_queue = gfar_clean_rx_ring(rx_queue,
> > budget_per_queue);
> > rx_cleaned += rx_cleaned_per_queue;
> >

--
Anton Vorontsov
email: cbouatmailru(a)gmail.com
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul Gortmaker on 26 Feb 2010 10:00
On 10-02-26 09:35 AM, Anton Vorontsov wrote:
> On Fri, Feb 26, 2010 at 12:06:15PM +0000, Martyn Welch wrote:
>> Anton Vorontsov wrote:
>>> On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
>>> [...]
>>>
>>>> I was able to reproduce it on an 8641D and bisected it down to this:
>>>>
>>>> -----------
>>>> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
>>>> Author: Anton Vorontsov<avorontsov(a)ru.mvista.com>
>>>> Date: Tue Nov 10 14:11:10 2009 +0000
>>>>
>>>> gianfar: Revive SKB recycling
>>>>
>>>
>>> Thanks for the bisect. I have a guess why tx hangs in
>>> SMP case. Could anyone try the patch down below?
>>>
>>
>> Yup, no problem. I'm afraid it doesn't resolve the problem for me.
>
> Hm.. I found a p2020 board and I was able to reproduce the issue.
> The patch down below fixed it completely for me... hm.

Interesting. I just tested the patch on the sbc8641d, and it
still has the issue with your patch applied. I'm using NFSroot
just like Martyn was and it still appears bound up on that
gianfar tx lock. I'll see if I can get a SysRq backtrace in
case that will help you see how it manages to get there...

Paul.

----

nfs: server not responding, still trying

[repeated ~15 times, then...]

INFO: task rc.sysinit:837 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
rc.sysinit D 0fef73f4 0 837 836 0x00000000
Call Trace:
[dfb7d9b0] [c000a144] __switch_to+0x8c/0xf8
[dfb7d9d0] [c03443dc] schedule+0x380/0x954
[dfb7da50] [c0344a0c] io_schedule+0x5c/0x90
[dfb7da70] [c0074b0c] sync_page+0x4c/0x74
[dfb7da80] [c0344f44] __wait_on_bit_lock+0xb0/0x148
[dfb7dab0] [c0074a8c] __lock_page+0x94/0xa4
[dfb7dae0] [c0074d5c] find_lock_page+0x8c/0xa4
[dfb7db00] [c0075674] filemap_fault+0x1ec/0x4fc
[dfb7db40] [c008d548] __do_fault+0x98/0x53c
[dfb7dba0] [c0018478] do_page_fault+0x2d0/0x500
[dfb7dc50] [c00149d4] handle_page_fault+0xc/0x80
--- Exception: 301 at __clear_user+0x14/0x7c
LR = load_elf_binary+0x670/0x1270
[dfb7dd10] [c00f6ca0] load_elf_binary+0x620/0x1270 (unreliable)
[dfb7dd90] [c00b1f78] search_binary_handler+0x17c/0x394
[dfb7dde0] [c00f4f50] load_script+0x274/0x288
[dfb7de90] [c00b1f78] search_binary_handler+0x17c/0x394
[dfb7dee0] [c00b3580] do_execve+0x240/0x29c
[dfb7df20] [c000a46c] sys_execve+0x68/0xa4
[dfb7df40] [c00145a4] ret_from_syscall+0x0/0x38

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Martyn Welch on 26 Feb 2010 10:20
Paul Gortmaker wrote:
> On 10-02-26 09:35 AM, Anton Vorontsov wrote:
>
>> On Fri, Feb 26, 2010 at 12:06:15PM +0000, Martyn Welch wrote:
>>
>>> Anton Vorontsov wrote:
>>>
>>>> On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
>>>> [...]
>>>>
>>>>
>>>>> I was able to reproduce it on an 8641D and bisected it down to this:
>>>>>
>>>>> -----------
>>>>> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
>>>>> Author: Anton Vorontsov<avorontsov(a)ru.mvista.com>
>>>>> Date: Tue Nov 10 14:11:10 2009 +0000
>>>>>
>>>>> gianfar: Revive SKB recycling
>>>>>
>>>>>
>>>> Thanks for the bisect. I have a guess why tx hangs in
>>>> SMP case. Could anyone try the patch down below?
>>>>
>>>>
>>> Yup, no problem. I'm afraid it doesn't resolve the problem for me.
>>>
>> Hm.. I found a p2020 board and I was able to reproduce the issue.
>> The patch down below fixed it completely for me... hm.
>>
>
> Interesting. I just tested the patch on the sbc8641d, and it
> still has the issue with your patch applied. I'm using NFSroot
> just like Martyn was and it still appears bound up on that
> gianfar tx lock. I'll see if I can get a SysRq backtrace in
> case that will help you see how it manages to get there...
>

I've got a p2020ds here as well, so I'll give NFSroot on that a try with
your patch.

Martyn



--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch(a)ge.com | M2 3AB VAT:GB 927559189

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Martyn Welch on 26 Feb 2010 10:40
Martyn Welch wrote:
> Paul Gortmaker wrote:
>
>> On 10-02-26 09:35 AM, Anton Vorontsov wrote:
>>
>>
>>> On Fri, Feb 26, 2010 at 12:06:15PM +0000, Martyn Welch wrote:
>>>
>>>
>>>> Anton Vorontsov wrote:
>>>>
>>>>
>>>>> On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
>>>>> [...]
>>>>>
>>>>>
>>>>>
>>>>>> I was able to reproduce it on an 8641D and bisected it down to this:
>>>>>>
>>>>>> -----------
>>>>>> commit a3bc1f11e9b867a4f49505ecac486a33af248b2e
>>>>>> Author: Anton Vorontsov<avorontsov(a)ru.mvista.com>
>>>>>> Date: Tue Nov 10 14:11:10 2009 +0000
>>>>>>
>>>>>> gianfar: Revive SKB recycling
>>>>>>
>>>>>>
>>>>>>
>>>>> Thanks for the bisect. I have a guess why tx hangs in
>>>>> SMP case. Could anyone try the patch down below?
>>>>>
>>>>>
>>>>>
>>>> Yup, no problem. I'm afraid it doesn't resolve the problem for me.
>>>>
>>>>
>>> Hm.. I found a p2020 board and I was able to reproduce the issue.
>>> The patch down below fixed it completely for me... hm.
>>>
>>>
>> Interesting. I just tested the patch on the sbc8641d, and it
>> still has the issue with your patch applied. I'm using NFSroot
>> just like Martyn was and it still appears bound up on that
>> gianfar tx lock. I'll see if I can get a SysRq backtrace in
>> case that will help you see how it manages to get there...
>>
>>
>
> I've got a p2020ds here as well, so I'll give NFSroot on that a try with
> your patch.
>

Out of 10 boot attempts, 7 failed.

Martyn

--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch(a)ge.com | M2 3AB VAT:GB 927559189

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Anton Vorontsov on 26 Feb 2010 11:20
On Fri, Feb 26, 2010 at 03:34:07PM +0000, Martyn Welch wrote:
[...]
> Out of 10 boot attempts, 7 failed.

OK, I see why. With ip=on (dhcp boot) it's much harder to trigger
it. With static ip config can I see the same.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Another set of nested svm fixes and optimizations
Next: Affordable Loan