* [PATCH] [9/12] pasemi_mac: SKB unmap optimization
From: Olof Johansson @ 2007-11-29 2:57 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071129025410.GA17215@lixom.net>
pasemi_mac: SKB unmap optimization
Avoid touching skb_shinfo() in the unmap path, since it turns out to
normally cause cache misses and delays. instead, save number of fragments
in the TX_RING_INFO structures since that's all that's needed anyway.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
drivers/net/pasemi_mac.c | 39 +++++++++++++++++++++++++--------------
1 file changed, 25 insertions(+), 14 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -253,11 +253,11 @@ static int get_skb_hdr(struct sk_buff *s
}
static int pasemi_mac_unmap_tx_skb(struct pasemi_mac *mac,
+ const int nfrags,
struct sk_buff *skb,
const dma_addr_t *dmas)
{
int f;
- int nfrags = skb_shinfo(skb)->nr_frags;
struct pci_dev *pdev = mac->dma_pdev;
pci_unmap_single(pdev, dmas[0], skb_headlen(skb), PCI_DMA_TODEVICE);
@@ -425,7 +425,7 @@ static void pasemi_mac_free_tx_resources
unsigned int i, j;
struct pasemi_mac_buffer *info;
dma_addr_t dmas[MAX_SKB_FRAGS+1];
- int freed;
+ int freed, nfrags;
int start, limit;
start = txring->next_to_clean;
@@ -438,10 +438,12 @@ static void pasemi_mac_free_tx_resources
for (i = start; i < limit; i += freed) {
info = &txring->ring_info[(i+1) & (TX_RING_SIZE-1)];
if (info->dma && info->skb) {
- for (j = 0; j <= skb_shinfo(info->skb)->nr_frags; j++)
+ nfrags = skb_shinfo(info->skb)->nr_frags;
+ for (j = 0; j <= nfrags; j++)
dmas[j] = txring->ring_info[(i+1+j) &
(TX_RING_SIZE-1)].dma;
- freed = pasemi_mac_unmap_tx_skb(mac, info->skb, dmas);
+ freed = pasemi_mac_unmap_tx_skb(mac, nfrags,
+ info->skb, dmas);
} else
freed = 2;
}
@@ -749,6 +751,8 @@ static int pasemi_mac_clean_tx(struct pa
unsigned long flags;
struct sk_buff *skbs[TX_CLEAN_BATCHSIZE];
dma_addr_t dmas[TX_CLEAN_BATCHSIZE][MAX_SKB_FRAGS+1];
+ int nf[TX_CLEAN_BATCHSIZE];
+ int nr_frags;
total_count = 0;
batch_limit = TX_CLEAN_BATCHSIZE;
@@ -758,6 +762,8 @@ restart:
start = txring->next_to_clean;
ring_limit = txring->next_to_fill;
+ prefetch(&TX_DESC_INFO(txring, start+1).skb);
+
/* Compensate for when fill has wrapped but clean has not */
if (start > ring_limit)
ring_limit += TX_RING_SIZE;
@@ -771,6 +777,9 @@ restart:
u64 mactx = TX_DESC(txring, i);
struct sk_buff *skb;
+ skb = TX_DESC_INFO(txring, i+1).skb;
+ nr_frags = TX_DESC_INFO(txring, i).dma;
+
if ((mactx & XCT_MACTX_E) ||
(*chan->status & PAS_STATUS_ERROR))
pasemi_mac_tx_error(mac, mactx);
@@ -779,21 +788,22 @@ restart:
/* Not yet transmitted */
break;
- skb = TX_DESC_INFO(txring, i+1).skb;
- skbs[descr_count] = skb;
+ buf_count = 2 + nr_frags;
+ /* Since we always fill with an even number of entries, make
+ * sure we skip any unused one at the end as well.
+ */
+ if (buf_count & 1)
+ buf_count++;
- buf_count = 2 + skb_shinfo(skb)->nr_frags;
- for (j = 0; j <= skb_shinfo(skb)->nr_frags; j++)
+ for (j = 0; j <= nr_frags; j++)
dmas[descr_count][j] = TX_DESC_INFO(txring, i+1+j).dma;
+ skbs[descr_count] = skb;
+ nf[descr_count] = nr_frags;
+
TX_DESC(txring, i) = 0;
TX_DESC(txring, i+1) = 0;
- /* Since we always fill with an even number of entries, make
- * sure we skip any unused one at the end as well.
- */
- if (buf_count & 1)
- buf_count++;
descr_count++;
}
txring->next_to_clean = i & (TX_RING_SIZE-1);
@@ -802,7 +812,7 @@ restart:
netif_wake_queue(mac->netdev);
for (i = 0; i < descr_count; i++)
- pasemi_mac_unmap_tx_skb(mac, skbs[i], dmas[i]);
+ pasemi_mac_unmap_tx_skb(mac, nf[i], skbs[i], dmas[i]);
total_count += descr_count;
@@ -1299,6 +1309,7 @@ static int pasemi_mac_start_tx(struct sk
}
TX_DESC(txring, fill) = mactx;
+ TX_DESC_INFO(txring, fill).dma = nfrags;
fill++;
TX_DESC_INFO(txring, fill).skb = skb;
for (i = 0; i <= nfrags; i++) {
^ permalink raw reply
* [PATCH] [10/12] pasemi_mac: Remove SKB copy/recycle logic
From: Olof Johansson @ 2007-11-29 2:57 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071129025410.GA17215@lixom.net>
pasemi_mac: Remove SKB copy/recycle logic
It doesn't really buy us much, since copying is about as expensive
as the allocation in the first place. Just remove it for now.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
drivers/net/pasemi_mac.c | 25 +++----------------------
1 file changed, 3 insertions(+), 22 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -503,13 +503,8 @@ static void pasemi_mac_replenish_rx_ring
/* Entry in use? */
WARN_ON(*buff);
- /* skb might still be in there for recycle on short receives */
- if (info->skb)
- skb = info->skb;
- else {
- skb = dev_alloc_skb(BUF_SIZE);
- skb_reserve(skb, LOCAL_SKB_ALIGN);
- }
+ skb = dev_alloc_skb(BUF_SIZE);
+ skb_reserve(skb, LOCAL_SKB_ALIGN);
if (unlikely(!skb))
break;
@@ -666,21 +661,7 @@ static int pasemi_mac_clean_rx(struct pa
goto next;
}
- if (len < 256) {
- struct sk_buff *new_skb;
-
- new_skb = netdev_alloc_skb(mac->netdev,
- len + LOCAL_SKB_ALIGN);
- if (new_skb) {
- skb_reserve(new_skb, LOCAL_SKB_ALIGN);
- memcpy(new_skb->data, skb->data, len);
- /* save the skb in buffer_info as good */
- skb = new_skb;
- }
- /* else just continue with the old one */
- } else
- info->skb = NULL;
-
+ info->skb = NULL;
info->dma = 0;
if (likely((macrx & XCT_MACRX_HTY_M) == XCT_MACRX_HTY_IPV4_OK)) {
^ permalink raw reply
* [PATCH] [11/12] pasemi_mac: Print warning when not attaching to a PHY
From: Olof Johansson @ 2007-11-29 2:58 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071129025410.GA17215@lixom.net>
pasemi_mac: Print warning when not attaching to a PHY
Print a warning on the console when not connecting to a phy for an interface.
It turns out to be a pretty common problem when someone gets the MDIO info
wrong in their device tree, resulting in the macs running at a fixed 1Gbit FD.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
drivers/net/pasemi_mac.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -1064,11 +1064,12 @@ static int pasemi_mac_open(struct net_de
write_mac_reg(mac, PAS_MAC_CFG_PCFG, flags);
ret = pasemi_mac_phy_init(dev);
- /* Some configs don't have PHYs (XAUI etc), so don't complain about
- * failed init due to -ENODEV.
+ /* Warn for missing PHY on SGMII (1Gig) ports.
*/
- if (ret && ret != -ENODEV)
- dev_warn(&mac->pdev->dev, "phy init failed: %d\n", ret);
+ if (ret && mac->type == MAC_TYPE_GMAC) {
+ dev_warn(&mac->pdev->dev, "PHY init failed: %d.\n", ret);
+ dev_warn(&mac->pdev->dev, "Defaulting to 1Gbit full duplex\n");
+ }
netif_start_queue(dev);
napi_enable(&mac->napi);
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Randy Dunlap @ 2007-11-29 1:40 UTC (permalink / raw)
To: Nish Aravamudan; +Cc: Linux Memory Management List, kniht, linuxppc-dev
In-Reply-To: <29495f1d0711281736if4bd8b0wc77d3beb39cb1284@mail.gmail.com>
Nish Aravamudan wrote:
> On 11/28/07, Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> On Tue, 27 Nov 2007 23:03:10 -0600 Jon Tollefson wrote:
>>
>>> This patch adds the hugepagesz boot-time parameter for ppc64 that lets
>>> you pick the size for your huge pages. The choices available are 64K
>>> and 16M. It defaults to 16M (previously the only choice) if nothing or
>>> an invalid choice is specified. Tested 64K huge pages with the
>>> libhugetlbfs 1.2 release with its 'make func' and 'make stress' test
>>> invocations.
>>>
>>> This patch requires the patch posted by Mel Gorman that adds
>>> HUGETLB_PAGE_SIZE_VARIABLE; "[PATCH] Fix boot problem with iSeries
>>> lacking hugepage support" on 2007-11-15.
>>>
>>> Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
>>> ---
>>>
>>> Documentation/kernel-parameters.txt | 1
>>> arch/powerpc/mm/hash_utils_64.c | 11 +--------
>>> arch/powerpc/mm/hugetlbpage.c | 41 ++++++++++++++++++++++++++++++++++++
>>> include/asm-powerpc/mmu-hash64.h | 1
>>> mm/hugetlb.c | 1
>>> 5 files changed, 46 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>>> index 33121d6..2fc1fb8 100644
>>> --- a/Documentation/kernel-parameters.txt
>>> +++ b/Documentation/kernel-parameters.txt
>>> @@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in the file
>>> See Documentation/isdn/README.HiSax.
>>>
>>> hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages.
>>> + hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages.
>> Any chance of spelling it as "hugepagesize" so that it's a little
>> less cryptic and more difficult to typo as "hugepages"?
>> (i.e., less confusion between them)
>
> It already exists as hugepagesz= for IA64. Changing it to hugepagesize
> would either make ppc be different than IA64, or require keeping both
> so as to make IA64 setups continue working as before?
Oh, but it wasn't in Doc/kernel-parameters.txt ? :(
OK, just leave it as is, I think.
Thanks,
--
~Randy
^ permalink raw reply
* [PATCH] [12/12] pasemi_mac: Don't enable RX/TX without a link (if possible)
From: Olof Johansson @ 2007-11-29 2:58 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071129025410.GA17215@lixom.net>
pasemi_mac: Don't enable RX/TX without a link (if possible)
Don't enable RX/TX of packets until we have a link, since there's a chance
we'll just get RX frame errors, etc.
The case where we don't have a PHY we can't do much about: Just enable
it and deal with errors as they come in.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
drivers/net/pasemi_mac.c | 41 +++++++++++++++++++++++++++++++++--------
1 file changed, 33 insertions(+), 8 deletions(-)
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -874,6 +874,24 @@ static irqreturn_t pasemi_mac_tx_intr(in
return IRQ_HANDLED;
}
+static void pasemi_mac_intf_disable(struct pasemi_mac *mac)
+{
+ unsigned int flags;
+
+ flags = read_mac_reg(mac, PAS_MAC_CFG_PCFG);
+ flags &= ~PAS_MAC_CFG_PCFG_PE;
+ write_mac_reg(mac, PAS_MAC_CFG_PCFG, flags);
+}
+
+static void pasemi_mac_intf_enable(struct pasemi_mac *mac)
+{
+ unsigned int flags;
+
+ flags = read_mac_reg(mac, PAS_MAC_CFG_PCFG);
+ flags |= PAS_MAC_CFG_PCFG_PE;
+ write_mac_reg(mac, PAS_MAC_CFG_PCFG, flags);
+}
+
static void pasemi_adjust_link(struct net_device *dev)
{
struct pasemi_mac *mac = netdev_priv(dev);
@@ -889,11 +907,14 @@ static void pasemi_adjust_link(struct ne
printk(KERN_INFO "%s: Link is down.\n", dev->name);
netif_carrier_off(dev);
+ pasemi_mac_intf_disable(mac);
mac->link = 0;
return;
- } else
+ } else {
+ pasemi_mac_intf_enable(mac);
netif_carrier_on(dev);
+ }
flags = read_mac_reg(mac, PAS_MAC_CFG_PCFG);
new_flags = flags & ~(PAS_MAC_CFG_PCFG_HD | PAS_MAC_CFG_PCFG_SPD_M |
@@ -1052,8 +1073,7 @@ static int pasemi_mac_open(struct net_de
pasemi_mac_restart_rx_intr(mac);
pasemi_mac_restart_tx_intr(mac);
- flags = PAS_MAC_CFG_PCFG_S1 | PAS_MAC_CFG_PCFG_PE |
- PAS_MAC_CFG_PCFG_PR | PAS_MAC_CFG_PCFG_CE;
+ flags = PAS_MAC_CFG_PCFG_S1 | PAS_MAC_CFG_PCFG_PR | PAS_MAC_CFG_PCFG_CE;
if (mac->type == MAC_TYPE_GMAC)
flags |= PAS_MAC_CFG_PCFG_TSR_1G | PAS_MAC_CFG_PCFG_SPD_1G;
@@ -1064,11 +1084,16 @@ static int pasemi_mac_open(struct net_de
write_mac_reg(mac, PAS_MAC_CFG_PCFG, flags);
ret = pasemi_mac_phy_init(dev);
- /* Warn for missing PHY on SGMII (1Gig) ports.
- */
- if (ret && mac->type == MAC_TYPE_GMAC) {
- dev_warn(&mac->pdev->dev, "PHY init failed: %d.\n", ret);
- dev_warn(&mac->pdev->dev, "Defaulting to 1Gbit full duplex\n");
+ if (ret) {
+ /* Since we won't get link notification, just enable RX */
+ pasemi_mac_intf_enable(mac);
+ if (mac->type == MAC_TYPE_GMAC) {
+ /* Warn for missing PHY on SGMII (1Gig) ports */
+ dev_warn(&mac->pdev->dev,
+ "PHY init failed: %d.\n", ret);
+ dev_warn(&mac->pdev->dev,
+ "Defaulting to 1Gbit full duplex\n");
+ }
}
netif_start_queue(dev);
^ permalink raw reply
* Re: [PATCH] [0/12] pasemi_mac updates for 2.6.25 + DMA channel management library
From: Olof Johansson @ 2007-11-29 2:59 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071129025410.GA17215@lixom.net>
On Wed, Nov 28, 2007 at 08:54:10PM -0600, Olof Johansson wrote:
> The patches are:
[...]
I got the order wrong above, the actual one is:
1/12 pasemi_mac: RX/TX ring management cleanup
2/12 pasemi_mac: Move register definitions to include/asm-powerpc
3/12 pasemi: DMA engine management library
4/12 pasemi_mac: Convert to new dma library
5/12 pasemi_mac: performance tweaks
6/12 pasemi_mac: Fix TX cleaning
7/12 pasemi_mac: Improve RX interrupt mitigation
8/12 pasemi_mac: Software-based LRO support
9/12 pasemi_mac: SKB unmap optimization
10/12 pasemi_mac: Remove SKB copy/recycle logic
11/12 pasemi_mac: Print warning when not attaching to a PHY
12/12 pasemi_mac: Don't enable RX/TX without a link (if possible)
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Nish Aravamudan @ 2007-11-29 3:01 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Linux Memory Management List, kniht, linuxppc-dev
In-Reply-To: <474E187E.7040404@oracle.com>
On 11/28/07, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> Nish Aravamudan wrote:
> > On 11/28/07, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >> On Tue, 27 Nov 2007 23:03:10 -0600 Jon Tollefson wrote:
> >>
> >>> This patch adds the hugepagesz boot-time parameter for ppc64 that lets
> >>> you pick the size for your huge pages. The choices available are 64K
> >>> and 16M. It defaults to 16M (previously the only choice) if nothing or
> >>> an invalid choice is specified. Tested 64K huge pages with the
> >>> libhugetlbfs 1.2 release with its 'make func' and 'make stress' test
> >>> invocations.
> >>>
> >>> This patch requires the patch posted by Mel Gorman that adds
> >>> HUGETLB_PAGE_SIZE_VARIABLE; "[PATCH] Fix boot problem with iSeries
> >>> lacking hugepage support" on 2007-11-15.
> >>>
> >>> Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
> >>> ---
> >>>
> >>> Documentation/kernel-parameters.txt | 1
> >>> arch/powerpc/mm/hash_utils_64.c | 11 +--------
> >>> arch/powerpc/mm/hugetlbpage.c | 41 ++++++++++++++++++++++++++++++++++++
> >>> include/asm-powerpc/mmu-hash64.h | 1
> >>> mm/hugetlb.c | 1
> >>> 5 files changed, 46 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> >>> index 33121d6..2fc1fb8 100644
> >>> --- a/Documentation/kernel-parameters.txt
> >>> +++ b/Documentation/kernel-parameters.txt
> >>> @@ -685,6 +685,7 @@ and is between 256 and 4096 characters. It is defined in the file
> >>> See Documentation/isdn/README.HiSax.
> >>>
> >>> hugepages= [HW,X86-32,IA-64] Maximal number of HugeTLB pages.
> >>> + hugepagesz= [HW,IA-64,PPC] The size of the HugeTLB pages.
> >> Any chance of spelling it as "hugepagesize" so that it's a little
> >> less cryptic and more difficult to typo as "hugepages"?
> >> (i.e., less confusion between them)
> >
> > It already exists as hugepagesz= for IA64. Changing it to hugepagesize
> > would either make ppc be different than IA64, or require keeping both
> > so as to make IA64 setups continue working as before?
>
> Oh, but it wasn't in Doc/kernel-parameters.txt ? :(
Nope :( I wonder how many other kernel parameters are in the same
boat? Where's an RPJDay-script when you need it?
> OK, just leave it as is, I think.
Yeah, I guess that's probably easiest...unfortunately.
-Nish
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Dell Query @ 2007-11-29 3:16 UTC (permalink / raw)
To: Stefan Roese, linuxppc-embedded
In-Reply-To: <200711281151.45446.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]
I don't know if the document that came with the PPC440EPx Sequoia Resource CD is right. It is odd that it is entitled "Embedded Planet 440xC" and it showed in page 34:
-----------------------------------------------------------------------
Table 4-4. Memory Map
Function Start Address End Address Size Chip Select
DDR SDRAM 0x0000 0000 0x0FFF FFFF 256 MB —
PCI Memory 0x8000 0000 0xBFFF FFFF 1024 MB —
BCSR 0xC000 0000 0xCFFF FFFF 256 MB CS2
NAND FLASH Controller1 0xD000 0000 0xD00F FFFF 1 MB CS3/CS0
NOR FLASH1 0xFC00 0000 0xFFFF FFFF 64 MB CS0/CS3
-----------------------------------------------------------------------
Anyway, I have seen Table 1. System Memory Address Map and it got EBC mapped at 0x1.c000.0000 and another one at 0x1.f000.0000. But I didn't see any BCSR info. Correct me if I am wrong, but should it not give me BCSR details like:
Register 0 = ID Board ID
Register 1 = 0000 0000 CPLD revision
Register 2 = 0000 xxxx User dip-switch / LEDs
Register 3 = 0000 xxxx Configuration dip-switch
Register 4 = 0000 0000 TMRCLK control
Register 5 = 0000 0000 PCI control, status, info
Register 6 = 0000 0000 Reset control
Register 7 = 0000 001x Memory control
Register 8 = 0000 0000 Ethernet control
Register 9 = 0000 0001 USB control
Register 10 = 0000 0000 Performance timer (MS Byte, bits 27-24)
Register 11 = 0000 0000 Performance timer (bits 23-16)
Register 12 = 0000 0000 Performance timer (bits 15-8)
Register 13 = 0000 0000 Performance timer (LS Byte, bits 7-0)
Regards,
dell
Stefan Roese <sr@denx.de> wrote: On Wednesday 28 November 2007, Dell Query wrote:
> Oh is it 0x1C0002000?
Just to be sure here, we are talking about the AMCC Sequoia board, right?
> Where can I get the document? What I have is 0xC0002000 from
> ep440xc_um_amcc.pdf file that I get from the accompanying PPC440EPx
> resource CD.
Please take a look at the 440EPx data sheet. It has a nice table with an
overview of the address maps (table 1). Here you will notice that the EBC has
multiple maps, one starting at 0x1.c000.0000 and another one at
0x1.f000.0000. Yes, these are 36bit physical addresses. In U-Boot these are
mapped via the TLB to 0xc000.0000 and 0xf000.0000. So in U-Boot you are able
to access the CPLD at 0xc0000000. But in Linux you have to map the 36bit
address to get the virtual address which you need for accessing. And using
arch/ppc you need to call ioremap64() with this 36bit address as parameter.
Hope this helps.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
---------------------------------
Get easy, one-click access to your favorites. Make Yahoo! your homepage.
[-- Attachment #2: Type: text/html, Size: 4265 bytes --]
^ permalink raw reply
* Re: [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
From: Ishizaki Kou @ 2007-11-29 3:22 UTC (permalink / raw)
To: gorcunov; +Cc: olof, paulus, linux-kernel, linuxppc-dev
In-Reply-To: <aa79d98a0711280259o6cc6fb12mf020c4a986d84ca6@mail.gmail.com>
Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> On 11/28/07, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> > On 11/28/07, Michael Ellerman <michael@ellerman.id.au> wrote:
> > > On Mon, 2007-11-26 at 10:46 +0300, Cyrill Gorcunov wrote:
> > > > This patch adds checking for NULL value returned to prevent possible
> > > > NULL pointer dereference.
> > > > Also two unneeded 'return' are removed.
> > > >
> > > > Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
> > > > ---
> > > > Any comments are welcome.
> > >
> > > I guess it's good to be paranoid, but this is a little verbose:
> > >
> > > wi0 = of_get_property(node, "device-id", NULL);
> > > + if (unlikely((!wi0))) {
> > > + printk(KERN_ERR "PCI: device-id not found.\n");
> > > + goto error;
> > > + }
> > > wi1 = of_get_property(node, "vendor-id", NULL);
> > > + if (unlikely((!wi1))) {
> > > + printk(KERN_ERR "PCI: vendor-id not found.\n");
> > > + goto error;
> > > + }
> > > wi2 = of_get_property(node, "class-code", NULL);
> > > + if (unlikely((!wi2))) {
> > > + printk(KERN_ERR "PCI: class-code not found.\n");
> > > + goto error;
> > > + }
> > > wi3 = of_get_property(node, "revision-id", NULL);
> > > + if (unlikely((!wi3))) {
> > > + printk(KERN_ERR "PCI: revision-id not found.\n");
> > > + goto error;
> > > + }
> > >
> > > Perhaps instead:
> > >
> > > wi0 = of_get_property(node, "device-id", NULL);
> > > wi1 = of_get_property(node, "vendor-id", NULL);
> > > wi2 = of_get_property(node, "class-code", NULL);
> > > wi3 = of_get_property(node, "revision-id", NULL);
> > >
> > > if (!wi0 || !wi1 || !wi2 || !wi3) {
> > > printk(KERN_ERR "PCI: Missing device tree properties.\n");
> > > goto error;
> > > }
> >
> > Hi Michael, yes that is much better (actually I was doubt about what form of
> > which the checking style to use - your form is much compact but mine does
> > show where *exactly* the problem appeared). So 'case that is the fake driver
> > your form is preferred ;) Ishizaki, could you use Michael's part then?
> >
> > >
> > >
> > > 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
> > >
> > >
> >
> > Cyrill
> >
> Ishizaki I can update the patch if you needed. Should I?
>
> Cyrill
There is no problem to use Michael's part, and I also prefer simple
one like this.
Cyrill, would you please update your patch?
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: 郭劲 @ 2007-11-29 3:11 UTC (permalink / raw)
To: Scott Wood, vijay baskar; +Cc: linuxppc-embedded
Hi,friends,
I plug in 2GB DDR-1 in my MPC8360 board,there are two DIMM-184 slots,each
DIMM-184 slot hold 1GB.Could you tell me how to let the linux know about those
2GB?
In uboot, I set up each DDR CS to visit 512MB, total 4 CS signal. DDR window
range is 2GB. I think the uboot has passed those DDR parameter to linux.
I once did a test that config the bootargs with mem=512M, then the linux just
only find 512MB, but if I config the mem=2048M, the linux still find about 750MB.
How to make the linux find the total 2GB memory?
>From: Scott Wood <scottwood@freescale.com>
>Reply-To:
>To: vijay baskar <cn.vijaibaskar@gdatech.co.in>
>Subject: Re: The question about the high memory support on MPC8360?
>Date:Wed, 28 Nov 2007 10:57:38 -0600
>
>vijay baskar wrote:
>> Hi, "The kernel also allows hardcoded mapping of IO regions into its
>> virtual address space through the io_block_mapping interface."
>>
>> Can u tell me how this is in current arch/powerpc.
>
>Everything is explicitly ioremapped.
>
>> Also does it mean that whatever be the size of the ram > 768 MB there
>> is not going to be much improvement in performance in kernel space
>> irrespective of invoking CONFIG_HIGHMEM or not?
>
>Well, the kernel can use highmem for cache... I'm not sure what you
>mean by "in kernel space".
>
>> Also do you think this low mem be enough if i have lots of kernel
>> space processes each invoking lots of kmallocs.
>
>That depends on what you mean by "lots". :-)
>
>You'll have 768MB of lowmem, and kmallocs can only use lowmem.
>
>> Will there be bottle necks?? Also what alternative do we have if low
>> mem of 768 MB is not enough??
>
>You'll need to change the user/kernel split, and deal with anything that
>breaks in the process.
>
>Or get a 64-bit chip. :-)
>
>-Scott
>
^ permalink raw reply
* Re: [PATCH] IB/ehca: Fix static rate if path faster than link
From: Roland Dreier @ 2007-11-29 3:42 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, Marcus Eder,
OF-General, Stefan Roscher
In-Reply-To: <200711281446.29085.fenkes@de.ibm.com>
thanks, applied
^ permalink raw reply
* Re: Timers on mpc8248 etc...
From: Alan Bennett @ 2007-11-29 4:06 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <474DFD15.603@freescale.com>
It comes from uboot. Can you point me in the right direction to make
sure its right?
PowerPC,8248@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <d#32>;
i-cache-line-size = <d#32>;
d-cache-size = <d#16384>;
i-cache-size = <d#16384>;
timebase-frequency = <0>;
clock-frequency = <0>;
};
On 11/28/07, Scott Wood <scottwood@freescale.com> wrote:
> Alan Bennett wrote:
> > I've got a routine that needs to delay for X microseconds, this is a
> > must. The command after schedule_timeout must has to wait for the HW
> > to complete a task that takes X microseconds.
> >
> > I would think that one way to do this is with a simple
> > schedule_timeout. But in the example below, the time that passes from
> > run1() to dontrun() is far less than 3.2 msecs. Infact, sometimes its
> > ~ 800 micros according the a analyzer looking at points triggered in
> > run1() and donrun(). Could this be a configuration problem with the
> > timer/interrupt that generates the jiffies?
>
> Are you sure the timebase frequency is set correctly in the device tree?
>
> -Scott
>
^ permalink raw reply
* [PATCH] Increase the upper bound on NR_CPUS.
From: Tony Breeds @ 2007-11-29 4:16 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
why not?
arch/powerpc/platforms/Kconfig.cputype | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 99684ea..5d70862 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -220,8 +220,8 @@ config SMP
If you don't know what to do here, say N.
config NR_CPUS
- int "Maximum number of CPUs (2-128)"
- range 2 128
+ int "Maximum number of CPUs (2-1024)"
+ range 2 1024
depends on SMP
default "32" if PPC64
default "4"
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] Increase the upper bound on NR_CPUS.
From: Michael Ellerman @ 2007-11-29 4:17 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071129041603.GM24243@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
On Thu, 2007-11-29 at 15:16 +1100, Tony Breeds wrote:
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
>
> ---
> why not?
How big is say a pseries_defconfig with NR_CPUS = 1024 ?
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: [PATCH] Increase the upper bound on NR_CPUS.
From: Tony Breeds @ 2007-11-29 4:23 UTC (permalink / raw)
To: Michael Ellerman; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <1196309836.7875.3.camel@concordia>
On Thu, Nov 29, 2007 at 03:17:16PM +1100, Michael Ellerman wrote:
> On Thu, 2007-11-29 at 15:16 +1100, Tony Breeds wrote:
> > Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> >
> > ---
> > why not?
>
> How big is say a pseries_defconfig with NR_CPUS = 1024 ?
This is a ppc64_defconfig, with a couple of extra patches, and
NR_CPUS=1024
tony@Sprygo:~/scratch/working$ size ../working_out/arch/powerpc/boot/zImage.{pmac,pseries,iseries} ../working_out/vmlinux
text data bss dec hex filename
3697092 5356 48232 3750680 393b18 ../working_out/arch/powerpc/boot/zImage.pmac
3697092 5356 48232 3750680 393b18 ../working_out/arch/powerpc/boot/zImage.pseries
8101340 4994176 815544 13911060 d44414 ../working_out/arch/powerpc/boot/zImage.iseries
8101340 4994176 815544 13911060 d44414 ../working_out/vmlinux
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] Increase the upper bound on NR_CPUS.
From: Michael Ellerman @ 2007-11-29 4:44 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071129042314.GN24243@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]
On Thu, 2007-11-29 at 15:23 +1100, Tony Breeds wrote:
> On Thu, Nov 29, 2007 at 03:17:16PM +1100, Michael Ellerman wrote:
> > On Thu, 2007-11-29 at 15:16 +1100, Tony Breeds wrote:
> > > Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> > >
> > > ---
> > > why not?
> >
> > How big is say a pseries_defconfig with NR_CPUS = 1024 ?
>
> This is a ppc64_defconfig, with a couple of extra patches, and
> NR_CPUS=1024
>
> tony@Sprygo:~/scratch/working$ size ../working_out/arch/powerpc/boot/zImage.{pmac,pseries,iseries} ../working_out/vmlinux
> text data bss dec hex filename
> 3697092 5356 48232 3750680 393b18 ../working_out/arch/powerpc/boot/zImage.pmac
> 3697092 5356 48232 3750680 393b18 ../working_out/arch/powerpc/boot/zImage.pseries
> 8101340 4994176 815544 13911060 d44414 ../working_out/arch/powerpc/boot/zImage.iseries
> 8101340 4994176 815544 13911060 d44414 ../working_out/vmlinux
OK, not too bad for the zImage, but the vmlinux has grown a bit, we
obviously have lots of foo[NR_CPUS].
NR_CPUS = 32 vs 1024
text data bss dec hex filename
7889287 1786256 529248 10204791 9bb677 vmlinux
7901531 4946864 814432 13662827 d07a6b vmlinux
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: [PATCH] PPC: CELLEB - fix potential NULL pointer dereference
From: Cyrill Gorcunov @ 2007-11-29 5:41 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: olof, paulus, linux-kernel, linuxppc-dev
In-Reply-To: <20071129.122245.-1300543769.kouish@swc.toshiba.co.jp>
[-- Attachment #1: Type: text/plain, Size: 369 bytes --]
On 11/29/07, Ishizaki Kou <kou.ishizaki@toshiba.co.jp> wrote:
[...snip...]
>
> There is no problem to use Michael's part, and I also prefer simple
> one like this.
>
> Cyrill, would you please update your patch?
>
> Best regards,
> Kou Ishizaki
>
Please see updated patch enveloped. (Can't do it inline becase I'm on
my work now where I have no Linux machine)
Cyrill
[-- Attachment #2: ppc-celleb-fix-null-v2.diff --]
[-- Type: text/plain, Size: 1977 bytes --]
---
From: Cyrill Gorcunov <gorcunov@gmail.com>
Subject: [PATCH] PPC: CELLEB - fix possible NULL pointer dereference
This patch adds checking for NULL returned value to
prevent possible NULL pointer dereference.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
arch/powerpc/platforms/celleb/pci.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c
index 6bc32fd..13ec4a6 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -138,8 +138,6 @@ static void celleb_config_read_fake(unsigned char *config, int where,
*val = celleb_fake_config_readl(p);
break;
}
-
- return;
}
static void celleb_config_write_fake(unsigned char *config, int where,
@@ -158,7 +156,6 @@ static void celleb_config_write_fake(unsigned char *config, int where,
celleb_fake_config_writel(val, p);
break;
}
- return;
}
static int celleb_fake_pci_read_config(struct pci_bus *bus,
@@ -351,6 +348,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
wi1 = of_get_property(node, "vendor-id", NULL);
wi2 = of_get_property(node, "class-code", NULL);
wi3 = of_get_property(node, "revision-id", NULL);
+ if (!wi0 || !wi1 || !wi2 || !wi3) {
+ printk(KERN_ERR "PCI: Missing device tree properties.\n");
+ goto error;
+ }
celleb_config_write_fake(*config, PCI_DEVICE_ID, 2, wi0[0] & 0xffff);
celleb_config_write_fake(*config, PCI_VENDOR_ID, 2, wi1[0] & 0xffff);
@@ -372,6 +373,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
celleb_setup_pci_base_addrs(hose, devno, fn, num_base_addr);
li = of_get_property(node, "interrupts", &rlen);
+ if (!li) {
+ printk(KERN_ERR "PCI: interrupts not found.\n");
+ goto error;
+ }
val = li[0];
celleb_config_write_fake(*config, PCI_INTERRUPT_PIN, 1, 1);
celleb_config_write_fake(*config, PCI_INTERRUPT_LINE, 1, val);
^ permalink raw reply related
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Stefan Roese @ 2007-11-29 6:10 UTC (permalink / raw)
To: Dell Query; +Cc: linuxppc-embedded
In-Reply-To: <556469.76659.qm@web45605.mail.sp1.yahoo.com>
On Thursday 29 November 2007, Dell Query wrote:
> I don't know if the document that came with the PPC440EPx Sequoia Resource
> CD is right. It is odd that it is entitled "Embedded Planet 440xC" and it
> showed in page 34:
> -----------------------------------------------------------------------
> Table 4-4. Memory Map
>
> Function Start Address End Address Size Chip Select
> DDR SDRAM 0x0000 0000 0x0FFF FFFF 256 MB =E2=80=94
> PCI Memory 0x8000 0000 0xBFFF FFFF 1024 MB =E2=80=94
> BCSR 0xC000 0000 0xCFFF FFFF 256 MB CS2
> NAND FLASH Controller1 0xD000 0000 0xD00F FFFF 1 MB CS3/CS0
> NOR FLASH1 0xFC00 0000 0xFFFF FFFF 64 MB CS0/CS3
> -----------------------------------------------------------------------
> Anyway, I have seen Table 1. System Memory Address Map and it got EBC
> mapped at 0x1.c000.0000 and another one at 0x1.f000.0000. But I didn't s=
ee
> any BCSR info. Correct me if I am wrong, but should it not give me BCSR
> details like:
This is board specific information and not CPU specific. The CPLD with it's=
=20
BCSR is a Sequoia thing and can therefor not be listed in the 440EPx manual=
s.=20
It it located on the EBC though which is documented in the 440EPx manuals.
So if this chips select which is connected to the CPLD is mapped to=20
0xc000.0000 which is the case for Sequoia, then you will "find" these=20
registers at physical address 0x1.c000.0000. And should use ioremap64() to=
=20
get the virtual address to access this CPLD.
Best regards,
Stefan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
^ permalink raw reply
* Re: [PATCH] Increase the upper bound on NR_CPUS.
From: Stephen Rothwell @ 2007-11-29 6:23 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071129041603.GM24243@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
Hi Tony, :-)
On Thu, 29 Nov 2007 15:16:03 +1100 tony@bakeyournoodle.com (Tony Breeds) wrote:
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
NAK ... you need to change the static initialisation of the paca
structures to match ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG] 2.6.24-rc3-git2 softlockup detected
From: Kamalesh Babulal @ 2007-11-29 6:31 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-scsi, LKML, Rafael J. Wysocki, linuxppc-dev, Balbir Singh
In-Reply-To: <20071127232552.ad16e95c.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Wed, 28 Nov 2007 12:47:19 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
>> Andrew Morton wrote:
>>> On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>>
>>>> Hi,
>>> (cc linux-scsi, for sym53c8xx)
>>>
>>>> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
>>> I assume this is a post-2.6.23 regression?
>>>
>>>> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
>>>> NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
>>>> REGS: c00000077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
>>>> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
>>>> TASK = c00000077cbd8000[375] 'insmod' THREAD: c00000077cbec000 CPU: 1
>>>> GPR00: d0000000001414fc c00000077cbef330 c00000000052b930 d000080080002014
>>>> GPR04: d00008008000202c 0000000000000000 c00000077ca1cb00 d00000000014ce54
>>>> GPR08: c00000077ca1c63c 0000000000000000 000000000000002a c00000000002f018
>>>> GPR12: d000000000143610 c000000000473d00
>>>> NIP [c00000000002f02c] .ioread8+0x14/0x60
>>>> LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>>>> Call Trace:
>>>> [c00000077cbef330] [c00000077cbef3c0] 0xc00000077cbef3c0 (unreliable)
>>>> [c00000077cbef3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
>>>> [c00000077cbef470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
>>>> [c00000077cbef710] [c0000000001bc118] .pci_device_probe+0x124/0x1b0
>>>> [c00000077cbef7b0] [c000000000221138] .driver_probe_device+0x144/0x20c
>>>> [c00000077cbef850] [c000000000221450] .__driver_attach+0xcc/0x154
>>>> [c00000077cbef8e0] [c00000000021ff94] .bus_for_each_dev+0x7c/0xd4
>>>> [c00000077cbef9a0] [c000000000220e9c] .driver_attach+0x28/0x40
>>>> [c00000077cbefa20] [c0000000002204d8] .bus_add_driver+0x90/0x228
>>>> [c00000077cbefac0] [c000000000221858] .driver_register+0x94/0xb0
>>>> [c00000077cbefb40] [c0000000001bc430] .__pci_register_driver+0x6c/0xcc
>>>> [c00000077cbefbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
>>>> [c00000077cbefc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
>>>> [c00000077cbefe30] [c00000000000872c] syscall_exit+0x0/0x40
>>>> Instruction dump:
>>>> 60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
>>>> f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
>>> I see no obvious lockup sites near the end of sym_hcb_attach(). Maybe it's
>>> being called lots of times from a higher level.. Do the traces all look
>>> the same?
>> Hi Andrew,
>>
>> I see this call trace twice and both looks similar and on another reboot
>> the following trace is seen twice in different cpu
>>
>> BUG: soft lockup detected on CPU#3!
>> Call Trace:
>> [C00000003FEDEDA0] [C000000000010220] .show_stack+0x68/0x1b0 (unreliable)
>> [C00000003FEDEE40] [C0000000000A061C] .softlockup_tick+0xf0/0x13c
>> [C00000003FEDEEF0] [C000000000072E2C] .run_local_timers+0x1c/0x30
>> [C00000003FEDEF70] [C000000000022FA0] .timer_interrupt+0xa8/0x488
>> [C00000003FEDF050] [C0000000000034EC] decrementer_common+0xec/0x100
>> --- Exception: 901 at .ioread8+0x14/0x60
>> LR = .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
>> [C00000003FEDF340] [D0000000002B3BC0] 0xd0000000002b3bc0 (unreliable)
>> [C00000003FEDF3B0] [D00000000029A3C0] .sym_hcb_attach+0x1194/0x1384 [sym53c8xx]
>> [C00000003FEDF480] [D000000000291D30] .sym2_probe+0x75c/0x9f8 [sym53c8xx]
>> [C00000003FEDF710] [C0000000001B65A4] .pci_device_probe+0x13c/0x1dc
>> [C00000003FEDF7D0] [C000000000219A0C] .driver_probe_device+0xa0/0x15c
>> [C00000003FEDF870] [C000000000219C64] .__driver_attach+0xb4/0x138
>> [C00000003FEDF900] [C00000000021913C] .bus_for_each_dev+0x7c/0xd4
>> [C00000003FEDF9C0] [C0000000002198B0] .driver_attach+0x28/0x40
>> [C00000003FEDFA40] [C000000000218BA4] .bus_add_driver+0x98/0x18c
>> [C00000003FEDFAE0] [C00000000021A064] .driver_register+0xa8/0xc4
>> [C00000003FEDFB60] [C0000000001B68AC] .__pci_register_driver+0x5c/0xa4
>> [C00000003FEDFBF0] [D00000000029C204] .sym2_init+0x104/0x1550 [sym53c8xx]
>> [C00000003FEDFC90] [C00000000008D1F4] .sys_init_module+0x1764/0x1998
>> [C00000003FEDFE30] [C00000000000869C] syscall_exit+0x0/0x40
>>
>
> hm, odd.
>
> Can you look up sym_hcb_attach+0x1194/0x1384 in gdb? Something like
>
Hi Andrew,
I tried with 2.6.24-rc3-git3 and got the following trace
BUG: soft lockup - CPU#2 stuck for 11s! [insmod:375]
NIP: c00000000002f02c LR: d0000000001414fc CTR: c00000000002f018
REGS: c00000077ca3b0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git3-autokern1)
MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24022088 XER: 00000000
TASK = c00000077cc58000[375] 'insmod' THREAD: c00000077ca38000 CPU: 2
GPR00: d0000000001414fc c00000077ca3b330 c00000000052b880 d000080080002014
GPR04: d00008008000202c 0000000000000000 c00000077c82eb00 d00000000014ce54
GPR08: c00000077c82e63c 0000000000000000 000000000000002a c00000000002f018
GPR12: d000000000143610 c000000000473f80
NIP [c00000000002f02c] .ioread8+0x14/0x60
LR [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
Call Trace:
[c00000077ca3b330] [c00000077ca3b3c0] 0xc00000077ca3b3c0 (unreliable)
[c00000077ca3b3a0] [d0000000001414fc] .sym_hcb_attach+0x1188/0x1378 [sym53c8xx]
[c00000077ca3b470] [d0000000001395f8] .sym2_probe+0x700/0x99c [sym53c8xx]
[c00000077ca3b710] [c0000000001bc098] .pci_device_probe+0x124/0x1b0
[c00000077ca3b7b0] [c0000000002210c4] .driver_probe_device+0x144/0x20c
[c00000077ca3b850] [c0000000002213dc] .__driver_attach+0xcc/0x154
[c00000077ca3b8e0] [c00000000021ff20] .bus_for_each_dev+0x7c/0xd4
[c00000077ca3b9a0] [c000000000220e28] .driver_attach+0x28/0x40
[c00000077ca3ba20] [c000000000220464] .bus_add_driver+0x90/0x228
[c00000077ca3bac0] [c0000000002217e4] .driver_register+0x94/0xb0
[c00000077ca3bb40] [c0000000001bc3b0] .__pci_register_driver+0x6c/0xcc
[c00000077ca3bbe0] [d000000000143428] .sym2_init+0x108/0x15b0 [sym53c8xx]
[c00000077ca3bc80] [c00000000008ce80] .sys_init_module+0x17c4/0x1958
[c00000077ca3be30] [c00000000000872c] syscall_exit+0x0/0x40
Instruction dump:
60000000 786b0420 38210070 7d635b78 e8010010 7c0803a6 4e800020 7c0802a6
f8010010 f821ff91 7c0004ac 89230000 <0c090000> 4c00012c 79290620 2f8900ff
The gdb list the following for the above trace
0xa4fc is in sym_hcb_attach (drivers/scsi/sym53c8xx_2/sym_hipd.c:1041).
1036 OUTL_DSP(np, pc);
1037 /*
1038 * Wait 'til done (with timeout)
1039 */
1040 for (i=0; i<SYM_SNOOP_TIMEOUT; i++)
1041 if (INB(np, nc_istat) & (INTF|SIP|DIP))
1042 break;
1043 if (i>=SYM_SNOOP_TIMEOUT) {
1044 printf ("CACHE TEST FAILED: timeout.\n");
1045 return (0x20);
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Dell Query @ 2007-11-29 6:41 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200711290710.29403.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]
I see. No wonder I couldn't get more information on BCSR. I should contact sequoia to get the proper details like the correct addresses.
I already used ioremap64(), remapping 0x1c0002000. I got a hex value for the Board ID but could figure out what it means. So I tried the USER_LED0/USER_LED1 (base address+0x2), to see if I could turn on/off the user LEDS, but still no luck.
I think I am accessing the wrong addresses so I need to verify it with them.
Thanks!
Regards,
dell
Stefan Roese <sr@denx.de> wrote: On Thursday 29 November 2007, Dell Query wrote:
> I don't know if the document that came with the PPC440EPx Sequoia Resource
> CD is right. It is odd that it is entitled "Embedded Planet 440xC" and it
> showed in page 34:
> -----------------------------------------------------------------------
> Table 4-4. Memory Map
>
> Function Start Address End Address Size Chip Select
> DDR SDRAM 0x0000 0000 0x0FFF FFFF 256 MB —
> PCI Memory 0x8000 0000 0xBFFF FFFF 1024 MB —
> BCSR 0xC000 0000 0xCFFF FFFF 256 MB CS2
> NAND FLASH Controller1 0xD000 0000 0xD00F FFFF 1 MB CS3/CS0
> NOR FLASH1 0xFC00 0000 0xFFFF FFFF 64 MB CS0/CS3
> -----------------------------------------------------------------------
> Anyway, I have seen Table 1. System Memory Address Map and it got EBC
> mapped at 0x1.c000.0000 and another one at 0x1.f000.0000. But I didn't see
> any BCSR info. Correct me if I am wrong, but should it not give me BCSR
> details like:
This is board specific information and not CPU specific. The CPLD with it's
BCSR is a Sequoia thing and can therefor not be listed in the 440EPx manuals.
It it located on the EBC though which is documented in the 440EPx manuals.
So if this chips select which is connected to the CPLD is mapped to
0xc000.0000 which is the case for Sequoia, then you will "find" these
registers at physical address 0x1.c000.0000. And should use ioremap64() to
get the virtual address to access this CPLD.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
---------------------------------
Get easy, one-click access to your favorites. Make Yahoo! your homepage.
[-- Attachment #2: Type: text/html, Size: 2947 bytes --]
^ permalink raw reply
* Re: Unable to Read PPC440EPx Board ID thru Board Control and Status Registers (BCSR)
From: Stefan Roese @ 2007-11-29 6:56 UTC (permalink / raw)
To: Dell Query; +Cc: linuxppc-embedded
In-Reply-To: <772588.56121.qm@web45611.mail.sp1.yahoo.com>
On Thursday 29 November 2007, Dell Query wrote:
> I see. No wonder I couldn't get more information on BCSR. I should contact
> sequoia to get the proper details like the correct addresses.
>
> I already used ioremap64(), remapping 0x1c0002000. I got a hex value for
> the Board ID but could figure out what it means. So I tried the
> USER_LED0/USER_LED1 (base address+0x2), to see if I could turn on/off the
> user LEDS, but still no luck. I think I am accessing the wrong addresses so
> I need to verify it with them.
Why do think you need the offset 0x2000? I just tested on my Sequoia under
U-Boot and "see" the CPLD at address 0xc000.0000:
=> md.b c0000000 20
c0000000: 0f 00 c0 07 00 80 00 80 00 20 00 00 00 00 00 00 ......... ......
c0000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
So you should map not 0x1.c000.2000 but 0x1.c000.0000 under Linux. Please let
me know if this works.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* SCC QMC driver Compilation
From: srikanth krishnakar @ 2007-11-29 7:23 UTC (permalink / raw)
To: Linuxppc-embedded
In-Reply-To: <6213bc560711282312t6e504846hceb81162e63310c9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2841 bytes --]
Hi panto,
Good Day,
I am trying to compile the QMC driver given for 2.4 kernel. but I am getting
the IOCTL errors. Will you please let me know the solution for these.
* Below is the log of Errors generated while compilation:**
*ppc_8xx-gcc -D__KERNEL__ -I/home/TEST_QMC/linux- 2.4.20_mvl31/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -I/home/TEST_QMC/linux-
2.4.20_mvl31/arch/ppc-fsigned-char -msoft-float -pipe -ffixed-r2
-Wno-uninitialized -mmultiple
-mstring -nostdinc -iwithprefix include -DKBUILD_BASENAME=qmc_core
-DEXPORT_SYMTAB -c qmc-core.c
qmc-core.c: In function `qmc_ioctl':
qmc-core.c:456: error: `QMC_IOC_MAGIC' undeclared (first use in this
function)
qmc-core.c:456: error: (Each undeclared identifier is reported only once
qmc-core.c:456: error: for each function it appears in.)
qmc-core.c:458: error: `QMC_IOC_MAXNR' undeclared (first use in this
function)
qmc-core.c:466: error: `QMC_IOCRESET' undeclared (first use in this
function)
qmc-core.c:469: error: `QMC_IOCSCONF' undeclared (first use in this
function)
qmc-core.c:470: error: `QMC_IOCGCONF' undeclared (first use in this
function)
qmc-core.c:471: error: storage size of `req' isn't known
qmc-core.c:471: warning: unused variable `req'
qmc-core.c :1012:2: #error Unknown board configuration.
qmc-core.c: In function `qmc_setup':
qmc-core.c:1311: error: `CLK_PCM_BIT' undeclared (first use in this
function)
qmc-core.c:1311: error: `X_PCMOUT1_BIT' undeclared (first use in this
function)
qmc-core.c:1311: error: `X_PCMIN1_BIT' undeclared (first use in this
function)
qmc-core.c:1313: error: `PCM_FS_BIT' undeclared (first use in this function)
qmc-core.c: In function `qmc_cleanup':
qmc-core.c :1640: error: `CLK_PCM_BIT' undeclared (first use in this
function)
qmc-core.c:1640: error: `X_PCMOUT1_BIT' undeclared (first use in this
function)
qmc-core.c:1640: error: `X_PCMIN1_BIT' undeclared (first use in this
function)
qmc-core.c: In function `devices_init':
qmc-core.c:1662: error: `QMC_MAJOR' undeclared (first use in this function)
qmc-core.c: In function `devices_cleanup':
qmc-core.c:1684: error: `QMC_MAJOR' undeclared (first use in this function)
make[3]: *** [qmc-core.o] Error 1
make[3]: Leaving directory `/home/TEST_QMC/linux-2.4.20_mvl31/drivers/qmc'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/home/TEST_QMC/linux-2.4.20_mvl31/drivers/qmc '
make[1]: *** [_subdir_qmc] Error 2
make[1]: Leaving directory `/home/TEST_QMC/linux-2.4.20_mvl31/drivers'
make: *** [_dir_drivers] Error 2
[root@smk linux-2.4.20_mvl31]# vi drivers/qmc/qmc-core.c +456 *
*
Waiting for your reply.
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 3579 bytes --]
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: vijay baskar @ 2007-11-29 7:29 UTC (permalink / raw)
To: 郭劲; +Cc: linuxppc-embedded
In-Reply-To: <396305910.05464@tsinghua.org.cn>
[-- Attachment #1: Type: text/html, Size: 3701 bytes --]
^ permalink raw reply
* [PATCH] PPC: CELLEB - fix possible NULL pointer dereference
From: Ishizaki Kou @ 2007-11-29 7:44 UTC (permalink / raw)
To: paulus; +Cc: gorcunov, olof, linux-kernel, linuxppc-dev
In-Reply-To: <aa79d98a0711282141l6b07569fmb925b198730a554e@mail.gmail.com>
From: Cyrill Gorcunov <gorcunov@gmail.com>
This patch adds checking for NULL returned value to
prevent possible NULL pointer dereference.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
---
Paul,
This is a resend of a patch from Cyrill. I changed it to inline style.
Cyrill,
This works good on Celleb. Thanks.
Best regards,
Kou Ishizaki
arch/powerpc/platforms/celleb/pci.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c b/arch/powerpc/platforms/celleb/pci.c
index 6bc32fd..13ec4a6 100644
--- a/arch/powerpc/platforms/celleb/pci.c
+++ b/arch/powerpc/platforms/celleb/pci.c
@@ -138,8 +138,6 @@ static void celleb_config_read_fake(unsigned char *config, int where,
*val = celleb_fake_config_readl(p);
break;
}
-
- return;
}
static void celleb_config_write_fake(unsigned char *config, int where,
@@ -158,7 +156,6 @@ static void celleb_config_write_fake(unsigned char *config, int where,
celleb_fake_config_writel(val, p);
break;
}
- return;
}
static int celleb_fake_pci_read_config(struct pci_bus *bus,
@@ -351,6 +348,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
wi1 = of_get_property(node, "vendor-id", NULL);
wi2 = of_get_property(node, "class-code", NULL);
wi3 = of_get_property(node, "revision-id", NULL);
+ if (!wi0 || !wi1 || !wi2 || !wi3) {
+ printk(KERN_ERR "PCI: Missing device tree properties.\n");
+ goto error;
+ }
celleb_config_write_fake(*config, PCI_DEVICE_ID, 2, wi0[0] & 0xffff);
celleb_config_write_fake(*config, PCI_VENDOR_ID, 2, wi1[0] & 0xffff);
@@ -372,6 +373,10 @@ static int __init celleb_setup_fake_pci_device(struct device_node *node,
celleb_setup_pci_base_addrs(hose, devno, fn, num_base_addr);
li = of_get_property(node, "interrupts", &rlen);
+ if (!li) {
+ printk(KERN_ERR "PCI: interrupts not found.\n");
+ goto error;
+ }
val = li[0];
celleb_config_write_fake(*config, PCI_INTERRUPT_PIN, 1, 1);
celleb_config_write_fake(*config, PCI_INTERRUPT_LINE, 1, val);
^ permalink raw reply related
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