From owner-freebsd-emulation Sun Jul 6 18:55:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA17330 for emulation-outgoing; Sun, 6 Jul 1997 18:55:31 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA17325 for ; Sun, 6 Jul 1997 18:55:26 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA26762; Mon, 7 Jul 1997 11:25:10 +0930 (CST) From: Michael Smith Message-Id: <199707070155.LAA26762@genesis.atrad.adelaide.edu.au> Subject: Re: Newer LINUX emulation mods? In-Reply-To: from "Alex.Boisvert" at "Jul 5, 97 09:48:41 am" To: boia01@pollux.GEL.USherb.CA (Alex.Boisvert) Date: Mon, 7 Jul 1997 11:25:09 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, timp@orion.ab.ca, freebsd-emulation@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alex.Boisvert stands accused of saying: > > Sorry to break in your conversation but I can describe a problem I see > with JDK 1.1.1 (Linux v3). > > When I run some applications (ie. demo apps provided by SUN in JDK > 1.1.1), I can "freeze" most of the demos by resizing (a few times) the > window they're in. It sometimes happens by moving the window as well. Aha. And what are the apps and the interpreter doing when they freeze? What's the 'wchan' field in the output of 'ps axlwww' say when they're frozen? How about a ktrace/kdump dissection of the freeze point? > In some rare occasions, I have been able to "freeze" my window manager > (fvwm95 or twm). Locking a window manager up isn't hard if the app loses its marbles; fvwm derivatives are very good at this. > Alex. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-emulation Mon Jul 7 06:59:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA13796 for emulation-outgoing; Mon, 7 Jul 1997 06:59:56 -0700 (PDT) Received: from fang.cs.sunyit.edu (umji@fang.cs.sunyit.edu [192.52.220.66]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA13791 for ; Mon, 7 Jul 1997 06:59:53 -0700 (PDT) Received: from localhost (umji@localhost) by fang.cs.sunyit.edu (8.7.6/8.7.3) with SMTP id JAA19290 for ; Mon, 7 Jul 1997 09:59:52 -0400 (EDT) Date: Mon, 7 Jul 1997 09:59:52 -0400 (EDT) From: Michael Imor To: freebsd-emulation@freebsd.org Subject: subscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk subscribe From owner-freebsd-emulation Wed Jul 9 06:08:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA13770 for emulation-outgoing; Wed, 9 Jul 1997 06:08:51 -0700 (PDT) Received: from jerrys.rogerswave.ca (jerrys@jerrys.rogerswave.ca [204.92.25.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA13763 for ; Wed, 9 Jul 1997 06:08:46 -0700 (PDT) Received: (from jerrys@localhost) by jerrys.rogerswave.ca (8.8.5/8.8.5) id GAA00244; Wed, 9 Jul 1997 06:10:29 -0700 (PDT) Date: Wed, 9 Jul 1997 06:10:29 -0700 (PDT) Message-Id: <199707091310.GAA00244@jerrys.rogerswave.ca> To: emulation@freebsd.org X-URL: http://www.freebsd.org/FAQ/FAQ95.html X-Mailer: Lynx, Version 2.7 X-Personal_name: Jerry Sturge From: jerrys@vcn.bc.ca Subject: emulation list Sender: owner-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Please add me to your emulation email list. I am interested in some sort of dos emulator for freebsd. I am not running X so pcemu is out of the questions. Does anyone have any suggestions. Sincerely J Sturge From owner-freebsd-emulation Wed Jul 9 07:23:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA16578 for emulation-outgoing; Wed, 9 Jul 1997 07:23:55 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA16567 for ; Wed, 9 Jul 1997 07:23:44 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id XAA13670; Wed, 9 Jul 1997 23:53:29 +0930 (CST) From: Michael Smith Message-Id: <199707091423.XAA13670@genesis.atrad.adelaide.edu.au> Subject: Re: emulation list In-Reply-To: <199707091310.GAA00244@jerrys.rogerswave.ca> from "jerrys@vcn.bc.ca" at "Jul 9, 97 06:10:29 am" To: jerrys@vcn.bc.ca Date: Wed, 9 Jul 1997 23:53:28 +0930 (CST) Cc: emulation@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk jerrys@vcn.bc.ca stands accused of saying: > Please add me to your emulation email list. I am interested > in some sort of dos emulator for freebsd. I am not running > X so pcemu is out of the questions. > Does anyone have any suggestions. > > Sincerely Have a look at the 'no X' build option for pcemu1.93pre (ftp://gsoft.com.au/pub/pcemu/pcemu1.93pre.tar.gz). I got sidetracked before this was fully cleaned up for release, but it does quite a respectable job on a terminal. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-emulation Fri Jul 11 16:45:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA09762 for emulation-outgoing; Fri, 11 Jul 1997 16:45:00 -0700 (PDT) Received: from pahtoh.cwu.edu (root@pahtoh.cwu.edu [198.104.65.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA09757 for ; Fri, 11 Jul 1997 16:44:57 -0700 (PDT) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by pahtoh.cwu.edu (8.8.5/8.8.5) with ESMTP id QAA27171 for ; Fri, 11 Jul 1997 16:44:57 -0700 (PDT) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.6/8.8.5) with SMTP id QAA23567 for ; Fri, 11 Jul 1997 16:44:56 -0700 (PDT) Date: Fri, 11 Jul 1997 16:44:56 -0700 (PDT) From: Chris Timmons Reply-To: Chris Timmons To: freebsd-emulation@freebsd.org Subject: Linux StreamWorks player; diagnostic output suggestion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While running down an emulation problem with the Linux/Elf StreamWorks Audio player, I've done some thinking about the way in which our diagnostic output for unimplemented ioctls is formatted by linux_ioctl.c in the linux emulator source. Please comment on what I've got below; if no-one strenuously objects I will send-pr it as a patch. The problem with StreamWorks Audio Player is that it wants to use ioctl commands not present in our VoxWare 3.0 sound driver system. The calls in question are available in the VoxWare v3.5-alpha5 driver which I am running on my 2.2-STABLE system courtesy work done by Amancio Hasty and Brian Litzinger (and probably others whom I am unaware of but thank nonetheless.) I am going to ask around on the -multimedia list if I can be of help integrating VoxWare v3.5-alpha5 into -current so that I can then prepare and submit the appropriate emulation mappings in linux_ioctl.c. linux_ioctl.c DIAGNOSTIC OUTPUT ------------------------------- I think the goal of the diagnostic output should be to give the end user something meaningful to put into a send-pr. Here is what I was seeing from the StreamWorks player.: LINUX: 'ioctl' fd=8, typ=0xc50(P), num=0x12 not implemented This contains good information, but to run this down you really have to use ktrace and have an understanding of linux ioctl encoding to get enough information to be able to start digging in the linux sources. You can't tell the mode of the request, only get a nibble of the parameter size, and aren't left with something that resembles an ioctl definition. I've modified the uprintf call to do a little bit more formatting, so that the output is now formatted like this: LINUX: unimplemented ioctl: fd=8, cmd=0x800c5012 (IOR, 'P', 18, 12) We now see the full command word, the mode and also the size parameter presented in more or less the way it would appear in the source which defines the ioctl itself. See the comment in my code about non-printing characters. In evaluating this change I would say that a drawback is more execution time if you're caught in a tight loop featuring an unimplemented ioctl, and also a more complex printf featuring the cryptic conditional operator. In the case of the former, probably the extra overhead is negligible, particularly because if you're executing it at all you have bigger problems :) I respect the fact that comments in the code are sparse because the code is self documenting. Would this comment be inappropriate? Presumably someone like I will have another emulation problem someday and come looking for clues - this will save time downloading the linux kernel sources, at least :) Proposed code snippet for the 'unimplemented ioctl' section of linux_ioctl.c: /* * Linux i386 IOCTL commands are 32 bits total, and at the source * level are encoded with the familiar _IO, _IOR, _IOW, and _IOWR * macros. The Linux binary encoding of the upper 16 bits differs * from that used by FreeBSD as follows: Like FreeBSD the lower 16 * bits contain the command while the higher 16 bits store the mode * and size of any parameter structures. FreeBSD's encoding scheme * is found in . * * In Linux binary encoding, the highest two bits of the most * significant 16 correspond to mode: * * 00 _IO (no parameters) * 01 _IOW (copy in parameters) * 10 _IOR (copy out parameters) * 11 _IOWR (copy in/copy out parameters) * * The remaining 14 bits of this word store the size of any * parameter structures. * * Many of the IOCTL codes found in the upper 8 bits of the lower 16 * conveniently correspond to ascii characters and are actually * represented that way by convention in source code. We print them * that way below, but there are codes that map to non-printing * characters. * Printing undefined characters in diagnostic output isn't a very nice * thing to do, but the alternative is either to omit entirely or be * much more complex than is appropriate. The non-printing codes can * still be seen in the cmd= output that shows all 32 bits. * */ uprintf("LINUX: unimplemented ioctl: fd=%d, cmd=0x%lx (%s, '%c', %lu, %lu)\n", args->fd, args->cmd, (args->cmd&0xc0000000) ? (args->cmd&0xc0000000) == 0x80000000 ? "IOR" : (args->cmd&0xc0000000) == 0x40000000 ? "IOW" : "IOWR" : "IO", /* ick - risk printing the unprintable */ (char)((args->cmd&0x0000ff00)>>8), args->cmd&0xff, (args->cmd&0x3fff0000) >> 16); return EINVAL; }