On Sun, Sep 17, 2000 at 10:17:48PM -0400, Roland McGrath wrote:
> For now, I've just done the minimal change that ought to work. I am not
> set up to check code in to subversions right now (no kerberos where I am).
> Someone who can should check this change in to the oskit-branch of gnumach.
Don
> Shouldn't this be Changelog.oskit? (along with the last entry?)
Yeah, they should be in there. ChangeLog should match the gnumach version
so that if the oskit-branch gets merged into gnumach at some point, all the
ChangeLog.oskit entries will go at the front of the ChangeLog in the merged
vers
Shouldn't this be Changelog.oskit? (along with the last entry?)
-Neal
> Index: ChangeLog
> ===
> RCS file: /cvs/gnumach/ChangeLog,v
> retrieving revision 1.69.2.2
> diff -b -u -r1.69.2.2 ChangeLog
> --- ChangeLog 2000/03/21 02:47:43
>[T]he bit must not be enabled before paging
> is enabled via CR0.PG. Program correctness may be affected by reversing this
> sequence, and processor performance will be impacted.
Ok, we should move the setting of the bit.
> The other, cleaner, option that I see
On Wed, Sep 06, 2000 at 02:49:55PM -0400, Roland McGrath wrote:
> I'm pretty sure I already make exactly that check (using the oskit header
> files and functions). That is the official Intel way of checking for the
> feature. The problem people are reporting is with AMD K6 family
> processors, w
On Wed, Sep 06, 2000 at 07:30:14PM +0200, Daniel Wagner wrote:
> Hi Igor!
>
> On Tue, 05 Sep 2000, Igor Khavkine wrote:
>
> > The first problem was that my computer generated a general protection fault
> > in the i386/intel/pmap.c::pmap_boostrap() function where the code was trying
> > to modify
On Thu, 07 Sep 2000, Roland McGrath wrote:
> > That's odd, since FreeBSD and Linux work fine on K6, even though
> > they don't do special treatment with K6 (as for the PGE bit). So
> > perhaps setting the bit is not the direct cause.
>
> Hmm, perhaps you can take a look at how they use the PGE
> That's odd, since FreeBSD and Linux work fine on K6, even though
> they don't do special treatment with K6 (as for the PGE bit). So
> perhaps setting the bit is not the direct cause.
Hmm, perhaps you can take a look at how they use the PGE feature and see if
it differs from what I did in oski
From: Roland McGrath <[EMAIL PROTECTED]>
Subject: Re: Problems with oskit-mach
Date: Wed, 6 Sep 2000 14:49:55 -0400 (EDT)
> I'm pretty sure I already make exactly that check (using the oskit header
> files and functions). That is the official Intel way of checking for th
I'm pretty sure I already make exactly that check (using the oskit header
files and functions). That is the official Intel way of checking for the
feature. The problem people are reporting is with AMD K6 family
processors, which appear to report that feature bit in cpuid but not
actually support
From: Roland McGrath <[EMAIL PROTECTED]>
Subject: Re: Problems with oskit-mach
Date: Wed, 6 Sep 2000 13:30:55 -0400 (EDT)
> It is certainly harmless to disable the code that uses PGE. It is just an
> optimization. It would be helpful to figure out exactly when it is and
> is
> On Tue, 05 Sep 2000, Igor Khavkine wrote:
>
> > The first problem was that my computer generated a general protection
> > fault in the i386/intel/pmap.c::pmap_boostrap() function where the code
> > was trying to modify the %cr4 register. I have a K6-III which pretends
> > to support the PGE ext
Hi Igor!
On Tue, 05 Sep 2000, Igor Khavkine wrote:
> The first problem was that my computer generated a general protection fault
> in the i386/intel/pmap.c::pmap_boostrap() function where the code was trying
> to modify the %cr4 register. I have a K6-III which pretends to support the
> PGE exten
13 matches
Mail list logo
