booting Linux in Linux using kexec tools

booting Linux in Linux using kexec tools

[Reddy Suneel-ASR125]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

Hi
 
I am trying to boot Linux (zImage.elf) in Linux using kexec tools. 
 
I am getting the folling crash
 
sh-2.05b#
sh-2.05b# kexec -e
Shutting down gianfar ethernet
Shutting down gianfar ethernet
Shutting down gianfar ethernet
Starting new kernel
Bye!
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: 2E5C0020 LR: C000A3CC SP: C8D97DF0 REGS: c8d97d40 TRAP: 0400    Not
taintedMSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK = c82f84a0[665] 'kexec' THREAD: c8d96000
Last syscall: 88
GPR00: 00000000 C8D97DF0 C82F84A0 2E5C1002 2E5C0000 00000000 00000F35
C0307DBC
GPR08: 2E5C0020 C0350000 00000000 C8D96000 00000000 10030450 00000220
100CBD88
GPR16: FFFFFFFF 00000000 00000000 00000000 00000000 00000000 FFFFFFFF
42202442
GPR24: 100D71C8 100D7508 2E5C1002 C0A8DC80 EE5C0000 2E5C0000 00000000
C0A8DC80
Call trace: [c000a2fc]  [c00302d0]  [c000206c]
Segmentation fault
sh-2.05b#
 
I am working on MPC8540 processor.
 
can any one help me.
 
Thanks&regards
Suneel

