Re: Re: hanging linuxthread processes
"John David Anglin" <[email protected]>
| Newsgroups | gmane.linux.ports.hppa |
|---|---|
| Message-ID | <[email protected]> |
> > http://lists.parisc-linux.org/pipermail/parisc-linux/2007-February/031385.html > > This one, definitely not ... it doesn't work ... I need to get acess to > a machine again where I can play around with it. > > > There's also the somewhat related space register issue associated with > > TLB flushing: > > > > http://lists.parisc-linux.org/pipermail/parisc-linux/2007-February/031365.html > > I think this one works OK ... but we could do with checking it > > > Randolph's change to tlbflush.h is broken and needs to be reverted > > if we don't have a better fix yet. > > I really think these problems demonstrate this new approach to patch > management is non functional. I bet even the good patch has had no > testing at all for the last two months. I've been testing both for the last two months. My impression is that the latter patch doesn't fully work. Although I was able to successfully bootstrap a SMP kernel with the patch, there were too many tlb problems for the system to be usable. The UP version of the same kernel only has the occassional problem. It sounds like I should remove the first one on the pa8800 to see if it is causing problems. I definitely miss being able to download parisc patched kernels and source for testing. However, I recognize that maintaining this tree is a lot of work. Comparing the linux and gcc development models, I have to say I think the gcc model is better. In gcc, it's possible to install bug fixes nearly all the time. In practice, the only period that is significantly restricted is the trunk stabilization period prior to the creation of a release branch. There are fewers releases, so this isn't too much of a problem. The trunk is quite unstable after a new release branch is created but that's life. Since the upstream linux merge windows are short, there's definitely a problem in tracking patches and getting a reasonable amount of testing before they go upstream. Even diffs are a problem as changes can conflict. Dave -- J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)