----Next_Part(Sun_Aug__9_15:35:18_1998)--
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

> Is anyone running -current (7/7 or later) on a laptop with a neomagic
> chip set and the emulated Xig freebsd software.  This worked fine for
> me under 1.3 and doesn't get started at all under -current.

I'm in a similar situation, and I got som help from Dave Huang to
solve this problem.  The problem is that the X server opens /dev/mem
read-only, and then proceeds to write into the memory area.  The
recipe for doing a binary patch follows attached below.

- H=E5vard

----Next_Part(Sun_Aug__9_15:35:18_1998)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Here's an idea... I don't know if it'll actually work, but it's worth a
try :) First find where the string "/dev/mem" occurs in the exe (which
you've already done :) In my example, I'm using the FreeBSD 4.1 demo
server:

% strings -t x Xaccel | grep /dev/mem
000e800 /dev/mem
000e809 Couldn't open "/dev/mem"

On the i386, a.out binaries are apparently loaded at 0x1000. So, 0xe800
in the file would end up at 0xf800 in memory. Use objdump or some other
disassembler to see where 0xf800 is referenced. For some reason, objdump
doesn't get the load address correct for FreeBSD binaries; it assumes
the text segment ends up at address 0. You can use the --adjust-vma
option to fix this though. (0x1020 because the a.out exec header is 0x20
bytes long and the text segment seems to always come right after that.
Also, see bytes 0x14 through 0x17 of the executable)

% objdump -d --adjust-vma=0x1020 Xaccel > Xaccel.s
% grep -n 0xf800 Xaccel.s
24579:    f844: 68 00 f8 00 00  pushl  $0xf800
233741:   8c127:        00 a1 00 00 00  addb   %ah,0xf8000000(%ecx)
239214:   8f26b:        00 05 02 00 00  addb   %al,0xf8000002

So, it's only referenced at one place... take a look around there...

% less +24574 Xaccel.s
    f838:       53              pushl  %ebx
    f839:       83 3d dc f3 09  cmpl   $0xffffffff,0x9f3dc
    f83e:       00 ff
    f840:       75 2e           jne    f870
    f842:       6a 00           pushl  $0x0
    f844:       68 00 f8 00 00  pushl  $0xf800
    f849:       e8 3e d9 08 00  call   9d18c
    f84e:       a3 dc f3 09 00  movl   %eax,0x9f3dc
    f853:       83 c4 08        addl   $0x8,%esp
    f856:       83 f8 ff        cmpl   $0xffffffff,%eax
    f859:       75 15           jne    f870
    f85b:       68 09 f8 00 00  pushl  $0xf809
    f860:       e8 4b 20 04 00  call   518b0

That looks like the one to me... f842 pushes the flags to the open call
(O_RDONLY), f844 pushes the pointer to the pathname ("/dev/mem"), and
f849 calls open(). Also, if you look a bit after that, you can see that
if the call returns -1, it pushes 0xf809, the address of the "Couldn't
open "/dev/mem"" message and calls some routine... maybe perror() or
something. Anyways, you want to change the "pushl $0x0" to "pushl $0x2",
so for the Xaccel 4.1 demo, you'd change byte 0xe843 of the binary from
0 to 2.

--------------------

> snylteveps# objdump -d --adjust-vma=0x1020 Xaccel > Xaccel.s
> objdump: Xaccel: File format not recognized
> snylteveps#

You may need to reconfigure and rebuild objdump with
configure --enable-targets=all for it to recognize FreeBSD binaries...
My objdump --help reports:

objdump: supported targets: a.out-i386-netbsd a.out-i386-bsd a.out-i386
msdos pe-i386 pei-i386 elf32-i386 a.out-i386-linux srec symbolsrec
tekhex binary ihex

objdump claims the FreeBSD binary I tried was of type "a.out-i386"

--------------------

----Next_Part(Sun_Aug__9_15:35:18_1998)----