[-- Attachment #2: Type: text/html, Size: 2535 bytes --]

Re: booting Linux in Linux using kexec tools

[Guennadi Liakhovetski]

Hi Suneel

On Wed, 30 Aug 2006, Reddy Suneel-ASR125 wrote:

> I am trying to boot Linux (zImage.elf) in Linux using kexec tools. 
>  
> I am getting the folling crash
>  
> sh-2.05b#
> sh-2.05b# kexec -e
> Shutting down gianfar ethernet
> Shutting down gianfar ethernet
> Shutting down gianfar ethernet
> Starting new kernel
> Bye!
> Oops: kernel access of bad area, sig: 11 [#1]

Have you got it working? Where do your kexec tools come from? Are they 
based on a version from http://www.xmission.com/~ebiederm/files/kexec/ 
and, if yes, how did yo adjust it to your system?

Thanks
Guennadi
---
Guennadi Liakhovetski

MAC driver issues

[David H. Lynch Jr.]

I am trying to get a network driver working.

It sends - I can capture the output with Etherreal and it looks good.
It receives - I can dump the received packets when the come in and they 
look ok to me.


BUT,
    If I try to ping another host, first Linux sends and ARP broadcast, 
the appropriate client sends an ARP response.
    Etherreal is happy with both.
    My driver gets the response - The driver says the packet lenght is 
64 bytes, which includes something like 14 bytes of padding at the end.
    But the actual packet looks perfect exactly like what etherreal says 
it should (and what I get when I capture a received ARP packet in 
another driver).
    At the end of the recive interrupt the skb is passed to Linux with 
the netif_rc(ndev) function. This returns SUCCESS.

    However, the paket never gets handed of to the ARP protocol - I put 
some debugging in there and I never see it, while if I switch to a 
different  NIC
    driver nearly the identical ARP packet gets processed by arp inside 
Linux.

    I have tried to chase this down, but I can't  follow what is going 
on inside of all the /net/core/dev.c etc.

    Has anyone seen something similar to this ?

    Does anyone have a clue where I can find some info  on trying to 
follow something through netif_rx to see where things are going off the 
rails ?



-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: MAC driver issues

[Alex Zeffertt]

Hi David,

I think in order to get any help from this list you need to be more specific
about how this problem relates to PowerPCs.

You also need to say exactly what "never gets handed off to the ARP protocol"
means.

FWIW, in my experience the hardware independent parts of the networking stack are
very stable and the problem is almost always with the drivers, or with the IP
configuration (e.g. two interfaces on the same subnet).

Alex

David H. Lynch Jr. wrote:
> I am trying to get a network driver working.
> 
> It sends - I can capture the output with Etherreal and it looks good.
> It receives - I can dump the received packets when the come in and they 
> look ok to me.
> 
> 
> BUT,
>     If I try to ping another host, first Linux sends and ARP broadcast, 
> the appropriate client sends an ARP response.
>     Etherreal is happy with both.
>     My driver gets the response - The driver says the packet lenght is 
> 64 bytes, which includes something like 14 bytes of padding at the end.
>     But the actual packet looks perfect exactly like what etherreal says 
> it should (and what I get when I capture a received ARP packet in 
> another driver).
>     At the end of the recive interrupt the skb is passed to Linux with 
> the netif_rc(ndev) function. This returns SUCCESS.
> 
>     However, the paket never gets handed of to the ARP protocol - I put 
> some debugging in there and I never see it, while if I switch to a 
> different  NIC
>     driver nearly the identical ARP packet gets processed by arp inside 
> Linux.
> 
>     I have tried to chase this down, but I can't  follow what is going 
> on inside of all the /net/core/dev.c etc.
> 
>     Has anyone seen something similar to this ?
> 
>     Does anyone have a clue where I can find some info  on trying to 
> follow something through netif_rx to see where things are going off the 
> rails ?
> 
> 
> 

Re: MAC driver issue

[David H. Lynch Jr.]

Alex Zeffertt wrote:
> Hi David,
>
> I think in order to get any help from this list you need to be more 
> specific
> about how this problem relates to PowerPCs.
    The relationship is weak - the driver is for a NIC in an embedded 
PPC 405.
    I was just hoping that someone here might have experienced a similar 
problem and have an idea what the answer might be -
    rather than join another list - I am sure there must be something 
like a network drivers list


>
> You also need to say exactly what "never gets handed off to the ARP 
> protocol"
> means.

    I mean I put a printk into the ARP protocol handler and in the 
working case I get to the prink, and in the failing case I don't.

    I have tried inspecting  netif_rx - but  it just queues up received 
packets - and in both my cases returns success.

    I am basically tryng to figure out what is it that the inbound 
network stack is upset about - somewhere it must have decided to reject
    my data, if I knew what it did not like, I would have a clue what to 
fix.  

> FWIW, in my experience the hardware independent parts of the 
> networking stack are
> very stable and the problem is almost always with the drivers, or with 
> the IP
> configuration (e.g. two interfaces on the same subnet).
    I have no doubt it is with the driver.  I am somewhat fortunate in 
this instance that I have a nearly identical setup - this is an FPGA 
based system
    I can swap the FPGA firmware, get an almost identical kernel with a 
slightly different NIC, and everything works - same cables, same IP's,
    Same switch, The only things different are the NIC and its driver. 
Even the Linux kernels are identical - except the NIC driver.
   
    BUT so is the data received and passed on to the kernel (outside 
random differences in the padding of the ARP packet)
    One works the other doesn't.


   


But since everything looks perfect, I have no clue where to start looking.
>
> Alex
>
> David H. Lynch Jr. wrote:
>> I am trying to get a network driver working.
>>
>> It sends - I can capture the output with Etherreal and it looks good.
>> It receives - I can dump the received packets when the come in and 
>> they look ok to me.
>>
>>
>> BUT,
>>     If I try to ping another host, first Linux sends and ARP 
>> broadcast, the appropriate client sends an ARP response.
>>     Etherreal is happy with both.
>>     My driver gets the response - The driver says the packet lenght 
>> is 64 bytes, which includes something like 14 bytes of padding at the 
>> end.
>>     But the actual packet looks perfect exactly like what etherreal 
>> says it should (and what I get when I capture a received ARP packet 
>> in another driver).
>>     At the end of the recive interrupt the skb is passed to Linux 
>> with the netif_rc(ndev) function. This returns SUCCESS.
>>
>>     However, the paket never gets handed of to the ARP protocol - I 
>> put some debugging in there and I never see it, while if I switch to 
>> a different  NIC
>>     driver nearly the identical ARP packet gets processed by arp 
>> inside Linux.
>>
>>     I have tried to chase this down, but I can't  follow what is 
>> going on inside of all the /net/core/dev.c etc.
>>
>>     Has anyone seen something similar to this ?
>>
>>     Does anyone have a clue where I can find some info  on trying to 
>> follow something through netif_rx to see where things are going off 
>> the rails ?
>>
>>
>>
>


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: MAC driver issue

[Alex Zeffertt]

>> FWIW, in my experience the hardware independent parts of the 
>> networking stack are
>> very stable and the problem is almost always with the drivers, or with 
>> the IP
>> configuration (e.g. two interfaces on the same subnet).

>     I have no doubt it is with the driver.  I am somewhat fortunate in 
> this instance that I have a nearly identical setup - this is an FPGA 
> based system
>     I can swap the FPGA firmware, get an almost identical kernel with a 
> slightly different NIC, and everything works - same cables, same IP's,
>     Same switch, The only things different are the NIC and its driver. 
> Even the Linux kernels are identical - except the NIC driver.
>    
>     BUT so is the data received and passed on to the kernel (outside 
> random differences in the padding of the ARP packet)
>     One works the other doesn't.
> 

Well ethernet device drivers contain multiple arp supporting methods,
e.g. header_cache, header_cache_update, hard_header_parse, etc etc.
Generally driver writers don't need to concern themselves about these
as they are assigned to generic handlers by ether_setup().  However,
your problematic driver may do something different.

Given this problem appears to be driver specific rather than PPC
specific your best bet is to try and contact the author.  BTW, I don't
think you've said which driver you are using, a key piece of info....

Alex

RE: MAC driver issue

[Martin, Tim]

>=20
> >     I have no doubt it is with the driver.  I am somewhat=20
> fortunate in=20
> > this instance that I have a nearly identical setup - this=20
> is an FPGA=20
> > based system
> >     I can swap the FPGA firmware, get an almost identical=20
> kernel with=20
> > a slightly different NIC, and everything works - same=20
> cables, same IP's,
> >     Same switch, The only things different are the NIC and=20
> its driver.=20
> > Even the Linux kernels are identical - except the NIC driver.
> >   =20
> >     BUT so is the data received and passed on to the kernel=20
> (outside=20
> > random differences in the padding of the ARP packet)

Why is the ARP packet padding random?  I would think it would be fixed,
since the ARP packet itself is a fixed length (for IPv4<->Ethernet ARPs)
and the minimum Ethernet frame is 64 bytes...


> >     One works the other doesn't.
> >=20
>=20
> Well ethernet device drivers contain multiple arp supporting=20
> methods, e.g. header_cache, header_cache_update,=20
> hard_header_parse, etc etc.
> Generally driver writers don't need to concern themselves=20
> about these as they are assigned to generic handlers by=20
> ether_setup().  However, your problematic driver may do=20
> something different.
>=20
> Given this problem appears to be driver specific rather than=20
> PPC specific your best bet is to try and contact the author. =20
> BTW, I don't think you've said which driver you are using, a=20
> key piece of info....
>=20

Might I suggest putting static ARP entries in the kernel (use the "arp"
command from a prompt) and some other packet traffic - UDP perhaps.  See
if the problem is specifically with the way your network driver handles
ARP packets, or if it's a more fundamental problem of how the driver
hands any type of Ethernet packet off to the upper kernel stack layers.