From chagin.dmitry at gmail.com  Sat Aug  2 16:02:10 2008
From: chagin.dmitry at gmail.com (Chagin Dmitry)
Date: Sat Aug  2 16:02:17 2008
Subject: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <alpine.BSF.1.10.0807251556100.31063@thor.farley.org>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<20080723184450.GA25356@freebsd.org>
	<alpine.BSF.1.10.0807231459030.12600@thor.farley.org>
	<alpine.BSF.1.10.0807240016340.28898@ora.chd.net>
	<alpine.BSF.1.10.0807231616570.12600@thor.farley.org>
	<20080725082156.GA41887@freebsd.org>
	<20080725083122.GA42835@freebsd.org>
	<alpine.BSF.1.10.0807251233470.1710@ora.chd.net>
	<alpine.BSF.1.10.0807251231050.30805@thor.farley.org>
	<alpine.BSF.1.10.0807252318130.1162@ora.chd.net>
	<alpine.BSF.1.10.0807251511230.31063@thor.farley.org>
	<alpine.BSF.1.10.0807260044170.1162@ora.chd.net>
	<alpine.BSF.1.10.0807251556100.31063@thor.farley.org>
Message-ID: <alpine.BSF.1.10.0808021950010.79549@ora.chd.net>

On Fri, 25 Jul 2008, Sean C. Farley wrote:

>>>  1. http://www.farley.org/freebsd/tmp/ktrace.out.bz2
>> 
>> I can't use it on -current, ktrace abi was changed. please, make
>> itself linux_kdump :)
>
> Picky, picky!  :)  Here[2] you go.
>
> Sean
>  2. http://www.farley.org/freebsd/tmp/ktrace.txt
>

Hi Sean,
please try:

http://78.107.232.239/linux_rt.patch

I can't test it on i386, but on amd64@compat32 it works :)

thnx!

-- 
Have fun!
chd
From chagin.dmitry at gmail.com  Sat Aug  2 20:54:44 2008
From: chagin.dmitry at gmail.com (Chagin Dmitry)
Date: Sat Aug  2 20:54:51 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
Message-ID: <alpine.BSF.1.10.0808030024140.81282@ora.chd.net>

On Wed, 23 Jul 2008, Sean C. Farley wrote:

> I am seeing if anyone has any insight on this PR (kern/122318[1]).  It
> would be nice to once again build using cmake within a Linux chroot.  :)
>
> Basically, the bug is that not only that cmake is dumping core; it is
> also forcing the user out of the chroot environment.  Here is the
> command used to start the chroot:
> /compat/linux/usr/sbin/chroot <chroot path> su - <build user>
>
> Thank you.
>
> Sean
>  1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
>

here patches for -current and releng_7:
http://78.107.232.239/rt_signals-current.patch
http://78.107.232.239/rt_signals-releng_7.patch

what patch do:
- rt sigtramp code works (this solves PR)
- align stack pointers
- remove kern_sigaltstack() at the end of rt_sigreturn(), it's a bogus.
   Here there is some information on it:
   http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1283.html

thnx!

-- 
Have fun!
chd
From rdivacky at freebsd.org  Sat Aug  2 22:17:23 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Sat Aug  2 22:17:42 2008
Subject: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <alpine.BSF.1.10.0808021950010.79549@ora.chd.net>
References: <alpine.BSF.1.10.0807231616570.12600@thor.farley.org>
	<20080725082156.GA41887@freebsd.org>
	<20080725083122.GA42835@freebsd.org>
	<alpine.BSF.1.10.0807251233470.1710@ora.chd.net>
	<alpine.BSF.1.10.0807251231050.30805@thor.farley.org>
	<alpine.BSF.1.10.0807252318130.1162@ora.chd.net>
	<alpine.BSF.1.10.0807251511230.31063@thor.farley.org>
	<alpine.BSF.1.10.0807260044170.1162@ora.chd.net>
	<alpine.BSF.1.10.0807251556100.31063@thor.farley.org>
	<alpine.BSF.1.10.0808021950010.79549@ora.chd.net>
Message-ID: <20080802221601.GA77929@freebsd.org>

On Sat, Aug 02, 2008 at 08:02:00PM +0400, Chagin Dmitry wrote:
> On Fri, 25 Jul 2008, Sean C. Farley wrote:
> 
> >>> 1. http://www.farley.org/freebsd/tmp/ktrace.out.bz2
> >>
> >>I can't use it on -current, ktrace abi was changed. please, make
> >>itself linux_kdump :)
> >
> >Picky, picky!  :)  Here[2] you go.
> >
> >Sean
> > 2. http://www.farley.org/freebsd/tmp/ktrace.txt
> >
> 
> Hi Sean,
> please try:
> 
> http://78.107.232.239/linux_rt.patch

great! can you point me at linux sources file/line-no where did you
find that it should be like this?

anyway.. great work!

roman
From rdivacky at freebsd.org  Sat Aug  2 22:22:40 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Sat Aug  2 22:22:49 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
Message-ID: <20080802222109.GA78151@freebsd.org>

On Sun, Aug 03, 2008 at 12:53:58AM +0400, Chagin Dmitry wrote:
> On Wed, 23 Jul 2008, Sean C. Farley wrote:
> 
> >I am seeing if anyone has any insight on this PR (kern/122318[1]).  It
> >would be nice to once again build using cmake within a Linux chroot.  :)
> >
> >Basically, the bug is that not only that cmake is dumping core; it is
> >also forcing the user out of the chroot environment.  Here is the
> >command used to start the chroot:
> >/compat/linux/usr/sbin/chroot <chroot path> su - <build user>
> >
> >Thank you.
> >
> >Sean
> > 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
> >
> 
> here patches for -current and releng_7:
> http://78.107.232.239/rt_signals-current.patch
> http://78.107.232.239/rt_signals-releng_7.patch
> 
> what patch do:
> - rt sigtramp code works (this solves PR)
> - align stack pointers
> - remove kern_sigaltstack() at the end of rt_sigreturn(), it's a bogus.
>   Here there is some information on it:
>   http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1283.html

I quickly skimmed over it and it looks correct, but please avoid
making gratuitous changes like moving stuff before comment after
the comment etc.

I will do a little more thorough review but so far it looks good

great work dmitry!

roman
From chagin.dmitry at gmail.com  Sat Aug  2 22:55:02 2008
From: chagin.dmitry at gmail.com (Chagin Dmitry)
Date: Sat Aug  2 22:55:08 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <20080802222109.GA78151@freebsd.org>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
	<20080802222109.GA78151@freebsd.org>
Message-ID: <alpine.BSF.1.10.0808030252230.82585@ora.chd.net>

On Sun, 3 Aug 2008, Roman Divacky wrote:

> On Sun, Aug 03, 2008 at 12:53:58AM +0400, Chagin Dmitry wrote:
>> On Wed, 23 Jul 2008, Sean C. Farley wrote:
>>
>>> I am seeing if anyone has any insight on this PR (kern/122318[1]).  It
>>> would be nice to once again build using cmake within a Linux chroot.  :)
>>>
>>> Basically, the bug is that not only that cmake is dumping core; it is
>>> also forcing the user out of the chroot environment.  Here is the
>>> command used to start the chroot:
>>> /compat/linux/usr/sbin/chroot <chroot path> su - <build user>
>>>
>>> Thank you.
>>>
>>> Sean
>>> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
>>>
>>
>> here patches for -current and releng_7:
>> http://78.107.232.239/rt_signals-current.patch
>> http://78.107.232.239/rt_signals-releng_7.patch
>>
>> what patch do:
>> - rt sigtramp code works (this solves PR)
>> - align stack pointers
>> - remove kern_sigaltstack() at the end of rt_sigreturn(), it's a bogus.
>>   Here there is some information on it:
>>   http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1283.html
>
> I quickly skimmed over it and it looks correct, but please avoid
> making gratuitous changes like moving stuff before comment after
> the comment etc.
>

I have simply transferred a line on place where it should be :)

> I will do a little more thorough review but so far it looks good
>

and please, test it on i386.

-- 
Have fun!
chd
From rdivacky at freebsd.org  Sun Aug  3 07:32:14 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Sun Aug  3 07:32:21 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <alpine.BSF.1.10.0808030252230.82585@ora.chd.net>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
	<20080802222109.GA78151@freebsd.org>
	<alpine.BSF.1.10.0808030252230.82585@ora.chd.net>
Message-ID: <20080803073044.GA4624@freebsd.org>

On Sun, Aug 03, 2008 at 02:54:53AM +0400, Chagin Dmitry wrote:
> On Sun, 3 Aug 2008, Roman Divacky wrote:
> 
> >On Sun, Aug 03, 2008 at 12:53:58AM +0400, Chagin Dmitry wrote:
> >>On Wed, 23 Jul 2008, Sean C. Farley wrote:
> >>
> >>>I am seeing if anyone has any insight on this PR (kern/122318[1]).  It
> >>>would be nice to once again build using cmake within a Linux chroot.  :)
> >>>
> >>>Basically, the bug is that not only that cmake is dumping core; it is
> >>>also forcing the user out of the chroot environment.  Here is the
> >>>command used to start the chroot:
> >>>/compat/linux/usr/sbin/chroot <chroot path> su - <build user>
> >>>
> >>>Thank you.
> >>>
> >>>Sean
> >>>1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
> >>>
> >>
> >>here patches for -current and releng_7:
> >>http://78.107.232.239/rt_signals-current.patch
> >>http://78.107.232.239/rt_signals-releng_7.patch
> >>
> >>what patch do:
> >>- rt sigtramp code works (this solves PR)
> >>- align stack pointers
> >>- remove kern_sigaltstack() at the end of rt_sigreturn(), it's a bogus.
> >>  Here there is some information on it:
> >>  http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1283.html
> >
> >I quickly skimmed over it and it looks correct, but please avoid
> >making gratuitous changes like moving stuff before comment after
> >the comment etc.
> >
> 
> I have simply transferred a line on place where it should be :)

no problem with the change itself but including it in the patch
makes the patch bigger and harder to review

> >I will do a little more thorough review but so far it looks good
> >
> 
> and please, test it on i386.

test with the cmake?
From chagin.dmitry at gmail.com  Sun Aug  3 07:38:56 2008
From: chagin.dmitry at gmail.com (Chagin Dmitry)
Date: Sun Aug  3 07:39:03 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <20080803073044.GA4624@freebsd.org>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
	<20080802222109.GA78151@freebsd.org>
	<alpine.BSF.1.10.0808030252230.82585@ora.chd.net>
	<20080803073044.GA4624@freebsd.org>
Message-ID: <alpine.BSF.1.10.0808031134260.84147@ora.chd.net>

On Sun, 3 Aug 2008, Roman Divacky wrote:

> On Sun, Aug 03, 2008 at 02:54:53AM +0400, Chagin Dmitry wrote:
>> On Sun, 3 Aug 2008, Roman Divacky wrote:
>>
>>> On Sun, Aug 03, 2008 at 12:53:58AM +0400, Chagin Dmitry wrote:
>>>> On Wed, 23 Jul 2008, Sean C. Farley wrote:
>>>>
>>>>> I am seeing if anyone has any insight on this PR (kern/122318[1]).  It
>>>>> would be nice to once again build using cmake within a Linux chroot.  :)
>>>>>
>>>>> Basically, the bug is that not only that cmake is dumping core; it is
>>>>> also forcing the user out of the chroot environment.  Here is the
>>>>> command used to start the chroot:
>>>>> /compat/linux/usr/sbin/chroot <chroot path> su - <build user>
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Sean
>>>>> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
>>>>>
>>>>
>>>> here patches for -current and releng_7:
>>>> http://78.107.232.239/rt_signals-current.patch
>>>> http://78.107.232.239/rt_signals-releng_7.patch
>>>>
>>>> what patch do:
>>>> - rt sigtramp code works (this solves PR)
>>>> - align stack pointers
>>>> - remove kern_sigaltstack() at the end of rt_sigreturn(), it's a bogus.
>>>>  Here there is some information on it:
>>>>  http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1283.html
>>>
>>> I quickly skimmed over it and it looks correct, but please avoid
>>> making gratuitous changes like moving stuff before comment after
>>> the comment etc.
>>>
>>
>> I have simply transferred a line on place where it should be :)
>
> no problem with the change itself but including it in the patch
> makes the patch bigger and harder to review

ok

>
>>> I will do a little more thorough review but so far it looks good
>>>
>>
>> and please, test it on i386.
>
> test with the cmake?
>

no, with special test http://78.107.232.239/tst_rtsig.c
cmake differs only that that uses select() and I sigsuspend() for 
sleep.

-- 
Have fun!
chd
From chagin.dmitry at gmail.com  Sun Aug  3 20:33:45 2008
From: chagin.dmitry at gmail.com (Chagin Dmitry)
Date: Sun Aug  3 20:33:51 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <20080803073044.GA4624@freebsd.org>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
	<20080802222109.GA78151@freebsd.org>
	<alpine.BSF.1.10.0808030252230.82585@ora.chd.net>
	<20080803073044.GA4624@freebsd.org>
Message-ID: <alpine.BSF.1.10.0808040026200.51243@ora.chd.net>

On Sun, 3 Aug 2008, Roman Divacky wrote:

>>>
>>
>> and please, test it on i386.
>
> test with the cmake?
>

I have updated the test http://78.107.232.239/tst_rtsig.c
in the previous version a problem with strerror(),
the test hangs even in fbsd.

-- 
Have fun!
chd
From linimon at FreeBSD.org  Mon Aug  4 08:31:29 2008
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Mon Aug  4 08:31:35 2008
Subject: ports/126232: Linux ioctl TCGETS (0x5401) always fails
Message-ID: <200808040831.m748VSVo067358@freefall.freebsd.org>

Synopsis: Linux ioctl TCGETS (0x5401) always fails

Responsible-Changed-From-To: freebsd-bugs->freebsd-emulation
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Aug 4 08:31:04 UTC 2008
Responsible-Changed-Why: 
reclassify.

http://www.freebsd.org/cgi/query-pr.cgi?pr=126232
From bugmaster at FreeBSD.org  Mon Aug  4 11:06:53 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Aug  4 11:07:27 2008
Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org
Message-ID: <200808041106.m74B6rrJ082027@freefall.freebsd.org>

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/21463   emulation  [linux] Linux compatability mode should not allow setu
o kern/97326   emulation  [linux] file descriptor leakage in linux emulation
o kern/117010  emulation  [linux] linux_getdents() get something like buffer ove

3 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/11165   emulation  [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999
o kern/29698   emulation  [linux] [patch] linux ipcs doesn'work
o kern/39201   emulation  [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu
o kern/41543   emulation  [patch] [request] easier wine/w23 support
a kern/72920   emulation  [linux]: path "prefixing" is not done on unix domain s
o kern/73777   emulation  [linux] [patch] linux emulation: root dir special hand
o kern/91293   emulation  [svr4] [patch] *Experimental* Update to the SVR4 emula
o ports/91318  emulation  [fix] graphics/linux_dri: works on amd64 too
o ports/121800 emulation  x11-toolkits/linux-openmotif - OpenMotif upgrade to 2.
o kern/122318  emulation  [linux] [cmake]: Segmentation fault when running Linux
o ports/123960 emulation  Port fix: archivers/linux-par2cmdline - better handlin
o ports/123964 emulation  Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS
o ports/126232 emulation  Linux ioctl TCGETS (0x5401) always fails

13 problems total.

From chagin.dmitry at gmail.com  Tue Aug  5 16:30:09 2008
From: chagin.dmitry at gmail.com (Chagin Dmitry)
Date: Tue Aug  5 16:30:25 2008
Subject: ports/126232: Linux ioctl TCGETS (0x5401)
Message-ID: <200808051630.m75GU9BL080025@freefall.freebsd.org>

The following reply was made to PR ports/126232; it has been noted by GNATS.

From: Chagin Dmitry <chagin.dmitry@gmail.com>
To: bug-followup@freebsd.org, yuri@tsoft.com
Cc: dchagin@freebsd.org
Subject: Re: ports/126232: Linux ioctl TCGETS (0x5401)
Date: Tue, 5 Aug 2008 20:27:44 +0400 (MSD)

 >
 >  Description:
 >  I've ran ktrace(1) on some Linux application and noticed that it has a
 >  lot calls like this:
 >  97754 app CALL linux_ioctl(0xf,0x5401 ,0xbfbfbc78)
 >  97754 app RET linux_ioctl -1 errno 25 Inappropriate ioctl for device
 >  0x5401 stands for TCGETS on Linux. As I understand this ioctl is
 >  obsolete
 >  and is replaced by tcgetattr() (?).
 
 Actually it not absolutelly so, tcgetattr() it is a glibc function
 which uses ioctl TCGETS inside.
 
 
 >  It's better to not return errno but to do what tcgetattr() does.
 >  This will take out one more potential point of failure for some Linux
 >  apps.
 
 I think that the author should give more information, at least explain
 on what specifies a file descriptor.
 
 thnx!
 
 -- 
 Have fun!
 chd
From yuri at rawbw.com  Tue Aug  5 17:20:03 2008
From: yuri at rawbw.com (Yuri)
Date: Tue Aug  5 17:20:09 2008
Subject: ports/126232: Linux ioctl TCGETS (0x5401)
Message-ID: <200808051720.m75HK2Z3085153@freefall.freebsd.org>

The following reply was made to PR ports/126232; it has been noted by GNATS.

From: Yuri <yuri@rawbw.com>
To: Chagin Dmitry <chagin.dmitry@gmail.com>
Cc: bug-followup@freebsd.org, dchagin@freebsd.org
Subject: Re: ports/126232: Linux ioctl TCGETS (0x5401)
Date: Tue, 05 Aug 2008 09:50:18 -0700

 Chagin Dmitry wrote:
 > Actually it not absolutelly so, tcgetattr() it is a glibc function
 > which uses ioctl TCGETS inside.
 >
 
 Actually on FreeBSD tcgetattr() is typedefed to ioctl TCGETA.
 
 In short this PR asks to implement TCGETS in Linux emulator.
 
 >
 > I think that the author should give more information, at least explain
 > on what specifies a file descriptor.
 
 Which author?
 
From yuri at rawbw.com  Tue Aug  5 17:30:04 2008
From: yuri at rawbw.com (Yuri)
Date: Tue Aug  5 17:30:10 2008
Subject: ports/126232: Linux ioctl TCGETS (0x5401)
Message-ID: <200808051730.m75HU4Lm085609@freefall.freebsd.org>

The following reply was made to PR ports/126232; it has been noted by GNATS.

From: Yuri <yuri@rawbw.com>
To: Cc: Chagin Dmitry <chagin.dmitry@gmail.com>, bug-followup@freebsd.org,
        dchagin@freebsd.org
Subject: Re: ports/126232: Linux ioctl TCGETS (0x5401)
Date: Tue, 05 Aug 2008 10:20:55 -0700

 Here is the relevant piece of information I found on usenet:
 <<
 TCGETA is the predecessor to *TCGETS*.  It uses the termio structure, 
 not the
 termios structure.  The difference is that the flag members in termio are
 of type unsigned short, while in termios they're tcflag_t, which is
 unsigned long on a Sun.
  >>
 
From chagin.dmitry at gmail.com  Tue Aug  5 18:00:09 2008
From: chagin.dmitry at gmail.com (Chagin Dmitry)
Date: Tue Aug  5 18:00:15 2008
Subject: ports/126232: Linux ioctl TCGETS (0x5401)
Message-ID: <200808051800.m75I068u088197@freefall.freebsd.org>

The following reply was made to PR ports/126232; it has been noted by GNATS.

From: Chagin Dmitry <chagin.dmitry@gmail.com>
To: Yuri <yuri@rawbw.com>
Cc: Chagin Dmitry <chagin.dmitry@gmail.com>, bug-followup@freebsd.org, 
    dchagin@freebsd.org
Subject: Re: ports/126232: Linux ioctl TCGETS (0x5401)
Date: Tue, 5 Aug 2008 21:52:26 +0400 (MSD)

 On Tue, 5 Aug 2008, Yuri wrote:
 
 > Chagin Dmitry wrote:
 >> Actually it not absolutelly so, tcgetattr() it is a glibc function
 >> which uses ioctl TCGETS inside.
 >> 
 >
 > Actually on FreeBSD tcgetattr() is typedefed to ioctl TCGETA.
 >
 > In short this PR asks to implement TCGETS in Linux emulator.
 >
 
 It is already implemented, see sys/compat/linux/linux_ioctl.c
 from line 670
 tcgetattr fails if file descriptor is not a tty, may be problem here?
 
 >> 
 >> I think that the author should give more information, at least explain
 >> on what specifies a file descriptor.
 >
 > Which author?
 >
 
 certainly, author ot the PR
 
 -- 
 Have fun!
 chd
From dchagin at freebsd.org  Sun Aug 10 11:49:33 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sun Aug 10 11:49:40 2008
Subject: x86_64 linuxulator patches
Message-ID: <20080810072013.GA15196@dchagin.dialup.corbina.ru>

Hi, as promised, I place x86_64 linuxulator patches.

here the basic patch:
http://78.107.232.239/linuxulator64-current.patch

here recvmsg && sendmsg patch (not tested with really applications):
http://78.107.232.239/send-recv-msg.patch

here master repository:
git://78.107.232.239/linuxulator

and ports used for testing (and only for testing):
git://78.107.232.239/linux_base-f8
git://78.107.232.239/linux_devel-f8
git://78.107.232.239/linux_kdump-1.6

by default on amd64 builds i386 linuxulator, for build x86_64 use
cd sys/modules/linux
make -D COMPAT_LINUX64

for correct recognition of what linuxulator version is used
added new sysctl compat.linux.platform
for example use in ports Makefile's:

LINUX_PLATFORM!=        /sbin/sysctl -n compat.linux.platform 2>/dev/null

.if ${LINUX_PLATFORM}x == "x"
IGNORE=                 linuxulator is not (kld)loaded
.elif ${LINUX_PLATFORM} == "i386"
LINUX_RPM_ARCH=         i386
.elif ${LINUX_PLATFORM} == "x86_64"
LINUX_RPM_ARCH=         x86_64
SFX=                    64
.else
IGNORE=                 ${LINUX_PLATFORM} is not supported
.endif

I shal glad to remarks, proposals and results of testing.
thnx

-- 
Have fun!
chd
From kostikbel at gmail.com  Sun Aug 10 11:54:11 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Aug 10 11:54:17 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
Message-ID: <20080810115406.GR97161@deviant.kiev.zoral.com.ua>

On Sun, Aug 10, 2008 at 11:20:13AM +0400, Chagin Dmitry wrote:
> Hi, as promised, I place x86_64 linuxulator patches.
> 
> here the basic patch:
> http://78.107.232.239/linuxulator64-current.patch
> 
> here recvmsg && sendmsg patch (not tested with really applications):
> http://78.107.232.239/send-recv-msg.patch
> 
> here master repository:
> git://78.107.232.239/linuxulator
> 
> and ports used for testing (and only for testing):
> git://78.107.232.239/linux_base-f8
> git://78.107.232.239/linux_devel-f8
> git://78.107.232.239/linux_kdump-1.6
> 
> by default on amd64 builds i386 linuxulator, for build x86_64 use
> cd sys/modules/linux
> make -D COMPAT_LINUX64
> 
> for correct recognition of what linuxulator version is used
> added new sysctl compat.linux.platform
> for example use in ports Makefile's:
> 
> LINUX_PLATFORM!=        /sbin/sysctl -n compat.linux.platform 2>/dev/null
> 
> .if ${LINUX_PLATFORM}x == "x"
> IGNORE=                 linuxulator is not (kld)loaded
> .elif ${LINUX_PLATFORM} == "i386"
> LINUX_RPM_ARCH=         i386
> .elif ${LINUX_PLATFORM} == "x86_64"
> LINUX_RPM_ARCH=         x86_64
> SFX=                    64
> .else
> IGNORE=                 ${LINUX_PLATFORM} is not supported
> .endif
> 
> I shal glad to remarks, proposals and results of testing.
> thnx

Reading your email, I got an impression that i386/linux and x86_64/linux
ABI emulators are mutually exclusive. Is this right ? I think it would
be most useful to be able to have them both in one kernel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080810/b4c85df3/attachment.pgp
From dchagin at freebsd.org  Sun Aug 10 12:04:21 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sun Aug 10 12:04:27 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080810115406.GR97161@deviant.kiev.zoral.com.ua>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
Message-ID: <20080810120424.GA15768@dchagin.dialup.corbina.ru>

On Sun, Aug 10, 2008 at 02:54:06PM +0300, Kostik Belousov wrote:
> On Sun, Aug 10, 2008 at 11:20:13AM +0400, Chagin Dmitry wrote:
> > Hi, as promised, I place x86_64 linuxulator patches.
> > 
> > here the basic patch:
> > http://78.107.232.239/linuxulator64-current.patch
> > 
> > here recvmsg && sendmsg patch (not tested with really applications):
> > http://78.107.232.239/send-recv-msg.patch
> > 
> > here master repository:
> > git://78.107.232.239/linuxulator
> > 
> > and ports used for testing (and only for testing):
> > git://78.107.232.239/linux_base-f8
> > git://78.107.232.239/linux_devel-f8
> > git://78.107.232.239/linux_kdump-1.6
> > 
> > by default on amd64 builds i386 linuxulator, for build x86_64 use
> > cd sys/modules/linux
> > make -D COMPAT_LINUX64
> > 
> > for correct recognition of what linuxulator version is used
> > added new sysctl compat.linux.platform
> > for example use in ports Makefile's:
> > 
> > LINUX_PLATFORM!=        /sbin/sysctl -n compat.linux.platform 2>/dev/null
> > 
> > .if ${LINUX_PLATFORM}x == "x"
> > IGNORE=                 linuxulator is not (kld)loaded
> > .elif ${LINUX_PLATFORM} == "i386"
> > LINUX_RPM_ARCH=         i386
> > .elif ${LINUX_PLATFORM} == "x86_64"
> > LINUX_RPM_ARCH=         x86_64
> > SFX=                    64
> > .else
> > IGNORE=                 ${LINUX_PLATFORM} is not supported
> > .endif
> > 
> > I shal glad to remarks, proposals and results of testing.
> > thnx
> 
> Reading your email, I got an impression that i386/linux and x86_64/linux
> ABI emulators are mutually exclusive. Is this right ? I think it would
> be most useful to be able to have them both in one kernel.

yes, it so. if there are ports working only on i386 it's necessary
to do it. I don't know such ports :(
thnx!

-- 
Have fun!
chd
From kostikbel at gmail.com  Sun Aug 10 12:21:29 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Sun Aug 10 12:21:36 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080810120424.GA15768@dchagin.dialup.corbina.ru>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
	<20080810120424.GA15768@dchagin.dialup.corbina.ru>
Message-ID: <20080810122124.GS97161@deviant.kiev.zoral.com.ua>

On Sun, Aug 10, 2008 at 04:04:24PM +0400, Chagin Dmitry wrote:
> On Sun, Aug 10, 2008 at 02:54:06PM +0300, Kostik Belousov wrote:
> > On Sun, Aug 10, 2008 at 11:20:13AM +0400, Chagin Dmitry wrote:
> > > Hi, as promised, I place x86_64 linuxulator patches.
> > > 
> > > here the basic patch:
> > > http://78.107.232.239/linuxulator64-current.patch
> > > 
> > > here recvmsg && sendmsg patch (not tested with really applications):
> > > http://78.107.232.239/send-recv-msg.patch
> > > 
> > > here master repository:
> > > git://78.107.232.239/linuxulator
> > > 
> > > and ports used for testing (and only for testing):
> > > git://78.107.232.239/linux_base-f8
> > > git://78.107.232.239/linux_devel-f8
> > > git://78.107.232.239/linux_kdump-1.6
> > > 
> > > by default on amd64 builds i386 linuxulator, for build x86_64 use
> > > cd sys/modules/linux
> > > make -D COMPAT_LINUX64
> > > 
> > > for correct recognition of what linuxulator version is used
> > > added new sysctl compat.linux.platform
> > > for example use in ports Makefile's:
> > > 
> > > LINUX_PLATFORM!=        /sbin/sysctl -n compat.linux.platform 2>/dev/null
> > > 
> > > .if ${LINUX_PLATFORM}x == "x"
> > > IGNORE=                 linuxulator is not (kld)loaded
> > > .elif ${LINUX_PLATFORM} == "i386"
> > > LINUX_RPM_ARCH=         i386
> > > .elif ${LINUX_PLATFORM} == "x86_64"
> > > LINUX_RPM_ARCH=         x86_64
> > > SFX=                    64
> > > .else
> > > IGNORE=                 ${LINUX_PLATFORM} is not supported
> > > .endif
> > > 
> > > I shal glad to remarks, proposals and results of testing.
> > > thnx
> > 
> > Reading your email, I got an impression that i386/linux and x86_64/linux
> > ABI emulators are mutually exclusive. Is this right ? I think it would
> > be most useful to be able to have them both in one kernel.
> 
> yes, it so. if there are ports working only on i386 it's necessary
> to do it. I don't know such ports :(

Whether there is a _port_ that has no amd64 counterpart for i386 one is
irrelevant there. The Linux ABI emulation is supposed to work not only with
a software installed from port, but with most binaries.

If emulating both ia32 and x86_64 simultaneously is technically feasible
(and I believe it is), then both should be available. i386->amd64 is
not the replacement step, this is an backward-compatible upgrade.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080810/06b6c99a/attachment.pgp
From dchagin at freebsd.org  Sun Aug 10 12:42:37 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sun Aug 10 12:42:43 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080810122124.GS97161@deviant.kiev.zoral.com.ua>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
	<20080810120424.GA15768@dchagin.dialup.corbina.ru>
	<20080810122124.GS97161@deviant.kiev.zoral.com.ua>
Message-ID: <20080810124236.GA15947@dchagin.dialup.corbina.ru>

On Sun, Aug 10, 2008 at 03:21:24PM +0300, Kostik Belousov wrote:
> On Sun, Aug 10, 2008 at 04:04:24PM +0400, Chagin Dmitry wrote:
> > On Sun, Aug 10, 2008 at 02:54:06PM +0300, Kostik Belousov wrote:
> > > On Sun, Aug 10, 2008 at 11:20:13AM +0400, Chagin Dmitry wrote:
> > > > Hi, as promised, I place x86_64 linuxulator patches.
> > > > 
> > > > here the basic patch:
> > > > http://78.107.232.239/linuxulator64-current.patch
> > > > 
> > > > here recvmsg && sendmsg patch (not tested with really applications):
> > > > http://78.107.232.239/send-recv-msg.patch
> > > > 
> > > > here master repository:
> > > > git://78.107.232.239/linuxulator
> > > > 
> > > > and ports used for testing (and only for testing):
> > > > git://78.107.232.239/linux_base-f8
> > > > git://78.107.232.239/linux_devel-f8
> > > > git://78.107.232.239/linux_kdump-1.6
> > > > 
> > > > by default on amd64 builds i386 linuxulator, for build x86_64 use
> > > > cd sys/modules/linux
> > > > make -D COMPAT_LINUX64
> > > > 
> > > > for correct recognition of what linuxulator version is used
> > > > added new sysctl compat.linux.platform
> > > > for example use in ports Makefile's:
> > > > 
> > > > LINUX_PLATFORM!=        /sbin/sysctl -n compat.linux.platform 2>/dev/null
> > > > 
> > > > .if ${LINUX_PLATFORM}x == "x"
> > > > IGNORE=                 linuxulator is not (kld)loaded
> > > > .elif ${LINUX_PLATFORM} == "i386"
> > > > LINUX_RPM_ARCH=         i386
> > > > .elif ${LINUX_PLATFORM} == "x86_64"
> > > > LINUX_RPM_ARCH=         x86_64
> > > > SFX=                    64
> > > > .else
> > > > IGNORE=                 ${LINUX_PLATFORM} is not supported
> > > > .endif
> > > > 
> > > > I shal glad to remarks, proposals and results of testing.
> > > > thnx
> > > 
> > > Reading your email, I got an impression that i386/linux and x86_64/linux
> > > ABI emulators are mutually exclusive. Is this right ? I think it would
> > > be most useful to be able to have them both in one kernel.
> > 
> > yes, it so. if there are ports working only on i386 it's necessary
> > to do it. I don't know such ports :(
> 
> Whether there is a _port_ that has no amd64 counterpart for i386 one is
> irrelevant there. The Linux ABI emulation is supposed to work not only with
> a software installed from port, but with most binaries.
> 

ok, I was glad it to read through :)

> If emulating both ia32 and x86_64 simultaneously is technically feasible
> (and I believe it is), then both should be available. i386->amd64 is
> not the replacement step, this is an backward-compatible upgrade.

I think that it not difficulty. two modules and two /compat/linux[SFX]
but it is necesary to think well,
and the opinion of ports maintainers is interesting.


-- 
Have fun!
chd
From ady at freebsd.ady.ro  Sun Aug 10 12:57:09 2008
From: ady at freebsd.ady.ro (Adrian Penisoara)
Date: Sun Aug 10 12:57:16 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080810124236.GA15947@dchagin.dialup.corbina.ru>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
	<20080810120424.GA15768@dchagin.dialup.corbina.ru>
	<20080810122124.GS97161@deviant.kiev.zoral.com.ua>
	<20080810124236.GA15947@dchagin.dialup.corbina.ru>
Message-ID: <78cb3d3f0808100557p2c958c4fq80c4d39507e58bea@mail.gmail.com>

Hi,

>> If emulating both ia32 and x86_64 simultaneously is technically feasible
>> (and I believe it is), then both should be available. i386->amd64 is
>> not the replacement step, this is an backward-compatible upgrade.
>
> I think that it not difficulty. two modules and two /compat/linux[SFX]
> but it is necesary to think well,
> and the opinion of ports maintainers is interesting.
>

 I'm working towards releasing a port for running Oracle XE w/ Linux
(x86) binaries on FreeBSD. Oracle XE has been working fine for me on
FreeBSD for quite a long time now and I'm pretty sure that the
Enterprise version does too. For the Enterprise releases there are
also (Linux) x86-64 binaries and for an Oracle DB I believe it would
make a difference.

 Also it's not unusual for a system to run multiple version (even
32bit/64bit) Oracle instances. So this would be a benefit.

Regards,
Adrian.
From dchagin at freebsd.org  Sun Aug 10 13:23:16 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sun Aug 10 13:23:24 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <78cb3d3f0808100557p2c958c4fq80c4d39507e58bea@mail.gmail.com>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
	<20080810120424.GA15768@dchagin.dialup.corbina.ru>
	<20080810122124.GS97161@deviant.kiev.zoral.com.ua>
	<20080810124236.GA15947@dchagin.dialup.corbina.ru>
	<78cb3d3f0808100557p2c958c4fq80c4d39507e58bea@mail.gmail.com>
Message-ID: <20080810132319.GA16145@dchagin.dialup.corbina.ru>

On Sun, Aug 10, 2008 at 02:57:08PM +0200, Adrian Penisoara wrote:
> Hi,
> 
> >> If emulating both ia32 and x86_64 simultaneously is technically feasible
> >> (and I believe it is), then both should be available. i386->amd64 is
> >> not the replacement step, this is an backward-compatible upgrade.
> >
> > I think that it not difficulty. two modules and two /compat/linux[SFX]
> > but it is necesary to think well,
> > and the opinion of ports maintainers is interesting.
> >
> 
>  I'm working towards releasing a port for running Oracle XE w/ Linux
> (x86) binaries on FreeBSD. Oracle XE has been working fine for me on
> FreeBSD for quite a long time now and I'm pretty sure that the
> Enterprise version does too. For the Enterprise releases there are
> also (Linux) x86-64 binaries and for an Oracle DB I believe it would
> make a difference.


Enterprise version (buffer cache part) depends on shm_(open|unlink)
behaviour, which differ in glibc-2.7 and fbsd.
I now investigate sysvshm and it...

> 
>  Also it's not unusual for a system to run multiple version (even
> 32bit/64bit) Oracle instances. So this would be a benefit.
> 

ok
thnx!

-- 
Have fun!
chd
From rdivacky at freebsd.org  Sun Aug 10 20:06:00 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Sun Aug 10 20:06:07 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
Message-ID: <20080810200436.GA29426@freebsd.org>

On Sun, Aug 10, 2008 at 11:20:13AM +0400, Chagin Dmitry wrote:
> Hi, as promised, I place x86_64 linuxulator patches.

can you give an overview what to expect from this? what
kind of problems people should report, what are known problems
etc.

also.. I believe you have an access to FreeBSD wiki - can you make
a page there describing the status of this? Plus a howto about
setting it up etc.

thnx a lot!

roman
From eculp at encontacto.net  Mon Aug 11 01:46:28 2008
From: eculp at encontacto.net (eculp)
Date: Mon Aug 11 01:46:34 2008
Subject: wine and MS InternetExplorer
Message-ID: <20080810204625.18453tshxwqgptkw@econet.encontacto.net>

Is there any way to get MS Internet explorer to work under wine.  The  
government here has some forms that require it and won't work with  
firefox or opera.  The part that bothers me even more is that they  
seem to be microsoft java apps.

I see there is an iexplorer in the distribution and I added gecko  
support but still couldn't get more that a transparent box.

Thanks,

ed
From bugmaster at FreeBSD.org  Mon Aug 11 11:06:56 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Aug 11 11:07:25 2008
Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org
Message-ID: <200808111106.m7BB6ttd047154@freefall.freebsd.org>

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/21463   emulation  [linux] Linux compatability mode should not allow setu
o kern/97326   emulation  [linux] file descriptor leakage in linux emulation
o kern/117010  emulation  [linux] linux_getdents() get something like buffer ove

