Re: Large stack usage in fs code (especially for PPC64)
On Tue, Nov 18, 2008 at 10:03:25AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2008-11-17 at 15:34 -0500, Steven Rostedt wrote: Note, I was using a default config that had CONFIG_IRQSTACKS off and CONFIG_PPC_64K_PAGES on. For one, we definitely need to turn IRQSTACKS on by default ... In fact, I'm pondering just removing the option. It shouldn't be a user-visible option. It shouldn't on x86 either, but there it always gets into the ideological 4k stacks flameware so people usually gave up after a while instead of doing the sensibke 8k + irqstacks by default, 4k as an option.. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Large stack usage in fs code (especially for PPC64)
On Tuesday 18 November 2008 09:53, Paul Mackerras wrote: I'd love to be able to use a 4k base page size if I could still get the reduction in page faults and the expanded TLB reach that we get now with 64k pages. If we could allocate the page cache for large files with order-4 allocations wherever possible that would be a good start. That can still have nasty side-effects like fragmentation and 64k granular reclaim. It also adds complexity to mapping the pages to userspace. Christoph's patchset IIRC also only did page cache, wheras I suppose your kernbench workload is gaining mainly from anonymous page faults. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Silence timebase sync code
On Tue, 18 Nov 2008, Michael Ellerman wrote:
On Mon, 2008-11-17 at 14:22 -0800, Trent Piepho wrote:
On Mon, 17 Nov 2008, Kumar Gala wrote:
On Nov 17, 2008, at 3:58 PM, Trent Piepho wrote:
It's over a dozen lines of output and doesn't appear to provide any useful
information. Even after looking at the code, I'm in the dark about what
score 299, offset 250 means.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
---
+++ b/arch/powerpc/kernel/smp-tbsync.c
@@ -113,7 +113,7 @@ void __devinit smp_generic_give_timebase(void)
{
int i, score, score2, old, min=0, max=5000, offset=1000;
- printk(Synchronizing timebase\n);
+ pr_info(Synchronizing timebase\n);
I think its useful to leave this as a printk.
#define pr_info(fmt, arg...) \
printk(KERN_INFO fmt, ##arg)
Isn't printk with no level tag the same as KERN_INFO?
Stuff like this should IMHO be printk(KERN_DEBUG ..)
That way it will show up in the log as long as you boot with 'debug' on
your command line, it doesn't require a kernel recompile to turn on. And
at the same time it doesn't spam the boot log for a normal boot.
Originally my patched changed it to debug, but Kumar requested I keep it at
info level. The timebase sync code might hang or be slow, so it's nice to
give a status output before doing it. It seems just as good as most of the
info printks during boot.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Use generic PHY driver for Marvell 88E1111 PHY on GE Fanuc SBC610
The Marvell PHY driver is currently being used for the 88E on the SBC610. This driver is causing the link to run in 10/Half mode, the generic PHY driver is correctly configuring the PHY as 1000/Full. Edit default config to use generic PHY driver. --- arch/powerpc/configs/86xx/gef_sbc610_defconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig b/arch/powerpc/configs/86xx/gef_sbc610_defconfig index 2da13e0..07ccaf8 100644 --- a/arch/powerpc/configs/86xx/gef_sbc610_defconfig +++ b/arch/powerpc/configs/86xx/gef_sbc610_defconfig @@ -838,7 +838,7 @@ CONFIG_PHYLIB=y # # MII PHY device drivers # -CONFIG_MARVELL_PHY=y +# CONFIG_MARVELL_PHY is not set # CONFIG_DAVICOM_PHY is not set # CONFIG_QSEMI_PHY is not set # CONFIG_LXT_PHY is not set ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Silence timebase sync code
On Mon, 2008-11-17 at 13:58 -0800, Trent Piepho wrote:
It's over a dozen lines of output and doesn't appear to provide any useful
information. Even after looking at the code, I'm in the dark about what
score 299, offset 250 means.
Hah ! I had almost the same patch in my pile for some time :-)
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/kernel/smp-tbsync.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/smp-tbsync.c
b/arch/powerpc/kernel/smp-tbsync.c
index bc892e6..b590135 100644
--- a/arch/powerpc/kernel/smp-tbsync.c
+++ b/arch/powerpc/kernel/smp-tbsync.c
@@ -113,7 +113,7 @@ void __devinit smp_generic_give_timebase(void)
{
int i, score, score2, old, min=0, max=5000, offset=1000;
- printk(Synchronizing timebase\n);
+ pr_info(Synchronizing timebase\n);
/* if this fails then this kernel won't work anyway... */
tbsync = kzalloc( sizeof(*tbsync), GFP_KERNEL );
@@ -123,14 +123,10 @@ void __devinit smp_generic_give_timebase(void)
while (!tbsync-ack)
barrier();
- printk(Got ack\n);
-
/* binary search */
for (old = -1; old != offset ; offset = (min+max) / 2) {
score = start_contest(kSetAndTest, offset, NUM_ITER);
- printk(score %d, offset %d\n, score, offset );
-
if( score 0 )
max = offset;
else
@@ -140,8 +136,8 @@ void __devinit smp_generic_give_timebase(void)
score = start_contest(kSetAndTest, min, NUM_ITER);
score2 = start_contest(kSetAndTest, max, NUM_ITER);
- printk(Min %d (score %d), Max %d (score %d)\n,
-min, score, max, score2);
+ pr_debug(Min %d (score %d), Max %d (score %d)\n,
+ min, score, max, score2);
score = abs(score);
score2 = abs(score2);
offset = (score score2) ? min : max;
@@ -155,7 +151,7 @@ void __devinit smp_generic_give_timebase(void)
if (score2 = score || score2 20)
break;
}
- printk(Final offset: %d (%d/%d)\n, offset, score2, NUM_ITER );
+ pr_debug(Final offset: %d (%d/%d)\n, offset, score2, NUM_ITER);
/* exiting */
tbsync-cmd = kExit;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Large stack usage in fs code (especially for PPC64)
On Tuesday 18 November 2008 13:08, Linus Torvalds wrote: On Tue, 18 Nov 2008, Paul Mackerras wrote: Also, you didn't respond to my comments about the purely software benefits of a larger page size. I realize that there are benefits. It's just that the downsides tend to swamp the upsides. The fact is, Intel (and to a lesser degree, AMD) has shown how hardware can do good TLB's with essentially gang lookups, giving almost effective page sizes of 32kB with hardly any of the downsides. Couple that with It's much harder to do this with powerpc I think because they would need to calculate 8 hashes and touch 8 cachelines to prefill 8 translations, wouldn't they? low-latency fault handling (for not when you miss in the TLB, but when something really isn't in the page tables), and it seems to be seldom the biggest issue. (Don't get me wrong - TLB's are not unimportant on x86 either. But on x86, things are generally much better). The per-page processing costs are interesting too, but IMO there is more work that should be done to speed up order-0 pages. The patches I had to remove the sync instruction for smp_mb() in unlock_page sped up pagecache throughput (populate, write(2), reclaim) on my G5 by something really crazy like 50% (most of that's in, but I'm still sitting on that fancy unlock_page speedup to remove the final smp_mb). I suspect some of the costs are also in powerpc specific code to insert linux ptes into their hash table. I think some of the synchronisation for those could possibly be shared with generic code so you don't need the extra layer of locks there. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Large stack usage in fs code (especially for PPC64)
* Christoph Hellwig [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 10:03:25AM +1100, Benjamin Herrenschmidt wrote: On Mon, 2008-11-17 at 15:34 -0500, Steven Rostedt wrote: Note, I was using a default config that had CONFIG_IRQSTACKS off and CONFIG_PPC_64K_PAGES on. For one, we definitely need to turn IRQSTACKS on by default ... In fact, I'm pondering just removing the option. It shouldn't be a user-visible option. It shouldn't on x86 either, but there it always gets into the ideological 4k stacks flameware so people usually gave up after a while instead of doing the sensibke 8k + irqstacks by default, 4k as an option.. yep, i tend to agree that 8k + irqstacks on both 32-bit and 64-bit would be the sane default. There's just too much gcc and other noise for us to have that cushion by default on 32-bit too. 64-bit is already there, on 32-bit we should decouple irqstacks from 4K stacks and just turn irqstacks on by default. Life's too short to fight kernel stack overflows - and now we've got the stack-tracer that will record and show the frame of the worst-ever kernel stack situation the system was in since bootup. (see Steve's tracer output in this thread) Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Use generic PHY driver for Marvell 88E1111 PHY on GE Fanuc SBC610
The Marvell PHY driver is currently being used for the 88E on the SBC610. This driver is causing the link to run in 10/Half mode, the generic PHY driver is correctly configuring the PHY as 1000/Full. Edit default config to use generic PHY driver. Signed-off-by: Martyn Welch [EMAIL PROTECTED] --- Agh! My mistake - forgot to add Signed-off, sorry. arch/powerpc/configs/86xx/gef_sbc610_defconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig b/arch/powerpc/configs/86xx/gef_sbc610_defconfig index 2da13e0..07ccaf8 100644 --- a/arch/powerpc/configs/86xx/gef_sbc610_defconfig +++ b/arch/powerpc/configs/86xx/gef_sbc610_defconfig @@ -838,7 +838,7 @@ CONFIG_PHYLIB=y # # MII PHY device drivers # -CONFIG_MARVELL_PHY=y +# CONFIG_MARVELL_PHY is not set # CONFIG_DAVICOM_PHY is not set # CONFIG_QSEMI_PHY is not set # CONFIG_LXT_PHY is not set ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/1] hvc_console: fix: remove duplicate hp-ws winsize check
Hello, this patch fixes a hvc terminal resize problem by removing a duplicate winsize comparison. Ben, could you add this patch to your tree for 2.6.28-rc6 bug fixes? Thanks and regards, Hendrik -- Hendrik Brueckner D/3303 Linux on System z Development eMail: [EMAIL PROTECTED] IBM Deutschland Research Development GmbH, Schoenaicher Str. 220, 71032 Boeblingen IBM Deutschland Research Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Erich Baier Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/1] hvc_console: fix: hp-ws winsize check runs out-of-sync
From: Hendrik Brueckner [EMAIL PROTECTED]
The test to check for a new winsize runs out-of-sync with the underlying
tty. After a tty has been released and initialized again, the winsize might
differ between the tty and the hp struct.
The solution is to simply remove the check and always schedule the resize work.
Signed-off-by: Hendrik Brueckner [EMAIL PROTECTED]
Acked-by: Christian Borntraeger [EMAIL PROTECTED]
---
drivers/char/hvc_console.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -689,10 +689,8 @@ EXPORT_SYMBOL_GPL(hvc_poll);
*/
void hvc_resize(struct hvc_struct *hp, struct winsize ws)
{
- if ((hp-ws.ws_row != ws.ws_row) || (hp-ws.ws_col != ws.ws_col)) {
- hp-ws = ws;
- schedule_work(hp-tty_resize);
- }
+ hp-ws = ws;
+ schedule_work(hp-tty_resize);
}
/*
--
Hendrik Brueckner
D/3303 Linux on System z Development
Tel: +49 7031 16-1073
Fax: +49 7031 16-3456
eMail: [EMAIL PROTECTED]
IBM Deutschland Research Development GmbH, Schoenaicher Str. 220, 71032
Boeblingen
IBM Deutschland Research Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Large stack usage in fs code (especially for PPC64)
Nick Piggin writes: It's much harder to do this with powerpc I think because they would need to calculate 8 hashes and touch 8 cachelines to prefill 8 translations, wouldn't they? Yeah, the hashed page table sucks. Film at 11, as they say. :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add sync_*_for_* to dma_ops
dma_addr_t dma_address, size_t size,
enum dma_data_direction direction,
struct dma_attrs *attrs);
+ void(*sync_single_for_cpu)(struct device *hwdev,
+ dma_addr_t dma_handle, size_t size,
+ enum dma_data_direction direction);
+ void(*sync_single_for_device)(struct device *hwdev,
+ dma_addr_t dma_handle, size_t size,
+ enum dma_data_direction direction);
+ void(*sync_single_range_for_cpu)(struct device *hwdev,
+ dma_addr_t dma_handle, unsigned long offset,
+ size_t size,
+ enum dma_data_direction direction);
+ void(*sync_single_range_for_device)(struct device *hwdev,
+ dma_addr_t dma_handle, unsigned long offset,
+ size_t size,
+ enum dma_data_direction direction);
Can't we implement the first 2 using the next 2 and passing a 0 offset ?
I mean, we're going to go through a function pointer, it's not like
handling the offset was going to cost us something :-)
+ void(*sync_sg_for_cpu)(struct device *hwdev,
+ struct scatterlist *sg, int nelems,
+ enum dma_data_direction direction);
+ void(*sync_sg_for_device)(struct device *hwdev,
+ struct scatterlist *sg, int nelems,
+ enum dma_data_direction direction);
};
/*
@@ -286,42 +306,75 @@ static inline void dma_sync_single_for_cpu(struct
device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction direction)
{
- BUG_ON(direction == DMA_NONE);
- __dma_sync(bus_to_virt(dma_handle), size, direction);
+ struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
+
+ BUG_ON(!dma_ops);
+ if (dma_ops-sync_single_for_cpu != NULL)
+ dma_ops-sync_single_for_cpu(dev, dma_handle, size,
+ direction);
}
.../...
The only objection that comes to mind here is that generally, you know
that your platform is going to be coherent or not at compile time, and
you don't want the above at all when it is (or won't need swiotlb).
So maybe we could have a Kconfig trickery so that
CONFIG_PPC_DMA_NEED_SYNC_OPS is set when either non coherent DMA is
select'ed or swiotlb support is select'ed by one of the enabled
platform. So if I enable only powermac, I get neither and don't get the
bloody inlines :-)
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][for 2.6.27/stable] Remove -mno-spe flags as they dont belong
For some unknown reason at Steven Rostedt added in disabling of the SPE instruction generation for e500 based PPC cores in commit 6ec562328fda585be2d7f472cfac99d3b44d362a. We are removing it because: 1. It generates e500 kernels that don't work 2. its not the correct set of flags to do this 3. we handle this in the arch/powerpc/Makefile already 4. its unknown in talking to Steven why he did this (This is backported for commit 65ecc14a30ad21bed9aabdfd6a2ae1a16a00) Signed-off-by: Kumar Gala [EMAIL PROTECTED] Tested-and-Acked-by: Steven Rostedt [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] --- Greg, A straight cherry pick of 65ecc14a30ad21bed9aabdfd6a2ae1a16a00 causes merge issues with 2.6.27.x, so there here is a version of the commit that should apply to 2.6.27.x - k kernel/Makefile |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/kernel/Makefile b/kernel/Makefile index 4e1d7df..143e8b6 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -11,8 +11,6 @@ obj-y = sched.o fork.o exec_domain.o panic.o printk.o \ hrtimer.o rwsem.o nsproxy.o srcu.o semaphore.o \ notifier.o ksysfs.o pm_qos_params.o sched_clock.o -CFLAGS_REMOVE_sched.o = -mno-spe - ifdef CONFIG_FTRACE # Do not trace debug files and internal ftrace files CFLAGS_REMOVE_lockdep.o = -pg @@ -21,7 +19,7 @@ CFLAGS_REMOVE_mutex-debug.o = -pg CFLAGS_REMOVE_rtmutex-debug.o = -pg CFLAGS_REMOVE_cgroup-debug.o = -pg CFLAGS_REMOVE_sched_clock.o = -pg -CFLAGS_REMOVE_sched.o = -mno-spe -pg +CFLAGS_REMOVE_sched.o = -pg endif obj-$(CONFIG_PROFILING) += profile.o -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Silence timebase sync code
On Nov 17, 2008, at 4:22 PM, Trent Piepho wrote:
On Mon, 17 Nov 2008, Kumar Gala wrote:
On Nov 17, 2008, at 3:58 PM, Trent Piepho wrote:
It's over a dozen lines of output and doesn't appear to provide
any useful
information. Even after looking at the code, I'm in the dark
about what
score 299, offset 250 means.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
---
arch/powerpc/kernel/smp-tbsync.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/smp-tbsync.c
b/arch/powerpc/kernel/smp-tbsync.c
index bc892e6..b590135 100644
--- a/arch/powerpc/kernel/smp-tbsync.c
+++ b/arch/powerpc/kernel/smp-tbsync.c
@@ -113,7 +113,7 @@ void __devinit smp_generic_give_timebase(void)
{
int i, score, score2, old, min=0, max=5000, offset=1000;
- printk(Synchronizing timebase\n);
+ pr_info(Synchronizing timebase\n);
I think its useful to leave this as a printk.
#define pr_info(fmt, arg...) \
printk(KERN_INFO fmt, ##arg)
Isn't printk with no level tag the same as KERN_INFO?
oops, sorry.. read the pr_info() as pr_debug()
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Use generic PHY driver for Marvell 88E1111 PHY on GE Fanuc SBC610
On Nov 18, 2008, at 4:55 AM, Martyn Welch wrote: The Marvell PHY driver is currently being used for the 88E on the SBC610. This driver is causing the link to run in 10/Half mode, the generic PHY driver is correctly configuring the PHY as 1000/Full. Edit default config to use generic PHY driver. Signed-off-by: Martyn Welch [EMAIL PROTECTED] --- Agh! My mistake - forgot to add Signed-off, sorry. arch/powerpc/configs/86xx/gef_sbc610_defconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hmm.. why not fix the issue with the 88e driver. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Use generic PHY driver for Marvell 88E1111 PHY on GE Fanuc SBC610
On Tue, 18 Nov 2008 07:39:21 -0600 Kumar Gala [EMAIL PROTECTED] wrote: On Nov 18, 2008, at 4:55 AM, Martyn Welch wrote: The Marvell PHY driver is currently being used for the 88E on the SBC610. This driver is causing the link to run in 10/Half mode, the generic PHY driver is correctly configuring the PHY as 1000/Full. Edit default config to use generic PHY driver. Signed-off-by: Martyn Welch [EMAIL PROTECTED] --- Agh! My mistake - forgot to add Signed-off, sorry. arch/powerpc/configs/86xx/gef_sbc610_defconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hmm.. why not fix the issue with the 88e driver. Two reasons really: 1) We don't use any of the non-generic features of the PHY. 2) Networking is really _not_ my forte. As a result, it's not itching ;-) Martyn -- Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748 GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square, Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC
Paul and Benjamin, Can I add your Acked-by: to all these patches that I submitted? I'm going to recommit them with a consistent subject (all lower case ppc), but I'm not going to change the patches themselves. Would you two be fine with that? Or at least one of you? -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
8360E MDS - linux 2.6.20
Hi All,Iam in the process of building the uImage and root file system for source linux 2.6.20 to bring up the powerpc 8360E MDS board. Please let me know whether I can get the minimum default config(.config) for building the same or any other document to guide the build.Thanks in advance.Regards,Nanda ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc832x_rdb: fix swapped ethernet ids
David Gibson wrote: On Mon, Nov 17, 2008 at 11:28:52AM -0500, Michael Barkowski wrote: David Gibson wrote: On Fri, Nov 14, 2008 at 10:16:19AM -0500, Michael Barkowski wrote: David Gibson wrote: On Thu, Nov 13, 2008 at 10:18:28AM -0500, Michael Barkowski wrote: ethernet0 (called FSL UEC0 in U-Boot) should be enet1 (UCC3/eth1), and ethernet1 should be enet0 (UCC2/eth0), to be consistent with U-Boot so that the interfaces do not swap addresses when control passes from U-Boot to the kernel. Um.. why is just swapping the aliases, rather than the enet labels the right approach here? Kim suggested it was better to localize the port ordering as a property of the board rather than that of the QE, and I agreed. And the enet0/enet1 names that appear in the labels come from the QE documentation? No.. but don't you think the UCC2, UCC3 names, which *do* come from the QE documentation, should match their labels in numeric ordering? Aren't the aliases just machine-specific shortcuts for the bootloader? Ok, that's reasonable (although personally I would have thought it would make more sense for the labels to be based on the documentation terms, so UCC2, UCC3 etc., as we do on 4xx). Yeah, that would make sense to me too. Although I guess that's a separate patch/issue, since the enet0/enet1 labelling is pretty common across 85xx/83xx. thanks, -- Michael ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
David Gibson wrote: Given the variety of strange I/O configurations in prototype and embedded platforms, I can't imagine this was a unique situation. So I've pushed my patch out, so anyone else in a similar situation can immediately turn their little udbg methods for whatever strange I/O they have into a fully-functional console. Maybe it's not something you'd want to go to release with, but it certainly simplifies life during bringup. Ok, I understand now. However, I would like to see two changes: 1) Re-arrange the Makefile as I pointed out in another post. 2) Update the Kconfig help file to be very clear that this feature is only meaningful if the platform has a udbg back-end but no other console or TTY driver. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Large stack usage in fs code (especially for PPC64)
On Tue, 18 Nov 2008, Nick Piggin wrote: The fact is, Intel (and to a lesser degree, AMD) has shown how hardware can do good TLB's with essentially gang lookups, giving almost effective page sizes of 32kB with hardly any of the downsides. Couple that with It's much harder to do this with powerpc I think because they would need to calculate 8 hashes and touch 8 cachelines to prefill 8 translations, wouldn't they? Oh, absolutely. It's why I despise hashed page tables. It's a broken concept. The per-page processing costs are interesting too, but IMO there is more work that should be done to speed up order-0 pages. The patches I had to remove the sync instruction for smp_mb() in unlock_page sped up pagecache throughput (populate, write(2), reclaim) on my G5 by something really crazy like 50% (most of that's in, but I'm still sitting on that fancy unlock_page speedup to remove the final smp_mb). I suspect some of the costs are also in powerpc specific code to insert linux ptes into their hash table. I think some of the synchronisation for those could possibly be shared with generic code so you don't need the extra layer of locks there. Yeah, the hashed page tables get extra costs from the fact that it can't share the software page tables with the hardware ones, and the associated coherency logic. It's even worse at unmap time, I think. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add sync_*_for_* to dma_ops
On Nov 18, 2008, at 6:22 AM, Benjamin Herrenschmidt wrote:
dma_addr_t dma_address, size_t size,
enum dma_data_direction direction,
struct dma_attrs *attrs);
+ void(*sync_single_for_cpu)(struct device *hwdev,
+ dma_addr_t dma_handle, size_t size,
+ enum dma_data_direction direction);
+ void(*sync_single_for_device)(struct device *hwdev,
+ dma_addr_t dma_handle, size_t size,
+ enum dma_data_direction direction);
+ void(*sync_single_range_for_cpu)(struct device *hwdev,
+ dma_addr_t dma_handle, unsigned long offset,
+ size_t size,
+ enum dma_data_direction direction);
+ void(*sync_single_range_for_device)(struct device
*hwdev,
+ dma_addr_t dma_handle, unsigned long offset,
+ size_t size,
+ enum dma_data_direction direction);
Can't we implement the first 2 using the next 2 and passing a 0
offset ?
I mean, we're going to go through a function pointer, it's not like
handling the offset was going to cost us something :-)
Looking at the swiotlb code; I think that's a reasonable thing to do.
Will respin.
+ void(*sync_sg_for_cpu)(struct device *hwdev,
+ struct scatterlist *sg, int nelems,
+ enum dma_data_direction direction);
+ void(*sync_sg_for_device)(struct device *hwdev,
+ struct scatterlist *sg, int nelems,
+ enum dma_data_direction direction);
};
/*
@@ -286,42 +306,75 @@ static inline void
dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction direction)
{
- BUG_ON(direction == DMA_NONE);
- __dma_sync(bus_to_virt(dma_handle), size, direction);
+ struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
+
+ BUG_ON(!dma_ops);
+ if (dma_ops-sync_single_for_cpu != NULL)
+ dma_ops-sync_single_for_cpu(dev, dma_handle, size,
+direction);
}
.../...
The only objection that comes to mind here is that generally, you know
that your platform is going to be coherent or not at compile time, and
you don't want the above at all when it is (or won't need swiotlb).
So maybe we could have a Kconfig trickery so that
CONFIG_PPC_DMA_NEED_SYNC_OPS is set when either non coherent DMA is
select'ed or swiotlb support is select'ed by one of the enabled
platform. So if I enable only powermac, I get neither and don't get
the
bloody inlines :-)
I thought about doing something like this, but didn't know if it was
worth the ifdeffing/CONFIG foo that would ensue; I guess your response
answers that question :)
Thanks!
B
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
BUG? timer_create() with SIGEV_THREAD not working (at least on ppc64)
The code below sets up a simple timer with SIGEV_THREAD. I compiled the
code as g++ timertest.cc -o timertest -lrt -pthread.
Running it on my G5 with 2.6.27 (but with an older glibc), it prints:
Creating timer
Setting timer 268509264 for 5-second expiration...
and then the timer never expires. I have an old Fedora Core 4 x86
machine and there it works as expected.
Is there some hard requirement to upgrade glibc? If not, then this
looks like a bug somewhere.
Thanks,
Chris
int main(void)
{
timer_t timer_id;
struct itimerspecits;
struct sigevent se;
// set timer signal event
se.sigev_notify = SIGEV_THREAD;
se.sigev_value.sival_ptr = timer_id;
se.sigev_notify_function = handler;
se.sigev_notify_attributes = NULL;
if ( timer_create(CLOCK_REALTIME, se, timer_id) 0)
{
printf(create timer failed\n);
fflush(0);
return 0;
}
// set timer.
its.it_value.tv_sec = 1;
its.it_value.tv_nsec= 0;
its.it_interval.tv_sec = 1;
its.it_interval.tv_nsec = 0;
if ( timer_settime(timer_id, 0, its, NULL) 0)
{
printf(set timer failed\n);
fflush(0);
return 0;
}
printf(set timer OK\n);
fflush(0);
while(1)
{ pause();}
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8360E MDS - linux 2.6.20
On 18 Nov 2008 14:40:50 - nanda [EMAIL PROTECTED] wrote: Hi All,Iam in the process of building the uImage and root file system for source linux 2.6.20 to bring up the powerpc 8360E MDS board. Please let me know whether I can get the minimum default config(.config) for building the same or any other document to guide the build.Thanks in advance.Regards,Nanda there should be a default config in arch/powerpc/configs - 'make mpc8360emds_defconfig' (or mpc836x_mds_defconfig for later kernel versions). Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add sync_*_for_* to dma_ops
@@ -286,42 +306,75 @@ static inline void dma_sync_single_for_cpu
(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction direction)
{
- BUG_ON(direction == DMA_NONE);
Did you intend to remove this here? It would be nice to test for it
even on platforms where the op is a nop; if there is an equivalent
test in every implementation of the ops, remove it there instead
(that's more source + binary code to remove, always a good thing ;-) )
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/6 v2] usb/fsl_qe_udc: Fix recursive locking bug in ch9getstatus()
The call chain is this:
qe_udc_irq() - grabs the udc-lock spinlock
rx_irq()
qe_ep0_rx()
ep0_setup_handle()
setup_received_handle()
ch9getstatus()
qe_ep_queue() - tries to grab the udc-lock again
It seems unsafe to temporarily drop the lock in the ch9getstatus(),
so to fix that bug the lock-less __qe_ep_queue() function
implemented and used by the ch9getstatus().
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
On Mon, Nov 17, 2008 at 05:59:42PM -0800, David Brownell wrote:
On Tuesday 11 November 2008, Anton Vorontsov wrote:
- spin_lock_irqsave(udc-lock, flags);
+ if (lock)
+ spin_lock_irqsave(lock, flags);
Ugly ugly ugly. Conditional locking is error prone ... don't.
Couldn't you just have the usb_ep_queue() method wrap lock calls
around a common routine called by that and the status reporting code?
Yeah, that's much better approach.
Or just have the status reporting code stuff the two bytes directly
into the FIFO? (Which is what a lot of other drivers do.)
Well, I think that using common code path for data transmission is
better, and simpler.
Thanks for the review.
drivers/usb/gadget/fsl_qe_udc.c | 27 +++
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/fsl_qe_udc.c b/drivers/usb/gadget/fsl_qe_udc.c
index 60b9279..165ff76 100644
--- a/drivers/usb/gadget/fsl_qe_udc.c
+++ b/drivers/usb/gadget/fsl_qe_udc.c
@@ -1681,14 +1681,12 @@ static void qe_free_request(struct usb_ep *_ep, struct
usb_request *_req)
kfree(req);
}
-/* queues (submits) an I/O request to an endpoint */
-static int qe_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
- gfp_t gfp_flags)
+static int __qe_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
+gfp_t gfp_flags)
{
struct qe_ep *ep = container_of(_ep, struct qe_ep, ep);
struct qe_req *req = container_of(_req, struct qe_req, req);
struct qe_udc *udc;
- unsigned long flags;
int reval;
udc = ep-udc;
@@ -1732,7 +1730,7 @@ static int qe_ep_queue(struct usb_ep *_ep, struct
usb_request *_req,
list_add_tail(req-queue, ep-queue);
dev_vdbg(udc-dev, gadget have request in %s! %d\n,
ep-name, req-req.length);
- spin_lock_irqsave(udc-lock, flags);
+
/* push the request to device */
if (ep_is_in(ep))
reval = ep_req_send(ep, req);
@@ -1748,11 +1746,24 @@ static int qe_ep_queue(struct usb_ep *_ep, struct
usb_request *_req,
if (ep-dir == USB_DIR_OUT)
reval = ep_req_receive(ep, req);
- spin_unlock_irqrestore(udc-lock, flags);
-
return 0;
}
+/* queues (submits) an I/O request to an endpoint */
+static int qe_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
+ gfp_t gfp_flags)
+{
+ struct qe_ep *ep = container_of(_ep, struct qe_ep, ep);
+ struct qe_udc *udc = ep-udc;
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(udc-lock, flags);
+ ret = __qe_ep_queue(_ep, _req, gfp_flags);
+ spin_unlock_irqrestore(udc-lock, flags);
+ return ret;
+}
+
/* dequeues (cancels, unlinks) an I/O request from an endpoint */
static int qe_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
{
@@ -2008,7 +2019,7 @@ static void ch9getstatus(struct qe_udc *udc, u8
request_type, u16 value,
udc-ep0_dir = USB_DIR_IN;
/* data phase */
- status = qe_ep_queue(ep-ep, req-req, GFP_ATOMIC);
+ status = __qe_ep_queue(ep-ep, req-req, GFP_ATOMIC);
if (status == 0)
return;
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add sync_*_for_* to dma_ops
On Nov 18, 2008, at 10:57 AM, Segher Boessenkool wrote:
@@ -286,42 +306,75 @@ static inline void
dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction direction)
{
- BUG_ON(direction == DMA_NONE);
Did you intend to remove this here? It would be nice to test for it
even on platforms where the op is a nop; if there is an equivalent
test in every implementation of the ops, remove it there instead
(that's more source + binary code to remove, always a good thing ;-) )
You're right that we have lost this test in platforms which do not
implement the sync ops, and if the test is useful, I can certainly
move it. However, it will actually result in more code on the current
ppc kernel, as there are 3x more dma_sync_* instances than there are
actual dma_direct_* instances (and nobody else implements
dma_sync_* :) Not that we're talking about a lot of code here, but it
definitely won't make the kernel smaller since we just don't need a
sync unless we're noncoherent which, thank insert deity here, is rare.
With the swiotlb case, the check needs to be in the swiotlb code
because there are other architectures that use the swiotlb code that
do not use a structure to get to their dma_ops like we do. IA64, for
example, sets up its dma_ops using config options and #defines the
names of the various dma_ functions. They don't go through a dma_ops
dereference, so the (possibly redundant for us) check in the swiotlb
code would need to remain.
So, the reason for moving it would be that we think it's still a
useful check to have. I'm happy to move it in that case.
Thanks,
-Becky
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/cell/axon-msi: retry on missing interrupt
Arnd,
However, reading that position does not flush the DMA, so that we can
observe stale data in the buffer.
The position register is in the DCR space from which a read does not flush
the interrupt. But it seem that reading a register mapped to the PLB5 can
flush the interrupts if the C3PO is set to producer/consumer mode.
Giora
Arnd Bergmann
[EMAIL PROTECTED]
To
17/11/2008 18:10 linuxppc-dev@ozlabs.org,
[EMAIL PROTECTED],
[EMAIL PROTECTED]
cc
Giora Biran/Haifa/[EMAIL PROTECTED],
[EMAIL PROTECTED], Michael
Ellerman [EMAIL PROTECTED]
Subject
[PATCH] powerpc/cell/axon-msi:
retry on missing interrupt
The MSI capture logic for the axon bridge can sometimes
lose interrupts in case of high DMA and interrupt load,
when it signals an MSI interrupt to the MPIC interrupt
controller while we are already handling another MSI.
Each MSI vector gets written into a FIFO buffer in main
memory using DMA, and that DMA access is normally flushed
by the actual interrupt packet on the IOIF. An MMIO
register in the MSIC holds the position of the last
entry in the FIFO buffer that was written. However,
reading that position does not flush the DMA, so that
we can observe stale data in the buffer.
In a stress test, we have observed the DMA to arrive
up to 14 microseconds after reading the register.
This patch works around this problem by retrying the
access to the FIFO buffer.
We can reliably detect the conditioning by writing
an invalid MSI vector into the FIFO buffer after
reading from it, assuming that all MSIs we get
are valid. After detecting an invalid MSI vector,
we udelay(1) in the interrupt cascade for up to
100 times before giving up.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
---
axon_msi.c | 36 +++-
1 files changed, 31 insertions(+), 5 deletions(-)
Index: linux-2.6/arch/powerpc/platforms/cell/axon_msi.c
===
--- linux-2.6.orig/arch/powerpc/platforms/cell/axon_msi.c
2008-11-17 10:29:05.0 -0500
+++ linux-2.6/arch/powerpc/platforms/cell/axon_msi.c 2008-11-17
10:29:08.0 -0500
@@ -95,6 +95,7 @@
struct axon_msic *msic = get_irq_data(irq);
u32 write_offset, msi;
int idx;
+int retry = 0;
write_offset = dcr_read(msic-dcr_host,
MSIC_WRITE_OFFSET_REG);
pr_debug(axon_msi: original write_offset 0x%x\n,
write_offset);
@@ -102,7 +103,7 @@
/* write_offset doesn't wrap properly, so we have to mask it
*/
write_offset = MSIC_FIFO_SIZE_MASK;
-while (msic-read_offset != write_offset) {
+while (msic-read_offset != write_offset retry 100) {
idx = msic-read_offset / sizeof(__le32);
msi = le32_to_cpu(msic-fifo_virt[idx]);
msi = 0x;
@@ -110,13 +111,37 @@
pr_debug(axon_msi: woff %x roff %x msi %x\n,
write_offset, msic-read_offset,
msi);
+if (msi NR_IRQS irq_map[msi].host == msic-
irq_host) {
+generic_handle_irq(msi);
+msic-fifo_virt[idx] = cpu_to_le32
(0x);
+} else {
+/*
+ * Reading the MSIC_WRITE_OFFSET_REG
does not
+ * reliably flush the outstanding DMA
to the
+ * FIFO buffer. Here we were reading
stale
+ * data, so we need to retry.
+ */
+
Re: [PATCH] powerpc/cell/axon-msi: retry on missing interrupt
On Tuesday 18 November 2008, Giora Biran wrote: Arnd, However, reading that position does not flush the DMA, so that we can observe stale data in the buffer. The position register is in the DCR space from which a read does not flush the interrupt. But it seem that reading a register mapped to the PLB5 can flush the interrupts if the C3PO is set to producer/consumer mode. Right, however I guess that implementing this in Linux would either get a lot uglier than the current patch, or require an updated firmware. The problem here is that the MSIC device node only provides a DCR register range, and no MMIO register range, so there is no clean way for the device driver to know about any register it can safely read. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: BUG? timer_create() with SIGEV_THREAD not working (at least on ppc64)
Chris Friesen wrote:
The code below sets up a simple timer with SIGEV_THREAD. I compiled the
code as g++ timertest.cc -o timertest -lrt -pthread.
Running it on my G5 with 2.6.27 (but with an older glibc), it prints:
Creating timer
Setting timer 268509264 for 5-second expiration...
and then the timer never expires. I have an old Fedora Core 4 x86
machine and there it works as expected.
Is there some hard requirement to upgrade glibc? If not, then this
looks like a bug somewhere.
I'm getting suspicious of either glibc or my version of strace, as it
shows the child thread calling rt_sigtimedwait() with an empty signal set.
clone(Process 2663 attached
child_stack=0xf7ffe6c0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED,
parent_tidptr=0xf7ffeb68, tls=0xf8005f80, child_tidptr=0xf7ffeb68) = 2663
[pid 2662] futex(0xf5f11a4, FUTEX_WAKE, 2147483647) = 0
[pid 2662] timer_create(0, {0x10011050, 32, SIGEV_THREAD_ID, {2663}},
{(nil)}) = 0
[pid 2662] timer_settime(0, , {it_interval={1, 0}, it_value={1, 0}},
unfinished ...
[pid 2663] rt_sigprocmask(SIG_BLOCK, [RTMIN], unfinished ...
[pid 2662] ... timer_settime resumed NULL) = 0
[pid 2662] fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0),
...}) = 0
[pid 2663] ... rt_sigprocmask resumed NULL, 8) = 0
[pid 2662] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 unfinished ...
[pid 2663] rt_sigtimedwait([], unfinished ...
[pid 2662] ... mmap resumed )= 0xf7ffa000
[pid 2662] write(1, set timer OK\n, 13set timer OK
Chris
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [v3] powerpc/4xx: work around CHIP11 errata in a more PAGE_SIZE-friendly way
On Fri, 2008-11-14 at 16:09 -0600, Hollis Blanchard wrote: Basically my revised proposal is to add explicit memory reservation properties to the device tree. Currently, /memreserve properties in .dts files are not present in the device tree itself, only in the FDT header. I think these reservations should be duplicated in the tree itself, so that they become visible to post-boot tools like kexec. In summary, all memory reservations will then exist both in the device tree and in the FDT header. Comments? Impact to uboot: revert memory node truncation; create reservation and /memreserve property. Impact to cuboot wrapper: revert memory node truncation; create reservation and /memreserve property. Impact to kernel: none. /memreserve will be ignored, since memory reservations are already handled properly. Impact to kexec-tools: Must take /memreserve into account when placing data at the end of memory. If this is all too much, then I'm close to giving up and burning a 64KB page, which requires only ALIGN_DOWN() in the kernel. Any comments? -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/6 v2] usb/fsl_qe_udc: Fix recursive locking bug in ch9getstatus()
On Tuesday 18 November 2008, Anton Vorontsov wrote: + spin_lock_irqsave(udc-lock, flags); + ret = __qe_ep_queue(_ep, _req, gfp_flags); + spin_unlock_irqrestore(udc-lock, flags); Why are you passing gfp_flags? Especially without checking ... GFP_KERNEL will be illegal, for example. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: spinlock lockup with next-20081118 on powerpc
Hi all, I got this in my boot test last night: Begin: Waiting for root file system... ... BUG: spinlock lockup on CPU#1, vol_id/3246, c0b09700 Call Trace: [c00040ef7080] [c000fb58] .show_stack+0x70/0x184 (unreliable) [c00040ef7130] [c027adac] ._raw_spin_lock+0x140/0x17c [c00040ef71d0] [c04ec648] ._spin_lock_irqsave+0x8c/0xc4 [c00040ef7270] [c00659dc] .lock_timer_base+0x38/0x90 [c00040ef7310] [c0065b50] .__mod_timer+0x4c/0x11c [c00040ef73c0] [c025ae9c] .blk_plug_device+0xc0/0xd8 [c00040ef7440] [c025bb90] .__make_request+0x498/0x518 [c00040ef74f0] [c0259dc8] .generic_make_request+0x24c/0x2a4 [c00040ef75b0] [c025b6d0] .submit_bio+0x108/0x130 [c00040ef7670] [c01210e4] .submit_bh+0x174/0x1c0 [c00040ef7700] [c01259a8] .block_read_full_page+0x34c/0x3b4 [c00040ef7820] [c0129a60] .blkdev_readpage+0x20/0x38 [c00040ef78a0] [c00c111c] .__do_page_cache_readahead+0x23c/0x2b8 [c00040ef7980] [c00c1370] .ondemand_readahead+0x1d8/0x210 [c00040ef7a30] [c00b7f20] .generic_file_aio_read+0x224/0x620 [c00040ef7b60] [c00f9020] .do_sync_read+0xc4/0x124 [c00040ef7cf0] [c00f98e0] .vfs_read+0xd8/0x1bc [c00040ef7d90] [c00f9f0c] .sys_read+0x4c/0x8c [c00040ef7e30] [c00084d4] syscall_exit+0x0/0x40 This was on a Power5 partition. I am attempting to reproduce the problem. Any clues? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpX107COExHG.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: BUG? timer_create() with SIGEV_THREAD not working (at least on ppc64)
Chris Friesen wrote: I'm getting suspicious of either glibc or my version of strace, as it shows the child thread calling rt_sigtimedwait() with an empty signal set. Looks like glibc was the culprit. It works fine with a newer version. Sorry for the false alarm. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: spinlock lockup with next-20081118 on powerpc
Hi all, On Wed, 19 Nov 2008 09:30:23 +1100 Stephen Rothwell [EMAIL PROTECTED] wrote: This was on a Power5 partition. I am attempting to reproduce the problem. OK, it reproduces. The machine is a Power5 partition (IBM,9124-720 eServer OpenPower 720) with 1 (2 way threaded) cpu (gr, rev2.1, 1.5GHz), 2G of memory, 2 NUMA nodes running Ubuntu Gutsy. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpptMk1f8FW9.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/6 v3] usb/fsl_qe_udc: Fix recursive locking bug in ch9getstatus()
The call chain is this:
qe_udc_irq() - grabs the udc-lock spinlock
rx_irq()
qe_ep0_rx()
ep0_setup_handle()
setup_received_handle()
ch9getstatus()
qe_ep_queue() - tries to grab the udc-lock again
It seems unsafe to temporarily drop the lock in the ch9getstatus(),
so to fix that bug the lock-less __qe_ep_queue() function
implemented and used by the ch9getstatus().
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
On Tue, Nov 18, 2008 at 02:13:30PM -0800, David Brownell wrote:
On Tuesday 18 November 2008, Anton Vorontsov wrote:
+ spin_lock_irqsave(udc-lock, flags);
+ ret = __qe_ep_queue(_ep, _req, gfp_flags);
+ spin_unlock_irqrestore(udc-lock, flags);
Why are you passing gfp_flags? Especially without
checking ... GFP_KERNEL will be illegal, for example.
Ugh, the gfp_flags aren't used at all. How about that
patch?
drivers/usb/gadget/fsl_qe_udc.c | 26 ++
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/fsl_qe_udc.c b/drivers/usb/gadget/fsl_qe_udc.c
index 60b9279..3587970 100644
--- a/drivers/usb/gadget/fsl_qe_udc.c
+++ b/drivers/usb/gadget/fsl_qe_udc.c
@@ -1681,14 +1681,11 @@ static void qe_free_request(struct usb_ep *_ep, struct
usb_request *_req)
kfree(req);
}
-/* queues (submits) an I/O request to an endpoint */
-static int qe_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
- gfp_t gfp_flags)
+static int __qe_ep_queue(struct usb_ep *_ep, struct usb_request *_req)
{
struct qe_ep *ep = container_of(_ep, struct qe_ep, ep);
struct qe_req *req = container_of(_req, struct qe_req, req);
struct qe_udc *udc;
- unsigned long flags;
int reval;
udc = ep-udc;
@@ -1732,7 +1729,7 @@ static int qe_ep_queue(struct usb_ep *_ep, struct
usb_request *_req,
list_add_tail(req-queue, ep-queue);
dev_vdbg(udc-dev, gadget have request in %s! %d\n,
ep-name, req-req.length);
- spin_lock_irqsave(udc-lock, flags);
+
/* push the request to device */
if (ep_is_in(ep))
reval = ep_req_send(ep, req);
@@ -1748,11 +1745,24 @@ static int qe_ep_queue(struct usb_ep *_ep, struct
usb_request *_req,
if (ep-dir == USB_DIR_OUT)
reval = ep_req_receive(ep, req);
- spin_unlock_irqrestore(udc-lock, flags);
-
return 0;
}
+/* queues (submits) an I/O request to an endpoint */
+static int qe_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
+ gfp_t gfp_flags)
+{
+ struct qe_ep *ep = container_of(_ep, struct qe_ep, ep);
+ struct qe_udc *udc = ep-udc;
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(udc-lock, flags);
+ ret = __qe_ep_queue(_ep, _req);
+ spin_unlock_irqrestore(udc-lock, flags);
+ return ret;
+}
+
/* dequeues (cancels, unlinks) an I/O request from an endpoint */
static int qe_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
{
@@ -2008,7 +2018,7 @@ static void ch9getstatus(struct qe_udc *udc, u8
request_type, u16 value,
udc-ep0_dir = USB_DIR_IN;
/* data phase */
- status = qe_ep_queue(ep-ep, req-req, GFP_ATOMIC);
+ status = __qe_ep_queue(ep-ep, req-req);
if (status == 0)
return;
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
On Tue, Nov 18, 2008 at 09:06:17AM -0600, Timur Tabi wrote: David Gibson wrote: Given the variety of strange I/O configurations in prototype and embedded platforms, I can't imagine this was a unique situation. So I've pushed my patch out, so anyone else in a similar situation can immediately turn their little udbg methods for whatever strange I/O they have into a fully-functional console. Maybe it's not something you'd want to go to release with, but it certainly simplifies life during bringup. Ok, I understand now. However, I would like to see two changes: 1) Re-arrange the Makefile as I pointed out in another post. Um.. yeah.. I'm a bit baffled by this.. all the existing backends are listed after hvc_console, I just added hvc_udbg to the end. I didn't really understand the rationale in that commit, but then I haven't had time to look at it very much yet. 2) Update the Kconfig help file to be very clear that this feature is only meaningful if the platform has a udbg back-end but no other console or TTY driver. Alrighty... -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC
Steven Rostedt writes: Can I add your Acked-by: to all these patches that I submitted? I'm going to recommit them with a consistent subject (all lower case ppc), but I'm not going to change the patches themselves. Would you two be fine with that? Or at least one of you? My preference would be for the patches to go through the powerpc tree unless there is a good reason for them to go via another tree. The style we use for the headline is powerpc: Add xyz feature or powerpc/subsystem: Fix foo bug. As for the acked-by, I feel I first need to go through the whole series again with the changes you have made recently. Have you reworked the earlier patches to avoid introducing any bugs, rather than just fixing the bugs with later patches? If you haven't, are you sure that the bugs won't cause any problems in bisecting? Also, what's the best place to find the latest patch set? Thanks again for doing all this work. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC
On Wed, 19 Nov 2008, Paul Mackerras wrote: Steven Rostedt writes: Can I add your Acked-by: to all these patches that I submitted? I'm going to recommit them with a consistent subject (all lower case ppc), but I'm not going to change the patches themselves. Would you two be fine with that? Or at least one of you? My preference would be for the patches to go through the powerpc tree unless there is a good reason for them to go via another tree. I have no problem with that. The only thing is that we have a lot of pending work still in the linux-tip tree, which you may need to pull in to get these patches working. Well, there's two or three commits in the generic code that I know the PPC code is dependent on. I could give you a list of commits in tip that need to go mainline first before we can pull in the PPC changes. Then you could wait till those changes make it into 29 and then you could push the PPC modifications in from your tree. The style we use for the headline is powerpc: Add xyz feature or powerpc/subsystem: Fix foo bug. We've been using the ftrace: subject format for most of our ftrace commits, and have been using ftrace, ppc: subject or ppc32 or ppc64 for those. But since this is a powerpc port, I will conform to your style. As for the acked-by, I feel I first need to go through the whole series again with the changes you have made recently. Have you reworked the earlier patches to avoid introducing any bugs, rather than just fixing the bugs with later patches? If you haven't, are you sure that the bugs won't cause any problems in bisecting? Fair enough. I'll rework the patches again to fold back in the changes based on your comments, as well as the comments of others. When I'm done, I'll repost to the list. This way, if you pull them in, you can add your Signed-off-by yourself. Also, what's the best place to find the latest patch set? I'll be keeping the changes in my repo: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git branch tip/ppc Note, this branch is based on top of Ingo's linux-tip tree. I can make a a branch ppc that will be based on top of mainline, and I can add the patches needed to get PPC working. The generic commits will have the ftrace: format. The generic ftrace patches will still need to go in through linux-tip. But when they do, feel free to push the PowerPC port in. Anyway, you are the ones that can test it better than we can. I have two PPC boxes that I test on, but I'm sure you have a lot more. Thanks again for doing all this work. Thank you for the reviews. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Silence timebase sync code
Trent Piepho writes: It's over a dozen lines of output and doesn't appear to provide any useful information. Even after looking at the code, I'm in the dark about what score 299, offset 250 means. I already put a very similar patch from Ben Herrenschmidt into my powerpc.git tree next branch, back on 5 November. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix BSR to allow mmap of small BSR on 64k kernel
Sonny Rao writes: - if (io_remap_pfn_range(vma, vma-vm_start, dev-bsr_addr PAGE_SHIFT, -size, vma-vm_page_prot)) + /* check for the case of a small BSR device and map one 4k page for it*/ + if (dev-bsr_len PAGE_SIZE size == PAGE_SIZE) + ret = remap_4k_pfn(vma, vma-vm_start, dev-bsr_addr 12, +vma-vm_page_prot); I think we should be checking that dev-bsr_len == 4096 here. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: allow configuring max stack dump depth
Johannes Berg writes: On my screen, when something crashes, I only have space for maybe 16 functions of the stack trace before the information above it scrolls off the screen. It's easy to hack the kernel to print out only that much, but it's harder to remember to do it. This patch introduces a config option for it so that I can keep the setting in my config. Could you make it depend on DEBUG_KERNEL or ADVANCED or something? + help + This option allows you to set the stack depth that the kernel + prints out in case your display is too small. The in case is a little ambiguous here. I suggest: + This option allows you to set the maximum depth that the kernel + prints in stack traces. This can be useful if your display + is too small. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: default IRQ affinity change in v2.6.27 (breaking several SMP PPC based systems)
David Miller wrote: From: Kumar Gala [EMAIL PROTECTED] Date: Fri, 24 Oct 2008 10:39:05 -0500 As for making it ARCH specific, that doesn't really help since not all PPC hw has the limitation I spoke of. Not even all MPIC (in our cases) have the limitation. Since the PPC code knows exactly which MPICs have the problem the PPC code is where the constraining can occur. I agree completely with the suggestion that the arch code has to interpret the cpumask as appropriate for the hardware, since the user can stick illegal values there anyways. Sorry for delay in replying to this. And sorry for causing regression on some ppc platforms. I totally agree with what Dave said above. ALL_CPUS is a sane default, platform code has to sanity check masks passed via set_affinity() calls anyway. So I beleive it should be fixed in the platform code. Max ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUG] ppc64 relocatable vmlinux builds even with undefined symbols
With the additon of -pie to build CONFIG_RELOCATABLE CONFIG_PPC64 kernels, even if a function is undefined we still get a vmlinux, System.map, and other files with no error message. This is with binutils 2.17 as built by debian with 2.6.28-rc5, CONFIG_EMBEDDED=y CONFIG_HOTPLUG=n CONFIG_PCI=y, CONFIG_RELOCATABLE=n arch/powerpc/kernel/built-in.o: In function `.pcibios_remove_root_bus': (.text+0x12dc4): undefined reference to `.pcibios_unmap_io_space' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 with CONFIG_RELOCATABLE=y LD init/built-in.o LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map Note that we set -pie for this combination. I tried adding seperately both --no-undefined and --no-allow-shlib-undefined to LDFLAGS_vmilnux, but the link still did not error out. I note that nm -u will detect the U symbol: $ nm -u /tmp/p-test/vmlinux w mach_cell w mach_iseries w mach_powermac U pcibios_unmap_io_space but that would either require duplicating cmd_vmlinux and adding an additonal check or modifing rule_vmlinux. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
