You have definitely identified the problem.  (That open'ing /dev/mem
for reading does not allow it to be mmap'ed for read/write -- it used
to.)  But your solution is MUCH TO COMPLICATED for the average user.

I looked at the actual freebsd mmap routine.  They make special
allowances for the Xig case.  I suggest that we make the same kind of
change in the freebsd emulated code so sys_freebsd_mmap() will take
care of things then call sys_mmap().

Any objections?


Havard.Eidnes@runit.sintef.no writes:

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