Jesse Brandeburg | 3 Mar 06:19 2011
Picon

Re: [E1000-devel] [PATCH] e1000: Allow the driver to be used on PA RISC C8000 workstation

On Mon, Feb 28, 2011 at 5:40 AM, Guy Martin <gmsoft <at> tuxicoman.be> wrote:
>
> Hi Jeff,
>
> Any luck getting this into mainline ?

Hi Guy, sorry for the delay,
We haven't been able to get our contacts in HP to give us a decent
response so far, we are following up with them to see whats up.  We
have not lost the patch and are still tracking it internally.

Give us a couple more weeks if that is okay and we should be able to
settle this by then.

> Regards,
>  Guy
>
> On Tue, 7 Dec 2010 05:48:55 -0800
> "Kirsher, Jeffrey T" <jeffrey.t.kirsher <at> intel.com> wrote:
>
> > I will add it to my tree/queue.
> >
> > Cheer,
> > Jeff
> >
> >
> >  -----Original Message-----
> > From:         Kyle McMartin [mailto:kyle <at> mcmartin.ca]
> > Sent: Monday, December 06, 2010 08:12 AM US Mountain Standard
> > Time To:      Guy Martin
(Continue reading)

John David Anglin | 12 Mar 18:08 2011
Picon

[parisc] [PATCH] timer_interrupt: Fix "SLOW!" warning on rp3440

The attached change fixes the "SLOW!" timer_interrupt warning that I
occassionally see on my rp3440 (800 MHz).  We need to avoid using the
expensive div/mul method.  I have seen instances where it takes more
than 0x7000 cycles.

Signed-off-by: John David Anglin  <dave.anglin <at> nrc-cnrc.gc.ca>

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

diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
index 05511cc..63071c4 100644
--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
 <at>  <at>  -76,7 +76,7  <at>  <at>  irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id)

 	cycles_elapsed = now - next_tick;

-	if ((cycles_elapsed >> 6) < cpt) {
+	if ((cycles_elapsed >> 7) < cpt) {
 		/* use "cheap" math (add/subtract) instead
 		 * of the more expensive div/mul method
 		 */
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

James Bottomley | 12 Mar 21:59 2011

Re: [parisc] [PATCH] timer_interrupt: Fix "SLOW!" warning on rp3440

On Sat, 2011-03-12 at 12:08 -0500, John David Anglin wrote:
> The attached change fixes the "SLOW!" timer_interrupt warning that I
> occassionally see on my rp3440 (800 MHz).  We need to avoid using the
> expensive div/mul method.  I have seen instances where it takes more
> than 0x7000 cycles.

> Signed-off-by: John David Anglin  <dave.anglin <at> nrc-cnrc.gc.ca>
> 
> Dave

Your change implies that more than 2^6 == 64 ticks (that's over half a
second) can have elapsed between two calls to timer_interrupt().  That
looks like an awfully large lacuna, and is like the cause of whatever
problem you're seeing rather than the use of divide.  Parisc even has
the DS instruction that would seem to make division not so expensive.

How much more expensive is div than mul?  because if it's a lot more, we
can use a logarithmic iteration to do the division.

James

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

Meelis Roos | 12 Mar 23:08 2011
Picon

compile failure: pacache.S and .size

This is todays 2.6.38-rc8+git on hppa64 with
(GNU Binutils for Debian) 2.21.0.20110302. Have not tried to build an 
earlier kernel with this binutils so I do not knwo if this is a 
regression but it looks more like a problem found by new binutils.

  AS      arch/parisc/kernel/pacache.o
arch/parisc/kernel/pacache.S: Assembler messages:
arch/parisc/kernel/pacache.S:1071: Error: .size expression does not evaluate to a constant

pacache.S line 1071 ends procedure disable_sr_hashing_asm and does seem 
to do it in normal way and without typos.

        .procend
ENDPROC(disable_sr_hashing_asm)

        .end

This preprocesses to

 .procend
.size disable_sr_hashing_asm, .-disable_sr_hashing_asm

 .end

and this seems fully normal to me. Other functions assemble fine here 
but the last one in file.

--

-- 
Meelis Roos (mroos <at> linux.ee)
--
(Continue reading)

John David Anglin | 13 Mar 00:36 2011
Picon

Re: [parisc] [PATCH] timer_interrupt: Fix "SLOW!" warning on rp3440

> 
> On Sat, 2011-03-12 at 12:08 -0500, John David Anglin wrote:
> > The attached change fixes the "SLOW!" timer_interrupt warning that I
> > occassionally see on my rp3440 (800 MHz).  We need to avoid using the
> > expensive div/mul method.  I have seen instances where it takes more
> > than 0x7000 cycles.
> 
> > Signed-off-by: John David Anglin  <dave.anglin <at> nrc-cnrc.gc.ca>
> > 
> > Dave
> 
> Your change implies that more than 2^6 == 64 ticks (that's over half a
> second) can have elapsed between two calls to timer_interrupt().  That
> looks like an awfully large lacuna, and is like the cause of whatever
> problem you're seeing rather than the use of divide.  Parisc even has
> the DS instruction that would seem to make division not so expensive.

No, it's not ticks.  It's cycles.  One cycle is 1/800000000 of a second
on my rp3440, so another factor of two didn't seem that expensive.  I
think the change is ok even on a 75 MHz machine.

> How much more expensive is div than mul?  because if it's a lot more, we
> can use a logarithmic iteration to do the division.

I agree that there are probably better ways to do the caculation.  I'm
not sure of the exact numbers but div is always significantly more
expensive than multiplication.  The current code probably divides twice.

If one is willing to save a couple fp regs, 32-bit hardware multiplication
is available.
(Continue reading)

John David Anglin | 13 Mar 01:03 2011
Picon

Re: compile failure: pacache.S and .size

On Sun, 13 Mar 2011, Meelis Roos wrote:

> This preprocesses to
> 
>  .procend
> .size disable_sr_hashing_asm, .-disable_sr_hashing_asm
> 
>  .end

It looks to me like someone may have removed the necessary whitespace before
.size in linkage.h.  It may now be necessary for parisc to define its own
version of END.  Don't think this has anything to do with binutils.

Dave
--

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

Meelis Roos | 13 Mar 01:38 2011
Picon

Re: compile failure: pacache.S and .size

> > This preprocesses to
> > 
> >  .procend
> > .size disable_sr_hashing_asm, .-disable_sr_hashing_asm
> > 
> >  .end
> 
> It looks to me like someone may have removed the necessary whitespace before
> .size in linkage.h.  It may now be necessary for parisc to define its own
> version of END.  Don't think this has anything to do with binutils.

But the defines of ENDPROC and END in linkage.h are from 2006, commit 
ab7efcc9 from Jan Beulich. This has not changed, binutils has, thus my 
idea about binutils difference. However, I do not have the old binutils 
package easyly availbale right now so I can not test that today.

--

-- 
Meelis Roos (mroos <at> linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

John David Anglin | 13 Mar 02:28 2011
Picon

Re: compile failure: pacache.S and .size

> > > This preprocesses to
> > > 
> > >  .procend
> > > .size disable_sr_hashing_asm, .-disable_sr_hashing_asm
> > > 
> > >  .end
> > 
> > It looks to me like someone may have removed the necessary whitespace before
> > .size in linkage.h.  It may now be necessary for parisc to define its own
> > version of END.  Don't think this has anything to do with binutils.
> 
> But the defines of ENDPROC and END in linkage.h are from 2006, commit 
> ab7efcc9 from Jan Beulich. This has not changed, binutils has, thus my 
> idea about binutils difference. However, I do not have the old binutils 
> package easyly availbale right now so I can not test that today.

I have not seen the problem with 2.21.51.20110218.  .size is handled
by generic code.  I find it hard to believe that .-disable_sr_hashing_asm
doesn't evaluate to a constant.  GCC always outputs a similar directive.
It would seem like almost every assembly would be broken if the problem
was with binutils.

Could you send preprocessed assembler file?

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
(Continue reading)

John David Anglin | 13 Mar 05:10 2011
Picon

Re: compile failure: pacache.S and .size

On Sun, 13 Mar 2011, Meelis Roos wrote:

> > > This preprocesses to
> > > 
> > >  .procend
> > > .size disable_sr_hashing_asm, .-disable_sr_hashing_asm
> > > 
> > >  .end
> > 
> > It looks to me like someone may have removed the necessary whitespace before
> > .size in linkage.h.  It may now be necessary for parisc to define its own
> > version of END.  Don't think this has anything to do with binutils.
> 
> But the defines of ENDPROC and END in linkage.h are from 2006, commit 
> ab7efcc9 from Jan Beulich. This has not changed, binutils has, thus my 
> idea about binutils difference. However, I do not have the old binutils 
> package easyly availbale right now so I can not test that today.

You are correct, there is a new error message for .size
http://sourceware.org/bugzilla/show_bug.cgi?id=12519
and the change was applied to the 2.21 branch.

The message was introduced because you can't size a function across
two sections.  It's not obvious why this is happening here.  So, I think
a binutils bug should be filed with preprocessed assembler.

Dave
--

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

Meelis Roos | 13 Mar 19:55 2011
Picon

Re: compile failure: pacache.S and .size

> You are correct, there is a new error message for .size
> http://sourceware.org/bugzilla/show_bug.cgi?id=12519
> and the change was applied to the 2.21 branch.
> 
> The message was introduced because you can't size a function across
> two sections.  It's not obvious why this is happening here.  So, I think
> a binutils bug should be filed with preprocessed assembler.

http://sourceware.org/bugzilla/show_bug.cgi?id=12579 - also hase the 
preprocessed file.

--

-- 
Meelis Roos (mroos <at> linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane