[Linux-Xtensa] Re: [patch 0/8] xtensa: s6000 & s6105 - Git Repo
Pulled; will try to merge early next week and get back to ya.
linux-xtensa at linux-xtensa.org
linux-xtensa at linux-xtensa.org
Sun Mar 22 11:57:56 PDT 2009
On Fri, Mar 20, 2009 at 03:19:00AM -0700, Piet Delaney wrote:
> Johannes Weiner wrote:
> >By the way, for when have you scheduled mainline integration of SMP
> >support and the new MMU code?
> I was wondering if we could push both of our changes together.
> Our new code is much more stable and easy to debug with.
> >We also have a bunch of device drivers that will soon show up on our
> >public git repository. Our goal is to get as much of them into the
> >.30 release but we'd need having our arch code adjustments in mainline
> >first so that the order of merges make sense - otherwise there would
> >be device drivers in the subtrees without any possible configurations
> >to use them.
> >Problem is, the merge window for .30 will probably open up in one to
> >two weeks and when it closes, no new features are allowed anymore and
> >we would have to wait for the next one in 6 to 8 weeks.
> We had a kernel problem earlier this week where we hung after 5 days and
> I needed to see what's going on inside the tasks. I got hung up getting
> a gdb macro working that like the Kdump 'btt' macro dumps the stacks of all
> of the kernel threads. See attachment. I think you will find it handy. I'm
> shooting for one month without any failures by the time of the SMP release
> but would like to check-in this Beta code now.
Could a watchdog have been helpful? There is a softlockup watchdog
that works with the timer interrupt. x86 also supports sysrq over the
serial console, I haven't looked into what is needed to have this on
xtensa, though. I just know that it doesn't work here. :(
Kudos on the macro, though, that thing sure looks scary ;)
> I'll be checking in tomorrow and merging with your code and the
> repository. I don't expect the merge with your changes to take long. Once
> it's merged I'll post it and you guys and Christian can check it out. If
> are no issues Christian could pull it to his linux-next repo, which is
> linked to the linux-next repo for the Xtensa arch.
> Perhaps it's more complicated than that. I think Christian, and the folks
> and over there are likely in the best position to judge the Xtensa arch
> code as
> being worthy of an upgrade. If both of us are sure that the merged
> environment is
> a significant improvement over the current code with no know downside, then
> seems reasonable to me to Christian should give it his blessing. I thought
> post notice of the change the Xtensa kernel mailing list to solicit
> I'd also really like to get into the 2.6.30-next pipe. I have a one line fix
> for the common kernel code and maybe I shouldn't include it. There a race
> in the scheduler with a division by zero. Like:
> if (p->n != 0)
> a = b / p->n
> changed to
> divisor = p->n
> if (divisor != 0)
> a = b / divisor
> Race is that p->n changes after the test but before the division. It likely
> occurs when the kernel isn't compiled with optimization.
Nice one. Please consider emailing this fix to the mailing list and
the scheduler guys (Ingo Molnar, Peter Zijlstra, ...) ASAP! If it's
really buggy, then we might want to have that in .29 as well, no?
> A few more very small Xtensa changes to common code; should effect other
'should' or 'shouldnt'?
> I'm very likely am using more cache and TLB flushes than are needed for the
> cache alias problem but they were difficult to pull out until the system is
> rock solid;
> seem to be ready for that removal but I'd like to get some testing on what
> we have now.
> I thought we'd include Xtensa macros in a new Documentation/Xtensa, like
> the attached
> ps.gdb macro and macros for dumping the TLB's and Caches.
> Sound ok to you?
Yep, sounds good.
More information about the linux-xtensa