3 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/11165   emulation  [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999
o kern/29698   emulation  [linux] [patch] linux ipcs doesn'work
o kern/39201   emulation  [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu
o kern/41543   emulation  [patch] [request] easier wine/w23 support
a kern/72920   emulation  [linux]: path "prefixing" is not done on unix domain s
o kern/73777   emulation  [linux] [patch] linux emulation: root dir special hand
o kern/91293   emulation  [svr4] [patch] *Experimental* Update to the SVR4 emula
o ports/91318  emulation  [fix] graphics/linux_dri: works on amd64 too
o ports/121800 emulation  x11-toolkits/linux-openmotif - OpenMotif upgrade to 2.
o kern/122318  emulation  [linux] [cmake]: Segmentation fault when running Linux
o ports/123960 emulation  Port fix: archivers/linux-par2cmdline - better handlin
o ports/123964 emulation  Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS
o ports/126232 emulation  Linux ioctl TCGETS (0x5401) always fails

13 problems total.

From scf at FreeBSD.org  Mon Aug 11 20:07:35 2008
From: scf at FreeBSD.org (Sean C. Farley)
Date: Mon Aug 11 20:07:41 2008
Subject: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <20080726083110.5d932695@deskjail>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<20080723184450.GA25356@freebsd.org>
	<alpine.BSF.1.10.0807231459030.12600@thor.farley.org>
	<alpine.BSF.1.10.0807240016340.28898@ora.chd.net>
	<alpine.BSF.1.10.0807231616570.12600@thor.farley.org>
	<20080725082156.GA41887@freebsd.org>
	<20080725083122.GA42835@freebsd.org>
	<alpine.BSF.1.10.0807251233470.1710@ora.chd.net>
	<alpine.BSF.1.10.0807251231050.30805@thor.farley.org>
	<alpine.BSF.1.10.0807252318130.1162@ora.chd.net>
	<alpine.BSF.1.10.0807251511230.31063@thor.farley.org>
	<20080726083110.5d932695@deskjail>
Message-ID: <alpine.BSF.1.10.0808111500420.9196@thor.farley.org>

On Sat, 26 Jul 2008, Alexander Leidinger wrote:

> Quoting "Sean C. Farley" <scf@FreeBSD.org> (Fri, 25 Jul 2008 15:36:52
> -0500 (CDT)):
>> On Fri, 25 Jul 2008, Chagin Dmitry wrote:
>
>>> uname must work on all supported linuxulators
>>
>> I agree, and it does work until I start playing with the Linux
>> version.
>
> Don't play with the linux version while linux programs are running.
> Changing the version from 2.4.x to 2.6.x and vice versa while a
> program is running is not supported at all and known to cause havoc.
> Roman, do we have the possibility to make an easy check in the sysctl
> handler if a linux program is still running and return an error from
> the handler?  Did I forgot something which makes it impossible to
> switch when a program was run under 2.6 and stopped?

I understand.  This is the first thing I surmised it was since I had
originally changed the versions while a Linux application was running.

> Sean, can you rule out the possibility that a program was still
> running under another version when you've seen the problems with
> uname?

Actually, I was having trouble (at #3 and #9) after:
1. Stopping all Linux applications.
2. Changing the Linux version from 2.6.16 (set at boot in
    /etc/sysctl.conf) to 2.4.2.
3. Running an application.
4. Unmounting linprocfs and linsysfs mount points.
5. Unloading  linux, linprocfs and linsysfs modules.
6. Loading  linux, linprocfs and linsysfs modules.
7. Mounting linprocfs and linsysfs mount points.
8. Setting Linux version to 2.6.16.
9. Running an application.

I do not see how the failures could continue at #9.  How could it carry
the state even after unloading all of the Linux modules?

Sean
-- 
scf@FreeBSD.org
From scf at FreeBSD.org  Mon Aug 11 20:14:53 2008
From: scf at FreeBSD.org (Sean C. Farley)
Date: Mon Aug 11 20:14:59 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
Message-ID: <alpine.BSF.1.10.0808111509280.9196@thor.farley.org>

On Sun, 3 Aug 2008, Chagin Dmitry wrote:

> On Wed, 23 Jul 2008, Sean C. Farley wrote:
>
>> I am seeing if anyone has any insight on this PR (kern/122318[1]).
>> It would be nice to once again build using cmake within a Linux
>> chroot.  :)
>> 
>> Basically, the bug is that not only that cmake is dumping core; it is
>> also forcing the user out of the chroot environment.  Here is the
>> command used to start the chroot:
>> /compat/linux/usr/sbin/chroot <chroot path> su - <build user>
>> 
>> Thank you.
>> 
>> Sean
>>  1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
>
> here patches for -current and releng_7:
> http://78.107.232.239/rt_signals-current.patch
> http://78.107.232.239/rt_signals-releng_7.patch
>
> what patch do:
> - rt sigtramp code works (this solves PR)
> - align stack pointers
> - remove kern_sigaltstack() at the end of rt_sigreturn(), it's a
>   bogus.
> Here there is some information on it:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1283.html

I just tried this patch.  It helps somewhat in that cmake does not die
immediately when running gcc, which may be dieing itself, but other
applications such as zsh and acroread start coring.  With acroread, it
is actually bash, but bash does not core when run directly.

This is on an amd64 system.

Sean
-- 
scf@FreeBSD.org
From kostikbel at gmail.com  Tue Aug 12 09:22:11 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Tue Aug 12 09:22:18 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <alpine.BSF.1.10.0808111509280.9196@thor.farley.org>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
	<alpine.BSF.1.10.0808111509280.9196@thor.farley.org>
Message-ID: <20080812092206.GC2852@deviant.kiev.zoral.com.ua>

On Mon, Aug 11, 2008 at 03:14:50PM -0500, Sean C. Farley wrote:
> On Sun, 3 Aug 2008, Chagin Dmitry wrote:
> 
> >On Wed, 23 Jul 2008, Sean C. Farley wrote:
> >
> >>I am seeing if anyone has any insight on this PR (kern/122318[1]).
> >>It would be nice to once again build using cmake within a Linux
> >>chroot.  :)
> >>
> >>Basically, the bug is that not only that cmake is dumping core; it is
> >>also forcing the user out of the chroot environment.  Here is the
> >>command used to start the chroot:
> >>/compat/linux/usr/sbin/chroot <chroot path> su - <build user>
> >>
> >>Thank you.
> >>
> >>Sean
> >> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
> >
> >here patches for -current and releng_7:
> >http://78.107.232.239/rt_signals-current.patch
> >http://78.107.232.239/rt_signals-releng_7.patch
> >
> >what patch do:
> >- rt sigtramp code works (this solves PR)
> >- align stack pointers
> >- remove kern_sigaltstack() at the end of rt_sigreturn(), it's a
> >  bogus.
> >Here there is some information on it:
> >http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1283.html
> 
> I just tried this patch.  It helps somewhat in that cmake does not die
> immediately when running gcc, which may be dieing itself, but other
> applications such as zsh and acroread start coring.  With acroread, it
> is actually bash, but bash does not core when run directly.
> 
> This is on an amd64 system.

CURRENT (what date ?) or RELENG_7 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080812/134cf829/attachment.pgp
From ady at freebsd.ady.ro  Tue Aug 12 09:38:20 2008
From: ady at freebsd.ady.ro (Adrian Penisoara)
Date: Tue Aug 12 09:38:27 2008
Subject: wine and MS InternetExplorer
In-Reply-To: <20080810204625.18453tshxwqgptkw@econet.encontacto.net>
References: <20080810204625.18453tshxwqgptkw@econet.encontacto.net>
Message-ID: <78cb3d3f0808120238k163092bfw2e3f5b49a33c9773@mail.gmail.com>

Hi,

On Mon, Aug 11, 2008 at 3:46 AM, eculp <eculp@encontacto.net> wrote:
> Is there any way to get MS Internet explorer to work under wine.  The
> government here has some forms that require it and won't work with firefox
> or opera.  The part that bothers me even more is that they seem to be
> microsoft java apps.
>
> I see there is an iexplorer in the distribution and I added gecko support
> but still couldn't get more that a transparent box.

 There is the IEs4Linux project which theoretically could be used also
on FreeBSD -- see the link below, follow the installation instructions
and let us know what results you get.

    http://www.tatanka.com.br/ies4linux/

  Apparently there is no FreeBSD port for this at this time, but if it
works for you then I guess it would make a really good candidate
(especially for enterprise/office environments).

Regards,
Adrian.
From scf at FreeBSD.org  Tue Aug 12 13:36:19 2008
From: scf at FreeBSD.org (Sean C. Farley)
Date: Tue Aug 12 13:36:25 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <20080812092206.GC2852@deviant.kiev.zoral.com.ua>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
	<alpine.BSF.1.10.0808111509280.9196@thor.farley.org>
	<20080812092206.GC2852@deviant.kiev.zoral.com.ua>
Message-ID: <alpine.BSF.1.10.0808120833510.16715@thor.farley.org>

On Tue, 12 Aug 2008, Kostik Belousov wrote:

> On Mon, Aug 11, 2008 at 03:14:50PM -0500, Sean C. Farley wrote:
>> On Sun, 3 Aug 2008, Chagin Dmitry wrote:
>>> On Wed, 23 Jul 2008, Sean C. Farley wrote:
>>>
>>>> I am seeing if anyone has any insight on this PR (kern/122318[1]).
>>>> It would be nice to once again build using cmake within a Linux
>>>> chroot.  :)
>>>>
>>>> Basically, the bug is that not only that cmake is dumping core; it
>>>> is also forcing the user out of the chroot environment.  Here is
>>>> the command used to start the chroot:
>>>> /compat/linux/usr/sbin/chroot <chroot path> su - <build user>
>>>>
>>>> Thank you.
>>>>
>>>> Sean
>>>> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
>>>
>>> here patches for -current and releng_7:
>>> http://78.107.232.239/rt_signals-current.patch
>>> http://78.107.232.239/rt_signals-releng_7.patch
>>>
>>> what patch do:
>>> - rt sigtramp code works (this solves PR)
>>> - align stack pointers
>>> - remove kern_sigaltstack() at the end of rt_sigreturn(), it's a
>>>  bogus.
>>> Here there is some information on it:
>>> http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1283.html
>>
>> I just tried this patch.  It helps somewhat in that cmake does not
>> die immediately when running gcc, which may be dieing itself, but
>> other applications such as zsh and acroread start coring.  With
>> acroread, it is actually bash, but bash does not core when run
>> directly.
>>
>> This is on an amd64 system.
>
> CURRENT (what date ?) or RELENG_7 ?

RELENG_7 fairly recent (r181375).  Without the patch, there are no
problems.  I really like that uname displays the revision.

Sean
-- 
scf@FreeBSD.org
From kostikbel at gmail.com  Tue Aug 12 14:18:40 2008
From: kostikbel at gmail.com (Kostik Belousov)
Date: Tue Aug 12 14:18:47 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <alpine.BSF.1.10.0808120833510.16715@thor.farley.org>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
	<alpine.BSF.1.10.0808111509280.9196@thor.farley.org>
	<20080812092206.GC2852@deviant.kiev.zoral.com.ua>
	<alpine.BSF.1.10.0808120833510.16715@thor.farley.org>
Message-ID: <20080812141831.GB1803@deviant.kiev.zoral.com.ua>

On Tue, Aug 12, 2008 at 08:36:16AM -0500, Sean C. Farley wrote:
> On Tue, 12 Aug 2008, Kostik Belousov wrote:
> 
> >On Mon, Aug 11, 2008 at 03:14:50PM -0500, Sean C. Farley wrote:
> >>On Sun, 3 Aug 2008, Chagin Dmitry wrote:
> >>>On Wed, 23 Jul 2008, Sean C. Farley wrote:
> >>>
> >>>>I am seeing if anyone has any insight on this PR (kern/122318[1]).
> >>>>It would be nice to once again build using cmake within a Linux
> >>>>chroot.  :)
> >>>>
> >>>>Basically, the bug is that not only that cmake is dumping core; it
> >>>>is also forcing the user out of the chroot environment.  Here is
> >>>>the command used to start the chroot:
> >>>>/compat/linux/usr/sbin/chroot <chroot path> su - <build user>
> >>>>
> >>>>Thank you.
> >>>>
> >>>>Sean
> >>>>1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
> >>>
> >>>here patches for -current and releng_7:
> >>>http://78.107.232.239/rt_signals-current.patch
> >>>http://78.107.232.239/rt_signals-releng_7.patch
> >>>
> >>>what patch do:
> >>>- rt sigtramp code works (this solves PR)
> >>>- align stack pointers
> >>>- remove kern_sigaltstack() at the end of rt_sigreturn(), it's a
> >>> bogus.
> >>>Here there is some information on it:
> >>>http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1283.html
> >>
> >>I just tried this patch.  It helps somewhat in that cmake does not
> >>die immediately when running gcc, which may be dieing itself, but
> >>other applications such as zsh and acroread start coring.  With
> >>acroread, it is actually bash, but bash does not core when run
> >>directly.
> >>
> >>This is on an amd64 system.
> >
> >CURRENT (what date ?) or RELENG_7 ?
> 
> RELENG_7 fairly recent (r181375).  Without the patch, there are no
> problems.  I really like that uname displays the revision.

As a wild guess, please merge r180992 and try again. I doubt that this
is the reason for the problem, but it might be.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080812/76341449/attachment.pgp
From dchagin at freebsd.org  Tue Aug 12 16:35:55 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Tue Aug 12 16:36:02 2008
Subject: [PATCH]Re: kern/122318 (CMake core dumping, chroot exiting)
In-Reply-To: <alpine.BSF.1.10.0808111509280.9196@thor.farley.org>
References: <alpine.BSF.1.10.0807231236140.12600@thor.farley.org>
	<alpine.BSF.1.10.0808030024140.81282@ora.chd.net>
	<alpine.BSF.1.10.0808111509280.9196@thor.farley.org>
Message-ID: <20080812163547.GA6520@dchagin.dialup.corbina.ru>

On Mon, Aug 11, 2008 at 03:14:50PM -0500, Sean C. Farley wrote:
> On Sun, 3 Aug 2008, Chagin Dmitry wrote:
> 
> >On Wed, 23 Jul 2008, Sean C. Farley wrote:
> >
> >>I am seeing if anyone has any insight on this PR (kern/122318[1]).
> >>It would be nice to once again build using cmake within a Linux
> >>chroot.  :)
> >>
> >>Basically, the bug is that not only that cmake is dumping core; it is
> >>also forcing the user out of the chroot environment.  Here is the
> >>command used to start the chroot:
> >>/compat/linux/usr/sbin/chroot <chroot path> su - <build user>
> >>
> >>Thank you.
> >>
> >>Sean
> >> 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122318
> >
> >here patches for -current and releng_7:
> >http://78.107.232.239/rt_signals-current.patch
> >http://78.107.232.239/rt_signals-releng_7.patch
> >
> >what patch do:
> >- rt sigtramp code works (this solves PR)
> >- align stack pointers
> >- remove kern_sigaltstack() at the end of rt_sigreturn(), it's a
> >  bogus.
> >Here there is some information on it:
> >http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1283.html
> 
> I just tried this patch.  It helps somewhat in that cmake does not die
> immediately when running gcc, which may be dieing itself, but other
> applications such as zsh and acroread start coring.  With acroread, it
> is actually bash, but bash does not core when run directly.
> 
> This is on an amd64 system.
> 

strange, please, ktrace/kdump output


-- 
Have fun!
chd
From eculp at encontacto.net  Wed Aug 13 13:27:40 2008
From: eculp at encontacto.net (eculp)
Date: Wed Aug 13 13:27:56 2008
Subject: wine and MS InternetExplorer
In-Reply-To: <78cb3d3f0808120238k163092bfw2e3f5b49a33c9773@mail.gmail.com>
References: <20080810204625.18453tshxwqgptkw@econet.encontacto.net>
	<78cb3d3f0808120238k163092bfw2e3f5b49a33c9773@mail.gmail.com>
Message-ID: <20080813082735.113561o9a39zgwsg@econet.encontacto.net>

Quoting Adrian Penisoara <ady@freebsd.ady.ro>:

> Hi,
>
> On Mon, Aug 11, 2008 at 3:46 AM, eculp <eculp@encontacto.net> wrote:
>> Is there any way to get MS Internet explorer to work under wine.  The
>> government here has some forms that require it and won't work with firefox
>> or opera.  The part that bothers me even more is that they seem to be
>> microsoft java apps.
>>
>> I see there is an iexplorer in the distribution and I added gecko support
>> but still couldn't get more that a transparent box.
>
>  There is the IEs4Linux project which theoretically could be used also
> on FreeBSD -- see the link below, follow the installation instructions
> and let us know what results you get.
>
>     http://www.tatanka.com.br/ies4linux/
>
>   Apparently there is no FreeBSD port for this at this time, but if it
> works for you then I guess it would make a really good candidate
> (especially for enterprise/office environments)

Thanks, Adrian.  I took a look at it yesterday but didn't have time to  
install it.  I'm downloading it now. It will be interesting to see if  
it is complete enough to work with the government's windows centric  
forms. I will post results to the list asap

Thanks again,

ed
>
> Regards,
> Adrian.
>

From test at airbites.pl  Thu Aug 14 18:22:05 2008
From: test at airbites.pl (D5YBeO@pIU271iL2.com)
Date: Thu Aug 14 18:22:41 2008
Subject: Saludamos!
Message-ID: <616F7D94.DC11F0D2@airbites.pl>

¡Buenos días! 
Nosotros somos vendedores de televisores plasma de las  marcas famosas:
Samsung, LG, Sony, Philips.
Ahora estamos seleccionando consultantes a distancia para nuestros
clientes.
Le garantizamos de 200 a 500 € por semana, con su dedicación de 1 a 5 horas
por día.
Usted tan solo necesita tener un ordenador y un teléfono.
Para recibir la descripción detallada del trabajo, puede Usted escribir a
nuestro email: Alessio.Webdreamers.31@gmail.com
Por favor, indique en su carta su nombre, edad y ciudad de residencia. 


From volker at vwsoft.com  Thu Aug 14 20:52:23 2008
From: volker at vwsoft.com (Volker)
Date: Thu Aug 14 20:52:30 2008
Subject: wine and MS InternetExplorer
In-Reply-To: <20080813082735.113561o9a39zgwsg@econet.encontacto.net>
References: <20080810204625.18453tshxwqgptkw@econet.encontacto.net>	<78cb3d3f0808120238k163092bfw2e3f5b49a33c9773@mail.gmail.com>
	<20080813082735.113561o9a39zgwsg@econet.encontacto.net>
Message-ID: <48A494CC.60704@vwsoft.com>

On 12/23/-58 20:59, eculp wrote:
> Quoting Adrian Penisoara <ady@freebsd.ady.ro>:
> 
>> Hi,
>>
>> On Mon, Aug 11, 2008 at 3:46 AM, eculp <eculp@encontacto.net> wrote:
>>> Is there any way to get MS Internet explorer to work under wine.  The
>>> government here has some forms that require it and won't work with
>>> firefox
>>> or opera.  The part that bothers me even more is that they seem to be
>>> microsoft java apps.
>>>
>>> I see there is an iexplorer in the distribution and I added gecko
>>> support
>>> but still couldn't get more that a transparent box.
>>
>>  There is the IEs4Linux project which theoretically could be used also
>> on FreeBSD -- see the link below, follow the installation instructions
>> and let us know what results you get.
>>
>>     http://www.tatanka.com.br/ies4linux/
>>
>>   Apparently there is no FreeBSD port for this at this time, but if it
>> works for you then I guess it would make a really good candidate
>> (especially for enterprise/office environments)
> 
> Thanks, Adrian.  I took a look at it yesterday but didn't have time to
> install it.  I'm downloading it now. It will be interesting to see if it
> is complete enough to work with the government's windows centric forms.
> I will post results to the list asap
> 
> Thanks again,
> 
> ed
>>
>> Regards,
>> Adrian.
>>
> 
> 

ed,

I'm running IE6 under wine for quite some time now. IIRC I've installed
IE manually. Tried IES4Linux before and found it too difficult to patch
as it's too Linux'ish (heavily Linux specific bash install scripts needs
_a lot_ of tweaking).

You may find instructions for installation on the net. Make sure, you're
using latest wine and set the environment to Win98 for IE. Running such
a crappy tool (IE) under FreeBSD seems to be braindead, but there are
situations where there's no other way. BTW, check licensing issues first.

HTH

Volker
From eculp at encontacto.net  Thu Aug 14 22:52:21 2008
From: eculp at encontacto.net (eculp)
Date: Thu Aug 14 22:52:27 2008
Subject: wine and MS InternetExplorer
In-Reply-To: <48A494CC.60704@vwsoft.com>
References: <20080810204625.18453tshxwqgptkw@econet.encontacto.net>
	<78cb3d3f0808120238k163092bfw2e3f5b49a33c9773@mail.gmail.com>
	<20080813082735.113561o9a39zgwsg@econet.encontacto.net>
	<48A494CC.60704@vwsoft.com>
Message-ID: <20080814175218.187454uxox5q8tss@econet.encontacto.net>

Quoting Volker <volker@vwsoft.com>:

> On 12/23/-58 20:59, eculp wrote:
>> Quoting Adrian Penisoara <ady@freebsd.ady.ro>:
>>
>>> Hi,
>>>
>>> On Mon, Aug 11, 2008 at 3:46 AM, eculp <eculp@encontacto.net> wrote:
>>>> Is there any way to get MS Internet explorer to work under wine.  The
>>>> government here has some forms that require it and won't work with
>>>> firefox
>>>> or opera.  The part that bothers me even more is that they seem to be
>>>> microsoft java apps.
>>>>
>>>> I see there is an iexplorer in the distribution and I added gecko
>>>> support
>>>> but still couldn't get more that a transparent box.
>>>
>>>  There is the IEs4Linux project which theoretically could be used also
>>> on FreeBSD -- see the link below, follow the installation instructions
>>> and let us know what results you get.
>>>
>>>     http://www.tatanka.com.br/ies4linux/
>>>
>>>   Apparently there is no FreeBSD port for this at this time, but if it
>>> works for you then I guess it would make a really good candidate
>>> (especially for enterprise/office environments)
>>
>> Thanks, Adrian.  I took a look at it yesterday but didn't have time to
>> install it.  I'm downloading it now. It will be interesting to see if it
>> is complete enough to work with the government's windows centric forms.
>> I will post results to the list asap
>>
>> Thanks again,
>>
>> ed
>>>
>>> Regards,
>>> Adrian.
>>>
>>
>>
>
> ed,
>
> I'm running IE6 under wine for quite some time now. IIRC I've installed
> IE manually. Tried IES4Linux before and found it too difficult to patch
> as it's too Linux'ish (heavily Linux specific bash install scripts needs
> _a lot_ of tweaking).
>
> You may find instructions for installation on the net. Make sure, you're
> using latest wine and set the environment to Win98 for IE. Running such
> a crappy tool (IE) under FreeBSD seems to be braindead, but there are
> situations where there's no other way. BTW, check licensing issues first.

Thanks, Volker.  I agree with the part about brain dead but here you  
can't access many government forms with out it.  Governments aren't  
usually recognized for their technological brilliance.

I'm assuming that you are using only the executable because I have  
tried to download, unpack and install it windows style and it didn't  
want to cooperate.

This should be better than IES4Linux that I haven't got going yet.  It  
seems to want a newer wine and I'm running wine-1.1.2,1 and have't  
continued to investigate.

I'll give an IE6 executable a try.

Thanks again,

ed
From eculp at encontacto.net  Thu Aug 14 23:26:39 2008
From: eculp at encontacto.net (eculp)
Date: Thu Aug 14 23:26:49 2008
Subject: wine and MS InternetExplorer
In-Reply-To: <20080814175218.187454uxox5q8tss@econet.encontacto.net>
References: <20080810204625.18453tshxwqgptkw@econet.encontacto.net>
	<78cb3d3f0808120238k163092bfw2e3f5b49a33c9773@mail.gmail.com>
	<20080813082735.113561o9a39zgwsg@econet.encontacto.net>
	<48A494CC.60704@vwsoft.com>
	<20080814175218.187454uxox5q8tss@econet.encontacto.net>
Message-ID: <20080814182636.19753pe2v866l5yc@econet.encontacto.net>

Quoting eculp <eculp@encontacto.net>:

> Quoting Volker <volker@vwsoft.com>:
>
>> On 12/23/-58 20:59, eculp wrote:
>>> Quoting Adrian Penisoara <ady@freebsd.ady.ro>:
>>>
>>>> Hi,
>>>>
>>>> On Mon, Aug 11, 2008 at 3:46 AM, eculp <eculp@encontacto.net> wrote:
>>>>> Is there any way to get MS Internet explorer to work under wine.  The
>>>>> government here has some forms that require it and won't work with
>>>>> firefox
>>>>> or opera.  The part that bothers me even more is that they seem to be
>>>>> microsoft java apps.
>>>>>
>>>>> I see there is an iexplorer in the distribution and I added gecko
>>>>> support
>>>>> but still couldn't get more that a transparent box.
>>>>
>>>> There is the IEs4Linux project which theoretically could be used also
>>>> on FreeBSD -- see the link below, follow the installation instructions
>>>> and let us know what results you get.
>>>>
>>>>    http://www.tatanka.com.br/ies4linux/
>>>>
>>>>  Apparently there is no FreeBSD port for this at this time, but if it
>>>> works for you then I guess it would make a really good candidate
>>>> (especially for enterprise/office environments)
>>>
>>> Thanks, Adrian.  I took a look at it yesterday but didn't have time to
>>> install it.  I'm downloading it now. It will be interesting to see if it
>>> is complete enough to work with the government's windows centric forms.
>>> I will post results to the list asap
>>>
>>> Thanks again,
>>>
>>> ed
>>>>
>>>> Regards,
>>>> Adrian.
>>>>
>>>
>>>
>>
>> ed,
>>
>> I'm running IE6 under wine for quite some time now. IIRC I've installed
>> IE manually. Tried IES4Linux before and found it too difficult to patch
>> as it's too Linux'ish (heavily Linux specific bash install scripts needs
>> _a lot_ of tweaking).
>>
>> You may find instructions for installation on the net. Make sure, you're
>> using latest wine and set the environment to Win98 for IE. Running such
>> a crappy tool (IE) under FreeBSD seems to be braindead, but there are
>> situations where there's no other way. BTW, check licensing issues first.
>
> Thanks, Volker.  I agree with the part about brain dead but here you  
> can't access many government forms with out it.  Governments aren't  
> usually recognized for their technological brilliance.
>
> I'm assuming that you are using only the executable because I have  
> tried to download, unpack and install it windows style and it didn't  
> want to cooperate.
>
> This should be better than IES4Linux that I haven't got going yet.   
> It seems to want a newer wine and I'm running wine-1.1.2,1 and  
> have't continued to investigate.
>
> I'll give an IE6 executable a try.

Just got a copy of IE6 copied it and ran:
wine "/root/.wine/drive_c/Program Files/Internet Explorer/
explorer.exe"

and got:

fixme:shell:StopWatchMode () stub!
fixme:process:SetProcessShutdownParameters (00000002, 00000000): partial stub.
wine: Unhandled page fault on read access to 0x3534336c at address  
0x3534336c (thread 0009), starting debugger...

With loads like:
5680 root          1 102    0  5468K  3112K CPU1   1   0:49 32.28% wineserver
  5717 root          1  60    0 12172K  4244K CPU1   1   0:18  8.79%  
wine-pthread
  5678 root          1  57    0 23548K 12984K piperd 1   0:15  8.06%  
wine-pthread

My guess would be to find one a little bit older maybe.

Thanks,

ed

From bsam at FreeBSD.org  Fri Aug 15 12:30:50 2008
From: bsam at FreeBSD.org (bsam@FreeBSD.org)
Date: Fri Aug 15 12:30:56 2008
Subject: ports/123964: Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS
Message-ID: <200808151230.m7FCUn1F018254@freefall.freebsd.org>

Synopsis: Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS

State-Changed-From-To: open->closed
State-Changed-By: bsam
State-Changed-When: Fri Aug 15 12:30:39 UTC 2008
State-Changed-Why: 
Committed, thanks!

http://www.freebsd.org/cgi/query-pr.cgi?pr=123964
From dfilter at FreeBSD.ORG  Fri Aug 15 12:40:03 2008
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Fri Aug 15 12:40:10 2008
Subject: ports/123964: commit references a PR
Message-ID: <200808151240.m7FCe34l020499@freefall.freebsd.org>

The following reply was made to PR ports/123964; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/123964: commit references a PR
Date: Fri, 15 Aug 2008 12:30:03 +0000 (UTC)

 bsam        2008-08-15 12:29:42 UTC
 
   FreeBSD ports repository
 
   Modified files:
     Mk                   bsd.linux-rpm.mk 
   Log:
   Make bsd.linux-rpm.mk respect NOPORTDOCS variable.
   
   PR:             123964
   Submitted by:   Ganael Laplanche <ganael.laplanche at martymac.com>
   Discussed at:   emulation@
   
   Revision  Changes    Path
   1.13      +15 -1     ports/Mk/bsd.linux-rpm.mk
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
From hraghav.devel at gmail.com  Fri Aug 15 23:57:42 2008
From: hraghav.devel at gmail.com (H Raghav)
Date: Fri Aug 15 23:57:49 2008
Subject: VMWare 3 port on FreeBSD 7 STABLE
Message-ID: <7c299c6c0808151631g5bee92eay6038e89da6b8a348@mail.gmail.com>

Hi:

I am trying to run VMware 3 port from /usr/ports/emulators/vmware3 on
FreeBSD 7.0 STABLE. I did a make install from the /usr/ports as root
and the build and install went fine. It installed Linux Base FC4 and
then installed VMWare 3.

However, whenever I try to startup vmware, I get an error that
/dev/vmmon cannot be found. The error is:

