Discussion:
problem installing BDI 4.20
(too old to reply)
Jon Elson
2005-03-20 00:18:12 UTC
Permalink
Hello, all,

I'm trying to install the BDI 4.20 from the iso image on the Romanian
mirror.
I checked the MD5 checksum, it matches fine. It gets to the point of
starting the
X server, and it croaks with the message :

XIO: fatal IO error 104 (communication reset by peer) on X server ":1.0"

I tried every variation the introductory scripts recommend, all with the
same result.
any suggestions?

Thanks,

Jon
Jon Elson
2005-03-20 00:20:02 UTC
Permalink
Oh, yes, I should add the computer is a Dell Optiplex GX110. It loaded
BDI-Live!
rc46 with no problems at all. It has 256 MB memory and a 500 MHz
Pentium III.

Thanks,

Jon
Jon Elson
2005-03-20 19:34:39 UTC
Permalink
Post by Jon Elson
Hello, all,
I'm trying to install the BDI 4.20 from the iso image on the Romanian
mirror.
I checked the MD5 checksum, it matches fine. It gets to the point of
starting the
XIO: fatal IO error 104 (communication reset by peer) on X server ":1.0"
I tried every variation the introductory scripts recommend, all with
the same result.
Does anyone know how to get a totally character-cell (glass tty) install
with
this system? I'd like to bypass the X startup completely for the
install, and then
work on X once I have Linux fully working. I'm not sure what the
problem is with
this Dell machine, but X works fine when the linux install from the
BDI-Live! rc-46
was used.

Every attempt to install with the 4.20 CD ended with the same X bomb.

Thanks,

Jon
Stephen Wille Padnos
2005-03-20 19:39:02 UTC
Permalink
Post by Jon Elson
Post by Jon Elson
Hello, all,
I'm trying to install the BDI 4.20 from the iso image on the Romanian
mirror.
I checked the MD5 checksum, it matches fine. It gets to the point of
starting the
XIO: fatal IO error 104 (communication reset by peer) on X server ":1.0"
I tried every variation the introductory scripts recommend, all with
the same result.
Does anyone know how to get a totally character-cell (glass tty)
install with
this system? I'd like to bypass the X startup completely for the
install, and then
work on X once I have Linux fully working. I'm not sure what the
problem is with
this Dell machine, but X works fine when the linux install from the
BDI-Live! rc-46
was used.
Every attempt to install with the 4.20 CD ended with the same X bomb.
Thanks,
Jon
You can hit F2 (I think) at the boot prompt for other options - one of
them is a text-mode install.
The configurator allows you to choose a text or graphical login, once
you can get that far.

It looks odd to me that it's trying to use display 1.0 vs 0.0 - but I'm
no expert there.

- Steve
Jon Elson
2005-03-21 06:17:18 UTC
Permalink
Post by Stephen Wille Padnos
It looks odd to me that it's trying to use display 1.0 vs 0.0 - but
I'm no expert there.
hey, that's good! I didn't even catch that! I'm not sure what would
cause that.
But, this is while running the install procedure after booting from
CDROM, so
the environment could be quite different.

Jon
Paul
2005-03-20 19:55:45 UTC
Permalink
Jon

Boot the computer up, insert the CD into the drive..

apt-cdrom add
apt-get upgrade

Alternatively, use synaptic to install the kernel & rtai-dev pacages. You will
then have a system quite capable of building the EMC sources (see
http://www.redpoint.org.uk/cgi-bin/emcinfo.pl?BDI-4_Install for the full
list).

The BDI-Live install is Debian, as is the BDI-4 (apart from a couple of custom
packages), so the Debian instructions will work.

Regards, Paul.
 I'd like to bypass the X startup completely for the
install, and then
work on X once I have Linux fully working.  I'm not sure what the
problem is with
this Dell machine, but X works fine when the linux install from the
BDI-Live! rc-46
was used.
Every attempt to install with the 4.20 CD ended with the same X bomb.
--
Pieces of seven, pieces of seven - A parroty error.
"To err is human...to really f*** things up requires the root password."
From a collection of quotes at http://www.indigo.org/quotes.html
Jon Elson
2005-03-22 06:45:54 UTC
Permalink
Post by Paul
Jon
Boot the computer up, insert the CD into the drive..
apt-cdrom add
apt-get upgrade
OK, I went through all this, and got the source loaded. (Is it supposed
to be under
/root/emc ?) The file that was originally in ...../src/emctask/extppmcio.c
and now looks like it should be in ..../src/iotask is not there. it is
still in the old
emc CVS repository. This is the "back door" that replaces
extbridgeportio.c to
feed the aux. I/O to the real time routines that handle it for all the
ppmc devices.
Could you get that into the bdi-4 tree and check that the make rules to
build
ppmcio are enabled? (I'm afraid to dive into changing the CVS for bdi-4 yet
because I've never even done a compile on bdi-4 yet!)

Thanks,

Jon
Paul
2005-03-22 12:36:58 UTC
Permalink
Hi Jon
OK, I went through all this, and got the source loaded.  (Is it supposed
to be under /root/emc ?)
Get out of the habit of logging in as root - It is all too easy to 'rm -fR *'
in the wrong place and trash the system. In addition, once the realtime
modules are loaded, root permissions are not required.
The file that was originally in ...../src/emctask/extppmcio.c
and now looks like it should be in ..../src/iotask is not there.  it is
still in the old emc CVS repository.  This is the "back door" that replaces
extbridgeportio.c to feed the aux. I/O to the real time routines that handle
it for all the ppmc devices.
extppmcio.c is virtually identical to extppt.c - I see no advantage in having
two sources with different names.
The "back door" you refer to is (as I recall you saying) an ugly kludge to get
through the realtime barrier. Yet there are commands within the existing
usrmotintf & emcmot subsytem to handle IO read/writes - These would be much
more generic and allow bridgeportio to be used with other IO interface cards.
The other downside to the shm approach is it is all to easy to break - I'm
sure JohnK has other plans for passing IO to/from the RT code which would
make a merge of the BDI-4 branch even more difficult... There is also the
problem that the RTAI team has dropped shared memory support from it's Fusion
branch.
Could you get that into the bdi-4 tree and check that the make rules to
build ppmcio are enabled?  (I'm afraid to dive into changing the CVS for
bdi-4 yet because I've never even done a compile on bdi-4 yet!)
Need to weed out the duplicity of files and make sure it works properly, there
is also the debian/rules to extend.. Compiling is not a problem, but I can't
run any tests on the finished binaries. I assume you will be at the codeFest
where we can work through some of these (minor & trivial) issues and ensure
there are no unpleasant bugs ?


Regards, Paul.
--
Pieces of seven, pieces of seven - A parroty error.
"To err is human...to really f*** things up requires the root password."
From a collection of quotes at http://www.indigo.org/quotes.html
Jon Elson
2005-03-23 18:36:48 UTC
Permalink
Post by Paul
extppmcio.c is virtually identical to extppt.c - I see no advantage in having
two sources with different names.
The "back door" you refer to is (as I recall you saying) an ugly kludge to get
through the realtime barrier. Yet there are commands within the existing
usrmotintf & emcmot subsytem to handle IO read/writes - These would be much
more generic and allow bridgeportio to be used with other IO interface cards.
But, I am communicating with a device over a COMMUNICATIONS CHANNEL
(the parallel port) that doesn't allow atomic transactions. Therefore,
I MUST
serialize access to the parallel port. If the real time driver comes
into the
middle of a write (or read) done by the Linux side, the results will be
totally unpredictable,
except that interference with the motion hardware is guaranteed.

But, the real smarts are in ppmcparport.c
Yes, I see that the wrapper extppmcio.c is redundant, and the extppt.c
probably
will suffice. (That doesn't exist in EMC1, but I guess
extbridgeportio.c was
the prototype of it.)
Post by Paul
The other downside to the shm approach is it is all to easy to break - I'm
sure JohnK has other plans for passing IO to/from the RT code which would
make a merge of the BDI-4 branch even more difficult... There is also the
problem that the RTAI team has dropped shared memory support from it's Fusion
branch.
Well, a method for guaranteed serial access to the parallel port as a
communications
channel is going to be required for this hardware. I suspect other
devices may need a
similar mechanism at sume time.
Post by Paul
Need to weed out the duplicity of files and make sure it works properly, there
is also the debian/rules to extend..
Yes, I'm not sure this is going to run into any of that. It seems this
latest problem is
all on the Linux side. As far as I can tell, the RT modules are all
there and waiting
for instructions from the Linux side.
Post by Paul
Compiling is not a problem, but I can't
run any tests on the finished binaries.
I'm painfully aware of that.
Post by Paul
I assume you will be at the codeFest
where we can work through some of these (minor & trivial) issues and ensure
there are no unpleasant bugs ?
I strongly want to get this fixed at an earlier date, and have a working
system with 4.xx at
the codefest to
do further development with. I have customers right now that want the
4.18 or
4.20 to work with my boards. (I still have a debian install problem
with the on-board
video of my favorite Dell system to resolve.)

Jon
Paul
2005-03-24 02:30:19 UTC
Permalink
Hi Jon
Post by Jon Elson
Post by Paul
The "back door" you refer to is (as I recall you saying) an ugly kludge to
get through the realtime barrier. Yet there are commands within the
existing usrmotintf & emcmot subsytem to handle IO read/writes - These
would be much more generic and allow bridgeportio to be used with other
IO interface cards.
But, I am communicating with a device over a COMMUNICATIONS CHANNEL
(the parallel port) that doesn't allow atomic transactions.  Therefore,
I MUST serialize access to the parallel port.  If the real time driver comes
into the middle of a write (or read) done by the Linux side, the results
will be totally unpredictable, except that interference with the motion
hardware is guaranteed.
I said nothing about the parallel port OR low level hardware driver. I refer
you to emcmotCommandHandler, EMCMOT_SET_INDEX_BIT and it's companion,
EMCMOT_READ_INDEX_BIT. You will also notice just above them in the main
switch, a couple of additional commands for analogue output. These commands
are portable across all existing hardware drivers and _could_ allow for a
generic IO controller rather than having a multitude.
What ever JohnK's plans are for IO control in the head of emc2, it is a sure
bet that a generic IO controller in the bdi-4 branch would be easier to
merge.


Regards, Paul.
--
Pieces of seven, pieces of seven - A parroty error.
"To err is human...to really f*** things up requires the root password."
From a collection of quotes at http://www.indigo.org/quotes.html
Continue reading on narkive:
Loading...