Re: HPPA and Squeeze

Re: HPPA and Squeeze

[Grant Grundler]

+linux-parisc (hppa kernel, compiler and !debian tech forum)

Neil,
thanks for the summary. I know this is an unpleasant business in general.

On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
> Hi,
> 
> As mentioned previously[0], the release team haven't been happy with the
> state of the HPPA port in Debian. After the release team meeting[1], it
> has been decided that unfortunatly HPPA will not be supported for
> Squeeze. This was after careful consideration, and wasn't an easy
> decision.
> 
> This means that ftpmasters will be asked to remove HPPA from testing and
> unstable from the 30th June. It is suggested that HPPA porters may wish
> to consider using debian-ports.org if they wish to continue with the
> port.
> 
> Regards,
> Neil McGovern
> 
> [0] http://lists.debian.org/debian-release/2009/04/msg00299.html

Carlos O'Donnell asked some questions in response to [0] and I never
saw any response.  Can an attendee of the above meeting please reply
this email from Carlos?
    http://lists.debian.org/debian-release/2009/04/msg00303.html

I also never got a response to my offer here:
    http://lists.debian.org/debian-release/2009/04/msg00339.html


And my response again to this question posted in [0]:
> * The machines that host the buildds still seem to have a very
> unreliable kernel. Is there any update on this?

Quite a few serious hppa specific bugs have been fixed upstream over
the past 6 months. This is worth revisiting.

Is upstream stable enough for a buildd?  I don't know since I'm not aware
of any attempts to run a buildd with those kernels.

Is the answer to that question still germane?
If so, I'm willing to setup a local buildd and try it. But I will need
more time and some commitment that if it works, hppa remain in testing
release (that's all I personally care about - I don't care about "stable"
releases.)


> [1] http://lists.debian.org/debian-project/2009/05/msg00080.html

Can we have the minutes for this meeting?

Also, I'd like to ask HPPA debs be kept in "testing" staging area,
just never promoted when the release is cut.  This will let people
continue using HPPA without having to suffer with the !hppa breakage
that lives in unstable.

thanks,
grant

Re: HPPA and Squeeze

[Neil McGovern]

Firstly, thanks for your mail, apologies that I haven't replied sooner,
we've had EU and local elections, so I've been busy runnign around with
leaflets, knocking on doors, kissing babies etc. like any politician. No
expenses though...

On Sat, Jun 06, 2009 at 12:36:01PM -0600, Grant Grundler wrote:
> Carlos O'Donnell asked some questions in response to [0] and I never
> saw any response.  Can an attendee of the above meeting please reply
> this email from Carlos?
>     http://lists.debian.org/debian-release/2009/04/msg00303.html
> 

I'm not sure what replies you'd like... there's certainly been some
follow ups to that mail.

> I also never got a response to my offer here:
>     http://lists.debian.org/debian-release/2009/04/msg00339.html
> 

Indeed, and that's worrying. I would have expected a HPPA porter (if
indeed one still exists) to have replied to that.

> Quite a few serious hppa specific bugs have been fixed upstream over
> the past 6 months. This is worth revisiting.
> 
> Is upstream stable enough for a buildd?  I don't know since I'm not aware
> of any attempts to run a buildd with those kernels.
> 

Neither do we, we're not HPPA porters :)
We did go through this before with newer kernels, and it didn't help
FWIW.

> Is the answer to that question still germane?

Ish. We still have the issue that you can't actually buy HPPAs any more,
and various bits and pieces from the Arch Requalification list.

[change of order by me below]
> Also, I'd like to ask HPPA debs be kept in "testing" staging area,
> just never promoted when the release is cut.  This will let people
> continue using HPPA without having to suffer with the !hppa breakage
> that lives in unstable. 

> (that's all I personally care about - I don't care about "stable"
> releases.)

This is one of the major problems for the port. Testing exists to create
the next stable release. Essentially, testing *is* the next stable,
except that it's a little volatile for a number of months... :)

> Can we have the minutes for this meeting?

I'm afraid they're not publicly available, but I will be posting a
mail to d-d-a real-soon-now(tm), apologies for the delays in this, it
was a rather full meeting.

Hope this helps,
Neil
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li A40F862E

Re: HPPA and Squeeze

[Thibaut VARENE]

On Mon, Jun 8, 2009 at 11:26 PM, Neil McGovern<maulkin@halon.org.uk> wrote:
> On Sat, Jun 06, 2009 at 12:36:01PM -0600, Grant Grundler wrote:
>> Is the answer to that question still germane?
>
> Ish. We still have the issue that you can't actually buy HPPAs any more,

When did "being a marketed platform" become a criteria for inclusion?
Is Debian the new Ubuntu? :-P

> I'm afraid they're not publicly available, but I will be posting a
> mail to d-d-a real-soon-now(tm), apologies for the delays in this, it
> was a rather full meeting.

Failing this, could we please have a detailed rationale for the
decision? I already posted a reply to this thread asking for this,
which seems to have been ignored. Of course I understand you were busy
with EU elections, still, any kind of "ACK" would be nice.

Thanks,
T-Bone


-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/

Re: HPPA and Squeeze

[Neil McGovern]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

On Tue, Jun 09, 2009 at 01:44:27AM +0200, Thibaut VARENE wrote:
> > Ish. We still have the issue that you can't actually buy HPPAs any more,
> 
> When did "being a marketed platform" become a criteria for inclusion?
> Is Debian the new Ubuntu? :-P
> 

Well, back in 2005...
http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html

However, I didn't mean it as a 'you must be able to get these from HP'.
You can't find them on ebay (for the three days I looked), and this
would indicate that it's unlikely that there's going to be sufficient
new porters to make this work.

> Failing this, could we please have a detailed rationale for the
> decision?

It'll be in the d-d-a post, or linked from the post :)

Hope this helps,
Neil
-- 
< linuxpoet> rails is a perversion
< mc> someone who use pgsql as calculator shouldnt talk of perversion.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: HPPA and Squeeze

[Thomas Bogendoerfer]

On Tue, Jun 09, 2009 at 10:29:54AM +0100, Neil McGovern wrote:
> However, I didn't mean it as a 'you must be able to get these from HP'.
> You can't find them on ebay (for the three days I looked), and this
> would indicate that it's unlikely that there's going to be sufficient
> new porters to make this work.

your ebay is broken.

A simple search for C3750 (an quite fast parisc workstation) on ebay.de
gives me four hits for complete systems. And there are other workstations
and servers on ebay.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: HPPA and Squeeze

[Aioanei Rares]

Neil McGovern wrote:
> On Tue, Jun 09, 2009 at 01:44:27AM +0200, Thibaut VARENE wrote:
>   
>>> Ish. We still have the issue that you can't actually buy HPPAs any more,
>>>       
>> When did "being a marketed platform" become a criteria for inclusion?
>> Is Debian the new Ubuntu? :-P
>>
>>     
>
> Well, back in 2005...
> http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
>
> However, I didn't mean it as a 'you must be able to get these from HP'.
> You can't find them on ebay (for the three days I looked), and this
> would indicate that it's unlikely that there's going to be sufficient
> new porters to make this work.
>
>   

www.gall.de and some more others
>> Failing this, could we please have a detailed rationale for the
>> decision?
>>     
>
> It'll be in the d-d-a post, or linked from the post :)
>
> Hope this helps,
> Neil
>   

Re: HPPA and Squeeze

[John David Anglin]

> > Well, back in 2005...
> > http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
> >
> > However, I didn't mean it as a 'you must be able to get these from HP'.
> > You can't find them on ebay (for the three days I looked), and this
> > would indicate that it's unlikely that there's going to be sufficient
> > new porters to make this work.
> >
> >   
> 
> www.gall.de and some more others

And in the US,
http://www.cypress-tech.com/
http://www.more-computers.com/

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Helge Deller]

Hi Sune, all,

Sune Vuorela wrote:
> On 2009-06-08, Thibaut VARENE <varenet@debian.org> wrote:
>> Failing this, could we please have a detailed rationale for the
>> decision?
> 
> I'm not in any way involved with the decision, but I support it.
> 
> I have in the past had some issues with some of the packages I
> (co)-maintain in debian on hppa, and I have in the past spent much more
> time on those packages on hppa than its userbase deserve. And I'm not a
> hppa porter.

Yes, there have been issues.

> I personally don't mind that we in debian supports many architectures,
> but it should mainly be the porters who are responsible for fixing
> architecture weirdnesses, not the package maintainers.

Sure.
 
> I have really missed this from the hppa porters. It might be that hppa
> porters don't care for Qt on hppa. It might be that hppa porters don't
> care for KDE on hppa. 

I think that's not fair.
I'm a big KDE and Qt fan and when you reported the issues, I stepped in.

You had problems with the locking functions in Qt. I did sent you
fixes for that to fix it in the qt code base.
This was one of the threads:  http://www.mail-archive.com/debian-hppa@lists.debian.org/msg05888.html
I have to admit, that I didn't checked if you integrated them yet, but since I didn't heard back, I expected you did.

Then, as a next step we stepped up to fix those Qt locking functions
at the place where they really needed to be fixed in the end, which is the gcc as atomic locking builtins.
Even this was integrated upstream:
http://permalink.gmane.org/gmane.comp.gcc.patches/166978

> But. As long as hppa is a release architecture in
> Debian, we have to have it working. And I have expected more help than I
> actually got.
> 
> There has in the past 6-8 month been random segfaults of
> anything from make over moc to dpkg on the hppa buildds making it hard
> to get stuff built. It doesn't seem like anyone have actually worked on
> this, except the buildd admin giving the packages back and next time
> they succeeded.

Sometimes finding kernel bugs isn't easy.
I wouldn't be astonished, if this patch fixes those issues:
http://patchwork.kernel.org/patch/28458/
It still is on discussion on the hppa-kernel-list.

> It seems that the buildd's have issues with actually being on line, and
> it can take 1-3 days for the buildd admins to actually notice this.
> 
> Up to the lenny release there was the "you can crash a hppa machine by
> building ruby"-issue, where the suggested solution was "Let's not ship
> ruby and instead let anyone with a account crash our boxes".

The kernel crash was finally fixed by:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c61c25eb02757ecf697015ef4ae3675c5e114e2e
 
> And in general, I have the impression that "random unexplainable
> failures" is just too common for hppa to actually be able to support it
> in debian. And I also have the impression that the porters think that
> "random unexplainable failures" is fully acceptable.

No, it's not.
Again, kernel bugs are sometimes hard to find.
I still think that http://patchwork.kernel.org/patch/28458/ may fix a few.
The only outstanding bug I still know of is that we sometimes face uid/gid issues.
This still needs analysis.

All that said, personally I'm currently really happy about the hppa unstable port.
I'm regularly compiling some really big closed-source application on this platform
and gcc-3.4 and gij-4.4 are doing a really good thing. Furthermore, the already started
migration to NPTL (from linuxthreads) is great, from which I expect even better results.
For me hppa unstable is currently in such a good shape in which it hasn't been up to now.
So, dropping it now at _this_ _stage_ from unstable would be really sad after such a long 
(and imho sucessful) way.

Best regards,
Helge

Re: HPPA and Squeeze

[Luk Claes]

Grant Grundler wrote:
> +linux-parisc (hppa kernel, compiler and !debian tech forum)
> 
> Neil,
> thanks for the summary. I know this is an unpleasant business in general.
> 
> On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
>> Hi,
>>
>> As mentioned previously[0], the release team haven't been happy with the
>> state of the HPPA port in Debian. After the release team meeting[1], it
>> has been decided that unfortunatly HPPA will not be supported for
>> Squeeze. This was after careful consideration, and wasn't an easy
>> decision.
>>
>> This means that ftpmasters will be asked to remove HPPA from testing and
>> unstable from the 30th June. It is suggested that HPPA porters may wish
>> to consider using debian-ports.org if they wish to continue with the
>> port.
>>
>> Regards,
>> Neil McGovern
>>
>> [0] http://lists.debian.org/debian-release/2009/04/msg00299.html
> 
> Carlos O'Donnell asked some questions in response to [0] and I never
> saw any response.  Can an attendee of the above meeting please reply
> this email from Carlos?
>
>     http://lists.debian.org/debian-release/2009/04/msg00303.html

Note that it's wrong to assume we will come with the answers. It's an
extra bad feeling we get that even the people that do respond when there
is a request regarding hppa porters don't know what the issues are...

> I also never got a response to my offer here:
>     http://lists.debian.org/debian-release/2009/04/msg00339.html

There was some discussion with DSA and they didn't seem willing to take
the offer as it would be very restricted regarding access and control
(too strongly firewalled if I remember correctly) for our
administrators. It's rather strange that you did not get any feedback in
that regard.

> And my response again to this question posted in [0]:
>> * The machines that host the buildds still seem to have a very
>> unreliable kernel. Is there any update on this?

It looks like the amount of random crashes has decreased and the amount
of random segfaults has increased, though does not look promising after
more than 2 years already of random issues like this.

> Is upstream stable enough for a buildd?  I don't know since I'm not aware
> of any attempts to run a buildd with those kernels.

Rather recent kernels have been tried and like said above seem to behave
better, but still very much subpar.

> Is the answer to that question still germane?
> If so, I'm willing to setup a local buildd and try it. But I will need
> more time and some commitment that if it works, hppa remain in testing
> release (that's all I personally care about - I don't care about "stable"
> releases.)

That's not how it works. testing is the preparation for the next stable
release, so staying in testing means fixing any important outstanding
porting issue and most importantly the random crashes and segfaults,
actively making sure there are no important issues with the hppa port
within Debian and committing to support the next stable release.

> Can we have the minutes for this meeting?

No, I didn't even get the chance myself to read them. A summary of the
minutes will be posted as usual in the next 'Bits from the Release Team'
though.

> Also, I'd like to ask HPPA debs be kept in "testing" staging area,
> just never promoted when the release is cut.  This will let people
> continue using HPPA without having to suffer with the !hppa breakage
> that lives in unstable.

This will get DSA, maintainers, release team and others keep being
frustrated that hppa issues are making their work harder and will only
be tolerated if there will finally be a clear commitment from the hppa
porters to deal with any present and future important porting issue in a
reasonable time frame.

The main problem we have with hppa is that important porter issues are
not dealt with in a reasonable time frame. The random crashes and
segfaults are lasting for years already!

Note that we do *NOT* intend to drop hppa from unstable, it being
mentioned at all was an unfortunate sign of the deep frustration of some...

Cheers

Luk

Debian Release Manager

Re: HPPA and Squeeze

[Bart Schelstraete]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

Hello all,

Everybody is talking about the 'random crashes' and 'segfaults' in the HPPA
version.
Over here I'm using the hppa on a small HP-UX workstation, and that has an
uptime of 542 days!.
So it's not that unstable.
I even need to say that I had a lot more crashes with the x86 version then
with the hppa version.


Just to say that I'm personally not so unhappy with deb hppa, and that not
everything is bad.


B

On Fri, Jun 12, 2009 at 8:49 AM, Luk Claes <luk@debian.org> wrote:

>
> The main problem we have with hppa is that important porter issues are
> not dealt with in a reasonable time frame. The random crashes and
> segfaults are lasting for years already!
>
> Note that we do *NOT* intend to drop hppa from unstable, it being
> mentioned at all was an unfortunate sign of the deep frustration of some...
>
>
-- 
Schelstraete Bart
http://www.schelstraete.org
bart@schelstraete.org
Sent from Brussels, Brx, Belgium
Mae West <http://www.brainyquote.com/quotes/authors/m/mae_west.html>  - "I
like restraint, if it doesn't go too far."

