Re: [Bug-hurd] Re: Problems with oskit-mach

2000-09-17 Thread Marcus Brinkmann
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

Re: [Bug-hurd] Re: Problems with oskit-mach

2000-09-17 Thread Roland McGrath
> 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

Re: [Bug-hurd] Re: Problems with oskit-mach

2000-09-17 Thread Neal H Walfield
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

[Bug-hurd] Re: Problems with oskit-mach

2000-09-17 Thread Roland McGrath
>[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

[Bug-hurd] Re: Problems with oskit-mach

2000-09-17 Thread Neal H Walfield
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

[Bug-hurd] Re: Problems with oskit-mach

2000-09-17 Thread Neal H Walfield
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