Panda and AMD64
Jean-Marc Bourguet
Hi all,
I've recently installed an "AMD64" linux distribution (Ubuntu 9.10 if that
matter) and tried to run Panda on it. I've tried:
- a self compiled one (with a patch published sometimes ago here to be
able to use tap/tun devices for BSD, modified by me for Linux)
- a clean unpacking of the version Mark pushed on my computer some years
ago the version
- a clean unpacking of the trailingedge version
and they all behave in a flacky way, ending more or less quickly with
output like this
[DTE: Bad to-10 BP 442200,,733000][dte_10xfrbeg: 10cnt left:
4086][dte_10xfrbeg: out of data, no I bit][DTE: Bad to-10 BP
0,,0][dte_10xfrbeg: 10cnt left: 4086][dte_10xfrbeg: out of data, no I
bit][DTE: Bad to-10 BP 0,,0][dte_10xfrbeg: 10cnt left: 3329][dte_10xfrbeg:
out of data, no I bit][DTE: Bad to-10 BP 0,,0][dte_10xfrbeg: 10cnt left:
4086][dte_10xfrbeg: out of data, no I bit][DTE: Bad to-10 BP
0,,0][dte_10xfrbeg: 10cnt left: 3329][dte_10xfrbeg: out of data, no I
bit][DTE: Bad to-10 BP 0,,0][dte_10xfrbeg: 10cnt left: 4086][dte_10xfrbeg:
out of data, no I bit][DTE: Bad to-10 BP 0,,0][dte_10xfrbeg: 10cnt left:
3329][dte_10xfrbeg: out of data, no I bit][DTE: Bad to-10 BP
0,,0][dte_10xfrbeg: 10cnt left: 4086][dte_10xfrbeg: out of data, no I
bit][DTE: Bad to-10 BP 0,,0][dte_10xfrbeg: 10cnt left: 3329][dte_10xfrbeg:
out of data, no I bit][DTE: Bad to-10 BP 0,,0][dte_10xfrbeg: 10cnt left:
4086][dte_10xfrbeg: out of data, no I bit]
On my previous linux installation, a 32 bits one, the same image behaves
sanely (I share the disk on which they are).
Is the problem know? Does someone have a clew at what should I look to fix
the issue (but I fear my knowledge of PDP-10 isn't good enough for this).
Yours,
--
Jean-Marc
Mark Crispin
> [DTE: Bad to-10 BP 442200,,733000][dte_10xfrbeg: 10cnt left: 4086][dte_10xfrbeg: out of data, no I bit]
This is a known problem on some Linux systems with high performance
hardware. As far as I know, Ken has not found a fix for it.
The workaround is to rebuild klh10 with a special configuration that
avoids the esoteric real-time-interrupt mechanisms.
In klh20-2.0h/src/Makefile, lines 357 and 358, you will find:
-DKLH10_ITIME_INTRP=1 \
-DKLH10_CTYIO_INT=1 \
Change both of these lines so they now read:
-DKLH10_ITIME_SYNC=1 \
-DKLH10_CTYIO_INT=0 \
You should only do this on a system which has this problem. It will run
on other systems, but will eat up CPU unnecessarily.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
glen herrmannsfeldt
> On Sat, 26 Dec 2009, Jean-Marc Bourguet posted:
>> [DTE: Bad to-10 BP 442200,,733000][dte_10xfrbeg: 10cnt left: 4086][dte_10xfrbeg: out of data, no I bit]
> This is a known problem on some Linux systems with high performance
> hardware. As far as I know, Ken has not found a fix for it.
The Hercules emulation of S/360 has problems on fast hardware, too.
One comes from the system clock, which can have zero counts over
a time where the OS figures it has at least one.
Another, I believe, comes from I/O, where the I/O operation
finishes (and the interrupt occurs) faster than expected.
-- glen
Jean-Marc Bourguet
> On Sat, 26 Dec 2009, Jean-Marc Bourguet posted:
>> [DTE: Bad to-10 BP 442200,,733000][dte_10xfrbeg: 10cnt left: 4086][dte_10xfrbeg: out of data, no I bit]
>
> This is a known problem on some Linux systems with high performance
> hardware. As far as I know, Ken has not found a fix for it.
Ho..., that reduce my changes of success when (and if) I try to find the
root cause but I've still some other things on my plate before I can give
times to that.
Something which could be relevant is that it works on the same hardware
with a 32 bits Linux installation. When I've time, I'll check with the
same distribution, changing only the bitness.
> The workaround is to rebuild klh10 with a special configuration that avoids
> the esoteric real-time-interrupt mechanisms.
>
> In klh20-2.0h/src/Makefile, lines 357 and 358, you will find:
> -DKLH10_ITIME_INTRP=1 \
> -DKLH10_CTYIO_INT=1 \
>
> Change both of these lines so they now read:
> -DKLH10_ITIME_SYNC=1 \
> -DKLH10_CTYIO_INT=0 \
>
> You should only do this on a system which has this problem. It will run on
> other systems, but will eat up CPU unnecessarily.
Thanks, I'll try that and report if it works.
Yours,
--
Jean-Marc
Morten Reistad
Mark Crispin <m...@panda.com> wrote:
>On Sat, 26 Dec 2009, Jean-Marc Bourguet posted:
>> [DTE: Bad to-10 BP 442200,,733000][dte_10xfrbeg: 10cnt left: 4086][dte_10xfrbeg: out of data, no I bit]
>
>This is a known problem on some Linux systems with high performance
>hardware. As far as I know, Ken has not found a fix for it.
There is no fix. Systems that behave like this are broken as designed.
>The workaround is to rebuild klh10 with a special configuration that
>avoids the esoteric real-time-interrupt mechanisms.
>
>In klh20-2.0h/src/Makefile, lines 357 and 358, you will find:
> -DKLH10_ITIME_INTRP=1 \
> -DKLH10_CTYIO_INT=1 \
>
>Change both of these lines so they now read:
> -DKLH10_ITIME_SYNC=1 \
> -DKLH10_CTYIO_INT=0 \
or upgrade to a 32-bit OS. With PAE you can use all of the memory,
just no more than 3.875 gigabytes per process. I can assure you that
KLH works just fine within that memory limitation.
>
>You should only do this on a system which has this problem. It will run
>on other systems, but will eat up CPU unnecessarily.
Amen.
-- mrr
Mark Crispin
> or upgrade to a 32-bit OS. With PAE you can use all of the memory,
> just no more than 3.875 gigabytes per process. I can assure you that
> KLH works just fine within that memory limitation.
It is not a 64-bit specific problem.
The problem also occurs on some 32-bit systems. I know because I have had
to do this workaround on some of my machines.
Robert Komar
Virtualbox has problems when the linux kernel has been built with
tickless timer support (CONFIG_NO_HZ enabled). Could it be that
klh10 has similar problems? For virtualbox, rebuilding the kernel
or booting with the 'nohz=off' parameter fixes the problem. The
latter is easy to try to see if it would help with klh10.
Cheers,
Rob Komar
Jean-Marc Bourguet
> Virtualbox has problems when the linux kernel has been built with
> tickless timer support (CONFIG_NO_HZ enabled). Could it be that
> klh10 has similar problems? For virtualbox, rebuilding the kernel
> or booting with the 'nohz=off' parameter fixes the problem. The
> latter is easy to try to see if it would help with klh10.
I had an hope as CONFIG_NO_HZ is on on the problematic system and not on
the one working, but booting with nohz=off doesn't make klh10 works.
--
Jean-Marc
Jean-Marc Bourguet
> On Sat, 26 Dec 2009, Jean-Marc Bourguet posted:
>> [DTE: Bad to-10 BP 442200,,733000][dte_10xfrbeg: 10cnt left: 4086][dte_10xfrbeg: out of data, no I bit]
>
> This is a known problem on some Linux systems with high performance
> hardware. As far as I know, Ken has not found a fix for it.
>
> The workaround is to rebuild klh10 with a special configuration that avoids
> the esoteric real-time-interrupt mechanisms.
>
> In klh20-2.0h/src/Makefile, lines 357 and 358, you will find:
> -DKLH10_ITIME_INTRP=1 \
> -DKLH10_CTYIO_INT=1 \
>
> Change both of these lines so they now read:
> -DKLH10_ITIME_SYNC=1 \
> -DKLH10_CTYIO_INT=0 \
>
> You should only do this on a system which has this problem. It will run on
> other systems, but will eat up CPU unnecessarily.
I've now had time to test this, it works on my system.
Thanks,
--
Jean-Marc