Re: Kernel Divide error trap

[Mark Paulus]

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 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
>
>_______________________________________________
>Bug-hurd mailing list
>Bug-hurd@gnu.org
>http://mail.gnu.org/mailman/listinfo/bug-hurd