* Re: 8xx v2.6 TLB problems and suggested workaround
From: Marcelo Tosatti @ 2005-04-04 20:09 UTC (permalink / raw)
To: linux-ppc-embedded, Dan Malek, Pantelis Antoniou; +Cc: Paul Mackerras
In-Reply-To: <20050404191718.GA30281@logos.cnet>
Hum,
The machine seems to be acting strange, but it boots normally
and applications run (more importantly there is no TLB entry
which could cause dcbst fault strangeness).
Some "dd" hangs till I press "ctrl+c", others just work. Really strange.
G'night, I'll look at it tomorrow.
[root@(none) /]# time dd if=/dev/zero of=file bs=16k count=400
400+0 records in
400+0 records out
real 0m4.261s
user 0m0.040s
sys 0m1.240s
[root@(none) /]# time dd if=/dev/zero of=file bs=32k count=400
real 0m50.369s
user 0m0.040s
sys 0m1.680s (ctrl+c)
[root@(none) /]#
> --- a/arch/ppc/kernel/head_8xx.S.orig 2005-04-04 19:43:23.000000000 -0300
> +++ b/arch/ppc/kernel/head_8xx.S 2005-04-04 19:47:40.000000000 -0300
> @@ -359,9 +359,7 @@
>
> . = 0x1200
> DataStoreTLBMiss:
> -#ifdef CONFIG_8xx_CPU6
> stw r3, 8(r0)
> -#endif
> DO_8xx_CPU6(0x3f80, r3)
> mtspr M_TW, r10 /* Save a couple of working registers */
> mfcr r10
> @@ -390,6 +388,16 @@
> mfspr r10, MD_TWC /* ....and get the pte address */
> lwz r10, 0(r10) /* Get the pte */
>
> + li r3, 0
> + cmpw r10, r3 /* does the pte contain a valid address? */
> + bne 4f
> + mfspr r10, M_TW /* Restore registers */
> + lwz r11, 0(r0)
> + mtcr r11
> + lwz r11, 4(r0)
> + lwz r3, 8(r0)
> + b DataAccess
> +4:
> /* Insert the Guarded flag into the TWC from the Linux PTE.
> * It is bit 27 of both the Linux PTE and the TWC (at least
> * I got that right :-). It will be better when we can put
> @@ -419,9 +427,7 @@
> lwz r11, 0(r0)
> mtcr r11
> lwz r11, 4(r0)
> -#ifdef CONFIG_8xx_CPU6
> lwz r3, 8(r0)
> -#endif
> rfi
>
> /* This is an instruction TLB error on the MPC8xx. This could be due
^ permalink raw reply
* PPC linux v2.6.11 network configuration hangs
From: Pari Subramaniam @ 2005-04-05 3:14 UTC (permalink / raw)
To: 'linux-ppc-embedded'
In-Reply-To: <b383dfd14d6dcc895297851a2424f319@freescale.com>
Hi,
We have 8540 based board running PPC port ver-2.4.30-pre1. when I tried =
to
upgrade to ver-2.6.11, the network interface loops (enabled TSEC alone)
indefinitely in the gfar_probe() at the following while loop:
/* Stop the DMA engine now, in case it was running before */
/* (The firmware could have used it, and left it running). */
/* To do this, we write Graceful Receive Stop and Graceful */
/* Transmit Stop, and then wait until the corresponding bits */
/* in IEVENT indicate the stops have completed. */
tempval =3D gfar_read(&priv->regs->dmactrl);
tempval &=3D ~(DMACTRL_GRS | DMACTRL_GTS);
gfar_write(&priv->regs->dmactrl, tempval);
tempval =3D gfar_read(&priv->regs->dmactrl);
tempval |=3D (DMACTRL_GRS | DMACTRL_GTS);
gfar_write(&priv->regs->dmactrl, tempval);
/*---------------------------------stays in this loop for
ever--------------------------------*/
while (!(gfar_read(&priv->regs->ievent) & (IEVENT_GRSC | =
IEVENT_GTSC)))
cpu_relax();
/*-----------------------------------------------------------------------=
-------
--------------*/
MPC8540 based system running boot loader U-Boot version-1.1.2. The TSEC =
port is
tested from the boot loader. The same behavior observed in all the =
boards.
I appreciate any help in this regard.
Thanks in advance
regards
-pari =20
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Sven Luther @ 2005-04-05 5:39 UTC (permalink / raw)
To: Christian; +Cc: linuxppc-dev, Tom Rini
In-Reply-To: <4251D5BA.5080905@gmx.net>
On Tue, Apr 05, 2005 at 02:03:06AM +0200, Christian wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sven Luther wrote:
> >>># This is a BitKeeper generated diff -Nru style patch.
> >>>#
> >>># ChangeSet
> >>># 2004/08/16 10:35:18-07:00 trini@kernel.crashing.org
> >>># ppc32: On PReP, use residual data for PCI dev -> IRQ, and use it.
> >
> > I got through all the changesets one by one, and it is most definitively this
> > one. i unapply it and it works, i apply it and it breaks.
>
> i can confirm this one.
>
> the changesets are listed here:
> http://linux.bkbits.net:8080/linux-2.6/patch@1.1803.125.6
>
> ...and because i had some troubles getting a GNU diff-style patch with
> /usr/bin/bk, i made one against 2.6.11.6:
>
> http://nerdbynature.de/bits/hal/2.6.11.6/1.1803.125.6.diff
>
> more info and dmesg under:
>
> http://nerdbynature.de/bits/hal/2.6.11.6/
>
> to summarize: i don't know exactly which changes, but *some* changes had
> to be made to arch/ppc/platforms/prep_pci.c to get the network card
> working [1] again (network code kept locking up the machine). after this
> issue was resolved, i too noticed the scsi errors [2] others were
> complaing about.
The issue seems obvious, the patch adds some different way of setting the
irqs, based on the residual data, which fails to do what it should on the
powerstack, and thus the irqs are fully left uninitialized.
Friendly,
Sven Luther
^ permalink raw reply
* [PATCH] Update ppc32-fix-errata-for-some-g3-cpus.patch
From: Benjamin Herrenschmidt @ 2005-04-05 6:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list
Hi Andrew !
The previous version of ppc32-fix-errata-for-some-g3-cpus.patch had an
issue that would crash some G4 CPUs on boot. This is fixed in this new
version, please replace the old one and send to linus asap (it's now
been tested on enough CPUs).
---
Some G3 CPUs can crash in funny way if a store from an FPU register
instruction is executed on a register that has never been initialized
since power on. This patch fixes it by making sure all FP registers have
been properly initialized at kernel boot and when waking from sleep. It
also makes the code that decides wether HID0_BTIC and HID0_DPM are
allowed on a given CPU smarter (it can actually _clear_ them now if they
are not allowed instead of just setting them when they are allowed in
case the firmware got them wrong)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/ppc/kernel/cpu_setup_6xx.S
===================================================================
--- linux-work.orig/arch/ppc/kernel/cpu_setup_6xx.S 2005-03-15 11:56:39.000000000 +1100
+++ linux-work/arch/ppc/kernel/cpu_setup_6xx.S 2005-04-05 15:57:49.000000000 +1000
@@ -30,12 +30,14 @@
blr
_GLOBAL(__setup_cpu_750)
mflr r4
+ bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
mtlr r4
blr
_GLOBAL(__setup_cpu_750cx)
mflr r4
+ bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
bl setup_750cx
@@ -43,6 +45,7 @@
blr
_GLOBAL(__setup_cpu_750fx)
mflr r4
+ bl __init_fpu_registers
bl setup_common_caches
bl setup_750_7400_hid0
bl setup_750fx
@@ -50,6 +53,7 @@
blr
_GLOBAL(__setup_cpu_7400)
mflr r4
+ bl __init_fpu_registers
bl setup_7400_workarounds
bl setup_common_caches
bl setup_750_7400_hid0
@@ -57,6 +61,7 @@
blr
_GLOBAL(__setup_cpu_7410)
mflr r4
+ bl __init_fpu_registers
bl setup_7410_workarounds
bl setup_common_caches
bl setup_750_7400_hid0
@@ -80,7 +85,7 @@
bne 1f /* don't invalidate the D-cache */
ori r8,r8,HID0_DCI /* unless it wasn't enabled */
1: sync
- mtspr SPRN_HID0,r8 /* enable and invalidate caches */
+ mtspr SPRN_HID0,r8 /* enable and invalidate caches */
sync
mtspr SPRN_HID0,r11 /* enable caches */
sync
@@ -151,10 +156,14 @@
*/
setup_750_7400_hid0:
mfspr r11,SPRN_HID0
- ori r11,r11,HID0_SGE | HID0_ABE | HID0_BHTE | HID0_BTIC
+ ori r11,r11,HID0_SGE | HID0_ABE | HID0_BHTE | HID0_BTIC
+ oris r11,r11,HID0_DPM@h
BEGIN_FTR_SECTION
- oris r11,r11,HID0_DPM@h /* enable dynamic power mgmt */
-END_FTR_SECTION_IFCLR(CPU_FTR_NO_DPM)
+ xori r11,r11,HID0_BTIC
+END_FTR_SECTION_IFSET(CPU_FTR_NO_BTIC)
+BEGIN_FTR_SECTION
+ xoris r11,r11,HID0_DPM@h /* disable dynamic power mgmt */
+END_FTR_SECTION_IFSET(CPU_FTR_NO_DPM)
li r3,HID0_SPD
andc r11,r11,r3 /* clear SPD: enable speculative */
li r3,0
@@ -218,13 +227,15 @@
/* All of the bits we have to set.....
*/
- ori r11,r11,HID0_SGE | HID0_FOLD | HID0_BHTE | HID0_LRSTK | HID0_BTIC
+ ori r11,r11,HID0_SGE | HID0_FOLD | HID0_BHTE
+ ori r11,r11,HID0_LRSTK | HID0_BTIC
+ oris r11,r11,HID0_DPM@h
BEGIN_FTR_SECTION
xori r11,r11,HID0_BTIC
END_FTR_SECTION_IFSET(CPU_FTR_NO_BTIC)
BEGIN_FTR_SECTION
- oris r11,r11,HID0_DPM@h /* enable dynamic power mgmt */
-END_FTR_SECTION_IFCLR(CPU_FTR_NO_DPM)
+ xoris r11,r11,HID0_DPM@h /* disable dynamic power mgmt */
+END_FTR_SECTION_IFSET(CPU_FTR_NO_DPM)
/* All of the bits we have to clear....
*/
@@ -248,6 +259,25 @@
isync
blr
+/*
+ * Initialize the FPU registers. This is needed to work around an errata
+ * in some 750 cpus where using a not yet initialized FPU register after
+ * power on reset may hang the CPU
+ */
+_GLOBAL(__init_fpu_registers)
+ mfmsr r10
+ ori r11,r10,MSR_FP
+ mtmsr r11
+ isync
+ addis r9,r3,empty_zero_page@ha
+ addi r9,r9,empty_zero_page@l
+ REST_32FPRS(0,r9)
+ sync
+ mtmsr r10
+ isync
+ blr
+
+
/* Definitions for the table use to save CPU states */
#define CS_HID0 0
#define CS_HID1 4
Index: linux-work/arch/ppc/platforms/pmac_sleep.S
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_sleep.S 2005-03-15 11:56:42.000000000 +1100
+++ linux-work/arch/ppc/platforms/pmac_sleep.S 2005-04-05 14:29:25.000000000 +1000
@@ -267,6 +267,10 @@
/* Restore various CPU config stuffs */
bl __restore_cpu_setup
+ /* Make sure all FPRs have been initialized */
+ bl reloc_offset
+ bl __init_fpu_registers
+
/* Invalidate & enable L1 cache, we don't care about
* whatever the ROM may have tried to write to memory
*/
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Pantelis Antoniou @ 2005-04-05 7:08 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <20050404200922.GC30252@logos.cnet>
Marcelo Tosatti wrote:
> Hum,
>
> The machine seems to be acting strange, but it boots normally
> and applications run (more importantly there is no TLB entry
> which could cause dcbst fault strangeness).
>
> Some "dd" hangs till I press "ctrl+c", others just work. Really strange.
>
> G'night, I'll look at it tomorrow.
>
> [root@(none) /]# time dd if=/dev/zero of=file bs=16k count=400
> 400+0 records in
> 400+0 records out
>
> real 0m4.261s
> user 0m0.040s
> sys 0m1.240s
> [root@(none) /]# time dd if=/dev/zero of=file bs=32k count=400
>
>
> real 0m50.369s
> user 0m0.040s
> sys 0m1.680s (ctrl+c)
> [root@(none) /]#
>
>
I can confirm that the patch works.
I no longer need the tlbie in update_mmu_cache.
/tmp # time dd if=/dev/zero of=file bs=16k count=400
400+0 records in
400+0 records out
real 0m 0.55s
user 0m 0.01s
sys 0m 0.52s
/tmp is tmpfs
Well done Marcelo!
Regards
Pantelis
P.S. CPU errata perhaps?
^ permalink raw reply
* Problem with linux porting
From: Atit_Shah @ 2005-04-05 8:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3574 bytes --]
Hi All,
We are having a problem with porting of Linux.
We are using the Linux kernel image modified to work on an EP8248 (having
the MPC8248 Processor) Board. We have our board configured the same as the
EP8248 board. We have made no changes to the Kernel Image and it crashes.
The last message it shows on the console is "Uncompressing Kernel....ok" and
the console log_buffer has the following:
"<6>Memory BAT mapping: BAT2=32Mb, BAT3=0Mb, residual: 0Mb.
<4>Oops: kernel access of bad area, sig: 11.<4>NIP: 00000000 XER: 00000000
LR: 00000000 SP: 00000000 REGS: c0150000 TRAP: 0000 Not tainted.<4>MSR:
00000000 EE: 0PR: 0 FP: 0 ME:0 IR/DR: 00.<4> TASK = c014f470[0] 'swapper'
Last syscall: 0 .<4>last math 00000000 last altivec 00000000.<4>Call
backtrace: 00000004 ."
The EP8248 Board have the following configurations:
1. 8MB Flash
Port Size = 32 Bit
Bottom Boot
2. 16MB SDRAM
Port Size = 32 Bit
3. EEPROM
4. Frequency
Core: 346MHz
CPM: 198MHz
BUS: 99MHz
Input: 66MHz
5. Memory Map
=====================================================================
Memory Region Size Address Range
=====================================================================
SDRAM 16MByte 0000_0000 - 00FF_FFFF
Flash 8MByte FF80_0000 - FFFF_FFFF
The board we are using has
1. 16MB Flash
Port Size = 32 Bit
Bottom Boot
2. 32MB SDRAM
Port Size = 64 Bit
3. No EEPROM
4. Frequency
Core: 400MHz
CPM: 200MHz
BUS: 100MHz
Input: 100MHz
5. Memory Map
=====================================================================
Memory Region Size Address
Range
======================================================================
SDRAM 32MByte 0000_0000 -
01FF_FFFF
Flash 16MByte FF00_0000 -
FFFF_FFFF
The value of the IMMR in HCRW is both boards is configured to 0xF0000000.
The value of IMAP_ADDR in linux/arch/ppc/platforms/ep8248.h and
u-boot/include/configs/ep8248.h is 0xF0000000. The BD_INFO structure and the
values are being passed perfectly from u-boot to Linux. The cmd_start and
cmd_end are also perfect - verified using the memory dump command in u-boot.
We have performed RAM test through u-boot and it has passed it.
We would be grateful if somebody could throw more light on where we are
going wrong and help us successful port Linux. If you require any more info
i would be more than glad to provide you with the same.
Thanks and Regards
Atit
**************************************************************************
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.
**************************************************************************
[-- Attachment #2: Type: text/html, Size: 17151 bytes --]
^ permalink raw reply
* Re: Problem with linux porting
From: Eugene Surovegin @ 2005-04-05 10:01 UTC (permalink / raw)
To: Atit_Shah; +Cc: linuxppc-embedded
In-Reply-To: <A44765C986F8D411995B00B0D0795F4B3A828130@hhtnt002>
On Tue, Apr 05, 2005 at 02:24:01PM +0530, Atit_Shah wrote:
> We are having a problem with porting of Linux.
[snip]
> 4. Frequency
>
> Core: 346MHz
>
> CPM: 198MHz
>
> BUS: 99MHz
>
> Input: 66MHz
What does "Input" clock mean?
If it's a CLKIN, why is Bus clock not equal to it?
--
Eugene
^ permalink raw reply
* [Fwd: Re: iBook G3 owners]
From: Sebastian Heutling @ 2005-04-05 10:22 UTC (permalink / raw)
To: debian-powerpc, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 106 bytes --]
Bah! Different mailing list, different behaviour if you click on "Reply
to Sender only"! ;-)
Sebasitna
[-- Attachment #2: Re: iBook G3 owners --]
[-- Type: message/rfc822, Size: 3188 bytes --]
From: Sebastian Heutling <sheutlin@gmx.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: iBook G3 owners
Date: Tue, 05 Apr 2005 12:19:33 +0200
Message-ID: <42526635.2010709@gmx.de>
Benjamin Herrenschmidt wrote:
>Hi !
>
>There have been various reports of issues with sleep among others on
>iBook G3 equiped with the 750FX processor. Also, the cpufreq code on
>these so far didn't change the CPU voltage, which limited the actual
>power saving at low frequency.
>
>I have uploaded various patches that should help fix these issues. Those
>patches are all against current linus bk and they should be all applied
>in the order below.
>
>I would really appreciate some tests as I don't have access to any of
>these machines. I need to know if cpufreq works reliably with those
>patches and if the new voltage control makes any differnece on battery
>life (check power consumption in /proc/pmu/battery_*/current when
>running on battery) and I need to know if the patches are improving
>reliability of sleep/wakeup.
>
>The 4 patches can be found at these URLs. If you had earlier versions of
>some of these, those patches replace them:
>
>http://gate.crahsing.org/~benh/ppc32-750-errata-fix.diff
>http://gate.crahsing.org/~benh/ppc32-pmac-sleep-fix.diff
>http://gate.crahsing.org/~benh/cpufreq-add-suspend.diff
>http://gate.crahsing.org/~benh/ppc32-cpufreq-gpio-off.diff
>
>Please, let me know asap,
>
>
Sleep/wakeup works with a modified arch/ppc/platform/pmac_sleep.S (bl
reloc_offset was missing which you send later). I still have a strange
problem with some programs started in init-Scripts. For example if I run
dbus on bootup and directly after that go to sleep and wake-up again my
ibook doesn't resume harddisks leaving the following last messages:
eth0 resuming
PHY ID: 4061e4, addr: 0
eth0: Link is up at 100 Mbps, full duplex.
eth0: Pause is disabled
If I disable dbus (stop it) and go to sleep, wakeup - no problem.
Sometimes it is even enough to just only restart the
daemon.
I'm not sure about cpufreq. I used to run the cpufreq daemon. With this
program I realised three possible frequencies on my ibook: 400, 462,
700 MHz. Using powernowd or directly the userspace governour gives only
400 and 700MHz. So maybe there is something wrong here, too or this
specific CPU/ibook does only support 2 states.
Details about the ibook:
iBook, Dual USB
blueberry:~# cat /proc/cpuinfo
processor : 0
cpu : 750FX
temperature : 1-76 C (uncalibrated)
clock : 700MHz
revision : 2.2 (pvr 7000 0202)
bogomips : 1388.54
machine : PowerBook4,3
motherboard : PowerBook4,3 MacRISC2 MacRISC Power Macintosh
detected as : 257 (iBook 2 rev. 2)
pmac flags : 0000001b
L2 cache : 512K unified
memory : 384MB
pmac-generation : NewWorld
Sebastian
^ permalink raw reply
* How to read EDID Information of Monitor
From: karthik @ 2005-04-06 0:32 UTC (permalink / raw)
To: linuxppc-dev
Sir,
In my project i am facing problem of how to read EDID information of
Monitor
^ permalink raw reply
* how to read EDID information of Monitor
From: karthik @ 2005-04-06 0:36 UTC (permalink / raw)
To: linuxppc-dev
Sir,
In my project i am facing problem of how to read EDID information of
Monior(not using video bios call). So it would be greatful, if u suggest me
some idea. soem were telling in readonfb.c driver fiel for readeon its
reading the EDID info. But could u tell me in bit detail about it. Also,
please tell me how the video driver reads EDID info.
Regards
Karthik
^ permalink raw reply
* RE: How to read EDID Information of Monitor [OT]
From: Fillod Stephane @ 2005-04-05 11:35 UTC (permalink / raw)
To: karthik, linuxppc-dev
karthik wrote:
>In my project i am facing problem of how to read EDID information of
Monitor
http://freshmeat.net/search/?q=3Dedid+§ion=3Dprojects
http://www.google.com/search?q=3DEDID&meta=3D
--=20
Stephane
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Jerome Glisse @ 2005-04-05 11:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1112656372.26086.88.camel@gaston>
I almost successfully run the 2.6.12-rc2, there were some
bad old stuff lying around. But i needed the two workaround
to compile it. So maybe this two could be applied to the kernel ?
Now the only issue which remains is that the radeon framebuffer
no more set a proper mode for my screen. The screen complain
about a out of range mode. But as soon as X start i get a proper
mode set but can't switch to console.
The screen is a crt one on a radeon 9600 with dvi->vga adapter.
Which works well on 2.6.10
I will try t look at radeon framebuffer see if i can find anythings.
Any idea of which change on that code may be the origin of this ?
Jerome Glisse
^ permalink raw reply
* Re: [Fwd: Re: iBook G3 owners]
From: Andreas Schwab @ 2005-04-05 12:10 UTC (permalink / raw)
To: Sebastian Heutling; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <425266E2.7060605@gmx.de>
Sebastian Heutling <sheutlin@gmx.de> writes:
> Sleep/wakeup works with a modified arch/ppc/platform/pmac_sleep.S (bl
> reloc_offset was missing which you send later). I still have a strange
> problem with some programs started in init-Scripts. For example if I run
> dbus on bootup and directly after that go to sleep and wake-up again my
> ibook doesn't resume harddisks leaving the following last messages:
>
> eth0 resuming
> PHY ID: 4061e4, addr: 0
> eth0: Link is up at 100 Mbps, full duplex.
> eth0: Pause is disabled
>
> If I disable dbus (stop it) and go to sleep, wakeup - no problem.
I have the same problem. I'm also seeing the same hang when the KDED
Media Manager is running (independent of hal/dbus). I believe the cause
for this is that the ide subsystem wakes up too late, and the cdrom
polling of hal or kded is resuming too early.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* RE: [PATCH] invalid instructions in kernel mode
From: Fillod Stephane @ 2005-04-05 12:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Kumar Gala wrote:
> What is the crash01 test doing that causes this code to get invoked? =20
crash01[1] (of LTP) is derived from crashme[2], a tool by George J.
Carrette.
It simulates real user programs by generating pseudo-random code and
jumping
into it. This is a great tool to stress test operating system
robustness.
It is very good at testing weird corner cases that no one enjoy doing,=20
eventually finding bugs that may have bitten you in the field.=20
For instance, 2.6.11.6 kernels with math emulation off have a problem
with=20
load/store of fp regs. Please see my question in another mail with Dan.
[1]
http://cvs.sourceforge.net/viewcvs.py/ltp/ltp/testcases/misc/crash/crash
01.c?only_with_tag=3DHEAD&view=3Dmarkup
[2] http://people.delphiforums.com/gjc/crashme.html
> is the kernel you are using using build with math emulation on or off?
My kernel is built with math emulation off. My toolchain is soft-fp
based.
Best Regards,
--=20
Stephane
^ permalink raw reply
* RE: [PATCH] invalid instructions in kernel mode
From: Fillod Stephane @ 2005-04-05 12:24 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
Dan Malek wrote:
>> What I don't understand, is how the FP load/store operations
>> in misc.S can "work" on a system with no FPU and *no* math-emu?
>
>What should happen is to follow the example used by 8xx for
>many years. As I said, when math emulation is disabled, there is
>still code that will emulate the load/store FP instructions. These
>instructions are used in may places even if user applications
>are compiled without any FP usage.
Ok.
>> Many years? Allow me to doubt it's really used :).
>
>I wrote it in 1998 for the 8xx. I thought 4xx and e500 used the
>same model. If they don't, they should.
Let's get it fixed.
>> Though, it does work for 8xx thanks to Soft_emulate_8xx, but doesn't
>> for other FPU-less cores when CONFIG_MATH_EMULATION is disabled.
>
>Well, then that should get fixed.
What's the right way to fix it?
>> So here is another patch,
[..]
>The only patch I'm interested in is making the 4xx and e500 follow the
>same path as 8xx. All of the non-FP cores should work the same way.
Speaking for myself, I don't plan on using the SPE FPU of the e500, but
would like to see the MATH_EMULATION=3Dn fixed. So how should we fix it?
It seems you didn't like my last patch which lets make enter the
math-emu
subdirectory only to compile the load/store (8xx could do that too).
Would you prefer a fix along the line of Soft_emulate_8xx() ?
Then should we make it a Soft_emulate_85xx and Soft_emulate_4xx or can
we attempt to fuse them altogether and rename(+make it generic)
Soft_emulate_8xx as Soft_emulate_classic?
>The e500 is a special case because it doesn't have a classic FPU but
>rather can utilize the SPE for floating point. Put some thought into=20
>that.
I don't know what Kumar and his team have in mind for the e500, whether
they will use SPE FPU for the classic load/store "emulation". Kumar,
can you please enlighten us on this topic?
Thanks,
--=20
Stephane
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Andreas Schwab @ 2005-04-05 12:39 UTC (permalink / raw)
To: Jerome Glisse; +Cc: linuxppc-dev list
In-Reply-To: <4240b91605040504525fd877e5@mail.gmail.com>
Jerome Glisse <j.glisse@gmail.com> writes:
> I will try t look at radeon framebuffer see if i can find anythings.
> Any idea of which change on that code may be the origin of this ?
I'd suggest looking at the changes between rc1 and rc2 first. On my iBook
G3 with Radeon M6 I'm also having problems with rc2, whereas rc1 is
working fine. I haven't found the time to look closer yet.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* RE: Problem with linux porting
From: Atit_Shah @ 2005-04-05 13:48 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
sorry the bus and input frequenies are same and its 100MHz.
yes it is the clkin freq
-----Original Message-----
From: Eugene Surovegin [mailto:ebs@ebshome.net]
Sent: Tuesday, April 05, 2005 3:31 PM
To: Atit_Shah
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Problem with linux porting
On Tue, Apr 05, 2005 at 02:24:01PM +0530, Atit_Shah wrote:
> We are having a problem with porting of Linux.
[snip]
> 4. Frequency
>
> Core: 346MHz
>
> CPM: 198MHz
>
> BUS: 99MHz
>
> Input: 66MHz
What does "Input" clock mean?
If it's a CLKIN, why is Bus clock not equal to it?
--
Eugene
**************************************************************************
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.
**************************************************************************
[-- Attachment #2: Type: text/html, Size: 2631 bytes --]
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Tom Rini @ 2005-04-05 14:38 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
In-Reply-To: <20050405053930.GD4604@pegasos>
On Tue, Apr 05, 2005 at 07:39:31AM +0200, Sven Luther wrote:
> On Tue, Apr 05, 2005 at 02:03:06AM +0200, Christian wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Sven Luther wrote:
> > >>># This is a BitKeeper generated diff -Nru style patch.
> > >>>#
> > >>># ChangeSet
> > >>># 2004/08/16 10:35:18-07:00 trini@kernel.crashing.org
> > >>># ppc32: On PReP, use residual data for PCI dev -> IRQ, and use it.
> > >
> > > I got through all the changesets one by one, and it is most definitively this
> > > one. i unapply it and it works, i apply it and it breaks.
> >
> > i can confirm this one.
> >
> > the changesets are listed here:
> > http://linux.bkbits.net:8080/linux-2.6/patch@1.1803.125.6
> >
> > ...and because i had some troubles getting a GNU diff-style patch with
> > /usr/bin/bk, i made one against 2.6.11.6:
> >
> > http://nerdbynature.de/bits/hal/2.6.11.6/1.1803.125.6.diff
> >
> > more info and dmesg under:
> >
> > http://nerdbynature.de/bits/hal/2.6.11.6/
> >
> > to summarize: i don't know exactly which changes, but *some* changes had
> > to be made to arch/ppc/platforms/prep_pci.c to get the network card
> > working [1] again (network code kept locking up the machine). after this
> > issue was resolved, i too noticed the scsi errors [2] others were
> > complaing about.
>
> The issue seems obvious, the patch adds some different way of setting the
> irqs, based on the residual data, which fails to do what it should on the
> powerstack, and thus the irqs are fully left uninitialized.
Can either of you verify that say 2.6.11.6 w/ "noresidual" on the
command-line works? Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: somewhat OT -- trying to build code on the fly then run it
From: Fillod Stephane @ 2005-04-05 15:08 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev
Chris Friesen wrote:=20
> I'm writing a testcase to test some code we wrote to allow userspace
to=20
> flush the whole dcache and invalidate the whole icache. =20
Your testcase sounds like this kernel module for RT load generator:
http://rtai.dk/cgi-bin/gratiswiki.pl?Latency_Killer/Flushy
Comments welcome.
--=20
Stephane
^ permalink raw reply
* Re: linux 2.6.12-rc1-bk5 compilation error
From: Jerome Glisse @ 2005-04-05 15:17 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list
In-Reply-To: <je1x9pv1mf.fsf@sykes.suse.de>
On Apr 5, 2005 1:39 PM, Andreas Schwab <schwab@suse.de> wrote:
> Jerome Glisse <j.glisse@gmail.com> writes:
>
> > I will try t look at radeon framebuffer see if i can find anythings.
> > Any idea of which change on that code may be the origin of this ?
>
> I'd suggest looking at the changes between rc1 and rc2 first. On my iBook
> G3 with Radeon M6 I'm also having problems with rc2, whereas rc1 is
> working fine. I haven't found the time to look closer yet.
>
> Andreas.
Shame on me, i was passing wrong arguments to the kernel
now this works...
Jerome Glisse
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Sven Luther @ 2005-04-05 15:23 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050405143802.GS25923@smtp.west.cox.net>
On Tue, Apr 05, 2005 at 07:38:02AM -0700, Tom Rini wrote:
> On Tue, Apr 05, 2005 at 07:39:31AM +0200, Sven Luther wrote:
> > On Tue, Apr 05, 2005 at 02:03:06AM +0200, Christian wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Sven Luther wrote:
> > > >>># This is a BitKeeper generated diff -Nru style patch.
> > > >>>#
> > > >>># ChangeSet
> > > >>># 2004/08/16 10:35:18-07:00 trini@kernel.crashing.org
> > > >>># ppc32: On PReP, use residual data for PCI dev -> IRQ, and use it.
> > > >
> > > > I got through all the changesets one by one, and it is most definitively this
> > > > one. i unapply it and it works, i apply it and it breaks.
> > >
> > > i can confirm this one.
> > >
> > > the changesets are listed here:
> > > http://linux.bkbits.net:8080/linux-2.6/patch@1.1803.125.6
> > >
> > > ...and because i had some troubles getting a GNU diff-style patch with
> > > /usr/bin/bk, i made one against 2.6.11.6:
> > >
> > > http://nerdbynature.de/bits/hal/2.6.11.6/1.1803.125.6.diff
> > >
> > > more info and dmesg under:
> > >
> > > http://nerdbynature.de/bits/hal/2.6.11.6/
> > >
> > > to summarize: i don't know exactly which changes, but *some* changes had
> > > to be made to arch/ppc/platforms/prep_pci.c to get the network card
> > > working [1] again (network code kept locking up the machine). after this
> > > issue was resolved, i too noticed the scsi errors [2] others were
> > > complaing about.
> >
> > The issue seems obvious, the patch adds some different way of setting the
> > irqs, based on the residual data, which fails to do what it should on the
> > powerstack, and thus the irqs are fully left uninitialized.
>
> Can either of you verify that say 2.6.11.6 w/ "noresidual" on the
> command-line works? Thanks.
Notice that last i checked, there was a typo which forced you to say
"nopresidual", and i think i did add this when i was testing, and it didn't
help.
Will try booting the debian 2.6.11-1 powerpc kernels which should include all
2.6.11.6 patches.
Friendly,
Sven Luther
^ permalink raw reply
* FCC Ethernet startup crash
From: Rune Torgersen @ 2005-04-05 15:37 UTC (permalink / raw)
To: linuxppc-embedded
I've been running into the old problem of the kernel ip stack crasheing
the kernel, because of early packets again.
This has been mentioned on this list several times before, but the
worarounds that used to work doesn't seem to work anymore.
(like changing the order of things in ip_init())
As far as I can tell, it is because the FCC enet drivers starts to
receive packets way before the ip stack is initialized.
Does anybody have any good ideas on how to fix this?
Kernel: 2.6.12-rc2 on a MPC8265
I can almost reliably recreate this by flood-pinging the board while the
kernel is booting.
The crach is as follows:
eth0: FCC ENET Version 0.3, 00:30:d7:00:01:08
eth1: FCC ENET Version 0.3, 00:30:d7:00:01:09
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: A0141440 LR: A012ACA0 SP: AFFB1D80 REGS: affb1cd0 TRAP: 0300 Not
tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 20000000
TASK =3D afde5ae0[1] 'swapper' THREAD: affb0000
Last syscall: 120
GPR00: 00000000 AFFB1D80 AFDE5AE0 A07069E0 AFF44000 A01E2C04 00001032
00000002
GPR08: A01E2C04 A0200000 AFFB0000 00000000 8010C082 000000B1 10000000
007FFF1E
GPR16: 00000000 00000001 007FFF00 0FFFA6F0 00000000 FFFFFFFF 00000003
0FFA0BD0
GPR24: 00000000 FFFB72C3 A01E1324 00000040 AFFB1DF8 A07069E0 A07069E0
A07069E0
Call trace: [a012aca0] [a012ae58] [a012afd8] [a001b30c] [a001b374]
[a001b464] [a0005a60] [a000480c] [a01fcfcc] [a01fd2bc]
[a01fddd0] [a01ec718] [a01ec7d8] [a0003a20] [a0006b44]
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
Call trace:
$ call2sym
Ready for call trace list. <ctrl-d> on a blank line when done.
[A0141440] [a012aca0] [a012ae58] [a012afd8] [a001b30c] [a001b374]
[a001b464] [a0005a60] [a000480c] [a01fcfcc] [a01fd2bc]
[a01fddd0] [a01ec718] [a01ec7d8] [a0003a20] [a0006b44]
Processing...
Address Function
A0141440 ip_rcv
a012aca0 netif_receive_skb
a012ae58 process_backlog
a012afd8 net_rx_action
a001b30c __do_softirq
a001b374 do_softirq
a001b464 irq_exit
a0005a60 do_IRQ
a000480c ret_from_except
a01fcfcc ip_rt_init
a01fd2bc ip_init
a01ec718 do_initcalls
a01ec7d8 do_basic_setup
a0003a20 init
a0006b44 kernel_thread
[runet@pib linux-innsys]$
Gdb list of excact line=20
(gdb) list *0xA0141440
0xa0141440 is in ip_rcv (net/ipv4/ip_input.c:370).
365 * that it receives, do not try to analyse it.
366 */
367 if (skb->pkt_type =3D=3D PACKET_OTHERHOST)
368 goto drop;
369
370 IP_INC_STATS_BH(IPSTATS_MIB_INRECEIVES);
371
372 if ((skb =3D skb_share_check(skb, GFP_ATOMIC)) =3D=3D =
NULL) {
373 IP_INC_STATS_BH(IPSTATS_MIB_INDISCARDS);
374 goto out;
Rune Torgersen
System Developer
Innovative Systems LLC
1000 Innovative Drive
Mitchell, SD 57301
Ph: 605-995-6120
www.innovsys.com
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Tom Rini @ 2005-04-05 15:47 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
In-Reply-To: <20050405152322.GC25311@pegasos>
On Tue, Apr 05, 2005 at 05:23:22PM +0200, Sven Luther wrote:
> On Tue, Apr 05, 2005 at 07:38:02AM -0700, Tom Rini wrote:
> > On Tue, Apr 05, 2005 at 07:39:31AM +0200, Sven Luther wrote:
> > > On Tue, Apr 05, 2005 at 02:03:06AM +0200, Christian wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > Sven Luther wrote:
> > > > >>># This is a BitKeeper generated diff -Nru style patch.
> > > > >>>#
> > > > >>># ChangeSet
> > > > >>># 2004/08/16 10:35:18-07:00 trini@kernel.crashing.org
> > > > >>># ppc32: On PReP, use residual data for PCI dev -> IRQ, and use it.
> > > > >
> > > > > I got through all the changesets one by one, and it is most definitively this
> > > > > one. i unapply it and it works, i apply it and it breaks.
> > > >
> > > > i can confirm this one.
> > > >
> > > > the changesets are listed here:
> > > > http://linux.bkbits.net:8080/linux-2.6/patch@1.1803.125.6
> > > >
> > > > ...and because i had some troubles getting a GNU diff-style patch with
> > > > /usr/bin/bk, i made one against 2.6.11.6:
> > > >
> > > > http://nerdbynature.de/bits/hal/2.6.11.6/1.1803.125.6.diff
> > > >
> > > > more info and dmesg under:
> > > >
> > > > http://nerdbynature.de/bits/hal/2.6.11.6/
> > > >
> > > > to summarize: i don't know exactly which changes, but *some* changes had
> > > > to be made to arch/ppc/platforms/prep_pci.c to get the network card
> > > > working [1] again (network code kept locking up the machine). after this
> > > > issue was resolved, i too noticed the scsi errors [2] others were
> > > > complaing about.
> > >
> > > The issue seems obvious, the patch adds some different way of setting the
> > > irqs, based on the residual data, which fails to do what it should on the
> > > powerstack, and thus the irqs are fully left uninitialized.
> >
> > Can either of you verify that say 2.6.11.6 w/ "noresidual" on the
> > command-line works? Thanks.
>
> Notice that last i checked, there was a typo which forced you to say
> "nopresidual", and i think i did add this when i was testing, and it didn't
> help.
That's a problem, as 'noresidual' was supposed to disable the new stuff
introduced here, for boxes that it may have broken.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: FCC Ethernet startup crash
From: Stefan Nickl @ 2005-04-05 15:56 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859335@ismail.innsys.innovsys.com>
On Tue, 2005-04-05 at 10:37 -0500, Rune Torgersen wrote:
> I've been running into the old problem of the kernel ip stack crasheing
> the kernel, because of early packets again.
>
> This has been mentioned on this list several times before, but the
> worarounds that used to work doesn't seem to work anymore.
> (like changing the order of things in ip_init())
>
> As far as I can tell, it is because the FCC enet drivers starts to
> receive packets way before the ip stack is initialized.
>
> Does anybody have any good ideas on how to fix this?
Maybe you want to try my version:
http://ozlabs.org/ppc32-patches/patch.pl?id=14
Or is it equal to your (no longer working) solution?
--
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply
* Re: 8xx v2.6 TLB problems and suggested workaround
From: Dan Malek @ 2005-04-05 15:58 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Paul Mackerras, linux-ppc-embedded
In-Reply-To: <20050404191718.GA30281@logos.cnet>
On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
> Problem is that the "dcbst" instruction will, _sometimes_ (the
> failure/success rate is about 1/4
> with my test application) fault as a _write_ operation on the data.
Oh, geeze .... It's all coming back to me now ....
The 8xx cache operations don't always operate as defined in the PEM.
There are likely to be some archive discussions within the Freescale
knowledge data base that describe the different behaviors I've seen
with the chip variants and revisions. I can't find any of those e-mail
discussions, so I'll try to recall from memory.
The PEM cache instructions are all implemented in a microcode that
uses the 8xx unique cache control SPRs. Depending upon the state
of the cache and MMU, it seems in some cases the EA translation is
subject to a "normal" protection match instead of a load operation
match.
The behavior of these operations isn't consistent across all of the 8xx
processor revisions, especially with early silicon if people are still
using those. During conversations with Freescale engineers, it seems
the only guaranteed operation was to use the 8xx unique SPRs, but
I think I only did that in 8xx specific functions.
We have way too much code in the TLB exception handlers already,
so let's just try a tlbia of the EA in the update_mmu_cache, with an
#ifdef
for the 8xx. It seems if the dcbst causes a TLB miss during execution,
it does the right thing. We may want to make the dcbxxx instructions
some
kind of macro, so on 8xx we can include such operations in otherwise
"standard" software.
Thanks for the great work!
-- 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