* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:33 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071105121530.5c38fbb7.kim.phillips@freescale.com>
On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> Hello all,
>
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below). Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
>
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me). I'm hoping they're
> trivial enough to go in 2.6.24.
All five patches are
Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Let's hope they'll hit 2.6.24.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] ehea: Add kdump support
From: Thomas Klein @ 2007-11-09 13:33 UTC (permalink / raw)
To: Jeff Garzik
Cc: Michael Neuling, Jan-Bernd Themann, netdev, linux-kernel,
linux-ppc, Christoph Raisch, Paul Mackerras, Marcus Eder,
Stefan Roscher
To support ehea driver reloading in a kdump kernel the driver has to perform
firmware handle deregistrations when the original kernel crashes. As there's
currently no notifier chain for machine crashes this patch enables kdump support
in the ehea driver by bending the ppc_md.machine_crash_shutdown hook to its own
machine crash handler. The original machine_crash_shutdown() fn is called
afterwards. This works fine as long as the ehea driver is the only one which
does so. Problems may occur if other drivers do the same and unload regularly.
This patch enables 2.6.24-rc2 to use kdump with ehea and only puts a very
low risk on base kernel. In 2.6.24 we know ehea is the only user of this
mechanism. The next step for 2.6.25 would be to add a proper notifier chain.
The full solution might be that register_reboot_notifier() provides sth
like a SYS_CRASH action. Please apply.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index f78e5bf..5935899 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0080"
+#define DRV_VERSION "EHEA_0081"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index f0319f1..40a732e 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -37,6 +37,7 @@
#include <linux/reboot.h>
#include <net/ip.h>
+#include <asm-powerpc/machdep.h>
#include "ehea.h"
#include "ehea_qmr.h"
@@ -98,6 +99,7 @@ static int port_name_cnt = 0;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags = 0;
struct work_struct ehea_rereg_mr_task;
+static void (*orig_machine_crash_shutdown)(struct pt_regs *regs);
struct semaphore dlpar_mem_lock;
@@ -3312,6 +3314,29 @@ static struct notifier_block ehea_reboot_nb = {
.notifier_call = ehea_reboot_notifier,
};
+void ehea_crash_notifier(struct pt_regs *regs)
+{
+ ehea_info("Machine crash: freeing all eHEA resources");
+ ibmebus_unregister_driver(&ehea_driver);
+ orig_machine_crash_shutdown(regs);
+}
+
+void ehea_register_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ orig_machine_crash_shutdown =
+ (void*)__xchg_u64((unsigned long*)&ppc_md.machine_crash_shutdown,
+ (unsigned long)ehea_crash_notifier);
+#endif
+}
+
+void ehea_unregister_crash_notifier(void)
+{
+#ifdef CONFIG_KEXEC
+ ppc_md.machine_crash_shutdown = orig_machine_crash_shutdown;
+#endif
+}
+
static int check_module_parm(void)
{
int ret = 0;
@@ -3369,6 +3394,7 @@ int __init ehea_module_init(void)
goto out;
register_reboot_notifier(&ehea_reboot_nb);
+ ehea_register_crash_notifier();
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
@@ -3382,6 +3408,7 @@ int __init ehea_module_init(void)
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ibmebus_unregister_driver(&ehea_driver);
goto out;
}
@@ -3396,6 +3423,7 @@ static void __exit ehea_module_exit(void)
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ehea_unregister_crash_notifier();
ehea_destroy_busmap();
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Anton Vorontsov @ 2007-11-09 13:25 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, linuxppc-dev, paulus, Li Yang, jgarzik
In-Reply-To: <20071108131135.e16a2f9a.kim.phillips@freescale.com>
On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote:
[...]
> right, but whether it does or not doesn't affect your failure outcome
> either I'm assuming.
>
> > > If it's something like 0x03, the u-boot patch will probably look like:
> > >
> > > if ((bcsr[12] == 0x10) &&
> > > (immr->sysconf.spridr == SPR_8360_REV21 ||
> > > immr->sysconf.spridr == SPR_8360E_REV21))
> > > /* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > > ...
> > >
> > > but these linux patches would remain the same (the clk and data delay
> > > settings for the UCC's are still valid; it's just the PHY config
> > > that is triggering your problem from what I can tell).
> >
> > Yup, most likely this is not UCC specific, but PHY. For some reason
> > delays making harm here...
And today I was unable to reproduce yesterday's behaviour. Your
patches works fine, with sixth patch and without it. With -rxid
and with just -id.
Though, after few resets I hit on that:
- - - -
U-Boot 1.3.0-rc3-g281df457-dirty (Nov 6 2007 - 18:19:35) MPC83XX
Reset Status: External/Internal Soft, External/Internal Hard
CPU: e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB: 264 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM: 256 MB (DDR2, 64-bit, ECC on)
SDRAM: 64 MB (local bus)
FLASH: 32 MB
In: serial
Out: serial
Err: serial
Net: UEC: PHY is Marvell 88E11x1 (1410cc2)
FSL UEC0: Full Duplex
switching to rgmii 100
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
read wrong value : mii_id 1,mii_reg 2, base e0103120
read wrong value : mii_id 1,mii_reg 3, base e0103120
UEC: PHY is Generic MII (ffffffff)
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 5, base e0103120
FSL UEC1: Full Duplex
switching to rgmii 100
FSL UEC1: Speed 100BT
FSL UEC1: Link is up
FSL UEC0, FSL UEC1
- - - -
And UCC1 does not work at all. After another reset that message
disappears and it does work again.
So, I think hardware is tricking me in various ways, not your
patches fault.
:-(
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* auto soft reset after kernel crash?
From: robert lazarski @ 2007-11-09 13:25 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm trying to read the __log_buf after a kernel crash on a custom
board via a software reset. While I'm waiting for the hardware guys to
give me a sw reset button, I've noticed that the particular 2.6.22
kernel I'm using software resets itself around 7 minutes after a
crash. I tried a 2.6.23 kernel to see if my problem was related to
kernel version and it doesn't reset itself. Is this reset indeed a
kernel feature? How do I enable / disable it and set the amount of
time it waits before it resets? I went thru the menuconfig features
and couldn't enable a sw reset. Any ideas?
Thanks,
Robert
^ permalink raw reply
* Appletouch going wild
From: Andreas Schwab @ 2007-11-09 12:58 UTC (permalink / raw)
To: linux-input; +Cc: linuxppc-dev
Every once in a while the touchpad in my iBook G4 (geyser1, 030B) is
going wild, emitting random movement events even when not being touched.
That started only with 2.6.24-rc1. The only way to stop it is to reload
the appletouch module. My guess would be that reinitializing the
touchpad can result in some kind of race condition.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* RE: Bootloader & Flash
From: MingLiu @ 2007-11-09 12:51 UTC (permalink / raw)
To: schardt; +Cc: linuxppc-embedded
In-Reply-To: <47344D70.4050308@fz-juelich.de>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
Hi,
> - I have download the zImage.elf via the EDK flash loader> - The flash loader creates a bootloader, this is also running on start up :)
What you need to store in flash memory, is not the .elf file. Before you use EDK flash loader to burn your linux kernel in flash, .elf file should be transfered into .srec file, just like the below reminds you: SREC line is corrupted.
> But ... It stops with an error-message after a few seconds:> > EDK Bootloader:> Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is corrupted> > What now ?
Hopefully it helps.
BR
Ming
_________________________________________________________________
Windows Live Spaces 中最年轻的成员！
http://miaomiaogarden2007.spaces.live.com/
[-- Attachment #2: Type: text/html, Size: 1005 bytes --]
^ permalink raw reply
* Re: [PATCH] balance ioremap/iounmap in {sycamore, walnut}_setup_arch()
From: Roel Kluin @ 2007-11-09 12:32 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <47333EDA.4080907@ru.mvista.com>
Valentine Barshak wrote:
> Roel Kluin wrote:
>> I guess it should be done after the last usage of kb_data or fpga_status?
>
> I think no iounmap(kb_data) needed. Looks like the pointer kn_cs (kb_cs
> = kb_data + 1) is used by the serio driver
> (drivers/input/serio/i8042-ppcio.h).
> Please note that we just ioremap and assign pointers here, not actually
> reading the registers.
> Also, looks like you unmap the fpga registers too early.
> Thanks,
> Valentine.
Thanks for your pointers. I'm new, so I'm not sure how this should be done. I
have removed the iounmap(kb_data), and moved the iounmap(fpga_status) lower.
possibly the latter could be done before the sycamore_rtc_base assignment?
--
Balance ioremap/iounmap
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/ppc/platforms/4xx/sycamore.c b/arch/ppc/platforms/4xx/sycamore.c
index 8689f3e..6ce4815 100644
--- a/arch/ppc/platforms/4xx/sycamore.c
+++ b/arch/ppc/platforms/4xx/sycamore.c
@@ -132,6 +132,7 @@ sycamore_setup_arch(void)
sycamore_rtc_base = (void *) SYCAMORE_RTC_VADDR;
TODC_INIT(TODC_TYPE_DS1743, sycamore_rtc_base, sycamore_rtc_base,
sycamore_rtc_base, 8);
+ iounmap(fpga_status);
/* Identify the system */
printk(KERN_INFO "IBM Sycamore (IBM405GPr) Platform\n");
^ permalink raw reply related
* Re: Bootloader & Flash
From: schardt @ 2007-11-09 12:07 UTC (permalink / raw)
To: MingLiu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-W14EEE9667CD669878D3BD0B28A0@phx.gbl>
Hi again,
i've learned a little bit :)
- I have download the zImage.elf via the EDK flash loader
- The flash loader creates a bootloader, this is also running on start up=
:)
But ... It stops with an error-message after a few seconds:
EDK Bootloader:
Bootloader: Processed (0x)000000b2 S-recordsERROR: SREC line is corrupted=
What now ?
Georg
MingLiu wrote:
> Dear Georg,
> I guess you were talking about the booting process of the system, both =
HW and the SW, from the flash memory. This process should be like this:
>
> 1. Store your HW bitstream and Linux kernel in flash memories. If neede=
d, perhaps you want another bootloader program, such as U-boot also insid=
e.=20
>
> 2. In your HW bitstream, you need one bootloader which helps you to loa=
d the software and execute it in DDR-ram. EDK helps you to generate such =
a bootloader when you design.=20
>
> 3. Durong Power on, HW bitstream (with an EDK bootloader included) will=
be loaded into FPGA and configure the FPGA, then the EDK bootloader will=
load your Linux kernel into DDR-Ram and execute it there. Thus your linu=
x could run.=20
>
> This is a normal process. If you want to execute the program in flash d=
irectly, that's another story. Also you should know, for the booting proc=
ess, MTD driver is not necessary. The driver is only used when you want t=
o access flash memories when you booted your Linux kernel.
>
> Clear or not? :)
>
> Best Regards
> Ming
>
> ----------------------------------------> Date: Wed, 7 Nov 2007 13:00:3=
5 +0100> From: g.schardt@fz-juelich.de> To: Linuxppc-embedded@ozlabs.org>=
Subject: Bootloader & Flash>> Hi,>> i use the AVnet Xilinx4 FX12 Minimod=
ule and until now, i use system-ace> to configure the fpga and boot the l=
inux kernel.> But now, i want to boot from the on board flash memory and =
have no idea> where to start.>> I think i have to:> - save the fpga confi=
guration in the fpga-prom> - use/program some kind of bootloader store in=
fpga block ram to jump to> the flash-adress where the executable linux k=
ernel resist> - use the mtd-device driver to mount root fs on the same fl=
ash some> address later>> Is this the right way ?>>> Regards> Georg>>>>>>=
> -----------------------------------------------------------------------=
------------------> -----------------------------------------------------=
------------------------------------> Forschungszentrum J=C3=BClich GmbH>=
52425 J=C3=BClich>> Sitz der Gesellschaft: J=C3=BClich> Eingetragen im H=
andelsregister des Amtsgerichts D=C3=BCren Nr. HR B 3498> Vorsitzende des=
Aufsichtsrats: MinDirig'in B=C3=A4rbel Brumme-Bothe> Gesch=C3=A4ftsf=C3=BC=
hrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.>=
Vorsitzender)> ---------------------------------------------------------=
--------------------------------> ---------------------------------------=
--------------------------------------------------> _____________________=
__________________________> Linuxppc-embedded mailing list> Linuxppc-embe=
dded@ozlabs.org> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _________________________________________________________________
> MSN =E4=B8=AD=E6=96=87=E7=BD=91=EF=BC=8C=E6=9C=80=E6=96=B0=E6=97=B6=E5=B0=
=9A=E7=94=9F=E6=B4=BB=E8=B5=84=E8=AE=AF=EF=BC=8C=E7=99=BD=E9=A2=86=E8=81=9A=
=E9=9B=86=E9=97=A8=E6=88=B7=E3=80=82
> http://cn.msn.com
=0A=0A-------------------------------------------------------------------------=
----------------=0A-----------------------------------------------------------=
------------------------------=0AForschungszentrum J=C3=BClich GmbH=0A52425 J=C3=BClich=
=0A=0ASitz der Gesellschaft: J=C3=BClich=0AEingetragen im Handelsregister des Amtsgeri=
chts D=C3=BCren Nr. HR B 3498=0AVorsitzende des Aufsichtsrats: MinDirig'in B=C3=A4rbel=
Brumme-Bothe=0AGesch=C3=A4ftsf=C3=BChrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr.=
Ulrich Krafft (stellv. =0AVorsitzender)=0A-------------------------------------=
----------------------------------------------------=0A-----------------------=
------------------------------------------------------------------=0A
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2007-11-09 11:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <47336F9D.8060405@freescale.com>
Am Donnerstag, den 08.11.2007, 14:20 -0600 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > If both mdio and mdc controlling pins are on the same processor port,
> > one resource should be used.
> > Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.
>
> How about:
> The first reg resource is the I/O port register block on which MDIO
> resides. The second reg resource is the I/O port register block on
> which MDC resides. If there is only one reg resource, it is used for
> both MDIO and MDC.
>
Ok.
> We also need to change the reference to port C in fsl,mdio-pin and
> fsl,mdc-pin.
Do you mean this:
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
-> fsl,cpm2-mdio-bitbang (reg is port C registers)
Properties for fsl,cpm2-mdio-bitbang:
-> fsl,mdio-pin : pin of port C controlling mdio data
-> fsl,mdc-pin : pin of port C controlling mdio clock
Right. But i thought it would be related to the example,
and than the reader gets the short comment about I/O ports.
Or the other variant would be:
--------------------
iv) MDIO
Currently defined compatibles:
fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
fsl,cpm2-mdio-bitbang (reg is the I/O port register block(s))
Properties for fsl,cpm2-mdio-bitbang:
The first reg resource is the I/O port register block on which MDIO
resides. The second reg resource is the I/O port register block on
which MDC resides. If there is only one reg resource, it is used for
both MDIO and MDC.
fsl,mdio-pin : pin of chosen port for controlling mdio data
fsl,mdc-pin : pin of chosen port for controlling mdio clock
Example:
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <10d40 14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <12>;
fsl,mdc-pin = <13>;
};
-----------------
Regards
Sergej.
^ permalink raw reply
* Please pull from 'for-2.6.24' branch
From: Kumar Gala @ 2007-11-09 9:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24
to receive the following updates:
arch/powerpc/Makefile | 3 +++
arch/powerpc/sysdev/cpm_common.c | 4 +---
include/asm-powerpc/tlbflush.h | 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
Kumar Gala (2):
[POWERPC] Add -mno-spe for ARCH=powerpc builds
[POWERPC] Fix oops related to 4xx flush_tlb_page modification
Scott Wood (1):
[POWERPC] cpm: Fix a couple minor issues in cpm_common.c.
^ permalink raw reply
* [PATCH] [POWERPC] Fix oops related to 4xx flush_tlb_page modification
From: Kumar Gala @ 2007-11-09 9:58 UTC (permalink / raw)
To: linuxppc-dev
kmap_atomic calls flush_tlb_page with a NULL VMA and thus we end
up dereferencing a NULL pointer to try and get the context.id.
If the VMA is null use the global pid value of 0.
---
include/asm-powerpc/tlbflush.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/tlbflush.h b/include/asm-powerpc/tlbflush.h
index e7b4c0d..5c91081 100644
--- a/include/asm-powerpc/tlbflush.h
+++ b/include/asm-powerpc/tlbflush.h
@@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma->vm_mm->context.id);
+ _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
}
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr, vma->vm_mm->context.id);
+ _tlbie(vmaddr, vma ? vma->vm_mm->context.id : 0);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
--
1.5.3.3
^ permalink raw reply related
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Domen Puncer @ 2007-11-09 9:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, netdev
In-Reply-To: <9e4733910711082131v70c4b7bm2b00445b7e62c33f@mail.gmail.com>
On 09/11/07 00:31 -0500, Jon Smirl wrote:
> This is the reason I couldn't get user space started or connect to my
> nfs server. Patch is against current linus git.
>
> mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> where the wrong skb buffer was being referenced.
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Acked-by: Domen Puncer <domen.puncer@telargo.com>
I can't test it at the moment, but the patch is obviously correct,
mapped buffer should be the _same_ as submitted.
>
> ---
>
> drivers/net/fec_mpc52xx.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
> index a8a0ee2..ddfcc0b 100644
> --- a/drivers/net/fec_mpc52xx.c
> +++ b/drivers/net/fec_mpc52xx.c
> @@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
>
> rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
> (struct bcom_bd **)&bd);
> - dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
> + dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
>
> /* Test for errors in received frame */
> if (status & BCOM_FEC_RX_BD_ERRORS) {
> @@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
> irq, void *dev_id)
> bcom_prepare_next_buffer(priv->rx_dmatsk);
>
> bd->status = FEC_RX_BUFFER_SIZE;
> - bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
> + bd->skb_pa = dma_map_single(&dev->dev, skb->data,
> FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
>
> bcom_submit_next_buffer(priv->rx_dmatsk, skb);
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
--
Domen Puncer | Research & Development
.............................................................................................
Telargo d.o.o. | Zagrebška cesta 20 | 2000 Maribor | Slovenia
.............................................................................................
www.telargo.com
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Benjamin Herrenschmidt @ 2007-11-09 7:50 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071109074155.266120@gmx.net>
> I tried to use /bin/sh as init program and was able to enter a command,
> but then the machine locked up, too.
> Could that be a problem with a CPU sleeping/idle code?
That's possibly an issue, try disabling power save if any for that CPU
type. If it worked and broke, you may have to bisect tho.
Ben.
^ permalink raw reply
* Re: Kernel locks up after calling kernel_execve()
From: Gerhard Pircher @ 2007-11-09 7:41 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194564017.6561.21.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Fri, 09 Nov 2007 10:20:17 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Kernel locks up after calling kernel_execve()
>
> On Thu, 2007-11-08 at 22:47 +0100, Gerhard Pircher wrote:
> > Hi,
> >
> > I tested my patches for the AmigaOne platform with the lastest
> > 2.6.24-rc2 kernel snapshot. The kernel runs through all initcalls, but
> > locks up completely after calling INIT (/sbin/init) by kernel_execve().
> > Thus I couldn't capture any kernel oops or panic output. Also the magic
> > sysrq key doesn't work. Enabling debug code for soft lockups and
> > spinlock debugging didn't reveal any information.
> > I'm not sure, but I think it is the same problem I had with all kernels
> > >= 2.6.17. All of these kernels lock up shortly before or right at
> > calling the init program (resp. as soon as the kernel forks some kernel
> > theads).
> > Any suggestions on how to track down this problem?
>
> You don't have a HW debugger or anything like that ?
>
> Ben.
Unfortunately, no. A BDI2000 is too costly for me.
I tried to use /bin/sh as init program and was able to enter a command,
but then the machine locked up, too.
Could that be a problem with a CPU sleeping/idle code?
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* help linux for linux2.6
From: vincent.liu @ 2007-11-09 6:39 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200711091434079212507@bmrtech.com>
Hi
These days I am working on a MPC8270 based board with linux 2.6.10 kernel.
When I use the default kernel and load the uImage to the target board.
The kernel hangs after uncompressing kernel image ... ok .
I am freshman in the embedded linux area,So I do not know how to go on this project.
>From internet , I searched many articles,and no gain.
Please help me .
Thanks a lot.
--------------
vincent.liu
2007-11-09
^ permalink raw reply
* [PATCH] ibm_newemac: Add ET1011c PHY support
From: Stefan Roese @ 2007-11-09 6:07 UTC (permalink / raw)
To: linuxppc-dev
This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
board.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/phy.c | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/phy.c b/drivers/net/ibm_newemac/phy.c
index 1404457..4270a66 100644
--- a/drivers/net/ibm_newemac/phy.c
+++ b/drivers/net/ibm_newemac/phy.c
@@ -314,6 +314,38 @@ static struct mii_phy_def bcm5248_phy_def = {
.ops = &generic_phy_ops
};
+static int et1011c_init(struct mii_phy *phy)
+{
+ u16 reg_short;
+
+ reg_short = (u16)(phy_read(phy, 0x16));
+ reg_short &= ~(0x7);
+ reg_short |= 0x6; /* RGMII Trace Delay*/
+ phy_write(phy, 0x16, reg_short);
+
+ reg_short = (u16)(phy_read(phy, 0x17));
+ reg_short &= ~(0x40);
+ phy_write(phy, 0x17, reg_short);
+
+ phy_write(phy, 0x1c, 0x74f0);
+ return 0;
+}
+
+static struct mii_phy_ops et1011c_phy_ops = {
+ .init = et1011c_init,
+ .setup_aneg = genmii_setup_aneg,
+ .setup_forced = genmii_setup_forced,
+ .poll_link = genmii_poll_link,
+ .read_link = genmii_read_link
+};
+
+static struct mii_phy_def et1011c_phy_def = {
+ .phy_id = 0x0282f000,
+ .phy_id_mask = 0x0fffff00,
+ .name = "ET1011C Gigabit Ethernet",
+ .ops = &et1011c_phy_ops
+};
+
static int m88e1111_init(struct mii_phy *phy)
{
printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
@@ -344,6 +376,7 @@ static struct mii_phy_def m88e1111_phy_def = {
};
static struct mii_phy_def *mii_phy_table[] = {
+ &et1011c_phy_def,
&cis8201_phy_def,
&bcm5248_phy_def,
&m88e1111_phy_def,
--
1.5.3.5.561.g140d
^ permalink raw reply related
* Re: [PATCH 2/6] ibm_newemac: Add ET1011c PHY support
From: Stefan Roese @ 2007-11-09 5:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1194555321.6561.4.camel@pasglop>
On Thursday 08 November 2007, Benjamin Herrenschmidt wrote:
> > DENX is pretty good about having Signed-off-by lines in their tree...
> > maybe you should add the original authors as well if it's there.
>
> I picked it up from an already patched tree. Stefan, can you provide me
> the proper SOB ?
Sure:
Signed-off-by: Stefan Roese <sr@denx.de>
Thanks.
Best regards,
Stefan
^ permalink raw reply
* [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: Jon Smirl @ 2007-11-09 5:31 UTC (permalink / raw)
To: PowerPC dev list, Domen Puncer, Grant Likely, netdev
This is the reason I couldn't get user space started or connect to my
nfs server. Patch is against current linus git.
mpc5200 fec driver is corrupting memory. This patch fixes two bugs
where the wrong skb buffer was being referenced.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
drivers/net/fec_mpc52xx.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index a8a0ee2..ddfcc0b 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
(struct bcom_bd **)&bd);
- dma_unmap_single(&dev->dev, bd->skb_pa, skb->len, DMA_FROM_DEVICE);
+ dma_unmap_single(&dev->dev, bd->skb_pa, rskb->len, DMA_FROM_DEVICE);
/* Test for errors in received frame */
if (status & BCOM_FEC_RX_BD_ERRORS) {
@@ -467,7 +467,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int
irq, void *dev_id)
bcom_prepare_next_buffer(priv->rx_dmatsk);
bd->status = FEC_RX_BUFFER_SIZE;
- bd->skb_pa = dma_map_single(&dev->dev, rskb->data,
+ bd->skb_pa = dma_map_single(&dev->dev, skb->data,
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv->rx_dmatsk, skb);
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Fix typo #ifdef -> #ifndef
From: Andrew Morton @ 2007-11-09 4:35 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: jeff, netdev, linux-kernel, linuxppc-embedded
In-Reply-To: <472CC914.3030709@scram.de>
> On Sat, 03 Nov 2007 20:16:36 +0100 Jochen Friedrich <jochen@scram.de> wrote:
> Subject: [PATCH] [POWERPC] Fix typo #ifdef -> #ifndef
Please put the "powerpc" outside the []. Because things inside [] get
removed when the receiver applies the patch, but the subsystem
identification ("powerpc") is useful information which we want to carry
into the permanent git record. (Although Paul might add it anyway - some
git tree maintainers do).
> User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009)
This seems to be setting a record for MUA vandalism. Leading spaces were
removed and various esoteric whitespace transformations were made. The
diffs were small so I fixed them by hand.
Please strangle your email client.
^ permalink raw reply
* Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
From: Jerry Van Baren @ 2007-11-09 0:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <473392A3.4010203@freescale.com>
Scott Wood wrote:
> David Gibson wrote:
>>> How hard would it be to get libfdt to dynamically allocate any extra space
>>> it needs? This is a regression from the current flat device tree code...
>> Uh.. it already does. Or rather, the shims in libfdt-wrapper.c do so,
>> when libfdt functions which can expand the tree report that they've
>> run out of room.
>
> Ah, good -- I was looking in libfdt itself, not the wrapper. Now if
> only we could get something similar into u-boot... maybe libfdt proper
> could accept an optional realloc() function pointer in fdt_init(), and
> eliminate the need for the caller to provide such a wrapper?
>
> -Scott
Hi Scott,
My concern from the u-boot side is that u-boot has to know exactly
*where* to put the expanded blob because it has to pass it to linux and
keep it out of linux' way so it doesn't get "stepped on." Linux has an
advantage in that it "owns" all of memory and can allocate and
deallocate whatever and wherever and it won't step on itself (hopefully).
I'm assuming your boot wedge has the advantage of being able to use
linux's malloc() and thus don't have to worry about coordinating with
linux on memory allocation.
With the current u-boot fdt command, you can resize the blob, and this
can be done in a script with all the (somewhat limited) capabilities of
the u-boot shell (an adaptation of hush).
In the u-boot world, we fixate on memory maps and putting things in
specific places. Maybe I'm making a problem where one doesn't exist,
but an arbitrary malloc() in u-boot (as opposed to linux's malloc) seems
like a Bad Thing[tm] because it is uncontrolled and may end up in a very
bad place when linux starts (e.g. the linux start up script expands
linux on top of the blob).
Best regards,
gvb
^ permalink raw reply
* Re: DTS Bytestrings Representation in /dts-v1/ files
From: David Gibson @ 2007-11-09 0:21 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IqCtu-0000ZE-Vi@jdl.com>
On Thu, Nov 08, 2007 at 01:18:50PM -0600, Jon Loeliger wrote:
>
> Folks,
>
> When the new DTS /dts-v1/ support is released Real Soon Now,
> it will support C-like literal constants. Hex values will be
> prefixed with 0x, binary with 0b, and bare numbers will be
> decimal unless they start with a leading 0.
>
> One outstanding question on which I'd like some feedback
> is the issue of bytestring value representation.
>
> Currently they look like this:
>
> stuff = [ 0b 31 22 de ea ad be ef ];
Or, equivalently, like this:
stuff = [0b3122deeaadbeef];
I think it's important to be aware of the more compact form when
considering whether to change the representation.
> One opinion is to have them continue to look like that
> and be in hex only.
>
> Another opinion is to allow the new, consistent C-style
> literals and expressions so that one could have:
>
> new_stuff = [ 0x31 49 '1' 23 17 ];
>
> Opinions?
>
> Thanks,
> jdl
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] Use SLB size from the device tree
From: Olof Johansson @ 2007-11-09 0:16 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus, Will Schmidt
In-Reply-To: <510.1194565218@neuling.org>
On Fri, Nov 09, 2007 at 10:40:18AM +1100, Michael Neuling wrote:
> Currently we hardwire the number of SLBs but the PAPR says we export an
> ibm,slb-size property to specify the number of SLB entries. This patch
> uses this property instead of assuming 64 always. If no property is
> found, we assume 64 entries as before.
>
> This soft patches the SLB handler, so it won't change performance at
> all.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Olof Johansson <olof@lixom.net>
I wonder if it isn't time soon to move all the mmu_.* globals to a
struct. That's a separate issue though.
-Olof
^ permalink raw reply
* Re: [PATCH] DTC: Polish up the DTS Version 1 implementation.
From: David Gibson @ 2007-11-09 0:13 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <47331979.7030803@freescale.com>
On Thu, Nov 08, 2007 at 08:13:13AM -0600, Jon Loeliger wrote:
> David Gibson wrote:
> >
> > Yes, I know, but I don't think it's even worth having the unused
> > internal parameterization.
>
> OK. We can eliminate it then; no problem.
>
> >> I ran my "old versus new DTC" comparison script and found it. :-)
> >
> > Heh, we should fold that into the testsuite, too.
>
> I'll start by simply adding the script to the test directory then.
Ok.
> >> Because it wasn't working, as explained in the comment I added.
> >> Specifically, (1<<bits), with bits==64 overflowed and yielded
> >> the value 0.
> >
> > Ah...
> >
> > Well, I assumed (1ULL << 64) would equal 0, which is why the
> > comparison has the (-1) - I was expecting for bits == 64 it would end
> > up being against -1, i.e. 0xffffffffffffffff. This appears to work on
> > the systems I've been using.
>
> But not on an x86 system.
>
> > But I just remembered that (x << n) has undefined behaviour in C when
> > n >= word size.
>
> Exactly. In fact, I think x86 takes the shift value, bit-wise
> ANDs it with 63 internally, and then shifts left by that value.
>
> So I guess (1 << 64) is just returning garbage - I
>
> In fact, it is yielding 1 on an x86 machine.
>
> > suspect I didn't catch it because I've been building with -O0 for
> > gdb-ability, which might change the behaviour of corner cases like
> > that.
>
> Or works on a PPC machine? :-)
Actually I was working from home on an x86 machine when I wrote that,
so I think it must have been the -O0.
> > So I guess we need
> > else if ((errno == ERANGE)
> > || ((bits < 64) && (val >= (1ULL << bits))))
>
> Sounds good. I'll commit --amend that into the patch!
>
>
> >> And in the blue corner, touting consistent hex forms, ...
> >
> > And in the red, compact bytestring representations.
>
> > No, seriously, the inconsistency bothers me too. But so does the fact
> > that using 0x in the bytestring would double the minimum size for
> > representing bytestrings, somewhat changing the flavour of [] as well
> > (because spaces are no longer optional). I'm looking for a killer
> > argument one way or the other, but I haven't found it yet.
>
> But why does it even have to be hex numbers at all?
> I guess my point is that they could just be expressions.
> You could use 0x31 or 49 or '1' or 061, whichever made
> more sense in some application. You don't necessarily take
> a representational size hit.
But you do take a hit w.r.t. *minimum* representation size - there's
no form amongst all the possibilities here more compact than pure hex.
Especially since spaces are optional in the old form. The fact that
[ab cd 00] and [abcd00] are equivalent was a deliberate choice in the
original form.
The point of [] is for random binary data which is neither strings
(even with the odd strange character) nor sensibly organized into
32-bit (or larger) integers. Wanting something other than hex here is
much rarer than in the < > case.
You're seeing < > and [ ] as basically the same thing - a list of
values - with the only difference being the size of those values.
That's not wrong, but it's not the only way to look at it - and it's
not the way I was thinking of [ ] when I invented it. Your proposal
makes perfect sense while you think of [] as a list of values - but
not so much when it's thought of as a direct binary representation.
So I'm thinking perhaps we need two different things here: a "list of
values" representation, which can accomodate expressions and can also
have multiple sizes (because expressions which are evaluated to a
16-bit or 64-bit value could also be useful under the right
circumstances), and the [ ] "bytestring
literal" representation. Perhaps something like:
(32-bit values)
<0xdeadbeef (1+1)>
or <.32 0xdeadbeef (1+1)>
(64-bit values)
<.64 (0xdeadbeef << 32) (-1)>
(8-bit values)
<.8 0x00 0x0a 0xe4 0x2c 0x23 (0x10 + n)>
i.e. < > is list of values form, with size of each value as a sort of
parameter (defaulting to 32-bit, of course). I'm not sure I like that
particular syntax, it's just the first thing I came up with to
demonstrate the idea.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] Use SLB size from the device tree
From: Michael Neuling @ 2007-11-08 23:40 UTC (permalink / raw)
To: paulus; +Cc: Olof Johansson, linuxppc-dev, Will Schmidt
Currently we hardwire the number of SLBs but the PAPR says we export an
ibm,slb-size property to specify the number of SLB entries. This patch
uses this property instead of assuming 64 always. If no property is
found, we assume 64 entries as before.
This soft patches the SLB handler, so it won't change performance at
all.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Paulus: for your 2.6.25 tree.
Olof: this touches the pasemi code, but I've not tested with one.
Will: this will interact with your SLB xmon patch, but is easy to
resolve.
arch/powerpc/kernel/prom.c | 11 +++++++++++
arch/powerpc/mm/hash_utils_64.c | 1 +
arch/powerpc/mm/slb.c | 3 +++
arch/powerpc/mm/slb_low.S | 5 +++--
arch/powerpc/platforms/pasemi/setup.c | 3 ++-
arch/powerpc/xmon/xmon.c | 2 +-
include/asm-powerpc/mmu-hash64.h | 1 +
include/asm-powerpc/reg.h | 6 ------
8 files changed, 22 insertions(+), 10 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/prom.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/prom.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/prom.c
@@ -583,6 +583,16 @@ static void __init check_cpu_pa_features
ibm_pa_features, ARRAY_SIZE(ibm_pa_features));
}
+static void __init check_cpu_slb_size(unsigned long node)
+{
+ u32 *slb_size_ptr;
+
+ slb_size_ptr = of_get_flat_dt_prop(node, "ibm,slb-size", NULL);
+ if (slb_size_ptr != NULL) {
+ mmu_slb_size = *slb_size_ptr;
+ }
+}
+
static struct feature_property {
const char *name;
u32 min_value;
@@ -701,6 +711,7 @@ static int __init early_init_dt_scan_cpu
check_cpu_feature_properties(node);
check_cpu_pa_features(node);
+ check_cpu_slb_size(node);
#ifdef CONFIG_PPC_PSERIES
if (nthreads > 1)
Index: linux-2.6-ozlabs/arch/powerpc/mm/hash_utils_64.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_utils_64.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/hash_utils_64.c
@@ -95,6 +95,7 @@ int mmu_vmalloc_psize = MMU_PAGE_4K;
int mmu_io_psize = MMU_PAGE_4K;
int mmu_kernel_ssize = MMU_SEGSIZE_256M;
int mmu_highuser_ssize = MMU_SEGSIZE_256M;
+u16 mmu_slb_size = 64;
#ifdef CONFIG_HUGETLB_PAGE
int mmu_huge_psize = MMU_PAGE_16M;
unsigned int HPAGE_SHIFT;
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -255,6 +255,7 @@ void slb_initialize(void)
static int slb_encoding_inited;
extern unsigned int *slb_miss_kernel_load_linear;
extern unsigned int *slb_miss_kernel_load_io;
+ extern unsigned int *slb_compare_rr_to_size;
/* Prepare our SLB miss handler based on our page size */
linear_llp = mmu_psize_defs[mmu_linear_psize].sllp;
@@ -268,6 +269,8 @@ void slb_initialize(void)
SLB_VSID_KERNEL | linear_llp);
patch_slb_encoding(slb_miss_kernel_load_io,
SLB_VSID_KERNEL | io_llp);
+ patch_slb_encoding(slb_compare_rr_to_size,
+ mmu_slb_size);
DBG("SLB: linear LLP = %04x\n", linear_llp);
DBG("SLB: io LLP = %04x\n", io_llp);
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb_low.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb_low.S
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb_low.S
@@ -227,8 +227,9 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISER
7: ld r10,PACASTABRR(r13)
addi r10,r10,1
- /* use a cpu feature mask if we ever change our slb size */
- cmpldi r10,SLB_NUM_ENTRIES
+ /* This gets soft patched on boot. */
+_GLOBAL(slb_compare_rr_to_size)
+ cmpldi r10,0
blt+ 4f
li r10,SLB_NUM_BOLTED
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pasemi/setup.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pasemi/setup.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pasemi/setup.c
@@ -36,6 +36,7 @@
#include <asm/smp.h>
#include <asm/time.h>
#include <asm/of_platform.h>
+#include <asm/mmu.h>
#include <pcmcia/ss.h>
#include <pcmcia/cistpl.h>
@@ -295,7 +296,7 @@ static int pas_machine_check_handler(str
int i;
printk(KERN_ERR "slb contents:\n");
- for (i = 0; i < SLB_NUM_ENTRIES; i++) {
+ for (i = 0; i < mmu_slb_size; i++) {
asm volatile("slbmfee %0,%1" : "=r" (e) : "r" (i));
asm volatile("slbmfev %0,%1" : "=r" (v) : "r" (i));
printk(KERN_ERR "%02d %016lx %016lx\n", i, e, v);
Index: linux-2.6-ozlabs/arch/powerpc/xmon/xmon.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/xmon/xmon.c
+++ linux-2.6-ozlabs/arch/powerpc/xmon/xmon.c
@@ -2531,7 +2531,7 @@ static void dump_slb(void)
printf("SLB contents of cpu %x\n", smp_processor_id());
- for (i = 0; i < SLB_NUM_ENTRIES; i++) {
+ for (i = 0; i < mmu_slb_size; i++) {
asm volatile("slbmfee %0,%1" : "=r" (tmp) : "r" (i));
printf("%02d %016lx ", i, tmp);
Index: linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/mmu-hash64.h
+++ linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
@@ -180,6 +180,7 @@ extern int mmu_vmalloc_psize;
extern int mmu_io_psize;
extern int mmu_kernel_ssize;
extern int mmu_highuser_ssize;
+extern u16 mmu_slb_size;
/*
* If the processor supports 64k normal pages but not 64k cache
Index: linux-2.6-ozlabs/include/asm-powerpc/reg.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/reg.h
+++ linux-2.6-ozlabs/include/asm-powerpc/reg.h
@@ -695,12 +695,6 @@
#define PV_BE 0x0070
#define PV_PA6T 0x0090
-/*
- * Number of entries in the SLB. If this ever changes we should handle
- * it with a use a cpu feature fixup.
- */
-#define SLB_NUM_ENTRIES 64
-
/* Macros for setting and retrieving special purpose registers */
#ifndef __ASSEMBLY__
#define mfmsr() ({unsigned long rval; \
^ permalink raw reply
* OT: Strange delays / what usually happens every 10 min?
From: Florian Boelstler @ 2007-11-08 23:39 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am currently working on a MPC8540-based custom board, which runs Linux
2.6.15 (arch/ppc).
I set up a periodically running kernel thread, which is delayed for a
single jiffy using schedule_timeout() in an infinite loop. It is used to
measure delays between invocations of that thread. For measuring the
distance in time the PPC's time base lower half register is used
(obtained using get_cycles() defined in asm/timex.h).
The thread calculates the delay to the previous run and only outputs the
result if a new maximum value has been determined (in respect to all
previous cycles). Further the thread outputs a warning if a very "high"
delay was determined. I.e. a delay greater than 5ms.
While running that test driver a delay of about 10ms _exactly_ occurs
every 10 minutes.
The kernel is configured using CONFIG_HZ=1000 and CONFIG_PREEMPT.
The CCB is at 333MHz, whereas the TBR update rate is 333 MHz / 8, i.e.
41,625 MHz.
Apart of some kernel threads almost all user processes have been killed
during the test. Only SSH and a bash were running.
The kernel comes with compiled in CIFS support, some kernel debugging
features like soft-lockup detection and preemption debugging. I.e. ps
lists the kernel threads ksoftirqd, watchdog, events, khelper, kthread,
kblockd, pdflush, aio, cifsoplockd and cifsdnotifyd.
An appropriate userspace test tool based on nanosleep() determined the
same results like the kernel thread.
I also run tcpdump once to check whether some "random" network activity
might be the reason. While there havn't been any packets matching that
10 minutes interval, I got to know that a nearby Windows machine issues
ARP requests every 10 minutes (though not matching the 10ms delay).
Which leads to the question whether Linux does something similar in the
network sub system?
Thanks for any idea, I'm lost.
Cheers,
Florian
^ 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