Could not open /dev/vmmon: No such file or directory.
Please make sure that the kernel module `vmmon' is loaded.

Failed to initialize monitor device.

Linprocfs is mounted on /compat/linux/proc. I also ran the
/usr/local/rc.d/vmware.sh start and it reported that all modules are
already loaded.

kldstat reveals that vmmon_smp.ko is indeed loaded.

Based on some research, I found this issue reported in FreeBSD 5.4; I
believe the same is at work here. I am running on a DELL SMP hardware
(DELL Precision 530 Workstation).

http://lists.freebsd.org/pipermail/freebsd-bugs/2005-May/012725.html

Any way to fix this issue in FreeBSD 7? Is it due to the SMP hardware?
Can I make VMWare belive that it is running on Uniprocessor hardware?
From dchagin at freebsd.org  Sun Aug 17 18:18:49 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sun Aug 17 18:18:56 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080810122124.GS97161@deviant.kiev.zoral.com.ua>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
	<20080810120424.GA15768@dchagin.dialup.corbina.ru>
	<20080810122124.GS97161@deviant.kiev.zoral.com.ua>
Message-ID: <20080817181757.GA2940@dchagin.dialup.corbina.ru>

On Sun, Aug 10, 2008 at 03:21:24PM +0300, Kostik Belousov wrote:
> On Sun, Aug 10, 2008 at 04:04:24PM +0400, Chagin Dmitry wrote:
> > On Sun, Aug 10, 2008 at 02:54:06PM +0300, Kostik Belousov wrote:
> > > On Sun, Aug 10, 2008 at 11:20:13AM +0400, Chagin Dmitry wrote:
> > > > Hi, as promised, I place x86_64 linuxulator patches.
> > > > 
> > > > here the basic patch:
> > > > http://78.107.232.239/linuxulator64-current.patch
> > > > 
> > > > here recvmsg && sendmsg patch (not tested with really applications):
> > > > http://78.107.232.239/send-recv-msg.patch
> > > > 
> > > > here master repository:
> > > > git://78.107.232.239/linuxulator
> > > > 
> > > > and ports used for testing (and only for testing):
> > > > git://78.107.232.239/linux_base-f8
> > > > git://78.107.232.239/linux_devel-f8
> > > > git://78.107.232.239/linux_kdump-1.6
> > > > 
> > > > by default on amd64 builds i386 linuxulator, for build x86_64 use
> > > > cd sys/modules/linux
> > > > make -D COMPAT_LINUX64
> > > > 
> > > > for correct recognition of what linuxulator version is used
> > > > added new sysctl compat.linux.platform
> > > > for example use in ports Makefile's:
> > > > 
> > > > LINUX_PLATFORM!=        /sbin/sysctl -n compat.linux.platform 2>/dev/null
> > > > 
> > > > .if ${LINUX_PLATFORM}x == "x"
> > > > IGNORE=                 linuxulator is not (kld)loaded
> > > > .elif ${LINUX_PLATFORM} == "i386"
> > > > LINUX_RPM_ARCH=         i386
> > > > .elif ${LINUX_PLATFORM} == "x86_64"
> > > > LINUX_RPM_ARCH=         x86_64
> > > > SFX=                    64
> > > > .else
> > > > IGNORE=                 ${LINUX_PLATFORM} is not supported
> > > > .endif
> > > > 
> > > > I shal glad to remarks, proposals and results of testing.
> > > > thnx
> > > 
> > > Reading your email, I got an impression that i386/linux and x86_64/linux
> > > ABI emulators are mutually exclusive. Is this right ? I think it would
> > > be most useful to be able to have them both in one kernel.
> > 
> > yes, it so. if there are ports working only on i386 it's necessary
> > to do it. I don't know such ports :(
> 
> Whether there is a _port_ that has no amd64 counterpart for i386 one is
> irrelevant there. The Linux ABI emulation is supposed to work not only with
> a software installed from port, but with most binaries.
> 
> If emulating both ia32 and x86_64 simultaneously is technically feasible
> (and I believe it is), then both should be available. i386->amd64 is
> not the replacement step, this is an backward-compatible upgrade.

Something few the interested participants of discussion :)
problem in that I am not familiar with a ports infrastructure...

in my opinion the best decision for amd64 looks so. 
we use two modules. linux.ko for x86_64 and linux32.ko for ia32,
option COMPAT_LINUX for x86_64 and COMPAT_LINUX32 for ia32.
and two  linux_base directories: /compat/linux for x86_64
and /compat/linux32 for ia32.

there are other opinions?
thnx!

-- 
Have fun!
chd
From rdivacky at freebsd.org  Sun Aug 17 19:08:02 2008
From: rdivacky at freebsd.org (Roman Divacky)
Date: Sun Aug 17 19:08:09 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080817181757.GA2940@dchagin.dialup.corbina.ru>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
	<20080810120424.GA15768@dchagin.dialup.corbina.ru>
	<20080810122124.GS97161@deviant.kiev.zoral.com.ua>
	<20080817181757.GA2940@dchagin.dialup.corbina.ru>
Message-ID: <20080817190606.GA67621@freebsd.org>

On Sun, Aug 17, 2008 at 10:17:57PM +0400, Chagin Dmitry wrote:
> On Sun, Aug 10, 2008 at 03:21:24PM +0300, Kostik Belousov wrote:
> > On Sun, Aug 10, 2008 at 04:04:24PM +0400, Chagin Dmitry wrote:
> > > On Sun, Aug 10, 2008 at 02:54:06PM +0300, Kostik Belousov wrote:
> > > > On Sun, Aug 10, 2008 at 11:20:13AM +0400, Chagin Dmitry wrote:
> > > > > Hi, as promised, I place x86_64 linuxulator patches.
> > > > > 
> > > > > here the basic patch:
> > > > > http://78.107.232.239/linuxulator64-current.patch
> > > > > 
> > > > > here recvmsg && sendmsg patch (not tested with really applications):
> > > > > http://78.107.232.239/send-recv-msg.patch
> > > > > 
> > > > > here master repository:
> > > > > git://78.107.232.239/linuxulator
> > > > > 
> > > > > and ports used for testing (and only for testing):
> > > > > git://78.107.232.239/linux_base-f8
> > > > > git://78.107.232.239/linux_devel-f8
> > > > > git://78.107.232.239/linux_kdump-1.6
> > > > > 
> > > > > by default on amd64 builds i386 linuxulator, for build x86_64 use
> > > > > cd sys/modules/linux
> > > > > make -D COMPAT_LINUX64
> > > > > 
> > > > > for correct recognition of what linuxulator version is used
> > > > > added new sysctl compat.linux.platform
> > > > > for example use in ports Makefile's:
> > > > > 
> > > > > LINUX_PLATFORM!=        /sbin/sysctl -n compat.linux.platform 2>/dev/null
> > > > > 
> > > > > .if ${LINUX_PLATFORM}x == "x"
> > > > > IGNORE=                 linuxulator is not (kld)loaded
> > > > > .elif ${LINUX_PLATFORM} == "i386"
> > > > > LINUX_RPM_ARCH=         i386
> > > > > .elif ${LINUX_PLATFORM} == "x86_64"
> > > > > LINUX_RPM_ARCH=         x86_64
> > > > > SFX=                    64
> > > > > .else
> > > > > IGNORE=                 ${LINUX_PLATFORM} is not supported
> > > > > .endif
> > > > > 
> > > > > I shal glad to remarks, proposals and results of testing.
> > > > > thnx
> > > > 
> > > > Reading your email, I got an impression that i386/linux and x86_64/linux
> > > > ABI emulators are mutually exclusive. Is this right ? I think it would
> > > > be most useful to be able to have them both in one kernel.
> > > 
> > > yes, it so. if there are ports working only on i386 it's necessary
> > > to do it. I don't know such ports :(
> > 
> > Whether there is a _port_ that has no amd64 counterpart for i386 one is
> > irrelevant there. The Linux ABI emulation is supposed to work not only with
> > a software installed from port, but with most binaries.
> > 
> > If emulating both ia32 and x86_64 simultaneously is technically feasible
> > (and I believe it is), then both should be available. i386->amd64 is
> > not the replacement step, this is an backward-compatible upgrade.
> 
> Something few the interested participants of discussion :)
> problem in that I am not familiar with a ports infrastructure...
> 
> in my opinion the best decision for amd64 looks so. 
> we use two modules. linux.ko for x86_64 and linux32.ko for ia32,
> option COMPAT_LINUX for x86_64 and COMPAT_LINUX32 for ia32.
> and two  linux_base directories: /compat/linux for x86_64
> and /compat/linux32 for ia32.

I generally agree with that but the problem is that this breaks
POLA... :(
From Alexander at Leidinger.net  Mon Aug 18 08:05:51 2008
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Mon Aug 18 08:05:57 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080817181757.GA2940@dchagin.dialup.corbina.ru>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
	<20080810120424.GA15768@dchagin.dialup.corbina.ru>
	<20080810122124.GS97161@deviant.kiev.zoral.com.ua>
	<20080817181757.GA2940@dchagin.dialup.corbina.ru>
Message-ID: <20080818100541.20073jcxqbtyci80@webmail.leidinger.net>

Quoting "Chagin Dmitry" <dchagin@freebsd.org> (from Sun, 17 Aug 2008  
22:17:57 +0400):

> On Sun, Aug 10, 2008 at 03:21:24PM +0300, Kostik Belousov wrote:
>> On Sun, Aug 10, 2008 at 04:04:24PM +0400, Chagin Dmitry wrote:
>> > On Sun, Aug 10, 2008 at 02:54:06PM +0300, Kostik Belousov wrote:
>> > > On Sun, Aug 10, 2008 at 11:20:13AM +0400, Chagin Dmitry wrote:
>> > > > Hi, as promised, I place x86_64 linuxulator patches.
>> > > >
>> > > > here the basic patch:
>> > > > http://78.107.232.239/linuxulator64-current.patch
>> > > >
>> > > > here recvmsg && sendmsg patch (not tested with really applications):
>> > > > http://78.107.232.239/send-recv-msg.patch
>> > > >
>> > > > here master repository:
>> > > > git://78.107.232.239/linuxulator
>> > > >
>> > > > and ports used for testing (and only for testing):
>> > > > git://78.107.232.239/linux_base-f8
>> > > > git://78.107.232.239/linux_devel-f8
>> > > > git://78.107.232.239/linux_kdump-1.6
>> > > >
>> > > > by default on amd64 builds i386 linuxulator, for build x86_64 use
>> > > > cd sys/modules/linux
>> > > > make -D COMPAT_LINUX64
>> > > >
>> > > > for correct recognition of what linuxulator version is used
>> > > > added new sysctl compat.linux.platform
>> > > > for example use in ports Makefile's:
>> > > >
>> > > > LINUX_PLATFORM!=        /sbin/sysctl -n compat.linux.platform  
>> 2>/dev/null
>> > > >
>> > > > .if ${LINUX_PLATFORM}x == "x"
>> > > > IGNORE=                 linuxulator is not (kld)loaded
>> > > > .elif ${LINUX_PLATFORM} == "i386"
>> > > > LINUX_RPM_ARCH=         i386
>> > > > .elif ${LINUX_PLATFORM} == "x86_64"
>> > > > LINUX_RPM_ARCH=         x86_64
>> > > > SFX=                    64
>> > > > .else
>> > > > IGNORE=                 ${LINUX_PLATFORM} is not supported
>> > > > .endif
>> > > >
>> > > > I shal glad to remarks, proposals and results of testing.
>> > > > thnx
>> > >
>> > > Reading your email, I got an impression that i386/linux and x86_64/linux
>> > > ABI emulators are mutually exclusive. Is this right ? I think it would
>> > > be most useful to be able to have them both in one kernel.
>> >
>> > yes, it so. if there are ports working only on i386 it's necessary
>> > to do it. I don't know such ports :(
>>
>> Whether there is a _port_ that has no amd64 counterpart for i386 one is
>> irrelevant there. The Linux ABI emulation is supposed to work not only with
>> a software installed from port, but with most binaries.
>>
>> If emulating both ia32 and x86_64 simultaneously is technically feasible
>> (and I believe it is), then both should be available. i386->amd64 is
>> not the replacement step, this is an backward-compatible upgrade.
>
> Something few the interested participants of discussion :)
> problem in that I am not familiar with a ports infrastructure...
>
> in my opinion the best decision for amd64 looks so.
> we use two modules. linux.ko for x86_64 and linux32.ko for ia32,
> option COMPAT_LINUX for x86_64 and COMPAT_LINUX32 for ia32.
> and two  linux_base directories: /compat/linux for x86_64
> and /compat/linux32 for ia32.
>
> there are other opinions?

I propose:
  - /compat/linux64 for 64bit stuff
  - /compat/linux32 a symlink to /compat/linux
  - /compat/linux for 32bit stuff (we can think about having)

Reasons:
  - existing installations don't get fucked up with a partial update
    (very big point!)
  - we don't have to special case amd64-linux32 for LINUXBASE, we
    just have to distinguish 32 and 64 bit (maybe with switches
    USE_LINUX and USE_LINUX64, we have to have separate 64bit
    ports anyway, when we want to be able to install in parallel)

Bye,
Alexander.

-- 
If God wanted us to be brave, why did he give us legs?
		-- Marvin Kitman

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
From ady at freebsd.ady.ro  Mon Aug 18 08:38:03 2008
From: ady at freebsd.ady.ro (Adrian Penisoara)
Date: Mon Aug 18 08:38:09 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080818100541.20073jcxqbtyci80@webmail.leidinger.net>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
	<20080810120424.GA15768@dchagin.dialup.corbina.ru>
	<20080810122124.GS97161@deviant.kiev.zoral.com.ua>
	<20080817181757.GA2940@dchagin.dialup.corbina.ru>
	<20080818100541.20073jcxqbtyci80@webmail.leidinger.net>
Message-ID: <78cb3d3f0808180138o6c2e7c3bhf6f49b4de547b218@mail.gmail.com>

Hi,

On Mon, Aug 18, 2008 at 10:05 AM, Alexander Leidinger
<Alexander@leidinger.net> wrote:
>> in my opinion the best decision for amd64 looks so.
>> we use two modules. linux.ko for x86_64 and linux32.ko for ia32,
>> option COMPAT_LINUX for x86_64 and COMPAT_LINUX32 for ia32.
>> and two  linux_base directories: /compat/linux for x86_64
>> and /compat/linux32 for ia32.
>>
>> there are other opinions?
>
> I propose:
>  - /compat/linux64 for 64bit stuff
>  - /compat/linux32 a symlink to /compat/linux
>  - /compat/linux for 32bit stuff (we can think about having)
>

 I agree with this later proposition, it's a bad thing to break the
already established purpose for /compat/linux (32bit binaries).

 Here is yet another variation:
   /compat/linux64 -- 64bit
   /compat/linux32 -- 32bit
   /compat/linux -> linux32  -- symlink, would this break anything in
the current ports/packages ?

 I strongly oppose having linux.ko as the 64bit version, rather there
should be linux64.ko (linux-x86_64.ko ?) and linux32.ko (linux-ia32.ko
?) and perhaps we should make linux.ko try loading both of these
(since the user did not specify the intended platform).

Just a thought,
Adrian.
From Alexander at Leidinger.net  Mon Aug 18 10:11:37 2008
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Mon Aug 18 10:11:44 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <78cb3d3f0808180138o6c2e7c3bhf6f49b4de547b218@mail.gmail.com>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
	<20080810120424.GA15768@dchagin.dialup.corbina.ru>
	<20080810122124.GS97161@deviant.kiev.zoral.com.ua>
	<20080817181757.GA2940@dchagin.dialup.corbina.ru>
	<20080818100541.20073jcxqbtyci80@webmail.leidinger.net>
	<78cb3d3f0808180138o6c2e7c3bhf6f49b4de547b218@mail.gmail.com>
Message-ID: <20080818121127.745322h5l2ufrxs0@webmail.leidinger.net>

Quoting "Adrian Penisoara" <ady@freebsd.ady.ro> (from Mon, 18 Aug 2008  
10:38:02 +0200):

> Hi,
>
> On Mon, Aug 18, 2008 at 10:05 AM, Alexander Leidinger
> <Alexander@leidinger.net> wrote:
>>> in my opinion the best decision for amd64 looks so.
>>> we use two modules. linux.ko for x86_64 and linux32.ko for ia32,
>>> option COMPAT_LINUX for x86_64 and COMPAT_LINUX32 for ia32.
>>> and two  linux_base directories: /compat/linux for x86_64
>>> and /compat/linux32 for ia32.
>>>
>>> there are other opinions?
>>
>> I propose:
>>  - /compat/linux64 for 64bit stuff
>>  - /compat/linux32 a symlink to /compat/linux
>>  - /compat/linux for 32bit stuff (we can think about having)
>>
>
>  I agree with this later proposition, it's a bad thing to break the
> already established purpose for /compat/linux (32bit binaries).
>
>  Here is yet another variation:
>    /compat/linux64 -- 64bit
>    /compat/linux32 -- 32bit
>    /compat/linux -> linux32  -- symlink, would this break anything in
> the current ports/packages ?

Making linux a symlink to linux32 will not work. I made the proposal  
the other way around on purpose. If an user does not update after the  
changes are introduced, any new installation (without the update) will  
mess-up the installation. If you don't have to worry about backwards  
compatibility, it's ok (and I would prefer it), but unfortunately it  
will create more hassle than it will help in the real world (there are  
too much people which will not make the right thing in such a case).

I also thought about workarounds, by e.g. checking if all involved  
paths are of the correct type and refuse to work or to adjust the  
paths if they aren't, but this will make the LINUXBASE handling very  
complicated, more than it is worth (there's already a lot of work to  
do to get all infrastructure for this together).

>  I strongly oppose having linux.ko as the 64bit version, rather there
> should be linux64.ko (linux-x86_64.ko ?) and linux32.ko (linux-ia32.ko
> ?) and perhaps we should make linux.ko try loading both of these
> (since the user did not specify the intended platform).

I like this. linux.ko as a meta module which depends upon linux32 and  
linux64 on amd64, and depends upon linux32 on i386. This way POLA is  
preserved, the documentation is not wrong (to enable linux emulation  
load the linux.ko), and people which only want one can load the  
specific one.

Bye,
Alexander.

-- 
	A domineering man married a mere wisp of a girl.  He came back from
his honeymoon a chastened man.  He'd become aware of the will of the wisp.

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
From bugmaster at FreeBSD.org  Mon Aug 18 11:06:48 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Aug 18 11:07:25 2008
Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org
Message-ID: <200808181106.m7IB6lkf079768@freefall.freebsd.org>

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/21463   emulation  [linux] Linux compatability mode should not allow setu
o kern/97326   emulation  [linux] file descriptor leakage in linux emulation
o kern/117010  emulation  [linux] linux_getdents() get something like buffer ove

3 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/11165   emulation  [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999
o kern/29698   emulation  [linux] [patch] linux ipcs doesn'work
o kern/39201   emulation  [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu
o kern/41543   emulation  [patch] [request] easier wine/w23 support
a kern/72920   emulation  [linux]: path "prefixing" is not done on unix domain s
o kern/73777   emulation  [linux] [patch] linux emulation: root dir special hand
o kern/91293   emulation  [svr4] [patch] *Experimental* Update to the SVR4 emula
o ports/91318  emulation  [fix] graphics/linux_dri: works on amd64 too
o ports/121800 emulation  x11-toolkits/linux-openmotif - OpenMotif upgrade to 2.
o kern/122318  emulation  [linux] [cmake]: Segmentation fault when running Linux
o ports/123960 emulation  Port fix: archivers/linux-par2cmdline - better handlin
o ports/126232 emulation  Linux ioctl TCGETS (0x5401) always fails

12 problems total.

From twickline at gmail.com  Tue Aug 19 13:36:05 2008
From: twickline at gmail.com (Tom Wickline)
Date: Tue Aug 19 13:36:12 2008
Subject: Bordeaux for FreeBSD coming soon
Message-ID: <19048609.post@talk.nabble.com>


Over the last couple day's I have been working on the Bordeaux for FreeBSD 7
port. We now have everything compiling and running but a lot more testing
needs to be done before it's ready for a final release. Internet Explorer,
Steam and Office 2003 are the only applications ive gotten around to testing
thus far. The good news is everything that I have tested works fairly well
on FreeBSD.

More info can be found here:
http://www.wine-reviews.net/wine-reviews/bordeaux/bordeaux-for-freebsd-coming-soon.html
-- 
View this message in context: http://www.nabble.com/Bordeaux-for-FreeBSD-coming-soon-tp19048609p19048609.html
Sent from the freebsd-emulation mailing list archive at Nabble.com.

From dchagin at freebsd.org  Tue Aug 19 17:45:43 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Tue Aug 19 17:45:49 2008
Subject: x86_64 linuxulator patches
In-Reply-To: <20080818100541.20073jcxqbtyci80@webmail.leidinger.net>
References: <20080810072013.GA15196@dchagin.dialup.corbina.ru>
	<20080810115406.GR97161@deviant.kiev.zoral.com.ua>
	<20080810120424.GA15768@dchagin.dialup.corbina.ru>
	<20080810122124.GS97161@deviant.kiev.zoral.com.ua>
	<20080817181757.GA2940@dchagin.dialup.corbina.ru>
	<20080818100541.20073jcxqbtyci80@webmail.leidinger.net>
Message-ID: <20080819174535.GA16788@dchagin.dialup.corbina.ru>

On Mon, Aug 18, 2008 at 10:05:41AM +0200, Alexander Leidinger wrote:
> Quoting "Chagin Dmitry" <dchagin@freebsd.org> (from Sun, 17 Aug 2008  
> 22:17:57 +0400):
> 
> >On Sun, Aug 10, 2008 at 03:21:24PM +0300, Kostik Belousov wrote:
> >>On Sun, Aug 10, 2008 at 04:04:24PM +0400, Chagin Dmitry wrote:
> >>> On Sun, Aug 10, 2008 at 02:54:06PM +0300, Kostik Belousov wrote:
> >>> > On Sun, Aug 10, 2008 at 11:20:13AM +0400, Chagin Dmitry wrote:
> >>> > > Hi, as promised, I place x86_64 linuxulator patches.
> >>> > >
> >>> > > here the basic patch:
> >>> > > http://78.107.232.239/linuxulator64-current.patch
> >>> > >
> >>> > > here recvmsg && sendmsg patch (not tested with really applications):
> >>> > > http://78.107.232.239/send-recv-msg.patch
> >>> > >
> >>> > > here master repository:
> >>> > > git://78.107.232.239/linuxulator
> >>> > >
> >>> > > and ports used for testing (and only for testing):
> >>> > > git://78.107.232.239/linux_base-f8
> >>> > > git://78.107.232.239/linux_devel-f8
> >>> > > git://78.107.232.239/linux_kdump-1.6
> >>> > >
> >>> > > by default on amd64 builds i386 linuxulator, for build x86_64 use
> >>> > > cd sys/modules/linux
> >>> > > make -D COMPAT_LINUX64
> >>> > >
> >>> > > for correct recognition of what linuxulator version is used
> >>> > > added new sysctl compat.linux.platform
> >>> > > for example use in ports Makefile's:
> >>> > >
> >>> > > LINUX_PLATFORM!=        /sbin/sysctl -n compat.linux.platform  
> >>2>/dev/null
> >>> > >
> >>> > > .if ${LINUX_PLATFORM}x == "x"
> >>> > > IGNORE=                 linuxulator is not (kld)loaded
> >>> > > .elif ${LINUX_PLATFORM} == "i386"
> >>> > > LINUX_RPM_ARCH=         i386
> >>> > > .elif ${LINUX_PLATFORM} == "x86_64"
> >>> > > LINUX_RPM_ARCH=         x86_64
> >>> > > SFX=                    64
> >>> > > .else
> >>> > > IGNORE=                 ${LINUX_PLATFORM} is not supported
> >>> > > .endif
> >>> > >
> >>> > > I shal glad to remarks, proposals and results of testing.
> >>> > > thnx
> >>> >
> >>> > Reading your email, I got an impression that i386/linux and 
> >>x86_64/linux
> >>> > ABI emulators are mutually exclusive. Is this right ? I think it would
> >>> > be most useful to be able to have them both in one kernel.
> >>>
> >>> yes, it so. if there are ports working only on i386 it's necessary
> >>> to do it. I don't know such ports :(
> >>
> >>Whether there is a _port_ that has no amd64 counterpart for i386 one is
> >>irrelevant there. The Linux ABI emulation is supposed to work not only 
> >>with
> >>a software installed from port, but with most binaries.
> >>
> >>If emulating both ia32 and x86_64 simultaneously is technically feasible
> >>(and I believe it is), then both should be available. i386->amd64 is
> >>not the replacement step, this is an backward-compatible upgrade.
> >
> >Something few the interested participants of discussion :)
> >problem in that I am not familiar with a ports infrastructure...
> >
> >in my opinion the best decision for amd64 looks so.
> >we use two modules. linux.ko for x86_64 and linux32.ko for ia32,
> >option COMPAT_LINUX for x86_64 and COMPAT_LINUX32 for ia32.
> >and two  linux_base directories: /compat/linux for x86_64
> >and /compat/linux32 for ia32.
> >
> >there are other opinions?
> 
> I propose:
>  - /compat/linux64 for 64bit stuff
>  - /compat/linux32 a symlink to /compat/linux
>  - /compat/linux for 32bit stuff (we can think about having)
> 
> Reasons:
>  - existing installations don't get fucked up with a partial update
>    (very big point!)
>  - we don't have to special case amd64-linux32 for LINUXBASE, we
>    just have to distinguish 32 and 64 bit (maybe with switches
>    USE_LINUX and USE_LINUX64, we have to have separate 64bit
>    ports anyway, when we want to be able to install in parallel)
> 

Thanks Alexander, Adrian, Roman! I have understood.


-- 
Have fun!
chd
From eculp at encontacto.net  Tue Aug 19 23:41:12 2008
From: eculp at encontacto.net (eculp)
Date: Tue Aug 19 23:41:19 2008
Subject: Bordeaux for FreeBSD coming soon
In-Reply-To: <19048609.post@talk.nabble.com>
References: <19048609.post@talk.nabble.com>
Message-ID: <20080819184108.64557e8fqaabqt8g@econet.encontacto.net>

Quoting Tom Wickline <twickline@gmail.com>:

>
> Over the last couple day's I have been working on the Bordeaux for FreeBSD 7
> port. We now have everything compiling and running but a lot more testing
> needs to be done before it's ready for a final release. Internet Explorer,
> Steam and Office 2003 are the only applications ive gotten around to testing
> thus far. The good news is everything that I have tested works fairly well
> on FreeBSD.
>
> More info can be found here:
> http://www.wine-reviews.net/wine-reviews/bordeaux/bordeaux-for-freebsd-coming-soon.html
> --
> View this message in context:  
> http://www.nabble.com/Bordeaux-for-FreeBSD-coming-soon-tp19048609p19048609.html
> Sent from the freebsd-emulation mailing list archive at Nabble.com.

I took a look at the links and need explorer support in FreeBSD before  
I can start converting all our PC's.  The government here requires  
Internet Explorer for many of their forms and we haven't found any way  
around the requirement.

I made the paypal deposit for the $20 that was required to test the  
beta version and am still, 8 hours later, waiting for the confirmation  
password to be able to download the beta.  I have checked Spam and it  
is the same email as the above that has no strange problems.  I'm  
somewhat concerned not for the money but to see if this is or can be  
the solution to our problem.

I'm sending a copy to the sales email of wine-reviews.

I'm also curious if a port will also require purchase?

thanks,

ed


From andr.pl at gmail.com  Wed Aug 20 08:41:45 2008
From: andr.pl at gmail.com (Andrey Ignatov)
Date: Wed Aug 20 08:41:52 2008
Subject: linux-megacli and linsysfs
Message-ID: <20080820081414.GA68778@rdna.yandex.ru>

Hi;

I have many servers with RAID controllers Dell PERC 5/E, PERC 6/E
(mfi driver in FreeBSD, man mfi). I use /usr/ports/sysutils/linux-megacli
for software management of these controllers. This management utility
works through linsysfs and linprocfs.

I has tried run linux-megacli on several servers and found law. The
utility works in case mfi0 is on scbus0 and is detected as host0 in
linsysfs but not works in other case (is detected as host1, host2 etc.
in linsysfs).

For example, megacli works perfectly on server "one":

one# camcontrol devlist
<DELL MD1000 A.04>                 at scbus0 target 17 lun 0 (ses0,pass0)
<DELL MD1000 A.04>                 at scbus0 target 18 lun 0 (ses1,pass1)
<SEAGATE ST3146855SS S527>         at scbus0 target 19 lun 0 (pass2)
<SEAGATE ST3146855SS S527>         at scbus0 target 20 lun 0 (pass3)
<SEAGATE ST3146855SS S527>         at scbus0 target 21 lun 0 (pass4)
<SEAGATE ST3146855SS S527>         at scbus0 target 22 lun 0 (pass5)
<SEAGATE ST3146855SS S527>         at scbus0 target 23 lun 0 (pass6)
<SEAGATE ST3146855SS S527>         at scbus0 target 24 lun 0 (pass7)
<SEAGATE ST3146855SS S527>         at scbus0 target 25 lun 0 (pass8)
<SEAGATE ST3146855SS S527>         at scbus0 target 26 lun 0 (pass9)
<SEAGATE ST3146855SS S527>         at scbus0 target 27 lun 0 (pass10)
<SEAGATE ST3146855SS S527>         at scbus0 target 28 lun 0 (pass11)
<SEAGATE ST3146855SS S527>         at scbus0 target 29 lun 0 (pass12)
<SEAGATE ST3146855SS S527>         at scbus0 target 30 lun 0 (pass13)
<SEAGATE ST3146855SS S527>         at scbus0 target 31 lun 0 (pass14)
<SEAGATE ST3146855SS S527>         at scbus0 target 32 lun 0 (pass15)
<SEAGATE ST3146855SS S527>         at scbus0 target 33 lun 0 (pass16)
<FUJITSU MBA3147RC 0103>           at scbus1 target 0 lun 0 (da0,pass17)
<FUJITSU MBA3147RC 0103>           at scbus1 target 1 lun 0 (da1,pass18)

(Dell PowerVault MD1000 is pluged to mfi0 on scbus0)

one# ls -d1 /compat/linux/sys/class/scsi_host/*
/compat/linux/sys/class/scsi_host/host0
/compat/linux/sys/class/scsi_host/host1
one# head -n1 /compat/linux/sys/class/scsi_host/host?/proc_name
==> /compat/linux/sys/class/scsi_host/host0/proc_name <==
megaraid_sas

==> /compat/linux/sys/class/scsi_host/host1/proc_name <==
(null)

one# megacli -AdpAllInfo -aALL | grep '^Product Name'
Product Name    : PERC 6/E Adapter


RAID controller on this server is on scbus0 and is detected as host0 in
linsysfs. This server based on motherboard Supermicro X7DBR-3,
/var/run/dmesg.boot:
...
mfi0: <Dell PERC 6> port 0x3000-0x30ff mem
0xd8240000-0xd827ffff,0xd8200000-0xd823ffff irq 16 at device 0.0 on pci6
...
mpt0: <LSILogic SAS/SATA Adapter> port 0x4000-0x40ff mem
0xd8510000-0xd8513fff,0xd8500000-0xd850ffff irq 16 at device 1.0 on pci9

mfi0 is detected out by the first, mpt0 - out by the second.


But megacli not works on server "two":

two# camcontrol devlist
<SEAGATE ST973402SS S207>          at scbus0 target 0 lun 0 (pass0,da0)
<SEAGATE ST973402SS S207>          at scbus0 target 1 lun 0 (pass1,da1)
<DP BACKPLANE 1.05>                at scbus0 target 8 lun 0 (ses0,pass2)
<DELL MD1000 A.03>                 at scbus2 target 34 lun 0 (ses1,pass3)
<ATA ST3500630NS 3BKH>             at scbus2 target 50 lun 0 (pass4)
<ATA ST3500630NS 3BKH>             at scbus2 target 51 lun 0 (pass5)
<ATA ST3500630NS 3BKH>             at scbus2 target 52 lun 0 (pass6)
<ATA ST3500630NS 3BKH>             at scbus2 target 53 lun 0 (pass7)
<ATA ST3500630NS 3BKH>             at scbus2 target 54 lun 0 (pass8)
<ATA ST3500630NS 3BKH>             at scbus2 target 55 lun 0 (pass9)
<ATA ST3500630NS 3BKH>             at scbus2 target 56 lun 0 (pass10)
<ATA ST3500630NS 3BKH>             at scbus2 target 57 lun 0 (pass11)
<ATA ST3500630NS 3BKH>             at scbus2 target 58 lun 0 (pass12)
<ATA ST3500630NS 3BKH>             at scbus2 target 59 lun 0 (pass13)
<ATA ST3500630NS 3BKH>             at scbus2 target 60 lun 0 (pass14)
<ATA ST3500641AS A>                at scbus2 target 61 lun 0 (pass15)
<ATA ST3500630NS 3BKH>             at scbus2 target 62 lun 0 (pass16)
<ATA ST3500630NS 3BKH>             at scbus2 target 63 lun 0 (pass17)
<ATA ST3500630NS 3BKH>             at scbus2 target 64 lun 0 (pass18)

two# ls -d1 /compat/linux/sys/class/scsi_host/*
/compat/linux/sys/class/scsi_host/host0
/compat/linux/sys/class/scsi_host/host1
two# head -n1
/compat/linux/sys/class/scsi_host/host?/proc_name
==> /compat/linux/sys/class/scsi_host/host0/proc_name <==
(null)

==> /compat/linux/sys/class/scsi_host/host1/proc_name <==
megaraid_sas

two# megacli -AdpAllInfo -aALL
                                     
two# echo $?
1

RAID controller is on scbus2 and is detected as host1 in linsysfs.
It's Dell 1950.
/var/run/dmesg.boot:
...
mpt0: <LSILogic SAS/SATA Adapter> port 0xec00-0xecff mem
0xfc7fc000-0xfc7fffff,0xfc7e0000-0xfc7effff irq 16 at device 0.0 on pci1
...
mfi0: <Dell PERC 5/i> mem 0xd80f0000-0xd80fffff,0xfc5c0000-0xfc5dffff
irq 18 at device 14.0 on pci11


mpt0 is detected out by the first, mfi0 - out by the second.
megacli not works in this case ..

But megacli identify correctly number of controllers on both servers:

one# megacli -AdpCount


Controller Count: 1.

two# megacli -AdpCount


Controller Count: 1.

hint.scbus.0.at="mfi0" in /boot/device.hints on server "two" affects
only a camcontrol's output but not affects a order of "hosts" in linsysfs
(megaraid_sas is detected as host1).

The result does not depend on type of the controller (PERC 5/E or PERC
6/E).

How I can change order of "hosts" in linsysfs that megaraid_sas was in
host0 ? Other workaround ?  I shall be grateful for any ideas.

Thanks.


-- 
Andrey Ignatov
From mdobrzyn at poczta.fm  Wed Aug 20 14:05:01 2008
From: mdobrzyn at poczta.fm (Michal Dobrzynski)
Date: Wed Aug 20 14:05:08 2008
Subject: vmware3 under freebsd 7.0
Message-ID: <fe5d69380808200636q6751d2a3ycb85c530c5e89b66@mail.gmail.com>

Hello

When I trying to bulid vmware3 package from
/usr/ports/emulators/vmware3 under FreeBSD 7.0 i386
I had followin error.


[root@mambo /usr/ports/emulators/vmware3]# make install
===>  Building for vmware3-3.2.1.2242_13,1
===> vmmon-only (all)
make -f Makefile.freebsd SMP=YES clean && make -f Makefile.freebsd SMP=YES
"/usr/share/mk/bsd.compat.mk", line 35: warning: NOMAN is deprecated
in favour of NO_MAN
rm -f export_syms vmmon_smp.ko vmmon_smp.kld cpuid.o memtrack.o
phystrack.o task.o vmx86.o driver.o hostif.o linux_emu.o
"/usr/share/mk/bsd.compat.mk", line 35: warning: NOMAN is deprecated
in favour of NO_MAN
Warning: Object directory not changed from original
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only
cc -O2 -fno-strict-aliasing -pipe -DCDEV_MAJOR_=200 -DDDB
-DVMX86_DEBUG -DSMP -DAPIC_IO  -D_KERNEL -DKLD_MODULE -std=c99
-nostdinc  -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/export/include
-I/sys -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/
-I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -c
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common/cpuid.c
cc -O2 -fno-strict-aliasing -pipe -DCDEV_MAJOR_=200 -DDDB
-DVMX86_DEBUG -DSMP -DAPIC_IO  -D_KERNEL -DKLD_MODULE -std=c99
-nostdinc  -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/export/include
-I/sys -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/
-I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -c
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common/memtrack.c
cc -O2 -fno-strict-aliasing -pipe -DCDEV_MAJOR_=200 -DDDB
-DVMX86_DEBUG -DSMP -DAPIC_IO  -D_KERNEL -DKLD_MODULE -std=c99
-nostdinc  -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/export/include
-I/sys -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/
-I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -c
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common/phystrack.c
cc -O2 -fno-strict-aliasing -pipe -DCDEV_MAJOR_=200 -DDDB
-DVMX86_DEBUG -DSMP -DAPIC_IO  -D_KERNEL -DKLD_MODULE -std=c99
-nostdinc  -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/export/include
-I/sys -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/
-I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -c Hello

[root@mambo /usr/ports/emulators/vmware3]# make install
===>  Building for vmware3-3.2.1.2242_13,1
===> vmmon-only (all)
make -f Makefile.freebsd SMP=YES clean && make -f Makefile.freebsd SMP=YES
"/usr/share/mk/bsd.compat.mk", line 35: warning: NOMAN is deprecated
in favour of NO_MAN
rm -f export_syms vmmon_smp.ko vmmon_smp.kld cpuid.o memtrack.o
phystrack.o task.o vmx86.o driver.o hostif.o linux_emu.o
"/usr/share/mk/bsd.compat.mk", line 35: warning: NOMAN is deprecated
in favour of NO_MAN
Warning: Object directory not changed from original
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only
cc -O2 -fno-strict-aliasing -pipe -DCDEV_MAJOR_=200 -DDDB
-DVMX86_DEBUG -DSMP -DAPIC_IO  -D_KERNEL -DKLD_MODULE -std=c99
-nostdinc  -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/export/include
-I/sys -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/
-I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -c
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common/cpuid.c
cc -O2 -fno-strict-aliasing -pipe -DCDEV_MAJOR_=200 -DDDB
-DVMX86_DEBUG -DSMP -DAPIC_IO  -D_KERNEL -DKLD_MODULE -std=c99
-nostdinc  -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/export/include
-I/sys -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/
-I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -c
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common/memtrack.c
cc -O2 -fno-strict-aliasing -pipe -DCDEV_MAJOR_=200 -DDDB
-DVMX86_DEBUG -DSMP -DAPIC_IO  -D_KERNEL -DKLD_MODULE -std=c99
-nostdinc  -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/export/include
-I/sys -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/
-I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -c
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common/phystrack.c
cc -O2 -fno-strict-aliasing -pipe -DCDEV_MAJOR_=200 -DDDB
-DVMX86_DEBUG -DSMP -DAPIC_IO  -D_KERNEL -DKLD_MODULE -std=c99
-nostdinc  -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/freebsd
-I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/export/include
-I/sys -I/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/
-I. -I@ -I@/contrib/altq -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-common
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions -c
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common/task.c
In file included from
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/taskswitch.h:25,
                 from
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/common/task.c:54:
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/vm_asm.h:
In function 'Div643264':
/usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only/include/vm_asm.h:1033:
error: memory input 4 is not directly addressable
*** Error code 1

Stop in /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only.
*** Error code 1

Stop in /usr/ports/emulators/vmware3/work/vmware-distrib/vmmon-only.
*** Error code 1

Stop in /usr/ports/emulators/vmware3/work/vmware-distrib.
*** Error code 1

Stop in /usr/ports/emulators/vmware3.
*** Error code 1

Stop in /usr/ports/emulators/vmware3.
[root@mambo /usr/ports/emulators/vmware3]#


Also I had install packages which vmware3 requires
autoconf-2.13.000227_6 Automatically configure source code on many
Un*x platforms
autoconf-2.61_2     Automatically configure source code on many Un*x platforms
autoconf-wrapper-20071109 Wrapper script for GNU autoconf
automake-1.4.6_4    GNU Standards-compliant Makefile generator (1.4)
automake-wrapper-20071109 Wrapper script for GNU automake
bash-3.2.25         The GNU Project's Bourne Again SHell
gettext-0.16.1_3    GNU gettext package
glib-2.14.2         Some useful routines of C programming (current stable versi
gmake-3.81_2        GNU version of 'make' utility
help2man-1.36.4_1   Automatically generating simple manual pages from program o
libiconv-1.11_1     A character set conversion library
libtool-1.5.24      Generic shared library support script
linux-expat-1.95.8  Linux/i386 binary port of Expat XML-parsing library
linux-fontconfig-2.2.3_7 Linux/i386 binary of Fontconfig
linux-xorg-libs-6.8.2_5 Xorg libraries, linux binaries
linux_base-fc-4_10  Base set of packages needed in Linux mode (for i386/amd64)
m4-1.4.9,1          GNU m4
mc-4.6.1_6          Midnight Commander, a free Norton Commander Clone
p5-Authen-PAM-0.16_1 A Perl interface to the PAM library
p5-Net-SSLeay-1.30_1 Perl5 interface to SSL
p5-gettext-1.05_1   Message handling functions
pcre-7.4            Perl Compatible Regular Expressions library
perl-5.8.8_1        Practical Extraction and Report Language
pkg-config-0.22_1   A utility to retrieve information about installed libraries
popt-1.7_4          A getopt(3) like library with a number of enhancements, fro
rpm-3.0.6_13        The Red Hat Package Manager
rtc-2004.02.24.1_8  Kernel module which provides /dev/rtc device support
screen-4.0.3_1      A multi-screen window manager
webmin-1.370_2      Web-based interface for system administration for Unix

Who know how I can compile it ? Or maybe other virtualization emulator ?

Michael
From sales at wine-reviews.net  Wed Aug 20 23:37:33 2008
From: sales at wine-reviews.net (Tom Wickline)
Date: Wed Aug 20 23:37:40 2008
Subject: Bordeaux for FreeBSD coming soon
In-Reply-To: <20080820122826.20458a9pnlmpa43c@econet.encontacto.net>
References: <19048609.post@talk.nabble.com>
	<20080819184108.64557e8fqaabqt8g@econet.encontacto.net>
	<20080820122826.20458a9pnlmpa43c@econet.encontacto.net>
Message-ID: <1219275452.5745.30.camel@localhost>

Hello Ed,

OK, ive sent you 5 emails now, one from sales, one from support, my user
account at wine-reviews, and even from my personal gmail account.....

Can you check your spam box pretty please?

This should be a private mail and not on freebsd-emulation
but it seems this is the only way you get a email from me.

If all else fails ill issue you a refund and you can wait
and try the full version when it ships. Refunds are always
no questions asked.. just ask and its done.

Tom


On Wed, 2008-08-20 at 12:28 -0500, eccl wrote:
> Still no news on the download.  The info from paypal follows.
> 


From andr.pl at gmail.com  Fri Aug 22 10:50:20 2008
From: andr.pl at gmail.com (Andrey Ignatov)
Date: Fri Aug 22 10:50:27 2008
Subject: linux-megacli and linsysfs
In-Reply-To: <20080820081414.GA68778@rdna.yandex.ru>
References: <20080820081414.GA68778@rdna.yandex.ru>
Message-ID: <20080822105011.GA1165@rdna.yandex.ru>

Hi;

Workaround is found.

The linsysfs create directories /compat/linux/sys/class/scsi_host/host*
for each device of class PCIC_STORAGE by default.

I has changed this behaviour and resolved my problem by this patch:

--8<--------------------------------------------------------------------
--- src/sys/compat/linsysfs/linsysfs.c.orig	2007-03-12 15:16:52.000000000 +0300
+++ src/sys/compat/linsysfs/linsysfs.c	2008-08-21 13:59:06.000000000 +0400
@@ -177,7 +177,7 @@
 				dir = pfs_create_dir(dir, device,
 				    NULL, NULL, NULL, 0);
 
-				if (dinfo->cfg.baseclass == PCIC_STORAGE) {
+				if (dinfo->cfg.baseclass == PCIC_STORAGE && dinfo->cfg.subclass == PCIS_STORAGE_RAID) {
 					/* DJA only make this if needed */
 					sprintf(host, "host%d", host_number++);
 					strcat(new_path, "/");
-->8--------------------------------------------------------------------


With this patch linsysfs created directories
/compat/linux/sys/class/scsi_host/host* for RAID controllers only and
not created for SCSI controllers like mpt. The RAID controller mfi0
detected so as /compat/linux/sys/class/scsi_host/host0 in linsysfs and
linux-megacli works correctly.

The topic is closed. Thanks.

P.S.

FreeBSD 7.0-STABLE amd64
linux-megacli-1.01.40_1
PERC 5/E, PERC 6/E
Dell PowerVault MD1000


-- 
Andrey Ignatov
From ed at 80386.nl  Fri Aug 22 11:29:28 2008
From: ed at 80386.nl (Ed Schouten)
Date: Fri Aug 22 11:29:34 2008
Subject: MPSAFE TTY: Linux PTY's
Message-ID: <20080822112927.GZ99951@hoeg.nl>

Hello Emulation folks,

I just wanted to send you all a message to say one of the things I tried
to improve in the MPSAFE TTY branch was support for PTY's for Linux
binaries.

At home I've got a FreeBSD Jail running Debian Etch. Unfortunately,
Linux sendmsg() is a little broken on FreeBSD/amd64, but so far I've
been able to at least get OpenSSH (as root) and GNU Screen working.

So if you folks run into any problems related to TTY's that you think
can easily be solved, just send me an email. Thanks!

-- 
 Ed Schouten <ed@80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080822/477262de/attachment.pgp
From rdivacky at FreeBSD.org  Fri Aug 22 11:31:18 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Fri Aug 22 11:31:25 2008
Subject: MPSAFE TTY: Linux PTY's
In-Reply-To: <20080822112927.GZ99951@hoeg.nl>
References: <20080822112927.GZ99951@hoeg.nl>
Message-ID: <20080822112946.GA97526@freebsd.org>

On Fri, Aug 22, 2008 at 01:29:27PM +0200, Ed Schouten wrote:
> Hello Emulation folks,
> 
> I just wanted to send you all a message to say one of the things I tried
> to improve in the MPSAFE TTY branch was support for PTY's for Linux
> binaries.
> 
> At home I've got a FreeBSD Jail running Debian Etch. Unfortunately,
> Linux sendmsg() is a little broken on FreeBSD/amd64, but so far I've
> been able to at least get OpenSSH (as root) and GNU Screen working.

I believe dmitry has a patch for this..
From nox at jelal.kn-bremen.de  Sun Aug 24 00:27:25 2008
From: nox at jelal.kn-bremen.de (Juergen Lock)
Date: Sun Aug 24 00:27:32 2008
Subject: qemu svn r5075 on FreeBSD - some observations (usb, vmwarevga,
	screen updates, monitor...)
Message-ID: <20080823235435.GA5405@saturn.kn-bremen.de>

Hi!

 I just played with qemu svn again on FreeBSD (experimental port
update here:
	http://people.freebsd.org/~nox/qemu/qemu-devel-20080823.patch
), and noticed a few things:

1. at least umass became slower, down from more than 1 MB/s to little
over 200 KB/s on one box here, emulated images (`usb_add disk:...') were
even more slow.

