* Re: SYSFS: need a noncaching read
From: Heiko Schocher @ 2007-09-12 11:59 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, linux-kernel, Detlev Zundel
In-Reply-To: <20070912113907.GA24087@kroah.com>
Hello Greg,
Am Mittwoch, den 12.09.2007, 04:39 -0700 schrieb Greg KH:
> > > Do an lseek back to 0 and then re-read, you will get called in your
> > > driver again.
> >
> > No thats not true. I thought this too, but if I make a:
> >
> > seek (fd, 0L, SEEK_SET);
> >
> > in Userspace, there is no retrigger in the sysFS, my driver is *not*
> > called again. So I made a own sysfs_seek function, which does retrigger
> > the driver ...
>
> Hm, are you sure? Otherwise the poll() stuff would not work at all.
Yes.
Sysfs uses generic_file_llseek (). And in sysfs_read_file ()
buffer->needs_read_fill must be 1, to reread from the driver.
generic_file_llseek () doesnt change this variable.
Best regards
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [PATCH] IB/ehca: Make sure user pages are from hugetlb before using MR large pages
From: Joachim Fenkes @ 2007-09-12 12:39 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
From: Hoang-Nam Nguyen <hnguyen@de.ibm.com>
...because, on virtualized hardware like System p, we can't be sure that the
physical pages behind them are contiguous.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
Another patch for 2.6.24 that will apply cleanly on top of my previous
patchset. Please review and apply. Thanks!
drivers/infiniband/hw/ehca/ehca_classes.h | 8 ++--
drivers/infiniband/hw/ehca/ehca_mrmw.c | 82 +++++++++++++++++++++++++----
2 files changed, 75 insertions(+), 15 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 206d4eb..c2edd4c 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -99,10 +99,10 @@ struct ehca_sport {
struct ehca_sma_attr saved_attr;
};
-#define HCA_CAP_MR_PGSIZE_4K 1
-#define HCA_CAP_MR_PGSIZE_64K 2
-#define HCA_CAP_MR_PGSIZE_1M 4
-#define HCA_CAP_MR_PGSIZE_16M 8
+#define HCA_CAP_MR_PGSIZE_4K 0x80000000
+#define HCA_CAP_MR_PGSIZE_64K 0x40000000
+#define HCA_CAP_MR_PGSIZE_1M 0x20000000
+#define HCA_CAP_MR_PGSIZE_16M 0x10000000
struct ehca_shca {
struct ib_device ib_device;
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index 4c8f3b3..1bb9d23 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -41,6 +41,8 @@
*/
#include <asm/current.h>
+#include <linux/mm.h>
+#include <linux/hugetlb.h>
#include <rdma/ib_umem.h>
@@ -51,6 +53,7 @@
#define NUM_CHUNKS(length, chunk_size) \
(((length) + (chunk_size - 1)) / (chunk_size))
+
/* max number of rpages (per hcall register_rpages) */
#define MAX_RPAGES 512
@@ -279,6 +282,52 @@ reg_phys_mr_exit0:
} /* end ehca_reg_phys_mr() */
/*----------------------------------------------------------------------*/
+static int ehca_is_mem_hugetlb(unsigned long addr, unsigned long size)
+{
+ struct vm_area_struct **vma_list;
+ unsigned long cur_base;
+ unsigned long npages;
+ int ret, i;
+
+ vma_list = (struct vm_area_struct **) __get_free_page(GFP_KERNEL);
+ if (!vma_list) {
+ ehca_gen_err("Can not alloc vma_list");
+ return -ENOMEM;
+ }
+
+ down_write(¤t->mm->mmap_sem);
+ npages = PAGE_ALIGN(size + (addr & ~PAGE_MASK)) >> PAGE_SHIFT;
+ cur_base = addr & PAGE_MASK;
+
+ while (npages) {
+ ret = get_user_pages(current, current->mm, cur_base,
+ min_t(int, npages,
+ PAGE_SIZE / sizeof (*vma_list)),
+ 1, 0, NULL, vma_list);
+
+ if (ret < 0) {
+ ehca_gen_err("get_user_pages() failed "
+ "ret=%x cur_base=%lx", ret, cur_base);
+ goto is_hugetlb_out;
+ }
+
+ for (i = 0; i < ret; ++i)
+ if (!is_vm_hugetlb_page(vma_list[i])) {
+ ret = 0;
+ goto is_hugetlb_out;
+ }
+
+ cur_base += ret * PAGE_SIZE;
+ npages -= ret;
+ }
+ ret = 1;
+
+is_hugetlb_out:
+ up_write(¤t->mm->mmap_sem);
+ free_page((unsigned long) vma_list);
+
+ return ret;
+}
struct ib_mr *ehca_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
u64 virt, int mr_access_flags,
@@ -346,18 +395,29 @@ struct ib_mr *ehca_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
num_kpages = NUM_CHUNKS((virt % PAGE_SIZE) + length, PAGE_SIZE);
/* select proper hw_pgsize */
if (ehca_mr_largepage &&
- (shca->hca_cap_mr_pgsize & HCA_CAP_MR_PGSIZE_16M)) {
- if (length <= EHCA_MR_PGSIZE4K
- && PAGE_SIZE == EHCA_MR_PGSIZE4K)
- hwpage_size = EHCA_MR_PGSIZE4K;
- else if (length <= EHCA_MR_PGSIZE64K)
- hwpage_size = EHCA_MR_PGSIZE64K;
- else if (length <= EHCA_MR_PGSIZE1M)
- hwpage_size = EHCA_MR_PGSIZE1M;
- else
- hwpage_size = EHCA_MR_PGSIZE16M;
+ shca->hca_cap_mr_pgsize & HCA_CAP_MR_PGSIZE_16M) {
+ ret = ehca_is_mem_hugetlb(virt, length);
+ switch (ret) {
+ case 0: /* mem is not from hugetlb */
+ hwpage_size = PAGE_SIZE;
+ break;
+ case 1:
+ if (length <= EHCA_MR_PGSIZE4K
+ && PAGE_SIZE == EHCA_MR_PGSIZE4K)
+ hwpage_size = EHCA_MR_PGSIZE4K;
+ else if (length <= EHCA_MR_PGSIZE64K)
+ hwpage_size = EHCA_MR_PGSIZE64K;
+ else if (length <= EHCA_MR_PGSIZE1M)
+ hwpage_size = EHCA_MR_PGSIZE1M;
+ else
+ hwpage_size = EHCA_MR_PGSIZE16M;
+ break;
+ default: /* out of mem */
+ ib_mr = ERR_PTR(-ENOMEM);
+ goto reg_user_mr_exit1;
+ }
} else
- hwpage_size = EHCA_MR_PGSIZE4K;
+ hwpage_size = EHCA_MR_PGSIZE4K; /* ehca1 can only 4k */
ehca_dbg(pd->device, "hwpage_size=%lx", hwpage_size);
reg_user_mr_fallback:
--
1.5.2
^ permalink raw reply related
* Re: new NAPI interface broken for POWER architecture?
From: Christoph Raisch @ 2007-09-12 13:10 UTC (permalink / raw)
To: David Miller
Cc: ossthema, Paul Mackerras, netdev, Jan-Bernd Themann, linuxppc-dev,
Arnd Bergmann, Michael Ellerman, shemminger
In-Reply-To: <20070912.055004.88490155.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 12.09.2007 14:50:04:
> From: Jan-Bernd Themann <ossthema@de.ibm.com>
> Date: Fri, 7 Sep 2007 11:37:02 +0200
>
> > 2) On SMP systems: after netif_rx_complete has been called on CPU1
> > (+interruts enabled), netif_rx_schedule could be called on CPU2
> > (irq handler) before net_rx_action on CPU1 has checked
NAPI_STATE_SCHED.
> > In that case the device would be added to poll lists of CPU1 and
CPU2
> > as net_rx_action would see NAPI_STATE_SCHED set.
> > This must not happen. It will be caught when netif_rx_complete is
> > called the second time (BUG() called)
> >
> > This would mean we have a problem on all SMP machines right now.
>
> This is not a correct statement.
>
> Only on your platform do network device interrupts get moved
> around, no other platform does this.
>
> Sparc64 doesn't, all interrupts stay in one location after
> the cpu is initially choosen.
>
> x86 and x86_64 specifically do not move around network
> device interrupts, even though other device types do
> get dynamic IRQ cpu distribution.
>
> That's why you are the only person seeing this problem.
>
> I agree that it should be fixed, but we should also fix the IRQ
> distribution scheme used on powerpc platforms which is totally
> broken in these cases.
This is definitely not something we can change in the HEA device driver
alone.
It could also affect any other networking cards on POWER (e1000,s2io...).
Paul, Michael, Arndt, what is your opinion here?
Gruss / Regards
Christoph Raisch
^ permalink raw reply
* Re: new NAPI interface broken for POWER architecture?
From: David Miller @ 2007-09-12 13:27 UTC (permalink / raw)
To: RAISCH
Cc: ossthema, pmac, netdev, THEMANN, linuxppc-dev, ARNDB, ellerman,
shemminger
In-Reply-To: <OF2D6ED296.BDB04FBF-ONC1257354.00473703-C1257354.0048406C@de.ibm.com>
From: Christoph Raisch <RAISCH@de.ibm.com>
Date: Wed, 12 Sep 2007 15:10:08 +0200
> This is definitely not something we can change in the HEA device driver
> alone.
And it shouldn't be, x86 implements the policy in irq balance
daemon, powerpc should do it wherever it would be appropriate
there.
> Paul, Michael, Arndt, what is your opinion here?
I'm all ears too :)
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Christoph Hellwig @ 2007-09-12 13:49 UTC (permalink / raw)
To: Heiko Carstens
Cc: Michael Neuling, linux-kernel, Christoph Hellwig, linuxppc-dev,
paulus, Alan Cox, Andrew Morton, Linus Torvalds, David S. Miller,
Martin Schwidefsky
In-Reply-To: <20070912115257.GC7858@osiris.boeblingen.de.ibm.com>
On Wed, Sep 12, 2007 at 01:52:57PM +0200, Heiko Carstens wrote:
> > I might be missing something, but the the right fix is probably to
> > apply the arch patches from Alan to powerpc and s390. We don't want to
> > be left over without all the nice termios features on these platforms,
> > do we?
>
> But not in rc6 timeframe, I would guess?
Ask Alan..
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 14:00 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070912035351.GF20218@localhost.localdomain>
>>>> + uli1575@0 {
>>>> + reg = <0 0 0 0 0>;
>>>
>>> This looks kind of bogus...
>>
>> Its a PCIe to PCI bridge that is transparent.
>
> Right.... if it has no control registers, I think it should just lack
> 'reg', not define a zero-length register block.
"reg" for PCI config registers has length 0 always, it's defined that
way in the PCI binding.
But if this thing is transparent, it doesn't have PCI config regs.
>>>> + #size-cells = <2>;
>>>> + #address-cells = <3>;
>>>> + ranges = <02000000 0 80000000
>>>> + 02000000 0 80000000
>>>> + 0 20000000
>>>> + 01000000 0 00000000
>>>> + 01000000 0 00000000
>>>> + 0 00100000>;
>
> And if truly transparent, it should perhaps have just ranges;
> indicating that child addresses are identity mapped to parent
> addresses.
If truly transparent, the node should just not be there at all!
>>>> + pci_bridge@0 {
>>>
>>> Ok.. why is pci_bridge nested within uli1575 - with the matching reg
>>> and ranges, it looks like they ought to be one device. Also if this
>>> is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
>>
>> We've been using this as it stands for a while. If there are some
>> changes here that make sense I'm willing to make them.
>
> Right, at present I don't see why you couldn't just ditch the
> pci_bridge node, and drop its contents straight into the uli1575 node.
Yeah. The preferred name for PCI-to-PCI bridge nodes is simply "pci",
btw.
Segher
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 14:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <AC5C6EF4-EE8E-487F-BF45-3653A5C2617D@kernel.crashing.org>
>>> + i8259: interrupt-controller@20 {
>>> + reg = <1 20 2
>>> + 1 a0 2
>>> + 1 4d0 2>;
>>> + clock-frequency = <0>;
>>
>> Hrm.. what is clock-frequency for on an i8259? I see that other 8259
>> descriptions have this as well, so it's not a problem with this patch
>> specifically.
>
> Its a copy-paste thing so I don't know.
If your bootwrapper doesn't fill in this value, you should get rid
of this property -- better to have no value than to have the wrong
value, esp. since it's probably unused anyway.
Segher
^ permalink raw reply
* Re: writing to flash from linux
From: David H. Lynch Jr. @ 2007-09-12 14:15 UTC (permalink / raw)
To: Yoni Levin; +Cc: linuxppc-embedded
In-Reply-To: <1E2D24B6DA8A4EE68CFFD33998B2BC26.MAI@mail.livedns.co.il>
Yoni Levin wrote:
> Hi , I have EN29LV640H flash (http://www.eonsdi.com/pdf/EN29LV640.pdf)
>
> On my mpc83xx board.
>
> How can I write data to flash from linux.?
>
> I guess it done with mtd , there is an example somewhere?
>
> Thanks.
>
>
I know nothing specific about your board or flash, but MTD is the
proper system for handling flash.
You need an mtd driver for your board - it is possible something
already exists, but if not you need to write it.
That driver may be extremely simple - if your boards flash system if
not very complex.
Some of the issues are ?
Is your flash partitioned - are there multiple regaions of flash
that each serve different purposes - such as a boot loader, a kernel, an
initrd and separately a file system - or even more than one file system.
Is your flash chip recognized by Linux (likely)
Are there special conditions for reading/writing flash on your board
- i.e. do you have to enable special voltages or protection bits - board
specific protection not chips specific,
Does your board "window" the flash such that only part of it is in
the CPU's memory space at one time.
Does your board have some odd quicks for accessing flash - like
requiring a 32 bit read to get a 16bit value ?
All of these are handled by the mtd driver
If as an example you have a very standard CFI flash chip, that has
no windowing, no special read/write enables, is always fully in the CPU
memory space at the same place,
and all the flash is going to be used for a single filesystem with
no reserved blocks, bootloaders etc.
The mtd driver could be trivial, there might even be something that
can just be used as is.
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* MirrorBit FLASH Read/Write Problem
From: Billalabeitia, Jose Carlos (GE Indust, ConsInd) @ 2007-09-12 14:21 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
Hello:
I would like to know if someone out there has experienced the
following
problems in the S29GL064M90TFIR60 FLASH (MirrorBit Technology):
- After two consecutive readings at the same random memory location,
the first reading is
all zeros, and the second one is the data OK.
- After programming one word to a random memory location, the data
stored is all zeros or the
adjacent memory location is affected with all zeros.
Thank you
Billa
[-- Attachment #2: Type: text/html, Size: 3150 bytes --]
^ permalink raw reply
* Re: [PATCH 08/12] IB/ehca: Replace get_paca()->paca_index by the more portable smp_processor_id()
From: Joachim Fenkes @ 2007-09-12 14:42 UTC (permalink / raw)
To: Nathan Lynch
Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <20070911145131.GN32388@localdomain>
On Tuesday 11 September 2007 16:51, Nathan Lynch wrote:
> > - get_paca()->paca_index, __FUNCTION__, \
> > + smp_processor_id(), __FUNCTION__, \
>
> I think I see these macros used in preemptible code (e.g. ehca_probe),
> where smp_processor_id() will print a warning when
> CONFIG_DEBUG_PREEMPT=y. Probably better to use raw_smp_processor_id.
You're right, man. The processor id doesn't need to be preemption-safe in this
context, so that would be a bogus warning. Thanks for pointing this out. I'll
post a new version of this patch.
Joachim
^ permalink raw reply
* [PATCH 08/12] IB/ehca: Replace get_paca()->paca_index by the more portable raw_smp_processor_id()
From: Joachim Fenkes @ 2007-09-12 14:44 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200709111533.14333.fenkes@de.ibm.com>
We can use raw_smp_processor_id() here because the processor ID is only used
for debug output and may therefore be preemption-unsafe.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
This is the same patch, but with smp_processor_id() replaced by
raw_smp_processor_id(), as kindly pointed out to me by Nathan. Thanks!
drivers/infiniband/hw/ehca/ehca_tools.h | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h b/drivers/infiniband/hw/ehca/ehca_tools.h
index f9b264b..4a8346a 100644
--- a/drivers/infiniband/hw/ehca/ehca_tools.h
+++ b/drivers/infiniband/hw/ehca/ehca_tools.h
@@ -73,37 +73,37 @@ extern int ehca_debug_level;
if (unlikely(ehca_debug_level)) \
dev_printk(KERN_DEBUG, (ib_dev)->dma_device, \
"PU%04x EHCA_DBG:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, \
+ raw_smp_processor_id(), __FUNCTION__, \
## arg); \
} while (0)
#define ehca_info(ib_dev, format, arg...) \
dev_info((ib_dev)->dma_device, "PU%04x EHCA_INFO:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg)
+ raw_smp_processor_id(), __FUNCTION__, ## arg)
#define ehca_warn(ib_dev, format, arg...) \
dev_warn((ib_dev)->dma_device, "PU%04x EHCA_WARN:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg)
+ raw_smp_processor_id(), __FUNCTION__, ## arg)
#define ehca_err(ib_dev, format, arg...) \
dev_err((ib_dev)->dma_device, "PU%04x EHCA_ERR:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg)
+ raw_smp_processor_id(), __FUNCTION__, ## arg)
/* use this one only if no ib_dev available */
#define ehca_gen_dbg(format, arg...) \
do { \
if (unlikely(ehca_debug_level)) \
printk(KERN_DEBUG "PU%04x EHCA_DBG:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg); \
+ raw_smp_processor_id(), __FUNCTION__, ## arg); \
} while (0)
#define ehca_gen_warn(format, arg...) \
printk(KERN_INFO "PU%04x EHCA_WARN:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg)
+ raw_smp_processor_id(), __FUNCTION__, ## arg)
#define ehca_gen_err(format, arg...) \
printk(KERN_ERR "PU%04x EHCA_ERR:%s " format "\n", \
- get_paca()->paca_index, __FUNCTION__, ## arg)
+ raw_smp_processor_id(), __FUNCTION__, ## arg)
/**
* ehca_dmp - printk a memory block, whose length is n*8 bytes.
--
1.5.2
^ permalink raw reply related
* Re: [POWERPC] PCI Bug fix for MRM failure in PPC 440EPx
From: Josh Boyer @ 2007-09-12 14:45 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200708301033.28423.ml@stefan-roese.de>
On Thu, 30 Aug 2007 10:33:28 +0200
Stefan Roese <ml@stefan-roese.de> wrote:
> Problem Description and Fix : Memory Read Multiples(MRM) do not work
> correctly on PPC 440EPX based systems. A PCI driver determines whether
> MRMs are supported by reading the PCI cache line size register. If this
> value is zero then MRMs are not supported. However some PCI drivers
> write to the PCI cache line size register on initialization. This
> results in MRMs being sent to system memory on 440EPX based systems.
> Since MRMs do not work correctly in 440EPX based systems this may cause
> system hang. This patch solves this problem by modifying the PPC
> platform specific PCI configuration register write function, by forcing
> any value written to PCI_CACHE_LINE_SIZE register to be 0. This fix was
> tested on different PCI cards : i.e. Silicon Image ATA card and Intel
> E1000 GIGE card. On Silicon Image ATA card without this fix in place
> creating a filesystem on IDE drive "mke2fs /dev/hda" was hanging the
> system. MRMs issued by the PCI card were seen on the PCI analyzer since
> the Silicon Image driver was setting the PCI_CACHE_LINE_SIZE register to
> 255. With this patch the PCI_CACHE_LINE_SIZE register was 0 and only
> Memory Reads were seen on PCI analyzer.
>
> Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> ---
> I know this patch is a little "dirty", but perhaps somebody has a better
> idea to fix this problem. Thanks.
For the peanut gallery, Stefan and I discussed this a bit on IRC today
and a different approach for arch/powerpc is going to be looked at
instead. Namely, introducing a new flag for indirect_type in the
pci_controller structure to key off of instead of having ifdefs.
josh
^ permalink raw reply
* RE: futex priority based wakeup
From: Benedict, Michael @ 2007-09-12 14:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1656e050709111714g1a84656bvd7823f5fc43345dd@mail.gmail.com>
Nguyen Nguyen wrote:
> I have seen something similar before. Our fix was to use
> pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED)
> so child threads wouldn't inherit attribute from parent.
> On 9/11/07, Ilya Lipovsky <lipovsky@cs.bu.edu> wrote:
>=20
> Hmm. Just for kicks - inside the important thread could you add:
<snip>
> printf("important's policy is %d and priority is %d\n",
curpolicy,
<snip>
> Do similar for the unimportant thread, and see if you
> get anything weird -
> e.g. priorities come out to be the same for threads.
Thank you both! You were each correct, and your input has been greatly
appreciated.
Adding the printf() resulted in:
unimportant's policy is 0 and priority is 0
unimportant waiting for futex
important's policy is 0 and priority is 0
important waiting for futex
main's policy is 0 and priority is 0
futex FUTEX_WAKE
unimportant's policy is 0 and priority is 0
unimportant got futex!
important's policy is 0 and priority is 0
important got futex!
Adding the PTHREAD_EXPLICIT_SCHED resulted in:
unimportant's policy is 1 and priority is 1
unimportant waiting for futex
important's policy is 1 and priority is 99
important waiting for futex
main's policy is 0 and priority is 0
futex FUTEX_WAKE
important's policy is 1 and priority is 99
important got futex!
unimportant's policy is 1 and priority is 1
unimportant got futex!
Verifying with pthread_muxtex / glibc 2.3.6:
unimportant's policy is 1 and priority is 1
unimportant waiting for mutex
important's policy is 1 and priority is 99
important waiting for mutex
main's policy is 0 and priority is 0
main unlocking mutex
important's policy is 1 and priority is 99
important got mutex!
unimportant's policy is 1 and priority is 1
unimportant got mutex!
And, to come full circle, regression on 2.6.21 resulted in:
unimportant's policy is 1 and priority is 1
unimportant waiting for futex
important's policy is 1 and priority is 99
important waiting for futex
main's policy is 0 and priority is 0
futex FUTEX_WAKE
unimportant's policy is 1 and priority is 1
unimportant got futex!
important's policy is 1 and priority is 99
important got futex!
Now it is time to audit my other code and make sure to add
PTHREAD_EXPLICIT_SCHED where appropriate. Thank you.
-Michael
^ permalink raw reply
* Re: Which 2.6 kernel for MPC5200
From: Jon Smirl @ 2007-09-12 15:08 UTC (permalink / raw)
To: Robert Schwebel, Domen Puncer; +Cc: Babarovic Ivica, linuxppc-embedded
In-Reply-To: <20070912062819.GI23573@pengutronix.de>
On 9/12/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> We have the OSELAS.BSP patch stack for the PCM030 working ontop of
> Linus' git. It still uses an older version of the Bestcom patches, so if
> you do some work in that area, please keep me informed about your
> progress.
What is the best way to proceed? I need to be on current git since we
are integrating a wireless driver that is tracking current git and the
mac80211 work.
I have Phytec (pcm030) and Efika hardware but I don't have a 5200lite.
Our prototype hardware uses the pcm030 module on a custom baseboard.
The best thing for me would be to get a FEC driver merged. That is the
largest piece of code that is floating around. Getting that merged
would give me a stable base to build future patches on.
I'd also like to get support for the pcm030 (minus real-time) merged.
That isn't a lot of code once FEC is in the kernel.
Domen has posted this driver "[RFC PATCH v0.1] net driver: mpc52xx
fec". I can work on breaking that up, but I don't have a 5200lite so I
will have to port to pcm030. I don't want to start on this if someone
else is already doing it.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* MDIO & phy device tree bindings (was Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port)
From: Kumar Gala @ 2007-09-12 15:08 UTC (permalink / raw)
To: David Gibson, Andy Fleming
Cc: linuxppc-dev@ozlabs.org list, Yoder Stuart-B08248
In-Reply-To: <20070912035351.GF20218@localhost.localdomain>
David,
I'm splitting this up since the mdio & phy comments are more general
that the 8572.dts
>>> [snip]
>>>> + mdio@24520 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + device_type = "mdio";
>>>
>>> I don't think we actually have an mdio device_type binding defined.
>>
>> We've had this on 83xx/85xx/86xx device trees for a far amount of
>> time now. Look at section 2a in booting-without-of.txt
>
> Ah, so we have; sorry. Although the binding as it is currently
> written is pretty much pointless - it should actually define some
> mappings between dt properties / addresses and the standards defining
> the MDIO bus.x
that's a doc issue at this point
>>>> + compatible = "gianfar";
>>>
>>> This needs to be more specific. And it certainly shouldn't be the
>>> same compatible string as the ethernet MACs have.
>>
>> Why not its the same controller? Again, we've been doing this for
>> some period of time already.
>
> Yes you have, but it's still crap. 'compatible' should be sufficient
> to distinguish the driver needed for device nodes, but the MACs and
> MDIO should clearly have different drivers (or at least, different
> parts of a driver).
don't disagree will see about coming up with a better name, and
deprecating 'gianfar'.
>>>> + reg = <24520 20>;
>>>> + phy0: ethernet-phy@0 {
>>>> + interrupt-parent = <&mpic>;
>>>> + interrupts = <a 1>;
>>>> + reg = <0>;
>>>> + device_type = "ethernet-phy";
>>>
>>> Do we actually have an ethernet-phy device_type binding? If not, we
>>> should kill this. 'compatible' properties for phys would
>>> probably be
>>> a good idea, though (giving the actual phy model).
>>
>> Look section 2c in booting-without-of.txt
>
> Ah, yes. That one's a rather less redeemable pointless device_type
> binding. We should kill it from booting-without-of.txt.
agreed, will poke andy on this.
- k
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-12 15:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070912035351.GF20218@localhost.localdomain>
>>>> + reg = <e0000 1000>;
>>>> + fsl,has-rstcr;
>>>> + };
>>>> +
>>>> + mpic: pic@40000 {
>>>> + clock-frequency = <0>;
>>>> + interrupt-controller;
>>>> + #address-cells = <0>;
>>>> + #interrupt-cells = <2>;
>>>> + reg = <40000 40000>;
>>>> + compatible = "chrp,open-pic";
>>>> + device_type = "open-pic";
>>>> + big-endian;
>>>> + };
>>>> + };
>>>> +
>>>> + pcie@ffe08000 {
>>>> + compatible = "fsl,mpc8548-pcie";
>>>
>>> And again, "fsl,mpc8572-pcie", "fsl,mpc8548-pcie".
>>
>> But why? there is no difference between the PCIe controller in
>> mpc8548 and mpc8572?
>
> As far as you've yet discovered...
Its the same actual block from design. I'll think some on this. If
I had some macro support in the dtc I wouldn't feel so bad about
doing this. Its the edit/modify/fix cycle that's a pain.
>>>> + uli1575@0 {
>>>> + reg = <0 0 0 0 0>;
>>>
>>> This looks kind of bogus...
>>
>> Its a PCIe to PCI bridge that is transparent.
>
> Right.... if it has no control registers, I think it should just lack
> 'reg', not define a zero-length register block.
>
>>>> + #size-cells = <2>;
>>>> + #address-cells = <3>;
>>>> + ranges = <02000000 0 80000000
>>>> + 02000000 0 80000000
>>>> + 0 20000000
>>>> + 01000000 0 00000000
>>>> + 01000000 0 00000000
>>>> + 0 00100000>;
>
> And if truly transparent, it should perhaps have just ranges;
> indicating that child addresses are identity mapped to parent
> addresses.
>
>>>> +
>>>> + pci_bridge@0 {
>>>
>>> Ok.. why is pci_bridge nested within uli1575 - with the matching reg
>>> and ranges, it looks like they ought to be one device. Also if this
>>> is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
>>
>> We've been using this as it stands for a while. If there are some
>> changes here that make sense I'm willing to make them.
>
> Right, at present I don't see why you couldn't just ditch the
> pci_bridge node, and drop its contents straight into the uli1575 node.
upon further review and discussion you are right about dropping the
pci_bridge@0 node from the ULI. However we do need to add a pcie@0
node to cover the virtual P2P bridge in the PHB. So we have something
like:
pcie@ff808000 {
pcie@0 {
uli@0 {
}
}
}
- k
^ permalink raw reply
* Re: Which 2.6 kernel for MPC5200
From: Grant Likely @ 2007-09-12 15:14 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded, Domen Puncer, Babarovic Ivica
In-Reply-To: <9e4733910709120808i687ab5far924201f8a910759c@mail.gmail.com>
On 9/12/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 9/12/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> > We have the OSELAS.BSP patch stack for the PCM030 working ontop of
> > Linus' git. It still uses an older version of the Bestcom patches, so if
> > you do some work in that area, please keep me informed about your
> > progress.
>
> What is the best way to proceed? I need to be on current git since we
> are integrating a wireless driver that is tracking current git and the
> mac80211 work.
>
> I have Phytec (pcm030) and Efika hardware but I don't have a 5200lite.
> Our prototype hardware uses the pcm030 module on a custom baseboard.
>
> The best thing for me would be to get a FEC driver merged. That is the
> largest piece of code that is floating around. Getting that merged
> would give me a stable base to build future patches on.
>
> I'd also like to get support for the pcm030 (minus real-time) merged.
> That isn't a lot of code once FEC is in the kernel.
>
> Domen has posted this driver "[RFC PATCH v0.1] net driver: mpc52xx
> fec". I can work on breaking that up, but I don't have a 5200lite so I
> will have to port to pcm030. I don't want to start on this if someone
> else is already doing it.
Sylvain's bestcomm patches need be cleaned up and resubmitted before
the next merge window opens. AFAIK, the code is pretty much ready,
and all the comments have been addressed. All that is required is the
final push to tidy the patchset and post to the list one more time.
Sylvain said that he was going to get this done last weekend, but I
haven't heard back from him yet.
Sylvain, if you need help, please let me know. I'll happily take on
the last bit of tidy work if that's what is needed to be finished
before the merge window. (And it needs to be ready *before*, not
during if I'm judging the prevailing winds correctly).
Cheers,
g.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Define termios_1 functions for powerpc, s390, avr32 and frv
From: Paul Mackerras @ 2007-09-12 15:16 UTC (permalink / raw)
To: Linus Torvalds, akpm
Cc: Michael Neuling, hskinnemoen, heiko.carstens, linux-kernel,
linuxppc-dev, Alan Cox, davem
Commit f629307c857c030d5a3dd777fee37c8bb395e171 introduced uses of
kernel_termios_to_user_termios_1 and user_termios_to_kernel_termios_1
on all architectures. However, powerpc, s390, avr32 and frv don't
currently define those functions since their termios struct didn't
need to be changed when the arbitrary baud rate stuff was added, and
thus the kernel won't currently build on those architectures.
This adds definitions of kernel_termios_to_user_termios_1 and
user_termios_to_kernel_termios_1 to include/asm-generic/termios.h
which are identical to kernel_termios_to_user_termios and
user_termios_to_kernel_termios respectively. The definitions are the
same because the "old" termios and "new" termios are in fact the same
on these architectures (which are the same ones that use
asm-generic/termios.h).
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Linus, this seems a bit cleaner than putting ifdefs in
drivers/char/tty_ioctl.c, and it fixes the compile error on powerpc.
Your choice whether to use this patch or Tony's.
diff --git a/include/asm-generic/termios.h b/include/asm-generic/termios.h
index 3769e6b..33dca30 100644
--- a/include/asm-generic/termios.h
+++ b/include/asm-generic/termios.h
@@ -63,6 +63,8 @@ static inline int kernel_termios_to_user_termio(struct termio __user *termio,
#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, sizeof(struct termios))
#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct termios))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u, sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k, sizeof(struct termios))
#endif /* __ARCH_TERMIO_GETPUT */
^ permalink raw reply related
* Re: [POWERPC] PCI Bug fix for MRM failure in PPC 440EPx
From: Kumar Gala @ 2007-09-12 15:14 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070912094536.013bf903@weaponx.rchland.ibm.com>
On Sep 12, 2007, at 9:45 AM, Josh Boyer wrote:
> On Thu, 30 Aug 2007 10:33:28 +0200
> Stefan Roese <ml@stefan-roese.de> wrote:
>
>> Problem Description and Fix : Memory Read Multiples(MRM) do not work
>> correctly on PPC 440EPX based systems. A PCI driver determines
>> whether
>> MRMs are supported by reading the PCI cache line size register. If
>> this
>> value is zero then MRMs are not supported. However some PCI drivers
>> write to the PCI cache line size register on initialization. This
>> results in MRMs being sent to system memory on 440EPX based systems.
>> Since MRMs do not work correctly in 440EPX based systems this may
>> cause
>> system hang. This patch solves this problem by modifying the PPC
>> platform specific PCI configuration register write function, by
>> forcing
>> any value written to PCI_CACHE_LINE_SIZE register to be 0. This
>> fix was
>> tested on different PCI cards : i.e. Silicon Image ATA card and Intel
>> E1000 GIGE card. On Silicon Image ATA card without this fix in place
>> creating a filesystem on IDE drive "mke2fs /dev/hda" was hanging the
>> system. MRMs issued by the PCI card were seen on the PCI analyzer
>> since
>> the Silicon Image driver was setting the PCI_CACHE_LINE_SIZE
>> register to
>> 255. With this patch the PCI_CACHE_LINE_SIZE register was 0 and only
>> Memory Reads were seen on PCI analyzer.
>>
>> Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
>> Signed-off-by: Stefan Roese <sr@denx.de>
>>
>> ---
>> I know this patch is a little "dirty", but perhaps somebody has a
>> better
>> idea to fix this problem. Thanks.
>
> For the peanut gallery, Stefan and I discussed this a bit on IRC today
> and a different approach for arch/powerpc is going to be looked at
> instead. Namely, introducing a new flag for indirect_type in the
> pci_controller structure to key off of instead of having ifdefs.
I assume you'll be adding to the 'quirk' flags that we already have
in place.
- k
^ permalink raw reply
* Re: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Scott Wood @ 2007-09-12 15:19 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <46B96294322F7D458F9648B60E15112C85D755@zch01exm26.fsl.freescale.net>
On Wed, Sep 12, 2007 at 03:13:09AM -0700, Zhang Wei-r63237 wrote:
> I have a strange issue here. If I rename 'fsl,dma' to 'fsl,mpc8540-dma',
> the 'fsl,mpc8540-dma-channel' will be also regarded as DMA device not
> DMA channel.
What tree are you using? Commit 804ace8881d211ac448082e871dd312132393049
in Paul's git tree should have fixed that.
-Scott
^ permalink raw reply
* Re: new NAPI interface broken for POWER architecture?
From: Arnd Bergmann @ 2007-09-12 15:18 UTC (permalink / raw)
To: Christoph Raisch
Cc: ossthema, Paul Mackerras, netdev, Jan-Bernd Themann, linuxppc-dev,
Michael Ellerman, shemminger, David Miller
In-Reply-To: <OF2D6ED296.BDB04FBF-ONC1257354.00473703-C1257354.0048406C@de.ibm.com>
On Wednesday 12 September 2007, Christoph Raisch wrote:
> David Miller <davem@davemloft.net> wrote on 12.09.2007 14:50:04:
>
> > I agree that it should be fixed, but we should also fix the IRQ
> > distribution scheme used on powerpc platforms which is totally
> > broken in these cases.
>
> This is definitely not something we can change in the HEA device driver
> alone.
> It could also affect any other networking cards on POWER (e1000,s2io...).
>
> Paul, Michael, Arndt, what is your opinion here?
The situation on Cell with the existing south bridge chips is that
interrupts _never_ get moved around, but are routed to specific
SMT threads by the firmware, while Linux does not interfere with
this.
We have been thinking about changing this so we can distribute
interrupts over all SMT threads in a given NUMA node, or even
over all logical CPUs in the system by reprogramming the
interrupt controller after each interrupt, but the current Axon bridge
chip will always have all devices routed to the same target CPU,
so it's unclear whether that is even an advantage.
Arnd <><
^ permalink raw reply
* Patches for 2.6.24
From: Grant Likely @ 2007-09-12 15:48 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev, Paul Mackerras
Kumar, can you please pick up the following patches and push them to paulus?
http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
http://patchwork.ozlabs.org/linuxppc/patch?id=13235
http://patchwork.ozlabs.org/linuxppc/patch?id=13249
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Patches for 2.6.24
From: Kumar Gala @ 2007-09-12 15:57 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <fa686aa40709120848x4720554jc46c8cd9ae3f355@mail.gmail.com>
On Sep 12, 2007, at 10:48 AM, Grant Likely wrote:
> Kumar, can you please pick up the following patches and push them
> to paulus?
>
> http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
I'll hand this one.
> http://patchwork.ozlabs.org/linuxppc/patch?id=13235
> http://patchwork.ozlabs.org/linuxppc/patch?id=13249
bootwrapper patches should be ack'd by david gibson and picked up by
paul at this point.
Did you have some other 834x defconfig updates as well?
- k
^ permalink raw reply
* Re: still using stabs debug format?
From: Kumar Gala @ 2007-09-12 16:00 UTC (permalink / raw)
To: bje, Ulrich Weigand
Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, Ed Swarthout
In-Reply-To: <0D968216-6743-498E-9723-F029FF3746C1@kernel.crashing.org>
Ben, Uli
Paul/BenH suggested that you might be able to help with my question.
> On Aug 17, 2007, at 7:54 PM, Segher Boessenkool wrote:
>
>>> Is anyone really still using the stabs format for kernel debug?
>>>
>>> can we kill off the .stabs references?
>>
>> What, you want to replace them with dwarf markup? Or just
>> get rid of the debug info completely?
>
> There are two users today:
>
> * N_SO for file information we can easily make into .file
> * N_FUN used in _GLOBAL() that marks it a 'function' is a bit
> misleading since we use this for both functions and data. Not sure
> what to do about that one, any suggestions?
#define _GLOBAL(n) \
.text; \
.stabs __stringify(n:F-1),N_FUN,0,0,n;\
.globl n; \
n:
this is the .stabs reference I'm trying to figure out what the dwarf
equiv would be.
- k
^ permalink raw reply
* Re: Patches for 2.6.24
From: Grant Likely @ 2007-09-12 16:02 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <B658701C-576E-459B-9FF4-BF43B429FCBB@kernel.crashing.org>
On 9/12/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 12, 2007, at 10:48 AM, Grant Likely wrote:
>
> > Kumar, can you please pick up the following patches and push them
> > to paulus?
> >
> > http://patchwork.ozlabs.org/linuxppc-embedded/patch?id=11303
>
> I'll hand this one.
>
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13235
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13249
>
> bootwrapper patches should be ack'd by david gibson and picked up by
> paul at this point.
Okay, David has already acked these. Paulus, can you please pick them up?
Thanks,
g.
>
> Did you have some other 834x defconfig updates as well?
I did; but it look like I need to rebase it again. I'll try to get
that done today.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox