From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 23 01:35:21 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5FA416A4CE for ; Mon, 23 Feb 2004 01:35:21 -0800 (PST) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDC4243D1D for ; Mon, 23 Feb 2004 01:35:20 -0800 (PST) (envelope-from farrenkopf@mail.sub.uni-goettingen.de) Received: from mail.sub.uni-goettingen.de ([134.76.163.85]) by mailer.gwdg.de with esmtp (Exim 4.20) id 1AvCUg-000692-Dt for freebsd-emulation@freebsd.org; Mon, 23 Feb 2004 10:35:18 +0100 Received: from SUB1/SpoolDir by mail.sub.uni-goettingen.de (Mercury 1.48); 23 Feb 04 10:35:18 +0100 Received: from SpoolDir by SUB1 (Mercury 1.48); 23 Feb 04 10:35:04 +0100 Received: from sub00261.sub.uni-goettingen.de (134.76.162.89) by mail.sub.uni-goettingen.de (Mercury 1.48) with ESMTP; 23 Feb 04 10:35:03 +0100 Date: Mon, 23 Feb 2004 10:35:03 +0100 From: Stefan Farrenkopf To: freebsd-emulation@freebsd.org Message-ID: <29370000.1077528903@sub00261.sub.uni-goettingen.de> X-Mailer: Mulberry/3.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie Subject: FreeBSD linux apps can not access mounted netware volumes X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Stefan Farrenkopf List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 09:35:22 -0000 Hello, (I hope this is the appropriate group, I posted the question already to "questions" and to some news groups.) I mount two NetWare shares within /etc/fstab at my FreeBSD desktop (using mount_nwfs) and I noticed in the past that linux applications like mulberry, acroread, etc. can not access these volumes. Instead they show an empty directory at the mount point and nothing below. Now I found that linux-mozilla-firebird (which is not my default browser) is also not able to access these shares, but it reports a permission problem: "You don't have the permissions necessary to view this directory" The permissions are set to 755 for all directories and to 644 for all files down the complete hierarchy. Owner and group are my local user:group. These are the lines from my /etc/fstab /SERVER:USER/user /home/sfarren/.NW/user nwfs rw,noauto,\ -A=SERVER 0 0 /SERVER:USER/data /home/sfarren/.NW/data nwfs rw,noauto,\ -A=SERVER 0 0 My colleagues with Linux boxes use ncpmount and do not encounter any problems with the NetWare shares. All application which run FreeBSD native have full access to the mounted NetWare volumes One of my colleagues made the suggestion that there may be a problem with stat() in the linux compatiblity environment which leads to the permission problem? Maybe someone knows how to solve this problem, it would help me to stay with FreeBSD on the Desktop, because the fact that I can not access each directory from some applications is really annoying in the long term run :( Any ideas are welcome :)) Does anyone know, if this issue is solved in rel. 5.x? best wishes and thanks for your help, Stefan From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 23 11:01:37 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11D7016A4D0 for ; Mon, 23 Feb 2004 11:01:37 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D65443D1F for ; Mon, 23 Feb 2004 11:01:37 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i1NJ1abv035116 for ; Mon, 23 Feb 2004 11:01:36 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i1NJ1aIL035110 for emulation@freebsd.org; Mon, 23 Feb 2004 11:01:36 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 23 Feb 2004 11:01:36 -0800 (PST) Message-Id: <200402231901.i1NJ1aIL035110@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: emulation@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 19:01:37 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/06/28] kern/53874 emulation /usr/ports/emulators/linux_base isn't wor 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/09/21] kern/21463 emulation Linux compatability mode should not allow o [2000/11/13] kern/22826 emulation Memory limits have no effect in linux com o [2000/12/14] misc/23561 emulation Linux compatibility mode does not support o [2001/03/28] kern/26171 emulation not work Linux-emulator, but hi is work i 4 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/19] misc/19391 emulation Evilness with Linux Terminus, causes X to o [2002/08/11] kern/41543 emulation Easier wine/w23 support p [2002/09/04] kern/42404 emulation TIOCSCTTY not implemented in linuxulator o [2002/11/26] kern/45785 emulation Linux WineX seems to require a few new li 4 problems total. From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 23 12:21:48 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BD5416A4CE for ; Mon, 23 Feb 2004 12:21:48 -0800 (PST) Received: from 194-185-53-242.f5.ngi.it (194-185-53-242.f5.ngi.it [194.185.53.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 407CF43D2D for ; Mon, 23 Feb 2004 12:21:47 -0800 (PST) (envelope-from mark@remotelab.org) Received: from einstein.lab (einstein.lab [192.168.168.2]) i1NKLjQ7001275; Mon, 23 Feb 2004 21:21:45 +0100 (CET) (envelope-from mark@remotelab.org) Received: from einstein.lab (localhost.lab [127.0.0.1]) by einstein.lab (8.12.10/8.12.10) with ESMTP id i1NKLaAp034187; Mon, 23 Feb 2004 21:21:36 +0100 (CET) (envelope-from mark@einstein.lab) Received: (from mark@localhost) by einstein.lab (8.12.10/8.12.10/Submit) id i1NKLaxL034186; Mon, 23 Feb 2004 21:21:36 +0100 (CET) (envelope-from mark) Date: Mon, 23 Feb 2004 21:21:36 +0100 From: Marco Trentini To: Mike Silbersack Message-ID: <20040223202136.GH657@einstein.lab> References: <20040217023115.W17031@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040217023115.W17031@odysseus.silby.com> User-Agent: Mutt/1.4.1i cc: emulation@freebsd.org Subject: Re: Another updated RTC driver for vmware users to try X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 20:21:48 -0000 On Tue, Feb 17, 2004 at 02:36:39AM -0600, Mike Silbersack wrote: > > Ok, I took a closer look at how the linux rtc driver actually works, and I > came up with this updated rtc driver. It should be a better emulation, > but my laptop is so pokey that I have trouble noticing a difference. It > appears that the current rtc is making the vmware client sleep too much, > so this might improve responsiveness a bit. > Great work! > Anyway, give it a shot and tell me how it works. I believe that this is > the last performance-related change to the driver, next up will be device > cloning. > > To build this, just throw rtc.c in the files/ directory of the rtc port > and rebuild it. What value should have the kernel HZ option? About 1000? Is 1300 proper? From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 23 12:42:20 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD7AF16A4CE for ; Mon, 23 Feb 2004 12:42:20 -0800 (PST) Received: from blackacid.thefrontnetworks.net (unknown [69.26.234.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B16843D1D for ; Mon, 23 Feb 2004 12:42:20 -0800 (PST) (envelope-from Lance@thefrontnetworks.net) Received: from 192.168.0.4 (vdsl-130-13-130-232.phnx.uswest.net [130.13.130.232]) by blackacid.thefrontnetworks.net (Postfix) with ESMTP id 29B352E019 for ; Mon, 23 Feb 2004 13:38:37 -0700 (MST) From: Lance Gilbert Organization: The Front Networks, LLC To: freebsd-emulation@freebsd.org Date: Mon, 23 Feb 2004 13:42:14 -0700 User-Agent: KMail/1.6 References: <200402231901.i1NJ1aIL035110@freefall.freebsd.org> In-Reply-To: <200402231901.i1NJ1aIL035110@freefall.freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402231342.14187.Lance@thefrontnetworks.net> Subject: Implimenting New Linux System Calls X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Lance@thefrontnetworks.net List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 20:42:20 -0000 Hi there, I'm new to the list, so excuse me if I bring up some topics which have been previously covered. (I just briefly looked through the mail archive) I have been working fairly extensively with the Linux emulation in FreeBSD over the past few months, primarily to get WineX 3.x working correctly under it. What concerns me, is that according to the response of 'uname -a' under Linux emulation, (chrooted) the implimentation is only at Linux kernel 2.4.2. With Linux already at 2.6.x and much later versions of 2.4.x, it would seem that FreeBSD's Linux emualation has started to fall behind in terms of syscalls. For example, I recently built a linux_base-Fedora port for myself. It uses a newer version of glibc then pervious linux_base. (glibc-2.3.2-101) As a result, even some simple commands like 'ls' core dump as a result of unimplemented system calls from newer linux kernels. I have tracked down the missing system call in question here, and it is an issue in "__pthread_initialize_minimal" from libpthread. (libpthread is provided by glibc) Point and case being, if things like 'ls' are core dumping now due to a lack of updated system calls, how long until this trend renders Linux Emulation useless, and what effect will the movement to 2.6 have here? Not to be completely glom-and-doom, I have started investigating the design of the Linux Emulation kernel module in order to start implimenting these calls myself, in an aim to keep it continually current with the current released Linux kernel. Is there already a team assigned to this task, or if not, would it perhaps be wise to start a project aimed at maintaining this? If anyone else is interested, I am also looking at the current state of linprocfs, and the challenges involved with updating that, especially given the fact that in 2.6 proc has changed fairly substantially. (Has there been any thought about how to manage 2.6 support while not breaking 2.4 support at this point?) My apologies for the long winded mail. Please feel free to respond to this on, or off list to me. -- Thanks, Lance Gilbert IT Department Head The Front Networks From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 23 13:32:53 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EF5216A4CE for ; Mon, 23 Feb 2004 13:32:53 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 481E343D1D for ; Mon, 23 Feb 2004 13:32:53 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.10/8.12.10) with ESMTP id i1NLWrOE047562; Mon, 23 Feb 2004 13:32:53 -0800 (PST) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.10/8.12.10/Submit) id i1NLWriN047561; Mon, 23 Feb 2004 13:32:53 -0800 (PST) (envelope-from marcel) Date: Mon, 23 Feb 2004 13:32:53 -0800 From: Marcel Moolenaar To: Lance Gilbert Message-ID: <20040223213253.GA47447@ns1.xcllnt.net> References: <200402231901.i1NJ1aIL035110@freefall.freebsd.org> <200402231342.14187.Lance@thefrontnetworks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402231342.14187.Lance@thefrontnetworks.net> User-Agent: Mutt/1.5.5.1i cc: freebsd-emulation@freebsd.org Subject: Re: Implimenting New Linux System Calls X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 21:32:53 -0000 On Mon, Feb 23, 2004 at 01:42:14PM -0700, Lance Gilbert wrote: > > Not to be completely glom-and-doom, I have started investigating the design of > the Linux Emulation kernel module in order to start implimenting these calls > myself, in an aim to keep it continually current with the current released > Linux kernel. Cool! > Is there already a team assigned to this task, or if not, would it perhaps be > wise to start a project aimed at maintaining this? The linux module is mostly unmaintained. Once in a while someone fixes the odd bug here or there or enhances it for some immediate need. My advice would be to submit PRs or find a committer who can commit your stuff and work with him/her. Note also that linux support is also present on alpha and it is expected that it is kept in sync with i386. The future will be even more interesting because linux emulation on amd64 is very much in demand. Linux emulation on ia64 is of less importance now, but not from the table. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 23 13:42:31 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F199016A4CE for ; Mon, 23 Feb 2004 13:42:30 -0800 (PST) Received: from multiplay.co.uk (www1.multiplay.co.uk [212.42.16.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F98943D31 for ; Mon, 23 Feb 2004 13:42:30 -0800 (PST) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [212.42.16.7]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 61-md50000000257.tmp for ; Mon, 23 Feb 2004 21:32:53 +0000 Message-ID: <025501c3fa55$e39a4bd0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Marcel Moolenaar" , "Lance Gilbert" References: <200402231901.i1NJ1aIL035110@freefall.freebsd.org><200402231342.14187.Lance@thefrontnetworks.net> <20040223213253.GA47447@ns1.xcllnt.net> Date: Mon, 23 Feb 2004 21:42:09 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: multiplay.co.uk, Mon, 23 Feb 2004 21:32:53 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-emulation@freebsd.org cc: freebsd-emulation@freebsd.org Subject: Re: Implimenting New Linux System Calls X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2004 21:42:31 -0000 It is indeed 5.2.1 did bring some much needed updates including updating the function table considerably. Steve / K ----- Original Message ----- From: "Marcel Moolenaar" To: "Lance Gilbert" Cc: Sent: Monday, February 23, 2004 9:32 PM Subject: Re: Implimenting New Linux System Calls > On Mon, Feb 23, 2004 at 01:42:14PM -0700, Lance Gilbert wrote: > > > > Not to be completely glom-and-doom, I have started investigating the design of > > the Linux Emulation kernel module in order to start implimenting these calls > > myself, in an aim to keep it continually current with the current released > > Linux kernel. > > Cool! > > > Is there already a team assigned to this task, or if not, would it perhaps be > > wise to start a project aimed at maintaining this? > > The linux module is mostly unmaintained. Once in a while someone fixes the > odd bug here or there or enhances it for some immediate need. My advice > would be to submit PRs or find a committer who can commit your stuff and > work with him/her. > > Note also that linux support is also present on alpha and it is expected > that it is kept in sync with i386. The future will be even more interesting > because linux emulation on amd64 is very much in demand. Linux emulation > on ia64 is of less importance now, but not from the table. > > FYI, > > -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.org" > > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 23 22:31:16 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAD4316A4CE for ; Mon, 23 Feb 2004 22:31:16 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7BAAC43D49 for ; Mon, 23 Feb 2004 22:31:16 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 20005 invoked from network); 24 Feb 2004 06:31:15 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 24 Feb 2004 06:31:15 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 24 Feb 2004 00:31:14 -0600 (CST) From: Mike Silbersack To: Byron Brummer In-Reply-To: <40384AB5.80608@rhps.org> Message-ID: <20040224002250.R5797@odysseus.silby.com> References: <20040217023115.W17031@odysseus.silby.com> <40384AB5.80608@rhps.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: emulation@freebsd.org Subject: Re: Another updated RTC driver for vmware users to try X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 06:31:16 -0000 On Sat, 21 Feb 2004, Byron Brummer wrote: > I'm happy to report I just gave this update a whirl and it made a > *HUGE* difference. Not quite 100% the match with Linux's > performance running the Alleg server, but lightyears better then > the last version (which was lightyears beyond the version it > replaced). Good! > So from a user perspective it looks like you're very much on > the right track. You say it sleeps too much...is there a way, > perhaps at the cost of extra CPU, to "overclock" the RTC driver > so that it barely sleeps if at all? Because of the "twitch" > nature of this game I care more about the response of this server > then of anything else on the machine. It would be possible to "overclock" the rtc driver, you could simply go into the code and find the rtc_ioctl function. Change the line "sc->var.freq = freq" to "sc->var.freq = freq * 2", and the interrupts should come at 2x the clockrate! (Make sure to up your system's kern.hz appropriately so that the extra rate really happens.) However, I don't think that is the problem. As you'll note in rtc_read, the driver tracks the number of interrupts which were missed, meaning that vmware did not call rtc_read to check in X number of interrupts. Well, when I threw a printf in there monitoring the count, I saw frequent spikes, as high as 200 missed interrupts at a time. This was with a virtually idle virtual machine! Whether this really means that vmware is getting behind or not, I am unsure. However, it does seem to suggest that the rtc driver is about as good as it is going to get, and that I may need to look elsewhere in the FreeBSD code to find the bottlenecks relative to the linux modules. Try the "overclocking" above and see how it works. Perhaps if it's successful I should make it the default. :) Hm, one other thought just struck me... I'm relying on the select syscall to perform the wakeups... perhaps our select is doing some sort of rounding off which is reducing the accuracy of the wakeups, I'll have to check that out. Mike "Silby" Silbersack From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 23 22:36:14 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24A8E16A4CE for ; Mon, 23 Feb 2004 22:36:14 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B502643D2D for ; Mon, 23 Feb 2004 22:36:13 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 21805 invoked from network); 24 Feb 2004 06:36:12 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 24 Feb 2004 06:36:12 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 24 Feb 2004 00:36:11 -0600 (CST) From: Mike Silbersack To: Byron Brummer In-Reply-To: <20040224002250.R5797@odysseus.silby.com> Message-ID: <20040224003433.Q5797@odysseus.silby.com> References: <20040217023115.W17031@odysseus.silby.com> <40384AB5.80608@rhps.org> <20040224002250.R5797@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: emulation@freebsd.org Subject: Re: Another updated RTC driver for vmware users to try X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 06:36:14 -0000 On Tue, 24 Feb 2004, Mike Silbersack wrote: > Hm, one other thought just struck me... I'm relying on the select syscall > to perform the wakeups... perhaps our select is doing some sort of > rounding off which is reducing the accuracy of the wakeups, I'll have to > check that out. > > Mike "Silby" Silbersack Ignore that thought. Although the process is waiting in select, it's my rtc routine which is woken up by tsleep and is calling selwakeup, there's no delay due to select's timeout routine whatsoever. Mike "Silby" Silbersack From owner-freebsd-emulation@FreeBSD.ORG Tue Feb 24 15:12:14 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 892E316A4CE for ; Tue, 24 Feb 2004 15:12:14 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1533343D2F for ; Tue, 24 Feb 2004 15:12:14 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 65729 invoked from network); 24 Feb 2004 23:12:12 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 24 Feb 2004 23:12:12 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 24 Feb 2004 17:12:11 -0600 (CST) From: Mike Silbersack To: Marco Trentini In-Reply-To: <20040223202136.GH657@einstein.lab> Message-ID: <20040224170758.N772@odysseus.silby.com> References: <20040217023115.W17031@odysseus.silby.com> <20040223202136.GH657@einstein.lab> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: emulation@freebsd.org Subject: Re: Another updated RTC driver for vmware users to try X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2004 23:12:14 -0000 On Mon, 23 Feb 2004, Marco Trentini wrote: > Great work! Thanks, I have gone ahead and committed this edition of the driver to the ports tree. > What value should have the kernel HZ option? > About 1000? Is 1300 proper? Good question, I'm not exactly sure. Higher should be better, but as far as I can tell, the rtc driver is really not the limiting factor in VMWare performance anymore. So, I think 1000 HZ should be sufficient for normal operation. The major exception to this would be in situations where the virtual machine uses a large hz setting that approaches your system's hz setting. I may take that hz warning out in the next version, I'm still thinking about it. Mike "Silby" Silbersack From owner-freebsd-emulation@FreeBSD.ORG Wed Feb 25 01:48:21 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3247B16A4CE for ; Wed, 25 Feb 2004 01:48:21 -0800 (PST) Received: from mailer.gwdg.de (mailer.gwdg.de [134.76.10.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99FC543D1D for ; Wed, 25 Feb 2004 01:48:20 -0800 (PST) (envelope-from sfarren@gwdg.de) Received: from sub00261.sub.uni-goettingen.de ([134.76.162.89]) by mailer.gwdg.de with esmtp (Exim 4.20) id 1AvveN-0000xu-EO for freebsd-emulation@freebsd.org; Wed, 25 Feb 2004 10:48:19 +0100 Date: Wed, 25 Feb 2004 10:48:19 +0100 From: Stefan Farrenkopf To: freebsd-emulation@freebsd.org Message-ID: <2300000.1077702499@sub00261.sub.uni-goettingen.de> X-Mailer: Mulberry/3.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Level: / X-Spam-Report: Content analysis: 0.0 points, 6.0 required X-Virus-Scanned: (clean) by exiscan+sophie Subject: Re: FreeBSD linux apps can not access mounted netware volumes X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Stefan Farrenkopf List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 09:48:21 -0000 Hi, I forgot to mention an important observation :( I am really sorry about that and I will add it now: Even if acroread and other linux apps do not see into the NetWare mounts: if I navigate with a file browser like nautilus into the netware volumes it's always possible to select a *.pdf file and to open it with the open dialog or with "acroread " from the command line. But with linux-mozillafirebird it is not possible to do the same thing with *.html documents (maybe I have a syntax problem with that?). AND: if I save a file and I select a deeper link into the Netware tree (which appears also emtpy in the save dialog), I can write the file into that directory with acroread, but I get a message "invalid path" from Mulberry. Otherwise I can go to one of my NetWare Volumes and "cd" into a random directory. When I start Mulberry from the command line and set it's initial directory path to a directory inside of the mounted NetWare Volumes, it creates a new directory (.mulberry) there which contains a new preferences file. So Mulberry is able to create files in the NetWare Volumes in general! This fact points to a problem with the linux compat layer(?) Anyway, I really appreciate your help. Thank you very much! best wishes, Stefan From owner-freebsd-emulation@FreeBSD.ORG Wed Feb 25 16:52:59 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EA2F16A4CE for ; Wed, 25 Feb 2004 16:52:59 -0800 (PST) Received: from jupiter.okstate.edu (jupiter.okstate.edu [139.78.100.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EA8643D1F for ; Wed, 25 Feb 2004 16:52:59 -0800 (PST) (envelope-from lreid@okstate.edu) Received: from dexter.okstate.edu (dexter.okstate.edu [139.78.100.26]) i1Q0qtw14396 for ; Wed, 25 Feb 2004 18:52:58 -0600 Received: from localhost (tools.you.okstate.edu [139.78.102.9]) by dexter.okstate.edu (Sun Internet Mail Server sims.4.0.2001.07.26.11.50.p9) with ESMTP id <0HTO00JDE2G69T@dexter.okstate.edu> for freebsd-emulation@freebsd.org; Wed, 25 Feb 2004 18:52:55 -0600 (CST) Received: from 63.68.159.2 ([63.68.159.2]) by webmail.okstate.edu (IMP) with HTTP for ; Wed, 25 Feb 2004 18:55:15 -0600 Date: Wed, 25 Feb 2004 18:55:15 -0600 From: Reid Linnemann To: freebsd-emulation@freebsd.org Message-id: <1077756915.403d43f331556@webmail.okstate.edu> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 Subject: linux mmap2 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 00:52:59 -0000 Hey all, I've got a little dilemma I need some hints with... I am running FreeBSD 4.9-STABLE, and trying to get a linux binary operating that uses mmap2. I've read a conversation kenneth culver had about his efforts, and from what I can tell mmap2 is implemented in -CURRENT - but not in -STABLE. Is there any way I can grab the -CURRENT version of the linuxulator, or cut'n'paste the changes kenneth made, and get mmap2 working? I had found, and later lost, kenneths record of changes he made to the linuxulator - if anyone can point me to them I would appreciate that as well. thanks, -Reid From owner-freebsd-emulation@FreeBSD.ORG Thu Feb 26 00:07:40 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5010116A4CE for ; Thu, 26 Feb 2004 00:07:40 -0800 (PST) Received: from zeweb.mindstep.com (zeweb.mindstep.com [209.188.85.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C398643D2D for ; Thu, 26 Feb 2004 00:07:38 -0800 (PST) (envelope-from bsdcvs-emul@mindstep.com) Received: from localhost (localhost.local.mindstep.com [127.0.0.1]) by hottub.local.mindstep.com (Postfix) with ESMTP id CED8BABC4; Thu, 26 Feb 2004 03:08:16 -0500 (EST) (envelope-from bsdcvs-emul@mindstep.com) Received: from hottub.local.mindstep.com ([127.0.0.1]) port 10024) with LMTP id 40475-02-4; Thu, 26 Feb 2004 03:08:10 -0500 (EST) Received: from mindstep.com (foudre.ontheroad.mindstep.com [192.168.50.7]) by hottub.local.mindstep.com (Postfix) with ESMTP id 336F3A9D9; Thu, 26 Feb 2004 03:08:03 -0500 (EST) (envelope-from bsdcvs-emul@mindstep.com) Message-ID: <403DA87E.1050308@mindstep.com> Date: Thu, 26 Feb 2004 09:04:14 +0100 From: Patrick Bihan-Faou Organization: netZuno Technologies User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-emulation@freebsd.org References: <1077756915.403d43f331556@webmail.okstate.edu> In-Reply-To: <1077756915.403d43f331556@webmail.okstate.edu> Content-Type: multipart/mixed; boundary="------------000007000808000004040709" X-Virus-Scanned: by amavisd-new on ZunoBox X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on hottub.local.mindstep.com cc: Reid Linnemann Subject: Re: linux mmap2 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 08:07:40 -0000 This is a multi-part message in MIME format. --------------000007000808000004040709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reid Linnemann wrote: >Hey all, I've got a little dilemma I need some hints with... > >I am running FreeBSD 4.9-STABLE, and trying to get a linux binary operating >that uses mmap2. I've read a conversation kenneth culver had about his efforts, >and from what I can tell mmap2 is implemented in -CURRENT - but not in -STABLE. >Is there any way I can grab the -CURRENT version of the linuxulator, or >cut'n'paste the changes kenneth made, and get mmap2 working? I had found, and >later lost, kenneths record of changes he made to the linuxulator - if anyone >can point me to them I would appreciate that as well. > > > In addition to mmap2 you'll probably need the ftruncate64 call. Here is a patch for FreeBSD 4.9 RELEASE that will add a few usefull syscalls. The implementation usually comes from FreeBSD 5.x or other not yet commited PRs. It has worked for me so far. Patrick. --------------000007000808000004040709 Content-Type: text/plain; name="linux_patches.shar" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="linux_patches.shar" # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # . # ./sys # ./sys/compat # ./sys/compat/linux # ./sys/compat/linux/linux_file.c.patch # ./sys/compat/linux/linux_ipc.c.patch # ./sys/i386 # ./sys/i386/linux # ./sys/i386/linux/linux.h.patch # ./sys/i386/linux/linux_dummy.c.patch # ./sys/i386/linux/linux_machdep.c.patch # ./sys/i386/linux/linux_sysvec.c.patch # echo c - . mkdir -p . > /dev/null 2>&1 echo c - ./sys mkdir -p ./sys > /dev/null 2>&1 echo c - ./sys/compat mkdir -p ./sys/compat > /dev/null 2>&1 echo c - ./sys/compat/linux mkdir -p ./sys/compat/linux > /dev/null 2>&1 echo x - ./sys/compat/linux/linux_file.c.patch sed 's/^X//' >./sys/compat/linux/linux_file.c.patch << 'SHAR-EOF-MARKER-73db4bcbd0dbd2530319f0beaf7528fd' X--- linux_file.c.orig X+++ linux_file.c X@@ -654,6 +654,26 @@ X } X X int X+linux_truncate64(struct proc *p, struct linux_truncate64_args *args) X+{ X+ struct truncate_args bsd; X+ caddr_t sg; X+ X+ sg = stackgap_init(); X+ CHECKALTEXIST(p, &sg, args->path); X+ X+#ifdef DEBUG X+ if (ldebug(truncate)) X+ printf(ARGS(truncate, "%s, %ld"), args->path, X+ (long)args->length); X+#endif X+ bsd.path = args->path; X+ bsd.length = args->length; X+ X+ return truncate(p, &bsd); X+} X+ X+int X linux_link(struct proc *p, struct linux_link_args *args) X { X struct link_args bsd; SHAR-EOF-MARKER-73db4bcbd0dbd2530319f0beaf7528fd echo x - ./sys/compat/linux/linux_ipc.c.patch sed 's/^X//' >./sys/compat/linux/linux_ipc.c.patch << 'SHAR-EOF-MARKER-567afdfde5ef3c7f68f72519ac8d7ca7' X--- linux_ipc.c.orig X+++ linux_ipc.c X@@ -80,6 +80,20 @@ X l_ushort seq; X }; X X+struct l_ipc64_perm { X+ l_key_t key; X+ l_uid_t uid; X+ l_gid_t gid; X+ l_uid_t cuid; X+ l_gid_t cgid; X+ l_ushort mode; X+ l_ushort __pad1; X+ l_ushort seq; X+ l_ushort __pad2; X+ l_ulong __unused1; X+ l_ulong __unused2; X+}; X+ X static void X linux_to_bsd_ipc_perm(struct l_ipc_perm *lpp, struct ipc_perm *bpp) X { X@@ -92,6 +106,18 @@ X bpp->seq = lpp->seq; X } X X+static void X+linux_to_bsd_ipc64_perm(struct l_ipc64_perm *lpp, struct ipc_perm *bpp) X+{ X+ bpp->key = lpp->key; X+ bpp->uid = lpp->uid; X+ bpp->gid = lpp->gid; X+ bpp->cuid = lpp->cuid; X+ bpp->cgid = lpp->cgid; X+ bpp->mode = lpp->mode; X+ bpp->seq = lpp->seq; X+} X+ X X static void X bsd_to_linux_ipc_perm(struct ipc_perm *bpp, struct l_ipc_perm *lpp) X@@ -105,6 +131,18 @@ X lpp->seq = bpp->seq; X } X X+static void X+bsd_to_linux_ipc64_perm(struct ipc_perm *bpp, struct l_ipc64_perm *lpp) X+{ X+ lpp->key = bpp->key; X+ lpp->uid = bpp->uid; X+ lpp->gid = bpp->gid; X+ lpp->cuid = bpp->cuid; X+ lpp->cgid = bpp->cgid; X+ lpp->mode = bpp->mode; X+ lpp->seq = bpp->seq; X+} X+ X struct l_semid_ds { X struct l_ipc_perm sem_perm; X l_time_t sem_otime; X@@ -116,6 +154,17 @@ X l_ushort sem_nsems; X }; X X+struct l_semid64_ds { X+ struct l_ipc64_perm sem_perm; X+ l_time_t sem_otime; X+ l_time_t sem_ctime; X+ void *sem_base; X+ void *sem_pending; X+ void *sem_pending_last; X+ void *undo; X+ l_ushort sem_nsems; X+}; X+ X struct l_shmid_ds { X struct l_ipc_perm shm_perm; X l_int shm_segsz; X@@ -130,6 +179,20 @@ X void *private3; X }; X X+struct l_shmid64_ds { X+ struct l_ipc64_perm shm_perm; X+ l_int shm_segsz; X+ l_time_t shm_atime; X+ l_time_t shm_dtime; X+ l_time_t shm_ctime; X+ l_ushort shm_cpid; X+ l_ushort shm_lpid; X+ l_short shm_nattch; X+ l_ushort private1; X+ void *private2; X+ void *private3; X+}; X+ X static void X linux_to_bsd_semid_ds(struct l_semid_ds *lsp, struct semid_ds *bsp) X { X@@ -141,6 +204,16 @@ X } X X static void X+linux_to_bsd_semid64_ds(struct l_semid64_ds *lsp, struct semid_ds *bsp) X+{ X+ linux_to_bsd_ipc64_perm(&lsp->sem_perm, &bsp->sem_perm); X+ bsp->sem_otime = lsp->sem_otime; X+ bsp->sem_ctime = lsp->sem_ctime; X+ bsp->sem_nsems = lsp->sem_nsems; X+ bsp->sem_base = lsp->sem_base; X+} X+ X+static void X bsd_to_linux_semid_ds(struct semid_ds *bsp, struct l_semid_ds *lsp) X { X bsd_to_linux_ipc_perm(&bsp->sem_perm, &lsp->sem_perm); X@@ -151,6 +224,16 @@ X } X X static void X+bsd_to_linux_semid64_ds(struct semid_ds *bsp, struct l_semid64_ds *lsp) X+{ X+ bsd_to_linux_ipc64_perm(&bsp->sem_perm, &lsp->sem_perm); X+ lsp->sem_otime = bsp->sem_otime; X+ lsp->sem_ctime = bsp->sem_ctime; X+ lsp->sem_nsems = bsp->sem_nsems; X+ lsp->sem_base = bsp->sem_base; X+} X+ X+static void X linux_to_bsd_shmid_ds(struct l_shmid_ds *lsp, struct shmid_ds *bsp) X { X linux_to_bsd_ipc_perm(&lsp->shm_perm, &bsp->shm_perm); X@@ -163,6 +246,19 @@ X bsp->shm_ctime = lsp->shm_ctime; X bsp->shm_internal = lsp->private3; /* this goes (yet) SOS */ X } X+static void X+linux_to_bsd_shmid64_ds(struct l_shmid64_ds *lsp, struct shmid_ds *bsp) X+{ X+ linux_to_bsd_ipc64_perm(&lsp->shm_perm, &bsp->shm_perm); X+ bsp->shm_segsz = lsp->shm_segsz; X+ bsp->shm_lpid = lsp->shm_lpid; X+ bsp->shm_cpid = lsp->shm_cpid; X+ bsp->shm_nattch = lsp->shm_nattch; X+ bsp->shm_atime = lsp->shm_atime; X+ bsp->shm_dtime = lsp->shm_dtime; X+ bsp->shm_ctime = lsp->shm_ctime; X+ bsp->shm_internal = lsp->private3; /* this goes (yet) SOS */ X+} X X static void X bsd_to_linux_shmid_ds(struct shmid_ds *bsp, struct l_shmid_ds *lsp) X@@ -178,6 +274,20 @@ X lsp->private3 = bsp->shm_internal; /* this goes (yet) SOS */ X } X X+static void X+bsd_to_linux_shmid64_ds(struct shmid_ds *bsp, struct l_shmid64_ds *lsp) X+{ X+ bsd_to_linux_ipc64_perm(&bsp->shm_perm, &lsp->shm_perm); X+ lsp->shm_segsz = bsp->shm_segsz; X+ lsp->shm_lpid = bsp->shm_lpid; X+ lsp->shm_cpid = bsp->shm_cpid; X+ lsp->shm_nattch = bsp->shm_nattch; X+ lsp->shm_atime = bsp->shm_atime; X+ lsp->shm_dtime = bsp->shm_dtime; X+ lsp->shm_ctime = bsp->shm_ctime; X+ lsp->private3 = bsp->shm_internal; /* this goes (yet) SOS */ X+} X+ X int X linux_semop(struct proc *p, struct linux_semop_args *args) X { X@@ -212,6 +322,7 @@ X linux_semctl(struct proc *p, struct linux_semctl_args *args) X { X struct l_semid_ds linux_semid; X+ struct l_semid64_ds linux_semid64; X struct __semctl_args /* { X int semid; X int semnum; X@@ -261,6 +372,15 @@ X unptr->buf = stackgap_alloc(&sg, sizeof(struct semid_ds)); X linux_to_bsd_semid_ds(&linux_semid, unptr->buf); X return __semctl(p, &bsd_args); X+ case LINUX_IPC_SET|LINUX_IPC_64: X+ bsd_args.cmd = IPC_SET; X+ error = copyin((caddr_t)args->arg.buf, &linux_semid64, X+ sizeof(linux_semid64)); X+ if (error) X+ return (error); X+ unptr->buf = stackgap_alloc(&sg, sizeof(struct semid_ds)); X+ linux_to_bsd_semid64_ds(&linux_semid64, unptr->buf); X+ return __semctl(p, &bsd_args); X case LINUX_IPC_STAT: X bsd_args.cmd = IPC_STAT; X unptr->buf = stackgap_alloc(&sg, sizeof(struct semid_ds)); X@@ -272,6 +392,17 @@ X bsd_to_linux_semid_ds(unptr->buf, &linux_semid); X return copyout(&linux_semid, (caddr_t)args->arg.buf, X sizeof(linux_semid)); X+ case LINUX_IPC_STAT|LINUX_IPC_64: X+ bsd_args.cmd = IPC_STAT; X+ unptr->buf = stackgap_alloc(&sg, sizeof(struct semid_ds)); X+ error = __semctl(p, &bsd_args); X+ if (error) X+ return error; X+ p->p_retval[0] = IXSEQ_TO_IPCID(bsd_args.semid, X+ unptr->buf->sem_perm); X+ bsd_to_linux_semid64_ds(unptr->buf, &linux_semid64); X+ return copyout(&linux_semid64, (caddr_t)args->arg.buf, X+ sizeof(linux_semid64)); X case LINUX_IPC_INFO: X case LINUX_SEM_INFO: X error = copyin((caddr_t)args->arg.buf, &linux_seminfo, X@@ -421,6 +552,7 @@ X linux_shmctl(struct proc *p, struct linux_shmctl_args *args) X { X struct l_shmid_ds linux_shmid; X+ struct l_shmid64_ds linux_shmid64; X struct shmctl_args /* { X int shmid; X int cmd; X@@ -439,6 +571,15 @@ X bsd_to_linux_shmid_ds(bsd_args.buf, &linux_shmid); X return copyout(&linux_shmid, (caddr_t)args->buf, sizeof(linux_shmid)); X X+ case LINUX_IPC_STAT|LINUX_IPC_64: X+ bsd_args.shmid = args->shmid; X+ bsd_args.cmd = IPC_STAT; X+ bsd_args.buf = (struct shmid_ds*)stackgap_alloc(&sg, sizeof(struct shmid_ds)); X+ if ((error = shmctl(p, &bsd_args))) X+ return error; X+ bsd_to_linux_shmid64_ds(bsd_args.buf, &linux_shmid64); X+ return copyout(&linux_shmid64, (caddr_t)args->buf, sizeof(linux_shmid64)); X+ X case LINUX_IPC_SET: X if ((error = copyin((caddr_t)args->buf, &linux_shmid, X sizeof(linux_shmid)))) X@@ -449,6 +590,16 @@ X bsd_args.cmd = IPC_SET; X return shmctl(p, &bsd_args); X X+ case LINUX_IPC_SET|LINUX_IPC_64: X+ if ((error = copyin((caddr_t)args->buf, &linux_shmid64, X+ sizeof(linux_shmid64)))) X+ return error; X+ bsd_args.buf = (struct shmid_ds*)stackgap_alloc(&sg, sizeof(struct shmid_ds)); X+ linux_to_bsd_shmid64_ds(&linux_shmid64, bsd_args.buf); X+ bsd_args.shmid = args->shmid; X+ bsd_args.cmd = IPC_SET; X+ return shmctl(p, &bsd_args); X+ X case LINUX_IPC_RMID: X bsd_args.shmid = args->shmid; X bsd_args.cmd = IPC_RMID; X@@ -460,6 +611,20 @@ X return error; X bsd_args.buf = (struct shmid_ds*)stackgap_alloc(&sg, sizeof(struct shmid_ds)); X linux_to_bsd_shmid_ds(&linux_shmid, bsd_args.buf); X+ } X+ return shmctl(p, &bsd_args); X+ X+ case LINUX_IPC_RMID|LINUX_IPC_64: X+ bsd_args.shmid = args->shmid; X+ bsd_args.cmd = IPC_RMID; X+ if (args->buf == NULL) X+ bsd_args.buf = NULL; X+ else { X+ if ((error = copyin((caddr_t)args->buf, &linux_shmid64, X+ sizeof(linux_shmid64)))) X+ return error; X+ bsd_args.buf = (struct shmid_ds*)stackgap_alloc(&sg, sizeof(struct shmid_ds)); X+ linux_to_bsd_shmid64_ds(&linux_shmid64, bsd_args.buf); X } X return shmctl(p, &bsd_args); X SHAR-EOF-MARKER-567afdfde5ef3c7f68f72519ac8d7ca7 echo c - ./sys/i386 mkdir -p ./sys/i386 > /dev/null 2>&1 echo c - ./sys/i386/linux mkdir -p ./sys/i386/linux > /dev/null 2>&1 echo x - ./sys/i386/linux/linux.h.patch sed 's/^X//' >./sys/i386/linux/linux.h.patch << 'SHAR-EOF-MARKER-0e3d93c3f5eb4a3d5b1172cad960e4ba' X--- linux.h.orig X+++ linux.h X@@ -532,6 +532,9 @@ X #define LINUX_IPC_STAT 2 X #define LINUX_IPC_INFO 3 X X+#define LINUX_IPC_OLD 0 X+#define LINUX_IPC_64 0x0100 X+ X #define LINUX_SHM_LOCK 11 X #define LINUX_SHM_UNLOCK 12 X #define LINUX_SHM_STAT 13 SHAR-EOF-MARKER-0e3d93c3f5eb4a3d5b1172cad960e4ba echo x - ./sys/i386/linux/linux_dummy.c.patch sed 's/^X//' >./sys/i386/linux/linux_dummy.c.patch << 'SHAR-EOF-MARKER-1b3f6aae2a39aa5043a0bf5f1e7e0cb4' X--- linux_dummy.c.orig X+++ linux_dummy.c X@@ -64,8 +64,8 @@ X DUMMY(capget); X DUMMY(capset); X DUMMY(sendfile); X-DUMMY(mmap2); X-DUMMY(truncate64); X+/*DUMMY(mmap2);*/ X+/*DUMMY(truncate64);*/ X DUMMY(setfsuid); X DUMMY(setfsgid); X DUMMY(pivot_root); SHAR-EOF-MARKER-1b3f6aae2a39aa5043a0bf5f1e7e0cb4 echo x - ./sys/i386/linux/linux_machdep.c.patch sed 's/^X//' >./sys/i386/linux/linux_machdep.c.patch << 'SHAR-EOF-MARKER-013eaf3882bdcd8e8dd36a2101827a2e' X--- linux_machdep.c.orig X+++ linux_machdep.c X@@ -381,6 +381,120 @@ X #define GUARD_SIZE (4 * PAGE_SIZE) X X int X+linux_mmap2(struct proc *p, struct linux_mmap2_args *linux_args) X+{ X+ struct mmap_args /* { X+ caddr_t addr; X+ size_t len; X+ int prot; X+ int flags; X+ int fd; X+ long pad; X+ off_t pos; X+ } */ bsd_args; X+ X+#ifdef DEBUG X+ if (ldebug(mmap2)) X+ printf(ARGS(mmap2, "%p, %d, %d, 0x%08x, %d, %d"), X+ (void *)linux_args->addr, linux_args->len, linux_args->prot, X+ linux_args->flags, linux_args->fd, linux_args->pos); X+#endif X+ X+ bsd_args.flags = 0; X+ if (linux_args->flags & LINUX_MAP_SHARED) X+ bsd_args.flags |= MAP_SHARED; X+ if (linux_args->flags & LINUX_MAP_PRIVATE) X+ bsd_args.flags |= MAP_PRIVATE; X+ if (linux_args->flags & LINUX_MAP_FIXED) X+ bsd_args.flags |= MAP_FIXED; X+ if (linux_args->flags & LINUX_MAP_ANON) X+ bsd_args.flags |= MAP_ANON; X+ else X+ bsd_args.flags |= MAP_NOSYNC; X+ if (linux_args->flags & LINUX_MAP_GROWSDOWN) { X+ bsd_args.flags |= MAP_STACK; X+ X+ /* The linux MAP_GROWSDOWN option does not limit auto X+ * growth of the region. Linux mmap with this option X+ * takes as addr the inital BOS, and as len, the initial X+ * region size. It can then grow down from addr without X+ * limit. However, linux threads has an implicit internal X+ * limit to stack size of STACK_SIZE. Its just not X+ * enforced explicitly in linux. But, here we impose X+ * a limit of (STACK_SIZE - GUARD_SIZE) on the stack X+ * region, since we can do this with our mmap. X+ * X+ * Our mmap with MAP_STACK takes addr as the maximum X+ * downsize limit on BOS, and as len the max size of X+ * the region. It them maps the top SGROWSIZ bytes, X+ * and autgrows the region down, up to the limit X+ * in addr. X+ * X+ * If we don't use the MAP_STACK option, the effect X+ * of this code is to allocate a stack region of a X+ * fixed size of (STACK_SIZE - GUARD_SIZE). X+ */ X+ X+ /* This gives us TOS */ X+ bsd_args.addr = (caddr_t)(linux_args->addr + linux_args->len); X+ X+ if (bsd_args.addr > p->p_vmspace->vm_maxsaddr) { X+ /* Some linux apps will attempt to mmap X+ * thread stacks near the top of their X+ * address space. If their TOS is greater X+ * than vm_maxsaddr, vm_map_growstack() X+ * will confuse the thread stack with the X+ * process stack and deliver a SEGV if they X+ * attempt to grow the thread stack past their X+ * current stacksize rlimit. To avoid this, X+ * adjust vm_maxsaddr upwards to reflect X+ * the current stacksize rlimit rather X+ * than the maximum possible stacksize. X+ * It would be better to adjust the X+ * mmap'ed region, but some apps do not check X+ * mmap's return value. X+ */ X+ p->p_vmspace->vm_maxsaddr = (char *)USRSTACK - X+ p->p_rlimit[RLIMIT_STACK].rlim_cur; X+ } X+ X+ /* This gives us our maximum stack size */ X+ if (linux_args->len > STACK_SIZE - GUARD_SIZE) X+ bsd_args.len = linux_args->len; X+ else X+ bsd_args.len = STACK_SIZE - GUARD_SIZE; X+ X+ /* This gives us a new BOS. If we're using VM_STACK, then X+ * mmap will just map the top SGROWSIZ bytes, and let X+ * the stack grow down to the limit at BOS. If we're X+ * not using VM_STACK we map the full stack, since we X+ * don't have a way to autogrow it. X+ */ X+ bsd_args.addr -= bsd_args.len; X+ } else { X+ bsd_args.addr = (caddr_t)linux_args->addr; X+ bsd_args.len = linux_args->len; X+ } X+ X+ bsd_args.prot = linux_args->prot | PROT_READ; /* always required */ X+ if (linux_args->flags & LINUX_MAP_ANON) X+ bsd_args.fd = -1; X+ else X+ bsd_args.fd = linux_args->fd; X+ bsd_args.pos = ctob(linux_args->pgoff); X+ bsd_args.pad = 0; X+ X+#ifdef DEBUG X+ if (ldebug(mmap2)) X+ printf("-> (%p, %d, %d, 0x%08x, %d, %d)\n", X+ (void *)bsd_args.addr, bsd_args.len, bsd_args.prot, X+ bsd_args.flags, bsd_args.fd, (int)bsd_args.pos); X+#endif X+ X+ return (mmap(p, &bsd_args)); X+} X+ X+int X linux_mmap(struct proc *p, struct linux_mmap_args *args) X { X struct mmap_args /* { SHAR-EOF-MARKER-013eaf3882bdcd8e8dd36a2101827a2e echo x - ./sys/i386/linux/linux_sysvec.c.patch sed 's/^X//' >./sys/i386/linux/linux_sysvec.c.patch << 'SHAR-EOF-MARKER-5063296fed19fdb032d23975e4efcbfc' X--- linux_sysvec.c.orig X+++ linux_sysvec.c X@@ -722,6 +722,7 @@ X args[2] = tf->tf_edx; X args[3] = tf->tf_esi; X args[4] = tf->tf_edi; X+ args[5] = tf->tf_ebp; /* tf_ebp taken from linux glibc sources */ X *params = NULL; /* no copyin */ X } X SHAR-EOF-MARKER-5063296fed19fdb032d23975e4efcbfc exit --------------000007000808000004040709-- From owner-freebsd-emulation@FreeBSD.ORG Thu Feb 26 04:47:18 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6267A16A4CE for ; Thu, 26 Feb 2004 04:47:18 -0800 (PST) Received: from ahze.ahze.net (adsl-068-209-163-003.sip.clt.bellsouth.net [68.209.163.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2108743D1F for ; Thu, 26 Feb 2004 04:47:18 -0800 (PST) (envelope-from ahze@ahze.net) Received: from [192.168.1.5] (eamc.ahze.net [192.168.1.5]) by ahze.ahze.net (Postfix) with ESMTP id 6FD134BA; Thu, 26 Feb 2004 07:48:54 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mike Johnson Date: Thu, 26 Feb 2004 07:47:10 -0500 To: freebsd-emulation@FreeBSD.org X-Mailer: Apple Mail (2.613) cc: mike johnson Subject: emulators/rtc with other apps other than Linux apps? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 12:47:18 -0000 Hi, I got rtc working with mplayer and I am wondering if it would be worth using it instead of usleep? I'm not very familiar with how emulators/rtc works vs. linux rtc. Is the rtc port as fast and accurate as linux rtc? mplayer seems to run really well with 4.9 $ mplayer blah.mpeg MPlayer 0.92-2.95.4 (C) 2000-2003 MPlayer Team <-- SNIP --> Using Linux hardware RTC timing (1024Hz). I was unable to get rtc to work on 5.2-CURRENT not only with mplayer but with test.c also it said /dev/rtc was busy diff -ruN multimedia/mplayer.orig/Makefile multimedia/mplayer/Makefile --- multimedia/mplayer.orig/Makefile Thu Feb 26 04:18:00 2004 +++ multimedia/mplayer/Makefile Thu Feb 26 05:59:23 2004 @@ -52,6 +52,7 @@ # Further, the correct instruction set of your processor is normally # auto-detected, so there is probably no necissity to change them. # +# # WITHOUT_MMX # default: autodetected # disables using of mmx code @@ -74,6 +75,10 @@ # kernel config. This is standard for 5.x systems on I686_CPU and above. # 4.x users will have to define this explicitly. # +# WITH_RTC +# default: autodetected +# REAL TIME CLOCK support +# # # Feature options: # These options influence, which libraries mplayer is linked to. @@ -235,6 +240,10 @@ .include +.if exists(${LOCALBASE}/modules/rtc.ko) +WITH_RTC= yes +.endif + .if exists(${LOCALBASE}/lib/libartsc.so.0) WITH_ARTS= yes .endif @@ -331,6 +340,14 @@ PLIST_SUB+= GMPLAYER="@comment " .endif +.if defined(WITH_RTC) +BUILD_DEPENDS+= ${LOCALBASE}/modules/rtc.ko:${PORTSDIR}/emulators/rtc +RUN_DEPENDS+= ${LOCALBASE}/modules/rtc.ko:${PORTSDIR}/emulators/rtc +EXTRA_PATCHES= ${PATCHDIR}/rtc-configure-patch +CONFIGURE_ARGS+= --enable-rtc +CONFIGURE_ENV+= CFLAGS+="-I/${LOCALBASE}/include" +.endif + .if defined(WITH_GUI) USE_GNOME+= gtk12 RUN_DEPENDS+= ${LOCALBASE}/share/mplayer/Skin:${PORTSDIR}/multimedia/ mplayer-skins @@ -552,6 +569,21 @@ ${CONFIGURE_WRKSRC}/${CONFIGURE_SCRIPT} @${REINPLACE_CMD} -Ee 's#-pthread|-lc_r#${PTHREAD_LIBS}#g' \ ${WRKSRC}/configure +.if defined(WITH_RTC) + @${REINPLACE_CMD} -e \ + 's|||' \ + ${WRKSRC}/configure \ + ${WRKSRC}/mplayer.c + @${REINPLACE_CMD} -e \ + 's|RTC_IRQP_SET|RTCIO_IRQP_SET|' \ + ${WRKSRC}/mplayer.c + @${REINPLACE_CMD} -e \ + 's|RTC_PIE_ON|RTCIO_PIE_ON|' \ + ${WRKSRC}/mplayer.c + @${REINPLACE_CMD} -e \ + 's|rtc_fd|rtc|' \ + ${WRKSRC}/mplayer.c +.endif pre-configure: .if defined(WITH_LIBDVDREAD) diff -ruN multimedia/mplayer.orig/files/rtc-configure-patch multimedia/mplayer/files/rtc-configure-patch --- multimedia/mplayer.orig/files/rtc-configure-patch Wed Dec 31 19:00:00 1969 +++ multimedia/mplayer/files/rtc-configure-patch Thu Feb 26 05:37:03 2004 @@ -0,0 +1,11 @@ +--- configure.orig Thu Feb 26 04:13:03 2004 ++++ configure Thu Feb 26 04:12:22 2004 +@@ -3781,7 +3781,7 @@ + + + echocheck "RTC" +-if linux ; then ++if freebsd ; then + if test "$_rtc" = auto ; then + cat > $TMPC << EOF + #include From owner-freebsd-emulation@FreeBSD.ORG Thu Feb 26 07:00:07 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED41316A4CE for ; Thu, 26 Feb 2004 07:00:07 -0800 (PST) Received: from mailhub.sweetdreamsracing.biz (mailhub.sweetdreamsracing.biz [66.92.171.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id A78B343D1F for ; Thu, 26 Feb 2004 07:00:07 -0800 (PST) (envelope-from culverk@sweetdreamsracing.biz) Received: by mailhub.sweetdreamsracing.biz (Postfix, from userid 80) id 2C5112D7; Thu, 26 Feb 2004 10:08:40 -0500 (EST) Received: from 141.156.69.109 ([141.156.69.109]) by www.sweetdreamsracing.biz (Horde) with HTTP for ; Thu, 26 Feb 2004 10:08:39 -0500 Message-ID: <20040226100839.kw8c4cws80so4g0c@www.sweetdreamsracing.biz> Date: Thu, 26 Feb 2004 10:08:39 -0500 From: Kenneth Culver To: Reid Linnemann References: <1077756915.403d43f331556@webmail.okstate.edu> In-Reply-To: <1077756915.403d43f331556@webmail.okstate.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs cc: freebsd-emulation@freebsd.org Subject: Re: linux mmap2 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 15:00:08 -0000 Quoting Reid Linnemann : > Hey all, I've got a little dilemma I need some hints with... > > I am running FreeBSD 4.9-STABLE, and trying to get a linux binary operating > that uses mmap2. I've read a conversation kenneth culver had about > his efforts, > and from what I can tell mmap2 is implemented in -CURRENT - but not > in -STABLE. > Is there any way I can grab the -CURRENT version of the linuxulator, or > cut'n'paste the changes kenneth made, and get mmap2 working? I had found, and > later lost, kenneths record of changes he made to the linuxulator - if anyone > can point me to them I would appreciate that as well. > > thanks, > -Reid > The changes I made back then weren't that complicated, but I'm not sure they actually helped the software I was working on run or not. I found out later that software worked fine with or without mmap2, but worked slightly faster with it. I don't have a copy of the patches I made back then either. I might be able to get a copy of the 4.9 source and make a patch there without testing it if you're interested. If you have any knowledge of C, however, it wouldn't be that hard to duplicate the changes that were made in -CURRENT. Ken From owner-freebsd-emulation@FreeBSD.ORG Fri Feb 27 09:53:39 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8961416A4CF for ; Fri, 27 Feb 2004 09:53:39 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 066F643D39 for ; Fri, 27 Feb 2004 09:53:39 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 92317 invoked from network); 27 Feb 2004 17:53:37 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 27 Feb 2004 17:53:37 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 27 Feb 2004 11:53:36 -0600 (CST) From: Mike Silbersack To: Mike Johnson Message-ID: <20040227114628.N724@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: emulation@freebsd.org Subject: Re: emulators/rtc with other apps other than Linux apps? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 17:53:39 -0000 Hi Mike! (Hm, that sounds odd...) The rtc port could work fine with native FreeBSD programs, I have been running most of my tests with natively compiled test tools. If your kern.hz is high enough, then the rtc driver should provide the best accuracy possible. If the application uses rtc properly, then I believe that yes, it will perform better than using usleep. However, I have not had a chance to look at the mplayer source code to see if this is the case. Also, we do not implement the full set of features that linux's rtc driver has yet, so if mplayer is depending on those features it may not be working correctly. Finally, the rtc driver should work fine on 5.2 - that's the platform I'm developing it on! However, note that some driver changes happened in the last week, and that I have not updated the port to compensate yet, so if you're running a really recent -current that there may be some breakage. I'll give mplayer a shot when and if I get some time. Mike "Silby" Silbersack From owner-freebsd-emulation@FreeBSD.ORG Fri Feb 27 11:20:36 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D82916A4CE for ; Fri, 27 Feb 2004 11:20:36 -0800 (PST) Received: from ahze.ahze.net (adsl-068-209-163-003.sip.clt.bellsouth.net [68.209.163.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31F8343D39 for ; Fri, 27 Feb 2004 11:20:36 -0800 (PST) (envelope-from ahze@ahze.net) Received: from [192.168.1.5] (eamc.ahze.net [192.168.1.5]) by ahze.ahze.net (Postfix) with ESMTP id 6D67781; Fri, 27 Feb 2004 14:22:14 -0500 (EST) In-Reply-To: <20040227114628.N724@odysseus.silby.com> References: <20040227114628.N724@odysseus.silby.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <03A602EE-695A-11D8-B964-000A958C81C6@ahze.net> Content-Transfer-Encoding: 7bit From: Mike Johnson Date: Fri, 27 Feb 2004 14:20:33 -0500 To: Mike Silbersack X-Mailer: Apple Mail (2.613) cc: emulation@freebsd.org Subject: Re: emulators/rtc with other apps other than Linux apps? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 19:20:36 -0000 Hi Mike, Thanks for the reply. I am still having problems with RTC with FreeBSD 5. It's only been recently that this has happened, it happened after make world and new kernel on 2/25. I have rebuild and reinstalled RTC trying to get it to work thinking it was out of sync from my system. here is what I get when I try and access /dev/rtc <--SNIP--> ===> Registering installation for rtc-2004.02.24.1_1 gentoo:/usr/ports/emulators/rtc root$ uname -a FreeBSD gentoo.ahze.net 5.2-CURRENT FreeBSD 5.2-CURRENT #35: Fri Feb 27 13:57:48 EST 2004 ahze@gentoo.ahze.net:/usr/obj/usr/src/sys/Gentoo i386 gentoo:/usr/ports/emulators/rtc root$ kldstat | grep rtc gentoo:/usr/ports/emulators/rtc root$ /usr/local/etc/rc.d/rtc.sh start rtcgentoo:/usr/ports/emulators/rtc root$ cd files/ gentoo:/usr/ports/emulators/rtc/files root$ gcc test.c gentoo:/usr/ports/emulators/rtc/files root$ ./a.out /dec/rtc: Device not configured gentoo:/usr/ports/emulators/rtc/files root$ file /dev/rtc /dev/rtc: character special (202/0) gentoo:/usr/ports/emulators/rtc/files root$ dmesg | grep -i rtc WARNING: Device driver "rtc" has wrong version and is disabled. Recompile KLD module. WARNING: driver "rtc" used unreserved major device number 202 Thanks, Mike Johnson From owner-freebsd-emulation@FreeBSD.ORG Fri Feb 27 11:32:18 2004 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAFD916A4CE for ; Fri, 27 Feb 2004 11:32:18 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 55D8943D31 for ; Fri, 27 Feb 2004 11:32:18 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 58928 invoked from network); 27 Feb 2004 19:32:17 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 27 Feb 2004 19:32:17 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 27 Feb 2004 13:32:16 -0600 (CST) From: Mike Silbersack To: Mike Johnson In-Reply-To: <03A602EE-695A-11D8-B964-000A958C81C6@ahze.net> Message-ID: <20040227133056.K4260@odysseus.silby.com> References: <20040227114628.N724@odysseus.silby.com> <03A602EE-695A-11D8-B964-000A958C81C6@ahze.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: emulation@freebsd.org Subject: Re: emulators/rtc with other apps other than Linux apps? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 19:32:19 -0000 On Fri, 27 Feb 2004, Mike Johnson wrote: > Hi Mike, > Thanks for the reply. I am still having problems with RTC with FreeBSD > 5. It's only been recently that this has happened, it happened after > make world and new kernel on 2/25. I have rebuild and reinstalled RTC > trying to get it to work thinking it was out of sync from my system. > > here is what I get when I try and access /dev/rtc > > WARNING: Device driver "rtc" has wrong version and is disabled. > Recompile KLD module. Yep, that's the change in -current which I haven't updated rtc to take into account yet. It should be as simple as adding .d_version = D_VERSION in the dev struct, but I haven't tried it myself yet. I will do so soon. Mike "Silby" Silbersack