Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS
Li Yang-R58472 writes: > Thanks for bringing [CONFIG_MPC8315_DS] up again. Looks like we do > have a problem here. My impression is that the simplest fix is Adrian's patch, which simply keys off CONFIG_MPC831x_RDB. It's not very satisfying, but I'll take "working" vs. "rare lockups at boot". If there is some other defining characteristic of boards that require this patch, then a simple KConfig snippit with a description would be even better. Without any KConfig support for this variable, I lost it even after using an oldconfig from my vendor. (Or, if it was preserved, I might have removed it when trying to optimize the kernel for support for our hardware, and I had no way of knowing that the MPC8315_DS had any impact on my system at all...) If it's actually a CPU/SOC-level problem, then an ideal situation would conditionalize the fix by examining CPU version or stepping. That would allow us to get rid of the config variable entirely. > Btw, did it help with your problem by enabling it? Possibly. :) I only saw the problem (failure to SATA handshake at 3Gbps?) very rarely, maybe one in 100 warm boot cycles. I've added the patch to my current project, and have not seen the problem since then, but until I'm problem free for another few weeks, I can't sign off on it. It certainly does look like a reasonable band-aid fix. In our case, we don't need anywhere near the higher bandwidth, so it's acceptable from that point of view. A clear statement or reference to a CPU / SOC errata would be preferred, though. It's a 4-year-old design, so even a brown paper bag bug isn't all that embarrassing anymore. :) Thanks, Tony p.s. This board also seems to suffer from occasionaly USB lockups on boot; if you end up digging through errata on 8315-based boards, please keep an eye out for that as well. Thanks! Link: http://patchwork.ozlabs.org/patch/152755/ I'm currently using that patch as well as a 10ms delay to try to avoid the hang. Successfully, so far, but a "blessed" solution from FSL would be awesome. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] signals, the first series
On Wed, May 23, 2012 at 03:14:05PM +1000, Stephen Rothwell wrote: > OK, it seem that most of this has been in Andrew's tree for a while, > sorry about that. Grr... *Another* missing prereq for task_work_add() series, this time on ppc64. Could somebody familiar with that beast take a look at this and tell if the change is sane? What we want is r0 = r3 & MSR_PR ? _TIF_NEED_RESCHED | _TIF_NOTIFY_RESUME | _TIF_SIGPENDING : _TIF_NEED_RESCHED; and when Roland re-added NOTIFY_RESUME he'd missed that hack (non-PREEMPT variant and 32bit code all just check _TIF_USER_WORK_MASK, so updating it had been enough in those cases). I don't have the hardware in question; the same instructions in userland on ppc32 box produce the right value. Unless NAKed I'm going to throw that one into the second pull request from signal.git, so if anyone has objections, please yell. I'll gladly replace that with better solution if one shows up (or, better yet, goes via ppc tree). AFAICS the diff below should work, but whether it's the best variant or not... No idea. Back to massaging VFS queue for pull... diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index ed1718f..e4fd9bb 100644 --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -563,9 +563,10 @@ _GLOBAL(ret_from_except_lite) li r0,_TIF_NEED_RESCHED/* bits to check */ ld r3,_MSR(r1) ld r4,TI_FLAGS(r9) - /* Move MSR_PR bit in r3 to _TIF_SIGPENDING position in r0 */ + /* Add MSR_PR bit in r3 in _TIF_SIGPENDING and _TIF_NOTIFY_RESUME positions in r0 */ rlwimi r0,r3,32+TIF_SIGPENDING-MSR_PR_LG,_TIF_SIGPENDING - and.r0,r4,r0/* check NEED_RESCHED and maybe SIGPENDING */ + rlwimi r0,r3,32+TIF_NOTIFY_RESUME-MSR_PR_LG,_TIF_NOTIFY_RESUME + and.r0,r4,r0/* check NEED_RESCHED and maybe SIGPENDING/NOTIFY_RESUME */ bne do_work #else /* !CONFIG_PREEMPT */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gianfar:don't add FCB length to hard_header_len
On 12-05-25 03:51 PM, Joe Perches wrote: > On Fri, 2012-05-25 at 11:58 -0400, Paul Gortmaker wrote: >> But you really shouldn't need the hardware to validate this kind of >> patch anyways -- aside from your code flow change in the irq routine of >> gianfar_ptp, you should have been simply able to check for object file >> equivalence before and after your change. > > No cross compiler either, and I'm lazy 'bout that... Can't get much easier than using one of these: http://www.kernel.org/pub/tools/crosstool/ Just untar, export PATH ARCH CROSS_COMPILE and go. Can't get much lazier than that. Great to have around. Paul. > > cheers, Joe > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gianfar:don't add FCB length to hard_header_len
On Fri, 2012-05-25 at 11:58 -0400, Paul Gortmaker wrote: > But you really shouldn't need the hardware to validate this kind of > patch anyways -- aside from your code flow change in the irq routine of > gianfar_ptp, you should have been simply able to check for object file > equivalence before and after your change. No cross compiler either, and I'm lazy 'bout that... cheers, Joe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops with Radeon/Uninorth on Maple
On Thu, May 24, 2012 at 2:18 AM, Dmitry Eremin-Solenikov wrote: > Hello, colleagues, > > I'm trying to enable an AGP slot (again) on my Maple board (dual PPC970FX > board, with CPC925 (U3H) north bridge). > > For now I'm stuck with a problem: I use radeon card, drm-radeon driver with > KMS. > > If I force drm-radeon to think about a card as about PCI card (by commenting > corresponding lines in drm_radeon_kms.c), everything works, I get > framebuffer, working X11, etc. If I enable agpgart-uninorth driver > and RADEON_IS_AGP flag in drm driver, I get an Oops early during the > bootstrap. Relevant part of the log (I can send full dmesg of normal > bootstrap or this oops on request, if that would help). For future reference, you can disable AGP by loading radeon with the agpmode parameter set to -1, e.g., radeon.agpmode=-1 No need to edit the source. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] gianfar:don't add FCB length to hard_header_len
[Re: [PATCH] gianfar:don't add FCB length to hard_header_len] On 24/05/2012
(Thu 09:16) Joe Perches wrote:
> On Thu, 2012-05-24 at 17:04 +0200, Jan Ceuleers wrote:
> > On 05/22/2012 09:18 PM, David Miller wrote:
> > > From: Jiajun Wu
> > > Date: Tue, 22 May 2012 17:00:48 +0800
> > >
> > >> FCB(Frame Control Block) isn't the part of netdev hard header.
> > >> Add FCB to hard_header_len will make GRO fail at MAC comparision stage.
> > >>
> > >> Signed-off-by: Jiajun Wu
> > >
> > > Applied, thanks.
> > >
> > > Someone needs to go through this driver when net-next opens up
> > > and fix all of the indentation in this driver.
> >
> > May I give that a go?
>
> I have scripts that automate most of this.
> I don't have the card though.
There is no card. The gianfar is a SOC for freescale 83xx, 85xx, 86xx
CPUs. If need be, I can test just as I did for your name overrun fix
in commit 0015e551e.
But you really shouldn't need the hardware to validate this kind of
patch anyways -- aside from your code flow change in the irq routine of
gianfar_ptp, you should have been simply able to check for object file
equivalence before and after your change.
Paul.
>
> Maybe this is a starting point?
> It doesn't fix most 80 column warnings.
>
> drivers/net/ethernet/freescale/gianfar.c | 299
> +++---
> drivers/net/ethernet/freescale/gianfar_ethtool.c | 131 +-
> drivers/net/ethernet/freescale/gianfar_ptp.c |8 +-
> drivers/net/ethernet/freescale/gianfar_sysfs.c |2 +-
> 4 files changed, 225 insertions(+), 215 deletions(-)
>
[...]
> diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c
> b/drivers/net/ethernet/freescale/gianfar_ptp.c
> index c08e5d4..3f7b81d 100644
> --- a/drivers/net/ethernet/freescale/gianfar_ptp.c
> +++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
> @@ -268,11 +268,11 @@ static irqreturn_t isr(int irq, void *priv)
> ptp_clock_event(etsects->clock, &event);
> }
>
> - if (ack) {
> - gfar_write(&etsects->regs->tmr_tevent, ack);
> - return IRQ_HANDLED;
> - } else
> + if (!ack)
> return IRQ_NONE;
> +
> + gfar_write(&etsects->regs->tmr_tevent, ack);
> + return IRQ_HANDLED;
> }
>
> /*
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: pread() and pwrite() system calls
On Fri, May 25, 2012 at 02:29:06PM +0100, David Laight wrote: > We have a system with linux 2.6.32 and the somewhat archaic > uClibc 0.9.27 (but I'm not sure the current version is > any better, and I think there are binary compatibility > if we update). > > I've just discovered that pread() is 'implemented' > by using 3 lseek() system calls and read(). > (the same is true for the 64bit versions). > > I thought that pread() was supposed to be atomic > (so usable concurrently by multiple threads) which > means that this implementation is completely broken. > > I've not looked to see what glibc does. > > I can see that part of the problem is the alignment > of the 64bit value on the argument list of syscall() > (when the register save area is cast to a sycall > argument structure). > But it also looks as though the uClibc syscall() > stub can only pass 5 arguments in registers, and > pread() (with an aligned 64bit offset) requires 6. > > The ucLibc source seems to be predicated by __NR_pread, > but if that were defined it would try to call > __syscall_pread() and I can't find that anywhere. > > A special pread/pwrite asm stub that just copies > r7 to r0 could be used. > > Would it be enough to do: > syscall_pread_pwrite: > mov 0,7 > sc > blr > and handle the -ve -> errno in C? Huh? Won't fly, r0 is used for the system call number! On the other hand, I believed PPC had no problems passing up to 8 32 bit arguments in registers (r3 to r10), but I may be confusing with the standard ABI for function calls. Hmm, a quick look at kernel/entry_32.s shows that it should be able to use at least r3 to r8, which should be sufficient. I think that it is an uClibc problem. Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
pread() and pwrite() system calls
We have a system with linux 2.6.32 and the somewhat archaic uClibc 0.9.27 (but I'm not sure the current version is any better, and I think there are binary compatibility if we update). I've just discovered that pread() is 'implemented' by using 3 lseek() system calls and read(). (the same is true for the 64bit versions). I thought that pread() was supposed to be atomic (so usable concurrently by multiple threads) which means that this implementation is completely broken. I've not looked to see what glibc does. I can see that part of the problem is the alignment of the 64bit value on the argument list of syscall() (when the register save area is cast to a sycall argument structure). But it also looks as though the uClibc syscall() stub can only pass 5 arguments in registers, and pread() (with an aligned 64bit offset) requires 6. The ucLibc source seems to be predicated by __NR_pread, but if that were defined it would try to call __syscall_pread() and I can't find that anywhere. A special pread/pwrite asm stub that just copies r7 to r0 could be used. Would it be enough to do: syscall_pread_pwrite: mov 0,7 sc blr and handle the -ve -> errno in C? I've seen other parts of linux pass structures to avoid issues with excessive number of arguments. Unlike things like NetBSD amd64 which will read additional args off the user stack (and has per-system call stubs in libc so doesn't lose one argument). (I rearranged the NetBSD amd64 kernel trap frame layout so all the args ended up adjacent...) David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: module loading issue/flaw in busy memory situation?
Hi, The basic question is, has the GPR r11 a dedicated function (to point to the previous stack frame) or is it still a volatile GPR, according to EABI definition ? In the case of a dedicated function was assigned, the trampoline code generation in arch/powerpc/kernel/module_32.c must be corrected. I'd suggest to use r12 instead of r11, in this case. Best Regards Steffen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
