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
> "DW" == Daniel Wagner <[EMAIL PROTECTED]> writes:
DW> Well that's only one side of the truth. AMD had in those K6
DW> series an very fast loop optimation. It was so fast, that
DW> Windows couldn't boot correctly, because they did also
DW> counting down a counter. The result
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.
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
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 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
On Tue, 25 Sep 2001, Piotr Krukowiecki wrote:
(I should have written before that there were some files on /tmp)
> And another bug, maybe know already:
> [...]
> cleaning up left over files...panic: choose_pset_thread
It happened again, so i rebooted to linux and enabled swap in fstab,
after th
On Sun, 23 Sep 2001, Marcus Brinkmann wrote:
> Ok, this ath the end of the following code in machine/pit.c:
>
> #define MICROCOUNT 1000/* keep small to prevent overflow */
> microfind()
> {
> unsigned int flags;
> unsigned char byte;
> unsigned short leftover;
>
refers to and maybe get
> > a foot into the problem.
>
> Kernel Divide error trap, eip 0x15f053
> kernel: Divide error (0), code=0
> Stopped at 0x15f053: idivl %ebx, %eax
Ok, this ath the end of the following code in machine/pit.c:
#define MICROCOUNT 1000/* keep
in your GRUB configuration), and wait for the crash
> to happen. Write down the dump as above and send it in. We can then
> check which line of source code the above eip refers to and maybe get
> a foot into the problem.
Kernel Divide error trap, eip 0x15f053
kernel: Divide error (0), code=
On Sat, 22 Sep 2001, Marcus Brinkmann wrote:
> On Sat, Sep 22, 2001 at 03:31:57PM +0200, Piotr Krukowiecki wrote:
> > Most times i get this:
>
> Does most times means it works sometimes?
Yes, i can boot once for about 15 tries.
> I assume this is gnumach, not oskit-mach. Install the gnumach-
On Sat, 22 Sep 2001, Piotr Krukowiecki wrote:
> Hi
>
> I have trubles with booting.
> Most times i get this:
>
> [...]
> com1: at atbus1, port=2f8, spl = 6, pic = 3. (DOS COM2)
> Kernel Divide error trap, eip 0x138de2
> kernel trap, type 0, code = 0
> Dump of i3
On Sat, Sep 22, 2001 at 03:31:57PM +0200, Piotr Krukowiecki wrote:
> Most times i get this:
Does most times means it works sometimes?
> [...]
> com1: at atbus1, port=2f8, spl = 6, pic = 3. (DOS COM2)
> Kernel Divide error trap, eip 0x138de2
> kernel trap, type 0, cod
Hi
I have trubles with booting.
Most times i get this:
[...]
com1: at atbus1, port=2f8, spl = 6, pic = 3. (DOS COM2)
Kernel Divide error trap, eip 0x138de2
kernel trap, type 0, code = 0
Dump of i386_saved_state 0018f588:
EAX 471e4898 EBX 08004aff ECX EDX
ESI 0206 EDI
20 matches
Mail list logo