On Thu, Sep 27, 2001 at 03:07:33AM +0200, Marcus Brinkmann wrote:
> diff -ru gnumach/i386/i386/locore.S
>/mnt/marcus/gnu/hurd/gnumach/gnumach-20010918/i386/i386/locore.S
> --- gnumach/i386/i386/locore.STue Apr 10 20:44:00 2001
> +++ /mnt/marcus/gnu/hurd/gnumach/gnumach-20010918/i386/i386/
On Thu, Sep 27, 2001 at 02:53:44AM +0200, Marcus Brinkmann wrote:
> ok, I have something for you. Please try the attached patch
Now it is attached.
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNUhttp://www.gnu.org
On Sun, Sep 23, 2001 at 07:26:31PM +0200, Piotr Krukowiecki wrote:
> Kernel Divide error trap, eip 0x15f053
> kernel: Divide error (0), code=0
> Stopped at 0x15f053: idivl %ebx, %eax
ok, I have something for you. Please try the attached patch, I am quite
confident it will work. The patch remove
On Wed, Sep 26, 2001 at 11:43:31PM +0200, Daniel Wagner wrote:
> Well that's only one side of the truth. AMD had in those K6 series an
> very fast loop optimation. It was so fast, that Windows couldn't boot
> correctly, because they did also counting down a counter. The result was
> used as a divi
Marcus Brinkmann schrieb am Mittwoch, den 26. September 2001:
> So, may it be that the loop in tenmicrosec was executed faster than the
> clock could go down? But that would be trifle strange as we have run the
> Hurd on mach faster machines than an AMD K6 400MHz and not have this bug
> (and any
On Wed, Sep 26, 2001 at 01:20:12PM -0600, Mark Paulus wrote:
> Could it be a compiler optimization issue, where the empty loop is
> simply optimized away, and therefore never executed??
He used the kernel I compiled for the Debian package which works for
everyone else.
Marcus
--
`Rhubarb is n
Could it be a compiler optimization issue, where the empty loop is
simply optimized away, and therefore never executed??
(I have seen stranger things come out of optimized code)
On Wed, 26 Sep 2001 19:20:22 +0200, Marcus Brinkmann wrote:
>On Wed, Sep 26, 2001 at 05:15:32PM +0200, Piotr Kr
Ok, I've changed the overfull paragraph around a bit, and now it's
a underfull paragraph, which is better I suppose. Both of those
are caused by longish URL's in the paragraphs, I'm not sure what
else can be done.
Yes, it is better. There not much you can do with long URLs.
The ne
On Wed, Sep 26, 2001 at 05:15:32PM +0200, Piotr Krukowiecki wrote:
> > > Anyway, first leftover is f3, second f3ff, so i'ts close to
> >
> > Just print the final calculation.
>
>
Ok, so why has it that value? It's strange enough. The tenmicrosec will
count down from MICROCOUNT (1000
On Wed, 26 Sep 2001, Marcus Brinkmann wrote:
> > Anyway, first leftover is f3, second f3ff, so i'ts close to
>
> Just print the final calculation.
> > Now, should i left that printk or maybe better would be to add sth. like
> > if (leftover == 0x) leftover -= 1;
>
> The last pr
On Wed, Sep 26, 2001 at 04:07:31PM +0200, Piotr Krukowiecki wrote:
> On Wed, 26 Sep 2001, Marcus Brinkmann wrote:
>
> > http://people.debian.org/~brinkmd/mach/mach-0.2.tar.gz (72966 bytes)
>
> You mean http://people.debian.org/~brinkmd/mach/mach-info-0.2.tar.gz
> ?
Oops. Yes, of course (and t
On Wed, 26 Sep 2001, Marcus Brinkmann wrote:
> http://people.debian.org/~brinkmd/mach/mach-0.2.tar.gz (72966 bytes)
You mean http://people.debian.org/~brinkmd/mach/mach-info-0.2.tar.gz
?
--
Piotrek
irc: #Debian.pl
Mors Drosophilis melanogastribus!
__
On Mon, Sep 03, 2001 at 10:03:19PM +0200, Marcus Brinkmann wrote:
> I started to incorporate the CMU manual pages for Mach into a GNU Mach
> reference manual. This work requries three steps:
>
> 1. Incorporate all of the relevant manual page content into the texi document.
> 2. Go over all GNU M
On Tue, Sep 25, 2001 at 09:57:23PM +0200, Piotr Krukowiecki wrote:
> > byte = inb(pitctr0_port); /* least siginifcant */
> here
> > leftover = inb(pitctr0_port); /* most significant */
> here
Those two printk's will indeed change the value of leftover completely, if I
am n
14 matches
Mail list logo
