kernel panic after upgrading to 2.6.22

kernel panic after upgrading to 2.6.22

[raul.moreno]

Hello everybody!

I have upgraded from 2.6.15 to 2.6.22 with a mpc866 processor.  I haven=
't
got any idea what is happening in the system, but I got a kernel panic.=
 The
direction of the kernel panic points to the "get_index( )" call into
"prio_tree_insert( )".
I don't think the problem is caused by the uart cpm, but it's also a
possibility.

Here is the console message:

Linux version 2.6.22.14-ELinOS-453 (sermb@pt-330039) (gcc version 3.4.4=

(ELinOS 4.2 3.4.4-38 2007-11-23)) #93 PREEMPT Tue Jan 8 16:8

Zone PFN ranges:

  DMA             0 ->    32768

  Normal      32768 ->    32768

early_node_map[1] active PFN ranges

    0:        0 ->    32768

Built 1 zonelists.  Total pages: 32512

Kernel command line:

PID hash table entries: 512 (order: 9, 2048 bytes)

Decrementer Frequency =3D 375000000/60

cpm_uart: console: compat mode

CPM uart[-]:init portdesc

CPM uart[0]:allocbuf

CPM uart[0]:initbd

CPM uart[0]:init_smc

CPM uart[0]:set_termios

Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

Memory: 125824k available (1424k kernel code, 288k data, 2192k init, 0k=

highmem)

Mount-cache hash table entries: 512

NET: Registered protocol family 16

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 4096 (order: 3, 32768 bytes)

TCP bind hash table entries: 4096 (order: 2, 16384 bytes)

TCP: Hash tables configured (established 4096 bind 4096)

TCP reno registered

JFFS2 version 2.2. (NAND) =C2=A9 2001-2006 Red Hat, Inc.

io scheduler noop registered (default)

io scheduler anticipatory registered

Serial: CPM driver $Revision: 0.02 $

cpm_uart: WARNING: no UART devices found on platform bus!

cpm_uart: the driver will guess configuration, but this mode is no long=
er
supported.

CPM uart[0]:config_port

CPM uart[0]:request port

CPM uart[0]:uart_type

ttyCPM0 at MMIO 0xff000a80 (irq =3D 20) is a CPM UART

CPM uart[1]:config_port

CPM uart[1]:request port

CPM uart[1]:allocbuf

CPM uart[1]:initbd

CPM uart[1]:init_smc

CPM uart[1]:uart_type

ttyCPM1 at MMIO 0xff000a90 (irq =3D 19) is a CPM UART

TCP cubic registered

NET: Registered protocol family 1

Freeing unused kernel memory: 2192k init

CPM uart[0]:startup

CPM uart[0]:set_termios

