RE: Linuxppc-dev Digest, Vol 40, Issue 57
From: Siva Prasad <hidden>
Date: 2007-12-06 17:56:36
Subsystem:
linux for powerpc (32-bit and 64-bit), the rest · Maintainers:
Madhavan Srinivasan, Linus Torvalds
Hello Bala, I don't think the ioremap issues are related with low memory offset mode. But again, I am not sure if you (system by default does not do it) are reserving that area (from 256 to 512 which is low memory offset region). Further, where do you get this 504 number specifically? If you want, I can try out your code on my 8641D board. Thanks Siva Date: Wed, 5 Dec 2007 17:45:01 -0800 (PST) From: sivaji <redacted> Subject: Re: Regarding MPC8641D To: linuxppc-dev@ozlabs.org Message-ID: [ref] Content-Type: text/plain; charset=3Dus-ascii Hi, We need only SMP mode, asper ur idea let me disable the Low memory offset mode. We face some issues when ioremap in the kernel, we guess the problem is related to Low memory offset mode so only we go for that. Consider now the Low memory offset is disable the bootargs (root=3D/dev/ram console=3DttyS0, mem=3D504M). When mem=3D504 or greater than we are not = able to ioremap, if mem is less than 500 there was no issues on ioremap. We can't understand why ioremap was failed for 504M? Thanks and Regards S.Balamurugan Siva Prasad-3 wrote:
=20 Hi, =20 If you want to use SMP, do not enable low memory offset mode. That is only and only for AMP, not for SMP. All the exception vectors go into
a
different address range for core1, once you enable that, resulting in
a
need for entirely different copy of OS (be it Linux, or any other OS). =20 You are in the right path. Just don't enable low memory offset mode, unless you are looking for Assymetric multi-processing. =20 - siva =20 =20 =20 =20 Message: 6 Date: Wed, 5 Dec 2007 16:45:31 -0800 (PST) From: sivaji <redacted> Subject: Re: Regarding MPC8641D To: linuxppc-dev@ozlabs.org Message-ID: [ref] Content-Type: text/plain; charset=3Dus-ascii =20 =20 Hai, The kernel was compiled in SMP mode. The low memory
offset
mode is only for AMP mode means, then how we test both the core 0 and 1 in the linux kernel ?. Asper my understanding if we enable the Low Memory Offset mode, then only the core1 translation is enabled. If we disalbed the
Low
Memory offset mode, Only Core 0 will work in SMP mode and Core 1 will idle. If we want to test the efficient of Dual core means we need to enable both the core and Low Memory Offset Mode. For this configuration linux
kernel
was not up. ( Please correct me if I am wrong ) =20 Thanks and Regards Sivaji =20 =20 Chris Fester wrote:quoted
=20 On Tue, 2007-12-04 at 23:51 -0800, sivaji wrote:quoted
We have designed a MPC8641D based AMC card. We are
using
thequoted
quoted
kernel (2.6.23-rc4) and uboot (1.2.0). When we disable the core1
Low
quoted
quoted
Memory offset mode the kernel was up and when we enable this core1 LowMemoryquoted
quoted
offset mode kernel was not up, It was hang after MPIC
initialization.
quoted
[snip!]quoted
After this the kernel was hang, i want to knowwhyquoted
quoted
kernel was hang when we enalbe Low memory Offset mode. Please help
me
toquoted
quoted
fix this issue.=20 Have you compiled your kernel for SMP mode? I believe the Low memory offset mode is only for AMP mode (vxworks can use this, probably
other
quoted
OSes). I don't know if the kernel has support for any
multiprocessing
quoted
mode other than SMP. =20 Hope that helps, Chris =20=20 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev =20 =20
--=20 View this message in context: http://www.nabble.com/Regarding-MPC8641D-tf4948004.html#a14184891 Sent from the linuxppc-dev mailing list archive at Nabble.com. ------------------------------ Message: 2 Date: Wed, 5 Dec 2007 20:55:05 -0500 From: "Jon Smirl" <redacted> Subject: Link up/down messages from 5200 ethernet driver To: "Grant Likely" <redacted>, "Domen Puncer" [off-list ref], "PowerPC dev list" [off-list ref] Message-ID: [ref] Content-Type: text/plain; charset=3DUTF-8 Why does the fec5200 driver sometimes not print 'PHY' correctly? phyCORE-MPC5200B-tiny login: T?V? f0003000:10 - Link is Down T?Y: f0003000:10 - Link is Up - 100/Full T?Y: f0003000:10 - Link is Down PHY: f0003000:10 - Link is Up - 100/Full --=20 Jon Smirl jonsmirl@gmail.com ------------------------------ Message: 3 Date: Thu, 6 Dec 2007 13:07:50 +1100 From: David Gibson <redacted> Subject: dtc: Remove space from flex command line To: Jon Loeliger <redacted> Cc: linuxppc-dev@ozlabs.org Message-ID: [ref] Content-Type: text/plain; charset=3Dus-ascii Author: Geoff Levand [off-list ref] Apparently some versions of flex don't correctly parse the -o parameter, if there's a space between the -o and its argument. So, this patch removes it. Signed-off-by: David Gibson <redacted> Index: dtc/Makefile =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
--- dtc.orig/Makefile 2007-12-06 13:03:41.000000000 +1100
+++ dtc/Makefile 2007-12-06 13:03:45.000000000 +1100@@ -206,7 +206,7 @@=20 %.lex.c: %.l @$(VECHO) LEX $@ - $(LEX) -o $@ $< + $(LEX) -o$@ $< =20 %.tab.c %.tab.h %.output: %.y @$(VECHO) BISON $@ --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ------------------------------ Message: 4 Date: Thu, 6 Dec 2007 13:39:19 +1100 From: Stephen Rothwell <redacted> Subject: [PATCH 1/2] [POWERPC] iommu_free_table doesn't need the device_node To: paulus@samba.org Cc: ppc-dev <redacted> Message-ID: [ref] Content-Type: text/plain; charset=3DUS-ASCII It only needs the iommu_table address. It also makes use of the node name to print error messages. So just pass it the things it needs. This reduces the places that know about the pci_dn by one. Signed-off-by: Stephen Rothwell <redacted> --- arch/powerpc/kernel/iommu.c | 8 +++----- arch/powerpc/platforms/pseries/iommu.c | 2 +- include/asm-powerpc/iommu.h | 3 +-- 3 files changed, 5 insertions(+), 8 deletions(-) --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 2d0c9ef..47c3fe5 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c@@ -526,16 +526,14 @@ struct iommu_table *iommu_init_table(structiommu_table *tbl, int nid)
return tbl;
}
=20
-void iommu_free_table(struct device_node *dn)
+void iommu_free_table(struct iommu_table *tbl, const char *node_name)
{
- struct pci_dn *pdn =3D dn->data;
- struct iommu_table *tbl =3D pdn->iommu_table;
unsigned long bitmap_sz, i;
unsigned int order;
=20
if (!tbl || !tbl->it_map) {
printk(KERN_ERR "%s: expected TCE map for %s\n",
__FUNCTION__,
- dn->full_name);
+ node_name);
return;
}
=20@@ -544,7 +542,7 @@ void iommu_free_table(struct device_node *dn) for (i =3D 0; i < (tbl->it_size/64); i++) { if (tbl->it_map[i] !=3D 0) { printk(KERN_WARNING "%s: Unexpected TCEs for
%s\n", - __FUNCTION__, dn->full_name); + __FUNCTION__, node_name); break; } }
diff --git a/arch/powerpc/platforms/pseries/iommu.cb/arch/powerpc/platforms/pseries/iommu.c index be17d23..d4e9d85 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c@@ -556,7 +556,7 @@ static int iommu_reconfig_notifier(structnotifier_block *nb, unsigned long acti case PSERIES_RECONFIG_REMOVE: if (pci && pci->iommu_table && of_get_property(np, "ibm,dma-window", NULL)) - iommu_free_table(np); + iommu_free_table(pci->iommu_table, np->full_name); break; default: err =3D NOTIFY_DONE;
diff --git a/include/asm-powerpc/iommu.h b/include/asm-powerpc/iommu.h
index 4a82fdc..7a3cef7 100644
--- a/include/asm-powerpc/iommu.h
+++ b/include/asm-powerpc/iommu.h@@ -69,10 +69,9 @@ struct iommu_table { };
=20 struct scatterlist; -struct device_node; =20 /* Frees table for an individual device node */ -extern void iommu_free_table(struct device_node *dn); +extern void iommu_free_table(struct iommu_table *tbl, const char *node_name); =20 /* Initializes an iommu_table based in values set in the passed-in * structure --=20 1.5.3.7 ------------------------------ Message: 5 Date: Thu, 6 Dec 2007 13:40:29 +1100 From: Stephen Rothwell <redacted> Subject: [PATCH 2/2] [POWERPC] pSeries: remove dependency on pci_dn bussubno To: paulus@samba.org Cc: ppc-dev <redacted> Message-ID: [ref] Content-Type: text/plain; charset=3DUS-ASCII Signed-off-by: Stephen Rothwell <redacted> --- arch/powerpc/platforms/pseries/iommu.c | 24 +++++++----------------- 1 files changed, 7 insertions(+), 17 deletions(-) --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/pseries/iommu.cb/arch/powerpc/platforms/pseries/iommu.c index d4e9d85..ebb9313 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c@@ -296,11 +296,12 @@ static void iommu_table_setparms(structpci_controller *phb,
static void iommu_table_setparms_lpar(struct pci_controller *phb,
struct device_node *dn,
struct iommu_table *tbl,
- const void *dma_window)
+ const void *dma_window,
+ int bussubno)
{
unsigned long offset, size;
=20
- tbl->it_busno =3D PCI_DN(dn)->bussubno;
+ tbl->it_busno =3D bussubno;
of_parse_dma_window(dn, dma_window, &tbl->it_index, &offset,
&size);
=20
tbl->it_base =3D 0;@@ -420,17 +421,10 @@ static void pci_dma_bus_setup_pSeriesLP(structpci_bus *bus)
pdn->full_name, ppci->iommu_table);
=20
if (!ppci->iommu_table) {
- /* Bussubno hasn't been copied yet.
- * Do it now because iommu_table_setparms_lpar needs it.
- */
-
- ppci->bussubno =3D bus->number;
-
tbl =3D kmalloc_node(sizeof(struct iommu_table),
GFP_KERNEL,
ppci->phb->node);
-
- iommu_table_setparms_lpar(ppci->phb, pdn, tbl,
dma_window);
-
+ iommu_table_setparms_lpar(ppci->phb, pdn, tbl,
dma_window,
+ bus->number);
ppci->iommu_table =3D iommu_init_table(tbl,
ppci->phb->node);
DBG(" created table: %p\n", ppci->iommu_table);
}@@ -523,14 +517,10 @@ static void pci_dma_dev_setup_pSeriesLP(structpci_dev *dev)
=20
pci =3D PCI_DN(pdn);
if (!pci->iommu_table) {
- /* iommu_table_setparms_lpar needs bussubno. */
- pci->bussubno =3D pci->phb->bus->number;
-
tbl =3D kmalloc_node(sizeof(struct iommu_table),
GFP_KERNEL,
pci->phb->node);
-
- iommu_table_setparms_lpar(pci->phb, pdn, tbl,
dma_window);
-
+ iommu_table_setparms_lpar(pci->phb, pdn, tbl,
dma_window,
+ pci->phb->bus->number);
pci->iommu_table =3D iommu_init_table(tbl,
pci->phb->node);
DBG(" created table: %p\n", pci->iommu_table);
} else {
--=20
1.5.3.7
------------------------------
Message: 6
Date: Thu, 06 Dec 2007 14:22:27 +1100
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH] pci: Fix bus resource assignment on 32 bits with
64b resources
To: Greg Kroah-Hartman <redacted>
Cc: linuxppc-dev@ozlabs.org, linux-pci@atrey.karlin.mff.cuni.cz,
linux-kernel@vger.kernel.org
Message-ID: <1196911347.7033.15.camel@pasglop>
Content-Type: text/plain
On Wed, 2007-12-05 at 17:40 +1100, Benjamin Herrenschmidt wrote:The current pci_assign_unassigned_resources() code doesn't work
properly
on 32 bits platforms with 64 bits resources. The main reason is the
use
of unsigned long in various places instead of resource_size_t. =20 This fixes it, along with some tricks to avoid casting to 64 bits on platforms that don't need it in every printk around. =20 This is a pre-requisite for making powerpc use the generic code
instead of
its own half-useful implementation. =20 Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> --- =20 This version fixes some stupid warnings when using 32 bits resources
... and has warnings on 64 bits platforms... GRRRR This whole issue of printk vs. resource_size_t is a terrible mess :-( Part of the problem is that resource_size_t can be either u32 or u64.. that is it can be either unsigned int, unsigned long or unsigned long long... and we have no way to reliably printk that. Any clever idea before I start pushing filthy macros up linux/types.h ? Cheers, Ben. ------------------------------ Message: 7 Date: Thu, 6 Dec 2007 14:32:47 +1100 From: Paul Mackerras <redacted> Subject: Re: [PATCH] Use SLB size from the device tree To: Michael Neuling <redacted> Cc: Olof Johansson <redacted>, linuxppc-dev@ozlabs.org, Will Schmidt [off-list ref] Message-ID: [ref] Content-Type: text/plain; charset=3Dus-ascii Michael Neuling writes:
Currently we hardwire the number of SLBs but the PAPR says we export
an
ibm,slb-size property to specify the number of SLB entries. This
patch
uses this property instead of assuming 64 always. If no property is found, we assume 64 entries as before.
On 32-bit platforms (e.g. powermac) I get: /home/paulus/kernel/powerpc/arch/powerpc/kernel/prom.c: In function 'check_cpu_slb_size': /home/paulus/kernel/powerpc/arch/powerpc/kernel/prom.c:592: error: 'mmu_slb_size' undeclared (first use in this function) /home/paulus/kernel/powerpc/arch/powerpc/kernel/prom.c:592: error: (Each undeclared identifier is reported only once /home/paulus/kernel/powerpc/arch/powerpc/kernel/prom.c:592: error: for each function it appears in.) make[2]: *** [arch/powerpc/kernel/prom.o] Error 1 Paul. ------------------------------ Message: 8 Date: Thu, 06 Dec 2007 14:48:18 +1100 From: Michael Ellerman <redacted> Subject: Re: drivers/net/iseries_veth.c dubious sysfs usage To: Greg KH <redacted> Cc: linuxppc-dev@ozlabs.org, "Kyle A. Lucke" <redacted>, paulus@samba.org, linux-kernel@vger.kernel.org, David Gibson [off-list ref] Message-ID: <1196912898.14754.13.camel@concordia> Content-Type: text/plain; charset=3D"us-ascii" On Wed, 2007-12-05 at 13:41 -0800, Greg KH wrote:
On Wed, Dec 05, 2007 at 10:10:31PM +1100, Michael Ellerman wrote:quoted
On Wed, 2007-12-05 at 01:30 -0800, Greg KH wrote:quoted
In doing a massive kobject cleanup of the kernel tree, I ran
across the
quoted
quoted
iseries_veth.c driver. =20 It looks like the driver is creating a number of subdirectories
under
quoted
quoted
the driver sysfs directory. This is odd and probably wrong. You
want
quoted
quoted
these virtual connections to show up in the main sysfs device
tree, not
quoted
quoted
under the driver directory. =20 I'll be glad to totally guess and try to move it around in the
sysfs
quoted
quoted
tree, but odds are I'll get it all wrong as I can't really test
this
quoted
quoted
out :) =20 Any hints on what this driver is trying to do in this sysfs
directories?
quoted
=20 I wrote the code, I think, but it's been a while - I'll have a look
at
quoted
it tomorrow.=20 Yes, can you send me the sysfs tree output of the driver directory,
and
what exactly the different files in there are supposed to be used for?
Sure. My version of tar (1.15.1) doesn't seem to be able to tar up /sys, so hopefully this is sufficient: igoeast:~# cd /sys/class/net/eth1/ igoeast:/sys/class/net/eth1# ls -la total 0 drwxr-xr-x 4 root root 0 Dec 6 10:22 . drwxr-xr-x 6 root root 0 Dec 6 10:21 .. -r--r--r-- 1 root root 4096 Dec 6 10:30 addr_len -r--r--r-- 1 root root 4096 Dec 6 10:30 address -r--r--r-- 1 root root 4096 Dec 6 10:30 broadcast -r--r--r-- 1 root root 4096 Dec 6 10:30 carrier lrwxrwxrwx 1 root root 0 Dec 6 10:22 device -> ../../../devices/vio/3 -r--r--r-- 1 root root 4096 Dec 6 10:30 dormant -r--r--r-- 1 root root 4096 Dec 6 10:30 features -rw-r--r-- 1 root root 4096 Dec 6 10:30 flags -r--r--r-- 1 root root 4096 Dec 6 10:30 ifindex -r--r--r-- 1 root root 4096 Dec 6 10:30 iflink -r--r--r-- 1 root root 4096 Dec 6 10:30 link_mode -rw-r--r-- 1 root root 4096 Dec 6 10:30 mtu -r--r--r-- 1 root root 4096 Dec 6 10:30 operstate drwxr-xr-x 2 root root 0 Dec 6 10:30 statistics lrwxrwxrwx 1 root root 0 Dec 6 10:30 subsystem -> ../../../class/net -rw-r--r-- 1 root root 4096 Dec 6 10:30 tx_queue_len -r--r--r-- 1 root root 4096 Dec 6 10:30 type -rw-r--r-- 1 root root 4096 Dec 6 10:30 uevent drwxr-xr-x 2 root root 0 Dec 6 10:30 veth_port Each net device has a port structure associated with it, the fields should be fairly self explanatory, they're all read only I think. igoeast:/sys/class/net/eth1# find veth_port/ veth_port/ veth_port/mac_addr veth_port/lpar_map veth_port/stopped_map veth_port/promiscuous veth_port/num_mcast igoeast:/sys/class/net/eth1# cd device/driver igoeast:/sys/class/net/eth1/device/driver# ls -l total 0 lrwxrwxrwx 1 root root 0 Dec 6 10:21 2 -> ../../../../devices/vio/2 lrwxrwxrwx 1 root root 0 Dec 6 10:21 3 -> ../../../../devices/vio/3 --w------- 1 root root 4096 Dec 6 10:21 bind drwxr-xr-x 2 root root 0 Dec 6 10:21 cnx00 drwxr-xr-x 2 root root 0 Dec 6 10:21 cnx02 drwxr-xr-x 2 root root 0 Dec 6 10:21 cnx03 drwxr-xr-x 2 root root 0 Dec 6 10:21 cnx04 lrwxrwxrwx 1 root root 0 Dec 6 10:21 module -> ../../../../module/iseries_veth --w------- 1 root root 4096 Dec 6 10:21 uevent --w------- 1 root root 4096 Dec 6 10:21 unbind The driver has a connection to all the other lpars, this is entirely independent of the net devices. igoeast:/sys/class/net/eth1/device/driver# find cnx00/ cnx00/ cnx00/outstanding_tx cnx00/remote_lp cnx00/num_events cnx00/reset_timeout cnx00/last_contact cnx00/state cnx00/src_inst cnx00/dst_inst cnx00/num_pending_acks cnx00/num_ack_events cnx00/ack_timeout
quoted
Why is it "odd and probably wrong" to create subdirectories under
the
quoted
driver in sysfs?=20 Because a driver does not have "devices" under it in the sysfs tree. All devices liven in the /sys/devices/ tree so we can properly manage them that way. A driver will then bind to a device, and the driver
core
will set up the linkages in sysfs properly so that everthing looks uniform.
OK. They're not "devices" that we create under the driver, they're just attributes of the driver, and they happen to be in groups so I put them in subdirectories. cheers --=20 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://ozlabs.org/pipermail/linuxppc-dev/attachments/20071206/f7bfe206/a ttachment-0001.pgp=20 ------------------------------ Message: 9 Date: Wed, 5 Dec 2007 21:46:53 -0700 From: "Grant Likely" <redacted> Subject: Re: Link up/down messages from 5200 ethernet driver To: "Jon Smirl" <redacted> Cc: PowerPC dev list <redacted>, Domen Puncer [off-list ref] Message-ID: [ref] Content-Type: text/plain; charset=3DUTF-8 On 12/5/07, Jon Smirl [off-list ref] wrote:
Why does the fec5200 driver sometimes not print 'PHY' correctly? phyCORE-MPC5200B-tiny login: T?V? f0003000:10 - Link is Down T?Y: f0003000:10 - Link is Up - 100/Full T?Y: f0003000:10 - Link is Down PHY: f0003000:10 - Link is Up - 100/Full
Weird; that line comes from drivers/net/phy/phy.c in phy_print_status(), and it's just a a pr_info statement. I suppose it might be a stack overrun, but I'd expect more severe symptoms if that was the case. That *looks* like a serial stream corruption. Is that the output of your serial port? Does dmesg show the same corruption? Cheers, g. --=20 Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely@secretlab.ca (403) 399-0195 ------------------------------ _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev End of Linuxppc-dev Digest, Vol 40, Issue 57 ********************************************