* Re: MPC5200 I2S driver
From: Eric N. Johnson (ACD) @ 2005-04-12 22:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050412211342.B7C92C108D@atlas.denx.de>
At 04:13 PM 4/12/2005, Wolfgang Denk wrote:
>i2s.c is not really a driver, but a (very OLD) test version of one
>used to demonstrate certain BestComm related problems. Don't try
>using it as a real driver ;-)
Humm, any pointers on writing our own driver then then? Digging through
the source for other drivers, bestcomm seems to be a real house of
cards. We just want simple audio output capability. No need to make it
work with the standard Linux/OSS sound API.
Where can we keep track of the eratta/bugs in bestcomm? Browsing through
the mailing list, I've found references that:
IDE and Ethernet DMA can't work at the same time
I2S TX and RX DMA can't work at the same time
AC-97 is terminally broken (no way to handle the slot tags properly
for variable sampling rates)
Are these all still true?
We've tried asking our local Freescale rep, but they seem to think that
Linux==Metrowerks, and they are looking into the bestcomm question, but
official responses from Freescale tend to take >1 week.
This is for a custom MPC5200 board, heavily based on IceCube with a single
I2S DAC on PSC2 running in "CODEC with MCLK" mode.
Sorry about the null subject line previously: fingers were working faster
than brain...
Thanks
Eric
------------------------------------
Eric Johnson, Electrical Engineer
Advanced Communication Design
7901 12th Avenue South
Bloomington, MN 55425
Ph: 952-854-4000 Fax: 952-854-5774
^ permalink raw reply
* Re: (no subject)
From: Wolfgang Denk @ 2005-04-12 21:13 UTC (permalink / raw)
To: Eric N. Johnson (ACD); +Cc: linuxppc-embedded
In-Reply-To: <6.2.1.2.1.20050412143653.02ae7720@mail.int.acdstar.com>
In message <6.2.1.2.1.20050412143653.02ae7720@mail.int.acdstar.com> you wrote:
>
> The kernel included in the DENX ELDK v3.1.1 has two drivers:
> i2s_ring.c and i2s.c.
i2s.c is not really a driver, but a (very OLD) test version of one
used to demonstrate certain BestComm related problems. Don't try
using it as a real driver ;-)
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
People are always a lot more complicated than you think. It's very
important to remember that. - Terry Pratchett, _Truckers_
^ permalink raw reply
* (no subject)
From: Eric N. Johnson (ACD) @ 2005-04-12 19:38 UTC (permalink / raw)
To: linuxppc-embedded
Has anyone been able to use an I2S audio DAC connected to a Programmable
Serial Controllers (PSC) on the Freescale MPC5200 CPU working under Linux?
The kernel included in the DENX ELDK v3.1.1 has two drivers:
i2s_ring.c and i2s.c.
The ring driver appears to be RX only, and the i2s.c driver causes the FEC
ethernet to hang at startup. I've read some previous mailing list messages
that suggest there are issues with bestcomm and i2s support.
We've tried adapting the i2s_ring.c driver for our needs. By default, it
only has a receive task. It partially initializes the port, and we see
appropriate waveforms on the MCLK, CLK, and FRAME lines, but have not been
able to transmit data.
The stock i2s.c driver hung the boot sequence, but if we comment out the
bestcomm startup code, it at least completes the boot cycle. Again we see
appropriate waveforms on the MCLK, CLK, and FRAME lines. If we feed data
to the device (after performing the port setup IOCTLs), we see a 750 us
burst of data every 45 ms or so.
Is it feasible to send 44.1 or 48 KHz 16-bit audio this way or is the PSC
only usable for lower data rate applications?
Thank you,
Eric
------------------------------------
Eric Johnson, Electrical Engineer
Advanced Communication Design
7901 12th Avenue South
Bloomington, MN 55425
Ph: 952-854-4000 Fax: 952-854-5774
^ permalink raw reply
* bdi2000 + mpc8560ads, very early breakpoints
From: Kylo Ginsberg @ 2005-04-12 19:21 UTC (permalink / raw)
To: linuxppc-embedded
I'm running a bdi2000 (with mpc85xx-gdb f/w 1.03) with a mpc8560ads
target, and I'm trying to set breakpoints early on in linux startup (in
the head_e500.S code that sets up tlb's). I'm setting the breakpoints
from within the bdi telnet interface.
I can:
--succesfully hit a breakpoint set up to any instruction <= the address
of the first 'tlbwe'.
--single step (with the bdi "TI" command) past that 'tlbwe' as far as
I've cared to try
I cannot:
--hit a breakpoint once the first 'tlbwe' has executed. If I attempt to
do so, linux startup doesn't proceed, I lose further communication with
the target and the BDI claims "COP Freeze" and I have to reset the target.
Btw, the 'tlbwe' in question marks invalid the first tlb1 entry setup by
u-boot, which pointed at flash address space. Code is running out of
ram at this point.
I'm probably missing something very basic here. Any ideas?
Thanks,
Kylo
^ permalink raw reply
* Re: Warm reboot on 826x targets
From: Frank @ 2005-04-12 19:08 UTC (permalink / raw)
To: Paul Gortmaker, linuxppc-embedded
--- Paul Gortmaker <p_gortmaker@yahoo.com> wrote:
> I've been trying to get a WRS 8265 to do a warm reboot, and
> found some
> things that I am wondering about.
>
> Firstly, is anyone having success on having "reboot" restart
> the machine
> on a similar platform?
>
> Secondly, the default BOOTROM_RESTART_ADDR is 0x40000104
> (sbc82xx.h) and I
> was wondering if this matches any platforms out there. On
> this board, the
> place where U-Boot lives is 0xFFF00104 -- and I've verified
> this by typing
> "g fff00104" at the U-Boot prompt which causes U-Boot to
> simply restart.
>
> I've changed the value in sbc82xx.h and now at the reboot,
> instead of a
> register dump, it simply hangs. Looking at m8260_gorom (in
> kernel/head.S)
> it clears the MSR_EE (ext int. enable) bit in the MSR before
> jumping --
> but I was wondering if there are other bits in MSR that need
> to be
> cleared; e.g. instruction relocation enable and data
> relocation enable
> (MSR_IR and MSR_DR). The register bits are on p76 of
> MPCFPE32B.pdf from
> Freescale.
>
> I guess if somebody even said "it works for me" then I'd have
> a better
> feeling thinking that what is done to the MSR currently is
> sufficient.
>
> Paul.
>
I'm working on the exact same problem with u-boot (trying to do
warm reboot from the VxWorks shell). I modified romInit.S to
pass control to u-boot (at 0xfe000000) and that works just fine.
But after I boot VxWorks from u-boot (go 0xfff00100) and invoke
reboot from the VxWorks shell, it just hangs. If I boot VxWorks
without invoking u-boot first, it works fine. If you find the
problem befor me, let me know and I'll do tha same...
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
^ permalink raw reply
* Re: Warm reboot on 826x targets
From: Eugene Surovegin @ 2005-04-12 18:31 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-embedded
In-Reply-To: <20050412181436.12272.qmail@web60501.mail.yahoo.com>
On Tue, Apr 12, 2005 at 11:14:35AM -0700, Paul Gortmaker wrote:
> I've been trying to get a WRS 8265 to do a warm reboot, and found some
> things that I am wondering about.
>
> Firstly, is anyone having success on having "reboot" restart the machine
> on a similar platform?
>
> Secondly, the default BOOTROM_RESTART_ADDR is 0x40000104 (sbc82xx.h) and I
> was wondering if this matches any platforms out there. On this board, the
> place where U-Boot lives is 0xFFF00104 -- and I've verified this by typing
> "g fff00104" at the U-Boot prompt which causes U-Boot to simply restart.
>
> I've changed the value in sbc82xx.h and now at the reboot, instead of a
> register dump, it simply hangs. Looking at m8260_gorom (in kernel/head.S)
> it clears the MSR_EE (ext int. enable) bit in the MSR before jumping --
> but I was wondering if there are other bits in MSR that need to be
> cleared; e.g. instruction relocation enable and data relocation enable
> (MSR_IR and MSR_DR). The register bits are on p76 of MPCFPE32B.pdf from
> Freescale.
>
> I guess if somebody even said "it works for me" then I'd have a better
> feeling thinking that what is done to the MSR currently is sufficient.
I don't have any problems using reboot() on 8248 based board.
Kernel.org-based 2.4.29 tree.
I have U-Boot at 0xfe00'0000, and I use 0xfe00'0104 as a second
parameter for m8260_gorom. Also make sure that first parameter is also
correct:
m8260_gorom(__pa(__res), 0xfe000104);
--
Eugene
^ permalink raw reply
* Warm reboot on 826x targets
From: Paul Gortmaker @ 2005-04-12 18:14 UTC (permalink / raw)
To: linuxppc-embedded
I've been trying to get a WRS 8265 to do a warm reboot, and found some
things that I am wondering about.
Firstly, is anyone having success on having "reboot" restart the machine
on a similar platform?
Secondly, the default BOOTROM_RESTART_ADDR is 0x40000104 (sbc82xx.h) and I
was wondering if this matches any platforms out there. On this board, the
place where U-Boot lives is 0xFFF00104 -- and I've verified this by typing
"g fff00104" at the U-Boot prompt which causes U-Boot to simply restart.
I've changed the value in sbc82xx.h and now at the reboot, instead of a
register dump, it simply hangs. Looking at m8260_gorom (in kernel/head.S)
it clears the MSR_EE (ext int. enable) bit in the MSR before jumping --
but I was wondering if there are other bits in MSR that need to be
cleared; e.g. instruction relocation enable and data relocation enable
(MSR_IR and MSR_DR). The register bits are on p76 of MPCFPE32B.pdf from
Freescale.
I guess if somebody even said "it works for me" then I'd have a better
feeling thinking that what is done to the MSR currently is sufficient.
Paul.
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
^ permalink raw reply
* Help needed Linux-2.6 - MPC8541
From: Junita Ajith @ 2005-04-12 17:38 UTC (permalink / raw)
To: linuxppc-embedded, pari
Hi
We are trying to port Linux-2.6 for our custom
MPC8541 board.
We have a TSEC and an FEC in the board.
With the "Networking Support" disabled in the Kernel,
the board boots up fine and gets to the prompt.
But with the "Networking Support" enabled in the
kernel the board hangs where it identifies the PHY,
inspite of giving the corrct PHY ID.
Any help is greatly appreciated.
PS:
We have linux-2.4 ported for the same board and so
taking that as reference trying to port Linux-2.6 ,
but havent succeeded yet.
Thanks
Junita
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: [PATCH] ppc32: Fix alignment exception checking on load/store multiple instructions
From: Dan Malek @ 2005-04-12 16:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <cb6c89fb776248d3a2ddbcd5d3d043ed@freescale.com>
On Apr 12, 2005, at 11:26 AM, Kumar Gala wrote:
> Upon further review, the PEM and PPC Arch spec, say that its ok to
> emulate lwarz as an lwz. From the spec:
Hmmm ... Seems weird. Since the emulation won't create the
reservation,
the subsequent stwcx will fail. If the stwcx to the same unaligned
address
will be a programming error.
Also, the EREF states that neither the lwarx nor stwcx should be
emulated,
and it's a programming error to have unaligned accesses with these.
I still don't like this "similar but different" Book-E architecture,
but I guess
we have to live with it ....
> The instructions lwz and lwarx give the same DSISR bits (all zero).
> But if lwarx causes an Alignment interrupt, it should not be emulated.
??? Those are nearly the same words from the EREF, I just didn't find
anything
like the following.
> ... It is adequate for the Alignment interrupt handler simply to treat
> the instruction as if it were lwz. The emulator
> must use the address in the DAR, rather than compute it from RA/RB/D,
> because lwz and lwarx have different instruction formats.
I guess it's done as lwz because it's not possible to actually emulate
an
unaligned lwarx?
> So we are handled lwarx according to the arch specs already.
If that's the way you read it :-) Probably not worth the discussion,
but
I brought it up since we are here and it will be soon forgotten.
Thanks.
-- Dan
^ permalink raw reply
* Re: Trying to understand alloc_skb()
From: Eugene Surovegin @ 2005-04-12 16:12 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca6570504120138738b554f@mail.gmail.com>
On Tue, Apr 12, 2005 at 05:38:01PM +0900, Daniel Ann wrote:
> My problem is that, kernel dies with "alloc_skb called nonatomically
> from interrupt c00ba718" message. After browsing mailing list, I think
> its to do with not providing it with enough locks prior.
>
> Question is, what kind of lock should I be providing ?
You don't need any locks, just pass correct gfp_mask parameter to
alloc_skb when it's called from IRQ context, e.g. GFP_ATOMIC.
--
Eugene
^ permalink raw reply
* Re: [PATCH] ppc32: Fix alignment exception checking on load/store multiple instructions
From: Dan Malek @ 2005-04-12 15:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Kumar Gala
In-Reply-To: <7f0a378a4f3b17a9db01773fcca5fafd@freescale.com>
On Apr 12, 2005, at 11:06 AM, Kumar Gala wrote:
> When you say "fix up" I assume you mean lwarx should return 0. It
> appears that stwcx. is already doing that. Can't think of any other
> cases that need fixing.
Yes, it should return an error. From a quick look at the slicing of the
bits in the code, it appears lawrx is decoded the same as lw.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] ppc32: Fix alignment exception checking on load/store multiple instructions
From: Kumar Gala @ 2005-04-12 15:26 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list
In-Reply-To: <7f0a378a4f3b17a9db01773fcca5fafd@freescale.com>
> > > The handling of misaligned load/store multiplies did not check to=20=
> see
> > > if
> >=A0 > the address were ok to access before __{get,put}_user().
> >
> > I think we should also take the opportunity to fix up the lawrx
> > case and look for other reserved/conditional instructions
> >=A0 that may slip through.=A0 Since these are atomic operations, we
> > can't emulate them.=A0 According to the PEM, an alignment fault
> > on these is a fatal programming error.
>
> When you say "fix up" I assume you mean lwarx should return 0.=A0 It
> appears that stwcx. is already doing that.=A0 Can't think of any other
> cases that need fixing.
Upon further review, the PEM and PPC Arch spec, say that its ok to=20
emulate lwarz as an lwz. =46rom the spec:
The instructions lwz and lwarx give the same DSISR bits (all zero). But=20=
if lwarx causes an Alignment interrupt, it should not be emulated. It=20
is adequate for the Alignment interrupt handler simply to treat the=20
instruction as if it were lwz. The emulator
must use the address in the DAR, rather than compute it from RA/RB/D,=20
because lwz and lwarx have different instruction formats.
So we are handled lwarx according to the arch specs already.
- kumar=
^ permalink raw reply
* Re: [PATCH] ppc32: Fix alignment exception checking on load/store multiple instructions
From: Kumar Gala @ 2005-04-12 15:06 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Kumar Gala
In-Reply-To: <83a359bdf2c4d4902f58e6788c37811a@embeddededge.com>
On Apr 12, 2005, at 9:46 AM, Dan Malek wrote:
>
>
> On Apr 12, 2005, at 2:03 AM, Kumar Gala wrote:
>
> > The handling of misaligned load/store multiplies did not check to =
see
> > if
> > the address were ok to access before __{get,put}_user().
>
> I think we should also take the opportunity to fix up the lawrx
> case and look for other reserved/conditional instructions
> that may slip through.=A0 Since these are atomic operations, we
> can't emulate them.=A0 According to the PEM, an alignment fault
> on these is a fatal programming error.
When you say "fix up" I assume you mean lwarx should return 0. It=20
appears that stwcx. is already doing that. Can't think of any other=20
cases that need fixing.
- kumar
^ permalink raw reply
* Re: [PATCH] ppc32: refactor FPU exception handling
From: Kumar Gala @ 2005-04-12 14:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev list, Jason McMullan
In-Reply-To: <f54dd3f8af3f508dc7774fb841a8877a@freescale.com>
Here is an updated version of the patch which moves the fast exception
return code into entry.S. Not sure if I see any reason we can't have akpm
merge this into -mm so people test it there.
Moved common FPU exception handling code out of head.S so it can be used
by several of the sub-architectures that might of a full PowerPC FPU.
Also, uses new CONFIG_PPC_FPU define to fix alignment exception
handling for floating point load/store instructions to only occur if we
have a hardware FPU.
Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/Kconfig 2005-04-12 09:54:36 -05:00
@@ -53,6 +53,7 @@
config 6xx
bool "6xx/7xx/74xx/52xx/82xx/83xx"
+ select PPC_FPU
help
There are four types of PowerPC chips supported. The more common
types (601, 603, 604, 740, 750, 7400), the Motorola embedded
@@ -85,6 +86,9 @@
bool "e500"
endchoice
+
+config PPC_FPU
+ bool
config BOOKE
bool
diff -Nru a/arch/ppc/Makefile b/arch/ppc/Makefile
--- a/arch/ppc/Makefile 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/Makefile 2005-04-12 09:54:36 -05:00
@@ -53,6 +53,7 @@
head-$(CONFIG_6xx) += arch/ppc/kernel/idle_6xx.o
head-$(CONFIG_POWER4) += arch/ppc/kernel/idle_power4.o
+head-$(CONFIG_PPC_FPU) += arch/ppc/kernel/fpu.o
core-y += arch/ppc/kernel/ arch/ppc/platforms/ \
arch/ppc/mm/ arch/ppc/lib/ arch/ppc/syslib/
diff -Nru a/arch/ppc/kernel/Makefile b/arch/ppc/kernel/Makefile
--- a/arch/ppc/kernel/Makefile 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/kernel/Makefile 2005-04-12 09:54:36 -05:00
@@ -9,6 +9,7 @@
extra-$(CONFIG_8xx) := head_8xx.o
extra-$(CONFIG_6xx) += idle_6xx.o
extra-$(CONFIG_POWER4) += idle_power4.o
+extra-$(CONFIG_PPC_FPU) += fpu.o
extra-y += vmlinux.lds
obj-y := entry.o traps.o irq.o idle.o time.o misc.o \
diff -Nru a/arch/ppc/kernel/align.c b/arch/ppc/kernel/align.c
--- a/arch/ppc/kernel/align.c 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/kernel/align.c 2005-04-12 09:54:36 -05:00
@@ -368,16 +368,24 @@
/* Single-precision FP load and store require conversions... */
case LD+F+S:
+#ifdef CONFIG_PPC_FPU
preempt_disable();
enable_kernel_fp();
cvt_fd(&data.f, &data.d, ¤t->thread.fpscr);
preempt_enable();
+#else
+ return 0;
+#endif
break;
case ST+F+S:
+#ifdef CONFIG_PPC_FPU
preempt_disable();
enable_kernel_fp();
cvt_df(&data.d, &data.f, ¤t->thread.fpscr);
preempt_enable();
+#else
+ return 0;
+#endif
break;
}
diff -Nru a/arch/ppc/kernel/entry.S b/arch/ppc/kernel/entry.S
--- a/arch/ppc/kernel/entry.S 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/kernel/entry.S 2005-04-12 09:54:36 -05:00
@@ -563,6 +563,65 @@
addi r1,r1,INT_FRAME_SIZE
blr
+ .globl fast_exception_return
+fast_exception_return:
+#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
+ andi. r10,r9,MSR_RI /* check for recoverable interrupt */
+ beq 1f /* if not, we've got problems */
+#endif
+
+2: REST_4GPRS(3, r11)
+ lwz r10,_CCR(r11)
+ REST_GPR(1, r11)
+ mtcr r10
+ lwz r10,_LINK(r11)
+ mtlr r10
+ REST_GPR(10, r11)
+ mtspr SPRN_SRR1,r9
+ mtspr SPRN_SRR0,r12
+ REST_GPR(9, r11)
+ REST_GPR(12, r11)
+ lwz r11,GPR11(r11)
+ SYNC
+ RFI
+
+#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
+/* check if the exception happened in a restartable section */
+1: lis r3,exc_exit_restart_end@ha
+ addi r3,r3,exc_exit_restart_end@l
+ cmplw r12,r3
+ bge 3f
+ lis r4,exc_exit_restart@ha
+ addi r4,r4,exc_exit_restart@l
+ cmplw r12,r4
+ blt 3f
+ lis r3,fee_restarts@ha
+ tophys(r3,r3)
+ lwz r5,fee_restarts@l(r3)
+ addi r5,r5,1
+ stw r5,fee_restarts@l(r3)
+ mr r12,r4 /* restart at exc_exit_restart */
+ b 2b
+
+ .comm fee_restarts,4
+
+/* aargh, a nonrecoverable interrupt, panic */
+/* aargh, we don't know which trap this is */
+/* but the 601 doesn't implement the RI bit, so assume it's OK */
+3:
+BEGIN_FTR_SECTION
+ b 2b
+END_FTR_SECTION_IFSET(CPU_FTR_601)
+ li r10,-1
+ stw r10,TRAP(r11)
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ lis r10,MSR_KERNEL@h
+ ori r10,r10,MSR_KERNEL@l
+ bl transfer_to_handler_full
+ .long nonrecoverable_exception
+ .long ret_from_except
+#endif
+
.globl sigreturn_exit
sigreturn_exit:
subi r1,r3,STACK_FRAME_OVERHEAD
diff -Nru a/arch/ppc/kernel/fpu.S b/arch/ppc/kernel/fpu.S
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/kernel/fpu.S 2005-04-12 09:54:36 -05:00
@@ -0,0 +1,133 @@
+/*
+ * FPU support code, moved here from head.S so that it can be used
+ * by chips which use other head-whatever.S files.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#include <linux/config.h>
+#include <asm/processor.h>
+#include <asm/page.h>
+#include <asm/mmu.h>
+#include <asm/pgtable.h>
+#include <asm/cputable.h>
+#include <asm/cache.h>
+#include <asm/thread_info.h>
+#include <asm/ppc_asm.h>
+#include <asm/offsets.h>
+
+/*
+ * This task wants to use the FPU now.
+ * On UP, disable FP for the task which had the FPU previously,
+ * and save its floating-point registers in its thread_struct.
+ * Load up this task's FP registers from its thread_struct,
+ * enable the FPU for the current task and return to the task.
+ */
+ .globl load_up_fpu
+load_up_fpu:
+ mfmsr r5
+ ori r5,r5,MSR_FP
+#ifdef CONFIG_PPC64BRIDGE
+ clrldi r5,r5,1 /* turn off 64-bit mode */
+#endif /* CONFIG_PPC64BRIDGE */
+ SYNC
+ MTMSRD(r5) /* enable use of fpu now */
+ isync
+/*
+ * For SMP, we don't do lazy FPU switching because it just gets too
+ * horrendously complex, especially when a task switches from one CPU
+ * to another. Instead we call giveup_fpu in switch_to.
+ */
+#ifndef CONFIG_SMP
+ tophys(r6,0) /* get __pa constant */
+ addis r3,r6,last_task_used_math@ha
+ lwz r4,last_task_used_math@l(r3)
+ cmpwi 0,r4,0
+ beq 1f
+ add r4,r4,r6
+ addi r4,r4,THREAD /* want last_task_used_math->thread */
+ SAVE_32FPRS(0, r4)
+ mffs fr0
+ stfd fr0,THREAD_FPSCR-4(r4)
+ lwz r5,PT_REGS(r4)
+ add r5,r5,r6
+ lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+ li r10,MSR_FP|MSR_FE0|MSR_FE1
+ andc r4,r4,r10 /* disable FP for previous task */
+ stw r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+1:
+#endif /* CONFIG_SMP */
+ /* enable use of FP after return */
+ mfspr r5,SPRN_SPRG3 /* current task's THREAD (phys) */
+ lwz r4,THREAD_FPEXC_MODE(r5)
+ ori r9,r9,MSR_FP /* enable FP for current */
+ or r9,r9,r4
+ lfd fr0,THREAD_FPSCR-4(r5)
+ mtfsf 0xff,fr0
+ REST_32FPRS(0, r5)
+#ifndef CONFIG_SMP
+ subi r4,r5,THREAD
+ sub r4,r4,r6
+ stw r4,last_task_used_math@l(r3)
+#endif /* CONFIG_SMP */
+ /* restore registers and return */
+ /* we haven't used ctr or xer or lr */
+ b fast_exception_return
+
+/*
+ * FP unavailable trap from kernel - print a message, but let
+ * the task use FP in the kernel until it returns to user mode.
+ */
+ .globl KernelFP
+KernelFP:
+ lwz r3,_MSR(r1)
+ ori r3,r3,MSR_FP
+ stw r3,_MSR(r1) /* enable use of FP after return */
+ lis r3,86f@h
+ ori r3,r3,86f@l
+ mr r4,r2 /* current */
+ lwz r5,_NIP(r1)
+ bl printk
+ b ret_from_except
+86: .string "floating point used in kernel (task=%p, pc=%x)\n"
+ .align 4,0
+
+/*
+ * giveup_fpu(tsk)
+ * Disable FP for the task given as the argument,
+ * and save the floating-point registers in its thread_struct.
+ * Enables the FPU for use in the kernel on return.
+ */
+ .globl giveup_fpu
+giveup_fpu:
+ mfmsr r5
+ ori r5,r5,MSR_FP
+ SYNC_601
+ ISYNC_601
+ MTMSRD(r5) /* enable use of fpu now */
+ SYNC_601
+ isync
+ cmpwi 0,r3,0
+ beqlr- /* if no previous owner, done */
+ addi r3,r3,THREAD /* want THREAD of task */
+ lwz r5,PT_REGS(r3)
+ cmpwi 0,r5,0
+ SAVE_32FPRS(0, r3)
+ mffs fr0
+ stfd fr0,THREAD_FPSCR-4(r3)
+ beq 1f
+ lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+ li r3,MSR_FP|MSR_FE0|MSR_FE1
+ andc r4,r4,r3 /* disable FP for previous task */
+ stw r4,_MSR-STACK_FRAME_OVERHEAD(r5)
+1:
+#ifndef CONFIG_SMP
+ li r5,0
+ lis r4,last_task_used_math@ha
+ stw r5,last_task_used_math@l(r4)
+#endif /* CONFIG_SMP */
+ blr
diff -Nru a/arch/ppc/kernel/head.S b/arch/ppc/kernel/head.S
--- a/arch/ppc/kernel/head.S 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/kernel/head.S 2005-04-12 09:54:36 -05:00
@@ -775,133 +775,6 @@
EXC_XFER_STD(0x480, UnknownException)
#endif /* CONFIG_PPC64BRIDGE */
-/*
- * This task wants to use the FPU now.
- * On UP, disable FP for the task which had the FPU previously,
- * and save its floating-point registers in its thread_struct.
- * Load up this task's FP registers from its thread_struct,
- * enable the FPU for the current task and return to the task.
- */
-load_up_fpu:
- mfmsr r5
- ori r5,r5,MSR_FP
-#ifdef CONFIG_PPC64BRIDGE
- clrldi r5,r5,1 /* turn off 64-bit mode */
-#endif /* CONFIG_PPC64BRIDGE */
- SYNC
- MTMSRD(r5) /* enable use of fpu now */
- isync
-/*
- * For SMP, we don't do lazy FPU switching because it just gets too
- * horrendously complex, especially when a task switches from one CPU
- * to another. Instead we call giveup_fpu in switch_to.
- */
-#ifndef CONFIG_SMP
- tophys(r6,0) /* get __pa constant */
- addis r3,r6,last_task_used_math@ha
- lwz r4,last_task_used_math@l(r3)
- cmpwi 0,r4,0
- beq 1f
- add r4,r4,r6
- addi r4,r4,THREAD /* want last_task_used_math->thread */
- SAVE_32FPRS(0, r4)
- mffs fr0
- stfd fr0,THREAD_FPSCR-4(r4)
- lwz r5,PT_REGS(r4)
- add r5,r5,r6
- lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5)
- li r10,MSR_FP|MSR_FE0|MSR_FE1
- andc r4,r4,r10 /* disable FP for previous task */
- stw r4,_MSR-STACK_FRAME_OVERHEAD(r5)
-1:
-#endif /* CONFIG_SMP */
- /* enable use of FP after return */
- mfspr r5,SPRN_SPRG3 /* current task's THREAD (phys) */
- lwz r4,THREAD_FPEXC_MODE(r5)
- ori r9,r9,MSR_FP /* enable FP for current */
- or r9,r9,r4
- lfd fr0,THREAD_FPSCR-4(r5)
- mtfsf 0xff,fr0
- REST_32FPRS(0, r5)
-#ifndef CONFIG_SMP
- subi r4,r5,THREAD
- sub r4,r4,r6
- stw r4,last_task_used_math@l(r3)
-#endif /* CONFIG_SMP */
- /* restore registers and return */
- /* we haven't used ctr or xer or lr */
- /* fall through to fast_exception_return */
-
- .globl fast_exception_return
-fast_exception_return:
- andi. r10,r9,MSR_RI /* check for recoverable interrupt */
- beq 1f /* if not, we've got problems */
-2: REST_4GPRS(3, r11)
- lwz r10,_CCR(r11)
- REST_GPR(1, r11)
- mtcr r10
- lwz r10,_LINK(r11)
- mtlr r10
- REST_GPR(10, r11)
- mtspr SPRN_SRR1,r9
- mtspr SPRN_SRR0,r12
- REST_GPR(9, r11)
- REST_GPR(12, r11)
- lwz r11,GPR11(r11)
- SYNC
- RFI
-
-/* check if the exception happened in a restartable section */
-1: lis r3,exc_exit_restart_end@ha
- addi r3,r3,exc_exit_restart_end@l
- cmplw r12,r3
- bge 3f
- lis r4,exc_exit_restart@ha
- addi r4,r4,exc_exit_restart@l
- cmplw r12,r4
- blt 3f
- lis r3,fee_restarts@ha
- tophys(r3,r3)
- lwz r5,fee_restarts@l(r3)
- addi r5,r5,1
- stw r5,fee_restarts@l(r3)
- mr r12,r4 /* restart at exc_exit_restart */
- b 2b
-
- .comm fee_restarts,4
-
-/* aargh, a nonrecoverable interrupt, panic */
-/* aargh, we don't know which trap this is */
-/* but the 601 doesn't implement the RI bit, so assume it's OK */
-3:
-BEGIN_FTR_SECTION
- b 2b
-END_FTR_SECTION_IFSET(CPU_FTR_601)
- li r10,-1
- stw r10,TRAP(r11)
- addi r3,r1,STACK_FRAME_OVERHEAD
- li r10,MSR_KERNEL
- bl transfer_to_handler_full
- .long nonrecoverable_exception
- .long ret_from_except
-
-/*
- * FP unavailable trap from kernel - print a message, but let
- * the task use FP in the kernel until it returns to user mode.
- */
-KernelFP:
- lwz r3,_MSR(r1)
- ori r3,r3,MSR_FP
- stw r3,_MSR(r1) /* enable use of FP after return */
- lis r3,86f@h
- ori r3,r3,86f@l
- mr r4,r2 /* current */
- lwz r5,_NIP(r1)
- bl printk
- b ret_from_except
-86: .string "floating point used in kernel (task=%p, pc=%x)\n"
- .align 4,0
-
#ifdef CONFIG_ALTIVEC
/* Note that the AltiVec support is closely modeled after the FP
* support. Changes to one are likely to be applicable to the
@@ -1014,42 +887,6 @@
#endif /* CONFIG_SMP */
blr
#endif /* CONFIG_ALTIVEC */
-
-/*
- * giveup_fpu(tsk)
- * Disable FP for the task given as the argument,
- * and save the floating-point registers in its thread_struct.
- * Enables the FPU for use in the kernel on return.
- */
- .globl giveup_fpu
-giveup_fpu:
- mfmsr r5
- ori r5,r5,MSR_FP
- SYNC_601
- ISYNC_601
- MTMSRD(r5) /* enable use of fpu now */
- SYNC_601
- isync
- cmpwi 0,r3,0
- beqlr- /* if no previous owner, done */
- addi r3,r3,THREAD /* want THREAD of task */
- lwz r5,PT_REGS(r3)
- cmpwi 0,r5,0
- SAVE_32FPRS(0, r3)
- mffs fr0
- stfd fr0,THREAD_FPSCR-4(r3)
- beq 1f
- lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5)
- li r3,MSR_FP|MSR_FE0|MSR_FE1
- andc r4,r4,r3 /* disable FP for previous task */
- stw r4,_MSR-STACK_FRAME_OVERHEAD(r5)
-1:
-#ifndef CONFIG_SMP
- li r5,0
- lis r4,last_task_used_math@ha
- stw r5,last_task_used_math@l(r4)
-#endif /* CONFIG_SMP */
- blr
/*
* This code is jumped to from the startup code to copy
diff -Nru a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
--- a/arch/ppc/kernel/head_44x.S 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/kernel/head_44x.S 2005-04-12 09:54:36 -05:00
@@ -426,7 +426,11 @@
PROGRAM_EXCEPTION
/* Floating Point Unavailable Interrupt */
+#ifdef CONFIG_PPC_FPU
+ FP_UNAVAILABLE_EXCEPTION
+#else
EXCEPTION(0x2010, FloatingPointUnavailable, UnknownException, EXC_XFER_EE)
+#endif
/* System Call Interrupt */
START_EXCEPTION(SystemCall)
@@ -686,9 +690,11 @@
*
* The 44x core does not have an FPU.
*/
+#ifndef CONFIG_PPC_FPU
_GLOBAL(giveup_fpu)
blr
-
+#endif
+
/*
* extern void abort(void)
*
diff -Nru a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h
--- a/arch/ppc/kernel/head_booke.h 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/kernel/head_booke.h 2005-04-12 09:54:36 -05:00
@@ -337,4 +337,11 @@
addi r3,r1,STACK_FRAME_OVERHEAD; \
EXC_XFER_LITE(0x0900, timer_interrupt)
+#define FP_UNAVAILABLE_EXCEPTION \
+ START_EXCEPTION(FloatingPointUnavailable) \
+ NORMAL_EXCEPTION_PROLOG; \
+ bne load_up_fpu; /* if from user, just load it up */ \
+ addi r3,r1,STACK_FRAME_OVERHEAD; \
+ EXC_XFER_EE_LITE(0x800, KernelFP)
+
#endif /* __HEAD_BOOKE_H__ */
diff -Nru a/arch/ppc/kernel/head_fsl_booke.S b/arch/ppc/kernel/head_fsl_booke.S
--- a/arch/ppc/kernel/head_fsl_booke.S 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/kernel/head_fsl_booke.S 2005-04-12 09:54:36 -05:00
@@ -477,7 +477,11 @@
PROGRAM_EXCEPTION
/* Floating Point Unavailable Interrupt */
+#ifdef CONFIG_PPC_FPU
+ FP_UNAVAILABLE_EXCEPTION
+#else
EXCEPTION(0x0800, FloatingPointUnavailable, UnknownException, EXC_XFER_EE)
+#endif
/* System Call Interrupt */
START_EXCEPTION(SystemCall)
@@ -883,10 +887,12 @@
/*
* extern void giveup_fpu(struct task_struct *prev)
*
- * The e500 core does not have an FPU.
+ * Not all FSL Book-E cores have an FPU
*/
+#ifndef CONFIG_PPC_FPU
_GLOBAL(giveup_fpu)
blr
+#endif
/*
* extern void abort(void)
diff -Nru a/arch/ppc/kernel/misc.S b/arch/ppc/kernel/misc.S
--- a/arch/ppc/kernel/misc.S 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/kernel/misc.S 2005-04-12 09:54:36 -05:00
@@ -1096,17 +1096,7 @@
* and exceptions as if the cpu had performed the load or store.
*/
-#if defined(CONFIG_4xx) || defined(CONFIG_E500)
-_GLOBAL(cvt_fd)
- lfs 0,0(r3)
- stfd 0,0(r4)
- blr
-
-_GLOBAL(cvt_df)
- lfd 0,0(r3)
- stfs 0,0(r4)
- blr
-#else
+#ifdef CONFIG_PPC_FPU
_GLOBAL(cvt_fd)
lfd 0,-4(r5) /* load up fpscr value */
mtfsf 0xff,0
diff -Nru a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
--- a/arch/ppc/kernel/traps.c 2005-04-12 09:54:36 -05:00
+++ b/arch/ppc/kernel/traps.c 2005-04-12 09:54:36 -05:00
@@ -176,7 +176,7 @@
#else
#define get_mc_reason(regs) (mfspr(SPRN_MCSR))
#endif
-#define REASON_FP 0
+#define REASON_FP ESR_FP
#define REASON_ILLEGAL ESR_PIL
#define REASON_PRIVILEGED ESR_PPR
#define REASON_TRAP ESR_PTR
diff -Nru a/include/asm-ppc/reg_booke.h b/include/asm-ppc/reg_booke.h
--- a/include/asm-ppc/reg_booke.h 2005-04-12 09:54:36 -05:00
+++ b/include/asm-ppc/reg_booke.h 2005-04-12 09:54:36 -05:00
@@ -304,6 +304,7 @@
#define ESR_PIL 0x08000000 /* Program Exception - Illegal */
#define ESR_PPR 0x04000000 /* Program Exception - Priveleged */
#define ESR_PTR 0x02000000 /* Program Exception - Trap */
+#define ESR_FP 0x01000000 /* Floating Point Operation */
#define ESR_DST 0x00800000 /* Storage Exception - Data miss */
#define ESR_DIZ 0x00400000 /* Storage Exception - Zone fault */
#define ESR_ST 0x00800000 /* Store Operation */
^ permalink raw reply
* Re: [PATCH] ppc32: Fix alignment exception checking on load/store multiple instructions
From: Dan Malek @ 2005-04-12 14:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.61.0504120101210.10781@blarg.somerset.sps.mot.com>
On Apr 12, 2005, at 2:03 AM, Kumar Gala wrote:
> The handling of misaligned load/store multiplies did not check to see
> if
> the address were ok to access before __{get,put}_user().
I think we should also take the opportunity to fix up the lawrx
case and look for other reserved/conditional instructions
that may slip through. Since these are atomic operations, we
can't emulate them. According to the PEM, an alignment fault
on these is a fatal programming error.
Thanks.
-- Dan
^ permalink raw reply
* Re: Trying to understand alloc_skb()
From: John W. Linville @ 2005-04-12 13:51 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca657050412060556af952e@mail.gmail.com>
On Tue, Apr 12, 2005 at 10:05:14PM +0900, Daniel Ann wrote:
> On Apr 12, 2005 9:24 PM, John W. Linville <linville@tuxdriver.com> wrote:
> > You may want to consider dev_alloc_skb...
>
> Ahh that's right. I remember reading a little comment on top dev_alloc_skb().
> Thank you so much. At least that inspired me :)
>
> Thing is, I got this error during a call to notifier_call_chain. So..
My guess would be that your best bet is to move your call to
notifier_call_chain off to a workqueue. notifier_call_chain (and/or
one or more of the functions it is calling) is likely written to
expect to be in process context.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: Trying to understand alloc_skb()
From: John W. Linville @ 2005-04-12 12:24 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca6570504120138738b554f@mail.gmail.com>
On Tue, Apr 12, 2005 at 05:38:01PM +0900, Daniel Ann wrote:
> My problem is that, kernel dies with "alloc_skb called nonatomically
> from interrupt c00ba718" message. After browsing mailing list, I think
> its to do with not providing it with enough locks prior.
You may want to consider dev_alloc_skb...
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: Trying to understand alloc_skb()
From: Daniel Ann @ 2005-04-12 13:05 UTC (permalink / raw)
To: Daniel Ann, linuxppc-embedded
In-Reply-To: <20050412122405.GA27920@tuxdriver.com>
On Apr 12, 2005 9:24 PM, John W. Linville <linville@tuxdriver.com> wrote:
> You may want to consider dev_alloc_skb...
Ahh that's right. I remember reading a little comment on top dev_alloc_skb().
Thank you so much. At least that inspired me :)
Thing is, I got this error during a call to notifier_call_chain. So..
I would have to go thru the functions who is responsible for issueing
alloc_skb directly. Gonna take a little while :P
Cheers,
--
Daniel
^ permalink raw reply
* Re: IDE and PCI
From: Marcin Dawidowicz @ 2005-04-12 10:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200504121214.28076.Schramel.Linux@go.bartec.de>
Hi,
On Tuesday 12 of April 2005 12:14, Marco Schramel wrote:
> Hi
>
> we runs a 2.4.25 on a custum board (MPC8270). We use compact flash over
> UPM. All runs fine. But if i config in the pci bus the i/o accesses on
> compact flash will fail. The kernel booting fails and it hangs up. At the
> same time i can read out the cf registers with bdi.
> It crashes on the first INB() call in ide_probe.c. "stat =
> hwif->INB(hwif->io_ports[IDE_STATUS_OFFSET]);". Without pci it works fine.
Propably isa_io_base is set to beginning of PCI IO area when PCI is enabled.
So all io accesses are mapped in different location. In this case you may
need to add additional offset to default io port addresses for compact flash
access.
Best regards,
Marcin
^ permalink raw reply
* Latest gnu tools for PPC
From: Prince V S @ 2005-04-12 10:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 167 bytes --]
Hi,
Can anybody tell me about the latest working gnu tool chain versions for PPC(IBM405EP). I am planning to use linux kernel-2.6.11.1.
Thanks,
Prince V.S
[-- Attachment #2: Type: text/html, Size: 675 bytes --]
^ permalink raw reply
* IDE and PCI
From: Marco Schramel @ 2005-04-12 10:14 UTC (permalink / raw)
To: PPC_LINUX
Hi
we runs a 2.4.25 on a custum board (MPC8270). We use compact flash over UPM. All runs fine.
But if i config in the pci bus the i/o accesses on compact flash will fail. The kernel booting fails and it hangs up.
At the same time i can read out the cf registers with bdi.
It crashes on the first INB() call in ide_probe.c. "stat = hwif->INB(hwif->io_ports[IDE_STATUS_OFFSET]);". Without pci it works fine.
Any ideas?
Thanks in advance
Marco
^ permalink raw reply
* RE: MTD Mapping driver - out of vmalloc space
From: Chris Elston @ 2005-04-12 10:07 UTC (permalink / raw)
To: linuxppc-embedded
>=20>=20How=20about=20setting=20PAGE_OFFSET=20to=200x80000000,=20that=20is=
=202G/2G=20split?
>=20>=20It=20would=20make=20enough=20virtual=20address=20space.=20I've=20n=
ever=20tried=20on=20PPC,
>=20>=20so=20I=20don't=20know=20the=20side=20effect=20of=20this.=20
>=20
>=20This=20is=20the=20ideal=20solution.=20=20It=20works=20fine=20with=20th=
e=20caveat=20that
>=20you=20have=20to=20be=20very=20aware=20of=20the=20virtual=20memory=20ma=
p=20of=20your=20board
>=20port=20when=20doing=20this.=20=20On=20ppc32,=20we=20have=20very=20fine=
=20grained=20options
>=20for=20manipulating=20this=20and=20other=20parameters=20under=20Advance=
d=20Options.
>=20If=20the=20original=20poster=20can=20provide=20more=20details=20then=20=
we=20can=20tell
>=20him=20the=20exact=20settings=20to=20use.
Thanks=20for=20everyone's=20input=20on=20this,=20I've=20moved=20the=20kern=
el=20virtual
base=20address=20to=200xa0000000,=20and=20it=20works=20fine=20now.=20=20
I'm=20still=20not=20convinced=20that=20this=20is=20a=20future=20proof=20so=
lution=20
though.=20=20What=20happens=20when=20I=20get=20a=20board=20with=20512MB=20=
Flash=201GB=20SDRAM?
I=20can=20push=20the=20top=20of=20the=20SDRAM=20out=20to=20the=20high=20me=
m=20area,=20but=20I'll=20
have=20to=20encroach=20further=20into=20user=20space=20to=20map=20the=20Fl=
ash.=20=20There's
no=20good=20reason=20that=20the=20whole=20of=20the=20Flash=20need=20be=20m=
apped=20at=20the=20same
time.=20(Perhaps=20performance?)
Thanks,
Chris.
________________________________________________________________________
This=20e-mail=20has=20been=20scanned=20for=20all=20viruses=20by=20Star.=20=
The
service=20is=20powered=20by=20MessageLabs.=20For=20more=20information=20on=
=20a=20proactive
anti-virus=20service=20working=20around=20the=20clock,=20around=20the=20gl=
obe,=20visit:
http://www.star.net.uk
________________________________________________________________________
^ permalink raw reply
* Re: Trying to understand alloc_skb()
From: Daniel Ann @ 2005-04-12 8:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <9b7ca6570504120138738b554f@mail.gmail.com>
In addition,
Im running 2.4.21 kernel.
Just then, I was looking at the 2.6.11 kernel source
(net/core/skbuff.c) and found out that large chunk of the alloc_skb()
has been thrown out.
Can this be removed from 2.4.21 also ? I might go and check out why
its been removed.
Still waiting for some good answer tho .. :)
Cheers,
On Apr 12, 2005 5:38 PM, Daniel Ann <ktdann@gmail.com> wrote:
> Hiya folks,
>
> I'm wondering if anyone could help me out with problem I have in alloc_skb().
>
> My problem is that, kernel dies with "alloc_skb called nonatomically
> from interrupt c00ba718" message. After browsing mailing list, I think
> its to do with not providing it with enough locks prior.
>
> Question is, what kind of lock should I be providing ?
>
> Since I have no clue as to which lock does what, I really need some
> good advise as to where to start looking.
>
> Could someone tell me the inside story on this ?
>
> --
> Daniel
>
--
Daniel
^ permalink raw reply
* Trying to understand alloc_skb()
From: Daniel Ann @ 2005-04-12 8:38 UTC (permalink / raw)
To: linuxppc-embedded
Hiya folks,
I'm wondering if anyone could help me out with problem I have in alloc_skb().
My problem is that, kernel dies with "alloc_skb called nonatomically
from interrupt c00ba718" message. After browsing mailing list, I think
its to do with not providing it with enough locks prior.
Question is, what kind of lock should I be providing ?
Since I have no clue as to which lock does what, I really need some
good advise as to where to start looking.
Could someone tell me the inside story on this ?
--
Daniel
^ permalink raw reply
* [PATCH] ppc32: Fix alignment exception checking on load/store multiple instructions
From: Kumar Gala @ 2005-04-12 6:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Paulus,
Can you take a look and ack this patch before I send to akpm.
The handling of misaligned load/store multiplies did not check to see if
the address were ok to access before __{get,put}_user().
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff -Nru a/arch/ppc/kernel/align.c b/arch/ppc/kernel/align.c
--- a/arch/ppc/kernel/align.c 2005-04-12 01:00:10 -05:00
+++ b/arch/ppc/kernel/align.c 2005-04-12 01:00:10 -05:00
@@ -290,6 +290,10 @@
/* lwm, stmw */
nb = (32 - reg) * 4;
}
+
+ if (!access_ok((flags & ST? VERIFY_WRITE: VERIFY_READ), addr, nb+nb0))
+ return -EFAULT; /* bad address */
+
rptr = (unsigned char *) ®s->gpr[reg];
if (flags & LD) {
for (i = 0; i < nb; ++i)
^ 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