[-- Attachment #2: Type: text/html, Size: 1536 bytes --]

Re: HPPA and Squeeze

[Bart Schelstraete]

 Hello all,

 Everybody is talking about the 'random crashes' and 'segfaults' in
the HPPA version.
 Over here I'm using the hppa on a small HP-UX workstation, and that
has an uptime of 542 days!.
 So it's not that unstable.
 I even need to say that I had a lot more crashes with the x86 version
then with the hppa version.


 Just to say that I'm personally not so unhappy with deb hppa, and
that not everything is bad.


 B

> On Fri, Jun 12, 2009 at 8:49 AM, Luk Claes <luk@debian.org> wrote:
>>
>> The main problem we have with hppa is that important porter issues are
>> not dealt with in a reasonable time frame. The random crashes and
>> segfaults are lasting for years already!
>>
>> Note that we do *NOT* intend to drop hppa from unstable, it being
>> mentioned at all was an unfortunate sign of the deep frustration of some=
...
>>
>
> --
> Schelstraete Bart
> http://www.schelstraete.org
> bart@schelstraete.org
> Sent from Brussels, Brx, Belgium
> Mae West =A0- "I like restraint, if it doesn't go too far."


--
Schelstraete Bart
http://www.schelstraete.org
bart@schelstraete.org
Sent from Brussels, Brx, Belgium
Erma Bombeck =A0- "Never have more children than you have car windows."

Re: HPPA and Squeeze

[James Bottomley]

On Fri, 2009-06-12 at 09:55 +0200, Bart Schelstraete wrote:
> Hello all,
> 
>  Everybody is talking about the 'random crashes' and 'segfaults' in
> the HPPA version.
>  Over here I'm using the hppa on a small HP-UX workstation, and that
> has an uptime of 542 days!.
>  So it's not that unstable.
>  I even need to say that I had a lot more crashes with the x86 version
> then with the hppa version.

It seems to be related to what machine you actually have.  I run a B180
as my network gateway, handling firewall, web,
postfix/postgrey/spamassassin at quite a high volume on a domain.  I
also used to run it with a PCMCIA wireless card just for chuckles and
grins (although I stopped that two years ago when I got a linksys).  It
runs debian testing and has been completely stable.  I only reboot it
for updates and in the seven or so years I've been doing this, I haven't
had any segfaults or crashes ... have to say I only started using debian
kernels on it for the last four or so years, because there used to be
big problems with the ones they built.

>  Just to say that I'm personally not so unhappy with deb hppa, and
> that not everything is bad.

I think the main class of problem machines are anything with SMP ...
unfortunately, I don't have one, so can't verify.

James

Re: HPPA and Squeeze

[dann frazier]

On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote:
> On Fri, 2009-06-12 at 09:55 +0200, Bart Schelstraete wrote:
> > Hello all,
> > 
> >  Everybody is talking about the 'random crashes' and 'segfaults' in
> > the HPPA version.
> >  Over here I'm using the hppa on a small HP-UX workstation, and that
> > has an uptime of 542 days!.
> >  So it's not that unstable.
> >  I even need to say that I had a lot more crashes with the x86 version
> > then with the hppa version.
> 
> It seems to be related to what machine you actually have.

And the load - buildds for unstable seem to trip over issues that we
don't see elsewhere.

>   I run a B180
> as my network gateway, handling firewall, web,
> postfix/postgrey/spamassassin at quite a high volume on a domain.  I
> also used to run it with a PCMCIA wireless card just for chuckles and
> grins (although I stopped that two years ago when I got a linksys).  It
> runs debian testing and has been completely stable.  I only reboot it
> for updates and in the seven or so years I've been doing this, I haven't
> had any segfaults or crashes ... have to say I only started using debian
> kernels on it for the last four or so years, because there used to be
> big problems with the ones they built.
> 
> >  Just to say that I'm personally not so unhappy with deb hppa, and
> > that not everything is bad.
> 
> I think the main class of problem machines are anything with SMP ...
> unfortunately, I don't have one, so can't verify.

We've tried both SMP and non-SMP kernels.

-- 
dann frazier

Re: HPPA and Squeeze

[Brian Szymanski]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

dann frazier wrote:
> On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote:
>   
>>>  Just to say that I'm personally not so unhappy with deb hppa, and
>>> that not everything is bad.
>>>       
>> I think the main class of problem machines are anything with SMP ...
>> unfortunately, I don't have one, so can't verify.
>>     
>
> We've tried both SMP and non-SMP kernels.
>   

FWIW, I've a j6700, running with an SMP kernel from testing, and it's
been rock solid for me.


-- 
Brian Szymanski
email:  skibrianski@gmail.com

Ex cibus merda. Ex merda humus. Ex humus cibus.


[-- Attachment #2: Type: text/html, Size: 1197 bytes --]

Re: HPPA and Squeeze

[Thibaut VARENE]

On Fri, Jun 12, 2009 at 5:35 PM, dann frazier<dannf@dannf.org> wrote:
> On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote:

>> It seems to be related to what machine you actually have.
>
> And the load - buildds for unstable seem to trip over issues that we
> don't see elsewhere.

"Workload" more to the point. Almost all my parisc boxen have been
running BOINC for years and never puked on it. I'm quite convinced the
issues buildds are suffering are much less random than people believe.
It's more likely that they are very uncommon corner cases.

FWIW, afaik "lafayette" - the autobuilder I recently provided - seems
to be running mostly fine. And as far as I (as the local admin) am
concerned, I believe my "response" time to problems (such as when the
first hardware that was committed to this autobuilder failed beyond
salvation and had to be entirely replaced) is acceptable. Let me know
if that weren't true ;-)

HTH
T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/

Re: HPPA and Squeeze

[dann frazier]

On Sun, Jun 14, 2009 at 08:29:14PM +0200, Thibaut VARENE wrote:
> On Fri, Jun 12, 2009 at 5:35 PM, dann frazier<dannf@dannf.org> wrote:
> > On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote:
> 
> >> It seems to be related to what machine you actually have.
> >
> > And the load - buildds for unstable seem to trip over issues that we
> > don't see elsewhere.
> 
> "Workload" more to the point.

Yes, workload is what I meant.

> Almost all my parisc boxen have been
> running BOINC for years and never puked on it. I'm quite convinced the
> issues buildds are suffering are much less random than people believe.
> It's more likely that they are very uncommon corner cases.
> 
> FWIW, afaik "lafayette" - the autobuilder I recently provided - seems
> to be running mostly fine. And as far as I (as the local admin) am
> concerned, I believe my "response" time to problems (such as when the
> first hardware that was committed to this autobuilder failed beyond
> salvation and had to be entirely replaced) is acceptable. Let me know
> if that weren't true ;-)
> 
> HTH
> T-Bone
> 

-- 
dann frazier

Re: HPPA and Squeeze

[Grant Grundler]

On Mon, Jun 08, 2009 at 10:26:06PM +0100, Neil McGovern wrote:
> Firstly, thanks for your mail, apologies that I haven't replied sooner,
> we've had EU and local elections, so I've been busy runnign around with
> leaflets, knocking on doors, kissing babies etc. like any politician. No
> expenses though...

No problem.

> 
> On Sat, Jun 06, 2009 at 12:36:01PM -0600, Grant Grundler wrote:
> > Carlos O'Donnell asked some questions in response to [0] and I never
> > saw any response.  Can an attendee of the above meeting please reply
> > this email from Carlos?
> >     http://lists.debian.org/debian-release/2009/04/msg00303.html
> > 
> 
> I'm not sure what replies you'd like... there's certainly been some
> follow ups to that mail.

The following questions haven't been answered in that thread:
1) Is there a list of different porting efforts?
2) What is considered proper java support? GCJ?

I've commented on the kernel side and it's looking better.
I don't know the status of the HPPA installer.

> > I also never got a response to my offer here:
> >     http://lists.debian.org/debian-release/2009/04/msg00339.html
> > 
> 
> Indeed, and that's worrying. I would have expected a HPPA porter (if
> indeed one still exists) to have replied to that.

Or they already have machines. I'm not a DD and don't aspire to be one.
So these are "in the wild" from a Debian point of view.

> > Quite a few serious hppa specific bugs have been fixed upstream over
> > the past 6 months. This is worth revisiting.
> > 
> > Is upstream stable enough for a buildd?  I don't know since I'm not aware
> > of any attempts to run a buildd with those kernels.
> 
> Neither do we, we're not HPPA porters :)
> We did go through this before with newer kernels, and it didn't help
> FWIW.
> 
> > Is the answer to that question still germane?
> 
> Ish. We still have the issue that you can't actually buy HPPAs any more,
> and various bits and pieces from the Arch Requalification list.

We can buy HPPA. Just not new ones. There are several resellers of
used HPPA gear if someone wants/needs to spend money on it.

Can you list the "various bits and pieces" specifically?

I can then prod the folks I know who might be able to do something about
if they still feel like it.


> [change of order by me below]
> > Also, I'd like to ask HPPA debs be kept in "testing" staging area,
> > just never promoted when the release is cut.  This will let people
> > continue using HPPA without having to suffer with the !hppa breakage
> > that lives in unstable. 
> 
> > (that's all I personally care about - I don't care about "stable"
> > releases.)
> 
> This is one of the major problems for the port. Testing exists to create
> the next stable release. Essentially, testing *is* the next stable,
> except that it's a little volatile for a number of months... :)

Ok.

> > Can we have the minutes for this meeting?
> 
> I'm afraid they're not publicly available, but I will be posting a
> mail to d-d-a real-soon-now(tm), apologies for the delays in this, it
> was a rather full meeting.

Given Debian is non-profit and strives to be transperent in it's operations,
this sounds like a digression in that effort.

I'm not on d-d-a. Can you please CC affected ports? (TIA)

cheers,
grant

Re: HPPA and Squeeze

[Grant Grundler]

On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
> Grant Grundler wrote:
> > +linux-parisc (hppa kernel, compiler and !debian tech forum)
> > 
> > Neil,
> > thanks for the summary. I know this is an unpleasant business in general.
> > 
> > On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
> >> Hi,
> >>
> >> As mentioned previously[0], the release team haven't been happy with the
> >> state of the HPPA port in Debian. After the release team meeting[1], it
> >> has been decided that unfortunatly HPPA will not be supported for
> >> Squeeze. This was after careful consideration, and wasn't an easy
> >> decision.
> >>
> >> This means that ftpmasters will be asked to remove HPPA from testing and
> >> unstable from the 30th June. It is suggested that HPPA porters may wish
> >> to consider using debian-ports.org if they wish to continue with the
> >> port.
> >>
> >> Regards,
> >> Neil McGovern
> >>
> >> [0] http://lists.debian.org/debian-release/2009/04/msg00299.html
> > 
> > Carlos O'Donnell asked some questions in response to [0] and I never
> > saw any response.  Can an attendee of the above meeting please reply
> > this email from Carlos?
> >
> >     http://lists.debian.org/debian-release/2009/04/msg00303.html
> 
> Note that it's wrong to assume we will come with the answers.

I was expecting a summary of specific issues from an organization
that claims to operate transperently.  The hand waving is easy. But
doesn't resolve problems and doesn't meet my expectation of an "open"
organization that I've donated money, time, and materials to.

>  It's an
> extra bad feeling we get that even the people that do respond when there
> is a request regarding hppa porters don't know what the issues are...

Expecting me to know the state of user space components is a bit silly.
I'm not a DD. I'm a kernel developer. Specifically IO/Device Drivers.

Carlos does know that state (toolchain/glibc) and he just wanted
a list of issues that are driving this decision. It's a very reasonable
question he asked.

> > I also never got a response to my offer here:
> >     http://lists.debian.org/debian-release/2009/04/msg00339.html
> 
> There was some discussion with DSA and they didn't seem willing to take
> the offer as it would be very restricted regarding access and control
> (too strongly firewalled if I remember correctly) for our administrators.

I can put one (and maybe two) machines on a public IP. Just ask.
The remote console access will remain behind a fire wall.

BTW, that firewall was reviewed and approved by Lamont (a pretty well
known DD and buildd maintainer).

Thibaut Varene (who is a DD) has offered to host HPPA buildd machines
as well but hasn't heard any response to that offer either.

> It's rather strange that you did not get any feedback in
> that regard.

Agred. Maybe the problems that need to be resolved aren't technical ones.

In any case, responding to some of the above with specific concerns
should continue this constructive dialog.

> 
> > And my response again to this question posted in [0]:
> >> * The machines that host the buildds still seem to have a very
> >> unreliable kernel. Is there any update on this?
> 
> It looks like the amount of random crashes has decreased and the amount
> of random segfaults has increased, though does not look promising after
> more than 2 years already of random issues like this.

The buildd is seeing issues most other HPPA users (including me) are
not seeing. That makes the problems quite a bit harder to resolve.

Last time I tried to set up a buildd was rather painful and exceeded
the amount of time I was willing to invest (vs contributing to other
kernel issues). This was more than 2 years ago and I'm willing to
try again IFF someone can tell me what impact that would have on
the Debian cabal that seems to be running things.

> > Is upstream stable enough for a buildd?  I don't know since I'm not aware
> > of any attempts to run a buildd with those kernels.
> 
> Rather recent kernels have been tried and like said above seem to behave
> better, but still very much subpar.

Have bugs been filed for those issues that HPPA folks can look at?
How can I find them?

> > Is the answer to that question still germane?
> > If so, I'm willing to setup a local buildd and try it. But I will need
> > more time and some commitment that if it works, hppa remain in testing
> > release (that's all I personally care about - I don't care about "stable"
> > releases.)
> 
> That's not how it works. testing is the preparation for the next stable
> release, so staying in testing means fixing any important outstanding
> porting issue and most importantly the random crashes and segfaults,
> actively making sure there are no important issues with the hppa port
> within Debian and committing to support the next stable release.

Ok. Sounds like Helge is ok with "unstable" and I'll try switching to
"unstable" instead of "testing". 


> > Can we have the minutes for this meeting?
> 
> No, I didn't even get the chance myself to read them. A summary of the
> minutes will be posted as usual in the next 'Bits from the Release Team'
> though.

Ok - can debian-hppa mailing list be CC'd when that's posted please?

> > Also, I'd like to ask HPPA debs be kept in "testing" staging area,
> > just never promoted when the release is cut.  This will let people
> > continue using HPPA without having to suffer with the !hppa breakage
> > that lives in unstable.
> 
> This will get DSA, maintainers, release team and others keep being
> frustrated that hppa issues are making their work harder

My goal is to allow these folks to ignore HPPA but still allow HPPA
to benefit from the "let bits bake in unstable before promoting".

I want to acknowledge stable releases are alot of work and I believe
Debian HPPA is sufficiently usable without that extra work.

>  and will only
> be tolerated if there will finally be a clear commitment from the hppa
> porters to deal with any present and future important porting issue in a
> reasonable time frame.
>
> The main problem we have with hppa is that important porter issues are
> not dealt with in a reasonable time frame. The random crashes and
> segfaults are lasting for years already!

As Helge said, many problems have been fixed. It's unfair to ignore that.

And open source is in general is NOT living up to the "good becuase
it was reviewed by many people" for the bulk of the code. HPPA is
suffering from this while resolving some pretty ugly arch specific issues.


> Note that we do *NOT* intend to drop hppa from unstable, it being
> mentioned at all was an unfortunate sign of the deep frustration of some...

Ok. Thanks for clarifying.

cheers,
grant

Re: HPPA and Squeeze

[Helge Deller]

On 06/15/2009 06:26 PM, Grant Grundler wrote:
> On Mon, Jun 08, 2009 at 10:26:06PM +0100, Neil McGovern wrote:
>> Firstly, thanks for your mail, apologies that I haven't replied sooner,
>> we've had EU and local elections, so I've been busy runnign around with
>> leaflets, knocking on doors, kissing babies etc. like any politician. No
>> expenses though...
>
> No problem.
>
>> On Sat, Jun 06, 2009 at 12:36:01PM -0600, Grant Grundler wrote:
>>> Carlos O'Donnell asked some questions in response to [0] and I never
>>> saw any response.  Can an attendee of the above meeting please reply
>>> this email from Carlos?
>>>      http://lists.debian.org/debian-release/2009/04/msg00303.html
>>>
>> I'm not sure what replies you'd like... there's certainly been some
>> follow ups to that mail.
>
> The following questions haven't been answered in that thread:
> 1) Is there a list of different porting efforts?
> 2) What is considered proper java support? GCJ?
>
> I've commented on the kernel side and it's looking better.
> I don't know the status of the HPPA installer.

The HPPA installer should be OK:
http://www.mail-archive.com/debian-hppa@lists.debian.org/msg06298.html

Helge

Re: HPPA and Squeeze

[Lucas Nussbaum]

On 15/06/09 at 11:31 -0600, Grant Grundler wrote:
> I was expecting a summary of specific issues from an organization
> that claims to operate transperently.  The hand waving is easy. But
> doesn't resolve problems and doesn't meet my expectation of an "open"
> organization that I've donated money, time, and materials to.
> 
> >  It's an
> > extra bad feeling we get that even the people that do respond when there
> > is a request regarding hppa porters don't know what the issues are...
> 
> Expecting me to know the state of user space components is a bit silly.
> I'm not a DD. I'm a kernel developer. Specifically IO/Device Drivers.
> 
> Carlos does know that state (toolchain/glibc) and he just wanted
> a list of issues that are driving this decision. It's a very reasonable
> question he asked.

[...]

> I can put one (and maybe two) machines on a public IP. Just ask.
> The remote console access will remain behind a fire wall.
> 
> BTW, that firewall was reviewed and approved by Lamont (a pretty well
> known DD and buildd maintainer).
> 
> Thibaut Varene (who is a DD) has offered to host HPPA buildd machines
> as well but hasn't heard any response to that offer either.

(Stepping in ; I had some HPPA-related issues in one of my packages -
ruby1.9 - so this is based on my experience with that problems)

I think that your email summarizes the problem quite well: there are
several people willing to offer buildd hosting, help after someone else
has investigated the issues, etc.
What debian-hppa currently lacks is someone that is willing to
proactively detect issues (looking at packages that failed to build, for
example), investigate them, and fix them. This can be done cooperating
with the package maintainers, but the HPPA side should take the lead.
The fact that HPPA people are asking the release team "what are the
problems you are talking about?" clearly shows that this is broken: the
HPPA people should be knowing more than the release team about HPPA
issues.

PS: if you want an HPPA-specific issue to play with,
http://experimental.debian.net/fetch.php?&pkg=ruby1.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=raw
might be a good candidate.
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |

Re: HPPA and Squeeze

[Helge Deller]

On 06/16/2009 08:25 AM, Lucas Nussbaum wrote:
> On 15/06/09 at 11:31 -0600, Grant Grundler wrote:
> PS: if you want an HPPA-specific issue to play with,
> http://experimental.debian.net/fetch.php?&pkg=ruby1.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=raw
> might be a good candidate.

In reality it's not (any longer) a hppa specific bug. It's a bug in ruby.
Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa.
The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable...

Helge

Re: HPPA and Squeeze

[Aurelien Jarno]

On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote:
> On 06/16/2009 08:25 AM, Lucas Nussbaum wrote:
>> On 15/06/09 at 11:31 -0600, Grant Grundler wrote:
>> PS: if you want an HPPA-specific issue to play with,
>> http://experimental.debian.net/fetch.php?&pkg=ruby1.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=raw
>> might be a good candidate.
>
> In reality it's not (any longer) a hppa specific bug. It's a bug in ruby.
> Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa.
> The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable...
>

BTW, Carlos, could you please send me the latest version of your
patches, so that we can actually do the switch with version 2.10?

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: HPPA and Squeeze

[Grant Grundler]

On Tue, Jun 16, 2009 at 08:25:31AM +0200, Lucas Nussbaum wrote:
...
> > BTW, that firewall was reviewed and approved by Lamont (a pretty well
> > known DD and buildd maintainer).
> > 
> > Thibaut Varene (who is a DD) has offered to host HPPA buildd machines
> > as well but hasn't heard any response to that offer either.
> 
> (Stepping in ; I had some HPPA-related issues in one of my packages -
> ruby1.9 - so this is based on my experience with that problems)
> 
> I think that your email summarizes the problem quite well: there are
> several people willing to offer buildd hosting, help after someone else
> has investigated the issues, etc.
> What debian-hppa currently lacks is someone that is willing to
> proactively detect issues (looking at packages that failed to build, for
> example), investigate them, and fix them. This can be done cooperating
> with the package maintainers, but the HPPA side should take the lead.

Yup - this is definitely true. debian-hppa needed alot of prodding to
look at buildd failures.

> The fact that HPPA people are asking the release team "what are the
> problems you are talking about?" clearly shows that this is broken: the
> HPPA people should be knowing more than the release team about HPPA
> issues.

Generalizing one person's response (mine) to represent the group is wrong.

However I agree the release team has no one who cares about HPPA involved.
And yes, it's up to the release team to track bugs and determine
the viability of a release based on outstanding bugs.

As I said before, I'm ok with NOT having a "stable" HPPA release.
If someone disagrees, then they need to participate in the release
team and help debian-hppa focus on critical buildd failures. ie generate
the nag mail listing the HPPA-specific issues that need to be resolved.


> PS: if you want an HPPA-specific issue to play with,
> http://experimental.debian.net/fetch.php?&pkg=ruby1.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=raw
> might be a good candidate.

This did take a long time to resolve. Helge described the root cause
(ruby did not support LinuxThreads implementation correctly) and
resolution plan (migrate HPPA to NTPL).

No phase of this problem sounds trivial to debug or resolve.
Based on this, I can argue the HPPA response is reasonable even
if is unsatisfactory and frustrating to you (as package maintainer).

Do you have another HPPA specific issue?
Or maybe just remind the list how to find those issues?
(Teach a man to fish...)

thanks,
grant

Re: HPPA and Squeeze

[dann frazier]

On Tue, Jun 16, 2009 at 02:50:27PM -0600, Grant Grundler wrote:
> On Tue, Jun 16, 2009 at 08:25:31AM +0200, Lucas Nussbaum wrote:
> ...
> > > BTW, that firewall was reviewed and approved by Lamont (a pretty well
> > > known DD and buildd maintainer).
> > > 
> > > Thibaut Varene (who is a DD) has offered to host HPPA buildd machines
> > > as well but hasn't heard any response to that offer either.
> > 
> > (Stepping in ; I had some HPPA-related issues in one of my packages -
> > ruby1.9 - so this is based on my experience with that problems)
> > 
> > I think that your email summarizes the problem quite well: there are
> > several people willing to offer buildd hosting, help after someone else
> > has investigated the issues, etc.
> > What debian-hppa currently lacks is someone that is willing to
> > proactively detect issues (looking at packages that failed to build, for
> > example), investigate them, and fix them. This can be done cooperating
> > with the package maintainers, but the HPPA side should take the lead.
> 
> Yup - this is definitely true. debian-hppa needed alot of prodding to
> look at buildd failures.
> 
> > The fact that HPPA people are asking the release team "what are the
> > problems you are talking about?" clearly shows that this is broken: the
> > HPPA people should be knowing more than the release team about HPPA
> > issues.
> 
> Generalizing one person's response (mine) to represent the group is wrong.
> 
> However I agree the release team has no one who cares about HPPA involved.
> And yes, it's up to the release team to track bugs and determine
> the viability of a release based on outstanding bugs.
> 
> As I said before, I'm ok with NOT having a "stable" HPPA release.
> If someone disagrees, then they need to participate in the release
> team and help debian-hppa focus on critical buildd failures. ie generate
> the nag mail listing the HPPA-specific issues that need to be resolved.
> 
> 
> > PS: if you want an HPPA-specific issue to play with,
> > http://experimental.debian.net/fetch.php?&pkg=ruby1.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=raw
> > might be a good candidate.
> 
> This did take a long time to resolve. Helge described the root cause
> (ruby did not support LinuxThreads implementation correctly) and
> resolution plan (migrate HPPA to NTPL).
> 
> No phase of this problem sounds trivial to debug or resolve.
> Based on this, I can argue the HPPA response is reasonable even
> if is unsatisfactory and frustrating to you (as package maintainer).
> 
> Do you have another HPPA specific issue?
> Or maybe just remind the list how to find those issues?
> (Teach a man to fish...)

Are we still having random segfaults on paer? If so - that's be a good
one to resolve. Not sure if DSA would be willing to grant (heh) you
access to that box, or if we should try running a dummy buildd on
another rp2470.

-- 
dann frazier

Re: HPPA and Squeeze

[John David Anglin]

> Again, kernel bugs are sometimes hard to find.
> I still think that http://patchwork.kernel.org/patch/28458/ may fix a few.
> The only outstanding bug I still know of is that we sometimes face uid/gid issues.
> This still needs analysis.

Helge suggested yesterday that the uid/gid issue might be a bug in nscd.
I installed 2.6.30 last night and disabled nscd.  I have now run for more
than a day without this issue appearing.  The machine did a full GCC build
and check taking about 24 hours.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Carlos O'Donell]

On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarno<aurelien@aurel32.net> wrote:
> On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote:
>> On 06/16/2009 08:25 AM, Lucas Nussbaum wrote:
>>> On 15/06/09 at 11:31 -0600, Grant Grundler wrote:
>>> PS: if you want an HPPA-specific issue to play with,
>>> http://experimental.debian.net/fetch.php?&pkg=ruby1.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=raw
>>> might be a good candidate.
>>
>> In reality it's not (any longer) a hppa specific bug. It's a bug in ruby.
>> Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa.
>> The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable...
>>
>
> BTW, Carlos, could you please send me the latest version of your
> patches, so that we can actually do the switch with version 2.10?

I'm in the middle of a build-test cycle with glibc/glibc-ports git
head. I'll send you the patches before the end of today.

Cheers,
Carlos.

Re: HPPA and Squeeze

[Matthias Klose]

Grant Grundler schrieb:
> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
>> Grant Grundler wrote:
>>> +linux-parisc (hppa kernel, compiler and !debian tech forum)
>>>
>>> Neil,
>>> thanks for the summary. I know this is an unpleasant business in general.
>>>
>>> On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
>>>> Hi,
>>>>
>>>> As mentioned previously[0], the release team haven't been happy with the
>>>> state of the HPPA port in Debian. After the release team meeting[1], it
>>>> has been decided that unfortunatly HPPA will not be supported for
>>>> Squeeze. This was after careful consideration, and wasn't an easy
>>>> decision.
>>>>
>>>> This means that ftpmasters will be asked to remove HPPA from testing and
>>>> unstable from the 30th June. It is suggested that HPPA porters may wish
>>>> to consider using debian-ports.org if they wish to continue with the
>>>> port.
>>>>
>>>> Regards,
>>>> Neil McGovern
>>>>
>>>> [0] http://lists.debian.org/debian-release/2009/04/msg00299.html
>>> Carlos O'Donnell asked some questions in response to [0] and I never
>>> saw any response.  Can an attendee of the above meeting please reply
>>> this email from Carlos?
>>>
>>>     http://lists.debian.org/debian-release/2009/04/msg00303.html
>> Note that it's wrong to assume we will come with the answers.
> 
> I was expecting a summary of specific issues from an organization
> that claims to operate transperently.  The hand waving is easy. But
> doesn't resolve problems and doesn't meet my expectation of an "open"
> organization that I've donated money, time, and materials to.

+1. dropping hppa as a release architecture was not communicated by the release
team at all.  I did spend some time to get gcj / default-jdk working on hppa,
and some money (buying a new disk for a hppa machine) to help this port.  The
time and the money could have spent better, if d-r would have better
communicated about their intent.

hppa is not in a good shape, but there are other architectures which are not
better (sparc, mips*) from a toolchain point of view. what about these?

there are issues pointed out and not addressed like the -dev / -headers packages
 built as binary independent packages just to save disk space, which have an
impact on "slow" architectures, and which are not addressed by the release team.
would the release team mind addressing these real issues, or should we drop
"slow" architectures as well?

  Matthias

Re: HPPA and Squeeze

[John David Anglin]

> Grant Grundler schrieb:
> > On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
> >> Grant Grundler wrote:
> >>> +linux-parisc (hppa kernel, compiler and !debian tech forum)
> >>>
> >>> Neil,
> >>> thanks for the summary. I know this is an unpleasant business in general.
> >>>
> >>> On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
> >>>> Hi,
> >>>>
> >>>> As mentioned previously[0], the release team haven't been happy with the
> >>>> state of the HPPA port in Debian. After the release team meeting[1], it
> >>>> has been decided that unfortunatly HPPA will not be supported for
> >>>> Squeeze. This was after careful consideration, and wasn't an easy
> >>>> decision.
> >>>>
> >>>> This means that ftpmasters will be asked to remove HPPA from testing and
> >>>> unstable from the 30th June. It is suggested that HPPA porters may wish
> >>>> to consider using debian-ports.org if they wish to continue with the
> >>>> port.
> >>>>
> >>>> Regards,
> >>>> Neil McGovern
> >>>>
> >>>> [0] http://lists.debian.org/debian-release/2009/04/msg00299.html
> >>> Carlos O'Donnell asked some questions in response to [0] and I never
> >>> saw any response.  Can an attendee of the above meeting please reply
> >>> this email from Carlos?
> >>>
> >>>     http://lists.debian.org/debian-release/2009/04/msg00303.html
> >> Note that it's wrong to assume we will come with the answers.
> > 
> > I was expecting a summary of specific issues from an organization
> > that claims to operate transperently.  The hand waving is easy. But
> > doesn't resolve problems and doesn't meet my expectation of an "open"
> > organization that I've donated money, time, and materials to.
> 
> +1. dropping hppa as a release architecture was not communicated by the release
> team at all.  I did spend some time to get gcj / default-jdk working on hppa,
> and some money (buying a new disk for a hppa machine) to help this port.  The
> time and the money could have spent better, if d-r would have better
> communicated about their intent.

I totally understand your frustration.  I have spent thousands of hours
supporting hppa.  At my current rate, this would be...

I believe that intent to drop an architecture should be communicated well
in advance of the fact.  Not doing so will alienate the developer and
user communities.

> hppa is not in a good shape, but there are other architectures which are not
> better (sparc, mips*) from a toolchain point of view. what about these?

Sparc still exists as a mainframe architecture.  If you can afford a
high end server, it's probably not that slow.  64 processors, 256 cores,
and 512 threads at 2.52 GHz can't be all that bad ;)

As you know, it takes a lot of effort to keep a tool chain up to date.
If a manufacturer doesn't provide the support that is needed to keep
the tool chain going, then the open source support for it will die.
It can't be done without access to a variety of hardware, and documentation
that may be proprietary.

Mips and arm are primarily embedded architectures.  Unless one of
these manages to achieve market success as a low-end programmable device
running linux, the user community is going to be limited to the developers
working on products using these devices.  The workstation and server
market using mips is dead.

I was able to build up the tools I need for a Linux arm board in a few
days.  Thus, I don't really see the need for Debian to try to maintain
full blown builds and releases for these architectures.  Certainly,
there's a lot applications for linux in board products, but it's very
product specific.

I can understand the desire to trim architectures.  However, it's clear
the current decision was based on some misinformation, and an unclear
rational.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Luk Claes]

Matthias Klose wrote:
> Grant Grundler schrieb:
>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
>>> Grant Grundler wrote:

>>>> On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:

>>>>     http://lists.debian.org/debian-release/2009/04/msg00303.html
>>> Note that it's wrong to assume we will come with the answers.
>> I was expecting a summary of specific issues from an organization
>> that claims to operate transperently.  The hand waving is easy. But
>> doesn't resolve problems and doesn't meet my expectation of an "open"
>> organization that I've donated money, time, and materials to.
> 
> +1. dropping hppa as a release architecture was not communicated by the release
> team at all.  I did spend some time to get gcj / default-jdk working on hppa,
> and some money (buying a new disk for a hppa machine) to help this port.  The
> time and the money could have spent better, if d-r would have better
> communicated about their intent.

There are issues with the hppa port where the release team considered
dropping it since 2005 communicated to the porter list...

> hppa is not in a good shape, but there are other architectures which are not
> better (sparc, mips*) from a toolchain point of view. what about these?

I'm not aware of current toolchain issues on sparc and the issues on
mips* still seem to be manageable, no?

> there are issues pointed out and not addressed like the -dev / -headers packages
>  built as binary independent packages just to save disk space, which have an
> impact on "slow" architectures, and which are not addressed by the release team.
> would the release team mind addressing these real issues, or should we drop
> "slow" architectures as well?

Well, this Packages issue is clearly a responsability from the FTP Team
and the Release Team would indeed be very happy to have that resolved.

Cheers

Luk

Re: HPPA and Squeeze

[Luk Claes]

John David Anglin wrote:
>> Grant Grundler schrieb:
>>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
>>>> Grant Grundler wrote:

> I can understand the desire to trim architectures.  However, it's clear
> the current decision was based on some misinformation, and an unclear
> rational.

There is no desire to trim working architectures.

It's very easy to tell there is nothing wrong when you don't have to
deal with unreliable build daemons, endless discussions but no visible
progress (except for java support) and complaints from DSA, package
maintainers and others.

Cheers

Luk

Re: HPPA and Squeeze

[Randolph Chung]

Luk,
> There is no desire to trim working architectures.
>
> It's very easy to tell there is nothing wrong when you don't have to
> deal with unreliable build daemons, endless discussions but no visible
> progress (except for java support) and complaints from DSA, package
> maintainers and others.
>   
If you looked at https://buildd.debian.org/stats/graph-big.png  I think 
it is obvious hppa is not *that* broken. hppa is >95% built. That is not 
that bad. Of course, it can be better, but if you looked at this with a 
historical perspective the port is really in a pretty good shape.

If you looked at the status of the toolchain posted to the 
gcc-testresults page: http://gcc.gnu.org/ml/gcc-testresults/2009-06/  
you can see that hppa is one of the better architectures out there. Our 
results are on par with (if not better than) other supported architectures.

IMHO hppa contributed a lot to getting Debian packages (and upstream) 
properly fixed to build properly across many other architectures and 
making it easier for new architectures to get incorporated into Debian. 
It's unfortunate that parisc is no longer a commercially popular 
platform, but why should not affect whether Debian supports it?

It's obvious from the recent exchange that there are still people on the 
hppa team (and other Debian maintainers) that are willing to work on 
this architecture to make things better. Also by many metrics it is 
still very much a working architecture. It's really a shame that 
Debian's considering dropping support for HPPA in Squeeze. Please 
reconsider.

randolph

Re: HPPA and Squeeze

[Thibaut VARENE]

On Thu, Jun 18, 2009 at 8:33 AM, Luk Claes<luk@debian.org> wrote:
> John David Anglin wrote:
>>> Grant Grundler schrieb:
>>>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
>>>>> Grant Grundler wrote:
>
>> I can understand the desire to trim architectures. =C2=A0However, it=
's clear
>> the current decision was based on some misinformation, and an unclea=
r
>> rational.
>
> There is no desire to trim working architectures.
>
> It's very easy to tell there is nothing wrong when you don't have to
> deal with unreliable build daemons, endless discussions but no visibl=
e
> progress (except for java support) and complaints from DSA, package
> maintainers and others.

I'm sorry, but this thread is now over 2 weeks old and we yet have to
see a *rationale* motivating the current decision. Not some claims
about bugs (which we still haven't been pointed at, except for the
ruby one, which we addressed already) affecting the buildds (and that
only you experience). Speaking of which, I'm not aware of any problem
affecting lafayette...

We have given you tangible elements and have answered each and every
questions that have been raised in this thread. The release team, on
the other hand, failed to answer the single question we've been
asking: what's the rationale for dropping parisc?

I joined Debian many years ago because it seemed to me that it had
proper ethics, in particular because decisions were taken
transparently, and were properly - and openly - discussed before
anything final was settled. I too have invested time and money into
the project. I'm extremely disappointed with the handling of the issue
at stake here.

Again, I would like to see a comprehensive rationale for this
decision, so that we can at least try to address the problems at hands
and hope for re-inclusion after squeeze. BTW, can you clarify whether
that would be an option?

Cheers,
T-Bone

--=20
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HPPA and Squeeze

[John David Anglin]

> It's very easy to tell there is nothing wrong when you don't have to
> deal with unreliable build daemons, endless discussions but no visible
> progress (except for java support) and complaints from DSA, package
> maintainers and others.

The problem with the build daemons may be a buggy version of nscd.
It causes random problems with uid/gid lookups.  This is just a guess
based on this report:
http://www.nabble.com/Boost-build-failure-on-hppa-td23496708.html

I had problems with sshd and dpkg on my c3750 until I disabled nscd.
It's now running 2.6.30.  It has done a full build and check of GCC
several times, and appears to be stable with this kernel.  This is
with a UP kernel.

With SMP kernels, there's still a problem with random segementation
faults.  These cause application core dumps and are normally logged
in /var/log/debug.  The frequency of these problems vary with kernel
version.

I believe that it should be possible to setup a reliable hppa build
server running a UP kernel.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Luk Claes]

Thibaut VARENE wrote:
> On Thu, Jun 18, 2009 at 8:33 AM, Luk Claes<luk@debian.org> wrote:
>> John David Anglin wrote:
>>>> Grant Grundler schrieb:
>>>>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
>>>>>> Grant Grundler wrote:
>>> I can understand the desire to trim architectures.  However, it's clear
>>> the current decision was based on some misinformation, and an unclear
>>> rational.
>> There is no desire to trim working architectures.
>>
>> It's very easy to tell there is nothing wrong when you don't have to
>> deal with unreliable build daemons, endless discussions but no visible
>> progress (except for java support) and complaints from DSA, package
>> maintainers and others.
> 
> I'm sorry, but this thread is now over 2 weeks old and we yet have to
> see a *rationale* motivating the current decision. Not some claims
> about bugs (which we still haven't been pointed at, except for the
> ruby one, which we addressed already) affecting the buildds (and that
> only you experience). Speaking of which, I'm not aware of any problem
> affecting lafayette...

lafayette is only doing non-sid to make sure we have a buildd that is
not heavy loaded and very probable to be able to build all security and
stable/oldstable updates...

> We have given you tangible elements and have answered each and every
> questions that have been raised in this thread. The release team, on
> the other hand, failed to answer the single question we've been
> asking: what's the rationale for dropping parisc?

Please read again, it's only in the beginning of the mail...

> I joined Debian many years ago because it seemed to me that it had
> proper ethics, in particular because decisions were taken
> transparently, and were properly - and openly - discussed before
> anything final was settled. I too have invested time and money into
> the project. I'm extremely disappointed with the handling of the issue
> at stake here.

I'm very disappointed at the hppa porters attitudes I must say. They
talk a lot, they assumingly work a lot behind the scenes, but they don't
seem to know what issues there are within the project nor is there any
visible progress unless we prod very hard and even then they are more
worried about the way we prod than about proving they are worthy to
support the port and show some real progress...

> Again, I would like to see a comprehensive rationale for this
> decision, so that we can at least try to address the problems at hands
> and hope for re-inclusion after squeeze. BTW, can you clarify whether
> that would be an option?

It's still an option to stay in squeeze like I told before, but we want
a clear sign that the port will be supported throughout the whole
release cycle (which honestly looks more and more like it could be the
case, though I still fail to see why randomly crashing and segfaulting
buildds and decreasing support for programming languages before Lenny
was not seen as critical enough).

Cheers

Luk

Re: HPPA and Squeeze

[Luk Claes]

Randolph Chung wrote:
> Luk,
>> There is no desire to trim working architectures.
>>
>> It's very easy to tell there is nothing wrong when you don't have to
>> deal with unreliable build daemons, endless discussions but no visible
>> progress (except for java support) and complaints from DSA, package
>> maintainers and others.
>>   
> If you looked at https://buildd.debian.org/stats/graph-big.png  I think
> it is obvious hppa is not *that* broken. hppa is >95% built. That is not
> that bad. Of course, it can be better, but if you looked at this with a
> historical perspective the port is really in a pretty good shape.

As already was explained, the issue is not that builds don't succeed
after multiple tries. The issue is that sometimes multiple tries are
needed and sometimes the buildds crash.

> If you looked at the status of the toolchain posted to the
> gcc-testresults page: http://gcc.gnu.org/ml/gcc-testresults/2009-06/ 
> you can see that hppa is one of the better architectures out there. Our
> results are on par with (if not better than) other supported architectures.

I hope that it will show in the reliability of the buildds and the
general improvement of support for the hppa port.

Cheers

Luk

HPPA and Squeeze

[Luk Claes]

Hmm...

It's right that some of my comments are rather harsh, though you must
know that I'm not speaking from a personal perspective.

Personally (and as Release Manager), I would be very happy to have a
good working hppa port for Squeeze and beyond.

I made sure that the hppa port was included into Lenny even when the
Debian System Administrators (DSA), package maintainers, release team
members an others were shouting to drop it. I thought it was unfair to
drop the port just before the release. They accepted my decision as long
as I would make it clear that it was a *big* exception not to be taken
lightly. At the time java support was completely dropped, buildds were
crashing every other day and support for other programing languages
looked poor and the port was still using linuxthreads as the latest of
all ports.

After the release of Lenny there were still not much signs of
improvement to the reliability of the buildds and the move to ntpl (that
was going to solve almost all issues the maintainers had) seemed to not
happen and not going to solve everything. The only surprising
improvement was the regained java support.

It's quite disturbing in my honest opinion that only after us starting a
thread like this one that we get to know the status of some of the
porting efforts and lots of vocal support, but not many visible
improvements. Instead of making sure that there is visibile improvement
after that, this pattern seems to repeat itself which is not looking
very promising. I'm sorry if my and others' frustration is ventilated in
some of the mails. The issues with the buildds are lasting for years
already with lots of time spent by DSA and others.

I still hope that the hppa porters can prove us wrong, fix the kernel
issues (which are the probable cause of the unreliability of the
buildds), finalise the ntpl move and stay on top of porting issues in
Debian in the future.

Please let us now focus on improving the status of the hppa port in
general and the buildds in particular!

Cheers

Luk

Re: HPPA and Squeeze

[Kurt Roeckx]

I take a regular look at various arches why packages are not
correctly built.  hppa is the most annoying arch for me. If you
look at the stats you will notice that it's almost always
the lowest in the stats.  The reason it more or less keeps up is
because I put alot of time in looking at the state of the
packages and that packages get retried alot by the buildd
maintainer.

One of the most annoying things about it is that packages only
get uploaded 2 or 3 times a week.  This has as effect that alot
of packages fail to build because others haven't been uploaded
yet.  Alot of packages are uninstallable, and are basicly waiting
for others to be built/uploaded.  With only 2/3 uploads a week
this means that packages are uninstallable for _weeks_.  By the
time the first reason has been fixed, something else already make
it uninstallable again.  And I guess this is also the reason
the release team always needs to take a look at why something
is uninstallable on hppa.  I can deal with this, but because of
this reason, hppa is a low priority port for me.

So it's my understanding that the porters have no idea about the
problems.  So I will start to mail you about problems as soon
as I see them and they look like porting issues specific
to hppa.

Here is a list of packages that failed to build because of instability
on the buildds today:
package     | buildd   | error
qgit        | penalosa | make: *** [install] Segmentation fault
acpica-unix | peri     | make: *** [install] Segmentation fault


This are probabaly porting issues, they atleast seems to
only affect hppa:
package        | error
rt-tests       | PTHREAD_PRIO_INHERIT undeclared (NPTL support?)
insighttoolkit | undefined references
axis	       | #531995: Cannot override the final method from ResourceBundle
petsc	       | petscvariables: No such file or directory

Logs can be found at
https://buildd.debian.org/build.cgi?arch=hppa;pkg=$package


Kurt

On Fri, Jun 19, 2009 at 08:05:56AM +0200, Luk Claes wrote:
> Hmm...
> 
> It's right that some of my comments are rather harsh, though you must
> know that I'm not speaking from a personal perspective.
> 
> Personally (and as Release Manager), I would be very happy to have a
> good working hppa port for Squeeze and beyond.
> 
> I made sure that the hppa port was included into Lenny even when the
> Debian System Administrators (DSA), package maintainers, release team
> members an others were shouting to drop it. I thought it was unfair to
> drop the port just before the release. They accepted my decision as long
> as I would make it clear that it was a *big* exception not to be taken
> lightly. At the time java support was completely dropped, buildds were
> crashing every other day and support for other programing languages
> looked poor and the port was still using linuxthreads as the latest of
> all ports.
> 
> After the release of Lenny there were still not much signs of
> improvement to the reliability of the buildds and the move to ntpl (that
> was going to solve almost all issues the maintainers had) seemed to not
> happen and not going to solve everything. The only surprising
> improvement was the regained java support.
> 
> It's quite disturbing in my honest opinion that only after us starting a
> thread like this one that we get to know the status of some of the
> porting efforts and lots of vocal support, but not many visible
> improvements. Instead of making sure that there is visibile improvement
> after that, this pattern seems to repeat itself which is not looking
> very promising. I'm sorry if my and others' frustration is ventilated in
> some of the mails. The issues with the buildds are lasting for years
> already with lots of time spent by DSA and others.
> 
> I still hope that the hppa porters can prove us wrong, fix the kernel
> issues (which are the probable cause of the unreliability of the
> buildds), finalise the ntpl move and stay on top of porting issues in
> Debian in the future.
> 
> Please let us now focus on improving the status of the hppa port in
> general and the buildds in particular!
> 
> Cheers
> 
> Luk
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-release-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 

Re: HPPA and Squeeze

[Philipp Kern]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
> Here is a list of packages that failed to build because of instability
> on the buildds today:
> package     | buildd   | error
> qgit        | penalosa | make: *** [install] Segmentation fault
> acpica-unix | peri     | make: *** [install] Segmentation fault

I had those random segfaults in make on paer too, until we switched to the
UP kernel, at least from what I saw.

Sadly it looks that I forgot the buildd upgrade process on paer some days
ago.  The buildd will be back building ASAP.

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp Kern                        Debian Developer
: :' :  http://philkern.de                         Stable Release Manager
`. `'   xmpp:phil@0x539.de                         Wanna-Build Admin
  `-    finger pkern/key@db.debian.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: HPPA and Squeeze

[Kurt Roeckx]

On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
> So it's my understanding that the porters have no idea about the
> problems.  So I will start to mail you about problems as soon
> as I see them and they look like porting issues specific
> to hppa.

netgen fails to built with an internal compiler error since
atleast April 2008.  Logs are at:
https://buildd.debian.org/build.cgi?pkg=netgen;ver=4.4-15;arch=hppa
https://buildd.debian.org/build.cgi?pkg=netgen;arch=hppa


Kurt

Re: HPPA and Squeeze

[Kurt Roeckx]

On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
> So it's my understanding that the porters have no idea about the
> problems.  So I will start to mail you about problems as soon
> as I see them and they look like porting issues specific
> to hppa.

Ruby1.9 hangs in test_thread.rb and gets killed after
150 minutes of inactivity.  I assume NPTL will fix this.


Kurt

Re: HPPA and Squeeze

[Thibaut VARENE]

On Sat, Jun 20, 2009 at 4:39 PM, Kurt Roeckx<kurt@roeckx.be> wrote:
> On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
>> So it's my understanding that the porters have no idea about the
>> problems. =C2=A0So I will start to mail you about problems as soon
>> as I see them and they look like porting issues specific
>> to hppa.
>
> Ruby1.9 hangs in test_thread.rb and gets killed after
> 150 minutes of inactivity. =C2=A0I assume NPTL will fix this.

yes, it's a ruby bug, it's been explained on this m-l already.
Ruby's implementation cannot handle linuxthreads.

--=20
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HPPA and Squeeze

[John David Anglin]

> On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
> > So it's my understanding that the porters have no idea about the
> > problems.  So I will start to mail you about problems as soon
> > as I see them and they look like porting issues specific
> > to hppa.
> 
> netgen fails to built with an internal compiler error since
> atleast April 2008.  Logs are at:
> https://buildd.debian.org/build.cgi?pkg=netgen;ver=4.4-15;arch=hppa
> https://buildd.debian.org/build.cgi?pkg=netgen;arch=hppa

g++ -c -I. -I../libsrc/interface -Iinclude -O2 -I/usr/include/GL -I/usr/include/tcl8.4 -I/usr/include/tk8.4 -I/usr/X11R6/include  -DLINUX -DOPENGL -DNGSOLVE basiclinalg/cholesky.cpp basiclinalg/calcinverse.cpp basiclinalg/vecmat.cpp basiclinalg/bandmatrix.cpp basiclinalg/eigensystem.cpp linalg/basevector.cpp linalg/vvector.cpp linalg/basematrix.cpp linalg/sparsematrix.cpp linalg/special_matrix.cpp linalg/cg.cpp linalg/chebyshev.cpp linalg/eigen.cpp linalg/order.cpp linalg/sparsecholesky.cpp linalg/pardisoinverse.cpp linalg/superluinverse.cpp linalg/jacobi.cpp linalg/blockjacobi.cpp linalg/commutingAMG.cpp ngstd/exception.cpp ngstd/table.cpp ngstd/bitarray.cpp ngstd/flags.cpp ngstd/symboltable.cpp ngstd/blockalloc.cpp ngstd/evalfunc.cpp ngstd/templates.cpp ngstd/localheap.cpp
linalg/basematrix.cpp: In member function 'void ngla::S_BaseMatrix<std::complex<double> >::_ZTv0_n72_NK4ngla12S_BaseMatrixISt7complexIdEE12MultTransAddES2_RKNS_10BaseVectorERS4_(ngbla::Complex, const ngla::BaseVector&, ngla::BaseVector&) const':
linalg/basematrix.cpp:208: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6830
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.3/README.Bugs> for instructions.

When an internal compiler error occurs as above, a GCC bug report with
the following information should be filed:

1) failing compiler command,
2) details of the compiler (gcc -v), and
3) the preprocessed source for the failing command.

You can CC me on hppa bugs (danglin at gcc dot gnu dot org).

It takes less than five minutes to generate the above information and
file a bug report.  The preprocessed source is really important as it
is very difficult for others to duplicate the problem otherwise.

In this case, it appears the following assert is triggered.

          /* If the DECL isn't in memory, then the DECL wasn't properly
	     marked TREE_ADDRESSABLE, which will be either a front-end
	     or a tree optimizer bug.  */
	  gcc_assert (MEM_P (result));

There's a fairly high probability that this is a generic bug.

If the bug is a compiler regression, then fixes will applied to all active
branches when available.  Thus, it is useful to know if an earlier compiler
version was able to successfully compile the file.

As things stand, I file more than 90% of hppa compiler bugs based on what
I see in my testing.  However, I'm not trying to build and maintain 10,000
packages.  So, hopefully, the debian build team can help a bit more with
problem reporting.

I recognize that not all bugs are easy to classify.  However, internal
compiler errors are always compiler bugs.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Kurt Roeckx]

On Sat, Jun 20, 2009 at 12:02:54PM -0400, John David Anglin wrote:
> > On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
> > > So it's my understanding that the porters have no idea about the
> > > problems.  So I will start to mail you about problems as soon
> > > as I see them and they look like porting issues specific
> > > to hppa.
> > 
> > netgen fails to built with an internal compiler error since
> > atleast April 2008.  Logs are at:
> 
> When an internal compiler error occurs as above, a GCC bug report with
> the following information should be filed:
> 
> 1) failing compiler command,
> 2) details of the compiler (gcc -v), and
> 3) the preprocessed source for the failing command.
> 
> You can CC me on hppa bugs (danglin at gcc dot gnu dot org).

I know how to file gcc bugs.  I've just filed one.  I didn't
have time to try and reduce the testcase, and I can't try
different versions of g++ yet.  I've asked to have different
versions installed on paer.

The bug report is at:
http://gcc.gnu.org/PR40505


> It takes less than five minutes to generate the above information and
> file a bug report.

I've never been able to file any (non-automated) bug report in
5 minutes.  And if you don't even have direct access to the
hardware it takes longer.


Kurt

Re: HPPA and Squeeze

[Grant Grundler]

On Sat, Jun 20, 2009 at 07:48:38PM +0200, Kurt Roeckx wrote:
...
> I know how to file gcc bugs.  I've just filed one.  I didn't
> have time to try and reduce the testcase, and I can't try
> different versions of g++ yet.  I've asked to have different
> versions installed on paer.
> 
> The bug report is at:
> http://gcc.gnu.org/PR40505

Kurt - thanks for filing the bug.

> > It takes less than five minutes to generate the above information and
> > file a bug report.
> 
> I've never been able to file any (non-automated) bug report in
> 5 minutes.  And if you don't even have direct access to the
> hardware it takes longer.

I agree. I'm trying to build netgen here too and if the ICE is easy to
reproduce, can make that available to danglin and add to the bugreport.  

thanks again,
grant

Re: HPPA and Squeeze

[John David Anglin]

> > I've never been able to file any (non-automated) bug report in
> > 5 minutes.  And if you don't even have direct access to the
> > hardware it takes longer.
> 
> I agree. I'm trying to build netgen here too and if the ICE is easy to
> reproduce, can make that available to danglin and add to the bugreport.  

There's no problem reproducing the ICE.

I've pretty much localized the problem.  It's a GCC middle-end bug.
The problem is in passing a complex double from a thunk.  The hppa
specification says that values larger than 64 bits are passed by
reference in the 32-bit runtime.  However, the value is in a pair
of registers and not copied to memory.  This doesn't happen in calls
from normal functions because the value gets copied to a stack slot.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[John David Anglin]

> On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
> > Here is a list of packages that failed to build because of instability
> > on the buildds today:
> > package     | buildd   | error
> > qgit        | penalosa | make: *** [install] Segmentation fault
> > acpica-unix | peri     | make: *** [install] Segmentation fault
> 
> I had those random segfaults in make on paer too, until we switched to the
> UP kernel, at least from what I saw.

Based on my experience with building GCC, a recent UP kernel (e.g., 2.6.30)
will avoid the random segfault problem.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Grant Grundler]

On Sat, Jun 20, 2009 at 06:25:20PM -0400, John David Anglin wrote:
> > > I've never been able to file any (non-automated) bug report in
> > > 5 minutes.  And if you don't even have direct access to the
> > > hardware it takes longer.
> > 
> > I agree. I'm trying to build netgen here too and if the ICE is easy to
> > reproduce, can make that available to danglin and add to the bugreport.  
> 
> There's no problem reproducing the ICE.

Indeed...already failed for me.

> I've pretty much localized the problem.  It's a GCC middle-end bug.
> The problem is in passing a complex double from a thunk.  The hppa
> specification says that values larger than 64 bits are passed by
> reference in the 32-bit runtime.  However, the value is in a pair
> of registers and not copied to memory.  This doesn't happen in calls
> from normal functions because the value gets copied to a stack slot.

I'm slightly confused about "stack slot". Could the "pass by reference"
refer to the address in the stack?

Anyway, thanks for quickly tracking this down.

grant

> 
> Dave
> -- 
> J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
> National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[John David Anglin]

> > I've pretty much localized the problem.  It's a GCC middle-end bug.
> > The problem is in passing a complex double from a thunk.  The hppa
> > specification says that values larger than 64 bits are passed by
> > reference in the 32-bit runtime.  However, the value is in a pair
> > of registers and not copied to memory.  This doesn't happen in calls
> > from normal functions because the value gets copied to a stack slot.
> 
> I'm slightly confused about "stack slot". Could the "pass by reference"
> refer to the address in the stack?

The reference can refer to a location on the stack (region allocated
for locals).  However, values larger than 64 bits can't be passed in the
argument slots.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Carlos O'Donell]

On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarno<aurelien@aurel32.net> wrote:
> On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote:
>> On 06/16/2009 08:25 AM, Lucas Nussbaum wrote:
>>> On 15/06/09 at 11:31 -0600, Grant Grundler wrote:
>>> PS: if you want an HPPA-specific issue to play with,
>>> http://experimental.debian.net/fetch.php?&pkg=ruby1.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=raw
>>> might be a good candidate.
>>
>> In reality it's not (any longer) a hppa specific bug. It's a bug in ruby.
>> Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa.
>> The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable...
>>
>
> BTW, Carlos, could you please send me the latest version of your
> patches, so that we can actually do the switch with version 2.10?
>

The latest patches are now up.

Core glibc patch:
http://www.parisc-linux.org/~carlos/2009-06-20-glibc-hppa-nptl.diff

Ports glibc patch:
http://www.parisc-linux.org/~carlos/2009-06-20-glibc-ports-hppa-nptl.diff

No regressions in the testsuite for hppa-linux-gnu.

No failures in my custom testsuite for the transition.

However, the usability testing in a chroot + vnc is showing that some
applications are segfaulting. I've been looking into this today.

Cheers,
Carlos.

Re: HPPA and Squeeze

[Matthias Klose]

Luk Claes schrieb:
> Matthias Klose wrote:
>> Grant Grundler schrieb:
>>> On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
>>>> Grant Grundler wrote:
> 
>>>>> On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
> 
>>>>>     http://lists.debian.org/debian-release/2009/04/msg00303.html
>>>> Note that it's wrong to assume we will come with the answers.
>>> I was expecting a summary of specific issues from an organization
>>> that claims to operate transperently.  The hand waving is easy. But
>>> doesn't resolve problems and doesn't meet my expectation of an "open"
>>> organization that I've donated money, time, and materials to.
>> +1. dropping hppa as a release architecture was not communicated by the release
>> team at all.  I did spend some time to get gcj / default-jdk working on hppa,
>> and some money (buying a new disk for a hppa machine) to help this port.  The
>> time and the money could have spent better, if d-r would have better
>> communicated about their intent.
> 
> There are issues with the hppa port where the release team considered
> dropping it since 2005 communicated to the porter list...
> 
>> hppa is not in a good shape, but there are other architectures which are not
>> better (sparc, mips*) from a toolchain point of view. what about these?
> 
> I'm not aware of current toolchain issues on sparc and the issues on
> mips* still seem to be manageable, no?

sparc-biarch defaulting to 32bit isn't supported by upstream; there are requests
to move to v9 optimization by default, which requires some work in the compiler.
I don't plan to update this for upcoming GCC versions, and there's no interest
by upstream to help with this kind of setup. You can't buy v8 software for years
now, but afaik all our machines run 64bit kernels. Maybe it's time to
acknowledge this, remove sparc from the list of release architectures and go on
with sparc64?

there are currently binutils issues outstanding, reported upstream. plus the
non-availability of developer machines seems to be an issue. Sadly we don't have
the mips support for squeeze as we had for lenny.

>> there are issues pointed out and not addressed like the -dev / -headers packages
>>  built as binary independent packages just to save disk space, which have an
>> impact on "slow" architectures, and which are not addressed by the release team.
>> would the release team mind addressing these real issues, or should we drop
>> "slow" architectures as well?
> 
> Well, this Packages issue is clearly a responsability from the FTP Team
> and the Release Team would indeed be very happy to have that resolved.

So it seems to be ok to ignore an issue, if you can work around it? Fine, then
I'll build all compiler front ends from one source again.

  Matthias

Re: HPPA and Squeeze

[Kurt Roeckx]

On Fri, Jun 19, 2009 at 05:43:24PM +0200, Philipp Kern wrote:
> On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
> > Here is a list of packages that failed to build because of instability
> > on the buildds today:
> > package     | buildd   | error
> > qgit        | penalosa | make: *** [install] Segmentation fault
> > acpica-unix | peri     | make: *** [install] Segmentation fault
> 
> I had those random segfaults in make on paer too, until we switched to the
> UP kernel, at least from what I saw.

Did something change to peri?  I'm currently only seeing them on
penalosa.

Failed logs the past few days:
Jun 22 | wesnoth                | penalosa | quilt segfaults
Jun 22 | gitg                   | penalosa | quilt segfaults
Jun 23 | zita-convolver         | penalosa | quilt segfaults
Jun 25 | autodocksuite          | penalosa | make segfaults
Jun 26 | mpd                    | penalosa | find segfaults?
Jun 30 | scorched3d             | penalosa | make segfaults
Jun 30 | libtext-bibtex-perl    | penalosa | make segfaults
Jun 30 | gnome-chemistry-utils  | penalosa | libtool segfaults
Jul 01 | openmsx-catapult       | penalosa | make segfaults
Jul 01 | prima                  | penalosa | make segfaults
Jul 01 | fvwm                   | penalosa | gcc says as had a segfault
Jul 01 | cherokee               | penalosa | quilt segfaults
Jul 03 | vflib3		        | penalosa | make segfaults
Jul 03 | rpy2		        | penalosa | make segfaults
Jul 03 | debian-installer-utils | penalosa | make segfaults

On other that looks weird is, all also on penalosa:
- scid, seems to have been stuck in a "cp".
- postgresql-8.3, not sure what the error is
- building gnome-system-monitor, openssh-client failed to install
  in it's postinst script calling update-alternatives

And then there is glob2 that fails with:
/usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot reach 0000f9bf_memcpy@@GLIBC_2.2+0, recompile with -ffunction-sections
/usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot handle R_PARISC_PCREL17F for memcpy@@GLIBC_2.2
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status


Kurt

Re: HPPA and Squeeze

[Philipp Kern]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Fri, Jul 03, 2009 at 08:57:56PM +0200, Kurt Roeckx wrote:
> Did something change to peri?  I'm currently only seeing them on
> penalosa.

UP kernel, maybe?

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp Kern                        Debian Developer
: :' :  http://philkern.de                         Stable Release Manager
`. `'   xmpp:phil@0x539.de                         Wanna-Build Admin
  `-    finger pkern/key@db.debian.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: HPPA and Squeeze

[Kurt Roeckx]

On Fri, Jul 03, 2009 at 09:28:00PM +0200, Philipp Kern wrote:
> On Fri, Jul 03, 2009 at 08:57:56PM +0200, Kurt Roeckx wrote:
> > Did something change to peri?  I'm currently only seeing them on
> > penalosa.
> 
> UP kernel, maybe?

Both peri and penalosa run 2.6.29-2-parisc64-smp and from what I
can tell run on identical hardware.


Kurt

Re: HPPA and Squeeze

[John David Anglin]

> And then there is glob2 that fails with:
> /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot reach 0000f9bf_memcpy@@GLIBC_2.2+0, recompile with -ffunction-sections
> /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot handle R_PARISC_PCREL17F for memcpy@@GLIBC_2.2
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status

I couldn't duplicate the problem with binutils 2.19.1-1 and gcc-4.3
4.3.3-10, or with my own binutils build on two different systems.

The above shouldn't happen as the text size of FileManager.o is well below
the size where a 17-bit branch can't reach the stub table.  Possibly, the
stub table is full.  On the otherhand, the "0000f9bf_memcpy@@GLIBC_2.2+0"
string looks garbled.  So, this may be another form of the SMP memory
corruption that causes the segvs, particularly if it isn't reproducible
on the build system.

The suggestion to "recompile with -ffunction-sections" is somewhat
misleading.  While -ffunction-sections may help sometimes, in other
cases it may be necessary to play with the ld --stub-group-size=N
option, or to compile with -mlong-calls.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Kurt Roeckx]

On Sat, Jul 04, 2009 at 03:52:16PM -0400, John David Anglin wrote:
> > And then there is glob2 that fails with:
> > /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot reach 0000f9bf_memcpy@@GLIBC_2.2+0, recompile with -ffunction-sections
> > /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot handle R_PARISC_PCREL17F for memcpy@@GLIBC_2.2
> > /usr/bin/ld: final link failed: Bad value
> > collect2: ld returned 1 exit status
> 
> I couldn't duplicate the problem with binutils 2.19.1-1 and gcc-4.3
> 4.3.3-10, or with my own binutils build on two different systems.
> 
> The above shouldn't happen as the text size of FileManager.o is well below
> the size where a 17-bit branch can't reach the stub table.  Possibly, the
> stub table is full.  On the otherhand, the "0000f9bf_memcpy@@GLIBC_2.2+0"
> string looks garbled.  So, this may be another form of the SMP memory
> corruption that causes the segvs, particularly if it isn't reproducible
> on the build system.

It actually already failed twice on the same system with the same
error.  I've just let it retry again, we'll see if it fails again.

The log file show this is with:
gcc-4.3 4.3.3-13 / 4.3.3-11
binutils 2.19.1-1


Kurt

Re: HPPA and Squeeze

[Kurt Roeckx]

On Sat, Jul 04, 2009 at 11:03:01PM +0200, Kurt Roeckx wrote:
> On Sat, Jul 04, 2009 at 03:52:16PM -0400, John David Anglin wrote:
> > > And then there is glob2 that fails with:
> > > /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot reach 0000f9bf_memcpy@@GLIBC_2.2+0, recompile with -ffunction-sections
> > > /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot handle R_PARISC_PCREL17F for memcpy@@GLIBC_2.2
> > > /usr/bin/ld: final link failed: Bad value
> > > collect2: ld returned 1 exit status
> > 
> > I couldn't duplicate the problem with binutils 2.19.1-1 and gcc-4.3
> > 4.3.3-10, or with my own binutils build on two different systems.
> > 
> > The above shouldn't happen as the text size of FileManager.o is well below
> > the size where a 17-bit branch can't reach the stub table.  Possibly, the
> > stub table is full.  On the otherhand, the "0000f9bf_memcpy@@GLIBC_2.2+0"
> > string looks garbled.  So, this may be another form of the SMP memory
> > corruption that causes the segvs, particularly if it isn't reproducible
> > on the build system.
> 
> It actually already failed twice on the same system with the same
> error.  I've just let it retry again, we'll see if it fails again.

And it failed again with the same error, on peri now.


Kurt

Re: HPPA and Squeeze

[John David Anglin]

> On Fri, Jul 03, 2009 at 09:28:00PM +0200, Philipp Kern wrote:
> > On Fri, Jul 03, 2009 at 08:57:56PM +0200, Kurt Roeckx wrote:
> > > Did something change to peri?  I'm currently only seeing them on
> > > penalosa.
> > 
> > UP kernel, maybe?
> 
> Both peri and penalosa run 2.6.29-2-parisc64-smp and from what I
> can tell run on identical hardware.

I tried a SMP kernel (2.6.30.1 with the patch set posted earlier) on
my rp34404.  Fired up a GCC build.  It didn't take more than a few
minutes to trigger a couple of segvs in /bin/sh.  On the other hand,
I ran a UP version of 2.6.30 for more than a week without any major
problems.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Helge Deller]

On 07/05/2009 01:34 AM, John David Anglin wrote:
>> On Fri, Jul 03, 2009 at 09:28:00PM +0200, Philipp Kern wrote:
>>> On Fri, Jul 03, 2009 at 08:57:56PM +0200, Kurt Roeckx wrote:
>>>> Did something change to peri?  I'm currently only seeing them on
>>>> penalosa.
>>> UP kernel, maybe?
>> Both peri and penalosa run 2.6.29-2-parisc64-smp and from what I
>> can tell run on identical hardware.
>
> I tried a SMP kernel (2.6.30.1 with the patch set posted earlier) on
> my rp34404.  Fired up a GCC build.  It didn't take more than a few
> minutes to trigger a couple of segvs in /bin/sh.  On the other hand,
> I ran a UP version of 2.6.30 for more than a week without any major
> problems.

So, instead of just complaining, wouldn't it be useful if someone with
root access would install a UP kernel (and disable nscd) for the time
being on the build servers?
That way we all would avoid debian build problems and could concentrate
on solving the issues with the SMP kernel itself.

In the meantime, all (IMHO) major kernel patches have now been included
in Linus' 2.6.31-rc2 kernel and I plan to backport and send them to the
stable-kernel team for inclusion into 2.6.29 and 2.6.30 stable
kernel series.

Helge

Re: HPPA and Squeeze

[Jurij Smakov]

On Sun, Jul 05, 2009 at 11:06:52AM +0200, Helge Deller wrote:
> On 07/05/2009 01:34 AM, John David Anglin wrote:
>>> On Fri, Jul 03, 2009 at 09:28:00PM +0200, Philipp Kern wrote:
>>>> On Fri, Jul 03, 2009 at 08:57:56PM +0200, Kurt Roeckx wrote:
>>>>> Did something change to peri?  I'm currently only seeing them on
>>>>> penalosa.
>>>> UP kernel, maybe?
>>> Both peri and penalosa run 2.6.29-2-parisc64-smp and from what I
>>> can tell run on identical hardware.
>>
>> I tried a SMP kernel (2.6.30.1 with the patch set posted earlier) on
>> my rp34404.  Fired up a GCC build.  It didn't take more than a few
>> minutes to trigger a couple of segvs in /bin/sh.  On the other hand,
>> I ran a UP version of 2.6.30 for more than a week without any major
>> problems.
>
> So, instead of just complaining, wouldn't it be useful if someone with
> root access would install a UP kernel (and disable nscd) for the time
> being on the build servers?
> That way we all would avoid debian build problems and could concentrate
> on solving the issues with the SMP kernel itself.
>
> In the meantime, all (IMHO) major kernel patches have now been included
> in Linus' 2.6.31-rc2 kernel and I plan to backport and send them to the
> stable-kernel team for inclusion into 2.6.29 and 2.6.30 stable
> kernel series.

HPPA folks, can you please convert at least one buildd to a UP
configuration? I have another example of extreme buildd flakiness mentioned
in bug #529485. Adam C Powell IV <hazelsct@debian.org> writes:

  That's too bad.  I saw 6 attempts to do 3.0.0-X of which two passed the
  first try and four failed.  At that rate (1/3), it would take nine
  attempts to have a decent chance of passing both rounds (debug static
  and optimized shared/static).

HPPA is the only arch for which petsc failed to build, and currently this
blocks petsc transition.

Best regards,
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: HPPA and Squeeze

[Philipp Kern]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On Sun, Jul 05, 2009 at 02:44:31PM +0100, Jurij Smakov wrote:
> HPPA folks, can you please convert at least one buildd to a UP
> configuration? I have another example of extreme buildd flakiness mentioned
> in bug #529485. Adam C Powell IV <hazelsct@debian.org> writes:

Well, paer is UP already.  It's interesting though that one of the
peri/penalosa twins works fine with SMP and the other does not.

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp Kern                        Debian Developer
: :' :  http://philkern.de                         Stable Release Manager
`. `'   xmpp:phil@0x539.de                         Wanna-Build Admin
  `-    finger pkern/key@db.debian.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: HPPA and Squeeze

[John David Anglin]

> That way we all would avoid debian build problems and could concentrate
> on solving the issues with the SMP kernel itself.

The problem actually may be present in UP kernels.  I had a segv this
morning building GCC with a UP 2.6.30.1:

adave@mx3210:~/gnu/gcc/objdir/hppa-linux/libjava$ gdb -c core /bin/sh
GNU gdb (GDB) 6.8.50.20090510-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "hppa-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(no debugging symbols found)
BFD: Warning: /home/dave/gnu/gcc/objdir/hppa-linux/libjava/core is truncated: expected core file size >= 196608, found: 118784.
Reading symbols from /lib/ld.so.1...Reading symbols from /usr/lib/debug/lib/ld-2.9.so...done.
done.
Loaded symbols for /lib/ld.so.1
Reading symbols from /lib/libncurses.so.5...done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.9.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.9.so...done.
done.
Loaded symbols for /lib/libc.so.6
Core was generated by `/bin/sh -c /home/dave/gnu/gcc/gcc/mkinstalldirs `dirname gnu/java/locale/Locale'.
Program terminated with signal 11, Segmentation fault.
#0  _dl_map_object_deps (map=0x403d8880, preloads=0x40001398, npreloads=12, 
    trace_mode=0, open_mode=0) at dl-deps.c:224
224	dl-deps.c: No such file or directory.
	in dl-deps.c
(gdb) bt
#0  _dl_map_object_deps (map=0x403d8880, preloads=0x40001398, npreloads=12, 
    trace_mode=0, open_mode=0) at dl-deps.c:224
#1  0x403b9bd4 in dl_main (phdr=0x10034, phnum=<value optimized out>, 
    user_entry=<value optimized out>) at rtld.c:1780
#2  0x403cb898 in _dl_sysdep_start (start_argptr=<value optimized out>, 
    dl_main=@0x403d7566: 0x403b8fe4 <dl_main>) at ../elf/dl-sysdep.c:239
#3  0x403b785c in _dl_start_final (arg=0xbfff2020, info=0xbfff2348)
    at rtld.c:332
#4  0x403b7adc in _dl_start (arg=0xbfff2020) at rtld.c:560
#5  0x403b742c in _start () from /lib/ld.so.1
#6  0x403b742c in _start () from /lib/ld.so.1
#7  0x403b742c in _start () from /lib/ld.so.1
#8  0x403b742c in _start () from /lib/ld.so.1
#9  0x403b742c in _start () from /lib/ld.so.1
#10 0x403b742c in _start () from /lib/ld.so.1
#11 0x403b742c in _start () from /lib/ld.so.1
#12 0x403b742c in _start () from /lib/ld.so.1
#13 0x403b742c in _start () from /lib/ld.so.1
#14 0x403b742c in _start () from /lib/ld.so.1
#15 0x403b742c in _start () from /lib/ld.so.1
#16 0x403b742c in _start () from /lib/ld.so.1
^CQuit

For some reason, gdb does terminate the backtrace.  Recent versions
of gdb also complain about core file truncation.  Think the full stack
region is not being dumped.

As with most of the segvs that I have debugged in the past, the problem
occurs in the dynamic loader.

This is the tombstone:

Jul  5 04:07:31 mx3210 kernel: 
Jul  5 04:07:31 mx3210 kernel: do_page_fault() pid=22068 command='sh' type=15 address=0x00000004
Jul  5 04:07:31 mx3210 kernel: Jul  5 04:07:31 mx3210 kernel:      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
Jul  5 04:07:31 mx3210 kernel: PSW: 00000000000001000000000000001111 Not taintedJul  5 04:07:31 mx3210 kernel: r00-03  000000000004000f 00000000403d76a0 0000000
0403c2c23 00000000bfff2ac0
Jul  5 04:07:31 mx3210 kernel: r04-07  00000000403d76a0 000000000000000c 0000000
040001398 00000000403b0dc0
Jul  5 04:07:31 mx3210 kernel: r08-11  0000000000000000 0000000000000002 0000000
040000e88 00000000bfff2d08
Jul  5 04:07:31 mx3210 kernel: r12-15  000000004037e4b4 00000000bfff2c48 00000000403d76a0 0000000000000004
Jul  5 04:07:31 mx3210 kernel: r16-19  00000000bfff2c08 00000000bfff2bc8 00000000bfff2b88 00000000403d76a0
Jul  5 04:07:31 mx3210 kernel: r20-23  00000000bfff2d0f 0000000000000000 0000000040002000 0000000000000001
Jul  5 04:07:31 mx3210 kernel: r24-27  000000000000000c 0000000040001398 00000000400013a8 00000000000365e8
Jul  5 04:07:31 mx3210 kernel: r28-31  0000000000000000 0000000024242424 00000000bfff2e00 00000000403c45c3
Jul  5 04:07:31 mx3210 kernel: sr00-03  000000000000e800 000000000000e800 0000000000000000 000000000000e800
Jul  5 04:07:31 mx3210 kernel: sr04-07  000000000000e800 000000000000e800 000000000000e800 000000000000e800
Jul  5 04:07:31 mx3210 kernel: 
Jul  5 04:07:31 mx3210 kernel:       VZOUICununcqcqcqcqcqcrmunTDVZOUI
Jul  5 04:07:31 mx3210 kernel: FPSR: 00000000000000000000000000000000
Jul  5 04:07:31 mx3210 kernel: FPER1: 00000000
Jul  5 04:07:31 mx3210 kernel: fr00-03  0000000000000000 0000000000000000 0000000000000000 0000000000000000
Jul  5 04:07:31 mx3210 kernel: fr04-07  fffffffffffff000 0000000000000000 ffffffffffffff9c bff0000000000000
Jul  5 04:07:31 mx3210 kernel: fr08-11  0000000000000000 000000004055d400 0000000000000802 000000004055d400
Jul  5 04:07:31 mx3210 kernel: fr12-15  00000000401a7d6c 0000000000000000 00000000401a5e94 000000007f40c580
Jul  5 04:07:31 mx3210 kernel: fr16-19  000000007f40ab38 000000007f406c78 000000007f430000 000000007f430000
Jul  5 04:07:31 mx3210 kernel: fr20-23  000000004055d400 00000000404f8bcc 000000000000026a 0000003700000000
Jul  5 04:07:31 mx3210 kernel: fr24-27  0000000000000000 000000007f430000 000000004055d400 0000000000000803
Jul  5 04:07:31 mx3210 kernel: fr28-31  ffffffffffffffe9 000000007ec4bc88 000000004055d400 0000000000000803
Jul  5 04:07:31 mx3210 kernel: 
Jul  5 04:07:31 mx3210 kernel: IASQ: 000000000000e800 000000000000e800 IAOQ: 00000000403c2b03 00000000403c2b07
Jul  5 04:07:31 mx3210 kernel:  IIR: 0f88108c    ISR: 000000000000e800  IOR: 0000000000000004
Jul  5 04:07:31 mx3210 kernel:  CPU:        0   CR30: 00000002bf8fc000 CR31: 0000000040564000
Jul  5 04:07:31 mx3210 kernel:  ORIG_R28: 00000000407a55c8
Jul  5 04:07:31 mx3210 kernel:  IAOQ[0]: 00000000403c2b03
Jul  5 04:07:31 mx3210 kernel:  IAOQ[1]: 00000000403c2b07
Jul  5 04:07:31 mx3210 kernel:  RP(r2): 00000000403c2c23

$ disasm 0x0f88108c
   0:	0f 88 10 8c 	ldw 4(ret0),r12

(gdb) p/x $pc
$1 = 0x403c2b00
(gdb) disass 0x403c2af0 0x403c2b10
Dump of assembler code from 0x403c2af0 to 0x403c2b10:
0x403c2af0 <_dl_map_object_deps+396>:	cmpib,= 0,ret0,0x403c32c8 <_dl_map_object_deps+2404>
0x403c2af4 <_dl_map_object_deps+400>:	ldi 0,r11
0x403c2af8 <_dl_map_object_deps+404>:	ldw 34(r10),ret0
0x403c2afc <_dl_map_object_deps+408>:	ldw -30(r3),r21
0x403c2b00 <_dl_map_object_deps+412>:	ldw 4(ret0),r12
0x403c2b04 <_dl_map_object_deps+416>:	stw r21,18(r3)
0x403c2b08 <_dl_map_object_deps+420>:	ldw -34(r3),ret0
0x403c2b0c <_dl_map_object_deps+424>:	stw r12,20(r3)
End of assembler dump.
(gdb) p/x $r10
$2 = 0x40000e88
(gdb) p/x *($r10 + 0x34)
$3 = 0x0
(gdb) p/x $r10 + 0x34
$4 = 0x40000ebc
(gdb) x/32x $r10
0x40000e88:	0x4029b000	0x40000e78	0x4029e5fc	0x40001118
0x40000e98:	0x40000bf0	0x40000e88	0x00000000	0x400010dc
0x40000ea8:	0x00000000	0x4029e5fc	0x00000000	0x00000000
0x40000eb8:	0x00000000	0x00000000	0x00000000	0x00000000
0x40000ec8:	0x00000000	0x00000000	0x00000000	0x00000000
0x40000ed8:	0x00000000	0x00000000	0x00000000	0x00000000
0x40000ee8:	0x00000000	0x00000000	0x00000000	0x00000000
0x40000ef8:	0x00000000	0x00000000	0x00000000	0x00000000

(gdb) p **preloads
$7 = {l_addr = 1077391360, l_name = 0x40000bd8 "/lib/libncurses.so.5", 
  l_ld = 0x403b0d18, l_next = 0x40000e88, l_prev = 0x403d8180, 
  l_real = 0x40000bf0, l_ns = 0, l_libname = 0x40000e44, l_info = {0x0, 
  0x403b0d20, 0x403b0d70, 0x403b0d68, 0x403b0d40, 0x403b0d48, 0x403b0d50, 
  0x403b0d88, 0x403b0d90, 0x403b0d98, 0x403b0d58, 0x403b0d60, 0x403b0d30, 
  0x403b0d38, 0x403b0d28, 0x0, 0x0, 0x0, 0x0, 0x0, 0x403b0d78, 0x0, 0x0, 
  0x403b0d80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x403b0da8, 
  0x403b0da0, 0x0, 0x0, 0x0, 0x0, 0x403b0db8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
  0x0, 0x0, 0x403b0db0, 0x0 <repeats 26 times>}, l_phdr = 0x4037b034, 
  l_entry = 1077435232, l_phnum = 4, l_ldnum = 26, l_searchlist = {
  r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x40000e40, 
  r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0, 
  l_nbuckets = 521, l_gnu_bitmask_idxbits = 0, l_gnu_shift = 0, 
  l_gnu_bitmask = 0x0, {l_gnu_buckets = 0x4037b8e0, l_chain = 0x4037b8e0}, {
  l_gnu_chain_zero = 0x4037b0bc, l_buckets = 0x4037b0bc}, 
  l_direct_opencount = 0, l_type = lt_library, l_relocated = 0, 
  l_init_called = 0, l_global = 0, l_reserved = 1, l_phdr_allocated = 0, 
  l_soname_added = 0, l_faked = 0, l_need_tls_init = 0, l_used = 0, 
  l_auditing = 0, l_audit_any_plt = 0, l_removed = 0, l_contiguous = 1, 
  l_rpath_dirs = {dirs = 0x0, malloced = 0}, l_reloc_result = 0x0, 
  l_versyms = 0x0, l_origin = 0x40000e60 "/lib", l_map_start = 1077391360, 
  l_map_end = 1077616976, l_text_end = 1077616640, l_scope_mem = {0x403d89dc, 
  0x0, 0x0, 0x0}, l_scope_max = 4, l_scope = 0x40000da8, l_local_scope = {
  0x40000d4c, 0x0}, l_dev = 536937216, l_ino = 641363, l_runpath_dirs = {
  dirs = 0x0, malloced = 0}, l_initfini = 0x40001398, l_reldepsmax = 0, 
  l_reldeps = 0x0, l_feature_1 = 0, l_flags_1 = 0, l_flags = 0, l_idx = 0, 
  l_mach = {fptr_table_len = 0, fptr_table = 0x0}, l_lookup_cache = {
  sym = 0x0, type_class = 0, value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, 
  l_tls_initimage_size = 0, l_tls_blocksize = 0, l_tls_align = 0, 
  l_tls_firstbyte_offset = 0, l_tls_offset = 0, l_tls_modid = 0, 
  l_relro_addr = 0, l_relro_size = 0, l_serial = 2, l_audit = 0x40000e40}

Register $r10 contains the address of the next link map:
(gdb) p (*preloads)->l_next
$10 = (struct link_map *) 0x40000e88

(gdb) p *(*preloads)->l_next
$11 = {l_addr = 1076473856, l_name = 0x40000e78 "/lib/libdl.so.2", 
  l_ld = 0x4029e5fc, l_next = 0x40001118, l_prev = 0x40000bf0, 
  l_real = 0x40000e88, l_ns = 0, l_libname = 0x400010dc, l_info = {0x0, 
  0x4029e5fc, 0x0 <repeats 74 times>}, l_phdr = 0x4029b034, 
  l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
  r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x400010d8, 
  r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0, 
  l_nbuckets = 0, l_gnu_bitmask_idxbits = 0, l_gnu_shift = 0, 
  l_gnu_bitmask = 0x0, {l_gnu_buckets = 0x0, l_chain = 0x0}, {
  l_gnu_chain_zero = 0x0, l_buckets = 0x0}, l_direct_opencount = 0, 
  l_type = lt_library, l_relocated = 0, l_init_called = 0, l_global = 0, 
  l_reserved = 1, l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0, 
  l_need_tls_init = 0, l_used = 0, l_auditing = 0, l_audit_any_plt = 0, 
  l_removed = 0, l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0}, 
  l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x400010f8 "/lib", 
  l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240, 
  l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4, 
  l_scope = 0x40001040, l_local_scope = {0x40000fe4, 0x0}, l_dev = 536937216, 
  l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0}, 
  l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0, 
  l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0, 
  fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0, 
  value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0, 
  l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0, 
  l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0, 
  l_serial = 3, l_audit = 0x400010d8}

(gdb) p &(*preloads)->l_next->l_info
$14 = (Elf32_Dyn *(*)[76]) 0x40000ea8
(gdb) p (*preloads)->l_next->l_info
$15 = {0x0, 0x4029e5fc, 0x0 <repeats 74 times>}
(gdb) p/x 0x40000ea8 + 5 * 4
$17 = 0x40000ebc

So, the segmentation fault was caused by a 0x0 in the l_info field of
the link map for "/lib/libdl.so.2".

elf.h:#define DT_STRTAB	5		/* Address of string table */

This is the code that causes the segv:

          const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);

$ readelf -a /lib/libdl.so.2
...
Dynamic section at offset 0x25fc contains 27 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x00000001 (NEEDED)                     Shared library: [ld.so.1]
 0x0000000e (SONAME)                     Library soname: [libdl.so.2]
 0x0000000c (INIT)                       0xc9c
 0x0000000d (FINI)                       0x20bc
 0x00000019 (INIT_ARRAY)                 0x3590
 0x0000001b (INIT_ARRAYSZ)               4 (bytes)
 0x00000004 (HASH)                       0x2168
 0x6ffffef5 (GNU_HASH)                   0x134
 0x00000005 (STRTAB)                     0x47c

It would appear there should be a string table.

Carlos, what do you think?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[John David Anglin]

> Register $r10 contains the address of the next link map:
> (gdb) p (*preloads)->l_next
> $10 = (struct link_map *) 0x40000e88
> 
> (gdb) p *(*preloads)->l_next
> $11 = {l_addr = 1076473856, l_name = 0x40000e78 "/lib/libdl.so.2", 
>   l_ld = 0x4029e5fc, l_next = 0x40001118, l_prev = 0x40000bf0, 
>   l_real = 0x40000e88, l_ns = 0, l_libname = 0x400010dc, l_info = {0x0, 
>   0x4029e5fc, 0x0 <repeats 74 times>}, l_phdr = 0x4029b034, 
>   l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
>   r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x400010d8, 
>   r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0, 
>   l_nbuckets = 0, l_gnu_bitmask_idxbits = 0, l_gnu_shift = 0, 
>   l_gnu_bitmask = 0x0, {l_gnu_buckets = 0x0, l_chain = 0x0}, {
>   l_gnu_chain_zero = 0x0, l_buckets = 0x0}, l_direct_opencount = 0, 
>   l_type = lt_library, l_relocated = 0, l_init_called = 0, l_global = 0, 
>   l_reserved = 1, l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0, 
>   l_need_tls_init = 0, l_used = 0, l_auditing = 0, l_audit_any_plt = 0, 
>   l_removed = 0, l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0}, 
>   l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x400010f8 "/lib", 
>   l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240, 
>   l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4, 
>   l_scope = 0x40001040, l_local_scope = {0x40000fe4, 0x0}, l_dev = 536937216, 
>   l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0}, 
>   l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0, 
>   l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0, 
>   fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0, 
>   value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0, 
>   l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0, 
>   l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0, 
>   l_serial = 3, l_audit = 0x400010d8}

When I run the command directly under gdb, the info is a different location
and the string table entry is not null:

(gdb) bt
#0  _dl_map_object_deps (map=0x403d8880, preloads=0x40001170, npreloads=12, 
    trace_mode=0, open_mode=0) at dl-deps.c:224
#1  0x403b9bd4 in dl_main (phdr=0x10034, phnum=<value optimized out>, 
    user_entry=<value optimized out>) at rtld.c:1780
#2  0x403cb898 in _dl_sysdep_start (start_argptr=<value optimized out>, 
    dl_main=@0x403d7566: 0x403b8fe4 <dl_main>) at ../elf/dl-sysdep.c:239
#3  0x403b785c in _dl_start_final (arg=0xbff01028, info=0xbff01188)
    at rtld.c:332
#4  0x403b7adc in _dl_start (arg=0xbff01028) at rtld.c:560

(gdb) p *(*preloads)->l_next
$2 = {l_addr = 1076473856, l_name = 0x40000c50 "/lib/libdl.so.2", 
  l_ld = 0x4029e5fc, l_next = 0x40000ef0, l_prev = 0x400009c8, 
  l_real = 0x40000c60, l_ns = 0, l_libname = 0x40000eb4, l_info = {0x0, 
  0x4029e604, 0x4029e66c, 0x4029e664, 0x4029e634, 0x4029e644, 0x4029e64c, 
  0x4029e684, 0x4029e68c, 0x4029e694, 0x4029e654, 0x4029e65c, 0x4029e614, 
  0x4029e61c, 0x4029e60c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4029e674, 0x0, 0x0, 
  0x4029e67c, 0x0, 0x4029e624, 0x0, 0x4029e62c, 0x0, 0x0, 0x0, 0x0, 0x0, 
  0x0, 0x4029e6b4, 0x4029e6ac, 0x4029e6a4, 0x4029e69c, 0x0, 0x0, 0x4029e6c4, 
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4029e6bc, 
  0x0 <repeats 25 times>, 0x4029e63c}, l_phdr = 0x4029b034, 
  l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
  r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x40000eb0, 
  r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0, 
  l_nbuckets = 22, l_gnu_bitmask_idxbits = 3, l_gnu_shift = 7, 
  l_gnu_bitmask = 0x4029b144, {l_gnu_buckets = 0x4029b154, 
  l_chain = 0x4029b154}, {l_gnu_chain_zero = 0x4029b148, 
  l_buckets = 0x4029b148}, l_direct_opencount = 0, l_type = lt_library, 
  l_relocated = 0, l_init_called = 0, l_global = 0, l_reserved = 1, 
  l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0, l_need_tls_init = 0, 
  l_used = 0, l_auditing = 0, l_audit_any_plt = 0, l_removed = 0, 
  l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0}, 
  l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x40000ed0 "/lib", 
  l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240, 
  l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4, 
  l_scope = 0x40000e18, l_local_scope = {0x40000dbc, 0x0}, l_dev = 536937216, 
  l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0}, 
  l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0, 
  l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0, 
  fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0, 
  value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0, 
  l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0, 
  l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0, 
  l_serial = 3, l_audit = 0x40000eb0}

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[John David Anglin]

> (gdb) p *(*preloads)->l_next
> $11 = {l_addr = 1076473856, l_name = 0x40000e78 "/lib/libdl.so.2", 
>   l_ld = 0x4029e5fc, l_next = 0x40001118, l_prev = 0x40000bf0, 
>   l_real = 0x40000e88, l_ns = 0, l_libname = 0x400010dc, l_info = {0x0, 
>   0x4029e5fc, 0x0 <repeats 74 times>}, l_phdr = 0x4029b034, 
>   l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
>   r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x400010d8, 
>   r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0, 
>   l_nbuckets = 0, l_gnu_bitmask_idxbits = 0, l_gnu_shift = 0, 
>   l_gnu_bitmask = 0x0, {l_gnu_buckets = 0x0, l_chain = 0x0}, {
>   l_gnu_chain_zero = 0x0, l_buckets = 0x0}, l_direct_opencount = 0, 
>   l_type = lt_library, l_relocated = 0, l_init_called = 0, l_global = 0, 
>   l_reserved = 1, l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0, 
>   l_need_tls_init = 0, l_used = 0, l_auditing = 0, l_audit_any_plt = 0, 
>   l_removed = 0, l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0}, 
>   l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x400010f8 "/lib", 
>   l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240, 
>   l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4, 
>   l_scope = 0x40001040, l_local_scope = {0x40000fe4, 0x0}, l_dev = 536937216, 
>   l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0}, 
>   l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0, 
>   l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0, 
>   fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0, 
>   value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0, 
>   l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0, 
>   l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0, 
>   l_serial = 3, l_audit = 0x400010d8}
> 
> (gdb) p &(*preloads)->l_next->l_info
> $14 = (Elf32_Dyn *(*)[76]) 0x40000ea8
> (gdb) p (*preloads)->l_next->l_info
> $15 = {0x0, 0x4029e5fc, 0x0 <repeats 74 times>}
> (gdb) p/x 0x40000ea8 + 5 * 4
> $17 = 0x40000ebc
> 
> So, the segmentation fault was caused by a 0x0 in the l_info field of
> the link map for "/lib/libdl.so.2".

After staring at the dynamic loader code for a while, I think the following
mmap call in dl-load.c doesn't correctly map the info data for /lib/libdl.so.2.

        /* Remember which part of the address space this object uses.  */
	l->l_map_start = (ElfW(Addr)) __mmap ((void *) mappref, maplength,
					      c->prot,
					      MAP_COPY|MAP_FILE,
					      fd, c->mapoff);

The info data is near the end of the mapped segment.  The l_info field
is initialized by elf_get_dynamic_info from the dynamic data mapped
at l->ld.

I seem to recall that the kernel mmap implementation on hppa is somewhat
unique.

In the above call, mappref is NULL.  The kernel selects the map location.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Carlos O'Donell]

On Sun, Jul 5, 2009 at 1:19 PM, John David
Anglin<dave@hiauly1.hia.nrc.ca> wrote:
> Carlos, what do you think?

I think the dynamic linker is always the first to touch the mmap'd
file and therefore the most likely to fail if something is wrong in
our VM layer.

Cheers,
Carlos.

Re: HPPA and Squeeze

[Carlos O'Donell]

On Sun, Jul 5, 2009 at 7:07 PM, John David
Anglin<dave@hiauly1.hia.nrc.ca> wrote:
> After staring at the dynamic loader code for a while, I think the fol=
lowing
> mmap call in dl-load.c doesn't correctly map the info data for /lib/l=
ibdl.so.2.
>
> =A0 =A0 =A0 =A0/* Remember which part of the address space this objec=
t uses. =A0*/
> =A0 =A0 =A0 =A0l->l_map_start =3D (ElfW(Addr)) __mmap ((void *) mappr=
ef, maplength,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0c->prot,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0MAP_COPY|MAP_FILE,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0fd, c->mapoff);
>
> The info data is near the end of the mapped segment. =A0The l_info fi=
eld
> is initialized by elf_get_dynamic_info from the dynamic data mapped
> at l->ld.

Why do you think this is wrong?

> I seem to recall that the kernel mmap implementation on hppa is somew=
hat
> unique.

I don't recall anything, Kyle?

> In the above call, mappref is NULL. =A0The kernel selects the map loc=
ation.

Yes, that's probably correct, the loader is letting the kernel choose
the address, at this point we don't care where the library is loaded.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HPPA and Squeeze

[John David Anglin]

> > The info data is near the end of the mapped segment. =A0The l_info field
> > is initialized by elf_get_dynamic_info from the dynamic data mapped
> > at l->ld.
> 
> Why do you think this is wrong?

I don't know about the specifics.  My supposition is that we may not
be copying the entire segment depending on where the map is placed.

> > I seem to recall that the kernel mmap implementation on hppa is somewhat
> > unique.
> 
> I don't recall anything, Kyle?

This came up with respect to the GCC PCH implementation for parisc.  See
comments in host-hpux.h.  At the moment, we do have a PCH related bug.
See PR 39355.  While I know the problem is present in the PCH file, I
haven't been able to figure out how wrong data gets in the file.

> > In the above call, mappref is NULL. =A0The kernel selects the map locatio=
> n.
> 
> Yes, that's probably correct, the loader is letting the kernel choose
> the address, at this point we don't care where the library is loaded.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[James Bottomley]

On Sun, 2009-07-05 at 20:17 -0400, John David Anglin wrote:
> > > The info data is near the end of the mapped segment. =A0The l_info field
> > > is initialized by elf_get_dynamic_info from the dynamic data mapped
> > > at l->ld.
> > 
> > Why do you think this is wrong?
> 
> I don't know about the specifics.  My supposition is that we may not
> be copying the entire segment depending on where the map is placed.

Who is supposed to copy the segment?  The user or the kernel?

> > > I seem to recall that the kernel mmap implementation on hppa is somewhat
> > > unique.
> > 
> > I don't recall anything, Kyle?
> 
> This came up with respect to the GCC PCH implementation for parisc.  See
> comments in host-hpux.h.  At the moment, we do have a PCH related bug.
> See PR 39355.  While I know the problem is present in the PCH file, I
> haven't been able to figure out how wrong data gets in the file.

Do you have a bugzilla reference so we can take a look ... also, is this
likely a tool chain problem or a kernel one?  If it's a kernel one could
someone provide a description of what they think is going wrong?

James

Re: HPPA and Squeeze

[John David Anglin]

> On Sun, 2009-07-05 at 20:17 -0400, John David Anglin wrote:
> > > > The info data is near the end of the mapped segment. =A0The l_info field
> > > > is initialized by elf_get_dynamic_info from the dynamic data mapped
> > > > at l->ld.
> > > 
> > > Why do you think this is wrong?
> > 
> > I don't know about the specifics.  My supposition is that we may not
> > be copying the entire segment depending on where the map is placed.
> 
> Who is supposed to copy the segment?  The user or the kernel?

As far as I can tell, the kernel is responsible for mapping the segment.
Then, elf_get_dynamic_info processes the mapped data to generate the
l_info field in the link map.

The kernel has control over where the segment is mapped.  In as much
as the dependencies for /bin/sh are processed many times in a GCC
build, I have to think the problem relates to the placement or a
random problem with mmap.  There is a small possibility that the
processing of the data by elf_get_dynamic_info has a problem.

> > > > I seem to recall that the kernel mmap implementation on hppa is somewhat
> > > > unique.
> > > 
> > > I don't recall anything, Kyle?
> > 
> > This came up with respect to the GCC PCH implementation for parisc.  See
> > comments in host-hpux.h.  At the moment, we do have a PCH related bug.
> > See PR 39355.  While I know the problem is present in the PCH file, I
> > haven't been able to figure out how wrong data gets in the file.
> 
> Do you have a bugzilla reference so we can take a look ... also, is this
> likely a tool chain problem or a kernel one?  If it's a kernel one could
> someone provide a description of what they think is going wrong?

The bugzilla reference is <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355>.

Many of my comments in the PR are wrong.  See comment #47.  At this time,
I know that the data in the PCH file are wrong but I don't know why.  In
any case, I should not have mentioned the PCH bug.  It's probably a tool
chain bug.  The main point of the comment was that the hppa mmap implementation
differs from other implementations (MAP_PRIVATE is not reliable).  So, there
may be other issues.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[John David Anglin]

> On Sun, Jul 5, 2009 at 1:19 PM, John David
> Anglin<dave@hiauly1.hia.nrc.ca> wrote:
> > Carlos, what do you think?
> 
> I think the dynamic linker is always the first to touch the mmap'd
> file and therefore the most likely to fail if something is wrong in
> our VM layer.

>From the core dump, this is the data supposed processed by
elf_get_dynamic_info:

(gdb) x/64x l->l_ld
0x4029e5fc <.LC11+4>:	0x00000001	0x00000167	0x00000001	0x00000171
0x4029e60c <.LC11+20>:	0x0000000e	0x00000179	0x0000000c	0x00000c9c
0x4029e61c <.LC11+36>:	0x0000000d	0x000020bc	0x00000019	0x00003590
0x4029e62c <.LC11+52>:	0x0000001b	0x00000004	0x00000004	0x00002168
0x4029e63c <.LC11+68>:	0x6ffffef5	0x00000134	0x00000005	0x0000047c
0x4029e64c <.LC11+84>:	0x00000006	0x000001ec	0x0000000a	0x000001c8
0x4029e65c <.LC11+100>:	0x0000000b	0x00000010	0x00000003	0x000037fc
0x4029e66c <.LC11+116>:	0x00000002	0x0000015c	0x00000014	0x00000007
0x4029e67c <.LC11+132>:	0x00000017	0x00000b40	0x00000007	0x000007b0
0x4029e68c <.LC11+148>:	0x00000008	0x00000390	0x00000009	0x0000000c
0x4029e69c <.LC11+164>:	0x6ffffffc	0x00000698	0x6ffffffd	0x00000006

(gdb) p l->l_ld[9]
$15 = {d_tag = 5, d_un = {d_val = 1148, d_ptr = 1148}}
(gdb) p/x 1148
$16 = 0x47c

The numbers seem to match that printed by readelf.  So, maybe Carlos
is right and this is a VM issue.  Is it possible the code saw different
data (e.g., the mmap operation was not complete before the mmap call
returned)?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Randolph Chung]

>>>>> I seem to recall that the kernel mmap implementation on hppa is somewhat
>>>>> unique.
>>>>>           
>>>> I don't recall anything, Kyle?
>>>>         
>>> This came up with respect to the GCC PCH implementation for parisc.  See
>>> comments in host-hpux.h.  At the moment, we do have a PCH related bug.
>>> See PR 39355.  While I know the problem is present in the PCH file, I
>>> haven't been able to figure out how wrong data gets in the file.
>>>       
There are some limitations on hppa if a file is both opened for reading 
(via read()) and written to via a mmap'ed mapping. This came up a few 
years ago.

Does gcc do this?

randolph

Re: HPPA and Squeeze

[John David Anglin]

> >>>>> I seem to recall that the kernel mmap implementation on hppa is somewhat
> >>>>> unique.
> >>>>>           
> >>>> I don't recall anything, Kyle?
> >>>>         
> >>> This came up with respect to the GCC PCH implementation for parisc.  See
> >>> comments in host-hpux.h.  At the moment, we do have a PCH related bug.
> >>> See PR 39355.  While I know the problem is present in the PCH file, I
> >>> haven't been able to figure out how wrong data gets in the file.
> >>>       
> There are some limitations on hppa if a file is both opened for reading 
> (via read()) and written to via a mmap'ed mapping. This came up a few 
> years ago.
> 
> Does gcc do this?

Not that I am aware of.  The situation is essentially the reverse of
the above.  Data is written from a region of memory.  Then, in another
instance of gcc, it needs to be mmap'ed back to the same location in
memory.  In theory, it could be brought back to a different location
but this would require a fairly complex set of relocations.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Carlos O'Donell]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

On Mon, Jul 6, 2009 at 9:28 AM, John David
Anglin<dave@hiauly1.hia.nrc.ca> wrote:
> Not that I am aware of.  The situation is essentially the reverse of
> the above.  Data is written from a region of memory.  Then, in another
> instance of gcc, it needs to be mmap'ed back to the same location in
> memory.  In theory, it could be brought back to a different location
> but this would require a fairly complex set of relocations.

GCC does not read() and write to the mmap()'d file.

The dynamic loader uses MAP_DENYWRITE to avoid writing into the mmap()'d memory.

I will reiterate my point here that the dynamic linker the first user
of mmap in a newly started process, and the first program to read and
process data from the mmap'd files. Therefore the dynamic linker is
always the first to suffer if a mapped region of memory is not
correct.

What we need to do here is create a test case.

I tried this:

1. cp /lib/libc.so.6 original.so
2. cp /lib/libc.so.6 map.so
3. gcc -O2 -g -o test-mmap test-mmap.c
4. while true; do ./test-mmap ./original.so ./map.so; done;

The test mmap's a file and compares it to the original, aborting if
the comparison fails. I've yet to see it abort on my a500, and I've
run 20-30 instances of the test simultaneously. Then again I don't see
any serious segv's like others do (2.6.26-1-parisc64-smp).

What might be a better testcase?

Cheers,
Carlos.

[-- Attachment #2: test-mmap.c --]
[-- Type: text/x-csrc, Size: 1807 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h> /* mmap */
#include <sys/types.h> /* open */
#include <sys/stat.h> /* open */
#include <fcntl.h> /* open */
#include <unistd.h> /* lseek */

#define BMAX 4096

int 
main (int argc, char **argv)
{
  void *mappref;
  int fd, fdc;
  off_t maplength, index, j;
  char *original = argv[1], *copy = argv[2];
  char buf[BMAX], *mbuf;
  ssize_t ret;
  /* Open original file to compute size. We open the original
     file to simulate having the fd open before mmap as the
     dynamic loader does.  */
  fd = open (original, O_RDONLY);
  if (fd == -1)
    {
      perror ("open");
      abort ();
    }
  maplength = lseek (fd, 0, SEEK_END);
  if (fd == -1)
    {
      perror ("lseek");
      abort ();
    }
  /* Now mmap the open file. */
  mappref = mmap ((void *)mappref, 
		  maplength, 
		  PROT_READ | PROT_EXEC, 
		  MAP_PRIVATE | MAP_DENYWRITE | MAP_FILE, 
		  fd, 
		  0);
  if (mappref == (void *)-1)
    {
      perror ("mmap");
      abort ();
    }
  mbuf = (char *)mappref;
  /* Compare mmap to copy. */
  fdc = open (copy, O_RDONLY);
  if (fdc == -1)
    {
      perror ("open #2");
      abort ();
    }
  for (index = 0; index < maplength; index += BMAX)
    {
      ret = read (fdc, &buf[0], BMAX);
      if ((ret != BMAX) && (ret == -1))
        {
	  perror ("read");
	  abort ();
        }
      for (j = 0; ((j < BMAX) && ((index + j) < maplength)); j++)
        {
	  if (mbuf[index + j] != buf[j])
	    {
	      fprintf(stderr, "Mismatch at %ld, read %d, expected %d\n", 
			index + j, (unsigned int)mbuf[index + j], (unsigned int)buf[j]);
	      abort ();
	    }
	  if (DEBUG)
	    printf ("Match at %ld, read %d, expected %d\n",
			index + j, (unsigned int)mbuf[index + j], (unsigned int)buf[j]);
        }
    }
  return 0;
}

Re: HPPA and Squeeze

[John David Anglin]

> I will reiterate my point here that the dynamic linker the first user
> of mmap in a newly started process, and the first program to read and
> process data from the mmap'd files. Therefore the dynamic linker is
> always the first to suffer if a mapped region of memory is not
> correct.

That is true to a certain extent.  However, there are large portions
of code and initialized data that it doesn't touch.  I don't think
that I've ever seen an invalid instruction fault.  So, I'm not fully
convinced that we understand the cause of these segvs.

As far as I can tell, the mmap'd data appears correct (at least as
far as what was recorded in the core file).  What is wrong is the
l_info field in the linker map.  Prior to failing on processing
libdl.so.2, it had successfully processed itself and libncurses.so.5
(see NEEDED entries for /bin/sh).  There isn't a lot that happens
between mmap'ing the file and the access to the STRTAB entry in
the l_info field.  The NEEDED entry at l_info[1] seems ok in the
dump.

I doubt this is a TLB issue as the data is a long way from page
boundaries.  Possibly, there is a cache line issue in the mmap'd
file, or as I suggested before a race condition and the file isn't
fully mapped when the mmap call returns.  In any case, the extraction
of the dynamic data failed after doing the first NEEDED entry.

I have to think that this has something to do with the machine
being a rp3440 (large memory and cache).  I have never seen this
on my c3750 with 32-bit UP kernel.  Also, this was with a 64-bit
UP kernel.

> What we need to do here is create a test case.
> 
> I tried this:
> 
> 1. cp /lib/libc.so.6 original.so
> 2. cp /lib/libc.so.6 map.so
> 3. gcc -O2 -g -o test-mmap test-mmap.c
> 4. while true; do ./test-mmap ./original.so ./map.so; done;
> 
> The test mmap's a file and compares it to the original, aborting if
> the comparison fails. I've yet to see it abort on my a500, and I've
> run 20-30 instances of the test simultaneously. Then again I don't see
> any serious segv's like others do (2.6.26-1-parisc64-smp).
> 
> What might be a better testcase?

I typically run my GCC builds with `make -j 4'.  So, there's a mix
of other stuff actively running at any time.

