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®ards
Suneel
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
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
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 ?
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:
quoted
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
quoted
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