* Re: Maple: killing a process that causes a machine check exception
From: Linas Vepstas @ 2006-05-23 16:48 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc64-dev
In-Reply-To: <20060523162348.GC5938@krispykreme>
On Wed, May 24, 2006 at 02:23:48AM +1000, Anton Blanchard wrote:
> jfaslist <jfaslist@yahoo.fr> wrote:
> > What do you mean by synchronous? Do you mean that the current process
> > may no be not the one that caused the ME?
>
> Yeah, a device doing DMA might cause a machine check independent to your
> current task. In that case we really need to take the machine down.
>
> > In my case I _need_ the process to be killed, as it is making a VME bus
> > error. / PCI target-abort.
>
> Sounds like you need a Maple specific machine check handler. My point is
> we cant merge a fix like that because it affects every powerpc arch out
> there, all with different machine check handling requirements.
Here's an utterly crazy idea that might take a lot of work to implement,
but might help with the problem. *If* it can be determined which pci device
caused the error, then it might be possible to reset the PCI device and
restart the device driver.
There is an existing infrastructure for "PCI Error Recovery" (known as
EEH on the pSeries) for detecting and clearing PCI bus errors. On the
pSeries, it depends on a combination of custom hardware PCI bridges and
firmware to isolate the failing device; but maybe on other systems, one
might be able to do "almost" as well.
(See kernel source, Documentation/pci-error-recovery.txt)
--linas
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-23 18:01 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060520135922.129a481d.akpm@osdl.org>
On Sat, 20 May 2006, Andrew Morton wrote:
> Mel Gorman <mel@csn.ul.ie> wrote:
>>
>>
>> Size zones and holes in an architecture independent manner for x86_64.
>>
>>
>
> I found a .config which triggers the cant-map-acpitables problem.
>
>
> With that .config, and without this patch:
>
> Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.6
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
> BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
> BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
> BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
> BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
> BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
> BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
> BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
> BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
> BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
> BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
> DMI 2.4 present.
> ACPI: PM-Timer IO Port: 0x408
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> Processor #0 6:15 APIC version 20
> ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> Processor #1 6:15 APIC version 20
> ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
> ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
> ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
> ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
> ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
>
>
> With that .config, and with this patch:
>
> Bootdata ok (command line is ro root=LABEL=/ earlyprintk=serial,ttyS0,9600,keep netconsole=4444@192.168.2.4/eth0,5147@192.168.2.33/00:0D:56:C6:C6:CC)
> Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #33 SMP Sat May 20 12:08:03 PDT 2006
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
> BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
> BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
> BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
> BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
> BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
> BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
> BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
> BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
> BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
> BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
> Too many memory regions, truncating
> Too many memory regions, truncating
> Too many memory regions, truncating
> DMI 2.4 present.
> ACPI: Unable to map RSDT header
> Intel MultiProcessor Specification v1.4
> Virtual Wire compatibility mode.
> OEM ID: Product ID: APIC at: 0xFEE00000
>
I think I have figured out what went wrong here.
arch/i386/kernel/acpi/boot.c has a __acpi_map_table() function which uses
a variable end_pfn_map variable defined in arch/x86_64/kernel/e820.c .
Part of the arch-independent-zone-sizing patch calculates end_pfn_map from
early_node_map[] which only contains information on real RAM regions.
On Christian's machine, there is no usable region after the ACPI table
data so early_node_map[] finishes just before the ACPI tables. This
results in the wrong value for end_pfn_map and the table fails to be
mapped. In Andrew's machines case, the regions got truncated and nothing
after ACPI NVS was recorded, including ACPI data which is why it fails to
boot.
Am not ready to release another set of patches, but I think this was the
cause of magic failures on x86_64.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [Cbe-oss-dev] Cell and new CPU feature bits
From: Benjamin Herrenschmidt @ 2006-05-23 21:52 UTC (permalink / raw)
To: Alex Rosenberg; +Cc: linuxppc-dev list, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <995508C0-6D30-479A-8ED5-C28CC0143DB7@playstation.sony.com>
> > Is this bug really going to be exposed in the wild or is it
> > an early silicon bug that will only bite early-testers?
>
> Is this or any other errata published somewhere? I didn't think they
> were.
I don't know, but I got approval to publically talk about that one (that
is to get a fix in the kernel, the vDSO, and see with Steve Munroe about
getting one in glibc hptiming as well)
> Our solution back at Apple was to put OF properties on the CPU node
> for each optional feature. e.g. for fres and frsqrte we put
> "graphics" since that's the official term for that group of optional
> instructions. We also put in "data-streams" instead of presuming that
> dss, etc. were always part of "altivec". These properties nicely fit
> into our Gestalt() API where "ppcf" had 32 bits to describe these to
> userland software.
Our firmwares do something similar, at least on pSeries (the cell blade
firmware may need a bit of kicking there). But that's only useful for
the kernel. I'm more interested about what is best to expose those to
userland and we have no such thing as good ol' Gestalt there :) We have
AT_HWCAP which we already use for a combination of things, and I was
wondering about the risk of running out of bits in there. Maybe we'll
have to extend the thing a bit.
I suppose the datastream instructions will mandate their own bits,
though nobody on the field seem to use them on linux at least on open
source code I've seen, and I'll probably add a separate bit for the new
altivec instructions. I was wondering if I should define a bit for those
"graphics" instruction and dcbf X form (at least the later could be just
derived from the uArchitecture bits in there)
Cheers,
Ben.
^ permalink raw reply
* CPU 1 refused to die!
From: Giuliano Pochini @ 2006-05-23 21:58 UTC (permalink / raw)
To: LinuxPPC-dev
I booted with maxcpus=1, then I enabled the 2nd cpu
with echo 1 > /sys/devices/system/cpu/cpu1/online
I can't disable it anymore. dmesg says "CPU 1 refused to die!".
/proc/cpuinfo and /proc/interrupts show one cpu only and the tasks run on
one cpu after the echo 0 > /sys/... , but since the command takes a couple
of seconds to complete I think it's not simply a bogus error message.
Dual G4 MDD
Linux Jay 2.6.16.16 #8 SMP Sat May 13 19:15:05 CEST 2006 ppc 7455,
altivec supported PowerMac3,6 GNU/Linux
--
Giuliano.
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Benjamin Herrenschmidt @ 2006-05-23 22:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <1148280172.6228.79.camel@johannes.berg>
> Right, that's how snd-powermac does it. It has the nasty side-effect of
> polluting the cache a lot though, since dbdma commands are 16 bytes
> long. Am I wrong?
You don't have that much DBDMA commands that it would pollute the cache
_a lot_ :)
> > Since we can only update the framecounter on a per-period basis,
>
> Alsa calls this thing the 'pointer' :) The frame counter we currently
> use is the frame counter register of the i2s bus controller, and I don't
> see why we shouldn't do that instead of reading back all the dbdma
> command status fields.
If you manage to have it properly in sync, that may work too.
> Since the i2s bus is not shut down it also counts when we are not
> transferring data. We currently calibrate on the first interrupt. That's
> fine, since having multiple periods means that we don't need to be
> absolutely precise here. If we miss one, that's fine, we can make it up
> the next time by saying that 2 have elapsed.
Ok.
Ben.
^ permalink raw reply
* Re: Setting I&D cache enable in the same mtspr instruction
From: Mark A. Greer @ 2006-05-23 22:34 UTC (permalink / raw)
To: Assaf Hoffman; +Cc: Ronen Shitrit, Rita Shtern, linuxppc-embedded
In-Reply-To: <B9FFC3F97441D04093A504CEA31B7C41A39491@msilexch01.marvell.com>
On Tue, May 23, 2006 at 12:55:46PM +0300, Assaf Hoffman wrote:
> Attached.
> Thanks.
Er, how about a *patch* place inline (as in, not as an attachment).
Thanks,
Mark
^ permalink raw reply
* Re: CPU 1 refused to die!
From: Nathan Lynch @ 2006-05-23 22:51 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: LinuxPPC-dev
In-Reply-To: <20060523235819.473e4149.pochini@shiny.it>
Giuliano Pochini wrote:
>
> I booted with maxcpus=1, then I enabled the 2nd cpu
> with echo 1 > /sys/devices/system/cpu/cpu1/online
So onlining at runtime seems to work. Did you verify that tasks get
run on the 2nd cpu after you online it? Any other strange messages in
dmesg?
> I can't disable it anymore. dmesg says "CPU 1 refused to die!".
But offlining doesn't.
Can you online and offline cpus if you boot without maxcpus=1?
^ permalink raw reply
* Re: pmppc7448/mv64x60 DMA from PCI to memory
From: Mark A. Greer @ 2006-05-23 23:54 UTC (permalink / raw)
To: Phil Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <1148395804.21475.53.camel@toby.int.avalon.com.au>
Hi Phil,
On Wed, May 24, 2006 at 12:20:04AM +0930, Phil Nitschke wrote:
> I've written a collection of simple routines to program the Marvell IDMA
> controller, for example:
> mv64x6x_init_dma_channel();
> mv64x6x_set_dma_mode();
> mv64x6x_set_src_addr();
> mv64x6x_set_dst_addr();
> mv64x6x_set_dma_count();
> mv64x6x_enable_dma();
> or rather more simply:
> mv64x6x_memcpy_dma(dst_handle, src_handle, size);
Listing routine names but no code doesn't really help.
> This works OK for copying from a memory to memory, where the buffers are
> allocated using:
> src = dma_alloc_noncoherent(NULL, BUF_SZ, &src_handle, GFP_KERNEL);
> The src_handle is passed directly to mv64x6x_set_src_addr();
>
> But when the src address is the FIFO on the PCI bus, I don't know how to
Do you really mean a FIFO? If so, that would explain a lot...
> get the IDMA controller to play nicely. The FIFO sits in the middle of
> the PCI device's I/O mem range 0x9fe00000 - 0x9fffffff. I've programmed
> and enabled a 5th address window in the IDMA controller which
> encompasses the 0x200000 bytes of the PCI memory range, and I'm not
> seeing any address violation or address miss errors. The PCI->memory
> DMA "completes" without any traffic every touching the PCI bus, so
> obviously I need to do something else/differently.
You say that you don't see any PCI traffic. Does that mean you
have a PCI analyzer and that you are sure that its set up correctly?
If so, then you have something botched in your IDMA->PCI window setup
or in the pgming of the DMA itself (e.g., in your descriptor(s)).
Also, set the SrcHold bit [3] of the channel control reg (low).
If its really a FIFO, you are--or will be once you get your windows
and descriptors set up correctly--reading the FIFO once then
incrementing past it.
> For this scenario, can anyone tell me:
> * Should I be using the same src address as that reported via
> the 'lspci' command - this _is_ the PCI bus address, isn't it?
"man lspci" (read up on the '-b' option)
> * Do I have to do anything special to tell the IDMA controller
> to source data from the PCI bus and shift it into memory?
You're talking to a *FIFO* which means you read all the data from one
address and write all the data to one, probably different, address.
Its not normal PCI memory, you don't increment through it. Its a
register of a FIFO that's in PCI memory space. That's why you need
to tell the IDMA ctlr to "hold" and read/write to the same address
each time.
> * Looking through mv64x60.c in the 2.6.16 kernel, I note that 4
> of the 8 possible IDMA address windows are configured (for each
> of the 512 MB DRAM on our processor card).
No they aren't. They're configured (or not) according to the setup info
that you pass in.
> Do I need to add
> tests to my source and destination regions, to determine if they
> cross one of the 512 MB regions, and hence will require a
> different CSx line (and thus the DMA will need to be broken into
> two transactions), or does kernel already take care to ensure
> allocated regions will not cross these boundaries?
No. You need to do what's appropriate for the hardware that you are
essentially writing a driver for. YOU are supposed to know what the
limitations of your hardware are. Even if you don't have a manual... ;)
Mark
^ permalink raw reply
* RE: question about linux with Xilinx ML-403
From: Rick Moleres @ 2006-05-23 21:21 UTC (permalink / raw)
To: Ming Liu, rick.moleres; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]
Ming,
-----Original Message-----
From: Ming Liu [mailto:eemingliu@hotmail.com]
Sent: Tuesday, May 23, 2006 3:42 AM
To: rick.moleres
Cc: linuxppc-embedded@ozlabs.org
Subject: question about linux with Xilinx ML-403
Hi Rick,
> Yes, we have a driver for the PLB TEMAC (different than the GSRD LL
> TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK
> 8.1.1, and MontaVista is on the verge of publishing a driver for PLB
> TEMAC for Linux 2.6. (I believe it came across this mailing list a few
> weeks ago)
I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore
Temac and PLB Temac included). I noticed that there is a directory
called
Xilinx_gige in the directory of /drivers/net. Is this the driver for
MontaVista Linux2.4.20?
Yes, this is the PLB TEMAC driver for Linux 2.4.20. In EDK 8.1.x, the
temac driver and Makefile are copied to drivers/net/xilinx_gige. This
xilinx_gige directory is not available in the MVL 3.1 Preview Kit, only
in the full Professional kit. We put the temac driver here mostly to
take advantage of the JUMBO_FRAME_SUPPORT in kernel configuration.
I copied the BSP and overwrote the original one in
the linux kernel directory (in the kernel directory, there is only a
directory called Xilinx_enet, no Xilinx_gige. So I just copied
Xilinx_gige.). However, my problem is in the menuconfig item of Network
Device Support->1000Mbit ethernet, there is not any option to choose and
enable the Xilinx on-chip ethernet. Is this a problem of MontaVista
Linux
3.1 Preview Kit, or my problem? And What shall I do to enable the
tri-mode
Temac in my platform? Thanks for your answer.
Our best recommendation is to use the drivers/net/xilinx_enet directory
for the temac driver and just enable the Xilinx 10/100 Ethernet in
menuconfig. If you want jumbo frame support, modify adapter.c in the
driver to define the CONFIG_XILINX_GIGE_JUMBO constant.
Note that Linux 2.6 support for the temac should be available from
MontaVista soon and a driver was pushed to this mailing list in March.
There will be support for MV Linux 2.6 in EDK 8.2.1 (around August).
Thanks,
Rick
[-- Attachment #2: Type: text/html, Size: 8154 bytes --]
^ permalink raw reply
* Re: pmppc7448/mv64x60 DMA from PCI to memory
From: Phil Nitschke @ 2006-05-24 2:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060523235449.GB1536@mag.az.mvista.com>
On Tue, 2006-05-23 at 16:54 -0700, Mark A. Greer wrote:
> You say that you don't see any PCI traffic. Does that mean you
> have a PCI analyzer and that you are sure that its set up correctly?
I don't have a PCI analyzer, however the JTAG used to program the PCI
device has been configured to display 4 K samples of PCI bus signals
(about 20 microsecs?) around the time of an interrupt which results in
the DMA being requested. Since my last post, I have managed to see some
traffic, but the PCI STOP# line is asserted, so I'm not seeing any data
being read. I'll investigate further...
> If so, then you have something botched in your IDMA->PCI window setup
Quite possibly. The patch below shows how I've set this window up. It
is not intended as a 'final' piece of code, so please forgive the magic
numbers. Could you review this for me?
> or in the pgming of the DMA itself (e.g., in your descriptor(s)).
Well the memory to memory DMA is working OK. I just didn't know what
the correct procedure was for determining the bus address of the FIFO.
For example, this mapping returns a dma handle which does not work:
fifo_dma_handle = pci_map_single(dev, my_card.bar1+fifo_address[0],
FIFO_SIZE, PCI_DMA_FROMDEVICE);
Whereas without DMA I would just use this:
ioread32_rep(my_card.bar1 + fifo_address[0], buf, 6);
Was I misguided in trying to use pci_map_single in this way?
> Also, set the SrcHold bit [3] of the channel control reg (low).
> If its really a FIFO, you are--or will be once you get your windows
> and descriptors set up correctly--reading the FIFO once then
> incrementing past it.
I can either address it as a FIFO, or as a memory range. I can read
from any address in the range and it returns the "next FIFO value".
Anyway, I've tried both src address hold settings...
> > For this scenario, can anyone tell me:
> > * Should I be using the same src address as that reported via
> > the 'lspci' command - this _is_ the PCI bus address, isn't it?
>
> "man lspci" (read up on the '-b' option)
I cannot see any difference with the '-b' flag. Maybe that is the way
of things on my architecture?
> > * Looking through mv64x60.c in the 2.6.16 kernel, I note that 4
> > of the 8 possible IDMA address windows are configured (for each
> > of the 512 MB DRAM on our processor card).
>
> No they aren't. They're configured (or not) according to the setup info
> that you pass in.
OK. I also note there are several cases where this is used in
mv64x60.c:
for (i=0; i<3; i++)
Why is 3 used in these loops, and not some other constant like
MV64360_xxxxx_WINDOWS (which are usually 4, not 3)?
> > Do I need to add
> > tests to my source and destination regions, to determine if they
> > cross one of the 512 MB regions, and hence will require a
> > different CSx line (and thus the DMA will need to be broken into
> > two transactions), or does kernel already take care to ensure
> > allocated regions will not cross these boundaries?
>
> No. You need to do what's appropriate for the hardware that you are
> essentially writing a driver for. YOU are supposed to know what the
> limitations of your hardware are.
OK, I know how my hardware is configured, but when trying to write a
generic driver, perhaps I need to have the mv64x60.c code remember the
CSx barriers, e.g. in the mv64x60_chip_info, so the IDMA engine can
access it. Do you think this would be possible/beneficial?
Thanks again,
--
Phil
Here is the patch to configure IDMA to PCI window(s):
--- linux-2.6.16/arch/ppc/syslib/mv64x60.c 2006-03-20
16:23:29.000000000 +1030
+++ linux-2.6.16-patched/arch/ppc/syslib/mv64x60.c 2006-05-23
16:33:52.000000000 +0930
@@ -535,6 +581,7 @@
mv64x60_config_pci_params(bh->hose_a, &si->pci_0);
mv64x60_config_cpu2pci_windows(bh, &si->pci_0, 0);
+ mv64x60_config_idma2pci_windows(bh, &si->pci_0, 0);
mv64x60_config_pci2mem_windows(bh, bh->hose_a,
&si->pci_0, 0,
mem_windows);
bh->ci->set_pci2regs_window(bh, bh->hose_a, 0,
@@ -548,6 +595,7 @@
mv64x60_config_pci_params(bh->hose_b, &si->pci_1);
mv64x60_config_cpu2pci_windows(bh, &si->pci_1, 1);
+ mv64x60_config_idma2pci_windows(bh, &si->pci_1, 1);
mv64x60_config_pci2mem_windows(bh, bh->hose_b,
&si->pci_1, 1,
mem_windows);
bh->ci->set_pci2regs_window(bh, bh->hose_b, 1,
@@ -1136,6 +1188,42 @@
bh->ci->disable_window_32bit(bh, win_tab[bus][i
+1]);
}
+static u32 idma_tab_xtra[MV64x60_CPU2MEM_WINDOWS] __initdata = {
+ MV64x60_IDMA2MEM_0_WIN, MV64x60_IDMA2MEM_1_WIN,
+ MV64x60_IDMA2MEM_2_WIN, MV64x60_IDMA2MEM_3_WIN,
+};
+
+void __init
+mv64x60_config_idma2pci_windows(struct mv64x60_handle *bh,
+ struct mv64x60_pci_info *pi, u32 bus)
+{
+ u32 attributes, unit_id;
+ int i;
+
+ /* Target Unit IDs: PCI0 = 3, PCI1 = 4. */
+ unit_id = bus ? 0x4 : 0x3;
+ /* 0x1d == No swap data, PCI-X NS attribute asserted, PCI memory
+ * space, PCIx_REQ64n asserted according to requested data size.
*/
+ attributes = (0x1d << 8) | unit_id;
+
+ for (i=0; i<3; i++)
+ if (pi->pci_mem[i].size > 0) {
+ mv64x60_set_32bit_window(bh, idma_tab_xtra[i],
+ pi->pci_mem[i].cpu_base,
pi->pci_mem[i].size,
+ attributes);
+ bh->ci->enable_window_32bit(bh,
idma_tab_xtra[i]);
+ /* Give idma r/w access to PCI memory region */
+ mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_0,
+ (0x3 << (i << 1)));
+ mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_1,
+ (0x3 << (i << 1)));
+ mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_2,
+ (0x3 << (i << 1)));
+ mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_3,
+ (0x3 << (i << 1)));
+ }
+}
+
/*
*****************************************************************************
*
@@ -2220,8 +2311,8 @@
};
static u32 idma_tab[MV64x60_CPU2MEM_WINDOWS] __initdata = {
- MV64x60_IDMA2MEM_0_WIN, MV64x60_IDMA2MEM_1_WIN,
- MV64x60_IDMA2MEM_2_WIN, MV64x60_IDMA2MEM_3_WIN,
+ MV64x60_IDMA2MEM_4_WIN, MV64x60_IDMA2MEM_5_WIN,
+ MV64x60_IDMA2MEM_6_WIN, MV64x60_IDMA2MEM_7_WIN,
};
static u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] __initdata =
@@ -2285,13 +2376,13 @@
/* Give idma r/w access to memory region */
mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_0,
- (0x3 << (i << 1)));
+ (0x3 << ((i+4) << 1)));
mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_1,
- (0x3 << (i << 1)));
+ (0x3 << ((i+4) << 1)));
mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_2,
- (0x3 << (i << 1)));
+ (0x3 << ((i+4) << 1)));
mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_3,
- (0x3 << (i << 1)));
+ (0x3 << ((i+4) << 1)));
}
}
^ permalink raw reply
* Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: sandeep malik @ 2006-05-24 6:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]
Hi All...
I am trying to run an application compiled with gcc toolchain gcc--3.4.3 and glibc -2.3.4 on PPC 8325 board running Linux 2.6.11....but some how I am getting following error....
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
I was suspecting this error might be because the hardware is not supporting floating point operations and hence i tried a simple program in which I intentionally did some floating point operation but that program was running as expected. So i concluded that it is not a problem related to floating point operations....I even tried compiling the application with classic ppc compiler(Ver 3.4.3) with -msoft-float option enabled, but still the results were same......
After these errors i am not able to get control of the system. If anyone who faced this or any such related issue please help me out like what could be probable reason for this error and what all options i have to debug this issue.....
Thanks & Regards,
Malik
---------------------------------
Yahoo! India Answers Share what your know-how and wisdom
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now
[-- Attachment #2: Type: text/html, Size: 5103 bytes --]
^ permalink raw reply
* RE: Help Needed: floating point used in kernel (task=c0398410, pc =3184)
From: Liu Dave-r63238 @ 2006-05-24 6:26 UTC (permalink / raw)
To: 'sandeep malik', linuxppc-embedded
Malik,
Because PPC8325 have NO float point unit, so please compile all of source code with gcc 8325 compiler
or use fixed simulate. The source code includs kernel, and filesystem.
Dave
-----Original Message-----
Hi All...
I am trying to run an application compiled with gcc toolchain gcc--3.4.3 and glibc -2.3.4 on PPC 8325 board running Linux 2.6.11....but some how I am getting following error....
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
floating point used in kernel (task=c0398410, pc=3184)
I was suspecting this error might be because the hardware is not supporting floating point operations and hence i tried a simple program in which I intentionally did some floating point operation but that program was running as expected. So i concluded that it is not a problem related to floating point operations....I even tried compiling the application with classic ppc compiler(Ver 3.4.3) with -msoft-float option enabled, but still the results were same......
After these errors i am not able to get control of the system. If anyone who faced this or any such related issue please help me out like what could be probable reason for this error and what all options i have to debug this issue.....
Thanks & Regards,
Malik
Yahoo! India Answers Share what your know-how and wisdom
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now
^ permalink raw reply
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: Roger Larsson @ 2006-05-24 6:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060524061205.53935.qmail@web8405.mail.in.yahoo.com>
On onsdag 24 maj 2006 08.12, sandeep malik wrote:
> Hi All...
>
> I am trying to run an application compiled with gcc toolchain gcc--3.4.3
> and glibc -2.3.4 on PPC 8325 board running Linux 2.6.11....but some how I
> am getting following error....
>
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
>
> I was suspecting this error might be because the hardware is not
> supporting floating point operations and hence i tried a simple program in
> which I intentionally did some floating point operation but that program
> was running as expected.
No, the warning is more serious than that.
Linux does not save floating point registers when entering kernel.
It might even optimize not to store/reload when doing a context switch.
If your kernel module is using floating point in your kernel code.
It will probably work on a processor not having floating point but will
break in mysterious ways on one supporting hardware floating point.
Do not use floating point in kernel. If you still have to you must take
extremely care.
Turn off kernel preemption.
Save FP registers.
Do your stuff.
Reload FP registers.
Turn on preemption.
But the question is why would you have to?
Simple calculations can be done in fixed point, and complex calculations
does not belong in the kernel.
/RogerL
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 1/10] Powerpc: Add general support for mpc7 448h pc2 (Taiga) platform
From: Zang Roy-r61911 @ 2006-05-24 7:23 UTC (permalink / raw)
To: Kumar Gala
Cc: Yang Xin-Xin-r48390, Paul Mackerras, Alexandre.Bounine,
linuxppc-dev list
> On May 18, 2006, at 3:05 AM, Zang Roy-r61911 wrote:
>
> >>
> >>> The tsi108 serial port is not a sub node of "soc". well,
> any way, I
> >>> can try soc!
> >>
> >> What is it ? Where is it ? "soc" is a bit of a generic name for
> >> something in the device-tree in fact... we might want to
> define a way
> >> to expose any bus via some kind of soc mecanism even if it's not a
> >> root bus.
> >>
> >>
> > Should I just use add_legacy_soc_port() instead of a new function
> > add_legacy_tsi_port()?
>
> I think seeing your dts will help here. We need to have a
> concept of a "bridge" that may be similar to an "soc".
mpc7448hpc2 dts :
/*
* MPC7448HPC2 (Taiga) board Device Tree Source
*
* Copyright 2006 Freescale Semiconductor Inc.
* 2006 Roy Zang <Roy Zang at freescale.com>.
*
* 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.
*/
/ {
model = "mpc7448hpc2";
compatible = "mpc74xx";
#address-cells = <1>;
#size-cells = <1>;
linux,phandle = <100>;
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells =<0>;
linux,phandle = <200>;
PowerPC,7448@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K bytes
i-cache-size = <8000>; // L1, 32K bytes
timebase-frequency = <0>; // 33 MHz, from uboot
clock-frequency = <0>; // From U-Boot
bus-frequency = <0>; // From U-Boot
32-bit;
linux,phandle = <201>;
linux,boot-cpu;
};
};
memory {
device_type = "memory";
linux,phandle = <300>;
reg = <00000000 20000000 // DDR2 512M at 0
>;
};
tsi108@c0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "tsi-bridge";
ranges = <00000000 c0000000 00010000>;
reg = <c0000000 00010000>;
bus-frequency = <0>;
i2c@7000 {
interrupt-parent = <7400>;
interrupts = <E 3>;
reg = <7000 400>;
device_type = "i2c";
compatible = "tsi-i2c";
};
mdio@6000 {
device_type = "mdio";
compatible = "tsi-ethernet"; // FIXME
ethernet-phy@6000 {
linux,phandle = <6000>;
interrupt-parent = <7400>;
interrupts = <2 1>;
reg = <6000 50>;
device_type = "ethernet-phy";
};
ethernet-phy@6400 {
linux,phandle = <6400>;
interrupt-parent = <7400>;
interrupts = <2 1>;
reg = <6400 50>;
device_type = "ethernet-phy";
};
};
ethernet@6200 {
#size-cells = <0>;
device_type = "network";
model = "TSI-ETH"; // FIXME
compatible = "tsi-ethernet"; // FIXME
reg = <6200 200>;
address = [ 00 06 D2 00 00 01 ];
interrupts = <10 3 10 3 10 3>;
interrupt-parent = <7400>;
phy-handle = <6000>;
};
ethernet@6600 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "TSI-ETH"; // FIXME
compatible = "tsi-ethernet"; // FIXME
reg = <6600 200>;
address = [ 00 06 D2 00 00 02 ];
interrupts = <11 3 11 3 11 3>;
interrupt-parent = <7400>;
phy-handle = <6400>;
};
serial@7808 {
device_type = "serial";
compatible = "ns16550";
reg = <7808 200>;
clock-frequency = <3f6b5a00>;
interrupts = <c 3>;
interrupt-parent = <7400>;
};
serial@7c08 {
device_type = "serial";
compatible = "ns16550";
reg = <7c08 200>;
clock-frequency = <3f6b5a00>;
interrupts = <d 3>;
interrupt-parent = <7400>;
};
pic@7400 {
linux,phandle = <7400>;
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <7400 400>;
built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
pci@1000 {
compatible = "tsi10x";
device_type = "pci";
linux,phandle = <1000>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <1000 1000>;
bus-range = <0 0>;
ranges = <02000000 0 e0000000 e0000000 0 1A000000
01000000 0 00000000 fa000000 0 00010000>;
clock-frequency = <7f28154>;
interrupt-parent = <7400>;
interrupts = <8 0>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 */
8800 0 0 1 7400 24 0
8800 0 0 2 7400 25 0
8800 0 0 3 7400 26 0
8800 0 0 4 7400 27 0
/* IDSEL 0x12 */
9000 0 0 1 7400 25 0
9000 0 0 2 7400 26 0
9000 0 0 3 7400 27 0
9000 0 0 4 7400 24 0
/* IDSEL 0x13 */
9800 0 0 1 7400 26 0
9800 0 0 2 7400 27 0
9800 0 0 3 7400 24 0
9800 0 0 4 7400 25 0
/* IDSEL 0x14 */
a000 0 0 1 7400 27 0
a000 0 0 2 7400 24 0
a000 0 0 3 7400 25 0
a000 0 0 4 7400 26 0
>;
};
};
};
^ permalink raw reply
* Re:Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: sandeep malik @ 2006-05-24 8:14 UTC (permalink / raw)
To: linuxppc-embedded, roger.larsson
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]
Hi Roger...
Thanks for your response.....but in my case the application is causing this error....this is not coming from any kernel module but a user space application which is creating problem.....and in that application also i have replaced all double occurances with long but still the same error was being flashed......what i suspect is this error is no where related to the usage of floating point as i compiled following code and run the same on the 8325 board and the code was running without any issue.....
#include "stdio.h"
int main()
{
int i=0;
float j= 1.2;
float result;
for(i=0; i<10; i++ )
{
result = result * 2;
}
printf("\n result %f",result);
return 0;
}
The result was exactly what is expected.....so i think this is not related to floating point but might be some other issue......
Are there any other scenarios which can lead to this message????
Regards,
Malik
=====================================================
> Hi All...
>
> I am trying to run an application compiled with gcc toolchain gcc--3.4.3
> and glibc -2.3.4 on PPC 8325 board running Linux 2.6.11....but some how I
> am getting following error....
>
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
> floating point used in kernel (task=c0398410, pc=3184)
>
> I was suspecting this error might be because the hardware is not
> supporting floating point operations and hence i tried a simple program in
> which I intentionally did some floating point operation but that program
> was running as expected.
No, the warning is more serious than that.
Linux does not save floating point registers when entering kernel.
It might even optimize not to store/reload when doing a context switch.
If your kernel module is using floating point in your kernel code.
It will probably work on a processor not having floating point but will
break in mysterious ways on one supporting hardware floating point.
Do not use floating point in kernel. If you still have to you must take
extremely care.
Turn off kernel preemption.
Save FP registers.
Do your stuff.
Reload FP registers.
Turn on preemption.
But the question is why would you have to?
Simple calculations can be done in fixed point, and complex calculations
does not belong in the kernel.
/RogerL
---------------------------------
Yahoo! India Answers Share what your know-how and wisdom
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now
[-- Attachment #2: Type: text/html, Size: 3599 bytes --]
^ permalink raw reply
* delay programming
From: tony @ 2006-05-24 9:23 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
hi all
I want to delay 1ms in the program,
does usleep(1000) works accurate?
any good idea?
regards
tony
^ permalink raw reply
* via-pmu runs device_power_down in atomic context
From: Johannes Berg @ 2006-05-24 8:01 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: cpufreq
[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]
Hey,
Everytime I suspend my powerbook, I see the following trace:
[10655.887546] BUG: sleeping function called from invalid context at include/linux/rwsem.h:43
[10655.887558] in_atomic():0, irqs_disabled():1
[10655.887562] Call Trace:
[10655.887565] [C581BD20] [C00081E8] show_stack+0x50/0x190 (unreliable)
[10655.887582] [C581BD50] [C0023BB0] __might_sleep+0xcc/0xe8
[10655.887592] [C581BD60] [C0038290] blocking_notifier_call_chain+0x2c/0xc0
[10655.887606] [C581BD80] [C01E90C0] cpufreq_suspend+0x130/0x148
[10655.887616] [C581BDB0] [C019D9E8] sysdev_suspend+0x10c/0x300
[10655.887627] [C581BDF0] [C01A3888] device_power_down+0x74/0xac
[10655.887636] [C581BE10] [C01B1264] pmac_suspend_devices+0x98/0x188
[10655.887643] [C581BE30] [C01B18F0] pmu_ioctl+0x59c/0xbc0
[10655.887649] [C581BED0] [C008E898] do_ioctl+0x80/0x84
[10655.887660] [C581BEE0] [C008E928] vfs_ioctl+0x8c/0x48c
[10655.887666] [C581BF10] [C008ED68] sys_ioctl+0x40/0x74
[10655.887673] [C581BF40] [C000F3A4] ret_from_syscall+0x0/0x38
The might_sleep() comes from down_read() and this happens because
blocking_notifier_call_chain calls it, it is also commented to run in
process context so this is all proper.
However, it obviously isn't run at process context. Looking why, I see
this in via-pmu.c:
/* We can now disable MSR_EE. This code of course works properly only
* on UP machines... For SMP, if we ever implement sleep, we'll have to
* stop the "other" CPUs way before we do all that stuff.
*/
local_irq_disable();
/* Broadcast power down irq
* This isn't that useful in most cases (only directly wired devices can
* use this but still... This will take care of sysdev's as well, so
* we exit from here with local irqs disabled and PIC off.
*/
ret = device_power_down(PMSG_SUSPEND);
Apparently this was a deliberate decision.
So the question is: which is correct? I can test and submit a patch to
fix the issue at either end; if cpufreq is wrong I'd move from a
blocking_ to an atomic_notifier_call_chain, if via-pmu.c is wrong I'd
call device_power_down earlier...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-24 9:41 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148395617.3434.0.camel@diesel>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Tue, 2006-05-23 at 09:46 -0500, Hollis Blanchard wrote:
> Yeah, I'm not sure how I was supposed to know that i2sbus was the magic
> module.
Heh, yeah, sorry. Thing is, if you'd have just installed the modules and
rebooted, it would have worked :)
> That seems to be working now. Again, from PowerMac11,2:
Yeah looks fine, except I just fixed a very stupid bug in the i2sbus
module. Please don't try to remove it after loading, until you upgrade
to the current version.
> This is probably just because I loaded all the modules I could find.
I tried changing the tas module to detect if the codec *really is
present*, but failed. There's some code in there, but I'll solicit some
help with that later.
> Volume control does indeed work when the tas module isn't loaded.
Interesting, but good to know. I'd have thought that the fabric would
not take the codec into use. Will see if I can fix that.
> Could you also add a sample modules.conf? For example, users should be
> told to remove snd-powermac.
Good point. Everything else should not be necessary though, since the
i2sbus module should automatically load due to having a macio modalias.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-24 9:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <1148422544.13249.96.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
On Wed, 2006-05-24 at 08:15 +1000, Benjamin Herrenschmidt wrote:
> > Right, that's how snd-powermac does it. It has the nasty side-effect of
> > polluting the cache a lot though, since dbdma commands are 16 bytes
> > long. Am I wrong?
>
> You don't have that much DBDMA commands that it would pollute the cache
> _a lot_ :)
Ah, yeah, I guess so. Well I do have 32 dbdma commands, them being
spaced up in 16-bytes means 16 cachelines, no? I'm not sure how the
cache is wired up ...
> > Alsa calls this thing the 'pointer' :) The frame counter we currently
> > use is the frame counter register of the i2s bus controller, and I don't
> > see why we shouldn't do that instead of reading back all the dbdma
> > command status fields.
>
> If you manage to have it properly in sync, that may work too.
Seems to work fine so far, even if bcm43xx kills a few interrupts ;)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* RE: question about linux with Xilinx ML-403
From: Ming Liu @ 2006-05-24 9:46 UTC (permalink / raw)
To: rick.moleres; +Cc: linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C0252AB7B@XCO-EXCHVS1.xlnx.xilinx.com>
Dear Rick,
First, thanks a lot for your information. However I still have something to
ask.
>Our best recommendation is to use the drivers/net/xilinx_enet directory
>for the temac driver and just enable the Xilinx 10/100 Ethernet in
>menuconfig.
I am not so clear with this. Do you mean that I just copy the source code
in the directory of xilinx_gige generated by EDK into the directory of
xilinx_enet in linux2.4.20, and then enable the Xilinx 10/100 ethernet in
the menuconfig? Can this method realize the 1000M ethernet? The source code
file names for Temac (xtemac_xxx.c or .h) are different with the ones for
emac (xemac_xxx.c or .h). Can the xtemac files be recognized by the linux
kernel?
BR
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: Roger Larsson @ 2006-05-24 9:48 UTC (permalink / raw)
To: sandeep malik, linuxppc-embedded
In-Reply-To: <20060524081447.12399.qmail@web8410.mail.in.yahoo.com>
On onsdag 24 maj 2006 10.14, you wrote:
> Hi Roger...
> Thanks for your response.....but in my case the application is causing
> this error....
It might be the application who runs, calls kernel for output, drivers used
for output uses floating point.
No application running => no floating point exceptions...
> The result was exactly what is expected.....so i think this is not
> related to floating point but might be some other issue......
Some driver, most likely your if you have made any yourself is
using floating point.
serial, console, ethernet drivers?
>
> Are there any other scenarios which can lead to this message????
Not unless the exception is setup wrong - I would not bet on that.
Lets trace it:
> > floating point used in kernel (task=c0398410, pc=3184)
This message is generated in ./arch/ppc/kernel/head.S
pc = 3184 (in hex)
Now check your System.map
The routine with the closest lower address is your main suspect,
the use of inlines can blur this...
(the task pointer is not that useful, they should have converted it
to process id)
/RogerL
^ permalink raw reply
* RE: delay programming
From: Li Yang-r58472 @ 2006-05-24 9:48 UTC (permalink / raw)
To: 'tony', linuxppc-embedded
That depends on how accurate you want. Sleep() functions can't be too accurate
for Linux schedule characteristic. To get best accuracy, you can use hardware
timer. udelay() is a choice which reduces the overall system performance.
Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org] On Behalf
> Of tony
> Sent: Wednesday, May 24, 2006 5:24 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: delay programming
>
>
> hi all
> I want to delay 1ms in the program,
> does usleep(1000) works accurate?
> any good idea?
>
> regards
> tony
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] make ams work with latest kernels
From: Johannes Berg @ 2006-05-24 10:09 UTC (permalink / raw)
To: Stelian Pop; +Cc: Andrew Morton, linuxppc-dev list, Linux Kernel list
In-Reply-To: <1148465069.6723.26.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]
On Wed, 2006-05-24 at 12:04 +0200, Stelian Pop wrote:
> Version 0.3 of ams (from http://popies.net/ams/) already had all those
> changes :)
Oh heh. :I downloaded the 2 version a while ago and forgot to check for
updates before fixing it up.
> The latest version (0.4) has some additionnal changes (fixes a double
> free induced by the use of input_free_device(), some other more cosmetic
> changes).
Nice :)
> Here it comes, along with proper kernel integration (Johannes, I've kept
> your Signed-off-by since the code is almost the same, feel free to
> disagree loudly if you must :) ).
:)
Patch looks good, thanks.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] make ams work with latest kernels
From: Stelian Pop @ 2006-05-24 10:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Morton, linuxppc-dev list, Linux Kernel list
In-Reply-To: <1148383943.25971.2.camel@johannes>
Le mardi 23 mai 2006 à 13:32 +0200, Johannes Berg a écrit :
> For those who don't know: ams, written by Stelian Pop, is a driver for
> the motion sensor present in some PowerBooks (the series the
> PowerBook5,6 falls into, later ones have a slightly different one the
> driver doesn't handle).
>
> Even though we still don't seem to have a client that can actually use
> this data (something to actually tell the hd to protect itself) I
> updated the ams code to compile against the latest linux kernel
> versions. I also fixed a buglet (the interrupt handler should return
> IRQ_HANDLED even if the init flag isn't set yet since we own the
> interrupts, they can't be shared).
Version 0.3 of ams (from http://popies.net/ams/) already had all those
changes :)
The latest version (0.4) has some additionnal changes (fixes a double
free induced by the use of input_free_device(), some other more cosmetic
changes).
> Stelian and all, how about adding this driver to linux? hdaps seems to
> be there even if it too doesn't serve a useful purpose at this time.
Ah, I wasn't aware that hdaps was already in. Oh, in this case let's
submit it.
Here it comes, along with proper kernel integration (Johannes, I've kept
your Signed-off-by since the code is almost the same, feel free to
disagree loudly if you must :) ).
---
From: Stelian Pop <stelian@popies.net>
This driver provides support for the Apple Motion Sensor (ams),
which provides an accelerometer and other misc. data.
Some Apple PowerBooks (the series the PowerBook5,6 falls into,
later ones have a slightly different one the driver doesn't handle)
are supported. The accelerometer data is readable via sysfs.
This driver also provides an absolute input class device, allowing
the laptop to act as a pinball machine-esque joystick.
In the future (once the proper API exist in the block layer) this
driver will tell the laptop disk to protect its heads in the event
of a catastrophic fall.
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/hwmon/ams.c | 519 +++++++++++++++++++++++++++++++++++++++++++++++++
drivers/hwmon/Kconfig | 17 +
drivers/hwmon/Makefile | 1
3 files changed, 537 insertions(+)
diff -r e292f327d882 drivers/hwmon/Kconfig
--- a/drivers/hwmon/Kconfig Wed May 24 11:35:02 2006 +0200
+++ b/drivers/hwmon/Kconfig Wed May 24 11:44:34 2006 +0200
@@ -450,6 +450,23 @@ config SENSORS_HDAPS
Say Y here if you have an applicable laptop and want to experience
the awesome power of hdaps.
+config SENSORS_AMS
+ tristate "Apple Motion Sensor (ams)"
+ depends on HWMON && INPUT && PPC32
+ default n
+ help
+ This driver provides support for the Apple Motion Sensor (ams),
+ which provides an accelerometer and other misc. data.
+ Some Apple PowerBooks (the series the PowerBook5,6 falls into,
+ later ones have a slightly different one the driver doesn't handle)
+ are supported. The accelerometer data is readable via sysfs.
+
+ This driver also provides an absolute input class device, allowing
+ the laptop to act as a pinball machine-esque joystick.
+
+ Say Y here if you have an applicable laptop and want to experience
+ the awesome power of ams.
+
config HWMON_DEBUG_CHIP
bool "Hardware Monitoring Chip debugging messages"
depends on HWMON
diff -r e292f327d882 drivers/hwmon/Makefile
--- a/drivers/hwmon/Makefile Wed May 24 11:35:02 2006 +0200
+++ b/drivers/hwmon/Makefile Wed May 24 11:44:34 2006 +0200
@@ -16,6 +16,7 @@ obj-$(CONFIG_SENSORS_ADM1026) += adm1026
obj-$(CONFIG_SENSORS_ADM1026) += adm1026.o
obj-$(CONFIG_SENSORS_ADM1031) += adm1031.o
obj-$(CONFIG_SENSORS_ADM9240) += adm9240.o
+obj-$(CONFIG_SENSORS_AMS) += ams.o
obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o
obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
obj-$(CONFIG_SENSORS_F71805F) += f71805f.o
diff -r e292f327d882 drivers/hwmon/ams.c
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/drivers/hwmon/ams.c Wed May 24 11:44:34 2006 +0200
@@ -0,0 +1,519 @@
+/*
+ * Apple Motion Sensor driver
+ *
+ * Copyright (C) 2005 Stelian Pop (stelian@popies.net)
+ *
+ * Clean room implementation based on the reverse engineered OSX driver by
+ * Johannes Berg <johannes@sipsolutions.net>, documentation available at
+ * http://johannes.sipsolutions.net/PowerBook/Apple_Motion_Sensor_Specification
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ */
+
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/input.h>
+#include <linux/kthread.h>
+
+#include <asm/of_device.h>
+#include <asm/pmac_feature.h>
+
+MODULE_DESCRIPTION("Apple Motion Sensor driver");
+MODULE_AUTHOR("Stelian Pop");
+MODULE_LICENSE("GPL");
+
+static unsigned int mouse;
+module_param(mouse, bool, 0);
+MODULE_PARM_DESC(mouse, "enable the input class device on module load");
+
+/* AMS registers */
+#define AMS_COMMAND 0x00 /* command register */
+#define AMS_STATUS 0x01 /* status register */
+#define AMS_CTRL1 0x02 /* read control 1 (number of values) */
+#define AMS_CTRL2 0x03 /* read control 2 (offset?) */
+#define AMS_CTRL3 0x04 /* read control 3 (size of each value?) */
+#define AMS_DATA1 0x05 /* read data 1 */
+#define AMS_DATA2 0x06 /* read data 2 */
+#define AMS_DATA3 0x07 /* read data 3 */
+#define AMS_DATA4 0x08 /* read data 4 */
+#define AMS_DATAX 0x20 /* data X */
+#define AMS_DATAY 0x21 /* data Y */
+#define AMS_DATAZ 0x22 /* data Z */
+#define AMS_FREEFALL 0x24 /* freefall int control */
+#define AMS_SHOCK 0x25 /* shock int control */
+#define AMS_SENSLOW 0x26 /* sensitivity low limit */
+#define AMS_SENSHIGH 0x27 /* sensitivity high limit */
+#define AMS_CTRLX 0x28 /* control X */
+#define AMS_CTRLY 0x29 /* control Y */
+#define AMS_CTRLZ 0x2A /* control Z */
+#define AMS_UNKNOWN1 0x2B /* unknown 1 */
+#define AMS_UNKNOWN2 0x2C /* unknown 2 */
+#define AMS_UNKNOWN3 0x2D /* unknown 3 */
+#define AMS_VENDOR 0x2E /* vendor */
+
+/* AMS commands - use with the AMS_COMMAND register */
+enum ams_cmd {
+ AMS_CMD_NOOP = 0,
+ AMS_CMD_VERSION,
+ AMS_CMD_READMEM,
+ AMS_CMD_WRITEMEM,
+ AMS_CMD_ERASEMEM,
+ AMS_CMD_READEE,
+ AMS_CMD_WRITEEE,
+ AMS_CMD_RESET,
+ AMS_CMD_START,
+};
+
+struct ams {
+ char init; /* has it been initialized ? */
+ int bus; /* i2c bus */
+ int address; /* i2c address */
+ struct i2c_client client; /* i2c client */
+ struct of_device *of_dev; /* sysfs device */
+ char vflag; /* use orient1 or orient2 ? */
+ u32 orient1; /* orientation words */
+ u32 orient2;
+ int irq1; /* first irq line */
+ int irq2; /* second irq line */
+ struct work_struct worker; /* worker thread */
+ struct input_dev *idev; /* input device */
+ int xcalib; /* calibrated null value for x */
+ int ycalib; /* calibrated null value for y */
+ struct task_struct *kthread; /* kthread for input */
+};
+
+static struct ams ams;
+
+static int ams_attach(struct i2c_adapter *adapter);
+static int ams_detach(struct i2c_adapter *adapter);
+
+static struct i2c_driver ams_driver = {
+ .driver = {
+ .name = "ams",
+ .owner = THIS_MODULE,
+ },
+ .attach_adapter = ams_attach,
+ .detach_adapter = ams_detach,
+};
+
+static inline s32 ams_read(u8 reg)
+{
+ return i2c_smbus_read_byte_data(&ams.client, reg);
+}
+
+static inline int ams_write(u8 reg, u8 value)
+{
+ return i2c_smbus_write_byte_data(&ams.client, reg, value);
+}
+
+static int ams_cmd(enum ams_cmd cmd)
+{
+ s32 result;
+ int i;
+
+ ams_write(AMS_COMMAND, cmd);
+ for (i = 0; i < 10; i++) {
+ mdelay(5);
+ result = ams_read(AMS_COMMAND);
+ if (result == 0 || result & 0x80)
+ return 0;
+ }
+ return -1;
+}
+
+static void ams_sensors(s8 *x, s8 *y, s8 *z)
+{
+ u32 orient;
+
+ *x = ams_read(AMS_DATAX);
+ *y = ams_read(AMS_DATAY);
+ *z = ams_read(AMS_DATAZ);
+
+ orient = ams.vflag ? ams.orient2 : ams.orient1;
+ if (orient & 0x80) {
+ s8 tmp = *x;
+ *x = *y;
+ *y = tmp;
+ }
+ if (orient & 0x04)
+ *z = ~*z;
+ if (orient & 0x02)
+ *y = ~*y;
+ if (orient & 0x01)
+ *x = ~*x;
+
+ /* printk(KERN_DEBUG "ams: Sensors (%d, %d, %d)\n", *x, *y, *z); */
+}
+
+static ssize_t ams_show_x(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ int retval;
+ s8 x, y, z;
+
+ ams_sensors(&x, &y, &z);
+ retval = snprintf(buf, PAGE_SIZE, "%d\n", x);
+ return retval;
+}
+static DEVICE_ATTR(x, S_IRUGO, ams_show_x, NULL);
+
+static ssize_t ams_show_y(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ int retval;
+ s8 x, y, z;
+
+ ams_sensors(&x, &y, &z);
+ retval = snprintf(buf, PAGE_SIZE, "%d\n", y);
+ return retval;
+}
+static DEVICE_ATTR(y, S_IRUGO, ams_show_y, NULL);
+
+static ssize_t ams_show_z(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ int retval;
+ s8 x, y, z;
+
+ ams_sensors(&x, &y, &z);
+ retval = snprintf(buf, PAGE_SIZE, "%d\n", z);
+ return retval;
+}
+
+static DEVICE_ATTR(z, S_IRUGO, ams_show_z, NULL);
+
+static int ams_mouse_kthread(void *data)
+{
+ s8 x, y, z;
+
+ while (!kthread_should_stop()) {
+ ams_sensors(&x, &y, &z);
+
+ input_report_abs(ams.idev, ABS_X, x - ams.xcalib);
+ input_report_abs(ams.idev, ABS_Y, y - ams.ycalib);
+
+ input_sync(ams.idev);
+
+ msleep(25);
+ }
+ return 0;
+}
+
+static void ams_mouse_enable(void)
+{
+ s8 x, y, z;
+
+ if (ams.idev)
+ return;
+
+ ams_sensors(&x, &y, &z);
+ ams.xcalib = x;
+ ams.ycalib = y;
+
+ ams.idev = input_allocate_device();
+ if (!ams.idev)
+ return;
+
+ ams.idev->name = "Apple Motion Sensor";
+ ams.idev->id.bustype = BUS_I2C;
+ ams.idev->id.vendor = 0;
+
+ input_set_abs_params(ams.idev, ABS_X, -50, 50, 3, 0);
+ input_set_abs_params(ams.idev, ABS_Y, -50, 50, 3, 0);
+
+ set_bit(EV_ABS, ams.idev->evbit);
+ set_bit(EV_KEY, ams.idev->evbit);
+ set_bit(BTN_TOUCH, ams.idev->keybit);
+
+ if (input_register_device(ams.idev)) {
+ input_free_device(ams.idev);
+ ams.idev = NULL;
+ return;
+ }
+
+ ams.kthread = kthread_run(ams_mouse_kthread, NULL, "kams");
+ if (IS_ERR(ams.kthread)) {
+ input_unregister_device(ams.idev);
+ ams.idev = NULL;
+ return;
+ }
+}
+
+static void ams_mouse_disable(void)
+{
+ if (!ams.idev)
+ return;
+
+ kthread_stop(ams.kthread);
+
+ input_unregister_device(ams.idev);
+
+ ams.idev = NULL;
+}
+
+static ssize_t ams_show_mouse(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%d\n", mouse);
+}
+
+static ssize_t ams_store_mouse(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ if (sscanf(buf, "%d\n", &mouse) != 1)
+ return -EINVAL;
+
+ mouse = !!mouse;
+
+ if (mouse)
+ ams_mouse_enable();
+ else
+ ams_mouse_disable();
+
+ return count;
+}
+static DEVICE_ATTR(mouse, S_IRUGO | S_IWUSR, ams_show_mouse, ams_store_mouse);
+
+static void ams_worker(void *data)
+{
+ /* TODO: park hard disk drives like OSX ? */
+ if (ams_read(AMS_FREEFALL) & 0x80)
+ printk(KERN_INFO "ams: freefall interrupt\n");
+ if (ams_read(AMS_SHOCK) & 0x80)
+ printk(KERN_INFO "ams: shock interrupt\n");
+
+ ams_write(AMS_FREEFALL, 0);
+ ams_write(AMS_SHOCK, 0);
+}
+
+static irqreturn_t ams_interrupt(int irq, void *devid, struct pt_regs *regs)
+{
+ if (ams.init)
+ schedule_work(&ams.worker);
+ return IRQ_HANDLED;
+}
+
+static int ams_attach(struct i2c_adapter *adapter)
+{
+ int vmaj, vmin;
+ unsigned long bus;
+
+ if (ams.init)
+ return 0;
+
+ if (strncmp(adapter->name, "uni-n", 5))
+ return -ENODEV;
+ bus = simple_strtoul(adapter->name + 6, NULL, 10);
+ if (bus != ams.bus)
+ return -ENODEV;
+
+ ams.client.addr = ams.address;
+ ams.client.adapter = adapter;
+ ams.client.driver = &ams_driver;
+ strcpy(ams.client.name, "Apple Motion Sensor");
+
+ if (ams_cmd(AMS_CMD_RESET)) {
+ printk(KERN_INFO "ams: Failed to reset the device\n");
+ return -ENODEV;
+ }
+
+ if (ams_cmd(AMS_CMD_START)) {
+ printk(KERN_INFO "ams: Failed to start the device\n");
+ return -ENODEV;
+ }
+
+ /* get version/vendor information */
+ ams_write(AMS_CTRL1, 0x02);
+ ams_write(AMS_CTRL2, 0x85);
+ ams_write(AMS_CTRL3, 0x01);
+
+ ams_cmd(AMS_CMD_READMEM);
+
+ vmaj = ams_read(AMS_DATA1);
+ vmin = ams_read(AMS_DATA2);
+ if (vmaj != 1 || vmin != 52) {
+ printk(KERN_INFO "ams: Incorrect device version (%d.%d)\n",
+ vmaj, vmin);
+ return -ENODEV;
+ }
+
+ ams_cmd(AMS_CMD_VERSION);
+
+ vmaj = ams_read(AMS_DATA1);
+ vmin = ams_read(AMS_DATA2);
+ if (vmaj != 0 || vmin != 1) {
+ printk(KERN_INFO "ams: Incorrect firmware version (%d.%d)\n",
+ vmaj, vmin);
+ return -ENODEV;
+ }
+
+ if (ams_read(AMS_VENDOR) & 0x10)
+ ams.vflag = 1;
+
+ /* write initial values */
+ ams_write(AMS_SENSLOW, 0x15);
+ ams_write(AMS_SENSHIGH, 0x60);
+ ams_write(AMS_CTRLX, 0x08);
+ ams_write(AMS_CTRLY, 0x0F);
+ ams_write(AMS_CTRLZ, 0x4F);
+ ams_write(AMS_UNKNOWN1, 0x14);
+
+ ams_write(AMS_FREEFALL, 0);
+ ams_write(AMS_SHOCK, 0);
+
+ /* enable interrupts */
+ ams_write(AMS_CTRLX, 0x88);
+ ams_write(AMS_CTRLY, 0x8F);
+ ams_write(AMS_CTRLZ, 0xCF);
+
+ if (i2c_attach_client(&ams.client)) {
+ printk(KERN_INFO "ams: Failed to attach the client\n");
+ return -ENODEV;
+ }
+
+ if (mouse)
+ ams_mouse_enable();
+
+ ams.init = 1;
+
+ printk(KERN_INFO "ams: Apple Motion Sensor enabled\n");
+
+ return 0;
+}
+
+static int ams_detach(struct i2c_adapter *adapter)
+{
+ if (!ams.init)
+ return 0;
+
+ if (ams.idev)
+ ams_mouse_disable();
+
+ i2c_detach_client(&ams.client);
+
+ /* disable and ack interrupts */
+ ams_write(AMS_CTRLX, 0x08);
+ ams_write(AMS_CTRLY, 0x0F);
+ ams_write(AMS_CTRLZ, 0x4F);
+ ams_write(AMS_FREEFALL, 0);
+ ams_write(AMS_SHOCK, 0);
+
+ ams.init = 0;
+
+ printk(KERN_INFO "ams: Apple Motion Sensor disabled\n");
+
+ return 0;
+}
+
+static int __init ams_init(void)
+{
+ struct device_node* np;
+ u32 *prop;
+
+ np = of_find_node_by_name(NULL, "accelerometer");
+ if (!np)
+ return -ENODEV;
+ if (!device_is_compatible(np, "AAPL,accelerometer_1"))
+ return -ENODEV;
+
+ prop = (u32 *)get_property(np, "orientation", NULL);
+ if (!prop)
+ return -EIO;
+ ams.orient1 = *prop;
+ ams.orient2 = *(prop + 1);
+
+ prop = (u32 *)get_property(np, "reg", NULL);
+ if (!prop)
+ return -ENODEV;
+
+ /* look for bus either by path or using "reg" */
+ if (strstr(np->full_name, "/i2c-bus@") != NULL) {
+ const char *tmp_bus = (strstr(np->full_name, "/i2c-bus@") + 9);
+ ams.bus = tmp_bus[0]-'0';
+ } else {
+ ams.bus = ((*prop) >> 8) & 0x0f;
+ }
+ ams.address = ((*prop) & 0xff) >> 1;
+
+ np = of_find_node_by_name(NULL, "accelerometer-1");
+ if (!np || np->n_intrs < 1)
+ return -ENODEV;
+
+ ams.irq1 = np->intrs[0].line;
+
+ np = of_find_node_by_name(NULL, "accelerometer-2");
+ if (!np || np->n_intrs < 1)
+ return -ENODEV;
+
+ ams.irq2 = np->intrs[0].line;
+
+ if (request_irq(ams.irq1, ams_interrupt, 0, "accelerometer-1",
+ NULL < 0))
+ return -ENODEV;
+
+ if (request_irq(ams.irq2, ams_interrupt, 0, "accelerometer-2",
+ NULL < 0)) {
+ free_irq(ams.irq1, NULL);
+ return -ENODEV;
+ }
+
+ INIT_WORK(&ams.worker, ams_worker, NULL);
+
+ if ((ams.of_dev = of_platform_device_create(np, "ams", NULL)) == NULL) {
+ free_irq(ams.irq1, NULL);
+ free_irq(ams.irq2, NULL);
+ return -ENODEV;
+ }
+
+ device_create_file(&ams.of_dev->dev, &dev_attr_x);
+ device_create_file(&ams.of_dev->dev, &dev_attr_y);
+ device_create_file(&ams.of_dev->dev, &dev_attr_z);
+ device_create_file(&ams.of_dev->dev, &dev_attr_mouse);
+
+ if (i2c_add_driver(&ams_driver) < 0) {
+ free_irq(ams.irq1, NULL);
+ free_irq(ams.irq2, NULL);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void __exit ams_exit(void)
+{
+ i2c_del_driver(&ams_driver);
+
+ free_irq(ams.irq1, NULL);
+ free_irq(ams.irq2, NULL);
+
+ device_remove_file(&ams.of_dev->dev, &dev_attr_x);
+ device_remove_file(&ams.of_dev->dev, &dev_attr_y);
+ device_remove_file(&ams.of_dev->dev, &dev_attr_z);
+ device_remove_file(&ams.of_dev->dev, &dev_attr_mouse);
+
+ of_device_unregister(ams.of_dev);
+}
+
+module_init(ams_init);
+module_exit(ams_exit);
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: sandeep malik @ 2006-05-24 12:30 UTC (permalink / raw)
To: Roger Larsson, linuxppc-embedded
In-Reply-To: <200605241148.38708.roger.larsson@norran.net>
[-- Attachment #1: Type: text/plain, Size: 2666 bytes --]
>It might be the application who runs, calls kernel for output, drivers used
>for output uses floating point.
>No application running => no floating point exceptions...
Yes even I do agree with this point.....and need ur help how to check this coz
the main reason is that the error is not consistently coming from one particular point but the location keeps on changing......
if we try to debug and remove from one point it start coming from some other point in the application......
>Some driver, most likely your if you have made any yourself is
>using floating point.
>serial, console, ethernet drivers?
No I am not running any such drivers which are new and can be suspected
all the drivers used are fully tested and working well with all other applications...
>pc = 3184 (in hex)
>Now check your System.map
>The routine with the closest lower address is your main suspect,
>the use of inlines can blur this...
>(the task pointer is not that useful, they should have converted it
>to process id)
Even this pc value is very less. I think it should be in the range of c0000000 - c0233e38(range I got from system.map file)....
if we think pc is returning the four LSB's even then it is not giving any such clue
as there are only ISR's defined in arc/ppc/kernel/head.S which are lying close to this address
Regards,
Malik
Roger Larsson <roger.larsson@norran.net> wrote:
On onsdag 24 maj 2006 10.14, you wrote:
> Hi Roger...
> Thanks for your response.....but in my case the application is causing
> this error....
It might be the application who runs, calls kernel for output, drivers used
for output uses floating point.
No application running => no floating point exceptions...
> The result was exactly what is expected.....so i think this is not
> related to floating point but might be some other issue......
Some driver, most likely your if you have made any yourself is
using floating point.
serial, console, ethernet drivers?
>
> Are there any other scenarios which can lead to this message????
Not unless the exception is setup wrong - I would not bet on that.
Lets trace it:
> > floating point used in kernel (task=c0398410, pc=3184)
This message is generated in ./arch/ppc/kernel/head.S
pc = 3184 (in hex)
Now check your System.map
The routine with the closest lower address is your main suspect,
the use of inlines can blur this...
(the task pointer is not that useful, they should have converted it
to process id)
/RogerL
---------------------------------
Yahoo! India Answers Share what your know-how and wisdom
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now
[-- Attachment #2: Type: text/html, Size: 3378 bytes --]
^ 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