2.6.31-rc7 : kernel BUG at drivers/rtc/rtc-ps3.c:36!
While trying to boot 2.6.31-rc7 on a power6 machine came
across the following Bug.
Starting udev: [ cut here ]
kernel BUG at drivers/rtc/rtc-ps3.c:36!
cpu 0x0: Vector: 700 (Program Check) at [c000f70f3570]
pc: c059a020: .ps3_get_time+0x3c/0x84
lr: c059a018: .ps3_get_time+0x34/0x84
sp: c000f70f37f0
msr: 80029032
current = 0xc000f8d14ee0
paca= 0xc12cc300
pid = 159, comm = hwclock
kernel BUG at drivers/rtc/rtc-ps3.c:36!
enter ? for help
[c000f70f3890] c0593918 .rtc_read_time+0xac/0xe8
[c000f70f3930] c0594508 .rtc_dev_ioctl+0x358/0x5a4
[c000f70f3a40] c01df868 .vfs_ioctl+0x70/0x10c
[c000f70f3af0] c01e00a0 .do_vfs_ioctl+0x6d8/0x748
[c000f70f3be0] c01e0198 .SyS_ioctl+0x88/0xd0
[c000f70f3ca0] c0221fc8 .do_ioctl32_pointer+0x3c/0x5c
[c000f70f3d40] c0226ef0 .compat_sys_ioctl+0x43c/0x4c4
[c000f70f3e30] c00085f0 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 0fee33e8
SP (ffe0c7d0) is in userspace
0:mon
0:mon di $.ps3_get_time
c0599fe4 7c0802a6 mflrr0
c0599fe8 f8010010 std r0,16(r1)
c0599fec fb81ffe0 std r28,-32(r1)
c0599ff0 fba1ffe8 std r29,-24(r1)
c0599ff4 fbe1fff8 std r31,-8(r1)
c0599ff8 f821ff61 stdur1,-160(r1)
c0599ffc 7c3f0b78 mr r31,r1
c059a000 7c9d2378 mr r29,r4
c059a004 6000 nop
...
c059a00c 387f0070 addir3,r31,112
c059a010 389f0078 addir4,r31,120
c059a014 4baf1235 bl c008b248#
._lv1_get_rtc+0x0/0x3c
c059a018 6000 nop
c059a01c 7c6307b4 extsw r3,r3
c059a020 0b03 tdnei r3,0
0:mon
0:mon r
R00 = c059a018 R16 =
R01 = c000f70f37f0 R17 = ffe0cb50
R02 = c1274d30 R18 =
R03 = fffe R19 = 1002
R04 = c000f70f3868 R20 =
R05 = 0004 R21 = 00033790
R06 = c000f70f39d4 R22 = 4a923592
R07 = R23 = 0001
R08 = 07c0 R24 = 40247009
R09 = c125d708 R25 = c0783208
R10 = c000f742cf80 R26 = ffea
R11 = c000f70f3868 R27 = c000f70f39b0
R12 = 4000 R28 = c000f742cd10
R13 = c12cc300 R29 = c000f70f39b0
R14 = 10019d40 R30 = c1213148
R15 = ffe0cc7b R31 = c000f70f37f0
pc = c059a020 .ps3_get_time+0x3c/0x84
lr = c059a018 .ps3_get_time+0x34/0x84
msr = 80029032 cr = 44222424
ctr = c0599fe4 xer = 0001 trap = 700
0:mon
Corresponding c code is :
static u64 read_rtc(void)
{
result = lv1_get_rtc(rtc_val, tb_val);
BUG_ON(result);
I had never tried enabling CONFIG_RTC_DRV_PS3 option before
so not sure if this is a new problem or an old one.
Thanks
-Sachin
--
-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.31-rc7 : kernel BUG at drivers/rtc/rtc-ps3.c:36!
On Mon, 2009-08-24 at 12:31 +0530, Sachin Sant wrote:
While trying to boot 2.6.31-rc7 on a power6 machine came
across the following Bug.
Starting udev: [ cut here ]
kernel BUG at drivers/rtc/rtc-ps3.c:36!
cpu 0x0: Vector: 700 (Program Check) at [c000f70f3570]
pc: c059a020: .ps3_get_time+0x3c/0x84
lr: c059a018: .ps3_get_time+0x34/0x84
sp: c000f70f37f0
msr: 80029032
current = 0xc000f8d14ee0
paca= 0xc12cc300
pid = 159, comm = hwclock
kernel BUG at drivers/rtc/rtc-ps3.c:36!
static u64 read_rtc(void)
{
result = lv1_get_rtc(rtc_val, tb_val);
BUG_ON(result);
I had never tried enabling CONFIG_RTC_DRV_PS3 option before
so not sure if this is a new problem or an old one.
Looks like an old one, or at least as long as the driver has existed.
The code needs to cope with being called on something other than a PS3.
Either the platform driver is only registered if the machine is a PS3,
or ps3_rtc_probe() actually does something to check it's on a PS3 before
registering the rtc_device.
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.31-rc7 : kernel BUG at drivers/rtc/rtc-ps3.c:36!
On Mon, 24 Aug 2009, Michael Ellerman wrote:
On Mon, 2009-08-24 at 12:31 +0530, Sachin Sant wrote:
While trying to boot 2.6.31-rc7 on a power6 machine came
across the following Bug.
Starting udev: [ cut here ]
kernel BUG at drivers/rtc/rtc-ps3.c:36!
cpu 0x0: Vector: 700 (Program Check) at [c000f70f3570]
pc: c059a020: .ps3_get_time+0x3c/0x84
lr: c059a018: .ps3_get_time+0x34/0x84
sp: c000f70f37f0
msr: 80029032
current = 0xc000f8d14ee0
paca= 0xc12cc300
pid = 159, comm = hwclock
kernel BUG at drivers/rtc/rtc-ps3.c:36!
static u64 read_rtc(void)
{
result = lv1_get_rtc(rtc_val, tb_val);
BUG_ON(result);
I had never tried enabling CONFIG_RTC_DRV_PS3 option before
so not sure if this is a new problem or an old one.
Looks like an old one, or at least as long as the driver has existed.
The code needs to cope with being called on something other than a PS3.
Either the platform driver is only registered if the machine is a PS3,
or ps3_rtc_probe() actually does something to check it's on a PS3 before
registering the rtc_device.
Bummer, how could we have missed that one?
Cooking a patch...
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre 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.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH for 2.6.31] powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration
On non-PS3, we get:
| kernel BUG at drivers/rtc/rtc-ps3.c:36!
because the rtc-ps3 platform device is registered unconditionally in a kernel
with builtin support for PS3.
Reported-by: Sachin Sant sach...@in.ibm.com
Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
---
arch/powerpc/platforms/ps3/time.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/time.c
b/arch/powerpc/platforms/ps3/time.c
index b178a1e..40b5cb4 100644
--- a/arch/powerpc/platforms/ps3/time.c
+++ b/arch/powerpc/platforms/ps3/time.c
@@ -21,6 +21,7 @@
#include linux/kernel.h
#include linux/platform_device.h
+#include asm/firmware.h
#include asm/rtc.h
#include asm/lv1call.h
#include asm/ps3.h
@@ -84,6 +85,9 @@ static int __init ps3_rtc_init(void)
{
struct platform_device *pdev;
+ if (!firmware_has_feature(FW_FEATURE_PS3_LV1))
+ return -ENODEV;
+
pdev = platform_device_register_simple(rtc-ps3, -1, NULL, 0);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
--
1.6.2.4
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre 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.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH for 2.6.31] powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration
Geert Uytterhoeven wrote: On non-PS3, we get: | kernel BUG at drivers/rtc/rtc-ps3.c:36! because the rtc-ps3 platform device is registered unconditionally in a kernel with builtin support for PS3. Reported-by: Sachin Sant sach...@in.ibm.com Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com --- arch/powerpc/platforms/ps3/time.c |4 1 files changed, 4 insertions(+), 0 deletions(-) Thanks, boots fine now. Tested-by : Sachin Sant sach...@in.ibm.com Regards -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH for 2.6.31] powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration
On Mon, 24 Aug 2009, Sachin Sant wrote: Geert Uytterhoeven wrote: On non-PS3, we get: | kernel BUG at drivers/rtc/rtc-ps3.c:36! because the rtc-ps3 platform device is registered unconditionally in a kernel with builtin support for PS3. Reported-by: Sachin Sant sach...@in.ibm.com Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com --- arch/powerpc/platforms/ps3/time.c |4 1 files changed, 4 insertions(+), 0 deletions(-) Thanks, boots fine now. Tested-by : Sachin Sant sach...@in.ibm.com Thanks for testing! We want this for 2.6.30-stable, too. With kind regards, Geert Uytterhoeven Software Architect Techsoft Centre Technology and Software Centre 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.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Doubt about powerpc7447a
Is it possible to change operating speed of powerpc7447a processor?can we configure it? I m not asking if this can be done in linux. I m asking if the hardware has some support for this.If yes,then how? -sumedh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc/mm: Add MMU features for TLB reservation Paired MAS registers
On Aug 19, 2009, at 7:43 PM, Benjamin Herrenschmidt wrote: On Wed, 2009-08-19 at 16:37 -0500, Kumar Gala wrote: On Aug 19, 2009, at 2:25 AM, Benjamin Herrenschmidt wrote: The whole thing only ever gets called if we had tlbsrx. so is there any utility in making a part of conditional on tlbsrx? I don't think so ... this is the second level TLB miss handler when the first level takes a hit on the virtually linear page tables, I has nothing to do with tlbsrx... however, it does offset the return address back into the first level handler by -4 to account for replaying the tlbsrx instruction which you probably don't want to do. Duh. Wasn't looking at the fall through. But is there any reason to even have any of the 6 instructions in the 'virt_page_table_tlb_miss_done' path if we don't have TLBSRX? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Name xpn x fields in HW pte format
Previously, the 36-bit code was using these bits, but they had
never been named in the pte format definition. This patch just
gives those fields their proper names and adds a comment that
they are only present on some processors.
There is no functional code change.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/mmu-hash32.h | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-hash32.h
b/arch/powerpc/include/asm/mmu-hash32.h
index 382fc68..16f513e 100644
--- a/arch/powerpc/include/asm/mmu-hash32.h
+++ b/arch/powerpc/include/asm/mmu-hash32.h
@@ -55,21 +55,25 @@ struct ppc_bat {
#ifndef __ASSEMBLY__
-/* Hardware Page Table Entry */
+/*
+ * Hardware Page Table Entry
+ * Note that the xpn and x bitfields are used only by processors that
+ * support extended addressing; otherwise, those bits are reserved.
+ */
struct hash_pte {
unsigned long v:1; /* Entry is valid */
unsigned long vsid:24; /* Virtual segment identifier */
unsigned long h:1; /* Hash algorithm indicator */
unsigned long api:6;/* Abbreviated page index */
unsigned long rpn:20; /* Real (physical) page number */
- unsigned long:3;/* Unused */
+ unsigned long xpn:3;/* Real page number bits 0-2, optional */
unsigned long r:1; /* Referenced */
unsigned long c:1; /* Changed */
unsigned long w:1; /* Write-thru cache mode */
unsigned long i:1; /* Cache inhibited */
unsigned long m:1; /* Memory coherence */
unsigned long g:1; /* Guarded */
- unsigned long :1; /* Unused */
+ unsigned long x:1; /* Real page number bit 3, optional */
unsigned long pp:2; /* Page protection */
};
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Change archdata dma_data type to dma_addr_t
Previously, this was specified as a void *, but that's not
large enough on 32-bit systems with 36-bit physical
addressing support. Change the type to dma_addr_t so it
will scale based on the size of a dma address.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/device.h|2 +-
arch/powerpc/include/asm/dma-mapping.h |2 +-
arch/powerpc/kernel/dma-iommu.c | 21 +
arch/powerpc/kernel/dma.c|6 +++---
arch/powerpc/kernel/pci-common.c |2 +-
arch/powerpc/kernel/vio.c|3 ++-
arch/powerpc/platforms/cell/beat_iommu.c |2 +-
arch/powerpc/platforms/cell/iommu.c |6 +++---
arch/powerpc/platforms/iseries/iommu.c |2 +-
arch/powerpc/platforms/pasemi/iommu.c|2 +-
arch/powerpc/platforms/pseries/iommu.c | 11 +++
arch/powerpc/sysdev/dart_iommu.c |2 +-
12 files changed, 35 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/device.h
b/arch/powerpc/include/asm/device.h
index 67fcd7f..07818ae 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -15,7 +15,7 @@ struct dev_archdata {
/* DMA operations on that device */
struct dma_map_ops *dma_ops;
- void*dma_data;
+ dma_addr_t dma_data;
#ifdef CONFIG_SWIOTLB
dma_addr_t max_direct_dma_addr;
#endif
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index cb2ca41..cf65ebb 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -26,7 +26,7 @@ extern void *dma_direct_alloc_coherent(struct device *dev,
size_t size,
extern void dma_direct_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle);
-extern unsigned long get_dma_direct_offset(struct device *dev);
+extern dma_addr_t get_dma_direct_offset(struct device *dev);
#ifdef CONFIG_NOT_COHERENT_CACHE
/*
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index 87ddb3f..13eef19 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -11,6 +11,11 @@
* Generic iommu implementation
*/
+static inline struct iommu_table *get_iommu_table_base(struct device *dev)
+{
+ return (struct iommu_table *)dev-archdata.dma_data;
+}
+
/* Allocates a contiguous real buffer and creates mappings over it.
* Returns the virtual address of the buffer and sets dma_handle
* to the dma address (mapping) of the first page.
@@ -18,7 +23,7 @@
static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
- return iommu_alloc_coherent(dev, dev-archdata.dma_data, size,
+ return iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
dma_handle, device_to_mask(dev), flag,
dev_to_node(dev));
}
@@ -26,7 +31,7 @@ static void *dma_iommu_alloc_coherent(struct device *dev,
size_t size,
static void dma_iommu_free_coherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle)
{
- iommu_free_coherent(dev-archdata.dma_data, size, vaddr, dma_handle);
+ iommu_free_coherent(get_iommu_table_base(dev), size, vaddr, dma_handle);
}
/* Creates TCEs for a user provided buffer. The user buffer must be
@@ -39,8 +44,8 @@ static dma_addr_t dma_iommu_map_page(struct device *dev,
struct page *page,
enum dma_data_direction direction,
struct dma_attrs *attrs)
{
- return iommu_map_page(dev, dev-archdata.dma_data, page, offset, size,
- device_to_mask(dev), direction, attrs);
+ return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
+ size, device_to_mask(dev), direction, attrs);
}
@@ -48,7 +53,7 @@ static void dma_iommu_unmap_page(struct device *dev,
dma_addr_t dma_handle,
size_t size, enum dma_data_direction direction,
struct dma_attrs *attrs)
{
- iommu_unmap_page(dev-archdata.dma_data, dma_handle, size, direction,
+ iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size, direction,
attrs);
}
@@ -57,7 +62,7 @@ static int dma_iommu_map_sg(struct device *dev, struct
scatterlist *sglist,
int nelems, enum dma_data_direction direction,
struct dma_attrs *attrs)
{
- return iommu_map_sg(dev, dev-archdata.dma_data, sglist, nelems,
+ return iommu_map_sg(dev, get_iommu_table_base(dev), sglist, nelems,
device_to_mask(dev), direction,
Re: [PATCH for 2.6.31] powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration
On 08/24/2009 01:54 AM, Geert Uytterhoeven wrote: On non-PS3, we get: | kernel BUG at drivers/rtc/rtc-ps3.c:36! because the rtc-ps3 platform device is registered unconditionally in a kernel with builtin support for PS3. Reported-by: Sachin Sant sach...@in.ibm.com Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com --- arch/powerpc/platforms/ps3/time.c |4 1 files changed, 4 insertions(+), 0 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Change archdata dma_data type to dma_addr_t
On Mon, Aug 24, 2009 at 11:17:14AM -0500, Becky Bruce wrote:
Previously, this was specified as a void *, but that's not
large enough on 32-bit systems with 36-bit physical
addressing support. Change the type to dma_addr_t so it
will scale based on the size of a dma address.
This looks extreml ugly to me. It seems like the typical use is to
store a pointer to a structure. So what about making the direct
dma case follow that general scheme instead?
E.g. declare a
struct direct_dma_data {
dma_addr_t direct_dma_offset;
};
and have one normal instace of it, and one per weird cell device.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
gianfar.c: Unwanted VLAN tagging on TX frames
Hello everyone,
I have the Freescale's MPC8313erdb eval board and run the latest stable linux
kernel version (linux-2.6.30.5).
After creating a VLAN device (e.g. eth0.2) a VLAN tag is also inserted into
frames that don't relate to a VLAN device. This is the case for frames that
are directly sent through a standard ethernet interface (e.g. eth0).
When creating a VLAN device the gianfar driver enables the hardware supported
VLAN tagging on TX frames. This is done by setting the VLINS bit of the TCTRL
register inside the function gianfar_vlan_rx_register().
The problem is that every outgoing frame will be tagged. For frames from an
interface like eth0 the VLN bit of the FCB isn't set. Therefore the eTSEC uses
the content of the Default VLAN control word register (DFVLAN) to tag the
frame. As long as this register will not be modified after a reset of the
controller the outgoing frames will be tagged with VID = 0 (priority tagged
frames).
The following patch solves this problem.
diff -uprN linux-2.6.30.5_orig//drivers/net/gianfar.c
linux-2.6.30.5/drivers/net/gianfar.c
--- linux-2.6.30.5_orig//drivers/net/gianfar.c 2009-08-16 23:19:38.0
+0200
+++ linux-2.6.30.5/drivers/net/gianfar.c2009-08-22 10:38:28.0
+0200
@@ -1309,6 +1309,7 @@ static int gfar_start_xmit(struct sk_buf
u32 bufaddr;
unsigned long flags;
unsigned int nr_frags, length;
+ u32 tempval;
base = priv-tx_bd_base;
@@ -1385,13 +1386,30 @@ static int gfar_start_xmit(struct sk_buf
gfar_tx_checksum(skb, fcb);
}
- if (priv-vlgrp vlan_tx_tag_present(skb)) {
- if (unlikely(NULL == fcb)) {
- fcb = gfar_add_fcb(skb);
- lstatus |= BD_LFLAG(TXBD_TOE);
- }
+ if (priv-vlgrp) {
+ if (vlan_tx_tag_present(skb)) {
+ if (unlikely(NULL == fcb)) {
+ fcb = gfar_add_fcb(skb);
+ lstatus |= BD_LFLAG(TXBD_TOE);
+ }
+
+ /* Enable VLAN tag insertion for frames from VLAN
devices */
+ tempval = gfar_read(priv-regs-tctrl);
+ if ( !(tempval TCTRL_VLINS) ) {
+ tempval |= TCTRL_VLINS;
+ gfar_write(priv-regs-tctrl, tempval);
+ }
- gfar_tx_vlan(skb, fcb);
+ gfar_tx_vlan(skb, fcb);
+ }
+ else {
+ /* Disable VLAN tag insertion for frames that are not
from a VLAN device */
+ tempval = gfar_read(priv-regs-tctrl);
+ if ( tempval TCTRL_VLINS ) {
+ tempval = ~TCTRL_VLINS;
+ gfar_write(priv-regs-tctrl, tempval);
+ }
+ }
}
/* setup the TxBD length and buffer pointer for the first BD */
@@ -1484,23 +1502,11 @@ static void gfar_vlan_rx_register(struct
priv-vlgrp = grp;
if (grp) {
- /* Enable VLAN tag insertion */
- tempval = gfar_read(priv-regs-tctrl);
- tempval |= TCTRL_VLINS;
-
- gfar_write(priv-regs-tctrl, tempval);
-
/* Enable VLAN tag extraction */
tempval = gfar_read(priv-regs-rctrl);
- tempval |= RCTRL_VLEX;
tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
gfar_write(priv-regs-rctrl, tempval);
} else {
- /* Disable VLAN tag insertion */
- tempval = gfar_read(priv-regs-tctrl);
- tempval = ~TCTRL_VLINS;
- gfar_write(priv-regs-tctrl, tempval);
-
/* Disable VLAN tag extraction */
tempval = gfar_read(priv-regs-rctrl);
tempval = ~RCTRL_VLEX;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: gianfar.c: Unwanted VLAN tagging on TX frames
On Mon, Aug 24, 2009 at 11:10 AM, Torsten Fleischer
to-fleisc...@t-online.de wrote:
Hello everyone,
I have the Freescale's MPC8313erdb eval board and run the latest stable
linux
kernel version (linux-2.6.30.5).
After creating a VLAN device (e.g. eth0.2) a VLAN tag is also inserted into
frames that don't relate to a VLAN device. This is the case for frames that
are directly sent through a standard ethernet interface (e.g. eth0).
When creating a VLAN device the gianfar driver enables the hardware
supported
VLAN tagging on TX frames. This is done by setting the VLINS bit of the
TCTRL
register inside the function gianfar_vlan_rx_register().
The problem is that every outgoing frame will be tagged. For frames from
an
interface like eth0 the VLN bit of the FCB isn't set. Therefore the eTSEC
uses
the content of the Default VLAN control word register (DFVLAN) to tag the
frame. As long as this register will not be modified after a reset of the
controller the outgoing frames will be tagged with VID = 0 (priority tagged
frames).
The following patch solves this problem.
diff -uprN linux-2.6.30.5_orig//drivers/net/gianfar.c
linux-2.6.30.5/drivers/net/gianfar.c
--- linux-2.6.30.5_orig//drivers/net/gianfar.c 2009-08-16
23:19:38.0 +0200
+++ linux-2.6.30.5/drivers/net/gianfar.c2009-08-22
10:38:28.0 +0200
@@ -1309,6 +1309,7 @@ static int gfar_start_xmit(struct sk_buf
u32 bufaddr;
unsigned long flags;
unsigned int nr_frags, length;
+ u32 tempval;
base = priv-tx_bd_base;
@@ -1385,13 +1386,30 @@ static int gfar_start_xmit(struct sk_buf
gfar_tx_checksum(skb, fcb);
}
- if (priv-vlgrp vlan_tx_tag_present(skb)) {
- if (unlikely(NULL == fcb)) {
- fcb = gfar_add_fcb(skb);
- lstatus |= BD_LFLAG(TXBD_TOE);
- }
+ if (priv-vlgrp) {
+ if (vlan_tx_tag_present(skb)) {
+ if (unlikely(NULL == fcb)) {
+ fcb = gfar_add_fcb(skb);
+ lstatus |= BD_LFLAG(TXBD_TOE);
+ }
+
+ /* Enable VLAN tag insertion for frames from VLAN
devices */
+ tempval = gfar_read(priv-regs-tctrl);
+ if ( !(tempval TCTRL_VLINS) ) {
+ tempval |= TCTRL_VLINS;
+ gfar_write(priv-regs-tctrl, tempval);
+ }
- gfar_tx_vlan(skb, fcb);
+ gfar_tx_vlan(skb, fcb);
+ }
+ else {
+ /* Disable VLAN tag insertion for frames that are
not from a VLAN device */
+ tempval = gfar_read(priv-regs-tctrl);
+ if ( tempval TCTRL_VLINS ) {
+ tempval = ~TCTRL_VLINS;
+ gfar_write(priv-regs-tctrl, tempval);
+ }
+ }
}
Hmmmhow have you tested this? This looks like it has a bad race
condition. The TCTRL register applies to all packets, which means if you
send a packet with VLAN tags, followed by one without, or visa versa,
there's a reasonable chance that the second packet's VLAN tags (or lack
thereof) will take precedence.
Without speaking for the company, I suspect that this is just how the eTSEC
works with VLAN -- all, or nothing.
Andy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch] powerpc/ps3: Update ps3_defconfig
Signed-off-by: Geoff Levand geoffrey.lev...@am.sony.com --- Hi Ben, Please send upstream if it is not too late. -Geoff arch/powerpc/configs/ps3_defconfig | 211 + 1 file changed, 75 insertions(+), 136 deletions(-) --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -1,13 +1,14 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc5 -# Fri May 15 10:37:00 2009 +# Linux kernel version: 2.6.31-rc7 +# Mon Aug 24 17:38:50 2009 # CONFIG_PPC64=y # # Processor support # +CONFIG_PPC_BOOK3S_64=y CONFIG_PPC_BOOK3S=y # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y @@ -20,6 +21,7 @@ CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y +CONFIG_PPC_HAVE_PMU_SUPPORT=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_64BIT=y @@ -31,6 +33,7 @@ CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y @@ -41,7 +44,6 @@ CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y @@ -62,6 +64,7 @@ CONFIG_DTC=y # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y # # General setup @@ -113,7 +116,6 @@ CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y -# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y @@ -126,7 +128,14 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_COUNTERS=y + +# +# Performance Counters +# +# CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y +# CONFIG_STRIP_ASM_SYMS is not set # CONFIG_COMPAT_BRK is not set CONFIG_SLAB=y # CONFIG_SLUB is not set @@ -145,6 +154,11 @@ CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y + +# +# GCOV-based kernel profiling +# +# CONFIG_GCOV_KERNEL is not set # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y @@ -210,7 +224,7 @@ CONFIG_PPC_CELL=y # # Cell Broadband Engine options # -CONFIG_SPU_FS=y +CONFIG_SPU_FS=m CONFIG_SPU_FS_64K_LS=y # CONFIG_SPU_TRACE is not set CONFIG_SPU_BASE=y @@ -255,6 +269,7 @@ CONFIG_BINFMT_MISC=y CONFIG_HUGETLB_PAGE_SIZE_VARIABLE=y # CONFIG_IOMMU_VMERGE is not set CONFIG_IOMMU_HELPER=y +# CONFIG_SWIOTLB is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_HAS_WALK_MEMORY=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y @@ -285,9 +300,9 @@ CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y -CONFIG_UNEVICTABLE_LRU=y CONFIG_HAVE_MLOCK=y CONFIG_HAVE_MLOCKED_PAGE_BIT=y +CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_MEMORY_PROBE=y CONFIG_PPC_HAS_HASH_64K=y CONFIG_PPC_4K_PAGES=y @@ -399,6 +414,7 @@ CONFIG_IPV6_NDISC_NODETYPE=y # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_PHONET is not set +# CONFIG_IEEE802154 is not set # CONFIG_NET_SCHED is not set # CONFIG_DCB is not set @@ -433,11 +449,14 @@ CONFIG_BT_HCIBTUSB=m CONFIG_WIRELESS=y CONFIG_CFG80211=m # CONFIG_CFG80211_REG_DEBUG is not set +# CONFIG_CFG80211_DEBUGFS is not set # CONFIG_WIRELESS_OLD_REGULATORY is not set CONFIG_WIRELESS_EXT=y # CONFIG_WIRELESS_EXT_SYSFS is not set # CONFIG_LIB80211 is not set CONFIG_MAC80211=m +CONFIG_MAC80211_DEFAULT_PS=y +CONFIG_MAC80211_DEFAULT_PS_VALUE=1 # # Rate control algorithm selection @@ -447,7 +466,6 @@ CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y # CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set CONFIG_MAC80211_RC_DEFAULT=pid -# CONFIG_MAC80211_MESH is not set # CONFIG_MAC80211_LEDS is not set # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_DEBUG_MENU is not set @@ -472,77 +490,7 @@ CONFIG_EXTRA_FIRMWARE= # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set -CONFIG_MTD=y -CONFIG_MTD_DEBUG=y -CONFIG_MTD_DEBUG_VERBOSE=0 -# CONFIG_MTD_CONCAT is not set -# CONFIG_MTD_PARTITIONS is not set -# CONFIG_MTD_TESTS is not set - -# -# User Modules And Translation Layers -# -# CONFIG_MTD_CHAR is not set -CONFIG_MTD_BLKDEVS=y -CONFIG_MTD_BLOCK=y -# CONFIG_FTL is not set -# CONFIG_NFTL is not set -# CONFIG_INFTL is not set -# CONFIG_RFD_FTL is not set -# CONFIG_SSFDC is not set -# CONFIG_MTD_OOPS is not set - -# -# RAM/ROM/Flash chip drivers -# -# CONFIG_MTD_CFI is not set -# CONFIG_MTD_JEDECPROBE is not set -CONFIG_MTD_MAP_BANK_WIDTH_1=y -CONFIG_MTD_MAP_BANK_WIDTH_2=y -CONFIG_MTD_MAP_BANK_WIDTH_4=y -# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set -# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set -#
Re: [PATCH 1/5] powerpc/mm: Add MMU features for TLB reservation Paired MAS registers
On Mon, 2009-08-24 at 11:12 -0500, Kumar Gala wrote: Duh. Wasn't looking at the fall through. But is there any reason to even have any of the 6 instructions in the 'virt_page_table_tlb_miss_done' path if we don't have TLBSRX? No, that's what I said in my initial email :-) You can probably alternate out that whole thing. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/mm: Add MMU features for TLB reservation Paired MAS registers
Support for TLB reservation (or TLB Write Conditional) and Paired MAS registers are optional for a processor implementation so we handle them via MMU feature sections. We currently only used paired MAS registers to access the full RPN + perm bits that are kept in MAS7||MAS3. We assume that if an implementation has hardware page table at this time it also implements in TLB reservations. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Add a MMU feature around virt_page_table_tlb_miss_done based on MMU_FTR_USE_TLBRSRV arch/powerpc/include/asm/mmu.h |9 + arch/powerpc/mm/tlb_low_64e.S | 38 +- 2 files changed, 46 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h index 2fcfefc..7ffbb65 100644 --- a/arch/powerpc/include/asm/mmu.h +++ b/arch/powerpc/include/asm/mmu.h @@ -58,6 +58,15 @@ */ #define MMU_FTR_TLBIE_206 ASM_CONST(0x0040) +/* Enable use of TLB reservation. Processor should support tlbsrx. + * instruction and MAS0[WQ]. + */ +#define MMU_FTR_USE_TLBRSRVASM_CONST(0x0080) + +/* Use paired MAS registers (MAS7||MAS3, etc.) + */ +#define MMU_FTR_USE_PAIRED_MAS ASM_CONST(0x0100) + #ifndef __ASSEMBLY__ #include asm/cputable.h diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S index 10d524d..2d01444 100644 --- a/arch/powerpc/mm/tlb_low_64e.S +++ b/arch/powerpc/mm/tlb_low_64e.S @@ -189,12 +189,16 @@ normal_tlb_miss: clrrdi r14,r14,3 or r10,r15,r14 +BEGIN_MMU_FTR_SECTION /* Set the TLB reservation and seach for existing entry. Then load * the entry. */ PPC_TLBSRX_DOT(0,r16) ld r14,0(r10) beq normal_tlb_miss_done +MMU_FTR_SECTION_ELSE + ld r14,0(r10) +ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_USE_TLBRSRV) finish_normal_tlb_miss: /* Check if required permissions are met */ @@ -241,7 +245,14 @@ finish_normal_tlb_miss: bne 1f li r11,MAS3_SW|MAS3_UW andcr15,r15,r11 -1: mtspr SPRN_MAS7_MAS3,r15 +1: +BEGIN_MMU_FTR_SECTION + srdir16,r15,32 + mtspr SPRN_MAS3,r15 + mtspr SPRN_MAS7,r16 +MMU_FTR_SECTION_ELSE + mtspr SPRN_MAS7_MAS3,r15 +ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_USE_PAIRED_MAS) tlbwe @@ -311,11 +322,13 @@ virt_page_table_tlb_miss: rlwinm r10,r10,0,16,1 /* Clear TID */ mtspr SPRN_MAS1,r10 1: +BEGIN_MMU_FTR_SECTION /* Search if we already have a TLB entry for that virtual address, and * if we do, bail out. */ PPC_TLBSRX_DOT(0,r16) beq virt_page_table_tlb_miss_done +END_MMU_FTR_SECTION_IFSET(MMU_FTR_USE_TLBRSRV) /* Now, we need to walk the page tables. First check if we are in * range. @@ -367,10 +380,18 @@ virt_page_table_tlb_miss: */ clrldi r11,r15,4 /* remove region ID from RPN */ ori r10,r11,1 /* Or-in SR */ + +BEGIN_MMU_FTR_SECTION + srdir16,r10,32 + mtspr SPRN_MAS3,r10 + mtspr SPRN_MAS7,r16 +MMU_FTR_SECTION_ELSE mtspr SPRN_MAS7_MAS3,r10 +ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_USE_PAIRED_MAS) tlbwe +BEGIN_MMU_FTR_SECTION virt_page_table_tlb_miss_done: /* We have overriden MAS2:EPN but currently our primary TLB miss @@ -394,6 +415,7 @@ virt_page_table_tlb_miss_done: addir10,r11,-4 std r10,PACA_EXTLB+EX_TLB_SIZE+EX_TLB_SRR0(r13) 1: +END_MMU_FTR_SECTION_IFSET(MMU_FTR_USE_TLBRSRV) /* Return to caller, normal case */ TLB_MISS_STATS_X(MMSTAT_TLB_MISS_PT_OK); TLB_MISS_EPILOG_SUCCESS @@ -618,7 +640,14 @@ htw_tlb_miss: #else ori r10,r15,(BOOK3E_PAGESZ_4K MAS3_SPSIZE_SHIFT) #endif + +BEGIN_MMU_FTR_SECTION + srdir16,r10,32 + mtspr SPRN_MAS3,r10 + mtspr SPRN_MAS7,r16 +MMU_FTR_SECTION_ELSE mtspr SPRN_MAS7_MAS3,r10 +ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_USE_PAIRED_MAS) tlbwe @@ -700,7 +729,14 @@ tlb_load_linear: clrrdi r10,r16,30 /* 1G page index */ clrldi r10,r10,4 /* clear region bits */ ori r10,r10,MAS3_SR|MAS3_SW|MAS3_SX + +BEGIN_MMU_FTR_SECTION + srdir16,r10,32 + mtspr SPRN_MAS3,r10 + mtspr SPRN_MAS7,r16 +MMU_FTR_SECTION_ELSE mtspr SPRN_MAS7_MAS3,r10 +ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_USE_PAIRED_MAS) tlbwe -- 1.6.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: change to of MTD partition parsing
Ben, We need a better solution to the problem. What does the device tree on SLOF look like? - k On Aug 12, 2009, at 10:07 AM, Benjamin Krill wrote: Hi Kumar, slof has a further node inside the flash node which is not a partition entry. The old code just used all children and since the further node isn't a partition not all needed properties are there. cheers ben * Kumar Gala | 2009-08-12 09:46:10 [-0500]: Ben, The following commit breaks the previous definition of flash partitions according to Documentation/powerpc/dts-bindings/mtd-physmap.txt. Using the 'name' field is bad practice. What was going on w/the SLOF case? - k commit 4b08e149c0e02e97ec49c2a31d14a0d3a02f8074 Author: Benjamin Krill b...@codiert.org Date: Fri Jan 23 17:18:05 2009 +0100 [MTD] ofpart: Check name property to determine partition nodes. SLOF has a further node which could not be evaluated by the current routine. The current routine returns because the node hasn't the required reg property. As fix this patch adds a check to determine the partition child nodes. If the node is not a partition the number of total partitions will be decreased and loop continues with the next nodes. Signed-off-by: Benjamin Krill b...@codiert.org Signed-off-by: David Woodhouse david.woodho...@intel.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch] powerpc/ps3: Update ps3_defconfig
Signed-off-by: Geoff Levand geoffrey.lev...@am.sony.com --- Hi Ben, Please send upstream if it is not too late. Is the current one broken? Maybe a commit message would be nice :-P Mikey -Geoff arch/powerpc/configs/ps3_defconfig | 211 +- --- 1 file changed, 75 insertions(+), 136 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
