Bug 14668 - Problem iBCS appeared starting from the version Linux RedHat 6.1
Problem iBCS appeared starting from the version Linux RedHat 6.1
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Alan Cox
Depends On:
  Show dependency treegraph
Reported: 2000-07-26 12:47 EDT by Need Real Name
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-12-14 19:26:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2000-07-26 12:47:20 EDT
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

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:

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

     b copied in / usr/local/bin

     Result (Bad :-( ):
     Segmentation fault

4 -  Case which functions correctly:


      /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)

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

      Result (Good :-)  ):
      Running CBASE...
      IPL doesn't exist or is not a regular file.
Comment 1 Bill Nottingham 2000-07-27 12:26:01 EDT
Does this still happen with the errata kernel (2.2.16-3)?
Comment 2 Need Real Name 2000-07-31 03:39:35 EDT
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 08:07:56 EDT
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 18:35:06 EDT
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-14 19:26:39 EST
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.