2, -vmwarevga seems to be broken with -kernel-kqemu (at least for linux
guests, it crashes the guest's xserver), and causes qemu to hang in
vmsvga_fifo_run without -kernel-kqemu sometimes (it never finds the end of
the fifo, and badcmd can also be reached with args not being reset so it
goobles up (unsigned)-1 fifo entries too.)  The following patch at least
stops the hangs, I still get `Unknown command 0x%02x in SVGA command FIFO'
messages probably because the fifo still gets out of sync:

Index: qemu/hw/vmware_vga.c
@@ -76,6 +76,7 @@
     uint32_t wblue;
     int syncing;
     int fb_size;
+    int empty;
 
     union {
         uint32_t *fifo;
@@ -487,7 +488,7 @@
 
 static inline int vmsvga_fifo_empty(struct vmsvga_state_s *s)
 {
-    if (!s->config || !s->enable)
+    if (!s->config || !s->enable || s->empty)
         return 1;
     return (s->cmd->next_cmd == s->cmd->stop);
 }
@@ -495,6 +496,10 @@
 static inline uint32_t vmsvga_fifo_read_raw(struct vmsvga_state_s *s)
 {
     uint32_t cmd = s->fifo[CMD(stop) >> 2];
+    if (s->cmd->next_cmd == s->cmd->stop) {
+        s->empty = 1;
+        return 0;
+    }
     s->cmd->stop = cpu_to_le32(CMD(stop) + 4);
     if (CMD(stop) >= CMD(max))
         s->cmd->stop = s->cmd->min;
@@ -512,6 +517,7 @@
     int args = 0;
     int x, y, dx, dy, width, height;
     struct vmsvga_cursor_definition_s cursor;
+    s->empty = 0;
     while (!vmsvga_fifo_empty(s))
         switch (cmd = vmsvga_fifo_read(s)) {
         case SVGA_CMD_UPDATE:
@@ -533,6 +539,7 @@
             vmsvga_fill_rect(s, colour, x, y, width, height);
             break;
 #else
+            args = 0;
             goto badcmd;
 #endif
 
@@ -547,6 +554,7 @@
             vmsvga_copy_rect(s, x, y, dx, dy, width, height);
             break;
 #else
+            args = 0;
             goto badcmd;
 #endif
 
@@ -609,6 +617,7 @@
             break; /* Nop */
 
         default:
+            args = 0;
         badcmd:
             while (args --)
                 vmsvga_fifo_read(s);

 and here is the xorg vmwarevga crash with -kernel-kqemu:

X.Org X Server 1.4.0.90
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20080517-2)
Current Operating System: Linux sidux 2.6.25-9.slh.1-sidux-686 #1 SMP PREEMPT Tue Jun 24 23:26:13 UTC 2008 i686
Build Date: 09 June 2008  03:18:20PM
 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sat Aug 23 18:40:58 2008
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Xorg Configured"
(**) |-->Screen "Screen 0" (0)
(**) |   |-->Monitor "Monitor 0"
(==) No device specified for screen "Screen 0".
	Using the first device section listed.
(**) |   |-->Device "Device 0"
(**) |-->Input Device "Keyboard 0"
(**) |-->Input Device "VMMouse 0"
(**) Option "AllowMouseOpenFail" "true"
(==) Automatically adding devices
(==) Automatically enabling devices
(==) No FontPath specified.  Using compiled-in default.
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
	Entry deleted from font path.
(WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
	Entry deleted from font path.
(WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist.
	Entry deleted from font path.
(==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi
(==) RgbPath set to "/etc/X11/rgb"
(==) ModulePath set to "/usr/lib/xorg/modules"
(**) Extension "Composite" is disabled
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Loader magic: 0x81e2560
(II) Module ABI versions:
	X.Org ANSI C Emulation: 0.3
	X.Org Video Driver: 2.0
	X.Org XInput driver : 2.0
	X.Org Server Extension : 0.3
	X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: "pcidata"
(II) Loading /usr/lib/xorg/modules//libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.0.0
	ABI class: X.Org Video Driver, version 2.0
(++) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,1237 card 0000,0000 rev 02 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 8086,7000 card 0000,0000 rev 00 class 06,01,00 hdr 80
(II) PCI: 00:01:1: chip 8086,7010 card 0000,0000 rev 00 class 01,01,80 hdr 00
(II) PCI: 00:01:3: chip 8086,7113 card 0000,0000 rev 03 class 06,80,00 hdr 00
(II) PCI: 00:02:0: chip 15ad,0405 card 15ad,0405 rev 00 class 03,00,00 hdr 00
(II) PCI: 00:03:0: chip 10ec,8029 card 0000,0000 rev 00 class 02,00,00 hdr 00
(II) PCI: 00:04:0: chip 1274,5000 card 4942,4c4c rev 00 class 04,01,00 hdr 00
(II) PCI: End of PCI scan
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (0,0,0), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 0 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) PCI-to-ISA bridge:
(II) Bus -1: bridge is at (0:1:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set)
(--) PCI:*(0:2:0) VMware Inc [VMware SVGA II] PCI Display Adapter rev 0, Mem @ 0xf0000000/23, I/O @ 0xc010/4
(II) Addressable bus resource ranges are
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
	[1] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) OS-reported resource ranges:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) Active PCI resource ranges:
	[0] -1	0	0xf0000000 - 0xf07fffff (0x800000) MX[B](B)
	[1] -1	0	0x0000c200 - 0x0000c2ff (0x100) IX[B]
	[2] -1	0	0x0000c100 - 0x0000c1ff (0x100) IX[B]
	[3] -1	0	0x0000c000 - 0x0000c00f (0x10) IX[B]
	[4] -1	0	0x0000c010 - 0x0000c01f (0x10) IX[B](B)
(II) Active PCI resource ranges after removing overlaps:
	[0] -1	0	0xf0000000 - 0xf07fffff (0x800000) MX[B](B)
	[1] -1	0	0x0000c200 - 0x0000c2ff (0x100) IX[B]
	[2] -1	0	0x0000c100 - 0x0000c1ff (0x100) IX[B]
	[3] -1	0	0x0000c000 - 0x0000c00f (0x10) IX[B]
	[4] -1	0	0x0000c010 - 0x0000c01f (0x10) IX[B](B)
(II) OS-reported resource ranges after removing overlaps with PCI:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[5] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
(II) All system resource ranges:
	[0] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[1] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[2] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[3] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[4] -1	0	0xf0000000 - 0xf07fffff (0x800000) MX[B](B)
	[5] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[6] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[7] -1	0	0x0000c200 - 0x0000c2ff (0x100) IX[B]
	[8] -1	0	0x0000c100 - 0x0000c1ff (0x100) IX[B]
	[9] -1	0	0x0000c000 - 0x0000c00f (0x10) IX[B]
	[10] -1	0	0x0000c010 - 0x0000c01f (0x10) IX[B](B)
(II) LoadModule: "extmod"
(II) Loading /usr/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 0.3
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"
(II) Loading /usr/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.0.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 0.3
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.3
(==) AIGLX enabled
(II) Loading extension GLX
(II) LoadModule: "freetype"
(II) Loading /usr/lib/xorg/modules//fonts/libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
	compiled for 1.4.0.90, module version = 2.1.0
	Module class: X.Org Font Renderer
	ABI class: X.Org Font Renderer, version 0.5
(II) Loading font FreeType
(II) LoadModule: "record"
(II) Loading /usr/lib/xorg/modules/extensions//librecord.so
(II) Module record: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.13.0
	Module class: X.Org Server Extension
	ABI class: X.Org Server Extension, version 0.3
(II) Loading extension RECORD
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.0.0
	ABI class: X.Org Server Extension, version 0.3
(II) Loading extension XFree86-DRI
(II) LoadModule: "vmware"
(II) Loading /usr/lib/xorg/modules/drivers//vmware_drv.so
(II) Module vmware: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 10.16.2
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 2.0
(II) LoadModule: "kbd"
(II) Loading /usr/lib/xorg/modules/input//kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.3.1
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 2.0
(II) LoadModule: "mouse"
(II) Loading /usr/lib/xorg/modules/input//mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 1.3.0
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 2.0
(II) VMWARE: driver for VMware SVGA: vmware0405, vmware0710
(II) Primary Device is: PCI 00:02:0
(--) Chipset vmware0405 found
(II) resource ranges after xf86ClaimFixedResources() call:
	[0] 0	0	0x000b8000 - 0x000bffff (0x8000) MX[B]
	[1] 0	0	0x000b0000 - 0x000b7fff (0x8000) MX[B]
	[2] 0	0	0x000a0000 - 0x000affff (0x10000) MX[B]
	[3] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[4] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[5] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[6] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[7] -1	0	0xf0000000 - 0xf07fffff (0x800000) MX[B](B)
	[8] 0	0	0x000003c0 - 0x000003df (0x20) IX[B]
	[9] 0	0	0x000003b0 - 0x000003bb (0xc) IX[B]
	[10] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[11] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[12] -1	0	0x0000c200 - 0x0000c2ff (0x100) IX[B]
	[13] -1	0	0x0000c100 - 0x0000c1ff (0x100) IX[B]
	[14] -1	0	0x0000c000 - 0x0000c00f (0x10) IX[B]
	[15] -1	0	0x0000c010 - 0x0000c01f (0x10) IX[B](B)
(II) resource ranges after probing:
	[0] 0	0	0x000b8000 - 0x000bffff (0x8000) MX[B]
	[1] 0	0	0x000b0000 - 0x000b7fff (0x8000) MX[B]
	[2] 0	0	0x000a0000 - 0x000affff (0x10000) MX[B]
	[3] -1	0	0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
	[4] -1	0	0x000f0000 - 0x000fffff (0x10000) MX[B]
	[5] -1	0	0x000c0000 - 0x000effff (0x30000) MX[B]
	[6] -1	0	0x00000000 - 0x0009ffff (0xa0000) MX[B]
	[7] -1	0	0xf0000000 - 0xf07fffff (0x800000) MX[B](B)
	[8] 0	0	0x000003c0 - 0x000003df (0x20) IX[B]
	[9] 0	0	0x000003b0 - 0x000003bb (0xc) IX[B]
	[10] -1	0	0x0000ffff - 0x0000ffff (0x1) IX[B]
	[11] -1	0	0x00000000 - 0x000000ff (0x100) IX[B]
	[12] -1	0	0x0000c200 - 0x0000c2ff (0x100) IX[B]
	[13] -1	0	0x0000c100 - 0x0000c1ff (0x100) IX[B]
	[14] -1	0	0x0000c000 - 0x0000c00f (0x10) IX[B]
	[15] -1	0	0x0000c010 - 0x0000c01f (0x10) IX[B](B)
(II) Setting vga for screen 0.
(--) VMWARE(0): VMware SVGA regs at (0xc010, 0xc011)
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/lib/xorg/modules//libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
	compiled for 1.4.0.90, module version = 0.1.0
	ABI class: X.Org Video Driver, version 2.0
(WW) System lacks support for changing MTRRs

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x7e) [0x80c913e]
1: [0xb8021400]
2: /usr/lib/xorg/modules/drivers//vmware_drv.so [0xb7bffd37]
3: /usr/bin/X(InitOutput+0xa0f) [0x80ab32f]
4: /usr/bin/X(main+0x2b1) [0x8074561]
5: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7da6455]
6: /usr/bin/X(FontFileCompleteXLFD+0x219) [0x8073a51]

Fatal server error:
Caught signal 11.  Server aborting

3. one one box (a c2d running FreeBSD/amd64) the qemu window stops updating
after a while until I move the mouse over it or over another window (I'm
using xfce configured for focus-follows-mouse.)  It still happens when I
disable powerd or SMP so its apparently not related to those...

4. command completion in the monitor is messed up, e.g. `cha' gets completed
to `chaang'.

5. there's an #include missing in block-raw-posix.c:

Index: qemu/block-raw-posix.c
@@ -55,6 +55,7 @@
 #include <linux/fd.h>
 #endif
 #ifdef __FreeBSD__
+#include <signal.h>
 #include <sys/disk.h>
 #endif
 
 I think thats it for now...

 Thanx,
	Juergen
From bugmaster at FreeBSD.org  Mon Aug 25 11:06:49 2008
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Aug 25 11:07:31 2008
Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org
Message-ID: <200808251106.m7PB6mXT027718@freefall.freebsd.org>

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/21463   emulation  [linux] Linux compatability mode should not allow setu
o kern/97326   emulation  [linux] file descriptor leakage in linux emulation
o kern/117010  emulation  [linux] linux_getdents() get something like buffer ove

3 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/11165   emulation  [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999
o kern/29698   emulation  [linux] [patch] linux ipcs doesn'work
o kern/39201   emulation  [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu
o kern/41543   emulation  [patch] [request] easier wine/w23 support
a kern/72920   emulation  [linux]: path "prefixing" is not done on unix domain s
o kern/73777   emulation  [linux] [patch] linux emulation: root dir special hand
o kern/91293   emulation  [svr4] [patch] *Experimental* Update to the SVR4 emula
o ports/91318  emulation  [fix] graphics/linux_dri: works on amd64 too
o ports/121800 emulation  x11-toolkits/linux-openmotif - OpenMotif upgrade to 2.
o kern/122318  emulation  [linux] [cmake]: Segmentation fault when running Linux
o ports/123960 emulation  Port fix: archivers/linux-par2cmdline - better handlin
o ports/126232 emulation  Linux ioctl TCGETS (0x5401) always fails

12 problems total.

From rdivacky at FreeBSD.org  Tue Aug 26 06:24:19 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Tue Aug 26 06:24:26 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <200808251106.m7PB6mXT027718@freefall.freebsd.org>
References: <200808251106.m7PB6mXT027718@freefall.freebsd.org>
Message-ID: <20080826062233.GA44122@freebsd.org>

> o kern/117010  emulation  [linux] linux_getdents() get something like buffer ove
 
does the patch proposed by Dmitry and Alexander fix this? It would be really nice
to move forward with this.... 

> o kern/122318  emulation  [linux] [cmake]: Segmentation fault when running Linux

what about this one? IIRC Dmitry posted a patch, does it fix the issue? can we commit
that?

> o ports/126232 emulation  Linux ioctl TCGETS (0x5401) always fails

this looks trivial too.... 

Dmitry - do you have some more information? Feel free to start sending me patches (one patch
fixing one thing at a time), I'll review them (or try my best reviewing it), test them (ditto)
and try to commit

ok?
From scf at FreeBSD.org  Tue Aug 26 13:19:51 2008
From: scf at FreeBSD.org (Sean C. Farley)
Date: Tue Aug 26 13:19:58 2008
Subject: Current problem reports assigned to
 freebsd-emulation@FreeBSD.org
In-Reply-To: <20080826062233.GA44122@freebsd.org>
References: <200808251106.m7PB6mXT027718@freefall.freebsd.org>
	<20080826062233.GA44122@freebsd.org>
Message-ID: <alpine.BSF.1.10.0808260815090.10885@thor.farley.org>

On Tue, 26 Aug 2008, Roman Divacky wrote:

>> o kern/122318  emulation  [linux] [cmake]: Segmentation fault when running Linux
>
> what about this one? IIRC Dmitry posted a patch, does it fix the
> issue? can we commit that?

I was on vacation and have not had free time to try it again since
r180992 was MFC'd to 7-STABLE.  I was getting a lot of core dumps
unrelated to but exasperated by Dmitry's patch.  Hopefully, I will find
a few minutes today.

Sean
-- 
scf@FreeBSD.org
From dchagin at freebsd.org  Thu Aug 28 17:36:40 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Thu Aug 28 17:36:47 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <20080826062233.GA44122@freebsd.org>
References: <200808251106.m7PB6mXT027718@freefall.freebsd.org>
	<20080826062233.GA44122@freebsd.org>
Message-ID: <20080828173549.GA3315@dchagin.dialup.corbina.ru>

On Tue, Aug 26, 2008 at 08:22:34AM +0200, Roman Divacky wrote:
> > o kern/117010  emulation  [linux] linux_getdents() get something like buffer ove
>  
> does the patch proposed by Dmitry and Alexander fix this? It would be really nice
> to move forward with this.... 
> 

The submitter does not respond, the last patch version works fine for me.


> > o kern/122318  emulation  [linux] [cmake]: Segmentation fault when running Linux
> 
> what about this one? IIRC Dmitry posted a patch, does it fix the issue? can we commit
> that?
> 

I have sent to Sean a patch for testing...


> > o ports/126232 emulation  Linux ioctl TCGETS (0x5401) always fails
> 
> this looks trivial too.... 
> 

Most likely it's a isatty() call with incorrect fd.

> Dmitry - do you have some more information? Feel free to start sending me patches (one patch
> fixing one thing at a time), I'll review them (or try my best reviewing it), test them (ditto)
> and try to commit
> 
> ok?

ok :)

thnx!

-- 
Have fun!
chd
From scf at FreeBSD.org  Fri Aug 29 22:10:59 2008
From: scf at FreeBSD.org (Sean C. Farley)
Date: Fri Aug 29 22:11:06 2008
Subject: Current problem reports assigned to
 freebsd-emulation@FreeBSD.org
In-Reply-To: <20080828173549.GA3315@dchagin.dialup.corbina.ru>
References: <200808251106.m7PB6mXT027718@freefall.freebsd.org>
	<20080826062233.GA44122@freebsd.org>
	<20080828173549.GA3315@dchagin.dialup.corbina.ru>
Message-ID: <alpine.BSF.1.10.0808291709360.5866@thor.farley.org>

On Thu, 28 Aug 2008, Chagin Dmitry wrote:

> On Tue, Aug 26, 2008 at 08:22:34AM +0200, Roman Divacky wrote:

*snip*

>> what about this one? IIRC Dmitry posted a patch, does it fix the
>> issue? can we commit that?
>
> I have sent to Sean a patch for testing...

It works on my amd64 system.  Thank you very much.

Sean
-- 
scf@FreeBSD.org
From scf at FreeBSD.org  Fri Aug 29 22:29:12 2008
From: scf at FreeBSD.org (Sean C. Farley)
Date: Fri Aug 29 22:29:18 2008
Subject: Linux applications core if running (k)qemu
Message-ID: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>

I am having trouble with kqemu.ko and linux.ko.  If I run qemu with the
following command, Linux applications (chroot, acroread, ls) will start
core dumping:
     qemu-system-x86_64 -m 512 \
     -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
     -std-vga -parallel none -serial none -monitor stdio \
     -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime

Loading kqemu.ko does not cause the problem, but the cores start a
little after WinXP starts running.  Unloading kqemu.ko does not help;
the cores still happen but more randomly.  I even tried unloading all
linux modules and reloading them without luck.  It takes a reboot.

Packages:
qemu-devel-0.9.1s.20080620_1
kqemu-kmod-devel-1.4.0.p1
linux_base-f8-8_4

sysctl:
compat.linux.osrelease: 2.6.16

dmesg:
kqemu version 0x00010400
kqemu: KQEMU installed, max_locked_mem=1792492kB.

System is 7-STABLE as of r181963 with or without the patch to fix RT
signals from Chagin.

Sean
-- 
scf@FreeBSD.org
From rdivacky at FreeBSD.org  Sat Aug 30 08:14:01 2008
From: rdivacky at FreeBSD.org (Roman Divacky)
Date: Sat Aug 30 08:14:07 2008
Subject: Current problem reports assigned to
	freebsd-emulation@FreeBSD.org
In-Reply-To: <alpine.BSF.1.10.0808291709360.5866@thor.farley.org>
References: <200808251106.m7PB6mXT027718@freefall.freebsd.org>
	<20080826062233.GA44122@freebsd.org>
	<20080828173549.GA3315@dchagin.dialup.corbina.ru>
	<alpine.BSF.1.10.0808291709360.5866@thor.farley.org>
Message-ID: <20080830081408.GA91470@freebsd.org>

On Fri, Aug 29, 2008 at 05:10:57PM -0500, Sean C. Farley wrote:
> On Thu, 28 Aug 2008, Chagin Dmitry wrote:
> 
> >On Tue, Aug 26, 2008 at 08:22:34AM +0200, Roman Divacky wrote:
> 
> *snip*
> 
> >>what about this one? IIRC Dmitry posted a patch, does it fix the
> >>issue? can we commit that?
> >
> >I have sent to Sean a patch for testing...
> 
> It works on my amd64 system.  Thank you very much.

ok... great, dmitry, please send me the (minimal) patch and commit message you
suggest, I'll review it

Alexander, do you have any comment?

roman

From dchagin at freebsd.org  Sat Aug 30 11:35:33 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sat Aug 30 11:35:40 2008
Subject: Linux applications core if running (k)qemu
In-Reply-To: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
References: <alpine.BSF.1.10.0808291711580.5866@thor.farley.org>
Message-ID: <20080830113448.GA2152@dchagin.dialup.corbina.ru>

On Fri, Aug 29, 2008 at 05:29:09PM -0500, Sean C. Farley wrote:
> I am having trouble with kqemu.ko and linux.ko.  If I run qemu with the
> following command, Linux applications (chroot, acroread, ls) will start
> core dumping:
>     qemu-system-x86_64 -m 512 \
>     -drive file=/usr/QEMU/WinXP/c.img,if=ide,media=disk -boot c \
>     -std-vga -parallel none -serial none -monitor stdio \
>     -net nic,model=e1000 -net tap,ifname=tap0,script=no -localtime
> 
> Loading kqemu.ko does not cause the problem, but the cores start a
> little after WinXP starts running.  Unloading kqemu.ko does not help;
> the cores still happen but more randomly.  I even tried unloading all
> linux modules and reloading them without luck.  It takes a reboot.
> 
> Packages:
> qemu-devel-0.9.1s.20080620_1
> kqemu-kmod-devel-1.4.0.p1
> linux_base-f8-8_4
> 
> sysctl:
> compat.linux.osrelease: 2.6.16
> 
> dmesg:
> kqemu version 0x00010400
> kqemu: KQEMU installed, max_locked_mem=1792492kB.
> 
> System is 7-STABLE as of r181963 with or without the patch to fix RT
> signals from Chagin.
> 

Interestingly... Sean, can you provide ktrace/kdump log of coring apps?
thnx!

-- 
Have fun!
chd
From Alexander at Leidinger.net  Sat Aug 30 12:49:11 2008
From: Alexander at Leidinger.net (Alexander Leidinger)
Date: Sat Aug 30 12:49:18 2008
Subject: Current problem reports assigned to
 freebsd-emulation@FreeBSD.org
In-Reply-To: <20080830081408.GA91470@freebsd.org>
References: <200808251106.m7PB6mXT027718@freefall.freebsd.org>
	<20080826062233.GA44122@freebsd.org>
	<20080828173549.GA3315@dchagin.dialup.corbina.ru>
	<alpine.BSF.1.10.0808291709360.5866@thor.farley.org>
	<20080830081408.GA91470@freebsd.org>
Message-ID: <20080830144859.74dbd47d@deskjail>

Quoting Roman Divacky <rdivacky@FreeBSD.org> (Sat, 30 Aug 2008 10:14:08 +0200):

> On Fri, Aug 29, 2008 at 05:10:57PM -0500, Sean C. Farley wrote:
> > On Thu, 28 Aug 2008, Chagin Dmitry wrote:
> > 
> > >On Tue, Aug 26, 2008 at 08:22:34AM +0200, Roman Divacky wrote:
> > 
> > *snip*
> > 
> > >>what about this one? IIRC Dmitry posted a patch, does it fix the
> > >>issue? can we commit that?
> > >
> > >I have sent to Sean a patch for testing...
> > 
> > It works on my amd64 system.  Thank you very much.
> 
> ok... great, dmitry, please send me the (minimal) patch and commit message you
> suggest, I'll review it
> 
> Alexander, do you have any comment?

Go ahead. I will be busy with renovating and moving for some weeks.

Bye,
Alexander.

-- 
"He's my father's godson."
		-- Michael Corleone, "Chapter 1", page 42
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
From dchagin at freebsd.org  Sun Aug 31 11:06:30 2008
From: dchagin at freebsd.org (Chagin Dmitry)
Date: Sun Aug 31 11:06:38 2008
Subject: MPSAFE TTY: Linux PTY's
In-Reply-To: <20080822112946.GA97526@freebsd.org>
References: <20080822112927.GZ99951@hoeg.nl>
	<20080822112946.GA97526@freebsd.org>
Message-ID: <20080831110610.GA2380@dchagin.dialup.corbina.ru>

On Fri, Aug 22, 2008 at 01:29:46PM +0200, Roman Divacky wrote:
> On Fri, Aug 22, 2008 at 01:29:27PM +0200, Ed Schouten wrote:
> > Hello Emulation folks,
> > 
> > I just wanted to send you all a message to say one of the things I tried
> > to improve in the MPSAFE TTY branch was support for PTY's for Linux
> > binaries.
> > 
> > At home I've got a FreeBSD Jail running Debian Etch. Unfortunately,
> > Linux sendmsg() is a little broken on FreeBSD/amd64, but so far I've
> > been able to at least get OpenSSH (as root) and GNU Screen working.
> 
> I believe dmitry has a patch for this..

the patch is bellow, I tested a patch only on LTP tests (with little changes),
it's necessary to test on real apps, it will be good if Ed will test..

diff --git a/src/sys/compat/linux/linux_socket.c b/src/sys/compat/linux/linux_socket.c
index 7202944..41556bb 100644
--- a/src/sys/compat/linux/linux_socket.c
+++ b/src/sys/compat/linux/linux_socket.c
@@ -421,6 +421,65 @@ linux_sa_put(struct osockaddr *osa)
 }
 
 static int
+linux_to_bsd_cmsg_type(int cmsg_type)
+{
+
+	switch (cmsg_type) {
+	case LINUX_SCM_RIGHTS:
+		return (SCM_RIGHTS);
+	case LINUX_SCM_CREDENTIALS:
+		return (SCM_CREDS);
+	}
+	return (cmsg_type);
+}
+
+static int
+bsd_to_linux_cmsg_type(int cmsg_type)
+{
+
+	switch (cmsg_type) {
+	case SCM_RIGHTS:
+		return (LINUX_SCM_RIGHTS);
+	case SCM_CREDS:
+		return (LINUX_SCM_CREDENTIALS);
+	}
+	return (cmsg_type);
+}
+
+
+
+static int
+linux_to_bsd_msghdr(struct msghdr *bhdr, const struct l_msghdr *lhdr)
+{
+	if (lhdr->msg_controllen > INT_MAX)
+		return (ENOBUFS);
+
+	bhdr->msg_name		= PTRIN(lhdr->msg_name);
+	bhdr->msg_namelen	= lhdr->msg_namelen;
+	bhdr->msg_iov		= PTRIN(lhdr->msg_iov);
+	bhdr->msg_iovlen	= lhdr->msg_iovlen;
+	bhdr->msg_control	= PTRIN(lhdr->msg_control);
+	bhdr->msg_controllen	= lhdr->msg_controllen;
+	bhdr->msg_flags		= lhdr->msg_flags;
+	return (0);
+}
+
+static int
+bsd_to_linux_msghdr(const struct msghdr *bhdr, struct l_msghdr *lhdr)
+{
+	lhdr->msg_name		= bhdr->msg_name;
+	lhdr->msg_namelen	= bhdr->msg_namelen;
+	lhdr->msg_iov		= bhdr->msg_iov;
+	lhdr->msg_iovlen	= bhdr->msg_iovlen;
+	lhdr->msg_control	= bhdr->msg_control;
+	lhdr->msg_controllen	= bhdr->msg_controllen;
+	return (0);
+}
+
+#define CMSGHDR_SIZE			CMSG_LEN(0)
+#define L_CMSGHDR_SIZE			LINUX_CMSG_LEN(0)
+
+static int
 linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags,
     enum uio_seg segflg)
 {
@@ -437,25 +496,57 @@ linux_sendit(struct thread *td, int s, struct msghdr *mp, int flags,
 		to = NULL;
 
 	if (mp->msg_control != NULL) {
+		struct l_cmsghdr *ptr_cmsg;
+		struct l_cmsghdr linux_cmsg;
 		struct cmsghdr *cmsg;
-
-		if (mp->msg_controllen < sizeof(struct cmsghdr)) {
-			error = EINVAL;
-			goto bad;
-		}
-		error = sockargs(&control, mp->msg_control,
-		    mp->msg_controllen, MT_CONTROL);
-		if (error)
-			goto bad;
-
-		cmsg = mtod(control, struct cmsghdr *);
-		cmsg->cmsg_level = linux_to_bsd_sockopt_level(cmsg->cmsg_level);
+		void *data;
+		socklen_t datalen;
+
+		cmsg = malloc(CMSGHDR_SIZE, M_TEMP, M_WAITOK | M_ZERO);
+		control = m_get(M_WAIT, MT_CONTROL);
+		ptr_cmsg = LINUX_CMSG_FIRSTHDR(mp);
+
+		do {
+			error = copyin(ptr_cmsg, &linux_cmsg,
+			    sizeof(struct l_cmsghdr));
+			if (error)
+				goto bad;
+			if (linux_cmsg.cmsg_len < sizeof(struct l_cmsghdr) ||
+			    linux_cmsg.cmsg_len > INT_MAX) {
+				error = EINVAL;
+				goto bad;
+			}
+
+			switch (linux_cmsg.cmsg_type) {
+			case LINUX_SCM_RIGHTS:
+				cmsg->cmsg_type =
+				    linux_to_bsd_cmsg_type(linux_cmsg.cmsg_type);
+				break;
+			default:
+				error = EINVAL;
+				goto bad;
+			}
+			cmsg->cmsg_level =
+			    linux_to_bsd_sockopt_level(linux_cmsg.cmsg_level);
+
+			datalen = linux_cmsg.cmsg_len - L_CMSGHDR_SIZE;
+			cmsg->cmsg_len = CMSG_LEN(datalen);
+			data = LINUX_CMSG_DATA(ptr_cmsg);
+
+			error = ENOBUFS;
+			if (!m_append(control, CMSGHDR_SIZE, (c_caddr_t) cmsg))
+				goto bad;
+			if (!m_append(control, datalen, (c_caddr_t) data))
+				goto bad;
+
+		} while ((ptr_cmsg = LINUX_CMSG_NXTHDR(mp, ptr_cmsg)));
+
+		free(cmsg, M_TEMP);
 	} else
 		control = NULL;
 
 	error = kern_sendit(td, s, mp, linux_to_bsd_msg_flags(flags), control,
 	    segflg);
-
 bad:
 	if (to)
 		FREE(to, M_SONAME);
@@ -1014,17 +1105,15 @@ struct linux_sendmsg_args {
 static int
 linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args)
 {
-	struct linux_sendmsg_args linux_args;
 	struct msghdr msg;
+	struct l_msghdr linux_msg;
 	struct iovec *iov;
 	int error;
 
-	/* XXXTJR sendmsg is broken on amd64 */
-
-	error = copyin(args, &linux_args, sizeof(linux_args));
+	error = copyin(PTRIN(args->msg), &linux_msg, sizeof(linux_msg));
 	if (error)
 		return (error);
-	error = copyin(PTRIN(linux_args.msg), &msg, sizeof(msg));
+	error = linux_to_bsd_msghdr(&msg, &linux_msg);
 	if (error)
 		return (error);
 
@@ -1042,8 +1131,7 @@ linux_sendmsg(struct thread *td, struct linux_sendmsg_args *args)
 		return (error);
 	msg.msg_iov = iov;
 	msg.msg_flags = 0;
-	error = linux_sendit(td, linux_args.s, &msg, linux_args.flags,
-	    UIO_USERSPACE);
+	error = linux_sendit(td, args->s, &msg, args->flags, UIO_USERSPACE);
 	free(iov, M_IOV);
 	return (error);
 }
@@ -1057,48 +1145,116 @@ struct linux_recvmsg_args {
 static int
 linux_recvmsg(struct thread *td, struct linux_recvmsg_args *args)
 {
-	struct linux_recvmsg_args linux_args;
-	struct recvmsg_args /* {
-		int	s;
-		struct	msghdr *msg;
-		int	flags;
-	} */ bsd_args;
 	struct msghdr msg;
-	struct cmsghdr *cmsg;
+	struct l_msghdr linux_msg;
+	struct iovec *uiov, *iov;
+	struct mbuf *control = NULL;
+	struct mbuf **controlp;
+	struct l_cmsghdr *cmsg = NULL;
 	int error;
 
-	/* XXXTJR recvmsg is broken on amd64 */
-
-	if ((error = copyin(args, &linux_args, sizeof(linux_args))))
+	error = copyin(PTRIN(args->msg), &linux_msg, sizeof (linux_msg));
+	if (error)
 		return (error);
-
-	if ((error = copyin(PTRIN(args->msg), &msg, sizeof (msg))))
+	error = linux_to_bsd_msghdr(&msg, &linux_msg);
+	if (error)
 		return (error);
-
-	bsd_args.s = linux_args.s;
-	bsd_args.msg = PTRIN(linux_args.msg);
-	bsd_args.flags = linux_to_bsd_msg_flags(linux_args.flags);
-	if (msg.msg_name) {
-	   	linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name,
-		      msg.msg_namelen);
-		error = recvmsg(td, &bsd_args);
-		bsd_to_linux_sockaddr((struct sockaddr *)msg.msg_name);
-	} else
-	   	error = recvmsg(td, &bsd_args);
+	error = copyiniov(msg.msg_iov, msg.msg_iovlen, &iov, EMSGSIZE);
 	if (error)
 		return (error);
 
-	if (bsd_args.msg->msg_control != NULL &&
-	    bsd_args.msg->msg_controllen > 0) {
-		cmsg = (struct cmsghdr*)bsd_args.msg->msg_control;
-		cmsg->cmsg_level = bsd_to_linux_sockopt_level(cmsg->cmsg_level);
+	uiov = msg.msg_iov;
+	msg.msg_iov = iov;
+	msg.msg_flags = linux_to_bsd_msg_flags(linux_msg.msg_flags);
+
+	if (msg.msg_name) {
+		error = linux_to_bsd_sockaddr((struct sockaddr *)msg.msg_name,
+		    msg.msg_namelen);
+		if (error)
+			goto bad;
 	}
 
-	error = copyin(PTRIN(linux_args.msg), &msg, sizeof(msg));
+	controlp = (msg.msg_control != NULL) ? &control : NULL;
+	error = kern_recvit(td, args->s, &msg, UIO_USERSPACE, controlp);
 	if (error)
-		return (error);
-	if (msg.msg_name && msg.msg_namelen > 2)
-		error = linux_sa_put(msg.msg_name);
+		goto bad;
+
+	msg.msg_iov = uiov;
+
+	error = bsd_to_linux_msghdr(&msg, &linux_msg);
+	if (error)
+		goto bad;
+
+	if (linux_msg.msg_name)
+		bsd_to_linux_sockaddr((struct sockaddr *)linux_msg.msg_name);
+	if (linux_msg.msg_name && linux_msg.msg_namelen > 2) {
+		error = linux_sa_put(linux_msg.msg_name);
+		if (error)
+			goto bad;
+	}
+
+	if (control) {
+		caddr_t outbuf;
+		struct cmsghdr *cm;
+
+		socklen_t datalen, outlen;
+		socklen_t clen;
+		void *data;
+
+		cmsg = malloc(L_CMSGHDR_SIZE, M_TEMP, M_WAITOK | M_ZERO);
+		outbuf = linux_msg.msg_control;
+		cm = mtod(control, struct cmsghdr *);
+		outlen = 0;
+		clen = control->m_len;
+
+		while (cm != NULL) {
+			data = CMSG_DATA(cm);
+			datalen = (caddr_t)cm + cm->cmsg_len - (caddr_t)data;
+
+			outlen += LINUX_CMSG_LEN(datalen);
+			if (outlen > linux_msg.msg_controllen) {
+				linux_msg.msg_flags |= LINUX_MSG_CTRUNC;
+				break;
+			}
+
+			/*
+			 * XXX here special handler of SCM_CREDS
+			 */
+
+			cmsg->cmsg_len = LINUX_CMSG_LEN(datalen);
+			cmsg->cmsg_type = bsd_to_linux_cmsg_type(cm->cmsg_type);
+			cmsg->cmsg_level =
+			    bsd_to_linux_sockopt_level(cm->cmsg_level);
+
+			error = copyout(cmsg, outbuf, L_CMSGHDR_SIZE);
+			if (error)
+				goto bad;
+			outbuf += L_CMSGHDR_SIZE;
+
+			error = copyout(data, outbuf, datalen);
+			if (error)
+				goto bad;
+			outbuf += LINUX_CMSG_ALIGN(datalen);
+			linux_msg.msg_controllen = outlen;
+
+			if (CMSG_SPACE(datalen) < clen) {
+				clen -= CMSG_SPACE(datalen);
+				cm = (struct cmsghdr *)
+				    ((caddr_t)cm + CMSG_SPACE(datalen));
+			} else
+				cm = NULL;
+		}
+	}
+
+	error = copyout(&linux_msg, PTRIN(args->msg), sizeof(linux_msg));
+
+bad:
+	free(iov, M_IOV);
+
+	if (control != NULL)
+		m_freem(control);
+	if (cmsg != NULL)
+		free(cmsg, M_TEMP);
 	return (error);
 }
 
diff --git a/src/sys/compat/linux/linux_socket.h b/src/sys/compat/linux/linux_socket.h
index 074e8e0..668ec7f 100644
--- a/src/sys/compat/linux/linux_socket.h
+++ b/src/sys/compat/linux/linux_socket.h
@@ -49,4 +49,49 @@
 #define LINUX_MSG_ERRQUEUE	0x2000
 #define LINUX_MSG_NOSIGNAL	0x4000
 
+/* Socket-level control message types */
+
+#define LINUX_SCM_RIGHTS	0x01
+#define LINUX_SCM_CREDENTIALS	0x02
+
+struct l_msghdr {
+	void		*msg_name;
+	l_int		msg_namelen;
+	struct iovec	*msg_iov;
+	l_size_t	msg_iovlen;
+	void		*msg_control;
+	l_size_t	msg_controllen;
+	unsigned	msg_flags;
+};
+
+struct l_cmsghdr {
+	l_size_t	cmsg_len;
+	l_int		cmsg_level;
+	l_int		cmsg_type;
+};
+
+/* Ancilliary data object information macros */
+
+#define LINUX_CMSG_ALIGN(len)   (((len) + sizeof(long)-1) & ~(sizeof(long)-1))
+#define LINUX_CMSG_DATA(cmsg)   ((void *)((char *)(cmsg) + \
+				    LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr))))
+#define LINUX_CMSG_SPACE(len)	(LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \
+				    LINUX_CMSG_ALIGN(len))
+#define LINUX_CMSG_LEN(len)	(LINUX_CMSG_ALIGN(sizeof(struct l_cmsghdr)) + \
+				    (len))
+#define LINUX_CMSG_FIRSTHDR(msg) \
+				((msg)->msg_controllen >= \
+				    sizeof(struct l_cmsghdr) ? \
+				    (struct l_cmsghdr *)((msg)->msg_control) : \
+				    (struct l_cmsghdr *)(NULL))
+#define LINUX_CMSG_NXTHDR(msg, cmsg) \
+				((((char *)(cmsg) + \
+				    LINUX_CMSG_ALIGN((cmsg)->cmsg_len) + \
+				    sizeof(*(cmsg))) > \
+				    (((char *)(msg)->msg_control) + \
+				    (msg)->msg_controllen)) ? \
+				    (struct l_cmsghdr *) NULL : \
+				    (struct l_cmsghdr *)((char *)(cmsg) + \
+				    LINUX_CMSG_ALIGN((cmsg)->cmsg_len)))
+
 #endif /* _LINUX_SOCKET_H_ */


-- 
Have fun!
chd