On Tue, May 12, 2009 at 04:52:45PM +1000, Stephen Rothwell wrote:
> Hi Nick,
>
> On Tue, 12 May 2009 16:03:52 +1000 Stephen Rothwell
> wrote:
> >
> > This is what I have been getting for the last few days:
>
> bisected into the net changes, I will follow up there, sorry.
No problem. Phew, your
Hi Nick,
On Tue, 12 May 2009 16:03:52 +1000 Stephen Rothwell
wrote:
>
> This is what I have been getting for the last few days:
bisected into the net changes, I will follow up there, sorry.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
At Mon, 11 May 2009 21:54:51 +0200,
Roel Kluin wrote:
>
> To avoid direct access to the driver_data pointer in struct device, the
> functions dev_get_drvdata() and dev_set_drvdata() should be used.
>
> Signed-off-by: Roel Kluin
The same fix has been already in Greg's tree (and thus in linux-nex
On Tue, 12 May 2009 07:59:18 +0200 Nick Piggin wrote:
>
> On Tue, May 12, 2009 at 03:56:13PM +1000, Stephen Rothwell wrote:
> > Hi Nick,
> >
> > On Tue, 12 May 2009 06:57:16 +0200 Nick Piggin wrote:
> > >
> > > Hmm, I think (hope) your problems were fixed with the recent memory
> > > coruption b
On Tue, May 12, 2009 at 03:56:13PM +1000, Stephen Rothwell wrote:
> Hi Nick,
>
> On Tue, 12 May 2009 06:57:16 +0200 Nick Piggin wrote:
> >
> > Hmm, I think (hope) your problems were fixed with the recent memory
> > coruption bug fix for SLQB. (if not, let me know)
> >
> > This one possibly looks
Hi Nick,
On Tue, 12 May 2009 06:57:16 +0200 Nick Piggin wrote:
>
> Hmm, I think (hope) your problems were fixed with the recent memory
> coruption bug fix for SLQB. (if not, let me know)
>
> This one possibly looks like a problem with remote memory allocation
> or memory hotplug or something lik
On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer
wrote:
>> > OK, so the key question seems to be *when* the bitstream is
> associated
>> > with the
>> > device tree. If at bitstream generation time, you can prepend the
> .dtb
>> > to the bitstream. As long as the dtb doesn't contain the ma
On Mon, May 11, 2009 at 7:12 PM, David Gibson
wrote:
> On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
>> In other words; having your bootloader support FDT is preferred, but
>> not required.
>
> I wouldn't even go so far as to say it's preferred. IMO, people have
> gone a bit prema
On Mon, May 11, 2009 at 06:21:35AM -0600, Matthew Wilcox wrote:
> On Mon, May 11, 2009 at 05:34:07PM +0530, Sachin Sant wrote:
> > Matthew Wilcox wrote:
> >> On Mon, May 11, 2009 at 05:16:10PM +0530, Sachin Sant wrote:
> >>
> >>> Today's Next tree failed to boot on a Power6 box with following BU
> -Original Message-
> From: David H. Lynch Jr. [mailto:dh...@dlasys.net]
> Sent: Monday, May 11, 2009 7:35 PM
> To: Stephen Neuendorffer; linuxppc-dev@ozlabs.org
> Subject: Re: device trees.
>
> Stephen Neuendorffer wrote:
> >
> >> Many of our systems are LX systems but currently we are
> > +struct arch_hw_breakpoint {
> > + char*name; /* Contains name of the symbol to set bkpt */
> > + unsigned long address;
> > + u8 type;
> > +};
>
> Can you reorder this to pack the struct better (ie. put the unsigned
> long first).
Oops, this is a char * not j
Stephen Neuendorffer wrote:
>
>> Many of our systems are LX systems but currently we are not running
>> Linux on them.
>>
>
> Master SelectMap, I presume? What FPGA family?
> Does the FPGA have access to the CPLD after boot, other than through the
> configuration pins?
>
>
One of the skill
On Tue, 2009-05-12 at 08:56 +1000, David Gibson wrote:
> On Mon, May 11, 2009 at 05:38:16PM -0400, David H. Lynch Jr. wrote:
> > Grant Likely wrote:
> > >>Anyway, all I was looking for was a leg up on figuring out how to do
> > >> what I want with them. Rather than starting from scratch.
> > >>
i tried to fetch data from periphial memories with DMA
the flow as following
flags = claim_dma_lock();
disable_dma(DMA_CH);
clear_dma_ff();
set_dma_count(DMA_CH, 4);
set_dma_addr(DMA_CH, virt_to_bus(kv_buf));
release_dma_lock(flags);
enable_dma(DMA_CH);
the code hault at disable_dma(DMA_CH)
in
On Mon, May 11, 2009 at 05:09:27PM -0600, Grant Likely wrote:
> On Mon, May 11, 2009 at 3:38 PM, David H. Lynch Jr. wrote:
> > Grant Likely wrote:
> >>
> >> What do you mean by "one size fits all solution?"
> >>
> >> The kernel doesn't care where the device tree comes from. All it
> >> cares abou
> Hi PPC Dev folks,
> Please find a patch below that implements the proposed Hardware
> Breakpoint interfaces for PPC64 architecture.
>
> As a brief introduction, the proposed Hardware Breakpoint
> infrastructure provides generic in-kernel interfaces to which users
> from kernel- and user-sp
On Mon, May 11, 2009 at 12:54:58PM -0400, David H. Lynch Jr. wrote:
> Timur Tabi wrote:
> > On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr.
> > wrote:
> >
> > So all you need to do is have your boot loader create a device tree
> > from scratch. If you're using U-Boot, then you can already do
On Mon, May 11, 2009 at 05:38:16PM -0400, David H. Lynch Jr. wrote:
> Grant Likely wrote:
> >
> > What do you mean by "one size fits all solution?"
> >
> > The kernel doesn't care where the device tree comes from. All it
> > cares about is that by the time the kernel is started the device tree
This started out as a thread on the ppc list, but on the suggestion of
DaveM and Paul Mackerras I'm expanding the receiver list a bit.
Currently, if a softirq is raised in process context the
TIF_RESCHED_PENDING flag gets set and on return to userspace we run the
scheduler, expecting it to switch
On Mon, May 11, 2009 at 5:19 PM, Stephen Neuendorffer
wrote:
>
>> >> The best alternative to creating the device tree dynamically
> would
>> >> be to
>> >> append the devicetree to the bitimage in a way the boot loader
> could
>> >> always find it.
>> >>
>> >
>> > That sounds like a good sol
> >>The best alternative to creating the device tree dynamically
would
> >> be to
> >>append the devicetree to the bitimage in a way the boot loader
could
> >> always find it.
> >>
> >
> > That sounds like a good solution to me.
> >
> I am glad you like it. If Xilinx would like to offe
Chris Friesen writes:
> Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT
> set (and maybe doing other stuff if there are no messages). In this
> case, schedule() would re-run the spinning task rather than running
> ksoftirqd. This could prevent any incoming packets from act
From: "Chris Friesen"
Date: Mon, 11 May 2009 12:25:54 -0600
> David Miller wrote:
>
>> You know, for networking over loopback (one of the only real cases
>> that even matters, if we get a hard interrupt then the return from
>> that would process any softints), we probably make out just fine
>> a
On Mon, May 11, 2009 at 02:28:50PM +1000, Mark Ware wrote:
> Ben Dooks wrote:
>> On Wed, Apr 29, 2009 at 08:43:14AM -0500, Kumar Gala wrote:
>>> On Apr 22, 2009, at 4:56 PM, Ben Dooks wrote:
>>>
On Tue, Apr 21, 2009 at 10:11:51AM -0500, Kumar Gala wrote:
> On Apr 21, 2009, at 7:49 AM, Mark
On Mon, May 11, 2009 at 3:38 PM, David H. Lynch Jr. wrote:
> Grant Likely wrote:
>>
>> What do you mean by "one size fits all solution?"
>>
>> The kernel doesn't care where the device tree comes from. All it
>> cares about is that by the time the kernel is started the device tree
>> must be fully
On Mon, 2009-05-11 at 19:44 +0100, Alan Cox wrote:
> > Ideally the DMI subsystem should be provided wrappers for platforms
> > without DMI, rendering patches like this unnecessary.
>
> Interesting question - is the PPC OpenFirmware machine information
> mappable onto the DMI space ? or the variou
On Mon, 2009-05-11 at 17:38 -0400, David H. Lynch Jr. wrote:
> Not only is the device tree expected to pass static hardware
> configuration information, but it is the sole means of passing
> anything.
> As an example Command lines are to be in the device tree.
> Everything is supposed to be in the
> > Not pretty, but it does more or less what you're talking about. Would
> > need some work to get it going on !pseries obviously.
>
> Heh, I didn't even know this existed. :-)
>
> Thinking about this more, it seems to me that the tricky bit would be
> figuring out how to drop all references t
Grant Likely wrote:
>
> What do you mean by "one size fits all solution?"
>
> The kernel doesn't care where the device tree comes from. All it
> cares about is that by the time the kernel is started the device tree
> must be fully formed and populated. It can be completely pre-canned
> (like s
Hi Roel,
On 05/11/2009 12:34 PM, Roel Kluin wrote:
> To avoid direct access to the driver_data pointer in struct device, the
> functions dev_get_drvdata() and dev_set_drvdata() should be used.
>
> Signed-off-by: Roel Kluin
> ---
> Please review. especially note that I removed a
> kfree(dev->sbd.
Hi PPC Dev folks,
Please find a patch below that implements the proposed Hardware
Breakpoint interfaces for PPC64 architecture.
As a brief introduction, the proposed Hardware Breakpoint
infrastructure provides generic in-kernel interfaces to which users
from kernel- and user-space can requ
To avoid direct access to the driver_data pointer in struct device, the
functions dev_get_drvdata() and dev_set_drvdata() should be used.
Signed-off-by: Roel Kluin
---
diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
index fbf5c93..586965f 100644
--- a/sound/aoa/fabrics/layout
> Ideally the DMI subsystem should be provided wrappers for platforms
> without DMI, rendering patches like this unnecessary.
Interesting question - is the PPC OpenFirmware machine information
mappable onto the DMI space ? or the various static bits of name
information in the various ARM and the
To avoid direct access to the driver_data pointer in struct device, the
functions dev_get_drvdata() and dev_set_drvdata() should be used.
Signed-off-by: Roel Kluin
---
Please review. especially note that I removed a
kfree(dev->sbd.core.driver_data);
Is that correct?
arch/powerpc/include/asm/p
David Miller wrote:
> You know, for networking over loopback (one of the only real cases
> that even matters, if we get a hard interrupt then the return from
> that would process any softints), we probably make out just fine
> anyways. As long as we hit a local_bh_enable() (and in the return
> pa
Feng Kan wrote:
Signed-off-by: Feng Kan
Signed-off-by: Mark Miesfeld
---
drivers/ata/Kconfig| 10 +
drivers/ata/Makefile |1 +
drivers/ata/sata_dwc.c | 2053
3 files changed, 2064 insertions(+), 0 deletions(-)
create mode 100644 dri
On Mon, May 11, 2009 at 10:45 AM, David H. Lynch Jr. wrote:
> Grant Likely wrote:
>>
>>> We are very actively headed in the opposite direction. It is my/our
>>> intention to have a single linux executable that works accross
>>> everyone of our cards and everyone of our bitfiles.
>>>
>>
>> Th
Jiri Pirko wrote:
Fri, May 08, 2009 at 09:57:22PM CEST, da...@davemloft.net wrote:
From: Sachin Sant
Date: Fri, 08 May 2009 18:22:48 +0530
Todays Next failed to boot on a Power6 JS22 blade with following oops.
Jiri, I suspect this might be your address list changes.
Although
Timur Tabi wrote:
> On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. wrote:
>
> So all you need to do is have your boot loader create a device tree
> from scratch. If you're using U-Boot, then you can already do this by
> making the appropriate libfdt calls. Otherwise, you should probably
> a
Grant Likely wrote:
>
>>We are very actively headed in the opposite direction. It is my/our
>> intention to have a single linux executable that works accross
>>everyone of our cards and everyone of our bitfiles.
>>
>
> That is the direction we are already going in. U-Boot supports
Matthew Wilcox wrote:
On Mon, May 11, 2009 at 09:49:55PM +0530, Sachin Sant wrote:
Yeah so the problem seems to be with SLQB. I was able to boot Next 11 with
SLUB on the same machine.
Is it 100% reproducable with SLQB? Our errors were fairly hard to tickle
on demand.
Yes. I am abl
Stephen Neuendorffer wrote:
>> You *could* generate the device tree dynamically, but I think that is
>> a path of diminishing returns considering that generating a .dts at
>> the same time as bitstream creation time is cheap and it is small. At
>> one time Steven Neuendorffer was playing with a sc
On Mon, May 11, 2009 at 09:49:55PM +0530, Sachin Sant wrote:
> Yeah so the problem seems to be with SLQB. I was able to boot Next 11 with
> SLUB on the same machine.
Is it 100% reproducable with SLQB? Our errors were fairly hard to tickle
on demand.
--
Matthew Wilcox In
Matthew Wilcox wrote:
Default one. SLQB
CONFIG_SLQB_ALLOCATOR=y
CONFIG_SLQB=y
Page size is 64K with Config DEBUG_PAGEALLOC set.
CONFIG_PPC_HAS_HASH_64K=y
CONFIG_PPC_64K_PAGES=y
CONFIG_DEBUG_PAGEALLOC=y
Hm. We've seen some similar problems at Intel while doing database
performance tests
> You *could* generate the device tree dynamically, but I think that is
> a path of diminishing returns considering that generating a .dts at
> the same time as bitstream creation time is cheap and it is small. At
> one time Steven Neuendorffer was playing with a scheme to preload a
> section of
On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. wrote:
> We are very actively headed in the opposite direction. It is my/our
> intention to have a single linux executable that works accross
> everyone of our cards and everyone of our bitfiles.
This is the same direction that "we" are he
On Mon, May 11, 2009 at 12:32 AM, David H. Lynch Jr. wrote:
> But partial reconfiguration is not the only way to encounter a
> dynamic environment.
> A typical pico system has multiple bit files and multiple
> executables stored in its flash file system.
> Power up and soft resets might e
Dear All,
I am a user of oprofile. When I use oprofile, I find some problems. Could you
please help me?
I have some questions about the open source code of the implementation of
oprofile in linux
kernel 2.6.26, which is presented op_model_fsl_emb.c, and the path in linux
kernel source
tree
On Thu 2009-05-07 12:11:29, Ingo Molnar wrote:
>
> * Nicholas Miell wrote:
>
> > On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (?) wrote:
> > > On Wed, May 6, 2009 at 15:13, Ingo Molnar wrote:
> > > > doing a (per arch) bitmap of harmless syscalls and replacing the
> > > > mode1_sy
On Mon, May 11, 2009 at 05:34:07PM +0530, Sachin Sant wrote:
> Matthew Wilcox wrote:
>> On Mon, May 11, 2009 at 05:16:10PM +0530, Sachin Sant wrote:
>>
>>> Today's Next tree failed to boot on a Power6 box with following BUG :
>>
>> This doesn't actually appear to be a SCSI bug ... it looks like
Matthew Wilcox wrote:
On Mon, May 11, 2009 at 05:16:10PM +0530, Sachin Sant wrote:
Today's Next tree failed to boot on a Power6 box with following BUG :
This doesn't actually appear to be a SCSI bug ... it looks like SCSI tried
to allocate memory and things went wrong in the memory all
ops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 DEBUG_PAGEALLOC NUMA pSeries
> Modules linked in: scsi_mod(+)
> NIP: c035f5a8 LR: c035f58c CTR: 00136f8c
> REGS: c000c7d03500 TRAP: 0300 Not tainted
> (2.6.30-rc5-autotest-next-20090511)
>
_CPUS=1024 DEBUG_PAGEALLOC NUMA pSeries
Modules linked in: scsi_mod(+)
NIP: c035f5a8 LR: c035f58c CTR: 00136f8c
REGS: c000c7d03500 TRAP: 0300 Not tainted
(2.6.30-rc5-autotest-next-20090511)
MSR: 80009032 CR: 28222484 XER: 000f
DAR: 0c994838,
On Sun, 10 May 2009, Christoph Hellwig wrote:
> On Fri, May 08, 2009 at 04:01:17PM +0200, Geert Uytterhoeven wrote:
> > +/* Cell page table entries */
> > +#define IOPTE_PP_W 0x8000ul /* protection: write */
> > +#define IOPTE_PP_R 0x4000ul /* protection: rea
54 matches
Mail list logo
