* Re: [PATCH] [POWERPC] Move phys_addr_t definition into asm/types.h
From: Geert Uytterhoeven @ 2008-04-02 11:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <451ABD36-3763-4AF0-B24B-AF043393A72C@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1929 bytes --]
On Tue, 1 Apr 2008, Kumar Gala wrote:
> On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote:
> >Kumar Gala writes:
> > >Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use it in
> > >places that before would have caused recursive includes.
> > >
> > >For example to use phys_addr_t in <asm/page.h> we would have included
> > ><asm/mmu.h> which would have possibly included <asm/mmu-hash64.h> which
> > >includes <asm/page.h>. Wheeee recursive include.
> >
> >In general this looks fine. I wonder if you should use u64 rather
> >than unsigned long long. Since CONFIG_PHYS_64BIT=n on 64-bit machines
> >(which is itself somewhat counterintuitive) we will actually use
> >unsigned long on 64-bit machines, so it matters less than I originally
> >thought, but it would be worth explaining that in a comment and/or the
> >commit message.
>
> We could change it to be:
>
> /* Physical address used by some IO functions */
> #if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT)
> typedef u64 phys_addr_t;
> #else
> typedef u32 phys_addr_t;
> #endif
>
> This seems a bit more self documenting which is always nice (and I can add a
> comment in the commit message about CONFIG_PHYS_64BIT only making sense on
> ppc32).
If it's counterintuitive that CONFIG_PHYS_64BIT=n on 64-bit machines, why
not set it to =y in Kconfig?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Quick patch for ucc_geth, add copybreak and move TX processing to soft IRQ
From: Joakim Tjernlund @ 2008-04-02 11:48 UTC (permalink / raw)
To: 'linuxppc-dev Development', Netdev
This is a quick hack to make ucc_geth handle a
ping -f -l 10 gracefully. Without it, the CPU will lockup during the ping flood.
I don't have time ATM to clean it up, but if anyone wants to he is welcome :)
Commenst on the geleral approach is wanted though, why do I need to move TX
processing to soft IRQ to make the system response under heavy load?
Kernel 2.6.23
Jocke
---
drivers/net/ucc_geth.c | 85 +++++++++++++++++++++++++++++++++--------------
1 files changed, 59 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 038ec75..b74b298 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -73,6 +73,11 @@ static struct {
module_param_named(debug, debug.msg_enable, int, 0);
MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 0xffff=all)");
+#define COPYBREAK_DEFAULT 256
+static unsigned int copybreak __read_mostly = COPYBREAK_DEFAULT;
+MODULE_PARM_DESC(copybreak,
+ "Maximum size of packet that is copied to a new buffer on receive");
+
static struct ucc_geth_info ugeth_primary_info = {
.uf_info = {
.bd_mem_part = MEM_PART_MURAM,
@@ -3380,14 +3385,12 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
#ifdef CONFIG_UGETH_TX_ON_DEMAND
struct ucc_fast_private *uccf;
#endif
- u8 *bd; /* BD pointer */
+ u8 *bd, *bd_ptr; /* BD pointer */
u32 bd_status;
u8 txQ = 0;
ugeth_vdbg("%s: IN", __FUNCTION__);
- spin_lock_irq(&ugeth->lock);
-
ugeth->stats.tx_bytes += skb->len;
/* Start from the next BD that should be filled */
@@ -3401,16 +3404,18 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
(ugeth->skb_curtx[txQ] +
1) & TX_RING_MOD_MASK(ugeth->ug_info->bdRingLenTx[txQ]);
- /* set up the buffer descriptor */
- out_be32(&((struct qe_bd *)bd)->buf,
- dma_map_single(NULL, skb->data, skb->len, DMA_TO_DEVICE));
+ bd_ptr = dma_map_single(NULL, skb->data, skb->len, DMA_TO_DEVICE);
/* printk(KERN_DEBUG"skb->data is 0x%x\n",skb->data); */
bd_status = (bd_status & T_W) | T_R | T_I | T_L | skb->len;
+ spin_lock_irq(&ugeth->lock);
+ /* set up the buffer descriptor */
+ out_be32(&((struct qe_bd *)bd)->buf, bd_ptr);
/* set bd status and length */
out_be32((u32 *)bd, bd_status);
+ spin_unlock_irq(&ugeth->lock);
dev->trans_start = jiffies;
@@ -3427,8 +3432,6 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
netif_stop_queue(dev);
}
- ugeth->txBd[txQ] = bd;
-
if (ugeth->p_scheduler) {
ugeth->cpucount[txQ]++;
/* Indicate to QE that there are more Tx bds ready for
@@ -3442,7 +3445,7 @@ static int ucc_geth_start_xmit(struct sk_buff *skb, struct net_device *dev)
uccf = ugeth->uccf;
out_be16(uccf->p_utodr, UCC_FAST_TOD);
#endif
- spin_unlock_irq(&ugeth->lock);
+ ugeth->txBd[txQ] = bd;
return 0;
}
@@ -3454,6 +3457,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
u16 length, howmany = 0;
u32 bd_status;
u8 *bdBuffer;
+ struct sk_buff *new_skb;
ugeth_vdbg("%s: IN", __FUNCTION__);
@@ -3467,6 +3471,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
bdBuffer = (u8 *) in_be32(&((struct qe_bd *)bd)->buf);
length = (u16) ((bd_status & BD_LENGTH_MASK) - 4);
skb = ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]];
+ new_skb = NULL;
/* determine whether buffer is first, last, first and last
(single buffer frame) or middle (not first and not last) */
@@ -3484,6 +3489,21 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
} else {
ugeth->stats.rx_packets++;
howmany++;
+ if (length < copybreak) {
+ new_skb =
+ netdev_alloc_skb(ugeth->dev, length + NET_IP_ALIGN);
+ if (new_skb) {
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ skb_copy_to_linear_data_offset(new_skb,
+ -NET_IP_ALIGN,
+ (skb->data -
+ NET_IP_ALIGN),
+ (length +
+ NET_IP_ALIGN));
+ skb = new_skb;
+ out_be32((u32 *)bd, (R_E | R_I | (in_be32((u32 *)bd) & R_W)));
+ }
+ }
/* Prep the skb for the packet */
skb_put(skb, length);
@@ -3502,16 +3522,17 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8 rxQ, int rx_work_limit
ugeth->dev->last_rx = jiffies;
- skb = get_new_skb(ugeth, bd);
- if (!skb) {
- if (netif_msg_rx_err(ugeth))
- ugeth_warn("%s: No Rx Data Buffer", __FUNCTION__);
- ugeth->stats.rx_dropped++;
- break;
- }
-
- ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]] = skb;
+ if (!new_skb) {
+ skb = get_new_skb(ugeth, bd);
+ if (!skb) {
+ if (netif_msg_rx_err(ugeth))
+ ugeth_warn("%s: No Rx Data Buffer", __FUNCTION__);
+ ugeth->stats.rx_dropped++;
+ break;
+ }
+ ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]] = skb;
+ }
/* update to point at the next skb */
ugeth->skb_currx[rxQ] =
(ugeth->skb_currx[rxQ] +
@@ -3535,6 +3556,7 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
struct ucc_geth_private *ugeth = netdev_priv(dev);
u8 *bd; /* BD pointer */
u32 bd_status;
+ int howmany = 0;
bd = ugeth->confBd[txQ];
bd_status = in_be32((u32 *)bd);
@@ -3547,12 +3569,17 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
if ((bd == ugeth->txBd[txQ]) && (netif_queue_stopped(dev) == 0))
break;
-
+ howmany++;
ugeth->stats.tx_packets++;
/* Free the sk buffer associated with this TxBD */
+#ifdef CONFIG_UGETH_NAPI
+ dev_kfree_skb(ugeth->
+ tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]]);
+#else
dev_kfree_skb_irq(ugeth->
tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]]);
+#endif
ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]] = NULL;
ugeth->skb_dirtytx[txQ] =
(ugeth->skb_dirtytx[txQ] +
@@ -3570,7 +3597,7 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
bd_status = in_be32((u32 *)bd);
}
ugeth->confBd[txQ] = bd;
- return 0;
+ return howmany;
}
#ifdef CONFIG_UGETH_NAPI
@@ -3596,6 +3623,12 @@ static int ucc_geth_poll(struct net_device *dev, int *budget)
howmany += ucc_geth_rx(ugeth, i, rx_work_limit);
}
+ spin_lock(&ugeth->lock);
+ for (i = 0; i < ug_info->numQueuesTx; i++) {
+ ucc_geth_tx(dev, i);
+ }
+ spin_unlock(&ugeth->lock);
+
dev->quota -= howmany;
rx_work_limit -= howmany;
*budget -= howmany;
@@ -3604,7 +3637,7 @@ static int ucc_geth_poll(struct net_device *dev, int *budget)
netif_rx_complete(dev);
uccf = ugeth->uccf;
uccm = in_be32(uccf->p_uccm);
- uccm |= UCCE_RX_EVENTS;
+ uccm |= UCCE_RX_EVENTS | UCCE_TX_EVENTS;
out_be32(uccf->p_uccm, uccm);
}
@@ -3641,10 +3674,10 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
out_be32(uccf->p_ucce, ucce);
/* check for receive events that require processing */
- if (ucce & UCCE_RX_EVENTS) {
+ if (ucce & (UCCE_RX_EVENTS | UCCE_TX_EVENTS)) {
#ifdef CONFIG_UGETH_NAPI
if (netif_rx_schedule_prep(dev)) {
- uccm &= ~UCCE_RX_EVENTS;
+ uccm &= ~(UCCE_RX_EVENTS | UCCE_TX_EVENTS);
out_be32(uccf->p_uccm, uccm);
__netif_rx_schedule(dev);
}
@@ -3658,7 +3691,7 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
}
#endif /* CONFIG_UGETH_NAPI */
}
-
+#ifndef CONFIG_UGETH_NAPI
/* Tx event processing */
if (ucce & UCCE_TX_EVENTS) {
spin_lock(&ugeth->lock);
@@ -3671,7 +3704,7 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
}
spin_unlock(&ugeth->lock);
}
-
+#endif
/* Errors and other events */
if (ucce & UCCE_OTHER) {
if (ucce & UCCE_BSY) {
@@ -3959,7 +3992,7 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
dev->watchdog_timeo = TX_TIMEOUT;
#ifdef CONFIG_UGETH_NAPI
dev->poll = ucc_geth_poll;
- dev->weight = UCC_GETH_DEV_WEIGHT;
+ dev->weight = UCC_GETH_DEV_WEIGHT*2;
#endif /* CONFIG_UGETH_NAPI */
dev->stop = ucc_geth_close;
dev->get_stats = ucc_geth_get_stats;
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] RTAS - adapt procfs interface
From: Paul Mackerras @ 2008-04-02 11:48 UTC (permalink / raw)
To: Nathan Lynch; +Cc: maxim, cbe-oss-dev, linuxppc-dev
In-Reply-To: <20080401200404.GS7137@localdomain>
Nathan Lynch writes:
> I think this is better... the way these files are used is lame, but
> this should preserve the existing behavior. I haven't yet tested
> this, can you?
Looks OK -- can I have a proper patch description and a signed-off-by
line for this please?
Paul.
^ permalink raw reply
* Re: Please pull from 'for-2.6.25' branch
From: Paul Mackerras @ 2008-04-02 11:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev list, Linus Torvalds
In-Reply-To: <D9513606-E9BC-4D20-BB2E-7CCD3D9CEDAA@kernel.crashing.org>
Kumar Gala writes:
> Paul, any comments on sending this onto linus. I was hoping to avoid
> 2.6.25 coming up not support the proper device bindings for DMA and
> SATA.
I've pulled it and I'll send it on later (or Linus can pull it
directly if he wants). There is the iSeries fix from Ben H plus two
other patches (one from Bartlomiej Sieka and one from Nathan Lynch)
where I'm waiting for proper patch descriptions and/or signed-off-by
lines. I was hoping to get those tomorrow and send the lot on to
Linus.
Paul.
^ permalink raw reply
* Re: [PATCH] RTAS - adapt procfs interface
From: Jens Osterkamp @ 2008-04-02 11:34 UTC (permalink / raw)
To: Nathan Lynch; +Cc: maxim, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <20080401200404.GS7137@localdomain>
On Tuesday 01 April 2008, Nathan Lynch wrote:
> Nathan Lynch wrote:
> >
> > One could argue that the real problem is using the proc_dir_entry's
> > reference count to enforce exclusive open.
>
>
> I think this is better... the way these files are used is lame, but
> this should preserve the existing behavior. I haven't yet tested
> this, can you?
I did and it works for me...
>
>
> diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
> index f227659..00bc308 100644
> --- a/arch/powerpc/kernel/rtas_flash.c
> +++ b/arch/powerpc/kernel/rtas_flash.c
> @@ -139,7 +139,7 @@ struct rtas_validate_flash_t
> unsigned int update_results; /* Update results token */
> };
>
> -static DEFINE_SPINLOCK(flash_file_open_lock);
> +static atomic_t open_count = ATOMIC_INIT(0);
> static struct proc_dir_entry *firmware_flash_pde;
> static struct proc_dir_entry *firmware_update_pde;
> static struct proc_dir_entry *validate_pde;
> @@ -216,7 +216,7 @@ static int rtas_flash_release(struct inode *inode, struct file *file)
> uf->flist = NULL;
> }
>
> - atomic_dec(&dp->count);
> + atomic_dec(&open_count);
> return 0;
> }
>
> @@ -352,26 +352,17 @@ static ssize_t rtas_flash_write(struct file *file, const char __user *buffer,
>
> static int rtas_excl_open(struct inode *inode, struct file *file)
> {
> - struct proc_dir_entry *dp = PDE(inode);
> -
> - /* Enforce exclusive open with use count of PDE */
> - spin_lock(&flash_file_open_lock);
> - if (atomic_read(&dp->count) > 1) {
> - spin_unlock(&flash_file_open_lock);
> + if (atomic_inc_return(&open_count) > 1) {
> + atomic_dec(&open_count);
> return -EBUSY;
> }
>
> - atomic_inc(&dp->count);
> - spin_unlock(&flash_file_open_lock);
> -
> return 0;
> }
>
> static int rtas_excl_release(struct inode *inode, struct file *file)
> {
> - struct proc_dir_entry *dp = PDE(inode);
> -
> - atomic_dec(&dp->count);
> + atomic_dec(&open_count);
>
> return 0;
> }
> @@ -580,7 +571,7 @@ static int validate_flash_release(struct inode *inode, struct file *file)
> }
>
> /* The matching atomic_inc was in rtas_excl_open() */
> - atomic_dec(&dp->count);
> + atomic_dec(&open_count);
>
> return 0;
> }
>
Gruß,
Jens
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* Re: [PATCH] RTAS - adapt procfs interface
From: Jens Osterkamp @ 2008-04-02 11:33 UTC (permalink / raw)
To: Nathan Lynch; +Cc: maxim, linuxppc-dev, Paul Mackerras, cbe-oss-dev
In-Reply-To: <20080401163504.GP7137@localdomain>
On Tuesday 01 April 2008, Nathan Lynch wrote:
> Jens Osterkamp wrote:
> >
> > Handling of the proc_dir_entry->count has being changed in 2.6.24-rc5.
>
> Do you know which commit caused the change?
Yes, we bisected it to the following commit :
commit 5a622f2d0f86b316b07b55a4866ecb5518dd1cf7
Author: Alexey Dobriyan <adobriyan@sw.ru>
Date: Tue Dec 4 23:45:28 2007 -0800
proc: fix proc_dir_entry refcounting
Creating PDEs with refcount 0 and "deleted" flag has problems (see below).
Switch to usual scheme:
* PDE is created with refcount 1
* every de_get does +1
* every de_put() and remove_proc_entry() do -1
* once refcount reaches 0, PDE is freed.
This elegantly fixes at least two following races (both observed) without
introducing new locks, without abusing old locks, without spreading
lock_kernel():
[...]
Gruß,
Jens
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* Re: [PATCH 0/4] [POWERPC] lockdep support for ppc64
From: Benjamin Herrenschmidt @ 2008-04-02 11:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1207129830.10910.25.camel@johannes.berg>
On Wed, 2008-04-02 at 11:50 +0200, Johannes Berg wrote:
> > This serie of patches adds lockdep support for 64 bits
> > powerpc. Dale's patch for 32 bits still need me to review
> > and test it which I'll try to do asap.
>
> Yay. I'll give it another try later today.
Haven't tested this version on G5 yet btw :-) (though I had a previous
one working internally). I tested on POWER6 pSeries and old iSeries
(spent a while fixing the later).
I'll run more tests tomorrow hopefully and add a few patch fixing
some of the issues that lockdep already starting showing.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Benjamin Herrenschmidt @ 2008-04-02 11:00 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080402.195215.-1300526901.kouish@swc.toshiba.co.jp>
On Wed, 2008-04-02 at 19:52 +0900, Ishizaki Kou wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > As you said, if read/write/in/out functions take device parameter,
> > > taking I/O function pointers into the dev_archdata structure should be
> > > the best solution. But they don't take device parameter, and they must
> > > search I/O function pointers with address parameter. I think it's
> > > better they search pointers from bus bridges, because access mothod
> > > for a device on its parent bus bridge, not device itself.
> >
> > What I meant is that if the pointers are in dev_archdata, we can
> > populate with a different set of pointers for PCI vs. PCI-E.
>
> I'm afraid I misunderstood your opinion.
>
> My concern is how to find a device by address when I/O function
> pointers are in dev_archdata.
>
> You must select the appropriate device with an address, because all
> I/O functions, read/write/in/out don't have device parameter. If the
> address is in MMIO space, you can set 'token' to the address to select
> the device. But in IO space, you can't set 'token' to the I/O port
> address. Thefore you must scan all devices to select the device.
>
> Do you have any better solution?
No, you are right. The EEH code has a way to go back to the device but
it has significant overhead. Let's stick to your current approach.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/11] cell: generalize io-workarounds code
From: Ishizaki Kou @ 2008-04-02 10:52 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1206652101.10388.28.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > As you said, if read/write/in/out functions take device parameter,
> > taking I/O function pointers into the dev_archdata structure should be
> > the best solution. But they don't take device parameter, and they must
> > search I/O function pointers with address parameter. I think it's
> > better they search pointers from bus bridges, because access mothod
> > for a device on its parent bus bridge, not device itself.
>
> What I meant is that if the pointers are in dev_archdata, we can
> populate with a different set of pointers for PCI vs. PCI-E.
I'm afraid I misunderstood your opinion.
My concern is how to find a device by address when I/O function
pointers are in dev_archdata.
You must select the appropriate device with an address, because all
I/O functions, read/write/in/out don't have device parameter. If the
address is in MMIO space, you can set 'token' to the address to select
the device. But in IO space, you can't set 'token' to the I/O port
address. Thefore you must scan all devices to select the device.
Do you have any better solution?
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: Peter Korsgaard @ 2008-04-02 9:51 UTC (permalink / raw)
To: John Linn; +Cc: git, linuxppc-embedded
In-Reply-To: <20080401234142.41B13191804A@mail111-sin.bigfish.com>
>>>>> "John" == John Linn <John.Linn@xilinx.com> writes:
John> I pushed PowerPC 440 support to the Xilinx Git server with
John> support for ppc arch and with powerpc arch support coming in
John> the near future.
Neat, but why have you added arch/ppc support? It's supposed to go
away pretty much by the time the hardware gets in the hand of
developers.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 0/4] [POWERPC] lockdep support for ppc64
From: Johannes Berg @ 2008-04-02 9:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1207122728.672673.111194574046.qpush@grosgo>
[-- Attachment #1: Type: text/plain, Size: 230 bytes --]
> This serie of patches adds lockdep support for 64 bits
> powerpc. Dale's patch for 32 bits still need me to review
> and test it which I'll try to do asap.
Yay. I'll give it another try later today.
Thanks,
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: SecretLab Git Server
From: Peter Korsgaard @ 2008-04-02 9:49 UTC (permalink / raw)
To: Grant Likely; +Cc: Sam Karp, linuxppc-embedded
In-Reply-To: <fa686aa40804012117s45d70c1by964d2e54fa097d1@mail.gmail.com>
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Grant> On Mon, Mar 31, 2008 at 8:12 PM, Sam Karp <sam.d.karp@gmail.com> wrote:
>> Any idea of other sources where else I could get either a kernel with the
>> USB driver or a standalone driver for the Xilinx ML403 board?
Grant> Look on the powerpc mailing list archives for Peter Korsgaard's patch
Grant> set for the c67x00. (I believe v10 is the latest patch set).
You can also get them from my homepage:
http://peter.korsgaard.com/patches/linux/c67x00-10-*.patch
I'll send an updated series in a few days.
Grant> You need to use the mailing list archive instead of patchwork. For
Grant> some reason patchwork doesn't recognize Peter's patches.
Yeah, I don't know what I'm doing wrong - Maybe it simply doesn't like
me? ;)
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH 4/4] [POWERPC] irqtrace support to 64-bit powerpc
From: Benjamin Herrenschmidt @ 2008-04-02 7:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1207122728.672673.111194574046.qpush@grosgo>
This adds the low level irq tracing hooks to the powerpc architecture
needed to enable full lockdep functionality
Partly based on Johannes Berg's initial version, removing the asm
trampoline that isn't needed (thus improving perfs) and all sorts
of bits and pieces, reworking most of the assembly, etc...
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/Kconfig | 9 +++++++
arch/powerpc/kernel/entry_64.S | 27 +++++++++++++++++++++-
arch/powerpc/kernel/head_64.S | 47 +++++++++++++++++++++++++++-------------
arch/powerpc/kernel/irq.c | 3 +-
arch/powerpc/kernel/ppc_ksyms.c | 4 ---
arch/powerpc/kernel/setup_64.c | 4 +++
include/asm-powerpc/exception.h | 6 ++---
include/asm-powerpc/hw_irq.h | 13 +++++------
include/asm-powerpc/irqflags.h | 37 +++++++++++++++++++++----------
include/asm-powerpc/rwsem.h | 35 ++++++++++++++++++++++-------
include/asm-powerpc/spinlock.h | 1
11 files changed, 134 insertions(+), 52 deletions(-)
--- linux-work.orig/arch/powerpc/Kconfig 2008-04-02 18:30:18.000000000 +1100
+++ linux-work/arch/powerpc/Kconfig 2008-04-02 18:30:21.000000000 +1100
@@ -53,6 +53,15 @@ config STACKTRACE_SUPPORT
bool
default y
+config TRACE_IRQFLAGS_SUPPORT
+ bool
+ depends on PPC64
+ default y
+
+config LOCKDEP_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
Index: linux-work/arch/powerpc/kernel/irq.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/irq.c 2008-04-02 18:30:20.000000000 +1100
+++ linux-work/arch/powerpc/kernel/irq.c 2008-04-02 18:30:21.000000000 +1100
@@ -114,7 +114,7 @@ static inline void set_soft_enabled(unsi
: : "r" (enable), "i" (offsetof(struct paca_struct, soft_enabled)));
}
-void local_irq_restore(unsigned long en)
+void raw_local_irq_restore(unsigned long en)
{
/*
* get_paca()->soft_enabled = en;
@@ -174,6 +174,7 @@ void local_irq_restore(unsigned long en)
__hard_irq_enable();
}
+EXPORT_SYMBOL(raw_local_irq_restore);
#endif /* CONFIG_PPC64 */
int show_interrupts(struct seq_file *p, void *v)
Index: linux-work/arch/powerpc/kernel/ppc_ksyms.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/ppc_ksyms.c 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/arch/powerpc/kernel/ppc_ksyms.c 2008-04-02 18:30:21.000000000 +1100
@@ -45,10 +45,6 @@
#include <asm/signal.h>
#include <asm/dcr.h>
-#ifdef CONFIG_PPC64
-EXPORT_SYMBOL(local_irq_restore);
-#endif
-
#ifdef CONFIG_PPC32
extern void transfer_to_handler(void);
extern void do_IRQ(struct pt_regs *regs);
Index: linux-work/include/asm-powerpc/hw_irq.h
===================================================================
--- linux-work.orig/include/asm-powerpc/hw_irq.h 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/include/asm-powerpc/hw_irq.h 2008-04-02 18:30:21.000000000 +1100
@@ -27,7 +27,7 @@ static inline unsigned long local_get_fl
return flags;
}
-static inline unsigned long local_irq_disable(void)
+static inline unsigned long raw_local_irq_disable(void)
{
unsigned long flags, zero;
@@ -39,14 +39,15 @@ static inline unsigned long local_irq_di
return flags;
}
-extern void local_irq_restore(unsigned long);
+extern void raw_local_irq_restore(unsigned long);
extern void iseries_handle_interrupts(void);
-#define local_irq_enable() local_irq_restore(1)
-#define local_save_flags(flags) ((flags) = local_get_flags())
-#define local_irq_save(flags) ((flags) = local_irq_disable())
+#define raw_local_irq_enable() raw_local_irq_restore(1)
+#define raw_local_save_flags(flags) ((flags) = local_get_flags())
+#define raw_local_irq_save(flags) ((flags) = raw_local_irq_disable())
-#define irqs_disabled() (local_get_flags() == 0)
+#define raw_irqs_disabled() (local_get_flags() == 0)
+#define raw_irqs_disabled_flags(flags) ((flags) == 0)
#define __hard_irq_enable() __mtmsrd(mfmsr() | MSR_EE, 1)
#define __hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
Index: linux-work/include/asm-powerpc/irqflags.h
===================================================================
--- linux-work.orig/include/asm-powerpc/irqflags.h 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/include/asm-powerpc/irqflags.h 2008-04-02 18:30:21.000000000 +1100
@@ -2,30 +2,43 @@
* include/asm-powerpc/irqflags.h
*
* IRQ flags handling
- *
- * This file gets included from lowlevel asm headers too, to provide
- * wrapped versions of the local_irq_*() APIs, based on the
- * raw_local_irq_*() macros from the lowlevel headers.
*/
#ifndef _ASM_IRQFLAGS_H
#define _ASM_IRQFLAGS_H
+#ifndef __ASSEMBLY__
/*
* Get definitions for raw_local_save_flags(x), etc.
*/
#include <asm-powerpc/hw_irq.h>
+#else
+#ifdef CONFIG_TRACE_IRQFLAGS
/*
- * Do the CPU's IRQ-state tracing from assembly code. We call a
- * C function, so save all the C-clobbered registers:
+ * Most of the CPU's IRQ-state tracing is done from assembly code; we
+ * have to call a C function so call a wrapper that saves all the
+ * C-clobbered registers.
*/
-#ifdef CONFIG_TRACE_IRQFLAGS
-
-#error No support on PowerPC yet for CONFIG_TRACE_IRQFLAGS
-
+#define TRACE_ENABLE_INTS bl .trace_hardirqs_on
+#define TRACE_DISABLE_INTS bl .trace_hardirqs_off
+#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip) \
+ cmpdi en, 0; \
+ bne 95f; \
+ stb en,PACASOFTIRQEN(r13); \
+ bl .trace_hardirqs_off; \
+ b skip; \
+95: bl .trace_hardirqs_on; \
+ li en,1;
+#define TRACE_AND_RESTORE_IRQ(en) \
+ TRACE_AND_RESTORE_IRQ_PARTIAL(en,96f); \
+96: stb en,PACASOFTIRQEN(r13)
#else
-# define TRACE_IRQS_ON
-# define TRACE_IRQS_OFF
+#define TRACE_ENABLE_INTS
+#define TRACE_DISABLE_INTS
+#define TRACE_AND_RESTORE_IRQ_PARTIAL(en,skip)
+#define TRACE_AND_RESTORE_IRQ(en) \
+ stb en,PACASOFTIRQEN(r13)
+#endif
#endif
#endif
Index: linux-work/include/asm-powerpc/rwsem.h
===================================================================
--- linux-work.orig/include/asm-powerpc/rwsem.h 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/include/asm-powerpc/rwsem.h 2008-04-02 18:30:21.000000000 +1100
@@ -32,11 +32,20 @@ struct rw_semaphore {
#define RWSEM_ACTIVE_WRITE_BIAS (RWSEM_WAITING_BIAS + RWSEM_ACTIVE_BIAS)
spinlock_t wait_lock;
struct list_head wait_list;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ struct lockdep_map dep_map;
+#endif
};
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+# define __RWSEM_DEP_MAP_INIT(lockname) , .dep_map = { .name = #lockname }
+#else
+# define __RWSEM_DEP_MAP_INIT(lockname)
+#endif
+
#define __RWSEM_INITIALIZER(name) \
- { RWSEM_UNLOCKED_VALUE, SPIN_LOCK_UNLOCKED, \
- LIST_HEAD_INIT((name).wait_list) }
+ { RWSEM_UNLOCKED_VALUE, __SPIN_LOCK_UNLOCKED((name).wait_lock), \
+ LIST_HEAD_INIT((name).wait_list) __RWSEM_DEP_MAP_INIT(name) }
#define DECLARE_RWSEM(name) \
struct rw_semaphore name = __RWSEM_INITIALIZER(name)
@@ -46,12 +55,15 @@ extern struct rw_semaphore *rwsem_down_w
extern struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem);
extern struct rw_semaphore *rwsem_downgrade_wake(struct rw_semaphore *sem);
-static inline void init_rwsem(struct rw_semaphore *sem)
-{
- sem->count = RWSEM_UNLOCKED_VALUE;
- spin_lock_init(&sem->wait_lock);
- INIT_LIST_HEAD(&sem->wait_list);
-}
+extern void __init_rwsem(struct rw_semaphore *sem, const char *name,
+ struct lock_class_key *key);
+
+#define init_rwsem(sem) \
+ do { \
+ static struct lock_class_key __key; \
+ \
+ __init_rwsem((sem), #sem, &__key); \
+ } while (0)
/*
* lock for reading
@@ -78,7 +90,7 @@ static inline int __down_read_trylock(st
/*
* lock for writing
*/
-static inline void __down_write(struct rw_semaphore *sem)
+static inline void __down_write_nested(struct rw_semaphore *sem, int subclass)
{
int tmp;
@@ -88,6 +100,11 @@ static inline void __down_write(struct r
rwsem_down_write_failed(sem);
}
+static inline void __down_write(struct rw_semaphore *sem)
+{
+ __down_write_nested(sem, 0);
+}
+
static inline int __down_write_trylock(struct rw_semaphore *sem)
{
int tmp;
Index: linux-work/include/asm-powerpc/spinlock.h
===================================================================
--- linux-work.orig/include/asm-powerpc/spinlock.h 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/include/asm-powerpc/spinlock.h 2008-04-02 18:30:21.000000000 +1100
@@ -19,6 +19,7 @@
*
* (the type definitions are in asm/spinlock_types.h)
*/
+#include <linux/irqflags.h>
#ifdef CONFIG_PPC64
#include <asm/paca.h>
#include <asm/hvcall.h>
Index: linux-work/include/asm-powerpc/exception.h
===================================================================
--- linux-work.orig/include/asm-powerpc/exception.h 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/include/asm-powerpc/exception.h 2008-04-02 18:30:21.000000000 +1100
@@ -228,18 +228,18 @@ label##_pSeries: \
BEGIN_FW_FTR_SECTION; \
stb r11,PACAHARDIRQEN(r13); \
END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISERIES); \
+ TRACE_DISABLE_INTS; \
BEGIN_FW_FTR_SECTION; \
mfmsr r10; \
ori r10,r10,MSR_EE; \
mtmsrd r10,1; \
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
-
#else
#define DISABLE_INTS \
li r11,0; \
stb r11,PACASOFTIRQEN(r13); \
- stb r11,PACAHARDIRQEN(r13)
-
+ stb r11,PACAHARDIRQEN(r13); \
+ TRACE_DISABLE_INTS
#endif /* CONFIG_PPC_ISERIES */
#define ENABLE_INTS \
Index: linux-work/arch/powerpc/kernel/head_64.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/head_64.S 2008-04-02 18:24:45.000000000 +1100
+++ linux-work/arch/powerpc/kernel/head_64.S 2008-04-02 18:30:21.000000000 +1100
@@ -36,8 +36,7 @@
#include <asm/firmware.h>
#include <asm/page_64.h>
#include <asm/exception.h>
-
-#define DO_SOFT_DISABLE
+#include <asm/irqflags.h>
/*
* We layout physical memory as follows:
@@ -450,8 +449,8 @@ bad_stack:
*/
fast_exc_return_irq: /* restores irq state too */
ld r3,SOFTE(r1)
+ TRACE_AND_RESTORE_IRQ(r3);
ld r12,_MSR(r1)
- stb r3,PACASOFTIRQEN(r13) /* restore paca->soft_enabled */
rldicl r4,r12,49,63 /* get MSR_EE to LSB */
stb r4,PACAHARDIRQEN(r13) /* restore paca->hard_enabled */
b 1f
@@ -808,7 +807,7 @@ _STATIC(load_up_altivec)
* Hash table stuff
*/
.align 7
-_GLOBAL(do_hash_page)
+_STATIC(do_hash_page)
std r3,_DAR(r1)
std r4,_DSISR(r1)
@@ -820,6 +819,27 @@ BEGIN_FTR_SECTION
END_FTR_SECTION_IFCLR(CPU_FTR_SLB)
/*
+ * On iSeries, we soft-disable interrupts here, then
+ * hard-enable interrupts so that the hash_page code can spin on
+ * the hash_table_lock without problems on a shared processor.
+ */
+ DISABLE_INTS
+
+ /*
+ * Currently, trace_hardirqs_off() will be called by DISABLE_INTS
+ * and will clobber volatile registers when irq tracing is enabled
+ * so we need to reload them. It may be possible to be smarter here
+ * and move the irq tracing elsewhere but let's keep it simple for
+ * now
+ */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ ld r3,_DAR(r1)
+ ld r4,_DSISR(r1)
+ ld r5,_TRAP(r1)
+ ld r12,_MSR(r1)
+ clrrdi r5,r5,4
+#endif /* CONFIG_TRACE_IRQFLAGS */
+ /*
* We need to set the _PAGE_USER bit if MSR_PR is set or if we are
* accessing a userspace segment (even from the kernel). We assume
* kernel addresses always have the high bit set.
@@ -832,13 +852,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_SLB)
rlwimi r4,r5,22+2,31-2,31-2 /* Set _PAGE_EXEC if trap is 0x400 */
/*
- * On iSeries, we soft-disable interrupts here, then
- * hard-enable interrupts so that the hash_page code can spin on
- * the hash_table_lock without problems on a shared processor.
- */
- DISABLE_INTS
-
- /*
* r3 contains the faulting address
* r4 contains the required access permissions
* r5 contains the trap number
@@ -848,7 +861,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_SLB)
bl .hash_page /* build HPTE if possible */
cmpdi r3,0 /* see if hash_page succeeded */
-#ifdef DO_SOFT_DISABLE
BEGIN_FW_FTR_SECTION
/*
* If we had interrupts soft-enabled at the point where the
@@ -860,7 +872,7 @@ BEGIN_FW_FTR_SECTION
*/
beq 13f
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
-#endif
+
BEGIN_FW_FTR_SECTION
/*
* Here we have interrupts hard-disabled, so it is sufficient
@@ -874,11 +886,12 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER
/*
* hash_page couldn't handle it, set soft interrupt enable back
- * to what it was before the trap. Note that .local_irq_restore
+ * to what it was before the trap. Note that .raw_local_irq_restore
* handles any interrupts pending at this point.
*/
ld r3,SOFTE(r1)
- bl .local_irq_restore
+ TRACE_AND_RESTORE_IRQ_PARTIAL(r3, 11f)
+ bl .raw_local_irq_restore
b 11f
/* Here we have a page fault that hash_page can't handle. */
@@ -1477,6 +1490,10 @@ _INIT_STATIC(start_here_multiplatform)
addi r2,r2,0x4000
add r2,r2,r26
+ /* Set initial ptr to current */
+ LOAD_REG_IMMEDIATE(r4, init_task)
+ std r4,PACACURRENT(r13)
+
/* Do very early kernel initializations, including initial hash table,
* stab and slb setup before we turn on relocation. */
Index: linux-work/arch/powerpc/kernel/setup_64.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/setup_64.c 2008-04-02 18:28:32.000000000 +1100
+++ linux-work/arch/powerpc/kernel/setup_64.c 2008-04-02 18:30:21.000000000 +1100
@@ -33,6 +33,7 @@
#include <linux/serial_8250.h>
#include <linux/bootmem.h>
#include <linux/pci.h>
+#include <linux/lockdep.h>
#include <asm/io.h>
#include <asm/kdump.h>
#include <asm/prom.h>
@@ -178,6 +179,9 @@ void __init early_setup(unsigned long dt
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
+ /* Initialize lockdep early or else spinlocks will blow */
+ lockdep_init();
+
DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
/*
Index: linux-work/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/entry_64.S 2008-04-02 18:11:56.000000000 +1100
+++ linux-work/arch/powerpc/kernel/entry_64.S 2008-04-02 18:30:21.000000000 +1100
@@ -29,6 +29,7 @@
#include <asm/cputable.h>
#include <asm/firmware.h>
#include <asm/bug.h>
+#include <asm/irqflags.h>
/*
* System calls.
@@ -88,6 +89,14 @@ system_call_common:
addi r9,r1,STACK_FRAME_OVERHEAD
ld r11,exception_marker@toc(r2)
std r11,-16(r9) /* "regshere" marker */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .trace_hardirqs_on
+ REST_GPR(0,r1)
+ REST_4GPRS(3,r1)
+ REST_2GPRS(7,r1)
+ addi r9,r1,STACK_FRAME_OVERHEAD
+ ld r12,_MSR(r1)
+#endif /* CONFIG_TRACE_IRQFLAGS */
li r10,1
stb r10,PACASOFTIRQEN(r13)
stb r10,PACAHARDIRQEN(r13)
@@ -102,7 +111,7 @@ BEGIN_FW_FTR_SECTION
b hardware_interrupt_entry
2:
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
-#endif
+#endif /* CONFIG_PPC_ISERIES */
mfmsr r11
ori r11,r11,MSR_EE
mtmsrd r11,1
@@ -504,6 +513,10 @@ BEGIN_FW_FTR_SECTION
li r3,0
stb r3,PACASOFTIRQEN(r13) /* ensure we are soft-disabled */
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .trace_hardirqs_off
+ mfmsr r10
+#endif
ori r10,r10,MSR_EE
mtmsrd r10 /* hard-enable again */
addi r3,r1,STACK_FRAME_OVERHEAD
@@ -512,7 +525,7 @@ BEGIN_FW_FTR_SECTION
4:
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
#endif
- stb r5,PACASOFTIRQEN(r13)
+ TRACE_AND_RESTORE_IRQ(r5);
/* extract EE bit and use it to restore paca->hard_enabled */
ld r3,_MSR(r1)
@@ -580,6 +593,16 @@ do_work:
bne restore
/* here we are preempting the current task */
1:
+#ifdef CONFIG_TRACE_IRQFLAGS
+ bl .trace_hardirqs_on
+ /* Note: we just clobbered r10 which used to contain the previous
+ * MSR before the hard-disabling done by the caller of do_work.
+ * We don't have that value anymore, but it doesn't matter as
+ * we will hard-enable unconditionally, we can just reload the
+ * current MSR into r10
+ */
+ mfmsr r10
+#endif /* CONFIG_TRACE_IRQFLAGS */
li r0,1
stb r0,PACASOFTIRQEN(r13)
stb r0,PACAHARDIRQEN(r13)
^ permalink raw reply
* [PATCH 3/4] [POWERPC] Fixup softirq preempt count
From: Benjamin Herrenschmidt @ 2008-04-02 7:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1207122728.672673.111194574046.qpush@grosgo>
This fixes the handling of the preempt count when switching
interrupt stacks so that HW interrupt properly get the softirq
mask copied over from the previous stack.
It also initializes the softirq stack preempt_count to 0 instead
of SOFTIRQ_OFFSET, like x86, as __do_softirq() does the increment,
and we hit some lockdep checks if we have it twice.
That means we do run for a little while off the softirq stack
with the preempt-count set to 0, which could be deadly if we
try to take a softirq at that point, however we do so with
interrupts disabled, so I think we are ok.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/irq.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/kernel/irq.c 2008-04-02 16:48:58.000000000 +1100
+++ linux-work/arch/powerpc/kernel/irq.c 2008-04-02 16:49:36.000000000 +1100
@@ -310,8 +310,21 @@ void do_IRQ(struct pt_regs *regs)
handler = &__do_IRQ;
irqtp->task = curtp->task;
irqtp->flags = 0;
+
+ /* Copy the softirq bits in preempt_count so that the
+ * softirq checks work in the hardirq context.
+ */
+ irqtp->preempt_count =
+ (irqtp->preempt_count & ~SOFTIRQ_MASK) |
+ (curtp->preempt_count & SOFTIRQ_MASK);
+
call_handle_irq(irq, desc, irqtp, handler);
irqtp->task = NULL;
+
+
+ /* Set any flag that may have been set on the
+ * alternate stack
+ */
if (irqtp->flags)
set_bits(irqtp->flags, &curtp->flags);
} else
@@ -357,7 +370,7 @@ void irq_ctx_init(void)
memset((void *)softirq_ctx[i], 0, THREAD_SIZE);
tp = softirq_ctx[i];
tp->cpu = i;
- tp->preempt_count = SOFTIRQ_OFFSET;
+ tp->preempt_count = 0;
memset((void *)hardirq_ctx[i], 0, THREAD_SIZE);
tp = hardirq_ctx[i];
^ permalink raw reply
* [PATCH 2/4] [POWERPC] lockdep stacktrace support
From: Benjamin Herrenschmidt @ 2008-04-02 7:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1207122728.672673.111194574046.qpush@grosgo>
From: Christoph Hellwig <hch@lst.de>
I recently tried to work on lockdep for powerpc. I have preliminary
version of the stacktrace code, but had to give up on trace irqflags
support because I'm not that knowledgeable on lowlevel ppc details.
Maybe someone more faimilar with the code wants to give it another try?
My stacktrace code is below:
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/Kconfig | 4 +++
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/stacktrace.c | 52 +++++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+)
--- linux-work.orig/arch/powerpc/Kconfig 2008-04-02 15:46:07.000000000 +1100
+++ linux-work/arch/powerpc/Kconfig 2008-04-02 16:47:46.000000000 +1100
@@ -49,6 +49,10 @@ config IRQ_PER_CPU
bool
default y
+config STACKTRACE_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
Index: linux-work/arch/powerpc/kernel/Makefile
===================================================================
--- linux-work.orig/arch/powerpc/kernel/Makefile 2008-04-02 15:46:07.000000000 +1100
+++ linux-work/arch/powerpc/kernel/Makefile 2008-04-02 16:46:07.000000000 +1100
@@ -67,6 +67,7 @@ obj-$(CONFIG_BOOTX_TEXT) += btext.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
+obj-$(CONFIG_STACKTRACE) += stacktrace.o
pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
Index: linux-work/arch/powerpc/kernel/stacktrace.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-work/arch/powerpc/kernel/stacktrace.c 2008-04-02 16:46:07.000000000 +1100
@@ -0,0 +1,52 @@
+
+#include <linux/sched.h>
+#include <linux/stacktrace.h>
+
+
+#ifdef CONFIG_PPC64
+#define MIN_STACK_FRAME 112 /* same as STACK_FRAME_OVERHEAD, in fact */
+#define FRAME_LR_SAVE 2
+#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD + 288)
+#define REGS_MARKER 0x7265677368657265ul
+#define FRAME_MARKER 12
+#else
+#define MIN_STACK_FRAME 16
+#define FRAME_LR_SAVE 1
+#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD)
+#define REGS_MARKER 0x72656773ul
+#define FRAME_MARKER 2
+#endif
+
+
+/*
+ * Save stack-backtrace addresses into a stack_trace buffer.
+ * If all_contexts is set, all contexts (hardirq, softirq and process)
+ * are saved. If not set then only the current context is saved.
+ */
+void save_stack_trace(struct stack_trace *trace)
+{
+ unsigned long sp;
+
+ asm("mr %0,1" : "=r" (sp));
+
+ for (;;) {
+ unsigned long *stack = (unsigned long *) sp;
+ unsigned long newsp, ip;
+
+ if (!validate_sp(sp, current, MIN_STACK_FRAME))
+ return;
+
+ newsp = stack[0];
+ ip = stack[FRAME_LR_SAVE];
+
+ if (!trace->skip)
+ trace->entries[trace->nr_entries++] = ip;
+ else
+ trace->skip--;
+
+ if (trace->nr_entries >= trace->max_entries)
+ return;
+
+ sp = newsp;
+ }
+}
^ permalink raw reply
* [PATCH 1/4] [POWERPC] Initialize paca->current earlier
From: Benjamin Herrenschmidt @ 2008-04-02 7:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1207122728.672673.111194574046.qpush@grosgo>
Currently, we initialize the "current" pointer in the PACA (which
is used by the "current" macro in the kernel) before calling
setup_system(). That means that early_setup() is called with
current still "NULL" which is -not- a good idea. It happens to
work so far but breaks with lockdep when early code calls printk.
This changes it so that all PACAs are statically initialized with
__current pointing to the init task. For non-0 CPUs, this is fixed
up before use.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/head_64.S | 4 ----
arch/powerpc/kernel/paca.c | 3 ++-
2 files changed, 2 insertions(+), 5 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/head_64.S 2008-04-02 18:20:53.000000000 +1100
+++ linux-work/arch/powerpc/kernel/head_64.S 2008-04-02 18:24:45.000000000 +1100
@@ -1505,10 +1505,6 @@ _INIT_GLOBAL(start_here_common)
li r0,0
stdu r0,-STACK_FRAME_OVERHEAD(r1)
- /* ptr to current */
- LOAD_REG_IMMEDIATE(r4, init_task)
- std r4,PACACURRENT(r13)
-
/* Load the TOC */
ld r2,PACATOC(r13)
std r1,PACAKSAVE(r13)
Index: linux-work/arch/powerpc/kernel/paca.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/paca.c 2008-04-02 18:28:07.000000000 +1100
+++ linux-work/arch/powerpc/kernel/paca.c 2008-04-02 18:28:22.000000000 +1100
@@ -72,7 +72,8 @@ struct slb_shadow slb_shadow[] __cacheli
.paca_index = (number), /* Paca Index */ \
.kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL, \
.hw_cpu_id = 0xffff, \
- .slb_shadow_ptr = &slb_shadow[number],
+ .slb_shadow_ptr = &slb_shadow[number], \
+ .__current = &init_task,
#ifdef CONFIG_PPC_ISERIES
#define PACA_INIT_ISERIES(number) \
^ permalink raw reply
* [PATCH 0/4] [POWERPC] lockdep support for ppc64
From: Benjamin Herrenschmidt @ 2008-04-02 7:52 UTC (permalink / raw)
To: linuxppc-dev
[Not to merge just yet ... almost]
This serie of patches adds lockdep support for 64 bits
powerpc. Dale's patch for 32 bits still need me to review
and test it which I'll try to do asap.
It needs the iSeries hardirq enable fix that I posted
earlier (which is probably 2.6.25 material).
Note that we can already see potential problems exposed
by it. So far on my list:
- something wrong with iseries veth. Haven't got to figure
out what yet, could be a false positive
- possible deadlock with the device-tree rwlock. The one that
I caught with lockdep here is pSeries rtas_set_rtc_time() calls
rtas_token() from softirq, which does on of_find_property(),
which takes the read lock. Other things can call prom_add_propety()
which can take the write lock, while softirqs are enabled -> boom.
Maybe we should forbid OF device-tree access from IRQs and thus
things that need to use rtas_token() will have to cache the token.
^ permalink raw reply
* Re: Xilinx LLTEMAC driver issues
From: Johann Baudy @ 2008-04-02 7:20 UTC (permalink / raw)
To: Magnus Hjorth; +Cc: linuxppc-embedded, John Linn, git
In-Reply-To: <000601c8931f$e1d549a0$a57fdce0$@se>
[-- Attachment #1: Type: text/plain, Size: 31267 bytes --]
I've solved this checksum offloading issue with this below patch.
It may help, if you need performance. It certainly needs review but it works
on my side.
--- xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c.orig 2008-03-21
09:11:43.000000000 +0100
+++ xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c 2008-03-21
09:24:23.000000000 +0100
@@ -133,7 +133,7 @@
(XLlDma_mBdRead((BdPtr), XLLDMA_BD_STSCTRL_USR0_OFFSET)) &
0xFFFFFFFE )
#define BdCsumSetup(BdPtr, Start, Insert) \
- XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, (Start) << 16 |
(Insert))
+ XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, ((Start) << 16) |
(Insert))
/* Used for debugging */
#define BdCsumInsert(BdPtr) \
@@ -1540,7 +1541,7 @@ static int xenet_DmaSend_internal(struct
/*
* if tx checksum offloading is enabled, when the ethernet stack
* wants us to perform the checksum in hardware,
- * skb->ip_summed is CHECKSUM_COMPLETE. Otherwise skb->ip_summed is
+ * skb->ip_summed is CHECKSUM_PARTIAL. Otherwise skb->ip_summed is
* CHECKSUM_NONE, meaning the checksum is already done, or
* CHECKSUM_UNNECESSARY, meaning checksumming is turned off (e.g.
* loopback interface)
@@ -1565,9 +1566,11 @@ static int xenet_DmaSend_internal(struct
* skb_transport_header(skb) points to the beginning of the ip header
*
*/
- if (skb->ip_summed == CHECKSUM_COMPLETE) {
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+
+ unsigned int csum_start_off = skb_transport_offset(skb);
+ unsigned int csum_index_off = csum_start_off + skb->csum_offset;
- unsigned char *raw = skb_transport_header(skb);
#if 0
{
unsigned int csum = _xenet_tx_csum(skb);
@@ -1578,9 +1581,8 @@ static int xenet_DmaSend_internal(struct
}
#else
BdCsumEnable(bd_ptr);
- BdCsumSetup(bd_ptr, raw - skb->data,
- (raw - skb->data) + skb->csum);
-
+ BdCsumSetup(bd_ptr, csum_start_off,
+ csum_index_off);
#endif
lp->tx_hw_csums++;
}
@@ -3277,7 +3279,7 @@ static int __devinit xtenet_of_probe(str
struct resource *r_irq = &r_irq_struct; /* Interrupt resources */
struct resource *r_mem = &r_mem_struct; /* IO mem resources */
struct xlltemac_platform_data *pdata = &pdata_struct;
- void *mac_address;
+ const void *mac_address;
int rc = 0;
const phandle *llink_connected_handle;
struct device_node *llink_connected_node;
On Mon, Mar 31, 2008 at 11:10 AM, Magnus Hjorth <mh@omnisys.se> wrote:
> Deactivating checksum offloading helped a lot! I still have some packet
> loss and not the best performance (TFTP transfer about 100 kbyte/s) but at
> least it works.
>
> Thanks!
>
> //Magnus
>
> > -----Original Message-----
> > From: rza1 [mailto:rza1@so-logic.net]
> > Sent: den 31 mars 2008 11:14
> > To: Magnus Hjorth
> > Cc: John Linn; git; linuxppc-embedded@ozlabs.org
> > Subject: Re: Xilinx LLTEMAC driver issues
> >
> > Hi Magnus,
> >
> > 1.
> > I am using nearly the same versions then you and got the same problems
> > too ;-).
> > I think there are some problems with the checksum offloading.
> > Try to sniff the some packages (e.g. wireshark)...
> > For me ICMP (ping) worked but udp and tcp not (because off a wrong
> > checksum in the transport layer).
> > A quick solution is to just deactivate checksum offloading.
> >
> > 2.
> > I remember some problems with Virtex-4 presamples too.
> > There where problems with the hard-temac wrapper. You had to use 1.00.a
> > and not b version.
> > But I don't have these problems with the EDK 9.2sp2/ISE9.2sp3 anymore.
> >
> > all the best,
> > Robert
> >
> > Magnus Hjorth wrote:
> > > Hi John,
> > >
> > > Thanks for the very fast reply! Right now I'm not at work so I don't
> > > have the board or EDK here to test anything.
> > >
> > > I'm using checksum offload, but I don't know if DRE is enabled or not.
> I
> > > can't recall seeing any setting to enable/disable DRE..
> > >
> > > A few things that crossed my mind:
> > >
> > > Last year I did a design with EDK 8.2, back then there was an issue
> with
> > > the ML403 boards having an old revision of the FPGA which wasn't
> > > compatible with some versions of the IP core. There are no such
> version
> > > issues with the xps_ll_temac?
> > >
> > > I don't think that I had phy-addr set in the DTS file. Will test that
> on
> > > Monday.
> > >
> > > Best regards,
> > > Magnus
> > >
> > >
> > > On Sat, 2008-03-29 at 07:58 -0600, John Linn wrote:
> > >
> > >> Hi Magnus,
> > >>
> > >> Sorry to hear you're having problems with it.
> > >>
> > >> I am doing testing on an ML405 which is the same board but with a
> bigger
> > FPGA, but with ppc arch and I don't see this issue. I have done limited
> testing
> > with powerpc arch and the LL TEMAC, but I didn't see this issue there
> either.
> > Powerpc arch is definitely less mature in my experience than the ppc
> arch. I'll
> > do a quick test with my powerpc arch and make sure again I'm not seeing
> it.
> > >>
> > >> My kernel is from the Xilinx Git tree, but there have been a number
> of
> > changes we have pushed out so I don't know how long ago you pulled from
> the Git
> > tree.
> > >>
> > >> My EDK project is 10.1 so it's a little newer. I am using LL TEMAC
> 1.01a so
> > it's a little newer. I reviewed the change log for the LL TEMAC and
> don't see
> > any big problems that were fixed in the newer versions, more new
> features. I'll
> > check with some others here to see if I missed something there.
> > >>
> > >> I am using DMA also, but no DRE or checksum offload. You didn't say
> anything
> > about those. I'm going to insert my mhs file that describes my system to
> let you
> > compare your system configuration. It's not clear to me yet if you have
> a h/w or
> > s/w problem.
> > >>
> > >> I'll also insert some of my device tree with the LL TEMAC so you can
> compare
> > (ignore 16550 stuff as we are still working on that).
> > >>
> > >> Since you can't ping reliably I would probably focus on that since
> it's
> > simpler than the other issues you're seeing.
> > >>
> > >> Thanks,
> > >> John
> > >>
> > >>
> > >>
> > >> #
> >
> ##############################################################################
> > >> # Created by Base System Builder Wizard for Xilinx EDK 10.1.1 Build
> > EDK_K_SP1.1
> > >> # Thu Feb 14 14:11:12 2008
> > >> # Target Board: Xilinx Virtex 4 ML405 Evaluation Platform Rev 1
> > >> # Family: virtex4
> > >> # Device: xc4vfx20
> > >> # Package: ff672
> > >> # Speed Grade: -10
> > >> # Processor: ppc405_0
> > >> # Processor clock frequency: 300.00 MHz
> > >> # Bus clock frequency: 100.00 MHz
> > >> # On Chip Memory : 8 KB
> > >> # Total Off Chip Memory : 128 MB
> > >> # - DDR_SDRAM = 128 MB
> > >> #
> >
> ##############################################################################
> > >> PARAMETER VERSION = 2.1.0
> > >>
> > >>
> > >> PORT fpga_0_RS232_Uart_sin_pin = fpga_0_RS232_Uart_sin, DIR = I
> > >> PORT fpga_0_RS232_Uart_sout_pin = fpga_0_RS232_Uart_sout, DIR = O
> > >> PORT fpga_0_LEDs_4Bit_GPIO_IO_pin = fpga_0_LEDs_4Bit_GPIO_IO, DIR =
> IO, VEC
> > = [0:3]
> > >> PORT fpga_0_IIC_EEPROM_Scl_pin = fpga_0_IIC_EEPROM_Scl, DIR = IO
> > >> PORT fpga_0_IIC_EEPROM_Sda_pin = fpga_0_IIC_EEPROM_Sda, DIR = IO
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CLK_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_CLK, DIR = I
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPA_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_MPA, DIR = O, VEC = [6:1]
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPD_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_MPD, DIR = IO, VEC = [15:0]
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CEN_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_CEN, DIR = O
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_OEN_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_OEN, DIR = O
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_WEN_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_WEN, DIR = O
> > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPIRQ_pin =
> > fpga_0_SysACE_CompactFlash_SysACE_MPIRQ, DIR = I
> > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_pin = fpga_0_DDR_SDRAM_DDR_Clk, DIR =
> O
> > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_n_pin = fpga_0_DDR_SDRAM_DDR_Clk_n,
> DIR = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_Addr_pin = fpga_0_DDR_SDRAM_DDR_Addr, DIR
> = O, VEC
> > = [12:0]
> > >> PORT fpga_0_DDR_SDRAM_DDR_BankAddr_pin =
> fpga_0_DDR_SDRAM_DDR_BankAddr, DIR
> > = O, VEC = [1:0]
> > >> PORT fpga_0_DDR_SDRAM_DDR_CAS_n_pin = fpga_0_DDR_SDRAM_DDR_CAS_n,
> DIR = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_CE_pin = fpga_0_DDR_SDRAM_DDR_CE, DIR = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_CS_n_pin = fpga_0_DDR_SDRAM_DDR_CS_n, DIR
> = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_RAS_n_pin = fpga_0_DDR_SDRAM_DDR_RAS_n,
> DIR = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_WE_n_pin = fpga_0_DDR_SDRAM_DDR_WE_n, DIR
> = O
> > >> PORT fpga_0_DDR_SDRAM_DDR_DM_pin = fpga_0_DDR_SDRAM_DDR_DM, DIR = O,
> VEC =
> > [3:0]
> > >> PORT fpga_0_DDR_SDRAM_DDR_DQS = fpga_0_DDR_SDRAM_DDR_DQS, DIR = IO,
> VEC =
> > [3:0]
> > >> PORT fpga_0_DDR_SDRAM_DDR_DQ = fpga_0_DDR_SDRAM_DDR_DQ, DIR = IO,
> VEC =
> > [31:0]
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TXD_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_TXD_0, DIR = O, VEC = [7:0]
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0, DIR = O
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0, DIR = O
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0, DIR = O
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RXD_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_RXD_0, DIR = I, VEC = [7:0]
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0, DIR = I
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0, DIR = I
> > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0_pin =
> > fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0, DIR = I
> > >> PORT fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0_pin =
> > fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0, DIR = I
> > >> PORT fpga_0_TriMode_MAC_GMII_MDIO_0_pin =
> fpga_0_TriMode_MAC_GMII_MDIO_0,
> > DIR = IO
> > >> PORT fpga_0_TriMode_MAC_GMII_MDC_0_pin =
> fpga_0_TriMode_MAC_GMII_MDC_0, DIR
> > = O
> > >> PORT fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n_pin =
> > fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n, DIR = O
> > >> PORT sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = CLK, CLK_FREQ =
> 100000000
> > >> PORT sys_rst_pin = sys_rst_s, DIR = I, RST_POLARITY = 0, SIGIS = RST
> > >>
> > >>
> > >> BEGIN ppc405_virtex4
> > >> PARAMETER INSTANCE = ppc405_0
> > >> PARAMETER HW_VER = 2.01.a
> > >> PARAMETER C_FASTEST_PLB_CLOCK = DPLB1
> > >> PARAMETER C_IDCR_BASEADDR = 0b0100000000
> > >> PARAMETER C_IDCR_HIGHADDR = 0b0111111111
> > >> BUS_INTERFACE JTAGPPC = jtagppc_0_0
> > >> BUS_INTERFACE IPLB0 = plb
> > >> BUS_INTERFACE DPLB0 = plb
> > >> BUS_INTERFACE IPLB1 = ppc405_0_iplb1
> > >> BUS_INTERFACE DPLB1 = ppc405_0_dplb1
> > >> BUS_INTERFACE RESETPPC = ppc_reset_bus
> > >> PORT CPMC405CLOCK = proc_clk_s
> > >> PORT EICC405EXTINPUTIRQ = EICC405EXTINPUTIRQ
> > >> END
> > >>
> > >> BEGIN jtagppc_cntlr
> > >> PARAMETER INSTANCE = jtagppc_0
> > >> PARAMETER HW_VER = 2.01.a
> > >> BUS_INTERFACE JTAGPPC0 = jtagppc_0_0
> > >> END
> > >>
> > >> BEGIN plb_v46
> > >> PARAMETER INSTANCE = plb
> > >> PARAMETER C_DCR_INTFCE = 0
> > >> PARAMETER C_NUM_CLK_PLB2OPB_REARB = 100
> > >> PARAMETER HW_VER = 1.02.a
> > >> PORT PLB_Clk = sys_clk_s
> > >> PORT SYS_Rst = sys_bus_reset
> > >> END
> > >>
> > >> BEGIN xps_bram_if_cntlr
> > >> PARAMETER INSTANCE = xps_bram_if_cntlr_1
> > >> PARAMETER HW_VER = 1.00.a
> > >> PARAMETER C_SPLB_NATIVE_DWIDTH = 64
> > >> PARAMETER C_BASEADDR = 0xffffe000
> > >> PARAMETER C_HIGHADDR = 0xffffffff
> > >> BUS_INTERFACE SPLB = plb
> > >> BUS_INTERFACE PORTA = xps_bram_if_cntlr_1_port
> > >> END
> > >>
> > >> BEGIN bram_block
> > >> PARAMETER INSTANCE = plb_bram_if_cntlr_1_bram
> > >> PARAMETER HW_VER = 1.00.a
> > >> BUS_INTERFACE PORTA = xps_bram_if_cntlr_1_port
> > >> END
> > >>
> > >> BEGIN xps_uart16550
> > >> PARAMETER INSTANCE = RS232_Uart
> > >> PARAMETER HW_VER = 2.00.a
> > >> PARAMETER C_IS_A_16550 = 1
> > >> PARAMETER C_BASEADDR = 0x83e00000
> > >> PARAMETER C_HIGHADDR = 0x83e0ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> PORT sin = fpga_0_RS232_Uart_sin
> > >> PORT sout = fpga_0_RS232_Uart_sout
> > >> PORT IP2INTC_Irpt = RS232_Uart_IP2INTC_Irpt
> > >> END
> > >>
> > >> BEGIN xps_gpio
> > >> PARAMETER INSTANCE = LEDs_4Bit
> > >> PARAMETER HW_VER = 1.00.a
> > >> PARAMETER C_INTERRUPT_PRESENT = 1
> > >> PARAMETER C_GPIO_WIDTH = 4
> > >> PARAMETER C_IS_DUAL = 0
> > >> PARAMETER C_IS_BIDIR = 1
> > >> PARAMETER C_ALL_INPUTS = 0
> > >> PARAMETER C_BASEADDR = 0x81400000
> > >> PARAMETER C_HIGHADDR = 0x8140ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> PORT GPIO_IO = fpga_0_LEDs_4Bit_GPIO_IO
> > >> PORT IP2INTC_Irpt = LEDs_4Bit_IP2INTC_Irpt
> > >> END
> > >>
> > >> BEGIN xps_iic
> > >> PARAMETER INSTANCE = IIC_EEPROM
> > >> PARAMETER HW_VER = 2.00.a
> > >> PARAMETER C_CLK_FREQ = 100000000
> > >> PARAMETER C_IIC_FREQ = 100000
> > >> PARAMETER C_TEN_BIT_ADR = 0
> > >> PARAMETER C_BASEADDR = 0x81600000
> > >> PARAMETER C_HIGHADDR = 0x8160ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> PORT Scl = fpga_0_IIC_EEPROM_Scl
> > >> PORT Sda = fpga_0_IIC_EEPROM_Sda
> > >> PORT IIC2INTC_Irpt = IIC_EEPROM_IIC2INTC_Irpt
> > >> END
> > >>
> > >> BEGIN xps_sysace
> > >> PARAMETER INSTANCE = SysACE_CompactFlash
> > >> PARAMETER HW_VER = 1.00.a
> > >> PARAMETER C_MEM_WIDTH = 16
> > >> PARAMETER C_BASEADDR = 0x83600000
> > >> PARAMETER C_HIGHADDR = 0x8360ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> PORT SysACE_CLK = fpga_0_SysACE_CompactFlash_SysACE_CLK
> > >> PORT SysACE_MPA = fpga_0_SysACE_CompactFlash_SysACE_MPA_split
> > >> PORT SysACE_MPD = fpga_0_SysACE_CompactFlash_SysACE_MPD
> > >> PORT SysACE_CEN = fpga_0_SysACE_CompactFlash_SysACE_CEN
> > >> PORT SysACE_OEN = fpga_0_SysACE_CompactFlash_SysACE_OEN
> > >> PORT SysACE_WEN = fpga_0_SysACE_CompactFlash_SysACE_WEN
> > >> PORT SysACE_MPIRQ = fpga_0_SysACE_CompactFlash_SysACE_MPIRQ
> > >> PORT SysACE_IRQ = SysACE_CompactFlash_SysACE_IRQ
> > >> END
> > >>
> > >> BEGIN mpmc
> > >> PARAMETER INSTANCE = DDR_SDRAM
> > >> PARAMETER HW_VER = 4.00.a
> > >> PARAMETER C_NUM_PORTS = 3
> > >> PARAMETER C_MEM_PARTNO = HYB25D512160BE-5
> > >> PARAMETER C_MEM_DATA_WIDTH = 32
> > >> PARAMETER C_MEM_DQS_WIDTH = 4
> > >> PARAMETER C_MEM_DM_WIDTH = 4
> > >> PARAMETER C_MEM_TYPE = DDR
> > >> PARAMETER C_NUM_IDELAYCTRL = 2
> > >> PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X0Y3-IDELAYCTRL_X0Y2
> > >> PARAMETER C_PIM0_BASETYPE = 2
> > >> PARAMETER C_PIM1_BASETYPE = 2
> > >> PARAMETER C_PIM2_BASETYPE = 3
> > >> PARAMETER C_MPMC_CLK0_PERIOD_PS = 10000
> > >> PARAMETER C_SDMA2_PI2LL_CLK_RATIO = 1
> > >> PARAMETER C_MPMC_BASEADDR = 0x00000000
> > >> PARAMETER C_MPMC_HIGHADDR = 0x07ffffff
> > >> PARAMETER C_SDMA_CTRL_BASEADDR = 0x84600000
> > >> PARAMETER C_SDMA_CTRL_HIGHADDR = 0x8460ffff
> > >> BUS_INTERFACE SPLB0 = ppc405_0_iplb1
> > >> BUS_INTERFACE SPLB1 = ppc405_0_dplb1
> > >> BUS_INTERFACE SDMA_LL2 = TriMode_MAC_GMII_LLINK0
> > >> BUS_INTERFACE SDMA_CTRL2 = plb
> > >> PORT DDR_Addr = fpga_0_DDR_SDRAM_DDR_Addr
> > >> PORT DDR_BankAddr = fpga_0_DDR_SDRAM_DDR_BankAddr
> > >> PORT DDR_CAS_n = fpga_0_DDR_SDRAM_DDR_CAS_n
> > >> PORT DDR_CE = fpga_0_DDR_SDRAM_DDR_CE
> > >> PORT DDR_CS_n = fpga_0_DDR_SDRAM_DDR_CS_n
> > >> PORT DDR_RAS_n = fpga_0_DDR_SDRAM_DDR_RAS_n
> > >> PORT DDR_WE_n = fpga_0_DDR_SDRAM_DDR_WE_n
> > >> PORT DDR_DM = fpga_0_DDR_SDRAM_DDR_DM
> > >> PORT DDR_DQS = fpga_0_DDR_SDRAM_DDR_DQS
> > >> PORT DDR_DQ = fpga_0_DDR_SDRAM_DDR_DQ
> > >> PORT DDR_Clk = fpga_0_DDR_SDRAM_DDR_Clk
> > >> PORT DDR_Clk_n = fpga_0_DDR_SDRAM_DDR_Clk_n
> > >> PORT MPMC_Clk0 = sys_clk_s
> > >> PORT MPMC_Clk90 = DDR_SDRAM_mpmc_clk_90_s
> > >> PORT SDMA2_Clk = sys_clk_s
> > >> PORT MPMC_Clk_200MHz = clk_200mhz_s
> > >> PORT MPMC_Rst = sys_periph_reset
> > >> PORT SDMA2_Rx_IntOut = DDR_SDRAM_SDMA2_Rx_IntOut
> > >> PORT SDMA2_Tx_IntOut = DDR_SDRAM_SDMA2_Tx_IntOut
> > >> END
> > >>
> > >> BEGIN xps_ll_temac
> > >> PARAMETER INSTANCE = TriMode_MAC_GMII
> > >> PARAMETER HW_VER = 1.01.a
> > >> PARAMETER C_SPLB_CLK_PERIOD_PS = 10000
> > >> PARAMETER C_PHY_TYPE = 1
> > >> PARAMETER C_NUM_IDELAYCTRL = 4
> > >> PARAMETER C_IDELAYCTRL_LOC = IDELAYCTRL_X1Y1-IDELAYCTRL_X1Y3-
> > IDELAYCTRL_X2Y2-IDELAYCTRL_X2Y3
> > >> PARAMETER C_TEMAC_TYPE = 1
> > >> PARAMETER C_BUS2CORE_CLK_RATIO = 1
> > >> PARAMETER C_BASEADDR = 0x81c00000
> > >> PARAMETER C_HIGHADDR = 0x81c0ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> BUS_INTERFACE LLINK0 = TriMode_MAC_GMII_LLINK0
> > >> PORT GMII_TXD_0 = fpga_0_TriMode_MAC_GMII_GMII_TXD_0
> > >> PORT GMII_TX_EN_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0
> > >> PORT GMII_TX_ER_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0
> > >> PORT GMII_TX_CLK_0 = fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0
> > >> PORT GMII_RXD_0 = fpga_0_TriMode_MAC_GMII_GMII_RXD_0
> > >> PORT GMII_RX_DV_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0
> > >> PORT GMII_RX_ER_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0
> > >> PORT GMII_RX_CLK_0 = fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0
> > >> PORT MII_TX_CLK_0 = fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0
> > >> PORT MDIO_0 = fpga_0_TriMode_MAC_GMII_MDIO_0
> > >> PORT MDC_0 = fpga_0_TriMode_MAC_GMII_MDC_0
> > >> PORT TemacPhy_RST_n = fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n
> > >> PORT GTX_CLK_0 = temac_clk_s
> > >> PORT REFCLK = clk_200mhz_s
> > >> PORT LlinkTemac0_CLK = sys_clk_s
> > >> PORT TemacIntc0_Irpt = TriMode_MAC_GMII_TemacIntc0_Irpt
> > >> END
> > >>
> > >> BEGIN util_bus_split
> > >> PARAMETER INSTANCE = SysACE_CompactFlash_util_bus_split_0
> > >> PARAMETER HW_VER = 1.00.a
> > >> PARAMETER C_SIZE_IN = 7
> > >> PARAMETER C_LEFT_POS = 0
> > >> PARAMETER C_SPLIT = 6
> > >> PORT Sig = fpga_0_SysACE_CompactFlash_SysACE_MPA_split
> > >> PORT Out1 = fpga_0_SysACE_CompactFlash_SysACE_MPA
> > >> END
> > >>
> > >> BEGIN plb_v46
> > >> PARAMETER INSTANCE = ppc405_0_iplb1
> > >> PARAMETER HW_VER = 1.02.a
> > >> PORT PLB_Clk = sys_clk_s
> > >> PORT SYS_Rst = sys_bus_reset
> > >> END
> > >>
> > >> BEGIN plb_v46
> > >> PARAMETER INSTANCE = ppc405_0_dplb1
> > >> PARAMETER HW_VER = 1.02.a
> > >> PORT PLB_Clk = sys_clk_s
> > >> PORT SYS_Rst = sys_bus_reset
> > >> END
> > >>
> > >> BEGIN clock_generator
> > >> PARAMETER INSTANCE = clock_generator_0
> > >> PARAMETER HW_VER = 2.00.a
> > >> PARAMETER C_EXT_RESET_HIGH = 1
> > >> PARAMETER C_CLKIN_FREQ = 100000000
> > >> PARAMETER C_CLKOUT0_FREQ = 100000000
> > >> PARAMETER C_CLKOUT0_BUF = TRUE
> > >> PARAMETER C_CLKOUT0_PHASE = 0
> > >> PARAMETER C_CLKOUT0_GROUP = DCM0
> > >> PARAMETER C_CLKOUT1_FREQ = 100000000
> > >> PARAMETER C_CLKOUT1_BUF = TRUE
> > >> PARAMETER C_CLKOUT1_PHASE = 90
> > >> PARAMETER C_CLKOUT1_GROUP = DCM0
> > >> PARAMETER C_CLKOUT2_FREQ = 300000000
> > >> PARAMETER C_CLKOUT2_BUF = TRUE
> > >> PARAMETER C_CLKOUT2_PHASE = 0
> > >> PARAMETER C_CLKOUT2_GROUP = DCM0
> > >> PARAMETER C_CLKOUT3_FREQ = 200000000
> > >> PARAMETER C_CLKOUT3_BUF = TRUE
> > >> PARAMETER C_CLKOUT3_PHASE = 0
> > >> PARAMETER C_CLKOUT3_GROUP = NONE
> > >> PARAMETER C_CLKOUT4_FREQ = 125000000
> > >> PARAMETER C_CLKOUT4_BUF = TRUE
> > >> PARAMETER C_CLKOUT4_PHASE = 0
> > >> PARAMETER C_CLKOUT4_GROUP = NONE
> > >> PORT CLKOUT0 = sys_clk_s
> > >> PORT CLKOUT1 = DDR_SDRAM_mpmc_clk_90_s
> > >> PORT CLKOUT2 = proc_clk_s
> > >> PORT CLKOUT3 = clk_200mhz_s
> > >> PORT CLKOUT4 = temac_clk_s
> > >> PORT CLKIN = dcm_clk_s
> > >> PORT LOCKED = Dcm_all_locked
> > >> PORT RST = net_gnd
> > >> END
> > >>
> > >> BEGIN proc_sys_reset
> > >> PARAMETER INSTANCE = proc_sys_reset_0
> > >> PARAMETER HW_VER = 2.00.a
> > >> PARAMETER C_EXT_RESET_HIGH = 0
> > >> BUS_INTERFACE RESETPPC0 = ppc_reset_bus
> > >> PORT Slowest_sync_clk = sys_clk_s
> > >> PORT Dcm_locked = Dcm_all_locked
> > >> PORT Ext_Reset_In = sys_rst_s
> > >> PORT Bus_Struct_Reset = sys_bus_reset
> > >> PORT Peripheral_Reset = sys_periph_reset
> > >> END
> > >>
> > >> BEGIN xps_intc
> > >> PARAMETER INSTANCE = xps_intc_0
> > >> PARAMETER HW_VER = 1.00.a
> > >> PARAMETER C_BASEADDR = 0x81800000
> > >> PARAMETER C_HIGHADDR = 0x8180ffff
> > >> BUS_INTERFACE SPLB = plb
> > >> PORT Irq = EICC405EXTINPUTIRQ
> > >> PORT Intr = RS232_Uart_IP2INTC_Irpt & LEDs_4Bit_IP2INTC_Irpt &
> > IIC_EEPROM_IIC2INTC_Irpt & SysACE_CompactFlash_SysACE_IRQ &
> > TriMode_MAC_GMII_TemacIntc0_Irpt & DDR_SDRAM_SDMA2_Rx_IntOut &
> > DDR_SDRAM_SDMA2_Tx_IntOut
> > >> END
> > >>
> > >>
> > >>
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> compatible = "xlnx,virtex";
> > >> model = "testing";
> > >> DDR_SDRAM: memory@0 {
> > >> device_type = "memory";
> > >> reg = < 0 8000000 >;
> > >> } ;
> > >> chosen {
> > >> bootargs = "console=ttyS0,9600 ip=on
> > nfsroot=172.16.40.76:/v2pclients/jhl26,tcp";
> > >> linux,stdout-path = "/plb@0/serial@83e00000";
> > >> } ;
> > >> cpus {
> > >> #address-cells = <1>;
> > >> #cpus = <1>;
> > >> #size-cells = <0>;
> > >> ppc405_0: cpu@0 {
> > >> clock-frequency = <11e1a300>;
> > >> compatible = "PowerPC,405", "ibm,ppc405";
> > >> d-cache-line-size = <20>;
> > >> d-cache-size = <4000>;
> > >> device_type = "cpu";
> > >> i-cache-line-size = <20>;
> > >> i-cache-size = <4000>;
> > >> model = "PowerPC,405";
> > >> reg = <0>;
> > >> timebase-frequency = <11e1a300>;
> > >> xlnx,apu-control = <de00>;
> > >> xlnx,apu-udi-1 = <a18983>;
> > >> xlnx,apu-udi-2 = <a38983>;
> > >> xlnx,apu-udi-3 = <a589c3>;
> > >> xlnx,apu-udi-4 = <a789c3>;
> > >> xlnx,apu-udi-5 = <a98c03>;
> > >> xlnx,apu-udi-6 = <ab8c03>;
> > >> xlnx,apu-udi-7 = <ad8c43>;
> > >> xlnx,apu-udi-8 = <af8c43>;
> > >> xlnx,deterministic-mult = <0>;
> > >> xlnx,disable-operand-forwarding = <1>;
> > >> xlnx,fastest-plb-clock = "DPLB0";
> > >> xlnx,generate-plb-timespecs = <1>;
> > >> xlnx,mmu-enable = <1>;
> > >> xlnx,pvr-high = <0>;
> > >> xlnx,pvr-low = <0>;
> > >> } ;
> > >> } ;
> > >> plb: plb@0 {
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> compatible = "xlnx,plb-v46-1.02.a";
> > >> ranges ;
> > >> IIC_EEPROM: i2c@81600000 {
> > >> compatible = "xlnx,xps-iic-2.00.a";
> > >> interrupt-parent = <&xps_intc_0>;
> > >> interrupts = < 4 2 >;
> > >> reg = < 81600000 10000 >;
> > >> xlnx,clk-freq = <5f5e100>;
> > >> xlnx,family = "virtex4";
> > >> xlnx,gpo-width = <1>;
> > >> xlnx,iic-freq = <186a0>;
> > >> xlnx,scl-inertial-delay = <0>;
> > >> xlnx,sda-inertial-delay = <0>;
> > >> xlnx,ten-bit-adr = <0>;
> > >> } ;
> > >> LEDs_4Bit: gpio@81400000 {
> > >> compatible = "xlnx,xps-gpio-1.00.a";
> > >> interrupt-parent = <&xps_intc_0>;
> > >> interrupts = < 5 2 >;
> > >> reg = < 81400000 10000 >;
> > >> xlnx,all-inputs = <0>;
> > >> xlnx,all-inputs-2 = <0>;
> > >> xlnx,dout-default = <0>;
> > >> xlnx,dout-default-2 = <0>;
> > >> xlnx,family = "virtex4";
> > >> xlnx,gpio-width = <4>;
> > >> xlnx,interrupt-present = <1>;
> > >> xlnx,is-bidir = <1>;
> > >> xlnx,is-bidir-2 = <1>;
> > >> xlnx,is-dual = <0>;
> > >> xlnx,tri-default = <ffffffff>;
> > >> xlnx,tri-default-2 = <ffffffff>;
> > >> } ;
> > >> RS232_Uart: serial@83e00000 {
> > >> compatible = "xlnx,xps-uart16550-2.00.a";
> > >> // compatible = "ns16550";
> > >> device_type = "serial";
> > >> interrupt-parent = <&xps_intc_0>;
> > >> interrupts = < 6 2 >;
> > >> reg = < 83e00000 10000 >;
> > >> current-speed = <d#9600>;
> > >> clock-frequency = <d#100000000>; /* added
> > by jhl */
> > >> reg-shift = <2>;
> > >> xlnx,family = "virtex4";
> > >> xlnx,has-external-rclk = <0>;
> > >> xlnx,has-external-xin = <0>;
> > >> xlnx,is-a-16550 = <1>;
> > >> } ;
> > >> SysACE_CompactFlash: sysace@83600000 {
> > >> compatible = "xlnx,xps-sysace-1.00.a";
> > >> interrupt-parent = <&xps_intc_0>;
> > >> interrupts = < 3 2 >;
> > >> reg = < 83600000 10000 >;
> > >> xlnx,family = "virtex4";
> > >> xlnx,mem-width = <10>;
> > >> } ;
> > >> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> compatible = "xlnx,compound";
> > >> ethernet@81c00000 {
> > >> compatible = "xlnx,xps-ll-temac-
> > 1.01.a";
> > >> device_type = "network";
> > >> interrupt-parent =
> > <&xps_intc_0>;
> > >> interrupts = < 2 2 >;
> > >> llink-connected = <&PIM2>;
> > >> local-mac-address = [ 02 00 00
> > 00 00 01 ];
> > >> reg = < 81c00000 40 >;
> > >> xlnx,bus2core-clk-ratio = <1>;
> > >> xlnx,phy-type = <1>;
> > >> xlnx,phyaddr = <1>;
> > >> xlnx,rxcsum = <0>;
> > >> xlnx,rxfifo = <1000>;
> > >> xlnx,temac-type = <1>;
> > >> xlnx,txcsum = <0>;
> > >> xlnx,txfifo = <1000>;
> > >> } ;
> > >> } ;
> > >> mpmc@0 {
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> compatible = "xlnx,mpmc-4.00.a";
> > >> PIM2: sdma@84600100 {
> > >> compatible = "xlnx,ll-dma-
> > 1.00.a";
> > >> interrupt-parent =
> > <&xps_intc_0>;
> > >> interrupts = < 1 2 0 2 >;
> > >> reg = < 84600100 80 >;
> > >> } ;
> > >> } ;
> > >> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
> > >> compatible = "xlnx,xps-bram-if-cntlr-
> > 1.00.a";
> > >> reg = < ffffe000 2000 >;
> > >> xlnx,family = "virtex4";
> > >> } ;
> > >> xps_intc_0: interrupt-controller@81800000 {
> > >> #interrupt-cells = <2>;
> > >> compatible = "xlnx,xps-intc-1.00.a";
> > >> interrupt-controller ;
> > >> reg = < 81800000 10000 >;
> > >> xlnx,num-intr-inputs = <7>;
> > >> } ;
> > >> } ;
> > >> ppc405_0_dplb1: plb@1 {
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> compatible = "xlnx,plb-v46-1.02.a";
> > >> ranges ;
> > >> } ;
> > >> } ;
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Magnus Hjorth [mailto:mh@omnisys.se]
> > >> Sent: Saturday, March 29, 2008 6:54 AM
> > >> To: git
> > >> Cc: linuxppc-embedded@ozlabs.org
> > >> Subject: Xilinx LLTEMAC driver issues
> > >>
> > >> Hi,
> > >>
> > >> I'm having some networking troubles with the Xilinx LLTEMAC driver
> from the
> > >> Xilinx Linux git tree (powerpc arch) on an ML403 board. EDK9.2SP2,
> > >> xps_ll_temac v1.00.b
> > >>
> > >> The weird thing is, that it sort of half works. It successfully makes
> a DHCP
> > >> request and gets its IP address. I tried setting up a tftpd server,
> and I can
> > >> see UDP requests coming in but the response doesn't seem to come out.
> I also
> > >> tried running a TCP server on the board, and it can see and accept
> incoming
> > >> connections but after that no data seems to get through. I can ping
> out and
> > >> get around 40% packet loss.
> > >>
> > >> Looking at /proc/interrupts, I can see both TxDma interrupts and
> RxDma
> > >> interrupts. No eth0 interrupts but that seems to be OK judging by the
> driver
> > >> source comments. Ifconfig shows no collistions, no dropped packets,
> no
> > errors,
> > >> so the system seems to think that everything is OK.
> > >>
> > >> Clues anyone? I'm starting to run out of ideas...
> > >>
> > >> Best regards,
> > >> Magnus
> > >>
> > >>
> > >> --
> > >>
> > >> Magnus Hjorth, M.Sc.
> > >> Omnisys Instruments AB
> > >> Gruvgatan 8
> > >> SE-421 30 Västra Frölunda, SWEDEN
> > >> Phone: +46 31 734 34 09
> > >> Fax: +46 31 734 34 29
> > >> http://www.omnisys.se
> > >>
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Johann Baudy
johaahn@gmail.com
[-- Attachment #2: Type: text/html, Size: 49288 bytes --]
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Michael Ellerman @ 2008-04-02 7:17 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linuxppc-dev, Andrew Morton, Badari Pulavarty, linux-kernel,
Balbir Singh
In-Reply-To: <47F330FF.3050806@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4590 bytes --]
On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> Andrew Morton wrote:
> > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >
> >> Hi Andrew,
> >>
> >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> >>
> >> [ 0.000000] ------------[ cut here ]------------
> >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> >> [ 0.000000] Modules linked in:
> >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> >> [ 0.000000] Call Trace:
> >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> >> [ 0.000000] Instruction dump:
> >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >>
> >
> > int __meminit vmemmap_populate(struct page *start_page,
> > unsigned long nr_pages, int node)
> > {
> > unsigned long mode_rw;
> > unsigned long start = (unsigned long)start_page;
> > unsigned long end = (unsigned long)(start_page + nr_pages);
> > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> >
> > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> >
> > /* Align to the page size of the linear mapping. */
> > start = _ALIGN_DOWN(start, page_size);
> >
> > for (; start < end; start += page_size) {
> > int mapped;
> > void *p;
> >
> > if (vmemmap_populated(start, page_size))
> > continue;
> >
> > p = vmemmap_alloc_block(page_size, node);
> > if (!p)
> > return -ENOMEM;
> >
> > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > start, p, __pa(p));
> >
> > mapped = htab_bolt_mapping(start, start + page_size,
> > __pa(p), mode_rw, mmu_linear_psize,
> > mmu_kernel_ssize);
> > =====> BUG_ON(mapped < 0);
> > }
> >
> > return 0;
> > }
> >
> > Beats me. pseries? Badari has been diddling with the bolted memory code
> > in git-powerpc...
>
> One of the machines is the Power5 and another is PowerMac G5, on which the
> same kernel panic is seen.
Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
should show what's happening in hpte_insert().
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Kamalesh Babulal @ 2008-04-02 7:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Balbir Singh, Badari Pulavarty, linux-kernel
In-Reply-To: <20080401233909.23220623.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>> Hi Andrew,
>>
>> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
>>
>> [ 0.000000] ------------[ cut here ]------------
>> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
>> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
>> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
>> [ 0.000000] Modules linked in:
>> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
>> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
>> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
>> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
>> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
>> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
>> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
>> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
>> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
>> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
>> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
>> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
>> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
>> [ 0.000000] Call Trace:
>> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
>> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
>> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
>> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
>> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
>> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
>> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
>> [ 0.000000] Instruction dump:
>> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
>> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
>> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
>> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>
>
> int __meminit vmemmap_populate(struct page *start_page,
> unsigned long nr_pages, int node)
> {
> unsigned long mode_rw;
> unsigned long start = (unsigned long)start_page;
> unsigned long end = (unsigned long)(start_page + nr_pages);
> unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
>
> mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
>
> /* Align to the page size of the linear mapping. */
> start = _ALIGN_DOWN(start, page_size);
>
> for (; start < end; start += page_size) {
> int mapped;
> void *p;
>
> if (vmemmap_populated(start, page_size))
> continue;
>
> p = vmemmap_alloc_block(page_size, node);
> if (!p)
> return -ENOMEM;
>
> pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> start, p, __pa(p));
>
> mapped = htab_bolt_mapping(start, start + page_size,
> __pa(p), mode_rw, mmu_linear_psize,
> mmu_kernel_ssize);
> =====> BUG_ON(mapped < 0);
> }
>
> return 0;
> }
>
> Beats me. pseries? Badari has been diddling with the bolted memory code
> in git-powerpc...
One of the machines is the Power5 and another is PowerMac G5, on which the
same kernel panic is seen.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Andrew Morton @ 2008-04-02 6:39 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: Badari, linux-kernel, linuxppc-dev, Pulavarty, Balbir Singh
In-Reply-To: <47F326E0.3010604@linux.vnet.ibm.com>
On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Hi Andrew,
>
> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
>
> [ 0.000000] ------------[ cut here ]------------
> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> [ 0.000000] Modules linked in:
> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> [ 0.000000] Call Trace:
> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> [ 0.000000] Instruction dump:
> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>
int __meminit vmemmap_populate(struct page *start_page,
unsigned long nr_pages, int node)
{
unsigned long mode_rw;
unsigned long start = (unsigned long)start_page;
unsigned long end = (unsigned long)(start_page + nr_pages);
unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
/* Align to the page size of the linear mapping. */
start = _ALIGN_DOWN(start, page_size);
for (; start < end; start += page_size) {
int mapped;
void *p;
if (vmemmap_populated(start, page_size))
continue;
p = vmemmap_alloc_block(page_size, node);
if (!p)
return -ENOMEM;
pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
start, p, __pa(p));
mapped = htab_bolt_mapping(start, start + page_size,
__pa(p), mode_rw, mmu_linear_psize,
mmu_kernel_ssize);
=====> BUG_ON(mapped < 0);
}
return 0;
}
Beats me. pseries? Badari has been diddling with the bolted memory code
in git-powerpc...
^ permalink raw reply
* [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Kamalesh Babulal @ 2008-04-02 6:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Balbir Singh, linux-kernel
In-Reply-To: <20080401213214.8fbb6d6b.akpm@linux-foundation.org>
Hi Andrew,
The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
[ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
[ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
[ 0.000000] Modules linked in:
[ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
[ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
[ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
[ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
[ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
[ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
[ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
[ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
[ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
[ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
[ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
[ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
[ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
[ 0.000000] Call Trace:
[ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
[ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
[ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
[ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
[ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
[ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
[ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
[ 0.000000] Instruction dump:
[ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
[ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
[ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
From: Arnd Bergmann @ 2008-04-02 5:21 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev, cel, linux-kernel, Carl Love
In-Reply-To: <1206460727.7132.232.camel@carll-linux-desktop>
On Tuesday 25 March 2008, Carl Love wrote:
> This patch fixes a bug in the code that records the SPU data and
> context switches. The buffer_mutex lock must be held when the
> kernel is adding data to the buffer between the kernel and the
> OProfile daemon. The lock is not being held in the current code
> base. This patch fixes the bug using work queues. The data to
> be passed to the daemon is caputured by the interrupt handler.
> The workqueue function is invoked to grab the buffer_mutex lock
> and add the data to the buffer.
So what was the exact bug you're fixing with this? There was no
buffer_mutex before, so why do you need it now? Can't this be a
spinlock so you can get it from interrupt context instead of
using a workqueue?
> Index: linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> ===================================================================
> --- linux-2.6.25-rc4.orig/arch/powerpc/oprofile/cell/spu_profiler.c
> +++ linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> @@ -16,6 +16,7 @@
> #include <linux/smp.h>
> #include <linux/slab.h>
> #include <asm/cell-pmu.h>
> +#include <linux/workqueue.h>
> #include "pr_util.h"
>
Please keep #include statements in alphabetical order, with all linux/ files
before the asm/ files.
> #define TRACE_ARRAY_SIZE 1024
> @@ -32,9 +33,19 @@ static unsigned int profiling_interval;
>
> #define SPU_PC_MASK 0xFFFF
>
> +/* The generic OProfile code uses the buffer_mutex to protect the buffer
> + * between the kernel and the daemon. The SPU code needs to use the buffer
> + * to ensure that the kernel SPU writes complete as a single block before
> + * being consumed by the daemon.
> + */
> +extern struct mutex buffer_mutex;
> +
> static DEFINE_SPINLOCK(sample_array_lock);
> unsigned long sample_array_lock_flags;
>
> +struct work_struct spu_record_wq;
> +extern struct workqueue_struct *oprofile_spu_wq;
> +
> void set_spu_profiling_frequency(unsigned int freq_khz, unsigned int cycles_reset)
> {
> unsigned long ns_per_cyc;
Never put extern statements in the implementation, they describe the
interface between two parts of the code and should be inside of a
common header.
Why do you want to have your own workqueue instead of using the
global one?
> @@ -123,14 +134,14 @@ static int cell_spu_pc_collection(int cp
> return entry;
> }
>
> -
> -static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> -{
> - ktime_t kt;
> +static void profile_spus_record_samples (struct work_struct *ws) {
> + /* This routine is called via schedule_work() to record the
> + * spu data. It must be run in a normal kernel mode to
> + * grab the OProfile mutex lock.
> + */
> int cpu, node, k, num_samples, spu_num;
>
> - if (!spu_prof_running)
> - goto stop;
> + mutex_lock(&buffer_mutex);
>
> for_each_online_cpu(cpu) {
> if (cbe_get_hw_thread_id(cpu))
> @@ -170,6 +181,20 @@ static enum hrtimer_restart profile_spus
> smp_wmb(); /* insure spu event buffer updates are written */
> /* don't want events intermingled... */
>
> + mutex_unlock(&buffer_mutex);
> +}
> +
> +static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> +{
> + ktime_t kt;
> +
> +
> + if (!spu_prof_running)
> + goto stop;
> +
> + /* schedule the funtion to record the data */
> + schedule_work(&spu_record_wq);
> +
> kt = ktime_set(0, profiling_interval);
> if (!spu_prof_running)
> goto stop;
This looks like you want to use a delayed_work rather than building your
own out of hrtimer and work. Is there any point why you want to use
an hrtimer?
> -static DEFINE_SPINLOCK(buffer_lock);
> +extern struct mutex buffer_mutex;
> +extern struct workqueue_struct *oprofile_spu_wq;
> +extern int calls_to_record_switch;
> +
Again, public interfaces need to go to a header file, and should
have a name that identifies the interface. "buffer_mutex" is
certainly not a suitable name for a kernel-wide global variable!
> static DEFINE_SPINLOCK(cache_lock);
> static int num_spu_nodes;
> +
> int spu_prof_num_nodes;
> int last_guard_val[MAX_NUMNODES * 8];
> +int cnt_swtch_processed_flag[MAX_NUMNODES * 8];
> +
> +struct spus_profiling_code_data_s {
> + int num_spu_nodes;
> + struct work_struct spu_prof_code_wq;
> +} spus_profiling_code_data;
> +
> +struct spu_context_switch_data_s {
> + struct spu *spu;
> + unsigned long spu_cookie;
> + unsigned long app_dcookie;
> + unsigned int offset;
> + unsigned long objectId;
> + int valid_entry;
> +} spu_context_switch_data;
I don't understand what these variables are really doing, but
having e.g. just one spu_context_switch_data for all the SPUs
doesn't seem to make much sense. What happens when two SPUs do
a context switch at the same time?
> +int calls_to_record_switch = 0;
> +int record_spu_start_flag = 0;
> +
> +struct spus_cntxt_sw_data_s {
> + int num_spu_nodes;
> + struct spu_context_switch_data_s spu_data[MAX_NUMNODES * 8];
> + struct work_struct spu_cntxt_work;
> +} spus_cntxt_sw_data;
Something is very wrong if you need so many global variables!
> /* Container for caching information about an active SPU task. */
> struct cached_info {
> @@ -44,6 +73,8 @@ struct cached_info {
> struct kref cache_ref;
> };
>
> +struct workqueue_struct *oprofile_spu_wq;
> +
> static struct cached_info *spu_info[MAX_NUMNODES * 8];
While you're cleaning this up, I guess the cached_info should
be moved into a pointer from struct spu as well, instead of
having this global variable here.
> @@ -375,16 +457,30 @@ int spu_sync_start(void)
> int k;
> int ret = SKIP_GENERIC_SYNC;
> int register_ret;
> - unsigned long flags = 0;
>
> spu_prof_num_nodes = number_of_online_nodes();
> num_spu_nodes = spu_prof_num_nodes * 8;
>
> - spin_lock_irqsave(&buffer_lock, flags);
> - add_event_entry(ESCAPE_CODE);
> - add_event_entry(SPU_PROFILING_CODE);
> - add_event_entry(num_spu_nodes);
> - spin_unlock_irqrestore(&buffer_lock, flags);
> + /* create private work queue, execution of work is time critical */
> + oprofile_spu_wq = create_workqueue("spu_oprofile");
> +
> + /* due to a race when the spu is already running stuff, need to
> + * set a flag to tell the spu context switch to record the start
> + * before recording the context switches.
> + */
> + record_spu_start_flag = 1;
> +
> + spus_profiling_code_data.num_spu_nodes = num_spu_nodes;
> +
> + /* setup work queue functiion for recording context switch info */
> + spus_cntxt_sw_data.num_spu_nodes = num_spu_nodes;
> + for (k = 0; k<(MAX_NUMNODES * 8); k++) {
> + spus_cntxt_sw_data.spu_data[k].valid_entry = 0;
> + cnt_swtch_processed_flag[k] = 0;
> + }
> +
> + INIT_WORK(&spus_cntxt_sw_data.spu_cntxt_work,
> + record_spu_process_switch);
I would guess that you need one work struct per SPU instead of a global
one, if you want to pass the SPU pointer as an argument.
Arnd <><
^ permalink raw reply
* [PATCH] [POWERPC] Fix iSeries hard irq enabling regression
From: Benjamin Herrenschmidt @ 2008-04-02 4:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
A subtle bug sneaked into iSeries recently. On this platform, we
must not normally clear MSR:EE unless it's for short periods of
time. Taking an interrupt while soft-disabled doesn't cause us to
clear it for example.
The iSeries kernel expects to mostly run with MSR:EE enabled at
all times except a few exception entry/exit code path. Thus
local_irq_enable() doesn't check if it needs to hard-enable as
it expects this to be unnecessary on iSeries.
However, hard_irq_disable() _does_ cause MSR:EE to be cleared,
including on iSeries. A call to it was recently added to the
context switch code, thus causing interrupts to become disabled
for a long period of time, causing the iSeries watchdog to kick
in under some circumstances and other nasty things.
This patch fixes it by making local_irq_enable() properly re-enable
MSR:EE on iSeries. It basically removes a return statement here
to make iSeries use the same code path as everybody else. That does
mean that we might occasionally get spurrious decrementer interrupts
but I don't think that matters.
Another option would have been to make hard_irq_disable() a nop
on iSeries but I didn't like it much, in case we have good reasons
to hard-disable.
Part of the patch is fixes to make sure the hard_enabled PACA field
is properly set on iSeries as it used not to be before, since it
was mostly unused.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
--
arch/powerpc/kernel/head_64.S | 13 +++++++------
arch/powerpc/kernel/irq.c | 1 -
2 files changed, 7 insertions(+), 7 deletions(-)
--- linux-work.orig/arch/powerpc/kernel/head_64.S 2008-04-02 15:47:20.000000000 +1100
+++ linux-work/arch/powerpc/kernel/head_64.S 2008-04-02 15:48:50.000000000 +1100
@@ -1387,12 +1387,14 @@ __secondary_start:
#ifdef CONFIG_PPC_ISERIES
BEGIN_FW_FTR_SECTION
ori r4,r4,MSR_EE
+ li r8,1
+ stb r8,PACAHARDIRQEN(r13)
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
#endif
BEGIN_FW_FTR_SECTION
- stb r7,PACASOFTIRQEN(r13)
stb r7,PACAHARDIRQEN(r13)
END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISERIES)
+ stb r7,PACASOFTIRQEN(r13)
mtspr SPRN_SRR0,r3
mtspr SPRN_SRR1,r4
@@ -1520,15 +1522,14 @@ _INIT_GLOBAL(start_here_common)
#ifdef CONFIG_PPC_ISERIES
BEGIN_FW_FTR_SECTION
mfmsr r5
- ori r5,r5,MSR_EE /* Hard Enabled */
+ ori r5,r5,MSR_EE /* Hard Enabled on iSeries*/
mtmsrd r5
+ li r5,1
END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
#endif
-BEGIN_FW_FTR_SECTION
- stb r5,PACAHARDIRQEN(r13)
-END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISERIES)
+ stb r5,PACAHARDIRQEN(r13) /* Hard Disabled on others */
- bl .start_kernel
+ bl .start_kernel
/* Not reached */
BUG_OPCODE
Index: linux-work/arch/powerpc/kernel/irq.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/irq.c 2008-04-02 15:46:34.000000000 +1100
+++ linux-work/arch/powerpc/kernel/irq.c 2008-04-02 15:46:37.000000000 +1100
@@ -143,7 +143,6 @@ void local_irq_restore(unsigned long en)
*/
if (local_paca->lppaca_ptr->int_dword.any_int)
iseries_handle_interrupts();
- return;
}
/*
^ permalink raw reply
* RE: Access physical memory via mmap() on ppc440epx.
From: Leonid @ 2008-04-02 4:30 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <1207100665.12155.100.camel@vader.jdub.homelinux.org>
Hi, Josh:
Thank you for your suggestion. Somehow it didn't work with mmap (may be,
my mistake, I'll double check), however it partially helped me with my
another problem.
I have kernel driver where I need read/write some HW device, connected
on address 0xea000000, chip select 4. This chip select configured
properly, here are EBC registers:
440EPx>rd ebc0_b4cr
ebc0_b4cr: 0xea01a000 -368992256
440EPx>rd ebc0_b4ap
ebc0_b4ap: 0x03037000 50556928
>From u-boot I can read/write this address with no problem (I use md/mw
commands).
In my driver I tried to ioremap() this address and any attempt to access
led to crash, same as with mmap().
When, following your suggestion, I used address 0x1ea00000 and
ioremap64(), crashes disappeared!
I even can write, but when I read data back I see least significant byte
of each 16 bits word only (bus is configured 16 bits width).=20
What can it be?
Thanks,
Leonid.=20
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@gmail.com]=20
Sent: Tuesday, April 01, 2008 6:44 PM
To: Leonid
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Access physical memory via mmap() on ppc440epx.
On Tue, 2008-04-01 at 14:12 -0700, Leonid wrote:
> Hi:
>=20
> I am trying to read from NOR flash, located on address 0xfc000000, on
my
It's at 0x1fc000000 IIRC.
> TLB entries look strange though. That what it was on u-boot stage:
>=20
> 440EPx>tlb 0 10
> IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
> 0 : 00 40000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 2 : 00 c0000000 256MB V0 -> 1_c0000000 U:0000 -I-G- XWRXWR
> 3 : 00 f0000000 256MB V0 -> 1_f0000000 U:0000 WI-G- XWRXWR
See. Virtual is 0xf0000000, physical is 0x1f0000000.
> On Linux stage it looks rather different:
I don't even see your entry in here. Likely because the TLB is small
and it's gone by the time you do the dump
> Probably under MMU it should look this way? How to use mmap() then?
Try mmap64 on the real physical address and see if that helps.
josh
^ 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