Oops: kernel access of bad area, sig: 11 [#1]

                                             PREEMPT

NIP: c00c9cdc LR: c00c9f2c CTR: 00000000

REGS: c0529cd0 TRAP: 0300   Not tainted  (2.6.22.14-ELinOS-453)

MSR: 00009032 <EE,ME,IR,DR>  CR: 35093059  XER: a0007a00

DAR: ff801005, DSISR: c0000000

TASK =3D c0524ae0[1] 'init' THREAD: c0528000

GPR00: c00c9f2c c0529d80 c0524ae0 ff800fff c03be29c c0529d98 c0529d9c
c03be278

GPR08: 00000000 00000000 c03be278 00000000 35093059 00000008 30027ff0
10001c3c

GPR16: 0ffd8000 00000129 00000000 c7c84578 00000000 c7c8458c 35093053
95053053

GPR24: 00000000 c03be278 c03be29c c7c8458c c03be29c c03be278 c03be56c
c03be320

Call Trace:

[c0529d80] [c03be2cc]  (unreliable)

[c0529d90] [c00c9f2c]

[c0529dd0] [c0047b3c]

[c0529df0] [c004e1a8]

[c0529e50] [c004f234]

[c0529e70] [c004f324]

[c0529eb0] [c004f720]

[c0529f10] [c000633c]

[c0529f40] [c0002a80]

Instruction dump:

7c8803a6 4e800021 38000001 7c030378 80010014 38210010 7c0803a6 4e800020=


7c0802a6 9421fff0 3944ffdc 90010014 <a0030006> 2f800000 419e0048 812a00=
44

Kernel panic - not syncing: Attempted to kill init!

Rebooting in 180 seconds..


Does anyone know what the problem could be?

Ra=FAl Moreno=

2.6.22-ppc8xx fec.c bugs

[raul.moreno]

Hello everyone,

I don't know who the maintainer of the FEC (Fast Ethernet Controller) i=
n
the ppc8xx achitecture is, so I am writing this email here.

After spending some time working withy kernel 2.6.15 for the ppc8xx
architecture, I've recently started to port to the 2.6.22. Doing so I h=
ave
found some bugs in the code managing the FEC (fec.c).

First I found (and cleared) some compilation errors due to inconsistent=

changes in function prototypes (i.e. INIT_WORK). Moreover, if the "MDIO=
 for
PHY" configuration is used (in my case for an LXT971 fec) the kernel
couldn't manage to finish booting and was caught in an infinite loop
waiting for fec intialization.

I've seen that some bugs were fixed in the latest kernel but others hav=
en't
been addressed (possibly undetected yet). The following is a diff with
corrections I made to the 2.6.22 'fec.c' file (currently seems to work
fine).

883a884

> #ifdef PHY_INTERRUPT

884a886,888

> #else

>     fep->link =3D 1;    /* If PHY_INTERRUPT is not defined, fep->link=
  must
be also put to 1 */

> #endif

1077c1082

< #endif /* CONFIG_FEC_LXT970 */

---

> #endif /* CONFIG_FEC_LXT971 */

1281c1286

<           container_of(work, struct fec_enet_private, phy_task);

---

>           container_of(work, struct fec_enet_private, phy_task2);
/* use phy_task2 -->config */

1660c1665,1666

<     cbd_base =3D (cbd_t *)dma_alloc_coherent(dev->class_dev.dev, PAGE=
_SIZE,

---

>     /* The first parameter has changed */

>     cbd_base =3D (cbd_t *)dma_alloc_coherent(&dev->dev, PAGE_SIZE,

1676,1678c1682,1684

<           ba =3D (unsigned char *)dma_alloc_coherent(dev->class_dev.d=
ev,

---

>           /* The first parameter has changed */

>           ba =3D (unsigned char *)dma_alloc_coherent(&dev->dev,

1814,1816c1821,1824

< #ifdef    CONFIG_USE_MDIO

<     INIT_WORK(&fep->phy_task, mii_relink, (void *)dev);

<     INIT_WORK(&fep->phy_task2, mii_display_config, (void *)dev);

---

> #ifdef    CONFIG_USE_MDIO         /* INIT_WORK has only two parameter=

since 2.6.20 */

>     INIT_WORK(&fep->phy_task, mii_relink);

>     INIT_WORK(&fep->phy_task2, mii_display_config);



I hope this helps.
Best regards,

Ra=FAl Moreno=

Re: 2.6.22-ppc8xx fec.c bugs

[Scott Wood]

raul.moreno@telvent.abengoa.com wrote:
> Hello everyone,
> 
> I don't know who the maintainer of the FEC (Fast Ethernet Controller) in
> the ppc8xx achitecture is, so I am writing this email here.

arch/ppc is deprecated, and arch/ppc/8xx_io especially so.

Please use drivers/net/fs_enet (and also note that arch/ppc will be 
going away in a few months).

> I've seen that some bugs were fixed in the latest kernel but others haven't
> been addressed (possibly undetected yet). The following is a diff with
> corrections I made to the 2.6.22 'fec.c' file (currently seems to work
> fine).

Please post patches against the latest head-of-tree, and in unified diff 
format (diff -u).

-Scott

Re: 2.6.22-ppc8xx fec.c bugs

[raul.moreno]

>>raul.moreno@telvent.abengoa.com wrote:
>> Hello everyone,
>>
>> I don't know who the maintainer of the FEC (Fast Ethernet Controller=
) in
>> the ppc8xx achitecture is, so I am writing this email here.

>arch/ppc is deprecated, and arch/ppc/8xx_io especially so.

>Please use drivers/net/fs_enet (and also note that arch/ppc will be
>going away in a few months).

I didn't know ppc was deprecated. Why is it so? Could you tell me where=
 can
I read anything about this issue?
I have been using this architecture since I started with Linux (not too=

long ago) because I manage a mpc866 processor.
Do you mean that I should port to arch/powerpc?

>> I've seen that some bugs were fixed in the latest kernel but others
haven't
>> been addressed (possibly undetected yet). The following is a diff wi=
th
>> corrections I made to the 2.6.22 'fec.c' file (currently seems to wo=
rk
>> fine).

>Please post patches against the latest head-of-tree, and in unified di=
ff
>format (diff -u).

I'll do it in this way for next patches.

Ra=FAl
=

Re: 2.6.22-ppc8xx fec.c bugs

[Scott Wood]

raul.moreno@telvent.abengoa.com wrote:
> I didn't know ppc was deprecated. Why is it so? 

Having separate 32 and 64 bit powerpc trees was a maintenance headache. 
  The way arch/ppc is structured was a maintenance headache.

> I have been using this architecture since I started with Linux (not too
> long ago) because I manage a mpc866 processor.

mpc866 chips are supported in arch/powerpc.

> Do you mean that I should port to arch/powerpc?

Yes.

-Scott