From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by ozlabs.org (Postfix) with ESMTP id 4F37767B96 for ; Wed, 30 Aug 2006 17:26:29 +1000 (EST) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k7U7QRdw017424 for ; Wed, 30 Aug 2006 00:26:27 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k7U7QPSb021099 for ; Wed, 30 Aug 2006 02:26:26 -0500 (CDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CC05.99925CA1" Subject: booting Linux in Linux using kexec tools Date: Wed, 30 Aug 2006 15:26:24 +0800 Message-ID: <405ECA8A30557F439A723E52D50838F9D829C6@ZMY16EXM66.ds.mot.com> From: "Reddy Suneel-ASR125" To: List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CC05.99925CA1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I am trying to boot Linux (zImage.elf) in Linux using kexec tools.=20 =20 I am getting the folling crash =20 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 =3D 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# =20 I am working on MPC8540 processor. =20 can any one help me. =20 Thanks®ards Suneel ------_=_NextPart_001_01C6CC05.99925CA1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi
 
I am = trying to boot=20 Linux (zImage.elf) in Linux using kexec tools.
 
I am = getting the=20 folling crash
 
sh-2.05b#
sh-2.05b# kexec -e
Shutting = down=20 gianfar ethernet
Shutting down gianfar ethernet
Shutting down = gianfar=20 ethernet
Starting new kernel
Bye!
Oops: kernel access of bad = area, sig:=20 11 [#1]
PREEMPT
NIP: 2E5C0020 LR: C000A3CC SP: C8D97DF0 REGS: = c8d97d40=20 TRAP: 0400    Not taintedMSR: 00001000 EE: 0 PR: 0 FP: 0 = ME: 1=20 IR/DR: 00
TASK =3D c82f84a0[665] 'kexec' THREAD: c8d96000
Last = syscall:=20 88
GPR00: 00000000 C8D97DF0 C82F84A0 2E5C1002 2E5C0000 00000000 = 00000F35=20 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] =20 [c00302d0]  [c000206c]
Segmentation=20 fault
sh-2.05b#
 
I am = working on=20 MPC8540 processor.
 
can = any one help=20 me.
 
Thanks&regards
Suneel
------_=_NextPart_001_01C6CC05.99925CA1-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by ozlabs.org (Postfix) with SMTP id 1FC6867BD9 for ; Tue, 5 Sep 2006 07:39:28 +1000 (EST) Date: Mon, 4 Sep 2006 23:39:25 +0200 (CEST) From: Guennadi Liakhovetski To: Reddy Suneel-ASR125 Subject: Re: booting Linux in Linux using kexec tools In-Reply-To: <405ECA8A30557F439A723E52D50838F9D829C6@ZMY16EXM66.ds.mot.com> Message-ID: References: <405ECA8A30557F439A723E52D50838F9D829C6@ZMY16EXM66.ds.mot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.dlasys.net (24.152.213.223.res-cmts.eph.ptd.net [24.152.213.223]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 8176C67BA6 for ; Tue, 5 Sep 2006 08:56:11 +1000 (EST) Received: from slip-12-65-222-48.mis.prserv.net ([12.65.222.48]:1141) by mx.dlasys.net with esmtpa (Exim 4.62 #1 (Debian)) id 1GKMsm-0004Pt-IF by authid with plain_server for ; Mon, 04 Sep 2006 18:25:36 -0400 Message-ID: <44FCA93E.1000009@dlasys.net> Date: Mon, 04 Sep 2006 18:31:26 -0400 From: "David H. Lynch Jr." MIME-Version: 1.0 To: linuxppc-embedded@ozlabs.org Subject: MAC driver issues References: <405ECA8A30557F439A723E52D50838F9D829C6@ZMY16EXM66.ds.mot.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cambridgebroadband.com (mailhost.cambridgebroadband.com [217.204.121.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 9AF0167B8C for ; Tue, 5 Sep 2006 18:33:14 +1000 (EST) Message-ID: <44FD3640.30208@cambridgebroadband.com> Date: Tue, 05 Sep 2006 09:33:04 +0100 From: Alex Zeffertt MIME-Version: 1.0 To: "David H. Lynch Jr." Subject: Re: MAC driver issues References: <405ECA8A30557F439A723E52D50838F9D829C6@ZMY16EXM66.ds.mot.com> <44FCA93E.1000009@dlasys.net> In-Reply-To: <44FCA93E.1000009@dlasys.net> Content-Type: text/plain; charset=us-ascii; format=flowed Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 ? > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.dlasys.net (24.152.213.223.res-cmts.eph.ptd.net [24.152.213.223]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 205A167B7E for ; Wed, 6 Sep 2006 16:29:27 +1000 (EST) Received: from l-dhlii.dlasys.net ([206.223.20.247]:1648) by mx.dlasys.net with esmtpa (Exim 4.62 #1 (Debian)) id 1GKqkR-0001B2-9D by authid with plain_server for ; Wed, 06 Sep 2006 02:18:55 -0400 Message-ID: <44FE69F2.40409@dlasys.net> Date: Wed, 06 Sep 2006 02:25:54 -0400 From: "David H. Lynch Jr." MIME-Version: 1.0 To: linuxppc-embedded@ozlabs.org Subject: Re: MAC driver issue References: <405ECA8A30557F439A723E52D50838F9D829C6@ZMY16EXM66.ds.mot.com> <44FCA93E.1000009@dlasys.net> <44FD3640.30208@cambridgebroadband.com> In-Reply-To: <44FD3640.30208@cambridgebroadband.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cambridgebroadband.com (mailhost.cambridgebroadband.com [217.204.121.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 9AD3B67B8C for ; Wed, 6 Sep 2006 18:25:47 +1000 (EST) Message-ID: <44FE85FE.2010608@cambridgebroadband.com> Date: Wed, 06 Sep 2006 09:25:34 +0100 From: Alex Zeffertt MIME-Version: 1.0 To: "David H. Lynch Jr." Subject: Re: MAC driver issue References: <405ECA8A30557F439A723E52D50838F9D829C6@ZMY16EXM66.ds.mot.com> <44FCA93E.1000009@dlasys.net> <44FD3640.30208@cambridgebroadband.com> <44FE69F2.40409@dlasys.net> In-Reply-To: <44FE69F2.40409@dlasys.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from VCAEXCH02.hq.corp.viasat.com (kestrel.viasat.com [199.106.52.139]) by ozlabs.org (Postfix) with ESMTP id E85C867B22 for ; Thu, 7 Sep 2006 04:11:49 +1000 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: MAC driver issue Date: Wed, 6 Sep 2006 11:11:14 -0700 Message-ID: <821B2170E9E7F04FA38DF7EC21DE487106404241@VCAEXCH01.hq.corp.viasat.com> From: "Martin, Tim" To: "David H. Lynch Jr." Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >=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.