Bug 76567

 <7>[ls:1307]: set personality to 4000005
Unable to handle kernel paging request at virtual address c88a8000
 printing eip:a0003759
*pde = 0150a067
*pte = 00000000
Oops: 0000
3c59x sr_mod cdrom ide-scsi sg scsi_mod lp parport_pc parport abi-isc abi-svr4
CPU:    0
EIP:    0023:[<a0003759>]    Not tainted
EFLAGS: 00010286
 
EIP is at Using_Versions [] 0xa0003758 (2.4.18-17.7.x)
eax: 0000000d   ebx: 08111988   ecx: 00402418   edx: bffff7d4
esi: bffff7d4   edi: 08111988   ebp: bffff7b4   esp: bffff570
ds: 002b   es: 002b   ss: 002b
Process ls (pid: 1307, stackpage=c1e13000)

No other trace

I'm getting something similar using a SCO Openserver Binary program, vsifax
version 2. Previous 7.2 kernel 2.4.9-34 worked fine. 2.4.18-17.7.x is no go:

From /var/log/messages:

Nov  5 14:42:10 bonny kernel: Unable to handle kernel paging request at virtual
address d08e6000
Nov  5 14:42:10 bonny kernel:  printing eip:
Nov  5 14:42:10 bonny kernel: 00012921
Nov  5 14:42:10 bonny kernel: *pde = 01af0067
Nov  5 14:42:10 bonny kernel: *pte = 00000000
Nov  5 14:42:10 bonny kernel: Oops: 0000
Nov  5 14:42:10 bonny kernel: appletalk ipx abi-sco abi-cxenix lcall7 abi-util
abi-svr4 binfmt_coff eepro100
Nov  5 14:42:10 bonny kernel: CPU:    0
Nov  5 14:42:10 bonny kernel: EIP:    0023:[zisofs_cleanup+75937/-1072693376]
 Not tainted
Nov  5 14:42:10 bonny kernel: EIP:    0023:[<00012921>]    Not tainted
Nov  5 14:42:10 bonny kernel: EFLAGS: 00010246
Nov  5 14:42:10 bonny kernel:
Nov  5 14:42:10 bonny kernel: EIP is at Using_Versions [] 0x12920 (2.4.18-17.7.x)
Nov  5 14:42:10 bonny kernel: eax: 00000003   ebx: bfffff6f   ecx: 00000082  
edx: 00000033
Nov  5 14:42:10 bonny kernel: esi: 00000001   edi: 00000000   ebp: bfffd184  
esp: bfffd16c
Nov  5 14:42:10 bonny kernel: ds: 002b   es: 002b   ss: 002b
Nov  5 14:42:10 bonny kernel: Process mt932 (pid: 32298, stackpage=c6979000)

Nov  5 14:42:10 bonny kernel:  <1>Unable to handle kernel paging request at
virtual address d08e6000
Nov  5 14:42:10 bonny kernel:  printing eip:
Nov  5 14:42:10 bonny kernel: 0002737d
Nov  5 14:42:10 bonny kernel: *pde = 01af0067
Nov  5 14:42:10 bonny kernel: *pte = 00000000
Nov  5 14:42:10 bonny kernel: Oops: 0000
Nov  5 14:42:10 bonny kernel: appletalk ipx abi-sco abi-cxenix lcall7 abi-util
abi-svr4 binfmt_coff eepro100
Nov  5 14:42:10 bonny kernel: CPU:    0
Nov  5 14:42:10 bonny kernel: EIP:    0023:[zisofs_cleanup+160509/-1072693376]
  Not tainted
Nov  5 14:42:10 bonny kernel: EIP:    0023:[<0002737d>]    Not tainted
Nov  5 14:42:10 bonny kernel: EFLAGS: 00010282
Nov  5 14:42:10 bonny kernel:
Nov  5 14:42:10 bonny kernel: EIP is at Using_Versions [] 0x2737c (2.4.18-17.7.x)
Nov  5 14:42:10 bonny kernel: eax: 0000001b   ebx: 00000003   ecx: 00000003  
edx: 00000008
Nov  5 14:42:10 bonny kernel: esi: 080d2ccc   edi: 080d2ccc   ebp: bffff814  
esp: bffff808
Nov  5 14:42:10 bonny kernel: ds: 002b   es: 002b   ss: 002b
Nov  5 14:42:10 bonny kernel: Process fxsched (pid: 32297, stackpage=c38e1000)
Nov  5 14:42:10 bonny kernel:  <7>[fxstat:16764]: set personality to 7000003

FWIW: vanilla 2.4.19 + latest linux-abi patch work, so I cannot ask for help on
linux-abi list since I would be immediately redirected to Red Hat :)

Maybe you could just suggest which patch introduced between 2.4.18-10 and
2.4.18-17.7.x might cause problems and I'll try recompiling without it.

Enabling linux-abi tracing does not help since kernel problem seems to be before
linux-abi takes over.

2.4.19 lacked a critical security fix that is the prime suspect right now for
breaking linux abi

Thanks. Since on some systems I'm interested in functionality more than
security, can you tell me the name of the patch or the source file touched by
the fix, so that I can undo it? I looked in the same places that broke iBCS on
2.2.x errata but they didn't change between the latest 2 kernel errata.

I tried 2.4.20-rc1 and it also works. It seems changes in .19 .20-rc1 vanilla
kernels only require that shlibs be now executables, otherwise you get a 
kernel: coff: trapping process with SEGV
if you are not root.

Note that I'm testing .19 and .20-rc1 with latest linux-abi while in the errata
there's the previous version. Differences are minor. I cannot test errata with
latest patch due to massive problems applying all the patches in the src.rpm.

I see in rawhide linux-abi is gone. Should I consider this bug as wontfix?

I understand you cannot support this, as stated in the spec file, but it would
be sufficient to know the patch causing this so I can by trial and error find
out the exact point and try reverting it for internal use.

Alternatively, is there a source file I could fill with printk in order to see
where it breaks?

Thanks.

I too see this problem with 7.2 with 2.4.18-19.7xsmp.
Specifically, a SCO executable that works fine with 2.4.9-21smp, 
segfaults with 2.4.18-19.7xsmp.  Is there any possiblity that
the newly released 2.4.18-24.7x might have fixed this?

Right now there are no more supported Red Hat kernel releases using linux-abi,
so I'm closing this as wontfix.

Still, it would have been nice if you had told what you changed, since there are
users of supported releases (ie 7.3) that saw linux-abi working when installed
out of the box, then broken, then removed during security kernel updates.

Redhat is supposed to be Linux!  Linux supports linux-abi  Either fix this or
stop calling yourself Linux.  I for one will be a stong advocate against Redhat
if you drop this support.  You have already lost many of the linux-abi users and
the rest will be gone when they must update someday.

"Redhat is supposed to be Linux!  Linux supports linux-abi "

Actually you're very wrong. linux-abi is NOT part of the normal linux kernel.
It's an external patch, one which hasn't been actively maintained for almost a
year now.

The only good thing about you had a broken and now dropped linux-abi support is
that I now have a great uptime on one of my boxes, almost a year now.
The bad part is I'm missing all security updates since I can't upgrade the
kernel any more.
Please reconsider.

Well, lets see
* there is a linux-ABI patch against an old kernel
* it's not really maintained
* it has security holes
* it doesn't really work well in general, only for some limited number of old
SCO apps
* customers need a SCO license anyway to use those
* the number of people running SCO apps on linux is very low; esp since most
  SCO apps have linux versions out now, native is far superior to emulation in 
  this case.

*** Bug 101044 has been marked as a duplicate of this bug. ***