Hi!
On Sat, Feb 27, 2010 at 11:05:32AM +0530, Kumar Gopalpet-B05799 wrote:
[...]
> Understood, and thanks for the explanation. Am I correct in saying that
> this is
> due to the out-of-order execution capability on powerpc ?
Nope, that was just a logic issue in the driver.
Though, with the patc
Anton Vorontsov wrote:
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 8bd3c9f..cccb409 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -2021,7 +2021,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
> net_device *dev)
> }
>
> /*
; da...@davemloft.net
>Subject: Re: Gianfar driver failing on MPC8641D based board
>
>On Fri, Feb 26, 2010 at 11:27:42AM -0500, Paul Gortmaker wrote:
>> On 10-02-26 11:10 AM, Anton Vorontsov wrote:
>> > On Fri, Feb 26, 2010 at 03:34:07PM +, Martyn Welch wrote:
>&
On 10-02-26 04:38 PM, Anton Vorontsov wrote:
> OK, I think I found what's happening in gianfar.
>
> Some background...
>
> start_xmit() prepares new skb for transmitting, generally it does
> three things:
>
> 1. sets up all BDs (marks them ready to send), except the first one.
> 2. stores skb i
On Fri, Feb 26, 2010 at 11:27:42AM -0500, Paul Gortmaker wrote:
> On 10-02-26 11:10 AM, Anton Vorontsov wrote:
> > On Fri, Feb 26, 2010 at 03:34:07PM +, Martyn Welch wrote:
> > [...]
> >> Out of 10 boot attempts, 7 failed.
> >
> > OK, I see why. With ip=on (dhcp boot) it's much harder to trigg
On 10-02-26 11:10 AM, Anton Vorontsov wrote:
> On Fri, Feb 26, 2010 at 03:34:07PM +, 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.
I'd kind of expected to
On 10-02-26 09:35 AM, Anton Vorontsov wrote:
> On Fri, Feb 26, 2010 at 12:06:15PM +, 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:
>>>
On Fri, Feb 26, 2010 at 03:34:07PM +, 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.
___
Linuxppc-dev mailing list
Linuxpp
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 +, Martyn Welch wrote:
>>>
>>>
Anton Vorontsov wrote:
> On Thu, Feb 25, 2010 at 07:53:30PM -0500,
Paul Gortmaker wrote:
> On 10-02-26 09:35 AM, Anton Vorontsov wrote:
>
>> On Fri, Feb 26, 2010 at 12:06:15PM +, Martyn Welch wrote:
>>
>>> Anton Vorontsov wrote:
>>>
On Thu, Feb 25, 2010 at 07:53:30PM -0500, Paul Gortmaker wrote:
[...]
> I was abl
On Fri, Feb 26, 2010 at 12:06:15PM +, 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 a3bc1f11e9b867a4f49
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
>> Date: Tue Nov 10 14:11:
Anton Vorontsov wrote:
> On Thu, Feb 25, 2010 at 04:46:54PM +, Martyn Welch wrote:
> [...]
>
>>> nfs: server 192.168.0.1 not responding, still trying
>>>
>>>
>> Further testing has shown that this isn't restricted to warm reboots, it
>> happens from cold as well. In addition, the e
@davemloft.net; Kumar Gala
>Subject: Re: Gianfar driver failing on MPC8641D based board
>
>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
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
> Date: Tue Nov 10 14:11:10 2009 +
>
> gianfar: Reviv
On Thu, Feb 25, 2010 at 12:49 PM, Anton Vorontsov
wrote:
> On Thu, Feb 25, 2010 at 07:51:41PM +0300, Anton Vorontsov wrote:
>> On Thu, Feb 25, 2010 at 04:46:54PM +, Martyn Welch wrote:
>> [...]
>> > > nfs: server 192.168.0.1 not responding, still trying
>> > >
>> >
>> > Further testing has sho
On Feb 25, 2010, at 10:46 AM, Martyn Welch wrote:
>
> Further testing has shown that this isn't restricted to warm reboots, it
> happens from cold as well. In addition, the exact timing of the failure
> seems to vary, some boots have got further before failing.
what mechanism do you use for war
On Thu, Feb 25, 2010 at 04:46:54PM +, Martyn Welch wrote:
[...]
> > nfs: server 192.168.0.1 not responding, still trying
> >
>
> Further testing has shown that this isn't restricted to warm reboots, it
> happens from cold as well. In addition, the exact timing of the failure
> seems to vary
Martyn Welch wrote:
> Martyn Welch wrote:
>
>> I have recently attempted to boot an 8641D based board from an NFS root.
>> The boot process grinds to a halt not long after the first access of the
>> NFS root and I receive multiple "nfs: server 192.168.0.1 not responding,
>> still trying" message
Martyn Welch wrote:
> I have recently attempted to boot an 8641D based board from an NFS root.
> The boot process grinds to a halt not long after the first access of the
> NFS root and I receive multiple "nfs: server 192.168.0.1 not responding,
> still trying" messages. Wireshark suggests that ther
I have recently attempted to boot an 8641D based board from an NFS root.
The boot process grinds to a halt not long after the first access of the
NFS root and I receive multiple "nfs: server 192.168.0.1 not responding,
still trying" messages. Wireshark suggests that there is no further
traffic from
21 matches
Mail list logo
