[parisc-linux] PCXS fixes

[parisc-linux] PCXS fixes

[John Marvin]

I just committed some PCXS fixes, some of which were based on the ideas
posted here in the last week or so for 720 support.  One new fix is that I
program the Asp interrupts correctly, fixing a bug which was preventing
710's from booting (I think there is at least one person on this list
with such a machine).

However, ls still hangs randomly (actually it is not random, it depends on
which directory the ls is done in).  It gets stuck in a ldcw loop due to
the lock word not being 16 byte aligned.  The problem is that we fixed the
alignment problems for static and dynamic allocations, but the align
attribute is ignored for automatic (stack) allocations. Note that
although ldcw requires 16 byte alignment for correct function, it does
not cause an unaligned fault if the address is not aligned, it just
doesn't work correctly!

Here are some suggested fixes:

    1) Fix the compiler to honor the aligned attribute for stack
    allocations. I'm not sure how difficult this would be. I'm
    not a compiler person, so someone else would have to do this.
    I would guess that this problem is in the machine independent
    part of the compiler. I'm not sure whether or not it would
    be considered a bug. It might be worth writing a test for
    the 386 version of gcc, and if it fails, report the "bug" and
    see what happens ...

    2) Change the lock structure to have 4 contiguous lock words, each
    initialized to 1.  Then the lock code can round the address up to the
    nearest 16 byte aligned address and use that for the semaphore.  If we
    choose this solution we can just get rid of the aligned attribute,
    since it would no longer serve any purpose.


John Marvin
jsm@fc.hp.com

Re: [parisc-linux] PCXS fixes

[Jochen Friedrich]

Hi John,

> However, ls still hangs randomly (actually it is not random, it depends on
> which directory the ls is done in).  It gets stuck in a ldcw loop due to
> the lock word not being 16 byte aligned.

I have the same hangs here on my 720.

And a few more random problems i noticed:

- IPv6 doesn't work yet (this is a ping from 3ffe:400:470:4::1 Linux/alpha 
to 3ffe:400:470:4::3 Linux/parisc):

kernel BUG at /usr/src/linux/include/asm/checksum.h:153!
ICMPv6 checksum failed [3ffe:0400:0470:0004:0000:0000:0000:0001 > 
ff02:0000:0000:0000:0000:0001:ff00:0003]

- zebra complains about netlink problems and loops:

2001/10/03 17:17:51 ZEBRA: netlink-cmd recvmsg overrun

Cheers,
Jochen

Re: [parisc-linux] PCXS fixes

[Albert Strasheim]

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

Hello,

On Wed, 03 Oct 2001, John Marvin wrote:

<snip>

> However, ls still hangs randomly (actually it is not random, it depends on
> which directory the ls is done in).  It gets stuck in a ldcw loop due to
> the lock word not being 16 byte aligned.  The problem is that we fixed the
> alignment problems for static and dynamic allocations, but the align
> attribute is ignored for automatic (stack) allocations. Note that
> although ldcw requires 16 byte alignment for correct function, it does
> not cause an unaligned fault if the address is not aligned, it just
> doesn't work correctly!
> 
> Here are some suggested fixes:
> 
>     1) Fix the compiler to honor the aligned attribute for stack
>     allocations. I'm not sure how difficult this would be. I'm
>     not a compiler person, so someone else would have to do this.
>     I would guess that this problem is in the machine independent
>     part of the compiler. I'm not sure whether or not it would
>     be considered a bug. It might be worth writing a test for
>     the 386 version of gcc, and if it fails, report the "bug" and
>     see what happens ...
> 
>     2) Change the lock structure to have 4 contiguous lock words, each
>     initialized to 1.  Then the lock code can round the address up to the
>     nearest 16 byte aligned address and use that for the semaphore.  If we
>     choose this solution we can just get rid of the aligned attribute,
>     since it would no longer serve any purpose.

As anyone decided on what do here? What would the test that John
mentions entail? How difficult is the second solution to implement?

Regards,

Albert

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

Re: [parisc-linux] PCXS fixes

[Albert Strasheim]

Hello parisc,

Has anyone given any thought to how one would go about solving the
problem outlined below? I am quite anxious to get my 720/50 working
properly. :-)

Keep up the good work, hackers!

Regards,

Albert

On Sat, 06 Oct 2001, Albert Strasheim wrote:

> Hello,
> 
> On Wed, 03 Oct 2001, John Marvin wrote:
> 
> <snip>
> 
> > However, ls still hangs randomly (actually it is not random, it depends on
> > which directory the ls is done in).  It gets stuck in a ldcw loop due to
> > the lock word not being 16 byte aligned.  The problem is that we fixed the
> > alignment problems for static and dynamic allocations, but the align
> > attribute is ignored for automatic (stack) allocations. Note that
> > although ldcw requires 16 byte alignment for correct function, it does
> > not cause an unaligned fault if the address is not aligned, it just
> > doesn't work correctly!
> > 
> > Here are some suggested fixes:
> > 
> >     1) Fix the compiler to honor the aligned attribute for stack
> >     allocations. I'm not sure how difficult this would be. I'm
> >     not a compiler person, so someone else would have to do this.
> >     I would guess that this problem is in the machine independent
> >     part of the compiler. I'm not sure whether or not it would
> >     be considered a bug. It might be worth writing a test for
> >     the 386 version of gcc, and if it fails, report the "bug" and
> >     see what happens ...
> > 
> >     2) Change the lock structure to have 4 contiguous lock words, each
> >     initialized to 1.  Then the lock code can round the address up to the
> >     nearest 16 byte aligned address and use that for the semaphore.  If we
> >     choose this solution we can just get rid of the aligned attribute,
> >     since it would no longer serve any purpose.
> 
> As anyone decided on what do here? What would the test that John
> mentions entail? How difficult is the second solution to implement?
> 
> Regards,
> 
> Albert

Re: [parisc-linux] PCXS fixes

[Michael S.Zick]

On Wednesday 03 October 2001 03:32 am, John Marvin wrote:
> ... Note that
> although ldcw requires 16 byte alignment for correct function, it does
> not cause an unaligned fault if the address is not aligned, it just
> doesn't work correctly!
>
> Here are some suggested fixes:
>     1)  ...
>     2)  ...
>
John, Albert and Group;

I am working on a generalized solution as suggestion #3.  Diffs to follow RSN 
- as soon as I finish the coding and Albert gets it to run.

Mike

Re: [parisc-linux] PCXS fixes

[Jim Buttafuoco]

John,

I have a couple of 710's and would love to test if you can provide me 
with a kernel to net boot from.

Jim


> I just committed some PCXS fixes, some of which were based on the 
ideas
> posted here in the last week or so for 720 support.  One new fix is 
that I
> program the Asp interrupts correctly, fixing a bug which was 
preventing
> 710's from booting (I think there is at least one person on this list
> with such a machine).
> 
> However, ls still hangs randomly (actually it is not random, it 
depends on
> which directory the ls is done in).  It gets stuck in a ldcw loop due 
to
> the lock word not being 16 byte aligned.  The problem is that we 
fixed the
> alignment problems for static and dynamic allocations, but the align
> attribute is ignored for automatic (stack) allocations. Note that
> although ldcw requires 16 byte alignment for correct function, it does
> not cause an unaligned fault if the address is not aligned, it just
> doesn't work correctly!
> 
> Here are some suggested fixes:
> 
>     1) Fix the compiler to honor the aligned attribute for stack
>     allocations. I'm not sure how difficult this would be. I'm
>     not a compiler person, so someone else would have to do this.
>     I would guess that this problem is in the machine independent
>     part of the compiler. I'm not sure whether or not it would
>     be considered a bug. It might be worth writing a test for
>     the 386 version of gcc, and if it fails, report the "bug" and
>     see what happens ...
> 
>     2) Change the lock structure to have 4 contiguous lock words, each
>     initialized to 1.  Then the lock code can round the address up to 
the
>     nearest 16 byte aligned address and use that for the semaphore.  
If we
>     choose this solution we can just get rid of the aligned attribute,
>     since it would no longer serve any purpose.
> 
> 
> John Marvin
> jsm@fc.hp.com
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/cgi-bin/mailman/listinfo/parisc-linux
> 
>