* Re: [PATCH] [V2] net: add Xilinx emac lite device driver
From: Michal Simek @ 2009-08-20 9:28 UTC (permalink / raw)
To: David Miller
Cc: sadanan, netdev, linuxppc-dev, jgarzik, john.linn, john.williams
In-Reply-To: <20090820.022536.264747725.davem@davemloft.net>
David Miller wrote:
> From: John Linn <john.linn@xilinx.com>
> Date: Wed, 19 Aug 2009 06:29:11 -0600
>
>
>> This patch adds support for the Xilinx Ethernet Lite device. The
>> soft logic core from Xilinx is typically used on Virtex and Spartan
>> designs attached to either a PowerPC or a Microblaze processor.
>>
>> Signed-off-by: Sadanand M <sadanan@xilinx.com>
>> Signed-off-by: John Linn <john.linn@xilinx.com>
>>
>
> Looks good, applied to net-next-2.6, thanks!
>
There were one bug with spinlock which John L fixed but not send to
mainling list. :-(
He wanted to create new v3 version. :-(.
When he wake up, he send you that bug fix or v3 version with it.
Regards,
Michal
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
^ permalink raw reply
* RE: [PATCH] [V2] net: add Xilinx emac lite device driver
From: John Linn @ 2009-08-20 9:32 UTC (permalink / raw)
To: David Miller, michal.simek
Cc: Sadanand Mutyala, netdev, linuxppc-dev, jgarzik, john.williams
In-Reply-To: <20090820.023047.86718643.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, August 20, 2009 10:31 AM
> To: michal.simek@petalogix.com
> Cc: John Linn; netdev@vger.kernel.org; linuxppc-dev@ozlabs.org;
jgarzik@pobox.com;
> grant.likely@secretlab.ca; jwboyer@linux.vnet.ibm.com;
john.williams@petalogix.com; Sadanand Mutyala
> Subject: Re: [PATCH] [V2] net: add Xilinx emac lite device driver
> =
> From: Michal Simek <michal.simek@petalogix.com>
> Date: Thu, 20 Aug 2009 11:28:48 +0200
> =
> > There were one bug with spinlock which John L fixed but not send to
> > mainling list. :-(
> > He wanted to create new v3 version. :-(.
> > When he wake up, he send you that bug fix or v3 version with it.
> =
> Send a new version, I'll revert V2 from my tree as I didn't push it
> out yet.
I'll send a V3 version very soon, thanks. =
Sorry for the hassle as I thought there would be more comments and I'd
incorporate the bug fix into those.
Appreciate your help.
-- John
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH] [V2] net: add Xilinx emac lite device driver
From: David Miller @ 2009-08-20 9:30 UTC (permalink / raw)
To: michal.simek
Cc: sadanan, netdev, linuxppc-dev, jgarzik, john.linn, john.williams
In-Reply-To: <4A8D1750.4000804@petalogix.com>
From: Michal Simek <michal.simek@petalogix.com>
Date: Thu, 20 Aug 2009 11:28:48 +0200
> There were one bug with spinlock which John L fixed but not send to
> mainling list. :-(
> He wanted to create new v3 version. :-(.
> When he wake up, he send you that bug fix or v3 version with it.
Send a new version, I'll revert V2 from my tree as I didn't push it
out yet.
^ permalink raw reply
* Re: [PATCH] [V2] net: add Xilinx emac lite device driver
From: David Miller @ 2009-08-20 9:25 UTC (permalink / raw)
To: john.linn
Cc: michal.simek, netdev, sadanan, linuxppc-dev, jgarzik,
john.williams
In-Reply-To: <20090819122920.37EE21728051@mail110-dub.bigfish.com>
From: John Linn <john.linn@xilinx.com>
Date: Wed, 19 Aug 2009 06:29:11 -0600
> This patch adds support for the Xilinx Ethernet Lite device. The
> soft logic core from Xilinx is typically used on Virtex and Spartan
> designs attached to either a PowerPC or a Microblaze processor.
>
> Signed-off-by: Sadanand M <sadanan@xilinx.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Looks good, applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: Regarding TSI108 ethernet DMA issue
From: Thirumalai @ 2009-08-20 7:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <e1ca2e7b0908192115o2cfa427fof21512757854901a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]
Hi all,
I found that the header file(dma-mapping.h) has changed. I saw this change has happened on Linux -2.6.28 kernel onwards. earlier kernel is having COMFIT_PPC64 macro. Based on this macro the things were happened. Is there any fixes available right now or any reasons behind this changes.
Regards,
T.
----- Original Message -----
From: Thirumalai Pachamuthu
To: linuxppc-dev@ozlabs.org
Sent: Thursday, August 20, 2009 9:45 AM
Subject: Regarding TSI108 ethernet DMA issue
Hi all,
I am trying to port linux 2.6.30 for my TSI108 based custom board where i am getting the following kernel panic message. I found that it was due to dma allocation function call particularly dma_alloc_coherent() of tsi108_open function. When we see the implementation of dma_alloc_coherent. It was bit changed from the previous linux versions it seems.
The implementation of dma_alloc_coherent was kept on the arch/powerpc/include/asm/dma-mapping.h file. Earlier implementation is not considering the first parameter what the tsi108 driver is passing as NULL. But the current implementation is considering this parameter and because of this the panic is coming what i believe.
So kindly let me know any patches for this problem or any fixes.
Regards,
T.
------------------------------------------------------------------------------
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 2763 bytes --]
^ permalink raw reply
* Re: [PATCH] Add kmemleak annotations to lmb.c
From: Michael Ellerman @ 2009-08-20 6:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Miller, linuxppc-dev
In-Reply-To: <1250287071.5085.2.camel@pc1117.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]
On Fri, 2009-08-14 at 22:57 +0100, Catalin Marinas wrote:
> On Fri, 2009-08-14 at 12:49 -0700, David Miller wrote:
> > From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Date: Fri, 14 Aug 2009 17:56:40 +1000
> >
> > > On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
> > >> On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
> > >> > We don't actually want kmemleak to track the lmb allocations, so we
> > >> > pass min_count as 0. However telling kmemleak about lmb allocations
> > >> > allows it to scan that memory for pointers to other memory that is
> > >> > tracked by kmemleak, ie. slab allocations etc.
> > >>
> > >> Looks alright to me (though I haven't tested it). You can add a
> > >> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> > >
> > > Actually, Milton pointed to me that we may not want to allow all
> > > LMB chunks to be scanned by kmemleaks, things like the DART hole
> > > that's taken out of the linear mapping for example may need to
> > > be avoided, though I'm not sure what would be the right way to
> > > do it.
> >
> > I think that annotating LMB for kmemleak may be more problems
> > that it's worth.
>
> BTW, are there many LMB allocations used for storing pointers to other
> objects? If not, it may be worth just annotating those with
> kmemleak_alloc() if you get false positives.
Yeah I think that's probably the safer approach. As Dave says even if
there's nothing obvious, lmb is used for very early allocs which are
more likely to be "special" and cause problems - and only when someone
boots with kmemleak enabled. So we're better to explicitly mark things
we want scanned.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [U-Boot] NAND ECC Error with wrong SMC ording bug
From: Stefan Roese @ 2009-08-20 5:01 UTC (permalink / raw)
To: u-boot; +Cc: linuxppc-dev, Feng Kan, linux-mtd, Sean MacLennan
In-Reply-To: <20090820003851.1a532444@lappy.seanm.ca>
On Thursday 20 August 2009 06:38:51 Sean MacLennan wrote:
> > I see other boards using SMC as well, can someone comment on the
> > change I am proposing.
> > Should I change the correction algorithm or the calculate function?
> > If the later is preferred
> > it would mean the change must be pushed in both U-Boot and Linux.
>
> Odds are the calculate function is wrong. The correction algo is used
> by many nand drivers, I *assume* it is correct. The calculate function
> was set to agree with u-boot (1.3.0).
Yes, it seems that you changed the order in the calculation function while
reworking the NDFC driver for arch/powerpc. So we should probably change this
order back to the original version. And change it in U-Boot as well.
BTW: I didn't see any problems with ECC so far with the current code. Feng,
how did you spot this problem?
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* powerpc-next rebased (again)
From: Benjamin Herrenschmidt @ 2009-08-20 4:40 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: linuxppc-dev list, Kumar Gala
In-Reply-To: <4177854C-965A-4A26-A517-B6F0B48703BD@kernel.crashing.org>
Ok so due to screwup mentioned earlier, it's rebased agian :-(
Hopefully that's the last time for very looooooong...
While at it, I removed the lmb kmemleak patch from Michael since
we decided it wasn't a good idea and added Kumar's fix for
assert_pte_locked().
I also updated the test branch with more stuff such as Fujita
IOMMU bits and pieces.
Cheers,
Ben.
^ permalink raw reply
* Re: NAND ECC Error with wrong SMC ording bug
From: Sean MacLennan @ 2009-08-20 4:38 UTC (permalink / raw)
To: Feng Kan; +Cc: linuxppc-dev, linux-mtd, u-boot
In-Reply-To: <4A8C87E6.6070702@amcc.com>
On Wed, 19 Aug 2009 16:16:54 -0700
Feng Kan <fkan@amcc.com> wrote:
> I see other boards using SMC as well, can someone comment on the
> change I am proposing.
> Should I change the correction algorithm or the calculate function?
> If the later is preferred
> it would mean the change must be pushed in both U-Boot and Linux.
Odds are the calculate function is wrong. The correction algo is used
by many nand drivers, I *assume* it is correct. The calculate function
was set to agree with u-boot (1.3.0).
Cheers,
Sean
P.S. Yes, I know the u-boot is an ancient version :(
^ permalink raw reply
* Regarding TSI108 ethernet DMA issue
From: Thirumalai Pachamuthu @ 2009-08-20 4:18 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <e1ca2e7b0908192115o2cfa427fof21512757854901a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2147 bytes --]
Hi all,
I am trying to port linux 2.6.30 for my TSI108 based custom board
where i am getting the following kernel panic message. I found that it was
due to dma allocation function call particularly dma_alloc_coherent() of
tsi108_open function. When we see the implementation of dma_alloc_coherent.
It was bit changed from the previous linux versions it seems.
The implementation of dma_alloc_coherent was kept on the
arch/powerpc/include/asm/dma-mapping.h file. Earlier implementation is not
considering the first parameter what the tsi108 driver is passing as NULL.
But the current implementation is considering this parameter and because of
this the panic is coming what i believe.
So kindly let me know any patches for this problem or any fixes.
------------[ cut here ]------------
Kernel BUG at c019074c [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
DPVME0447
NIP: c019074c LR: c019074c CTR: c014ea48
REGS: df82bd80 TRAP: 0700 Not tainted (2.6.30)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24000022 XER: 20000000
TASK = df82c000[1] 'swapper' THREAD: df82a000
GPR00: c019074c df82be30 df82c000 00000030 000013e0 ffffffff c014e998
00000035
GPR08: c02f2af0 c02e7bb8 000013e0 c02cd8f4 24000042 00000000 00000002
00000000
GPR16: c02c0000 00000000 00000000 00000000 00000000 0ffaa41c c0300000
00000004
GPR24: 00000000 00000000 c02f0000 c02f0000 df821030 00000000 df821000
df821300
NIP [c019074c] tsi108_open+0x5c/0x90
LR [c019074c] tsi108_open+0x5c/0x90
Call Trace:
[df82be30] [c019074c] tsi108_open+0x5c/0x90 (unreliable)
[df82be50] [c01b1564] dev_open+0xac/0x11c
[df82be70] [c01b1464] dev_change_flags+0x160/0x1b4
[df82be90] [c02bc5f8] ip_auto_config+0x18c/0xe5c
[df82bf50] [c0003c8c] do_one_initcall+0x34/0x1a8
[df82bfd0] [c02a1848] kernel_init+0x9c/0x100
[df82bff0] [c0012064] kernel_thread+0x4c/0x68
Instruction dump:
807f003c 7fc8f378 4beb8d71 7c7d1b79 40820028 80bf003c 3c60c029 7fc6f378
386327c0 90be0028 809f0040 4be90669 <0fe00000> 48000000 80bf003c 3c60c029
---[ end trace dc633a1da0ecdafb ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
Regards,
T.
[-- Attachment #2: Type: text/html, Size: 2429 bytes --]
^ permalink raw reply
* Regarding TSI108 ethernet DMA issue
From: Thirumalai Pachamuthu @ 2009-08-20 4:15 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
Hi all,
I am trying to port linux 2.6.30 for my TSI108 based custom board
where i am getting the following kernel panic message. I found that it was
due to dma allocation function call particularly dma_alloc_coherent() of
tsi108_open function. When we see the implementation of dma_alloc_coherent.
It was bit changed from the previous linux versions it seems.
The implementation of dma_alloc_coherent was kept on the
arch/powerpc/include/asm/dma-mapping.h file. Earlier implementation is not
considering the first parameter what the tsi108 driver is passing as NULL.
But the current implementation is considering this parameter and because of
this the panic is coming what i believe.
So kindly let me know any patches for this problem or any fixes.
Regards,
T.
[-- Attachment #2: Type: text/html, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] agp/uninorth: Unify U3 and pre-U3 insert_memory and remove_memory hooks.
From: Benjamin Herrenschmidt @ 2009-08-20 0:47 UTC (permalink / raw)
To: Michel Dänzer; +Cc: Dave Airlie, linuxppc-dev
In-Reply-To: <1250151313.4992.202.camel@thor>
On Thu, 2009-08-13 at 10:15 +0200, Michel Dänzer wrote:
> On Thu, 2009-08-13 at 17:05 +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2009-08-04 at 23:51 +0200, Michel Dänzer wrote:
> > > From: Michel Dänzer <daenzer@vmware.com>
> > >
> > > Signed-off-by: Michel Dänzer <daenzer@vmware.com>
> > > ---
> >
> > Hi Michel !
> >
> > While your two previous patches apply just fine, this one doesn't,
> > the uninorth_insert_memory() function seems to be slightly different
> > upstream. Does this depend on some separate yet unapplied patches ?
>
> I previously sent the attached patches to Dave in the course of the
> radeon KMS issues thread. Not sure which of these he's picked up yet, if
> any.
I merged the first two patches in your series, we can sort out the 3rd
one in a second pass on the merge window.
Cheers,
Ben.
>
> > I'm putting 1/3 and 2/3 into my -test branch and they should hit my
> > -next branch in a couple of days.
> >
> > Or do you prefer us to merge that via Dave ?
> >
> > The thing is, stuff in -powerpc is much more likely to get some amount
> > of testing on actual ppc hardware than stuff in random other trees :-)
>
> I'm fine with either way.
>
>
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/mm: Add MMU features for TLB reservation & Paired MAS registers
From: Benjamin Herrenschmidt @ 2009-08-20 0:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <AC207041-6DB9-476E-B171-C1F6E10D3FAB@kernel.crashing.org>
On Wed, 2009-08-19 at 16:37 -0500, Kumar Gala wrote:
> On Aug 19, 2009, at 2:25 AM, Benjamin Herrenschmidt wrote:
> The whole thing only ever gets called if we had tlbsrx. so is there
> any utility in making a part of conditional on tlbsrx?
I don't think so ... this is the second level TLB miss handler when
the first level takes a hit on the virtually linear page tables, I
has nothing to do with tlbsrx... however, it does offset the return
address back into the first level handler by -4 to account for
replaying the tlbsrx instruction which you probably don't want to do.
Ben.
^ permalink raw reply
* NAND ECC Error with wrong SMC ording bug
From: Feng Kan @ 2009-08-19 23:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: u-boot, linux-mtd
In-Reply-To: <1250569482.19007.23.camel@pasglop>
Hi All:
It seems that the ECC correction is broken on the Linux with the 4xx
NDFC driver.
It uses the SMC order when reading the ECC code. 2-1-3
static int ndfc_calculate_ecc(struct mtd_info *mtd,
const u_char *dat, u_char *ecc_code)
{
struct ndfc_controller *ndfc = &ndfc_ctrl;
uint32_t ecc;
uint8_t *p = (uint8_t *)&ecc;
wmb();
ecc = in_be32(ndfc->ndfcbase + NDFC_ECC);
/* The NDFC uses Smart Media (SMC) bytes order */
ecc_code[0] = p[2];
ecc_code[1] = p[1];
ecc_code[2] = p[3];
return 0;
}
However, when in the correction function, the byte address order is
again reverses
causing incorrect byte location.
* performace it does not make any difference
*/
if (eccsize_mult == 1)
byte_addr = (addressbits[b0] << 4) +
addressbits[b1];
>>>> The above really should be byte_addr = (addressbits[b1] << 4) +
addressbits[b0];
else
byte_addr = (addressbits[b2 & 0x3] << 8) +
(addressbits[b1] << 4) +
addressbits[b0];
bit_addr = addressbits[b2 >> 2];
/* flip the bit */
buf[byte_addr] ^= (1 << bit_addr);
printk(KERN_INFO "Corrected b[0] 0x%x b[1]0x%x\n", b0, b1);
printk(KERN_INFO "cal ecc b[0] 0x%x b[1]0x%x\n",
calc_ecc[0] , calc_ecc[1]);
printk(KERN_INFO "read ecc b[0] 0x%x b[1]0x%x\n",
read_ecc[0] , read_ecc[1]);
return 1;
I see other boards using SMC as well, can someone comment on the change
I am proposing.
Should I change the correction algorithm or the calculate function? If
the later is preferred
it would mean the change must be pushed in both U-Boot and Linux.
Feng Kan
AMCC Software
^ permalink raw reply
* Re: [PATCH/RFC] powerpc/mm: Cleanup handling of execute permission
From: Benjamin Herrenschmidt @ 2009-08-19 22:17 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev list, Kumar Gala
In-Reply-To: <16251558-DDF6-46C3-98C2-2FC7CD8A398B@kernel.crashing.org>
On Wed, 2009-08-19 at 15:59 -0500, Becky Bruce wrote:
> On Aug 18, 2009, at 5:33 PM, Benjamin Herrenschmidt wrote:
>
> >
> FYI, I pulled your updated test branch this morning, booted, and did a
> full LTP run on 8572. The results are consistent with the baseline I
> have, so it looks like the issue is properly fixed.
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Re: powerpc-next rebased
From: Benjamin Herrenschmidt @ 2009-08-19 21:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <2E8B90A3-A3FD-4EC8-9D41-1BA9E8B261AB@kernel.crashing.org>
On Wed, 2009-08-19 at 08:43 -0500, Kumar Gala wrote:
>
> You screwed it up... :)
>
> The commits you pulled in from me you seem to have changed the
> author
> of the commits which is NOT cool at all. Adding signed-off-by is
> good, changing the committer is ok, but changing the author of the
> commit is not. Please fix this ASAP.
Strange. I just rebased and ammended them, I didn't think that would
change the author :-( I'll try to figure out what went wrong and will
fix it up.
Cheers,
Ben.
> Here's an example (in your tree):
>
> http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;h=87f1e94c949c28fdaa079d5115a8010c9a40569d
>
> vs the commit in my tree:
>
> http://git.kernel.org/?p=linux/kernel/git/galak/powerpc.git;a=commit;h=d920991f7e02788ba2b468b3023e5bbbc7a32f30
^ permalink raw reply
* Re: [PATCH 1/5] powerpc/mm: Add MMU features for TLB reservation & Paired MAS registers
From: Kumar Gala @ 2009-08-19 21:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1250666756.4810.16.camel@pasglop>
On Aug 19, 2009, at 2:25 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-19 at 00:08 -0500, Kumar Gala wrote:
>> Support for TLB reservation (or TLB Write Conditional) and Paired MAS
>> registers are optional for a processor implementation so we handle
>> them via MMU feature sections.
>>
>> We currently only used paired MAS registers to access the full RPN
>> + perm
>> bits that are kept in MAS7||MAS3. We assume that if an
>> implementation has
>> hardware page table at this time it also implements in TLB
>> reservations.
>
> You also need to be careful with this code:
>
> virt_page_table_tlb_miss_done:
>
> /* We have overriden MAS2:EPN but currently our primary TLB miss
> * handler will always restore it so that should not be an issue,
> * if we ever optimize the primary handler to not write MAS2 on
> * some cases, we'll have to restore MAS2:EPN here based on the
> * original fault's DEAR. If we do that we have to modify the
> * ITLB miss handler to also store SRR0 in the exception frame
> * as DEAR.
> *
> * However, one nasty thing we did is we cleared the reservation
> * (well, potentially we did). We do a trick here thus if we
> * are not a level 0 exception (we interrupted the TLB miss) we
> * offset the return address by -4 in order to replay the tlbsrx
> * instruction there
> */
> subf r10,r13,r12
> cmpldi cr0,r10,PACA_EXTLB+EX_TLB_SIZE
> bne- 1f
> ld r11,PACA_EXTLB+EX_TLB_SIZE+EX_TLB_SRR0(r13)
> addi r10,r11,-4
> std r10,PACA_EXTLB+EX_TLB_SIZE+EX_TLB_SRR0(r13)
>
> You may want to make the 3 last lines conditional on having tlbsrx.
The whole thing only ever gets called if we had tlbsrx. so is there
any utility in making a part of conditional on tlbsrx?
> Right now, in the no-tlbsrx. case, what happens is that it will go
> back
> to the previous instruction, an or, which hopefully should be harmless
> -but- this code is nasty enough you really don't want to take that
> sort of chances.
>
> Feel free to add a fat comment next to the ld in the tlbsrx case
> itself
> explaining why those two instructions must be kept together and any
> change here must be reflected in the second level handler.
>
> Cheers,
> Ben.
>
^ permalink raw reply
* Re: [PATCH/RFC] powerpc/mm: Cleanup handling of execute permission
From: Becky Bruce @ 2009-08-19 20:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Kumar Gala
In-Reply-To: <1250634800.4810.1.camel@pasglop>
On Aug 18, 2009, at 5:33 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2009-08-18 at 16:56 -0400, Josh Boyer wrote:
>> On Fri, Aug 14, 2009 at 05:39:42PM -0500, Becky Bruce wrote:
>>> Ben,
>>>
>>> This breaks the boot on 8572. I don't know why yet (and I'm
>>> probably
>>> not going to figure it out before I go home, because, frankly,
>>> it's late
>>> on a Friday afternoon and I need a glass of wine or, perhaps, a
>>> beer).
>>>
>>> Kumar and I will poke into this more and let you know what we find
>>> out -
>>> in the meantime, if you have any brilliant flashes, pony up!
>>
>> I tested this on a 440EPx NFS rootfs boot too. It doesn't cause
>> init itself
>> to crap out with a SIGILL like Becky's board, but it does do weird
>> things
>> and cause a SIGILL elsewhere during my boot.
>>
>> Reverting this patch from your testing branch allows things to work
>> just fine.
>
> Becky found my thinko, I'll send a new patch later today.
Ben,
FYI, I pulled your updated test branch this morning, booted, and did a
full LTP run on 8572. The results are consistent with the baseline I
have, so it looks like the issue is properly fixed.
-Becky
^ permalink raw reply
* Re: [PATCH] spinlock: __raw_spin_is_locked() should return true for UP
From: Scott Wood @ 2009-08-19 18:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: peterz, linux-kernel, Steven Rostedt, linuxppc-dev, mingo, tglx
In-Reply-To: <alpine.LFD.2.01.0908181640120.3158@localhost.localdomain>
On Tue, Aug 18, 2009 at 04:52:20PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 18 Aug 2009, Steven Rostedt wrote:
> >
> > > The thing is, some people may assert that a lock is held, but others could
> > > easily be looping until it's not held using something like
> > >
> > > while (spin_is_locked(lock))
> > > cpu_relax();
> >
> > Wouldn't something like that be really racey? And anyone doing such a
> > thing had better have that code within an #ifdef CONFIG_SMP.
>
> Sure, it's hopefully inside a #ifdef CONFIG_SMP.
>
> And no, it's not necessarily racy. Sure, it's race in itself if that's all
> you are doing, but I could imagine writing that kind of code if I knew
> some lock was likely held, and I wanted to avoid doing a "try_lock()"
> until it got released.
So you'd basically have the effect of a spin_lock(), except with the
bonus of breaking RT hacks that do something other than spin, and
preventing arch code from doing certain types of relaxation that are only
appropriate when waiting on a lock (such as mdors on powerpc, which
de-emphasizes until a reservation is broken).
Not exactly something we should encourage, IMHO.
-Scott
^ permalink raw reply
* Re: Linux booting problem on powerpc 440
From: Josh Boyer @ 2009-08-19 17:35 UTC (permalink / raw)
To: Sumesh Kaana; +Cc: linuxppc-dev
In-Reply-To: <BLU124-W26979C48CA968E784AEA0CB4FE0@phx.gbl>
On Wed, Aug 19, 2009 at 01:01:16PM +0000, Sumesh Kaana wrote:
>
>
>
>Hi all,
>I am trying to boot linux kernel (2.6.30) on a custom built board.I am using simple ppc platform and attached are my dts file and boot log..
>I've 16Mb of RAM,UART and UIC with powerpc 440x5 processor.Kernel Image size is less than 1 mb.
>i am not using any bootloaders such as U-boot
>i have a small program on reset vector which will copy linux bin image from flash to 4mb (Link Address as per wrapper script), after that execution starts from link address.
How large of an initial TLB are you setting up for all of this in your simple
bootloader?
>the problem that i face is kernel crashes in different places while booting for different linux images, but always mentioned that
>TASK = 'swapper'
>
>Can anyone tell what would be the problem..?
I won't quote the file itself since your email is terribly word-wrapped, but
the #address-cells = <1> in the root node looks incorrect for a 440 based CPU.
It should be 2, as 440 does 36-bit addressing. Similarly for the PLB node.
You would need to fix the memory reg property for this.
The CPU node should probably have #size-cells = <0>, though I don't think that
matters much.
The serial port appears to be at an odd address for a 440 based SoC, but I
have no idea if that is correct or not.
Outside of those issues, I can't think of anything off the top of my head that
would cause the panic you are seeing.
josh
^ permalink raw reply
* Re: powerpc-next rebased
From: Kumar Gala @ 2009-08-19 14:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <5CBF10F7-8927-47AD-B4F8-1F07754207A8@kernel.crashing.org>
On Aug 19, 2009, at 8:54 AM, Kumar Gala wrote:
>
> On Aug 19, 2009, at 8:43 AM, Kumar Gala wrote:
>
>>
>> On Aug 19, 2009, at 2:33 AM, Benjamin Herrenschmidt wrote:
>>
>>> Allright it's done, let's hope I didn't screw up :-)
>>
>> You screwed it up... :)
>>
>> The commits you pulled in from me you seem to have changed the
>> author of the commits which is NOT cool at all. Adding signed-off-
>> by is good, changing the committer is ok, but changing the author
>> of the commit is not. Please fix this ASAP.
>>
>> Here's an example (in your tree):
>>
>> http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;h=87f1e94c949c28fdaa079d5115a8010c9a40569d
>>
>> vs the commit in my tree:
>>
>> http://git.kernel.org/?p=linux/kernel/git/galak/powerpc.git;a=commit;h=d920991f7e02788ba2b468b3023e5bbbc7a32f30
>
> I'll leave my tree alone to allow you to try and fix this. It looks
> like the stuff you pulled in from Josh's tree also has similar foobar.
>
> - k
To be nice I published a 'fix-author' branch on my kernel.org tree
that should be identical to your tree up to:
commit b045513a1d657178868a1b1c5c2c56b7ef67766d
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Tue Aug 18 15:21:40 2009 +0000
powerpc/mm: Fix assert_pte_locked to work properly on uniprocessor
Since the pte_lockptr is a spinlock it gets optimized away on
uniprocessor builds so using spin_is_locked is not correct. We
can use
assert_spin_locked instead and get the proper behavior between UP
and
SMP builds.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
I doesn't have any Signed-off-by from you for the commits from Josh or
I. Otherwise the Author's have been fixed.
- k
^ permalink raw reply
* [PATCH v2] powerpc: Fix __flush_icache_range on 44x
From: Josh Boyer @ 2009-08-19 14:27 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
The ptrace POKETEXT interface allows a process to modify the text pages of
a child process being ptraced, usually to insert breakpoints via trap
instructions. The kernel eventually calls copy_to_user_page, which in turn
calls __flush_icache_range to invalidate the icache lines for the child
process.
However, this function does not work on 44x due to the icache being virtually
indexed. This was noticed by a breakpoint being triggered after it had been
cleared by ltrace on a 440EPx board. The convenient solution is to do a
flash invalidate of the icache in the __flush_icache_range function.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
I tested this on powerpc-next this morning using the same testcase as before.
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 15f28e0..da9c0c4 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -342,10 +342,17 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
addi r3,r3,L1_CACHE_BYTES
bdnz 1b
sync /* wait for dcbst's to get to ram */
+#ifndef CONFIG_44x
mtctr r4
2: icbi 0,r6
addi r6,r6,L1_CACHE_BYTES
bdnz 2b
+#else
+ /* Flash invalidate on 44x because we are passed kmapped addresses and
+ this doesn't work for userspace pages due to the virtually tagged
+ icache. Sigh. */
+ iccci 0, r0
+#endif
sync /* additional sync needed on g4 */
isync
blr
^ permalink raw reply related
* OF modalias
From: Wolfgang Grandegger @ 2009-08-19 14:15 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm confused by the modalias'es created by OF devices, e.g.:
# cat /sys/devices/f0000000.soc5200/f0000f00.spi/modalias
of:NspiT<NULL>Cfsl,mpc5200b-spiCfsl,mpc5200-spi
First of all, the string "<NULL>" looks like an error.
I could then dynamically load a driver module for the SPI using:
# modprobe `cat sys/devices/f0000000.soc5200/f0000f00.spi/modalias`
This does make sense for the SPI device, but there are OF devices which
cannot really be used by a module driver, e.g.:
# cat /sys/devices/f0000000.soc5200/f0000500.interrupt-controller/modalias
of:Ninterrupt-controllerT<NULL>Cfsl,mpc5200b-picCfsl,mpc5200-pic
The same for localbus, cdm, etc. Does it make sense for these
to create a modalias file?
Likely I have missed something. Thanks for clarification.
Wolfgang.
^ permalink raw reply
* Re: powerpc-next rebased
From: Kumar Gala @ 2009-08-19 13:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <2E8B90A3-A3FD-4EC8-9D41-1BA9E8B261AB@kernel.crashing.org>
On Aug 19, 2009, at 8:43 AM, Kumar Gala wrote:
>
> On Aug 19, 2009, at 2:33 AM, Benjamin Herrenschmidt wrote:
>
>> Allright it's done, let's hope I didn't screw up :-)
>
> You screwed it up... :)
>
> The commits you pulled in from me you seem to have changed the
> author of the commits which is NOT cool at all. Adding signed-off-
> by is good, changing the committer is ok, but changing the author of
> the commit is not. Please fix this ASAP.
>
> Here's an example (in your tree):
>
> http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;h=87f1e94c949c28fdaa079d5115a8010c9a40569d
>
> vs the commit in my tree:
>
> http://git.kernel.org/?p=linux/kernel/git/galak/powerpc.git;a=commit;h=d920991f7e02788ba2b468b3023e5bbbc7a32f30
I'll leave my tree alone to allow you to try and fix this. It looks
like the stuff you pulled in from Josh's tree also has similar foobar.
- k
^ permalink raw reply
* Re: powerpc-next rebased
From: Kumar Gala @ 2009-08-19 13:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1250667232.4810.20.camel@pasglop>
On Aug 19, 2009, at 2:33 AM, Benjamin Herrenschmidt wrote:
> Allright it's done, let's hope I didn't screw up :-)
You screwed it up... :)
The commits you pulled in from me you seem to have changed the author
of the commits which is NOT cool at all. Adding signed-off-by is
good, changing the committer is ok, but changing the author of the
commit is not. Please fix this ASAP.
Here's an example (in your tree):
http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=commitdiff;h=87f1e94c949c28fdaa079d5115a8010c9a40569d
vs the commit in my tree:
http://git.kernel.org/?p=linux/kernel/git/galak/powerpc.git;a=commit;h=d920991f7e02788ba2b468b3023e5bbbc7a32f30
- k
^ 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