bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Kernel Divide error trap


From: Marcus Brinkmann
Subject: Re: Kernel Divide error trap
Date: Wed, 26 Sep 2001 19:20:22 +0200
User-agent: Mutt/1.3.22i

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 ffff
> > 
> > Just print the final calculation.
> 
> ffff

Ok, so why has it that value?  It's strange enough.  The tenmicrosec will
count down from MICROCOUNT (1000) to zero, and in this time, the counter
should go down from 0xffff to something smaller than that.

It can't overflow, because counting to 1000 is fast.  The comment above the
function says "MICROCOUNT 1000  /* keep small to prevent overflow */" and
that was when a 386 was a powerful machine.

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 faster machine should show the same bug).  I have personally run
the Hurd on a Pentium III with 1GHz, and it worked just fine.

On the other hand, that adding a printk hold it up enough to go down to
0xfff3 (IIRC), so maybe it is indeed the case that the clock doesn't go down
at all.  Does your processor do something special to an empty loop that
prevents the clock from going down?  I am no processor expert.  Why have
other people with a similar configuration not reported such a problem
before?

However I turn it, it remains a mystery to me, and frankly, I am not sure
what to suggest to you how to get more info about it.

> > > Now, should i left that printk or maybe better would be to add sth. like 
> > > if (leftover == 0xffff) leftover -= 1;
> > 
> > The last printk should be ok.  BTW, oskit-mach does not use that code, so
> 
> But it doesn't change anything. I must add "if"

Yeah, simply setting microdata to 1 might work around it, but I don't think
it's the correct approach.  At least I don't understand why the code doesn't
work on your machine but on other, even faster machines.

> > the problem will go away in the future.  However, we might be able to just
> 
> Future does not satisfy me ;)

A hack to just make it work on your machine doesn't satisfy me ;)

> Well, why not. I have another bug, i'll post info but i must check
> mail archive

You scare me ;)

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]