Bug 14668 - Problem iBCS appeared starting from the version Linux RedHat 6.1
Summary: Problem iBCS appeared starting from the version Linux RedHat 6.1
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.2
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alan Cox
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-26 16:47 UTC by Need Real Name
Modified: 2008-05-01 15:37 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2002-12-15 00:26:39 UTC


Attachments (Terms of Use)

Description Need Real Name 2000-07-26 16:47:20 UTC
Subject: Problem iBCS appeared starting from the version Linux RedHat 6.1
*************************************************************************

We use, under development, a BASIC interpreter that initially functioned
under various SCO environments : (SCO XENIX 386, SCO UNIX 3.2 v4.2, SCO
OPENSERVER 5).

We succeeded, without problems and thanks to the iBCS module, to work
whith it in a linux RedHat 6.0 (2.2.5) developpement environnement.In
order to follow the Linux peripheral drivers evolutions, we have done
tests whith the RedHat 6.1 (kernel 2.2.10) and RedHat 6.2 (kernel 2.2.14).
The first tests were not convincing :
The launching of the interpreter always ended with an error
"Segmentation fault".

The only way we found to avoid this problem has been to install the BASIC
interpreter in a small linux ext2 partition of 10 Mb and by using a 
symbolic link to have it in the /usr directory.
This "solution" works fine too for other binary files that were causing
the same errors "Segmentation Faults".

As you can imagine, we are not satisfied with this solution and we are
looking for information about this problem :
        - Why does it appear?
        - Is there something to do to solve it really?
        - Is our "empirical solution" the only way to execute our
	  binary files?

To understand better the problem, here are some more informations about
what we did.
Additional information:

1 - information returned by " file " for the binary file (b):
    # b:  Pure Microsoft a.out separate segmented Word-swapped V2.3 V3.0
    386 small model executable

2 - binary type of file recognized by iBCS:  format xout

3 -  Case which does not function correctly:

     Partitioning:
     /dev/sda5 one / standard ext2 (rw) (1500Mo)
     /dev/sda1 one / standardboot ext2 (rw) (1OMo)
     /dev/sda7 one /uss standard ext2 (rw) (500Mo)

     Installation:
     b copied in / usr/local/bin

     Result (Bad :-( ):
     #/usr/local/bin/b
     Segmentation fault

4 -  Case which functions correctly:

      Partitioning:

      /dev/sda5 one / standard ext2 (rw) (1500Mo)
      /dev/sda1 one / standardboot ext2 (rw) (10Mo)
      /dev/sda7 one / cibcs standard ext2 (rw) (10Mo)
      /dev/sda8 one / uss standard ext2 (rw) (490Mo)

      Installation:
      b copied /cibcs
      ln - s /cibcs/b /usr/local/bin/b

      Result (Good :-)  ):
      #/usr/local/bin/b
      Running CBASE...
      IPL doesn't exist or is not a regular file.
      #

Comment 1 Bill Nottingham 2000-07-27 16:26:01 UTC
Does this still happen with the errata kernel (2.2.16-3)?

Comment 2 Need Real Name 2000-07-31 07:39:35 UTC
yes , we have the same problem with the kernel 2.2.16-3

If i creates a ext2 filesystem with the RH6.0 distribution's mke2fs under 
RH6.2 , it's good !!!! , why ???? .  




Comment 3 Need Real Name 2000-08-01 12:07:56 UTC
On RH6.2 , the default block size and the default fragment size use by mke2fs 
are set to 8192 for large ext2 fs. If i use mke2fs with a value of 1024 
(options -b and -f) , all xout binaries run well .

Comment 4 Alan Cox 2000-09-16 22:35:06 UTC
This sounds like there is a block size assumption in the x.out loader for 1K
blocks. I wasn't 
aware of this one. I will investigate when I get time


Comment 5 Alan Cox 2002-12-15 00:26:39 UTC
ibcs2 was replaced with xabi in 2.4



Note You need to log in before you can comment on or make changes to this bug.