* booting and mounting PCIIDE: kernel access of bad area
From: KokHow Teh @ 2005-09-28 10:01 UTC (permalink / raw)
To: linuxppc-embedded
Hi;
I have rebuilt arabella linux kernel with PCI IDE support. However,
the kernel bootup crashes with "kernel access of bad area" message. I think
it has something to do with the IDE base addess setup. I have tried to
change the ide0=base,ctl but to no avail. Hope you are able to advise me on
that. Thanks.
Regards,
TEH
u-boot> diskboot $loadaddr 0:1
Loading from IDE device 0, partition 1: Name: hda1
Type: U-Boot
Image Name: Linux Kernel Image
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 893382 Bytes = 872.4 kB
Load Address: 00000000
Entry Point: 00000000
u-boot> bootm
## Booting image at 00100000 ...
Image Name: Linux Kernel Image
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 893382 Bytes = 872.4 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
MPC82xxADS/PQ2FADS board support by Arabella
Memory BAT mapping: BAT2=32Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.26 (root@ShrekII.marconi.com) (gcc version 3.3.2) #6 Wed
Sep 28 11:58:24 MYT 2005
ADS setup arch
MPC82xx PCI bridge initialization
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda2 rw ide0=0x1f0,0x3f6
ide_setup: ide0=0x1f0,0x3f6
ADS init IRQ. NR_IRQS=256
PIC: fully preemptible IRQ mode
ADS time init
ADS calibrate decrementer. FREQ=100000000, tb_ticks_per_jiffy=250000
Calibrating delay loop... 266.24 BogoMIPS
Memory: 30252k available (1384k kernel code, 472k data, 232k init, 0k
highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
PCI: moved device 00:16.0 resource 6 (7201) to 90000000
PCI: moved device 00:16.0 resource 4 (101) to 0
PCI: moved device 00:16.0 resource 0 (101) to 10
PCI: moved device 00:16.0 resource 2 (101) to 10
PCI: moved device 00:16.0 resource 1 (101) to 20
PCI: moved device 00:16.0 resource 3 (101) to 20
ADS init
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
pty: 256 Unix98 ptys configured
Generic RTC Driver v1.07
devsoc: devsoc_init:
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Oops: kernel access of bad area, sig: 11
NIP: C00BC0B0 XER: 20000000 LR: C00BC0A4 SP: C02F1F20 REGS: c02f1e70 TRAP:
0300 Not tainted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000CFB, DSISR: 22000000
TASK = c02f0000[1] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: 00000001 C02F1F20 C02F0000 00000001 00009032 00000001 00000832
00000000
GPR08: C01E0000 C01B0000 C01E0000 00000000 C01E0000 FFFFFFFF 01FC5000
00000000
GPR16: 00000001 00000001 FFFFFFFF 007FFF00 003FF000 00000000 00000001
01B78978
GPR24: 00000000 00000000 40000000 00000000 007FFF00 C01E0000 C01B067C
C01E0000
Call backtrace:
C0197464 C01A7658 C01A88B8 C01A8940 C01A898C C019E684 C0003970
C000820C
Kernel panic: Attempted to kill init!
<0>Rebooting in 180 seconds..
^ permalink raw reply
* mpc5200 and pcmcia
From: Derycke, Johan @ 2005-09-28 12:23 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]
Hi all,
I am working on a custom board based on the Lite5200.
It is expanded with a PCI1410 PC Card Controller on the PCI bus.
In the history of this list I found a patch against an older kernel version
to solve some issues:
http://ozlabs.org/pipermail/linuxppc-embedded/2004-December/016273.html
I took the old 2.4.23 kernel and applied the patch.
I could get my 3c589 network adaptor to work.
Is this patch available for the current 2.4.25 kernel?
Br,
Johan Derycke
[-- Attachment #2: Type: text/html, Size: 1146 bytes --]
^ permalink raw reply
* ^[$B$*$PMM$G2T$0!*!*^[(B
From: info @ 2005-09-28 12:57 UTC (permalink / raw)
To: Linuxppc-embedded
^[$B'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X^[(B
^[$B=w@-$NAj<j$r$7$FD:$1$kCK@-Jg=8^[(B
^[$BEvHVAH$G$O!"EPO?$7$F$$$k=w@-2q0w$N^[(B
^[$BAj<j$r$7$F$/$l$kCK@-$rJg=8$7$F$$$^$9!#^[(B
http://awg.webchu.com/gyakuten/?dog
^[$BJg=8>r7o!!#2#2:P$+$i#3#5:P$^$G$NCK@-^[(B
^[$BJs=7$K4X$7$F$O!"Aj<j=w@-$HD>@\OC$7$F$*7h$a2<$5$$!#^[(B
^[$BEvJ}$O8r>D@.N)$N:]!"=w@-2q0w$NJ}$+$iNA6b$rD:$/0Y^[(B
^[$BCK@-2q0w$NJ}$+$i0l@Z$*6b$rD:$-$^$;$s!#^[(B
^[$B>0!"EPO?$7$F$$$k=w@-2q0w$NJ}$O!"?H85?3::$r$7$?^[(B
^[$BJ}$N$_$H$J$j$^$9!#2q0w$NCf$K$O<R2qE*CO0L$N$"$kJ}$b^[(B
^[$B$*$j$^$9$N$G!">o<1$"$kJ}$N$_$NJg=8$H$5$;$FD:$-$^$9!#^[(B
^[$B59$7$/$*4j$$CW$7$^$9!#^[(B
http://awg.webchu.com/gyakuten/?dog
^[$B'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X'X^[(B
I don't veceive yourmail
^[$B%a!<%k<u?.5qH]^[(B
^[$B!!^[(B
^ permalink raw reply
* Re: How to use SPE on MPC8541
From: Andy Fleming @ 2005-09-28 15:32 UTC (permalink / raw)
To: Gérard Guével; +Cc: linuxppc-embedded
In-Reply-To: <003201c5c402$fb80d430$5201a8c0@GEG2400>
On Sep 28, 2005, at 03:02, G=E9rard Gu=E9vel wrote:
>
> Andy,
>
>
>> Your driver runs in kernel space. The kernel has the SPE bit off.
>> The MSR state is process-specific. If the code executes, the
>> MSR bit
>> is set. Why do you want to see if the bit is set?
>>
>
> OK, this is a bad idea to use a driver to check the msr register.
>
> I don't especially want to see if the bit is set, I just want
> to improve the board performance for a Linux application :-).
>
> To check the performance, I used the Dhrystone 2.1 benchmark with
> the standard glibc (strcpy, strcmp, ...) on one part, and with
> the freescale SPE library on the other part (vstrcpy, vstrcmp, ...).
>
> I already verified in the binary elf file that the right functions are
> called.
> When I run the benchmark, I get the same MIPS with and without SPE =20
> code.
Hmm... This is very strange, because Dhrystone is exactly the =20
benchmark this was tested on. How did you determine that the SPE =20
functions are called?
> I ran the same benchmark on the same board without OS,
> with a personal pseudo glibc, I have the same MIPS as under Linux,
> with the freescale library, I gain 40% of perf.
>
> That's I want to retreive with the Linux OS.
I'm not sure why you aren't seeing a performance gain, but I assure =20
you that, if SPE instructions weren't working, Dhrystone would =20
crash. The only other possibility I can think of is that the SPE =20
versions of the functions aren't being called.=
^ permalink raw reply
* Re: How to use SPE on MPC8541
From: Andy Fleming @ 2005-09-28 15:34 UTC (permalink / raw)
To: Fillod Stephane; +Cc: linuxppc-embedded
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D4F0DF7@rennsmail02.eu.thmulti.com>
On Sep 28, 2005, at 03:12, Fillod Stephane wrote:
> Bonjour G=E9rard,
>
> G=E9rard Gu=E9vel wrote:
>
>> I don't especially want to see if the bit is set, I just want
>> to improve the board performance for a Linux application :-).
>>
>
> Do you know where your CPU is spending much of its time?
> It looks like a job for OProfile. Support for e500 exists in 2.6.x
> thanks to the fine folks of Freescale. We appreciate their involvement
> in OSS community.
Yeah, oprofile would probably help here.
>
>> with the standard glibc (strcpy, strcmp, ...) on one part, and with
>> the freescale SPE library on the other part (vstrcpy, vstrcmp, ...).
>>
>
> Will the SPE enhanced C library calls will be integrated in Glibc =20
> one day?
>
I don't think the glibc people integrate processor-specific changes, =20
so it's not likely.
Andy=
^ permalink raw reply
* Help Reqd on Strange kernel panic with PPC-405 running Linux.
From: arun.prabha @ 2005-09-28 16:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: arun.prabha
Hi All,
I am seeking help for a custom kernel module. If this is not the
appropriate
list, I apologize and could you point me to the right list.
I am seeing a strange kernel panic in a tasklet that gets
scheduled by an ISR. The panic happens when it tries to write to
a memory mapped register. A function is called to write to the
register in the tasklet with the base address, offset and value,
as arguments(in this order). The function adds the base and offset
and uses writel() to do the actual write.
This usually works fine. But when the panic happens, register r3
(base) and r4 (offset) have the same value. r3/base is the expected
ioremaped address, but r4 somehow gets the value of base. This is
strange as we always use #defined values for the offset (After the
panic, I have verified that the load immediate instruction has the
correct value and is not corrupted). When r3 and r4 are added, we=0D
get an invalid virtual address and the kernel panics. In the oops
message it is clear that r0 is r3 + r4.
This is what the disassembled code looks like.
000005f8 <write_to_register>:
5f8: 7c 03 22 14 add r0,r3,r4
5fc: 7c a0 05 2c stwbrx r5,r0,r0
600: 7c 00 06 ac eieio
604: 4e 80 00 20 blr
The most puzzling part I felt is that when I modified the code to loop
infinitely if base and offset are equal (See below for the new code),
we don't see the panic at all. In the above case the panic
happens in just a few minutes when I increase the frequency of the
interrupts, While in this case it works for hours.
000005f8 <write_to_register>:
5f8: 7c 03 20 00 cmpw r3,r4
5fc: 41 a2 00 00 beq+ 5fc <write_to_register+0x4>
600: 7c 03 22 14 add r0,r3,r4
604: 7c a0 05 2c stwbrx r5,r0,r0
608: 7c 00 06 ac eieio
60c: 4e 80 00 20 blr
I don't see the problem when I modify in the following ways.
1. Add two nops before the add r0,r3,r4 instruction. (With one nop the=0D
problem happens).
2. Inlining the register write function.
Basically, I have observed that even the slightest change in the
instruction
sequence in and around the call to the register write function obviates
the
problem.
In the tasklet this register write routine is called a lot of times,
sometimes in big loops, to program different registers. But the crash
always happens at the same place.
There seems to be no data corruption. I can't say for sure for a stack
corruption,
but then why does the nops fix (or at least appears to have fixed) the
issue.
Could this be due to some errors in instruction re-ordering/branch
prediction
by the processor?=0D
Hoping that the problem is something obvious to the PPC gurus.
I would appreciate any help/tips on what could be the problem.
I am running MontaVista Linux on a Xilinx PPC405.
Thanks in advance,
Arun.
PS. Please cc me as I am not subscribed to the group.
Confidentiality Notice=0D
The information contained in this electronic message and any attachments to=
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or=
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or=
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
^ permalink raw reply
* [PATCH] ppc32 ld.script fix for building on ppc64
From: Al Viro @ 2005-09-28 23:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
In arch/ppc/boot/ld.script we need OUTPUT_ARCH(powerpc:common) for
the same reasons why we need it in vmlinux.lds.S; when we build on ppc64
box, we need to be explicit about the target.
See http://linus.bkbits.net:8080/linux-2.5/cset@1.1784.8.10 for
the corresponding fix in vmlinux.lds.S.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----
diff -urN RC14-rc2-git6-uml-kconfig/arch/ppc/boot/ld.script RC14-rc2-git6-ppc-arch/arch/ppc/boot/ld.script
--- RC14-rc2-git6-uml-kconfig/arch/ppc/boot/ld.script 2005-08-28 23:09:40.000000000 -0400
+++ RC14-rc2-git6-ppc-arch/arch/ppc/boot/ld.script 2005-09-28 13:02:21.000000000 -0400
@@ -1,4 +1,4 @@
-OUTPUT_ARCH(powerpc)
+OUTPUT_ARCH(powerpc:common)
SECTIONS
{
/* Read-only sections, merged into text segment: */
^ permalink raw reply
* Re: mpc5200 and pcmcia
From: Andrew Dennison @ 2005-09-28 23:26 UTC (permalink / raw)
To: Derycke, Johan; +Cc: linuxppc-embedded
In-Reply-To: <81A66F72DCACD511B0600002A551BFCB08D3A926@kuumex05.barco.com>
On 9/28/05, Derycke, Johan <johan.derycke@barco.com> wrote:
>
> I am working on a custom board based on the Lite5200.
> It is expanded with a PCI1410 PC Card Controller on the PCI bus.
>
> In the history of this list I found a patch against an older kernel versi=
on
> to solve some issues:
> http://ozlabs.org/pipermail/linuxppc-embedded/2004-December/016273.html
>
> I took the old 2.4.23 kernel and applied the patch.
> I could get my 3c589 network adaptor to work.
Nice to get some feedback, Your the second person that has used it.
> Is this patch available for the current 2.4.25 kernel?
>
It will work conceptually with 2.4.25 as I'm currently running a
relatively recent denx kernel with similar changes. I haven't
published a recent patch yet as there wasn't much feedback last
time...
I've recently done some more work on this to clean it up, for example
USB didn't work with that previous patch but they now coesist happily.
I'll look at posting a patch soon when it's merged into my shiny new GIT tr=
ee.
Andrew
^ permalink raw reply
* [PATCH] mv64x60 iomem annotations
From: Al Viro @ 2005-09-28 23:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----
diff -urN RC14-rc2-git6-n_r3964/arch/ppc/syslib/mv64x60.c RC14-rc2-git6-mv64x60/arch/ppc/syslib/mv64x60.c
--- RC14-rc2-git6-n_r3964/arch/ppc/syslib/mv64x60.c 2005-09-28 13:01:59.000000000 -0400
+++ RC14-rc2-git6-mv64x60/arch/ppc/syslib/mv64x60.c 2005-09-28 13:02:22.000000000 -0400
@@ -34,7 +34,7 @@
DEFINE_SPINLOCK(mv64x60_lock);
static phys_addr_t mv64x60_bridge_pbase;
-static void *mv64x60_bridge_vbase;
+static void __iomem *mv64x60_bridge_vbase;
static u32 mv64x60_bridge_type = MV64x60_TYPE_INVALID;
static u32 mv64x60_bridge_rev;
#if defined(CONFIG_SYSFS) && !defined(CONFIG_GT64260)
@@ -938,7 +938,7 @@
*
* Return the virtual address of the bridge's registers.
*/
-void *
+void __iomem *
mv64x60_get_bridge_vbase(void)
{
return mv64x60_bridge_vbase;
diff -urN RC14-rc2-git6-n_r3964/include/asm-ppc/mv64x60.h RC14-rc2-git6-mv64x60/include/asm-ppc/mv64x60.h
--- RC14-rc2-git6-n_r3964/include/asm-ppc/mv64x60.h 2005-09-22 01:17:31.000000000 -0400
+++ RC14-rc2-git6-mv64x60/include/asm-ppc/mv64x60.h 2005-09-28 13:02:22.000000000 -0400
@@ -233,7 +233,7 @@
struct mv64x60_handle {
u32 type; /* type of bridge */
u32 rev; /* revision of bridge */
- void *v_base; /* virtual base addr of bridge regs */
+ void __iomem *v_base;/* virtual base addr of bridge regs */
phys_addr_t p_base; /* physical base addr of bridge regs */
u32 pci_mode_a; /* pci 0 mode: conventional pci, pci-x*/
@@ -303,7 +303,7 @@
u32 cfg_data, struct pci_controller **hose);
int mv64x60_get_type(struct mv64x60_handle *bh);
int mv64x60_setup_for_chip(struct mv64x60_handle *bh);
-void *mv64x60_get_bridge_vbase(void);
+void __iomem *mv64x60_get_bridge_vbase(void);
u32 mv64x60_get_bridge_type(void);
u32 mv64x60_get_bridge_rev(void);
void mv64x60_get_mem_windows(struct mv64x60_handle *bh,
^ permalink raw reply
* [PATCH] mv64x60_wdt __user annotations and cleanups
From: Al Viro @ 2005-09-28 23:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
* use nonseekable_open() instead of messing with
if (*ppos != file->f_pos)
return -EISPIPE
in ->write() (->read is NULL).
* trivial __user annotations
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----
diff -urN RC14-rc2-git6-base/drivers/char/watchdog/mv64x60_wdt.c current/drivers/char/watchdog/mv64x60_wdt.c
--- RC14-rc2-git6-base/drivers/char/watchdog/mv64x60_wdt.c 2005-09-26 00:02:29.000000000 -0400
+++ current/drivers/char/watchdog/mv64x60_wdt.c 2005-09-22 15:08:16.000000000 -0400
@@ -87,6 +87,8 @@
mv64x60_wdt_service();
mv64x60_wdt_handler_enable();
+ nonseekable_open(inode, file);
+
return 0;
}
@@ -103,12 +105,9 @@
return 0;
}
-static ssize_t mv64x60_wdt_write(struct file *file, const char *data,
+static ssize_t mv64x60_wdt_write(struct file *file, const char __user *data,
size_t len, loff_t * ppos)
{
- if (*ppos != file->f_pos)
- return -ESPIPE;
-
if (len)
mv64x60_wdt_service();
@@ -119,6 +118,7 @@
unsigned int cmd, unsigned long arg)
{
int timeout;
+ void __user *argp = (void __user *)arg;
static struct watchdog_info info = {
.options = WDIOF_KEEPALIVEPING,
.firmware_version = 0,
@@ -127,13 +127,13 @@
switch (cmd) {
case WDIOC_GETSUPPORT:
- if (copy_to_user((void *)arg, &info, sizeof(info)))
+ if (copy_to_user(argp, &info, sizeof(info)))
return -EFAULT;
break;
case WDIOC_GETSTATUS:
case WDIOC_GETBOOTSTATUS:
- if (put_user(wdt_status, (int *)arg))
+ if (put_user(wdt_status, (int __user *)argp))
return -EFAULT;
wdt_status &= ~WDIOF_KEEPALIVEPING;
break;
@@ -154,7 +154,7 @@
case WDIOC_GETTIMEOUT:
timeout = mv64x60_wdt_timeout * HZ;
- if (put_user(timeout, (int *)arg))
+ if (put_user(timeout, (int __user *)argp))
return -EFAULT;
break;
^ permalink raw reply
* ^[$B;(;o$G$*Fk@w$_!#CO0hJL$K??7u$J=P2q$$^[(B
From: info @ 2005-09-29 0:58 UTC (permalink / raw)
To: Linuxppc-embedded
^[$B-!%(%C%A8BDj5U1g"-^[(B
http://www.00-love3.com/?apple01
^[$B:G?7$NCO0h8!:w5!G=$rEk:\$7$^$7$?!#^[(B
^[$B"($^$@$^$@@kEABgI}3HBgCf^[(B
^[$B!J=w@-%3%_%C%/;o!&=w@-%U%!%C%7%g%s;o!&=w@-=54);o!&!&!&!K^[(B
^[$B-"^[(BSM^[$B8BDj5U1g"-^[(B
http://www.00-love3.com/?apple01
^[$B$*8_$$$N6a$$=j$b$9$0$K$o$+$k$N$G!"B(7h$b^[(BOK^[$B!*^[(B
^[$B$^$:$OL5NAEPO?!&7G<(HD$GAj<j$rC5$7$F$*;n$7$/$@$5$$!#^[(B
^[$B-#%F%l%(%C%A8BDj5U1g"-^[(B
http://www.00-love3.com/?apple01
^[$B"($3$s$JNI$$;W$$$7$F!oLc$C$FNI$$$N$+$J$!!)^[(B
^[$B"(%5!<%S%9%]%$%s%H$b==J,$K$D$$$F$^$9$N$G!"$*9%$_$N=w@-$,C5$7=P$;$^$9!#^[(B
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
18^[$B:PL$K~6X;_^[(B
^[$BITMW$JJ}$O"-^[(B
sweet_info_sweet@yahoo.ca
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
^ permalink raw reply
* fix-up GIANFAR driver timer bug
From: sun @ 2005-09-29 2:07 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]
Repeat executing a command series like the attached descript will cause
system hanging or kernel panic shown below on a GIANFAR used system.
The attached patch is for fix the above issue.
The issue and the solution have been confirmed on
MPC8560ADS and MPC85555CDS evaluation boards.
----------
-sh-3.00# ./net_setting.sh
eth1 setting start
###set ip-address
###net Trying to free free IRQ103
down
###set MAC address
###net up
kernel BUG in cascade at kernel/timer.c:419!
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C0029090 LR: C00290A0 SP: CCD69B20 REGS: ccd69a70 TRAP: 0700 Not tainted
MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK = cde58080[170] 'ifconfig' THREAD: ccd68000
Last syscall: 54
GPR00: 00000001 CCD69B20 CDE58080 C0311DD4 C031269C FFFBD700 C0311F4C C0311E94
GPR08: FFFBD869 00003B60 00000169 00003B5F FFFBD700 1010A204 00000000 00000000
GPR16: 00000000 1001C094 00000000 00000000 C07D2400 FFFF8914 C03092C0 C0310000
GPR24: C0310000 C0310000 C0280000 C0311DD4 00000017 C0311DD4 C0312694 C031269C
NIP [c0029090] cascade+0x40/0x78
LR [c00290a0] cascade+0x50/0x78
Call trace:
[c002923c] run_timer_softirq+0x174/0x1d8
[c0024b4c] __do_softirq+0x80/0xf4
[c0024c18] do_softirq+0x58/0x60
[c0003930] timer_interrupt+0xa0/0x208
[c0002598] ret_from_except+0x0/0x18
[c001f694] release_console_sem+0xc4/0x234
[c001f95c] vprintk+0x158/0x1c0
[c001fa14] printk+0x50/0x60
[c014d91c] get_phy_info+0xcc/0xe4
[c014b30c] gfar_enet_open+0x2ec/0x390
[c01a7630] dev_open+0xb0/0xd8
[c01a8dc4] dev_change_flags+0x6c/0x144
[c01e6eec] devinet_ioctl+0x618/0x764
[c01e8250] inet_ioctl+0x10c/0x120
[c019dbcc] sock_ioctl+0x1ac/0x288
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 1 seconds..U-Boot 1.1.2 (Aug 19 2005 - 09:55:23)
[-- Attachment #2: fixIFCONFIGpanic.patch --]
[-- Type: application/octet-stream, Size: 1730 bytes --]
--- old_kernel/drivers/net/gianfar.c 2005-06-21 10:57:29.000000000 +0900
+++ new_kernel/drivers/net/gianfar.c 2005-09-26 17:05:46.116951768 +0900
@@ -541,6 +541,14 @@
MII_INTERRUPT_DISABLED);
}
+/* following 2 steps is a attempting to prevent system hanging/panic
+ when executing ifconfig command. by Sun Zhitai, Sep. 26 2005 */
+
+ cancel_delayed_work(&priv->tq);
+ del_timer_sync(&priv->phy_info_timer);
+
+/* appended end */
+
spin_unlock_irqrestore(&priv->lock, flags);
/* Free the IRQs */
@@ -770,7 +778,7 @@
init_timer(&priv->phy_info_timer);
priv->phy_info_timer.function = &gfar_phy_startup_timer;
priv->phy_info_timer.data = (unsigned long) priv->mii_info;
- mod_timer(&priv->phy_info_timer, jiffies + HZ);
+ __mod_timer(&priv->phy_info_timer, jiffies + HZ);
/* Configure the coalescing support */
if (priv->txcoalescing)
@@ -1500,7 +1508,7 @@
schedule_work(&priv->tq);
- mod_timer(&priv->phy_info_timer, jiffies +
+ __mod_timer(&priv->phy_info_timer, jiffies +
GFAR_PHY_CHANGE_TIME * HZ);
}
@@ -1523,7 +1531,7 @@
/* If autonegotiation failed to start, and
* we haven't timed out, reset the timer, and return */
if (result && secondary--) {
- mod_timer(&priv->phy_info_timer, jiffies + HZ);
+ __mod_timer(&priv->phy_info_timer, jiffies + HZ);
return;
} else if (result) {
/* Couldn't start autonegotiation.
@@ -1564,7 +1572,7 @@
init_timer(&priv->phy_info_timer);
priv->phy_info_timer.function = &gfar_phy_timer;
priv->phy_info_timer.data = (unsigned long) mii_info->dev;
- mod_timer(&priv->phy_info_timer, jiffies +
+ __mod_timer(&priv->phy_info_timer, jiffies +
GFAR_PHY_CHANGE_TIME * HZ);
}
[-- Attachment #3: net_setting.sh --]
[-- Type: application/octet-stream, Size: 291 bytes --]
#! /bin/sh
date
echo "eth1 setting start"
sl(){
echo
}
echo "###set ip-address"
ifconfig eth1 192.168.0.37 netmask 255.255.255.0
sl
echo "###net down"
ifconfig eth1 down
sl
echo "###set MAC address"
ifconfig eth1 hw ether 00:e0:0c:00:01:fd
sl
echo "###net up"
ifconfig eth1 up
sl
^ permalink raw reply
* how to make a PCI net card work on ICECUBE ?
From: ÏÄÓê @ 2005-09-29 3:56 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
Thanks for your help.
I found out that the ICECUBE board could tftpboot via the PCI netcard if wire net to the card, but the board could not mount NFS via the card.
So i set the environment ethact to i82559#0 and saveenv , but the board still could not mount NFS via the card.During the booting-up ,there was nothing about eth1 shown .
And i wired net to the FEC ethernet port,reset the board,found that the environment ethact was now FEC ETHERNET,so i set it again to i82559#0 and saveenv,booted up the kernel, there was nothing about eth1 shown , i tried ifconfig eth1 * up ,information were below:
bash-2.05b# ifconfig eth1 198.87.102.218 up
SIOCSIFADDR: No such device
eth1: unknown interface: No such device
eth1: unknown interface: No such device
where did i make mistakes ?
Best Regards
xiayu
^ permalink raw reply
* Determining physical processors on SMT driven architectures
From: Anantha Kiran Kandukuri @ 2005-09-29 5:19 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 796 bytes --]
Hi,
Is there a programatical way of caliculating physical CPUs on IBM
SMT driven archtitural machines.
I am aware of commands of sort "lsdev -C -c processor" and "smtctl".
But is there any API to do same thing. I saw "processor_info"
strucutre in "/usr/include/sys/iplcb.h" contains information i am
looking for. Is there a way to access this.
Linux on IntelHT, stores this info in "/proc/cpuinfo" file. Similarly
AIX stores this info in "/dev/pmem" file. In KDB, "ipl" subcommand
actually parses file "/dev/pmem" to access "processor_info" strctures.
Can i simulate these KDB commands in a programatical fashion.
Atleast, are there "CPUID" sort of assembly instructions in AIX, so
that i can probe for actual number of CPUs.
Any help is appreciated.
Thanks
-Ananth
--
[-- Attachment #2: Type: text/html, Size: 1034 bytes --]
^ permalink raw reply
* mpc8xx and LCD
From: Fend, Matthias @ 2005-09-29 6:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
hello,
We want to use mpc860/855 with a 320x240 graphic lcd module.
Now there are many possibilities to interface such a module, but I guess this is
not the first time
someone will need a LCD display. So I'm trying to find out the most common way
to implement the
desired functionality.
At the moment I think we should use a lcd controller from Epson (S1D13700 or
S1D13305) since they are
working on Linux framebuffer device driver for it. But I'm not sure how to
design the hardware interface ... all
the LCD modules I found provide only a reduced number of port pins so that the
controller only can be used
in indirect-mode, so I'm not sure whether to connect the module directly to the
CPUs bus or use some
GPIO pins for this...
Has anybody else implemented a LCD into a mpc8xx (not 823) board successfully ?
Are there some good resources somewhere in the web about this topic ?
thanks for your recommendations,
mattthias
[-- Attachment #2: Type: text/html, Size: 1780 bytes --]
^ permalink raw reply
* iMac G5: experimental thermal & cpufreq support
From: Benjamin Herrenschmidt @ 2005-09-29 7:20 UTC (permalink / raw)
To: linuxppc64-dev
Cc: linuxppc-dev list, debian-powerpc@lists.debian.org,
Linux Kernel list
Hi !
I now have some experimental thermal control and cpufreq support for
iMac G5. I have not _yet_ implemented support for the SMU based single
CPU desktops (PowerMac9,1), those will have to wait a little bit more
(not too much hopefully, but I need potential testers to contact me as I
lack hardware access). At this point, it should work on PowerMac8,1
(iMacG5 rev A) and PowerMac8,2 (iMacG5 rev B).
WARNING: This is really a 'first shot'. There is no overtemp detection,
so be careful. The driver doesn't yet have a sysfs interface for you to
read the temperature, but I left it with verbose debugging enabled in
the kernel log so you can see what's going on with the 2 control loops
(the System one which ticks every 5 seconds and the CPU one which ticks
every second). Please tell me if it appears to behave properly. On my
iMac G5 rev A, the target temperature for the CPU is set by the firmware
at 78 degree C with a max at about 83 degree. If I put load on the CPU,
the CPU appears to properly ramp up slowly to 82 then go down and
stabilize at 78 while the driver slowly ramps the fans up.
The algorithm itself is extracted from darwin. However, it's a rather
complex modified version of the PID algorithm, and thus it could use
some review to make sure I got everything right.
The thermal control is also part of a new infrastructure I have written
called "windfarm" that splits the whole thing into several modules
(though I have only tested with everything built in at this point).
Ultimately, it should be possible to port the existing Desktop G5 and
Xserver thermal driver to the new infrastructure provided that the
appropriate sensor & control modules are written. The old thermal driver
uses pretty much the same 2 kind of PID control loops as provided by the
windfarm_pid helper.
I would encourage people doing thermal control on other machines
(laptops, etc...) to also use the new infrastructure.
Ok, now the patches. You need to appy them in proper order. First of
all, it all is on top of current -git as of yesterday. I won't guarantee
they will apply on anything more ancient.
First, you need a fix that is currently pending in -mm (and should be in
2.6.14 before it's final) :
http://gate.crashing.org/~benh/ppc64-smu-fix.diff
Then, you can apply the patch that adds cpufreq support for the iMac G5
(and possibly the SMU based desktop, though not tested)
http://gate.crashing.org/~benh/ppc64-fx-freq-scaling.diff
Then apply those 2 patches in that order:
http://gate.crashing.org/~benh/ppc64-smu-partitions.diff
http://gate.crashing.org/~benh/ppc64-smu-thermal-control.diff
That's it. Now enable:
CONFIG_WINDFARM_SMU
and
CONFIG_I2C_PMAC_SMU
If you are using modules, you may have to manually load the whole bunch,
especially the i2c SMU one which isn't requested (yet).
And let me know :)
Regards,
Ben.
^ permalink raw reply
* Re: Starting the arch/powerpc merge
From: Giuliano Pochini @ 2005-09-29 7:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <1127865914.6102.0.camel@gaston>
On 28-Sep-2005 Benjamin Herrenschmidt wrote:
> On Tue, 2005-09-27 at 18:30 +1000, Paul Mackerras wrote:
>> Christoph Hellwig writes:
>>
>> > What about just dropping POWER3/4 support in 32bit mode?
>>
>> Yes... I'm getting very close to deciding to do that. In fact POWER3
>> isn't too bad, since it still has BATs, but POWER4/PPC970 would be
>> tricky.
>>
>> Does anyone on these lists have any major objections if we drop
>> support for 32-bit kernels on POWER3 and POWER4/PPC970?
>
> I've stopped supporting G5 on 32 bits kernel for some time now, I have
> absolutely no problem just dropping the POWER4 support in 32 bits kernel
> in the merged tree.
Out of curiosity, is there any advantage in using a 32 bits
kernel on ppc64 over a 64 bits kernel ? Speed ? Complexity ?
Compatibility ? Memory ?
--
Giuliano.
^ permalink raw reply
* Re: how to make a PCI net card work on ICECUBE ?
From: Wolfgang Denk @ 2005-09-29 7:58 UTC (permalink / raw)
To: xiay; +Cc: linuxppc-embedded
In-Reply-To: <200509291156.AA2359564@NARI-RELAYS.COM>
In message <200509291156.AA2359564@NARI-RELAYS.COM> you wrote:
>
> I found out that the ICECUBE board could tftpboot via the PCI netcard if wire net to the card, but the board could not mount NFS via the card.
>
> So i set the environment ethact to i82559#0 and saveenv , but the board still could not mount NFS via the card.During the booting-up ,there was nothing about eth1 shown .
...
> bash-2.05b# ifconfig eth1 198.87.102.218 up
> SIOCSIFADDR: No such device
> eth1: unknown interface: No such device
> eth1: unknown interface: No such device
>
> where did i make mistakes ?
I guess you forgot to configure the correct driver for your network
card into your Linux kernel.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Old programmers never die, they just branch to a new address.
^ permalink raw reply
* Re: iMac G5: experimental thermal & cpufreq support
From: Benjamin Herrenschmidt @ 2005-09-29 8:40 UTC (permalink / raw)
To: linuxppc64-dev
Cc: linuxppc-dev list, debian-powerpc@lists.debian.org,
Linux Kernel list
In-Reply-To: <1127978432.6102.53.camel@gaston>
On Thu, 2005-09-29 at 17:20 +1000, Benjamin Herrenschmidt wrote:
> http://gate.crashing.org/~benh/ppc64-smu-thermal-control.diff
You may want to re-download this one if you got it already, I just fixed
a bug in the calculations of the CPU control loop. It's now getting
results much more consistant with OS X. I still have to add some
overtemp handling and I'll remove the debug stuff and work on supporting
the PowerMac9,1 desktop model.
Ben.
^ permalink raw reply
* Re: how to make a PCI net card work on ICECUBE ?
From: debora liu @ 2005-09-29 9:24 UTC (permalink / raw)
To: linuxppc-embedde; +Cc: xiay@nari-relays.com
SGVsbG8sIM/E0+oNCg0KSW4gbWVzc2FnZSA8MjAwNS0wOS0yOSAxMTo1NjozMiB4aWF5QG5hcmkt
cmVsYXlzLmNvbT4geW91IHdyb3RlOg0KDQo+VGhhbmtzIGZvciB5b3VyIGhlbHAuDQo+DQo+SSBm
b3VuZCBvdXQgdGhhdCB0aGUgSUNFQ1VCRSBib2FyZCBjb3VsZCB0ZnRwYm9vdCB2aWEgdGhlIFBD
SSBuZXRjYXJkIGlmIHdpcmUgbmV0IHRvIHRoZSBjYXJkLCBidXQgdGhlIGJvYXJkIGNvdWxkIG5v
dCBtb3VudCBORlMgdmlhIHRoZSBjYXJkLg0KdGZ0cGJvb3QgY291bGQgZG93biBrZXJuZWwgdXNl
IGV0aDAgb3IgZXRoMSB3aXRoIHVib290DQo+DQo+U28gaSBzZXQgdGhlIGVudmlyb25tZW50IGV0
aGFjdCB0byBpODI1NTkjMCBhbmQgc2F2ZWVudiAsIGJ1dCB0aGUgYm9hcmQgc3RpbGwgY291bGQg
bm90IG1vdW50IE5GUyB2aWEgdGhlIGNhcmQuRHVyaW5nIHRoZSBib290aW5nLXVwICx0aGVyZSB3
YXMgbm90aGluZyBhYm91dCBldGgxIHNob3duIC4NCndoaWNoIGlzIGV0aDAgaW4ga2VybmVsPw0K
Pg0KPkFuZCBpIHdpcmVkIG5ldCB0byB0aGUgRkVDIGV0aGVybmV0IHBvcnQscmVzZXQgdGhlIGJv
YXJkLGZvdW5kIHRoYXQgdGhlIGVudmlyb25tZW50IGV0aGFjdCB3YXMgbm93IEZFQyBFVEhFUk5F
VCxzbyBpIHNldCBpdCBhZ2FpbiB0byBpODI1NTkjMCBhbmQgc2F2ZWVudixib290ZWQgdXAgdGhl
IGtlcm5lbCwgdGhlcmUgd2FzIG5vdGhpbmcgYWJvdXQgZXRoMSBzaG93biAsIGkgdHJpZWQgaWZj
b25maWcgZXRoMSAqIHVwICxpbmZvcm1hdGlvbiB3ZXJlIGJlbG93OiANCj4NCj5iYXNoLTIuMDVi
IyBpZmNvbmZpZyBldGgxIDE5OC44Ny4xMDIuMjE4IHVwDQo+U0lPQ1NJRkFERFI6IE5vIHN1Y2gg
ZGV2aWNlDQo+ZXRoMTogdW5rbm93biBpbnRlcmZhY2U6IE5vIHN1Y2ggZGV2aWNlDQo+ZXRoMTog
dW5rbm93biBpbnRlcmZhY2U6IE5vIHN1Y2ggZGV2aWNlIA0KRG8geW91IHJlZ2llc3QgaTgyNTU5
IGRyaXZlcj8NCgkJCQkgDQqhoaGhoaGhoaGhoaGhoaGhRGVib3JhIExpdQ0KoaGhoaGhoaGhoaGh
oaGhoWRlYm9yYWxoQHNpbm92ZWUuY29tDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDktMjkN
Cg0K
^ permalink raw reply
* BRG setting error
From: Borsodi Petr @ 2005-09-29 9:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I found an error in Baud Rate Generator setting for MPC82XX processors.
The CD field of im_brgcx (x =3D 1..8) register is set to wrong value. =
This
field must be set to divisor lowered by 1, in according with doc for
MPC8272 or similar. I have searched 2.4.31 and 2.6.12 kernels.
Please check these functions:
linux-2.4.31\arch\ppc\boot\simple\m8260_tty.c: serial_init
linux-2.4.31\arch\ppc\cpm2_io\commproc.c: cpm2_setbrg
linux-2.4.31\arch\ppc\cpm2_io\commproc.c: cpm2_fastbrg
linux-2.6.12\arch\ppc\boot\simple\m8260_tty.c: serial_init
linux-2.6.12\arch\ppc\syslib\cpm2_common.c: cpm2_setbrg
linux-2.6.12\arch\ppc\syslib\cpm2_common.c: cpm2_fastbrg
This problem is shown only for small divider - for normal UART baud
rates the deviation is slight.
(I think that better approach is round the divisor to nearest value).
Best regards
Petr Borsodi, SW Development
S.ICZ a.s., J.S. Baara 40, 370 01 Ceske Budejovice, Czech Republic
^ permalink raw reply
* Re: CPM2 early console
From: Kalle Pokki @ 2005-09-29 12:24 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <433A6E6D.4070403@iki.fi>
Kalle Pokki wrote:
> I guess Linux remaps the RAM as copy-back. But snooping should work
> with copy-back caches, shouldn't it?
Oh, well. The kernel boots just fine if I add
flags |= _PAGE_WRITETHRU | _PAGE_COHERENT;
in setbat() in arch/ppc/mm/ppc_mmu.c. But this should not depend on this
kind of a hack, should it?
^ permalink raw reply
* Available user-level tool for I2C device?
From: Sam Song @ 2005-09-29 12:35 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'd like to ask whether there is user-level utility
for I2C device registers access like lspci/setpci for
PCI device?
I have a RTC chip DS1337 on a 8248 target. It can
work right in u-boot and linux. If no similar utility,
I will switch to change hwclock.c in busybox to make
it. Any idea?
Thanks in advance,
Sam
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
^ permalink raw reply
* Re: BRG setting error
From: Dan Malek @ 2005-09-29 12:48 UTC (permalink / raw)
To: Borsodi Petr; +Cc: linuxppc-embedded
In-Reply-To: <9999CA1912E416428A03B319E6D084C807C831@DCB02.cb.i.cz>
On Sep 29, 2005, at 5:06 AM, Borsodi Petr wrote:
> I found an error in Baud Rate Generator setting for MPC82XX processors.
How about a patch we can apply? Declaring a bug and hoping
someone else will fix it isn't likely to happen :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: CPM2 early console
From: Dan Malek @ 2005-09-29 12:50 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <433BDCE7.2060206@iki.fi>
On Sep 29, 2005, at 8:24 AM, Kalle Pokki wrote:
> flags |= _PAGE_WRITETHRU | _PAGE_COHERENT;
>
> in setbat() in arch/ppc/mm/ppc_mmu.c. But this should not depend on
> this kind of a hack, should it?
This is clearly wrong since other 82xx processors work fine. Something
is amiss with your boot rom or other setup of this processor.
Thanks.
-- Dan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox