ServerWorks docs?

ServerWorks docs?

[Rico Tudor]

Does anyone have reference material for the ServerWorks northbridge?
I want to add their chipsets to my ECC-monitoring utility, but their
web site is little more than marketing drivel.  Plus, they don't respond
to e-mail.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ServerWorks docs?

[davej]

On 16 Dec 2000, Rico Tudor wrote:

> Does anyone have reference material for the ServerWorks northbridge?
> I want to add their chipsets to my ECC-monitoring utility, but their
> web site is little more than marketing drivel.  Plus, they don't respond
> to e-mail.

I've tried on several occasions, but not got anywhere.
Judging by the comments on the lm-sensors homepage, chances of them
publically releasing register level info seems pretty slim.

regards,

Davej.

-- 
| Dave Jones <davej@suse.de>  http://www.suse.de/~davej
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ServerWorks docs?

[J . A . Magallon]

On 2000/12/16 Rico Tudor wrote:
> Does anyone have reference material for the ServerWorks northbridge?
> I want to add their chipsets to my ECC-monitoring utility, but their
> web site is little more than marketing drivel.  Plus, they don't respond
> to e-mail.

I was about to tell you that you were in trouble, but there are news;
look at

http://www.netroedge.com/~lm78/

What I knew was November 30, but look at news from December.

-- 
Juan Antonio Magallon Lacarta                                 #> cd /pub
mailto:jamagallon@able.es                                     #> more beer

Linux werewolf 2.2.19-pre1 #1 SMP Fri Dec 15 22:25:20 CET 2000 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ServerWorks docs?

[Jeff Nguyen]

Serverworks wants to support the Linux community. Thus they are
willing to share certain information to developers without risking the IP.
Recently ASL has been working with Serverworks in supporting the
lm-sensor project and other Linux software developer.

Let me know if you need some help with the chipset information.

Jeff

ASL Inc.

----- Original Message -----
From: <davej@suse.de>
To: "Rico Tudor" <rico@patrec.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Saturday, December 16, 2000 12:00 PM
Subject: Re: ServerWorks docs?


> On 16 Dec 2000, Rico Tudor wrote:
>
> > Does anyone have reference material for the ServerWorks northbridge?
> > I want to add their chipsets to my ECC-monitoring utility, but their
> > web site is little more than marketing drivel.  Plus, they don't respond
> > to e-mail.
>
> I've tried on several occasions, but not got anywhere.
> Judging by the comments on the lm-sensors homepage, chances of them
> publically releasing register level info seems pretty slim.
>
> regards,
>
> Davej.
>
> --
> | Dave Jones <davej@suse.de>  http://www.suse.de/~davej
> | SuSE Labs
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ServerWorks docs?

[Dan Hollis]

On Sat, 16 Dec 2000 davej@suse.de wrote:
> On 16 Dec 2000, Rico Tudor wrote:
> > Does anyone have reference material for the ServerWorks northbridge?
> > I want to add their chipsets to my ECC-monitoring utility, but their
> > web site is little more than marketing drivel.  Plus, they don't respond
> > to e-mail.
> I've tried on several occasions, but not got anywhere.
> Judging by the comments on the lm-sensors homepage, chances of them
> publically releasing register level info seems pretty slim.

serverworks requires you not only to sign an NDA, but also do all
development on-site at their santa clara HQ under their direct
supervision.

I think it's rather stupid to have to take several days off work to fly
down to their HQ just for code that will take maybe 5 minutes to write.

If someone in santa clara wants to do it, fine.

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ServerWorks docs?

[Rico Tudor]

Thanks for the offer, but the basic problem remains: no docs.
As jamagallon@able.es noted, http://www.netroedge.com/~lm78/ shows some
cause for hope, but a medium-sized LART is still called for.

My interest in ServerWorks documentation is two-fold: first, to
expand chipset support in my ECC utility and second, to better support
ServerWorks-based machines in my workplace.

On behalf of the Linux community, I would sign NDA if it was civilized
and if my source remained, obviously, public-domain.  I could visit
ServerWorks on my next foray to the Bay Area.

More important to me is ready access to technical documentation to support
machines at work.  I come from the era when PDP-11's were shipped with
schematics, the OS, and the source to the OS.  Things have been going
downhill ever since.  I'm not catching the next plane to the Bay Area
for "eyes only" examination of a document every time a problem arises.
In this regard, companies like IBM Storage and Intel win my kudos,
and my dollars.  ServerWorks may get some of those dollars because they
have an affordable chipset that supports 4 GB, but that advantage can
change overnight.  It's not like IP has a long half-life these days,
unless you can corner the pyramid-building business.

These companies must evaluate their proprietary stance in relation to lost
sales, the more so as free source accelerates.  ATI, Matrox, Adaptec: need
we say more?  But then, I'm preaching to the choir.  Perhaps ServerWorks
should look into their hearts, and decide what small part of their IP
has enormous, eternal value -- the kind that will have them rolling in
dough, just like Scrooge McDuck.  The rest of the specification, like
the miserable ECC circuitry that's been done a million times before,
release it already!  Their adoring Linux fans are waiting.

P.S. I wonder if Via reads this list.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ServerWorks docs?

[Matthew Jacob]

Two points:

> More important to me is ready access to technical documentation to support
> machines at work.  I come from the era when PDP-11's were shipped with
> schematics, the OS, and the source to the OS.  Things have been going

The only source for the OS that came 'for free' that I can recall for the
PDP-11 was RSX-11- but that was only the bare kernel. The filesystem and the
utilities's source wwas not available. At that time, as you can probably well
recall, the UNIX source licence from WECO was 40K$ for v7 at Sidereal.

> downhill ever since.  I'm not catching the next plane to the Bay Area
> for "eyes only" examination of a document every time a problem arises.
> In this regard, companies like IBM Storage and Intel win my kudos,

Don't applaud either Intel or IBM too loudly. In particular, Intel. Just *try*
and get documentation about their frickin' gigabit ethernet chip out of them.


-matt


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

gettimeofday() non-monotonic on uniprocessor system with ntp turned off?

[Christopher Friesen]

I am having a little bit of a problem.  I'm on a single processor G4 system
running 2.2.17 and I do not have ntp turned on.  However, successive calls to
gettimeofday() occasionally return results that make it look as though time was
running backwards.  

To test this, I wrote a small program that does a loop and calls gettimeofday(),
comparing the result to the previous time around.  If the latest call is
"earlier" than the previous one, it prints both out as well as the difference
between the two.  Here is some of the results:

time1             time2             delta
977032354.149970  977032354.140019  0.009951
977032507.119949  977032507.110004  0.009945
977032806.429940  977032806.420004  0.009936
977032822.349971  977032822.340008  0.009963
977032989.739968  977032989.730015  0.009953
977033057.579978  977033057.570006  0.009972
977033065.269950  977033065.260023  0.009927
977033155.499958  977033155.490030  0.009928
977033205.799960  977033205.790029  0.009931
977033279.919965  977033279.910024  0.009941
977033367.589953  977033367.580008  0.009945
977033454.509977  977033454.500030  0.009947
977033457.359965  977033457.350003  0.009962
977033500.619954  977033500.610011  0.009943
977033509.679964  977033509.670020  0.009944
977033659.439972  977033659.430003  0.009969
977033842.399966  977033842.390019  0.009947
977034023.419976  977034023.410023  0.009953
977034026.019983  977034026.010011  0.009972
977034085.899979  977034085.890032  0.009947
977034176.219956  977034176.210013  0.009943
977034691.289969  977034691.280026  0.009943
977034845.569984  977034845.560024  0.009960

It appears that the problem happens only when the first time reading is very
close to the end of a jiffy period.  It almost seems like the microseconds value
rolls over to the new jiffy, then the program reads the value before the seconds
value catches up.  

Is this a known issue?  Has anyone fixed this already?  I'm kind of surprised
that something like this is still around.

Thanks,

Chris


-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ServerWorks docs?

[Jeff Nguyen]

Rico & Dan,

Below is the Email that Jim Forster of Serverworks sent to me:

          "We want to enable the Linux community as quickly as possible; we
agree with
            you that it makes business sense to do so.  Given the fact that
our IP is
           our sole product, we cannot release our technical documents to
the world at
            large.  We have been working to create an extract of our
documents to enable
            the Linux community.  As a small company experiencing tremendous
growth, our
            support infrastructure must focus on our existing customers.  At
this time,
            I do not have an estimated release date for the technical
extract.
            ...
            We are continuing our work to enable the Linux community.  Can
you think of
             any alternative methods to enable the Linux community without
exposing
              ourselves?  I'm certainly open to new ideas..."

Jim responded to my Email regarding support for lm-sensor. Granted
Serverworks has
not released any information to the public. But they are planing to extract
certain chipset
information that might be helpful for you. They are also open to idea from
the Linux
community.

After Jim replied, Phil Edelbock from lm-sensor group came up with a good
idea. They
decided to ask Jim for a specific set of information pertaining to the
project. So rather
goes for the whole documentation, they only asked for a small subset. The
idea worked
because Serverworks were able to supply the information quickly.

This could be a good approach in getting information from Serverwork outside
of NDA.

Jeff

ASL Inc.

----- Original Message -----
From: "Rico Tudor" <rico@patrec.com>
To: "Jeff Nguyen" <jeff@aslab.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, December 18, 2000 3:14 AM
Subject: Re: ServerWorks docs?


> Thanks for the offer, but the basic problem remains: no docs.
> As jamagallon@able.es noted, http://www.netroedge.com/~lm78/ shows some
> cause for hope, but a medium-sized LART is still called for.
>
> My interest in ServerWorks documentation is two-fold: first, to
> expand chipset support in my ECC utility and second, to better support
> ServerWorks-based machines in my workplace.
>
> On behalf of the Linux community, I would sign NDA if it was civilized
> and if my source remained, obviously, public-domain.  I could visit
> ServerWorks on my next foray to the Bay Area.
>
> More important to me is ready access to technical documentation to support
> machines at work.  I come from the era when PDP-11's were shipped with
> schematics, the OS, and the source to the OS.  Things have been going
> downhill ever since.  I'm not catching the next plane to the Bay Area
> for "eyes only" examination of a document every time a problem arises.
> In this regard, companies like IBM Storage and Intel win my kudos,
> and my dollars.  ServerWorks may get some of those dollars because they
> have an affordable chipset that supports 4 GB, but that advantage can
> change overnight.  It's not like IP has a long half-life these days,
> unless you can corner the pyramid-building business.
>
> These companies must evaluate their proprietary stance in relation to lost
> sales, the more so as free source accelerates.  ATI, Matrox, Adaptec: need
> we say more?  But then, I'm preaching to the choir.  Perhaps ServerWorks
> should look into their hearts, and decide what small part of their IP
> has enormous, eternal value -- the kind that will have them rolling in
> dough, just like Scrooge McDuck.  The rest of the specification, like
> the miserable ECC circuitry that's been done a million times before,
> release it already!  Their adoring Linux fans are waiting.
>
> P.S. I wonder if Via reads this list.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: gettimeofday() non-monotonic on uniprocessor system with ntp turned off?

[Paul Mackerras]

Christopher Friesen writes:

> I am having a little bit of a problem.  I'm on a single processor G4 system
> running 2.2.17 and I do not have ntp turned on.  However, successive calls to
> gettimeofday() occasionally return results that make it look as though time was
> running backwards.  

Looking at the code in the kernel, I can't see why this would happen.
Could you send me the code for your test program so I can chase this?

Paul.

-- 
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Anyone else interested in a high-precision monotonic counter?

[Christopher Friesen]

Has anyone ever considered including a microsecond-precision
monotonically-increasing counter in the kernel?  This would allow for
easy timing of alarms and such by using absolute values of when the
alarm should expire rather than a list of deltas from previous alarms.

The thing I have in mind would store a value something like "xtime"
(maybe call it "ytime"?) in the kernel.  This value would be initialized
to zero on startup, and would be incremented at the same time as
"xtime".  However, while "xtime" reflects adjustments to the actual
system time (settimeofday(), date, ntp, etc.), this value would not. 
Finally, it would be accessed with a system call essentially identical
to sys_gettimeofday(), only it would access "ytime" instead of "xtime"
before going down and getting the microseconds from the RTC.

This doesn't seem to me as though it would be all that tricky to add,
and I could see it being very useful in providing a timing source that
is guaranteed to a) be accurate to microseconds and b) never go
backwards.


Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Anyone else interested in a high-precision monotonic counter?

[Manfred Bartz]

"Christopher Friesen" <cfriesen@nortelnetworks.com> writes:

> Has anyone ever considered including a microsecond-precision
> monotonically-increasing counter in the kernel?  This would allow for
> easy timing of alarms and such by using absolute values of when the
> alarm should expire rather than a list of deltas from previous alarms.
> 
> The thing I have in mind would store a value something like "xtime"
> (maybe call it "ytime"?) in the kernel.  This value would be initialized
> to zero on startup, and would be incremented at the same time as
> "xtime".  However, while "xtime" reflects adjustments to the actual
> system time (settimeofday(), date, ntp, etc.), this value would not. 
> Finally, it would be accessed with a system call essentially identical
> to sys_gettimeofday(), only it would access "ytime" instead of "xtime"
> before going down and getting the microseconds from the RTC.
> 
> This doesn't seem to me as though it would be all that tricky to add,
> and I could see it being very useful in providing a timing source that
> is guaranteed to 
>         a) be accurate to microseconds and 
>         b) never go backwards.

Why a new system call?  

regarding a:  it could have microsecond resolution but not
              microseconds accuracy.
regarding b:  have you looked at the return-value of times(2)
              Or roll your own using setitimer(2)
-- 
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Anyone else interested in a high-precision monotonic counter?

[Christopher Friesen]

Manfred Bartz wrote:

> Why a new system call?
Well, you'd be accessing a different kernel variable--"ytime" instead of
"xtime". This new variable wouldn't be adjusted when the  system
time/date was, it would start at zero and always increase. 
 
> regarding a:  it could have microsecond resolution but not
>               microseconds accuracy.

On PPC and x86 systems, gettimeofday() is both accurate and precise to
microseconds, since it is based off of jiffies and then offset to get
microseconds.


> regarding b:  have you looked at the return-value of times(2)
>               Or roll your own using setitimer(2)

Both of these are precise only to jiffies, which defaults at 10
milliseconds on x86 and PPC.  If you want microsecond timing, the only
current standard way to do it is to use gettimeofday(), which is
sensitive to changes in system date and time.




-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Anyone else interested in a high-precision monotonic counter?

[Manfred Bartz]

"Christopher Friesen" <cfriesen@nortelnetworks.com> wrote:

> Manfred Bartz wrote:
> 
> > Why a new system call?
> Well, you'd be accessing a different kernel variable--"ytime" instead of
> "xtime". This new variable wouldn't be adjusted when the  system
> time/date was, it would start at zero and always increase. 

> > have you looked at the return-value of times(2)
> > Or roll your own using setitimer(2)
> 
> Both of these are precise only to jiffies, which defaults at 10
> milliseconds on x86 and PPC.  If you want microsecond timing, the only
> current standard way to do it is to use gettimeofday(), which is
> sensitive to changes in system date and time.

Ok.  A monotonic, high resolution timer would be useful.

Maybe one should then push for a full implementation of xtime
including TIME_MONOTONIC and TIME_TAI?

        <http://www.cl.cam.ac.uk/~mgk25/c-time/>
        <http://cr.yp.to/time.html>

-- 
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/