David S. Miller wrote:
> It's funny someone would post on debian-sparc trying to sound knowledgable
> and not even know that's he's engaged in conversation with the primary
> author of the Linux kernel support for Sparc.
To be fair to Paul, I have been on this list for over a year and did not
know
On Fri, 3 Oct 2003, Antonello wrote:
> And my dmesg remembers this to me at each boot (I have an HappyMeal Ethernet,
> so I can post this message on the Internet because of David) :)
H... David is (or has been) involved in quite a number of drivers:
-
[EMAIL PROTECTED] cd /usr/src/kernel
rking arch refers to sparc (not sparc64) in 2.6.0-test6 and is
completely wrong. It actually was a compound issue with gcc, then a
corrupted second stage loader. The wierd part was that another user I mail
to had the exact same problem, and wierdly enough, the exact same cause.
(Not quite SO wierd
On Friday 03 October 2003 17:00, David S. Miller wrote:
> It's funny someone would post on debian-sparc trying to sound knowledgable
> and not even know that's he's engaged in conversation with the primary
> author of the Linux kernel support for Sparc.
I did know it instead :). I read about it o
On Fri, 3 Oct 2003, Paul wrote:
> >All of the creator3D support I wrote is 32-bit and takes full advantage
> > of the UPA bandwidth. 64-bits or not makes no difference wrt. to this,
> > so your ignorance is showing again... The bus bandwidth of UPA
> > is 64-bytes in one transfer, not 64-bits.
<[EMAIL PROTECTED]>; "David S. Miller"
Cc:
Sent: Friday, October 03, 2003 8:57 AM
Subject: Re: 2.6.0-test6
> "Paul" wrote:
> > I'm not saying that 32 bit is right for everyone, I am saying that for
> what
> > I do, it would give me a noticeable
On Fri, 3 Oct 2003 09:45:39 -0500
"Paul" <[EMAIL PROTECTED]> wrote:
> http://docs.sun.com/db/doc/805-7764-12/6j7a77hhh?a=view#z400010a55fa
> "The UPA 64-bit data bus provides the connection between the CPU module and
> the UPA graphics. The 64-bit UPA data shares the data bus with memory
> through
like to see how it runs on my SS20. Maybe
I'll switch from Solaris/Linux/NetBSD.
Maybe I'm just an old fogey who remembers the days when you tried to wring
out the performance by aligning software as closely to hardware as possible.
Maybe I think it's strange/inelegant to have a nonwo
"Paul" wrote:
> I'm not saying that 32 bit is right for everyone, I am saying that for
what
> I do, it would give me a noticeable and measurable boost in speed.
> Again, if I'm wrong, please explain to me how and/or why. I'm learning
every
> day, and I'll learn from anybody that can/will teach me.
On Fri, 2003-10-03 at 14:20, David S. Miller wrote:
[snip]
> The part I hate the most about threads like this is that if I don't
> waste my time sitting here correcting you, someone less knowledgable
> is going to read your posting and think there is some truth to it.
>
And I for one am gratefu
On Fri, 3 Oct 2003 08:02:43 -0500
"Paul" <[EMAIL PROTECTED]> wrote:
> Ok, I'll happily concede that 64 bit Sparcs are faster (in general) then 32
> bit sparcs. BUT, I think that has more to do with better/more
> [cache|architecture|MHz|optimizations|processor design] than with simple
> '64-bittedn
anybody that can/will teach me.
Thanks
Paul
P.S. This COULD all be a plot on my part to make sure my poor SS20 will
still be supported in 2.6! GRIN!
- Original Message -
From: "David S. Miller"
To: "Paul" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, October 03, 2003 7:06 A
On Fri, 3 Oct 2003 06:21:38 -0500
"Paul" <[EMAIL PROTECTED]> wrote:
> Let's see, the first and most obvious issue would be transferring 64 bit
> pointers per cycle instead of two 32 bit pointers in the same cycle. Sure,
> if I had a large enough data set, it would speed things up greatly.
But the
x27;cache
miss' performance hits, and again, we're back to transferring dbl the word
size we really need.
Please, if I've got this wrong, let me know, and please explain why. I'm not
being sarcastic, I really would like to know.
Thanks
Paul
- Original Message -
F
On Thu, 2 Oct 2003 18:57:43 -0500
"Paul" <[EMAIL PROTECTED]> wrote:
> Personally, I prefer 32 bit, all marketroid blathering to the contrary. If I
> had a huge database or was simulating weather/gnabgig/etc, then it'd be
> worthwhile. Otherwise, the overhead of 64 bit just isn't quite worth it to
Ben Collins" <[EMAIL PROTECTED]>
To: "Paul" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, October 02, 2003 5:48 PM
Subject: Re: 2.6.0-test6
> On Thu, Oct 02, 2003 at 04:54:07PM -0500, Paul wrote:
> > Ahh, but my goal is to have sparc32 running. I don't need 64 b
On Thu, Oct 02, 2003 at 04:54:07PM -0500, Paul wrote:
> Ahh, but my goal is to have sparc32 running. I don't need 64 bt, and I'd
> prefer not to have the overhead. I figure that sparc64 is a good place to
> start though. Not to mention the SS20 that I'm eventually going to have
> running deb.
>
>
- Original Message -
From: "Ben Collins" <[EMAIL PROTECTED]>
To: "Paul" <[EMAIL PROTECTED]>
Sent: Thursday, October 02, 2003 3:44 PM
Subject: Re: 2.6.0-test6
> On Thu, Oct 02, 2003 at 04:00:58PM -0500, Paul wrote:
> > 3.0r1 aka woody. It's a
A levelezÅm azt hiszi, hogy Ben Collins a következÅeket Ãrta:
> You never said what ver of Debian-sparc you are running. If you are
> using gcc-3, I hope you are using atleast 3.3.2.
Do we have a list of known to work and known not to work
packages? Especially of those which are needed to com
> I'm using gcc3 (ln -s) and it's stock sparc64 beyond that. The sparc port
> seems to have issues with gcc/register clobbers, I haven't dug up the patch
> for that.
You never said what ver of Debian-sparc you are running. If you are
using gcc-3, I hope you are using atleast 3.3.2.
> Biggest c
Well, I'm new here so a quick personal sparc
rundown:
SS20 Dual SM62's,
Ultra 1 170, Creator3d series 2, 2
qfe's
Ultra 10 440
Anyway, I've got 2.6.0-test6 to compile and boot,
and I thought I might pass along a couple of wierdnesses I stumbled across
(please no
21 matches
Mail list logo