I'll give the testcase a try tonight.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Kyle McMartin]

On Mon, Jul 06, 2009 at 02:45:37PM -0400, John David Anglin wrote:
> I have to think that this has something to do with the machine
> being a rp3440 (large memory and cache).  I have never seen this
> on my c3750 with 32-bit UP kernel.  Also, this was with a 64-bit
> UP kernel.
> 

If I remember correctly, there's still some issues with the L2 cache on
pa8800 that we haven't quite bothered to work out yet, since it's "good
enough" for now. James probably knows more. It would be interesting to
see if you could reproduce it with a UP 64-bit kernel on your C3750 to
discount the L2 problems.

regards, Kyle

Re: HPPA and Squeeze

[John David Anglin]

> If I remember correctly, there's still some issues with the L2 cache on
> pa8800 that we haven't quite bothered to work out yet, since it's "good
> enough" for now. James probably knows more. It would be interesting to
> see if you could reproduce it with a UP 64-bit kernel on your C3750 to
> discount the L2 problems.

Googling, I see Grant had trouble with RCU_TORTURE_TEST=y.  Probably,
I should test current kernel to see if the problem is still present.

I guess you are referring to this change:
http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/

I'm thinking we must be missing a flush...  Maybe in clear_user_page
as for copy_user_page?

Do the problematic debian buildd machines have pa8800/pa8900 processors?

My sense is that some change (probably to the core memory management
code) made the coherence issue worse post 2.6.22.x.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[dann frazier]

On Mon, Jul 06, 2009 at 09:47:09PM -0400, John David Anglin wrote:
> > If I remember correctly, there's still some issues with the L2 cache on
> > pa8800 that we haven't quite bothered to work out yet, since it's "good
> > enough" for now. James probably knows more. It would be interesting to
> > see if you could reproduce it with a UP 64-bit kernel on your C3750 to
> > discount the L2 problems.
> 
> Googling, I see Grant had trouble with RCU_TORTURE_TEST=y.  Probably,
> I should test current kernel to see if the problem is still present.
> 
> I guess you are referring to this change:
> http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/
> 
> I'm thinking we must be missing a flush...  Maybe in clear_user_page
> as for copy_user_page?
> 
> Do the problematic debian buildd machines have pa8800/pa8900 processors?

dannf@penalosa:~$ cat /proc/cpuinfo 
processor	  : 0
cpu family	  : PA-RISC 2.0
cpu 		  : PA8700 (PCX-W2)
cpu MHz		    : 750.000000
model		      : 9000/785/J6700
model name	      : Duet W2
hversion	      : 0x00005dd0
sversion	      : 0x00000491
I-cache		      	: 768 KB
D-cache			  : 1536 KB (WB, direct mapped)
ITLB entries		  : 240
DTLB entries		  : 240 - shared with ITLB
bogomips		  : 1495.04
software id		  : 2001606322


> My sense is that some change (probably to the core memory management
> code) made the coherence issue worse post 2.6.22.x.
> 
> Dave

-- 
dann frazier

Re: HPPA and Squeeze

[Carlos O'Donell]

On Mon, Jul 6, 2009 at 10:43 PM, dann frazier<dannf@dannf.org> wrote:
> dannf@penalosa:~$ cat /proc/cpuinfo
> processor =A0 =A0 =A0 =A0 : 0
> cpu family =A0 =A0 =A0 =A0: PA-RISC 2.0
> cpu =A0 =A0 =A0 =A0 =A0 =A0 =A0 : PA8700 (PCX-W2)
> cpu MHz =A0 =A0 =A0 =A0 =A0 =A0 : 750.000000
> model =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 9000/785/J6700
> model name =A0 =A0 =A0 =A0 =A0 =A0: Duet W2
> hversion =A0 =A0 =A0 =A0 =A0 =A0 =A0: 0x00005dd0
> sversion =A0 =A0 =A0 =A0 =A0 =A0 =A0: 0x00000491
> I-cache =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 768 KB
> D-cache =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 1536 KB (WB, direct mapped)
> ITLB entries =A0 =A0 =A0 =A0 =A0 =A0 =A0: 240
> DTLB entries =A0 =A0 =A0 =A0 =A0 =A0 =A0: 240 - shared with ITLB
> bogomips =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: 1495.04
> software id =A0 =A0 =A0 =A0 =A0 =A0 =A0 : 2001606322

This is very similar to my own box. In frustration I've started
installing a buildd on my own a500. I might as well run a buildd to
load the machine and see if any of the reported package FTBS crop up.

Cheers,
Carlos.

Re: HPPA and Squeeze

[James Bottomley]

On Mon, 2009-07-06 at 21:47 -0400, John David Anglin wrote:
> > If I remember correctly, there's still some issues with the L2 cache on
> > pa8800 that we haven't quite bothered to work out yet, since it's "good
> > enough" for now. James probably knows more. It would be interesting to
> > see if you could reproduce it with a UP 64-bit kernel on your C3750 to
> > discount the L2 problems.
> 
> Googling, I see Grant had trouble with RCU_TORTURE_TEST=y.  Probably,
> I should test current kernel to see if the problem is still present.
> 
> I guess you are referring to this change:
> http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/
> 
> I'm thinking we must be missing a flush...  Maybe in clear_user_page
> as for copy_user_page?

Clear user page is very clever and doesn't need a flush.  What it does
is clear the page through the users cache rather than the kernel's ...
what it actually does is place zeros in the cache above the physical
page, so the user can only access the zeros ... they eventually get
cleaned back to the page as the cache empties.

> Do the problematic debian buildd machines have pa8800/pa8900 processors?

No boxes outside of the cupertino test ring and a few giveaways (you,
kyle and t-bone, I think) have pa88/8900 cpus.

> My sense is that some change (probably to the core memory management
> code) made the coherence issue worse post 2.6.22.x.

So if I characterise the problem you think you're seeing: on mmap of a
file at a memory location to be determined by the kernel, a sequential
set of reads of the mapped location eventually turns up a zero where
there should be data?  Yes, it does sound like a caching issue.

James

Re: HPPA and Squeeze

[James Bottomley]

On Mon, 2009-07-06 at 17:43 -0400, Kyle McMartin wrote:
> On Mon, Jul 06, 2009 at 02:45:37PM -0400, John David Anglin wrote:
> > I have to think that this has something to do with the machine
> > being a rp3440 (large memory and cache).  I have never seen this
> > on my c3750 with 32-bit UP kernel.  Also, this was with a 64-bit
> > UP kernel.
> > 
> 
> If I remember correctly, there's still some issues with the L2 cache on
> pa8800 that we haven't quite bothered to work out yet, since it's "good
> enough" for now. James probably knows more. It would be interesting to
> see if you could reproduce it with a UP 64-bit kernel on your C3750 to
> discount the L2 problems.

The pa8800/8900 are very special systems.  They have an L1/L2 VIPT cache
but an L2 PIPT one.  All other parisc systems have VIPT throughout.

The problem with the VIPT/PIPT combination is that you can get read only
stale alias resolution between the VIPT/PIPT hierarchy ... linux just
doesn't expect this to happen.  We work around this with extra flushes
in kmap to prevent the read only alias resolution from happening.
There's nothing missing in the logic of this, the only problem is that
its operation treats the vast L2 PIPT cache as a useless boat anchor
whose only job is to make life harder for us ... so we're getting
absolutely no benefit from the 25-50MB of cache there.

James

Re: HPPA and Squeeze

[John David Anglin]

> So if I characterise the problem you think you're seeing: on mmap of a
> file at a memory location to be determined by the kernel, a sequential
> set of reads of the mapped location eventually turns up a zero where
> there should be data?  Yes, it does sound like a caching issue.

Yes.  The loop is terminated by a null tag:

  while (dyn->d_tag != DT_NULL)
      {
         ...
      }

However, the core dump doesn't show a null tag before the STRTAB tag
that caused the segmentation fault.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Carlos O'Donell]

On Tue, Jul 7, 2009 at 12:21 PM, John David
Anglin<dave@hiauly1.hia.nrc.ca> wrote:
>> So if I characterise the problem you think you're seeing: on mmap of=
 a
>> file at a memory location to be determined by the kernel, a sequenti=
al
>> set of reads of the mapped location eventually turns up a zero where
>> there should be data? =A0Yes, it does sound like a caching issue.
>
> Yes. =A0The loop is terminated by a null tag:
>
> =A0while (dyn->d_tag !=3D DT_NULL)
> =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 ...
> =A0 =A0 =A0}
>
> However, the core dump doesn't show a null tag before the STRTAB tag
> that caused the segmentation fault.

Do you mean "after" the STRTAB tag? I assume the library on-disk has a
DT_NULL, otherwise it would always fail.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HPPA and Squeeze

[John David Anglin]

On Tue, 07 Jul 2009, Carlos O'Donell wrote:

> On Tue, Jul 7, 2009 at 12:21 PM, John David
> Anglin<dave@hiauly1.hia.nrc.ca> wrote:
> >> So if I characterise the problem you think you're seeing: on mmap =
of a
> >> file at a memory location to be determined by the kernel, a sequen=
tial
> >> set of reads of the mapped location eventually turns up a zero whe=
re
> >> there should be data? =A0Yes, it does sound like a caching issue.
> >
> > Yes. =A0The loop is terminated by a null tag:
> >
> > =A0while (dyn->d_tag !=3D DT_NULL)
> > =A0 =A0 =A0{
> > =A0 =A0 =A0 =A0 ...
> > =A0 =A0 =A0}
> >
> > However, the core dump doesn't show a null tag before the STRTAB ta=
g
> > that caused the segmentation fault.
>=20
> Do you mean "after" the STRTAB tag? I assume the library on-disk has =
a
> DT_NULL, otherwise it would always fail.

I'm sure that there is a null tag after the STRTAB.  The segmentation
fault occurred because the get operation failed after processing
the first NEEDED tag and before the STRTAB tag.  The loop goes
sequentially through the array of DT objects in the recently mmap'd
data and inserts pointers to these objects into the dynamic loaders
link map for the file (in the l_info field).  There were no null tags
between the NEEDED entry and the STRTAB entry in the mmap'd data in
the core dump.  The DT objects are near the end of the mmap'd data.

I would guess that the loop terminated early because the l_info array
is all zeros except for the first NEEDED entry.  It appears correct.  T=
he
loop might have terminated early because of a cache issue, or possibly
the value loaded from memory somehow got corrupted.  Another possibilit=
y
would be the mmap operation wasn't complete when the memory was examine=
d
by the dynamic loader.  When the core dump was done, the operation was
complete.

I think it's less likely that a cache issue affected the memory used by
the dynamic loader (l_info field) as the data before and after in the
map seemed reasonable.

The fact PA8700 processors are also experiencing similar problems
would seem to suggest that this isn't a PA8800 L2 issue unless we have
multiple problems.

I think we need to try running a recent kernel on gsyprf11 for a while
to see if we can capture a similar event.

Dave
--=20
J. David Anglin                                  dave.anglin@nrc-cnrc.g=
c.ca
National Research Council of Canada              (613) 990-0752 (FAX: 9=
52-6602)
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HPPA and Squeeze

[Carlos O'Donell]

On Tue, Jul 7, 2009 at 6:07 PM, John David
Anglin<dave@hiauly1.hia.nrc.ca> wrote:
> I would guess that the loop terminated early because the l_info array
> is all zeros except for the first NEEDED entry. =A0It appears correct=
=2E =A0The
> loop might have terminated early because of a cache issue, or possibl=
y
> the value loaded from memory somehow got corrupted. =A0Another possib=
ility
> would be the mmap operation wasn't complete when the memory was exami=
ned
> by the dynamic loader. =A0When the core dump was done, the operation =
was
> complete.
>
> I think it's less likely that a cache issue affected the memory used =
by
> the dynamic loader (l_info field) as the data before and after in the
> map seemed reasonable.
>
> The fact PA8700 processors are also experiencing similar problems
> would seem to suggest that this isn't a PA8800 L2 issue unless we hav=
e
> multiple problems.
>
> I think we need to try running a recent kernel on gsyprf11 for a whil=
e
> to see if we can capture a similar event.

This rang a bell...

In glibc/elf/rtld.c we have this:

  /* Partly clean the `bootstrap_map' structure up.  Don't use
     `memset' since it might not be built in or inlined and we cannot
     make function calls at this point.  Use '__builtin_memset' if we
     know it is available.  We do not have to clear the memory if we
     do not have to use the temporary bootstrap_map.  Global variables
     are initialized to zero by default.  */
#ifndef DONT_USE_BOOTSTRAP_MAP
# ifdef HAVE_BUILTIN_MEMSET
  __builtin_memset (bootstrap_map.l_info, '\0', sizeof (bootstrap_map.l=
_info));
# else
  for (size_t cnt =3D 0;
       cnt < sizeof (bootstrap_map.l_info) / sizeof (bootstrap_map.l_in=
fo[0]);
       ++cnt)
    bootstrap_map.l_info[cnt] =3D 0;
# endif

On hppa we don't have builtin memset (probably one of the few arches),
so we fall back on this weird loop which I always thought was wrong.

I was seeing problems with l_info having garbage in it, so I had a
local hack which cleared the entire bootstrap_map.

Did your l_info come from the bootstrap_map?

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HPPA and Squeeze

[John David Anglin]

> On Tue, Jul 7, 2009 at 6:07 PM, John David
> Anglin<dave@hiauly1.hia.nrc.ca> wrote:
> > I would guess that the loop terminated early because the l_info array
> > is all zeros except for the first NEEDED entry. =A0It appears correct. =
> =A0The
> > loop might have terminated early because of a cache issue, or possibly
> > the value loaded from memory somehow got corrupted. =A0Another possibilit=
> y
> > would be the mmap operation wasn't complete when the memory was examined
> > by the dynamic loader. =A0When the core dump was done, the operation was
> > complete.
> >
> > I think it's less likely that a cache issue affected the memory used by
> > the dynamic loader (l_info field) as the data before and after in the
> > map seemed reasonable.
> >
> > The fact PA8700 processors are also experiencing similar problems
> > would seem to suggest that this isn't a PA8800 L2 issue unless we have
> > multiple problems.
> >
> > I think we need to try running a recent kernel on gsyprf11 for a while
> > to see if we can capture a similar event.
> 
> This rang a bell...
> 
> In glibc/elf/rtld.c we have this:
> 
>   /* Partly clean the `bootstrap_map' structure up.  Don't use
>      `memset' since it might not be built in or inlined and we cannot
>      make function calls at this point.  Use '__builtin_memset' if we
>      know it is available.  We do not have to clear the memory if we
>      do not have to use the temporary bootstrap_map.  Global variables
>      are initialized to zero by default.  */
> #ifndef DONT_USE_BOOTSTRAP_MAP
> # ifdef HAVE_BUILTIN_MEMSET
>   __builtin_memset (bootstrap_map.l_info, '\0', sizeof (bootstrap_map.l_inf=
> o));
> # else
>   for (size_t cnt =3D 0;
>        cnt < sizeof (bootstrap_map.l_info) / sizeof (bootstrap_map.l_info[0=
> ]);
>        ++cnt)
>     bootstrap_map.l_info[cnt] =3D 0;
> # endif
> 
> On hppa we don't have builtin memset (probably one of the few arches),
> so we fall back on this weird loop which I always thought was wrong.
> 
> I was seeing problems with l_info having garbage in it, so I had a
> local hack which cleared the entire bootstrap_map.
> 
> Did your l_info come from the bootstrap_map?

No.  The l_info fields for the dynamic loader and libncurses.so.5
had already been processed.  The segv occurred processing the needed
entry for libdl.so.2.  The code was processing the needed entries
for /bin/sh.

The cause of the corruption that you observed is not obvious to
me.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: HPPA and Squeeze

[Aurelien Jarno]

On Sun, Jun 21, 2009 at 06:55:21PM -0400, Carlos O'Donell wrote:
> On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarno<aurelien@aurel32.net> wrote:
> > On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote:
> >> On 06/16/2009 08:25 AM, Lucas Nussbaum wrote:
> >>> On 15/06/09 at 11:31 -0600, Grant Grundler wrote:
> >>> PS: if you want an HPPA-specific issue to play with,
> >>> http://experimental.debian.net/fetch.php?&pkg=ruby1.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=raw
> >>> might be a good candidate.
> >>
> >> In reality it's not (any longer) a hppa specific bug. It's a bug in ruby.
> >> Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa.
> >> The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable...
> >>
> >
> > BTW, Carlos, could you please send me the latest version of your
> > patches, so that we can actually do the switch with version 2.10?
> >
> 
> The latest patches are now up.
> 
> Core glibc patch:
> http://www.parisc-linux.org/~carlos/2009-06-20-glibc-hppa-nptl.diff
> 
> Ports glibc patch:
> http://www.parisc-linux.org/~carlos/2009-06-20-glibc-ports-hppa-nptl.diff
> 
> No regressions in the testsuite for hppa-linux-gnu.
> 

I have just included these patches in the eglibc-2.10 branch of our SVN,
though currently the linuxthreads version is still built by default.

I got the following regressions in the NPTL build compared to the 
linuxthreads build:
| Encountered regressions that don't match expected failures:
| tst-cancelx20.out, Error 1
| tst-cancelx21.out, Error 1
| tst-cancelx4.out, Error 1
| tst-cancelx5.out, Error 1
| tst-cleanupx4.out, Error 1
| tst-cputimer1.out, Error 1
| tst-cputimer2.out, Error 1
| tst-cputimer3.out, Error 1
| tst-mqueue3.out, Error 1
| tststatic2.out, Error 1
| tststatic.out, Error 1
| tst-timer4.out, Error 1
| tst-timer5.out, Error 1
| tst-tls9-static.out, Error 1

Is it something expected?

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: HPPA and Squeeze

[Carlos O'Donell]

On Sun, Jul 12, 2009 at 8:30 AM, Aurelien Jarno<aurelien@aurel32.net> wrote:
> I have just included these patches in the eglibc-2.10 branch of our SVN,
> though currently the linuxthreads version is still built by default.
>
> I got the following regressions in the NPTL build compared to the
> linuxthreads build:
> | Encountered regressions that don't match expected failures:
> | tst-cancelx20.out, Error 1
> | tst-cancelx21.out, Error 1
> | tst-cancelx4.out, Error 1
> | tst-cancelx5.out, Error 1
> | tst-cleanupx4.out, Error 1

These are expected regressions

> | tst-cputimer1.out, Error 1
> | tst-cputimer2.out, Error 1
> | tst-cputimer3.out, Error 1
> | tst-mqueue3.out, Error 1

So are these.

> | tststatic2.out, Error 1
> | tststatic.out, Error 1

These are not.

> | tst-timer4.out, Error 1
> | tst-timer5.out, Error 1

These are.

> | tst-tls9-static.out, Error 1

This is not.

I'm building my own set of patches for debian-glibc, I'll tell you
what my results are when I finish today.

Cheers,
Carlos.

Re: HPPA and Squeeze

[Carlos O'Donell]

On Sun, Jul 12, 2009 at 10:52 AM, Carlos
O'Donell<carlos@systemhalted.org> wrote:
> I'm building my own set of patches for debian-glibc, I'll tell you
> what my results are when I finish today.

I had to restart the build last night, and it's building right now. I
should have test results within 2 hours.

I have trimmed debian-release from the CC.

Thanks.

Cheers,
Carlos.