#73 IBCS2 on Arch Linux 3.19.3-3-ARCH x86 (no x64)

[Zangune]

Duplicate of [patches:#72] as Chris Severance said here [forge:site-support:#10139] that ticket status should be changed to "open" and just you can do that.

The attachment was created by him in the linked ticket, I just download it and uploaded it here.
The following text and the title are just a copy paste of what he wrote:

Now mostly working on Arch Linux 3.19.3-3-ARCH x86
Bug: No x64 support (kernel oops)
Bug: Solaris not working with sock_sendmsg sock_recvmsg
Tested: SCO FPU

Note that rolling release Linux are a great choice for developing IBCS2 but a poor choice for running IBCS2.

[Javier Martinez]

I see, for the traces you inserted in the source, that you are looking for the solution to the 64bit oops. I tried the same last winter, and my conclusion was that the oops was caused when the module tried to modify the interrupt descriptor table (IDT). Maybe the address received for the table was wrong (I think not, however), or maybe the table is protected somehow. In either case, trying to modify the table pointed by the structure descr_t retrieved by the sidt call causes the oops:

lcall_idt_init:
idt_descr.ptr[Amd64vector*2+0] =
((u64)lcall_int & 0xFFFF) << 0 |
__KERNEL_CS << 16 |
(u64)0xee00L << 32 |
((u64)lcall_int >> 16 & 0xFFFF) << 48;

I'm sorry if you feel i'm stating some point already obvious to you, but I'm hoping to give a hand if I can to solve this.

Regards,
Javier.

[Chris Severance]

By reordering the two writes to the idt, I was able to prove that it's not a wrong address, bum interrupt assembly code, or a hijacked in use interrupt. I displayed all the table values and it crashed when I wrote a value I knew was already there. That tells me that the table is locked. I left the debug code in as it was quite a hassle to write and is easy to remove or disable whenever the problem is fixed.

Since I know so little about kernel development, my first step in fixing this would be to go back to a kernel version where the code still runs. Figure out what the interrupt does and maybe why it's needed in 64 bit mode and not in 32 bit mode. See if the assembly code is flimsy and likely to break with every kernel change or robust and unlikely to break.

Then work forwards through the kernels until it stops working and look for the code change. The kernel devs must read and write this table so it's a matter of finding out how they do it. I suspect they added a memory unlock and lock around the table writes. The place where this is done wasn't easy to find in the source code searchers so I gave up.

It would be nice if the IBCS code was updated to use the idt macros that the kernel uses rather than manually bit banging the interrupt values together. That would make verifying code correctness a matter of checking against the kernel source rather than checking the AMD manual. My testing was on Intel processors. You should try at least one AMD processor to see if there are any behavioral differences.

When you're done using the Debian version that Russell Stuart wrote the 64 bit code for, you might find the Arch Rollback Machine helpful. The Arch Linux package page for linux shows you the version history by date and the ARM will let you start at the kernel version you want and work forwards as desired.

Arch Linux seems the optimal platform to develop IBCS on. You fix all the crashes long before anyone else sees them and you can run as many kernel versions as you need to get all the code inflection points so rather than hack-n-slash forwards as is being done now you can keep it running across several kernel versions and eliminate the problem where IBCS doesn't work on Red Hat version foo and Ubuntu version bar. IBCS would be worth publishing if it could be maintained across many recent OS releases. This shouldn't be very difficult with the emulation module I added.

[serock]

Hello, sorry for my English, compile the ibcs-3.19.0.38beta patch on the kernel 3.19.3 and 3.19.8 (vanilla ice) and both give me the same "error":

/usr/src/ibcs-3.19.0.38beta/svr4/open.c: In function ‘svr4_getdents’:
/usr/src/ibcs-3.19.0.38beta/svr4/open.c:383:2: warning: initialization from incompatible pointer type
};
^
/usr/src/ibcs-3.19.0.38beta/svr4/open.c:383:2: warning: (near initialization for ‘buf.ctx.actor’)
/usr/src/ibcs-3.19.0.38beta/util/plist.c: In function ‘plist’:
/usr/src/ibcs-3.19.0.38beta/util/plist.c:32:4: warning: '0' flag used with ‘%p’ gnu_printf format [-Wformat=]
sprintf(p, "%08p", (void )addr); / warning on this line */
^
/usr/src/ibcs-3.19.0.38beta/util/plist.c: In function ‘pdump.part.0’:
/usr/src/ibcs-3.19.0.38beta/util/plist.c:84:1: warning: the frame size of 2044 bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^

I have BBx Progression 4 originally from an SCO UNIX 3.2 SysVR3 2 now works well, do not know if could be problematic in some situation