From rdivacky at freebsd.org Thu May 1 08:14:06 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu May 1 08:14:09 2008 Subject: [PATCH]: robust futexes In-Reply-To: <20080430121513.33f9452b@kan.dnsalias.net> References: <20080430081806.GA81772@freebsd.org> <20080430121513.33f9452b@kan.dnsalias.net> Message-ID: <20080501081334.GA54624@freebsd.org> On Wed, Apr 30, 2008 at 12:15:13PM -0400, Alexander Kabaev wrote: > On Wed, 30 Apr 2008 10:18:06 +0200 > Roman Divacky wrote: > > > hi > > > > I implemented robust futexes in linuxulator and I need to get it > > reviewed/tested. The best way to test it is (according to linux > > documnetation) to run yum and kill -9 it while it runs. > > > > The patch is here: > > http://www.vlakno.cz/~rdivacky/linux_robust_futex.patch > > > > the patch should be ok as I followed linux code very closely (most of > > the code runs in userspace so kernel has very well defined work). I > > tested it lightly on i386. > > > > I'd like to commit this quite soon so please help. > > > > thnx! > > > > roman > Hi, > > some comments: > > linux_emul.c: > > @@ -86,6 +86,7 @@ > em = malloc(sizeof *em, M_LINUX, M_WAITOK | M_ZERO); > em->pid = child; > em->pdeath_signal = 0; > + em->robust_futexes = NULL; > > M_ZERO is not quite zero enough? :) I prefer it to be initialized so people can see immediately that its '0/NULL' dont think it matters much :) if this penalizes fork() by more than 10% I'll remove that :-D > linux_futex.c in release_futexes: > > + head = em->robust_futexes; > + > + if (fetch_robust_entry(&entry, &head->list.next, &pi)) > + return; > > Aren't you taking a fault in copyin unconditionally if > em->robust_mutexes happens to be NULL? Why not check is for NULL first? I think it can be done this way and it makes sense... I wonder why linux does not check it, they usually optimize everything... > Also, is sched_relinguish really necessary after each each futex > recovery _except_ from the 'pending' futex one? linux calls cond_resched() in this place and I believe there's a reason for this. I dont know much what the userspace part is doing but I believe it makes sense to reschedule after each futex recovery so other threads can "do stuff". anyway.. this is what linux does and I believe we should stick to it. Do you have any particular reason why you mind this? > i386/conf/GENERIC: > > Does not belong in this patch, probably included in by mistake. yes.. this is included by mistake.. thnx a lot for the review! an updated patch can be found at: www.vlakno.cz/~rdivacky/linux_robust_futex.2.patch roman From rdivacky at freebsd.org Thu May 1 08:18:51 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu May 1 08:18:54 2008 Subject: Linux compat ioctl return values In-Reply-To: <481897AB.7070003@thedarkside.nl> References: <481897AB.7070003@thedarkside.nl> Message-ID: <20080501081811.GB54624@freebsd.org> On Wed, Apr 30, 2008 at 06:00:43PM +0200, Pieter de Boer wrote: > Hi, > > I've been working on a kernel driver that creates a device. This device > in turn is opened and ioctl'd from a Linux executable. I've registered a > handler for these ioctl's and my ioctl handler is succesfully executed. > > My ioctl-handler returns a large positive value, but the userland > application retrieves the value 1, EPERM. If I return 42, the userland > application retrieves 42, but 260 is retrieved as 1. It appears there's a > threshold somewhere above which the return value is set to 1, but I > haven't been able to find out where in the code this is done. The Linux > executable actually expects the value I return, and doesn't work when > EPERM is found instead. > > So, the question is: does anyone know where such a threshold may > reside and how to work around it? this is done in (for i386) sys/i386/i386/trap.c around line 1050. in short, we define in the sysvec structure sv_errtbl and if returned error > the size of the table we just return -1. error table for linux is roughly to 70. thats why you are getting -1 (1 after translation) you might extend the errno table (i386/linux/linux_sysvec.c for i386, line 126) if you provide (tested!) patch for i386/amd64, I am sure it will get commited roman From pieter at thedarkside.nl Thu May 1 09:57:44 2008 From: pieter at thedarkside.nl (Pieter de Boer) Date: Thu May 1 09:57:47 2008 Subject: Linux compat ioctl return values In-Reply-To: <20080501081811.GB54624@freebsd.org> References: <481897AB.7070003@thedarkside.nl> <20080501081811.GB54624@freebsd.org> Message-ID: <48199416.5000407@thedarkside.nl> Roman Divacky wrote: >> I've been working on a kernel driver that creates a device. This device >> in turn is opened and ioctl'd from a Linux executable. I've registered a >> handler for these ioctl's and my ioctl handler is succesfully executed. >> >> My ioctl-handler returns a large positive value, but the userland >> application retrieves the value 1, EPERM. If I return 42, the userland >> application retrieves 42, but 260 is retrieved as 1. It appears there's a >> threshold somewhere above which the return value is set to 1, but I >> haven't been able to find out where in the code this is done. The Linux >> executable actually expects the value I return, and doesn't work when >> EPERM is found instead. >> >> So, the question is: does anyone know where such a threshold may >> reside and how to work around it? > > this is done in (for i386) sys/i386/i386/trap.c around line 1050. > > in short, we define in the sysvec structure sv_errtbl and if returned > error > the size of the table we just return -1. error table for > linux is roughly to 70. thats why you are getting -1 (1 after translation) > > you might extend the errno table (i386/linux/linux_sysvec.c for i386, line 126) The issue appears to be a bit more involved. It seems that in Linux, when the ioctl() syscall returns a negative value 'error', 'errno' is set to '-error' and the return value of the ioctl() library call is -1. All positive values are simply passed through: when the ioctl() syscall returns 35235, the ioctl() library call also returns 35235. This seems to be a difference in semantics between FreeBSD and Linux; FreeBSD is a bit more conservative. As the trap code in sys/i386/i386/trap.c is used for both FreeBSD and Linux executables, I wonder how to differentiate between both in trap.c. To see if I can at least make my Linux executable work for now, I'm going to test the following patch (to trap.c): - error = -1; /* XXX */ + /* Do nothing */ I suppose a patch that differentiates between Linux and FreeBSD syscalls is needed here, but how this could be done, dunno. -- Pieter From rdivacky at freebsd.org Thu May 1 10:03:01 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu May 1 10:03:03 2008 Subject: Linux compat ioctl return values In-Reply-To: <48199416.5000407@thedarkside.nl> References: <481897AB.7070003@thedarkside.nl> <20080501081811.GB54624@freebsd.org> <48199416.5000407@thedarkside.nl> Message-ID: <20080501100229.GA60391@freebsd.org> On Thu, May 01, 2008 at 11:57:42AM +0200, Pieter de Boer wrote: > Roman Divacky wrote: > > >>I've been working on a kernel driver that creates a device. This device > >>in turn is opened and ioctl'd from a Linux executable. I've registered a > >>handler for these ioctl's and my ioctl handler is succesfully executed. > >> > >>My ioctl-handler returns a large positive value, but the userland > >>application retrieves the value 1, EPERM. If I return 42, the userland > >>application retrieves 42, but 260 is retrieved as 1. It appears there's a > >>threshold somewhere above which the return value is set to 1, but I > >>haven't been able to find out where in the code this is done. The Linux > >>executable actually expects the value I return, and doesn't work when > >>EPERM is found instead. > >> > >>So, the question is: does anyone know where such a threshold may > >>reside and how to work around it? > > > >this is done in (for i386) sys/i386/i386/trap.c around line 1050. > > > >in short, we define in the sysvec structure sv_errtbl and if returned > >error > the size of the table we just return -1. error table for > >linux is roughly to 70. thats why you are getting -1 (1 after translation) > > > >you might extend the errno table (i386/linux/linux_sysvec.c for i386, line > >126) > > The issue appears to be a bit more involved. It seems that in Linux, > when the ioctl() syscall returns a negative value 'error', 'errno' is > set to '-error' and the return value of the ioctl() library call is -1. > All positive values are simply passed through: when the ioctl() syscall > returns 35235, the ioctl() library call also returns 35235. > > This seems to be a difference in semantics between FreeBSD and Linux; > FreeBSD is a bit more conservative. As the trap code in > sys/i386/i386/trap.c is used for both FreeBSD and Linux executables, I > wonder how to differentiate between both in trap.c. > > To see if I can at least make my Linux executable work for now, I'm > going to test the following patch (to trap.c): > - error = -1; /* XXX */ > + /* Do nothing */ > > I suppose a patch that differentiates between Linux and FreeBSD syscalls > is needed here, but how this could be done, dunno. I dont think so.... native freebsd does NOT have errno translation table. you patch makes sense I'd say From nox at jelal.kn-bremen.de Thu May 1 10:54:22 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu May 1 10:54:25 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080429222458.GA20855@saturn.kn-bremen.de> References: <20080429222458.GA20855@saturn.kn-bremen.de> Message-ID: <20080501101951.GA30274@saturn.kn-bremen.de> On Wed, Apr 30, 2008 at 12:24:58AM +0200, Juergen Lock wrote: > Yeah, the amd64 kernel reuses the same gdt to setup all cpus, causing > kqemu to end up restoring the interrupt stackpointer (after running > guest code using its own cpu state) from the tss of the last cpu, > regardless which cpu it happened to run on. And that then causes the last > cpu's (usually) idle thread's stack to get smashed and the host doing > multiple panics... (Which also explains why pinning qemu onto cpu 1 > worked on a 2-way host.) > Hmm maybe the following is a little more clear: kqemu sets up its own cpu state and has to save and restore the original state because of that, so among other things it does an str insn (store task register), and later an ltr insn (load task register) using the value it got from the first str insn. That ltr insn loads the selector for the tss which is stored in the gdt, and that entry in the gdt is different for each cpu, but since a single gdt was reused to setup the cpus at boot (in init_secondary() in /sys/amd64/amd64/mp_machdep.c), it still points to the tss for the last cpu, instead of to the right one for the cpu the ltr insn gets executed on. That is what the kqemu_tss_workaround() in the patch `fixes'... > Here's the patch I just tested, of course you'd want to disable this > once the gdt is no longer shared, so assuming someone wants to fix this, > please also do an OSVERSION bump... The patch applied with offsets (I still had debug code in when I made it), here is a rebased version: Index: kqemu-freebsd.c @@ -33,6 +33,11 @@ #include #include +#ifdef __x86_64__ +#include +#include +#include +#endif #include "kqemu-kernel.h" @@ -234,6 +239,19 @@ va_end(ap); } +#ifdef __x86_64__ +/* called with interrupts disabled */ +void CDECL kqemu_tss_workaround(void) +{ + int gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); + + gdt_segs[GPROC0_SEL].ssd_base = (long) &common_tss[PCPU_GET(cpuid)]; + ssdtosyssd(&gdt_segs[GPROC0_SEL], + (struct system_segment_descriptor *)&gdt[GPROC0_SEL]); + ltr(gsel_tss); +} +#endif + struct kqemu_instance { #if __FreeBSD_version >= 500000 TAILQ_ENTRY(kqemu_instance) kqemu_ent; Index: common/kernel.c @@ -1025,6 +1025,9 @@ #ifdef __x86_64__ uint16_t saved_ds, saved_es; unsigned long fs_base, gs_base; +#ifdef __FreeBSD__ + struct kqemu_global_state *g = s->global_state; +#endif #endif #ifdef PROFILE @@ -1188,6 +1191,13 @@ apic_restore_nmi(s, apic_nmi_mask); } profile_record(s); +#ifdef __FreeBSD__ +#ifdef __x86_64__ + spin_lock(&g->lock); + kqemu_tss_workaround(); + spin_unlock(&g->lock); +#endif +#endif if (s->mon_req == MON_REQ_IRQ) { struct kqemu_exception_regs *r; Index: kqemu-kernel.h @@ -44,4 +44,10 @@ void CDECL kqemu_log(const char *fmt, ...); +#ifdef __FreeBSD__ +#ifdef __x86_64__ +void CDECL kqemu_tss_workaround(void); +#endif +#endif + #endif /* KQEMU_KERNEL_H */ From jhb at freebsd.org Thu May 1 14:55:55 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu May 1 14:55:59 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080501101951.GA30274@saturn.kn-bremen.de> References: <20080429222458.GA20855@saturn.kn-bremen.de> <20080501101951.GA30274@saturn.kn-bremen.de> Message-ID: <200805011011.06951.jhb@freebsd.org> On Thursday 01 May 2008 06:19:51 am Juergen Lock wrote: > On Wed, Apr 30, 2008 at 12:24:58AM +0200, Juergen Lock wrote: > > Yeah, the amd64 kernel reuses the same gdt to setup all cpus, causing > > kqemu to end up restoring the interrupt stackpointer (after running > > guest code using its own cpu state) from the tss of the last cpu, > > regardless which cpu it happened to run on. And that then causes the > > last cpu's (usually) idle thread's stack to get smashed and the host > > doing multiple panics... (Which also explains why pinning qemu onto cpu > > 1 worked on a 2-way host.) > > Hmm maybe the following is a little more clear: kqemu sets up its own > cpu state and has to save and restore the original state because of that, > so among other things it does an str insn (store task register), and later > an ltr insn (load task register) using the value it got from the first > str insn. That ltr insn loads the selector for the tss which is stored > in the gdt, and that entry in the gdt is different for each cpu, but since > a single gdt was reused to setup the cpus at boot (in init_secondary() in > /sys/amd64/amd64/mp_machdep.c), it still points to the tss for the last > cpu, instead of to the right one for the cpu the ltr insn gets executed on. > That is what the kqemu_tss_workaround() in the patch `fixes'... Perhaps kqemu shouldn't be doing str/ltr on amd64 instead? The things i386 uses a separate tss for in the kernel (separate stack for double faults) is handled differently on amd64 (on amd64 we make the double fault handler use one of the IST stacks). > > Here's the patch I just tested, of course you'd want to disable this > > once the gdt is no longer shared, so assuming someone wants to fix this, > > please also do an OSVERSION bump... > > The patch applied with offsets (I still had debug code in when I made it), > here is a rebased version: > > Index: kqemu-freebsd.c > @@ -33,6 +33,11 @@ > > #include > #include > +#ifdef __x86_64__ > +#include > +#include > +#include > +#endif > > #include "kqemu-kernel.h" > > @@ -234,6 +239,19 @@ > va_end(ap); > } > > +#ifdef __x86_64__ > +/* called with interrupts disabled */ > +void CDECL kqemu_tss_workaround(void) > +{ > + int gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); > + > + gdt_segs[GPROC0_SEL].ssd_base = (long) &common_tss[PCPU_GET(cpuid)]; > + ssdtosyssd(&gdt_segs[GPROC0_SEL], > + (struct system_segment_descriptor *)&gdt[GPROC0_SEL]); > + ltr(gsel_tss); > +} > +#endif > + > struct kqemu_instance { > #if __FreeBSD_version >= 500000 > TAILQ_ENTRY(kqemu_instance) kqemu_ent; > Index: common/kernel.c > @@ -1025,6 +1025,9 @@ > #ifdef __x86_64__ > uint16_t saved_ds, saved_es; > unsigned long fs_base, gs_base; > +#ifdef __FreeBSD__ > + struct kqemu_global_state *g = s->global_state; > +#endif > #endif > > #ifdef PROFILE > @@ -1188,6 +1191,13 @@ > apic_restore_nmi(s, apic_nmi_mask); > } > profile_record(s); > +#ifdef __FreeBSD__ > +#ifdef __x86_64__ > + spin_lock(&g->lock); > + kqemu_tss_workaround(); > + spin_unlock(&g->lock); > +#endif > +#endif > > if (s->mon_req == MON_REQ_IRQ) { > struct kqemu_exception_regs *r; > Index: kqemu-kernel.h > @@ -44,4 +44,10 @@ > > void CDECL kqemu_log(const char *fmt, ...); > > +#ifdef __FreeBSD__ > +#ifdef __x86_64__ > +void CDECL kqemu_tss_workaround(void); > +#endif > +#endif > + > #endif /* KQEMU_KERNEL_H */ > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" -- John Baldwin From nox at jelal.kn-bremen.de Thu May 1 15:57:47 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu May 1 15:57:55 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <200805011011.06951.jhb@freebsd.org> References: <20080429222458.GA20855@saturn.kn-bremen.de> <20080501101951.GA30274@saturn.kn-bremen.de> <200805011011.06951.jhb@freebsd.org> Message-ID: <20080501155304.GB2940@saturn.kn-bremen.de> On Thu, May 01, 2008 at 10:11:06AM -0400, John Baldwin wrote: > On Thursday 01 May 2008 06:19:51 am Juergen Lock wrote: > > On Wed, Apr 30, 2008 at 12:24:58AM +0200, Juergen Lock wrote: > > > Yeah, the amd64 kernel reuses the same gdt to setup all cpus, causing > > > kqemu to end up restoring the interrupt stackpointer (after running > > > guest code using its own cpu state) from the tss of the last cpu, > > > regardless which cpu it happened to run on. And that then causes the > > > last cpu's (usually) idle thread's stack to get smashed and the host > > > doing multiple panics... (Which also explains why pinning qemu onto cpu > > > 1 worked on a 2-way host.) > > > > Hmm maybe the following is a little more clear: kqemu sets up its own > > cpu state and has to save and restore the original state because of that, > > so among other things it does an str insn (store task register), and later > > an ltr insn (load task register) using the value it got from the first > > str insn. That ltr insn loads the selector for the tss which is stored > > in the gdt, and that entry in the gdt is different for each cpu, but since > > a single gdt was reused to setup the cpus at boot (in init_secondary() in > > /sys/amd64/amd64/mp_machdep.c), it still points to the tss for the last > > cpu, instead of to the right one for the cpu the ltr insn gets executed on. > > That is what the kqemu_tss_workaround() in the patch `fixes'... > > Perhaps kqemu shouldn't be doing str/ltr on amd64 instead? The things i386 > uses a separate tss for in the kernel (separate stack for double faults) is > handled differently on amd64 (on amd64 we make the double fault handler use > one of the IST stacks). Well, kqemu uses its own gdt, tss and everything while running guest code in its monitor, so it kinda has to do the str/ltr.s to setup its stuff, run guest code, and then restore the original state of things. (And `restore original state of things' is what failed here.) Oh and also the tss does seem to be used for the interrupt stack on amd64 too, at least thats the one that ended up wrong and caused the panics I saw... Juergen From jhb at freebsd.org Thu May 1 18:52:24 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu May 1 18:52:32 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080501155304.GB2940@saturn.kn-bremen.de> References: <20080429222458.GA20855@saturn.kn-bremen.de> <200805011011.06951.jhb@freebsd.org> <20080501155304.GB2940@saturn.kn-bremen.de> Message-ID: <200805011335.06415.jhb@freebsd.org> On Thursday 01 May 2008 11:53:04 am Juergen Lock wrote: > On Thu, May 01, 2008 at 10:11:06AM -0400, John Baldwin wrote: > > On Thursday 01 May 2008 06:19:51 am Juergen Lock wrote: > > > On Wed, Apr 30, 2008 at 12:24:58AM +0200, Juergen Lock wrote: > > > > Yeah, the amd64 kernel reuses the same gdt to setup all cpus, causing > > > > kqemu to end up restoring the interrupt stackpointer (after running > > > > guest code using its own cpu state) from the tss of the last cpu, > > > > regardless which cpu it happened to run on. And that then causes the > > > > last cpu's (usually) idle thread's stack to get smashed and the host > > > > doing multiple panics... (Which also explains why pinning qemu onto cpu > > > > 1 worked on a 2-way host.) > > > > > > Hmm maybe the following is a little more clear: kqemu sets up its own > > > cpu state and has to save and restore the original state because of that, > > > so among other things it does an str insn (store task register), and later > > > an ltr insn (load task register) using the value it got from the first > > > str insn. That ltr insn loads the selector for the tss which is stored > > > in the gdt, and that entry in the gdt is different for each cpu, but since > > > a single gdt was reused to setup the cpus at boot (in init_secondary() in > > > /sys/amd64/amd64/mp_machdep.c), it still points to the tss for the last > > > cpu, instead of to the right one for the cpu the ltr insn gets executed on. > > > That is what the kqemu_tss_workaround() in the patch `fixes'... > > > > Perhaps kqemu shouldn't be doing str/ltr on amd64 instead? The things i386 > > uses a separate tss for in the kernel (separate stack for double faults) is > > handled differently on amd64 (on amd64 we make the double fault handler use > > one of the IST stacks). > > Well, kqemu uses its own gdt, tss and everything while running guest code > in its monitor, so it kinda has to do the str/ltr.s to setup its stuff, run > guest code, and then restore the original state of things. (And `restore > original state of things' is what failed here.) > > Oh and also the tss does seem to be used for the interrupt stack on > amd64 too, at least thats the one that ended up wrong and caused the panics > I saw... The single TSS holds the IST pointers. On i386 we use a separate TSS for double faults, but on amd64 a double fault uses the same TSS but uses the IST pointers from that same TSS. The TSS also holds the ring stack pointer for when syscalls, interrupts, and traps from userland cross from ring 3 to ring 0 which is probably why you got a panic. Because of the fact that amd64 in normal operation never changes the task register (and that the gdt isn't used quite the same either, all the per-cpu stuff is via FSBASE and GSBASE) I don't expect the kernel to change to use a per-cpu gdt or the like. I think you will need to use the current approach of patching kqemu to fixup the tss/gdt when reloading the task register. You might want to make it a regular part of the code rather than a workaround as a result. -- John Baldwin From brix at FreeBSD.org Thu May 1 21:58:20 2008 From: brix at FreeBSD.org (Henrik Brix Andersen) Date: Thu May 1 21:58:28 2008 Subject: CrossOver Games port for PC-BSD / FreeBSD In-Reply-To: <48089FAC.5090306@pcbsd.com> References: <48089FAC.5090306@pcbsd.com> Message-ID: <20080501213957.GA24543@tirith.brixandersen.dk> On Fri, Apr 18, 2008 at 09:18:36AM -0400, Kris Moore wrote: > I've been working with Jeremy White over at CodeWeavers, and he has now > gone ahead and created an unsupported build of CrossOver Games for PC / > FreeBSD. Great news - thanks for working on this :) > Also, before anybody asks, yes you can run the > install-crossover-pcbsdgames*.sh installer on vanilla FreeBSD. Since PC-BSD > isn't a fork, the only thing you need to ensure, is that if you are on > FreeBSD 6.3, you must apply the Wine patch at http://wiki.freebsd.org/Wine. > Users on FreeBSD 7.0 or higher do not need this patch applied. The 'install-crossover-pcbsdgames-7.0.0.sh' package is compiled for FreeBSD 6, it seems. Do you know if there are any plans for a 7.x compatible build? Brix -- Henrik Brix Andersen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 217 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080501/3388b8e4/attachment.pgp From chagin.dmitry at gmail.com Fri May 2 21:35:47 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Fri May 2 21:35:51 2008 Subject: [RFC]: a place for [f]truncate64 In-Reply-To: <20080423114242.GY18958@deviant.kiev.zoral.com.ua> References: <20080423112543.GA20954@freebsd.org> <20080423114242.GY18958@deviant.kiev.zoral.com.ua> Message-ID: On Wed, 23 Apr 2008, Kostik Belousov wrote: > On Wed, Apr 23, 2008 at 01:25:43PM +0200, Roman Divacky wrote: >> hi, >> >> Linux defines two syscalls ftruncate64 and truncate64 that are >> defined only on 32bit archs, currently Linuxulator implementes >> ftruncate64 which is defined in linux[32]_machdep.c, ie. in >> machine dependant file. >> >> I plan to commit truncate64 but I prefer it to be placed in >> linux_file.c which is machine independent. Kostik and I had >> a discussion about this yesterday and we didnt agree what >> is the best place for these functions. >> It's better to have some the duplicated lines of a code in linux[32]_machdep.c, rather than dust (aka more lines of #ifdef XX32x64) in machine independant code. On an example linux_fcntl64 defined only for 32bit archs, but look at realization of linux_fcntl. The variable of type linux_fcntl64_args is used, which in 64bit world will be undefined. >> I think it's better to have it in linux_file.c because the >> only problem that can arise is that on platforms that don't >> use these syscalls there will be unused function in linux_file.c >> Kostik prefers each linux[32]_machdep.c to have it's own copy. >> >> So I ask emulation@ what should be done, do we want this in linux_file.c >> or linux[32]_machdep.c > > It is wrong to limit the discussion to not quite interesting case of the > truncate64. There is a lot more duplication, see the linux{,32}_machdep.c. > > I would prefer to have some definite word on the reason for this. > I think that that there was no mess in the further, it's necessary to transfer a machine dependent code according to definition. thnx! -- Have fun! chd From nox at jelal.kn-bremen.de Sat May 3 13:13:41 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sat May 3 13:13:48 2008 Subject: astro/google-earth updated, working again on 6... Message-ID: <20080503130356.GA37108@saturn.kn-bremen.de> Hi! For those that don't see commit messages, the google-earth distfile was updated again and I just committed an update to the port. And it works again on 6, at least for me! :) enjoy, Juergen From nox at jelal.kn-bremen.de Sat May 3 13:13:41 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sat May 3 13:13:48 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <200805011335.06415.jhb@freebsd.org> References: <20080429222458.GA20855@saturn.kn-bremen.de> <200805011011.06951.jhb@freebsd.org> <20080501155304.GB2940@saturn.kn-bremen.de> <200805011335.06415.jhb@freebsd.org> Message-ID: <20080503131139.GA37131@saturn.kn-bremen.de> On Thu, May 01, 2008 at 01:35:06PM -0400, John Baldwin wrote: > On Thursday 01 May 2008 11:53:04 am Juergen Lock wrote: > > On Thu, May 01, 2008 at 10:11:06AM -0400, John Baldwin wrote: > > > On Thursday 01 May 2008 06:19:51 am Juergen Lock wrote: > > > > On Wed, Apr 30, 2008 at 12:24:58AM +0200, Juergen Lock wrote: > > > > > Yeah, the amd64 kernel reuses the same gdt to setup all cpus, causing > > > > > kqemu to end up restoring the interrupt stackpointer (after running > > > > > guest code using its own cpu state) from the tss of the last cpu, > > > > > regardless which cpu it happened to run on. And that then causes the > > > > > last cpu's (usually) idle thread's stack to get smashed and the host > > > > > doing multiple panics... (Which also explains why pinning qemu onto > cpu > > > > > 1 worked on a 2-way host.) > > > > > > > > Hmm maybe the following is a little more clear: kqemu sets up its own > > > > cpu state and has to save and restore the original state because of > that, > > > > so among other things it does an str insn (store task register), and > later > > > > an ltr insn (load task register) using the value it got from the first > > > > str insn. That ltr insn loads the selector for the tss which is stored > > > > in the gdt, and that entry in the gdt is different for each cpu, but > since > > > > a single gdt was reused to setup the cpus at boot (in init_secondary() > in > > > > /sys/amd64/amd64/mp_machdep.c), it still points to the tss for the last > > > > cpu, instead of to the right one for the cpu the ltr insn gets executed > on. > > > > That is what the kqemu_tss_workaround() in the patch `fixes'... > > > > > > Perhaps kqemu shouldn't be doing str/ltr on amd64 instead? The things > i386 > > > uses a separate tss for in the kernel (separate stack for double faults) > is > > > handled differently on amd64 (on amd64 we make the double fault handler > use > > > one of the IST stacks). > > > > Well, kqemu uses its own gdt, tss and everything while running guest code > > in its monitor, so it kinda has to do the str/ltr.s to setup its stuff, run > > guest code, and then restore the original state of things. (And `restore > > original state of things' is what failed here.) > > > > Oh and also the tss does seem to be used for the interrupt stack on > > amd64 too, at least thats the one that ended up wrong and caused the panics > > I saw... > > The single TSS holds the IST pointers. On i386 we use a separate TSS for > double faults, but on amd64 a double fault uses the same TSS but uses the IST > pointers from that same TSS. The TSS also holds the ring stack pointer for > when syscalls, interrupts, and traps from userland cross from ring 3 to ring > 0 which is probably why you got a panic. > Yeah thats where it happened. > Because of the fact that amd64 in normal operation never changes the task > register (and that the gdt isn't used quite the same either, all the per-cpu > stuff is via FSBASE and GSBASE) I don't expect the kernel to change to use a > per-cpu gdt or the like. I think you will need to use the current approach > of patching kqemu to fixup the tss/gdt when reloading the task register. You > might want to make it a regular part of the code rather than a workaround as > a result. > Hmm okay, how would you call it then, kqemu_tss_fixup? Juergen From frank at exit.com Sat May 3 23:11:39 2008 From: frank at exit.com (Frank Mayhar) Date: Sat May 3 23:11:41 2008 Subject: Using Linux Nero port in FreeBSD 6. Message-ID: <1209856296.17097.5.camel@jill.exit.com> I've been trying to make this work and it never can seem to find the device. It's a DVD writer on /dev/cd0 (connected via USB so it's using the SCSI-like interface) and /dev/pass0. I've tried every combination I can think of of pointing /compat/linux/dev/ to either /dev/cd0 or /dev/pass0, to no avail. The best I've received is the ktrace showing it getting ENOTTY (inappropriate ioctl for device). Hints? Suggestions? -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* From Alexander at Leidinger.net Sun May 4 07:15:51 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sun May 4 07:15:55 2008 Subject: Using Linux Nero port in FreeBSD 6. In-Reply-To: <1209856296.17097.5.camel@jill.exit.com> References: <1209856296.17097.5.camel@jill.exit.com> Message-ID: <20080504091539.1b140107@deskjail> Quoting Frank Mayhar (Sat, 03 May 2008 16:11:36 -0700): > I've been trying to make this work and it never can seem to find the > device. It's a DVD writer on /dev/cd0 (connected via USB so it's using > the SCSI-like interface) and /dev/pass0. I've tried every combination I > can think of of pointing /compat/linux/dev/ to > either /dev/cd0 or /dev/pass0, to no avail. The best I've received is > the ktrace showing it getting ENOTTY (inappropriate ioctl for device). > > Hints? Suggestions? Several possibilities: The SCSI part has a linux emulation part (I don't remember the name ATM), give it a try and report back if it works. In the linux emulation exists a device wrapper feature. You can add the device there (in the source) which nero tries to open, and maybe add some more code which maps linux ioctls to FreeBSD ones (or at least identify which devices it tries to open and which ioctls it wants to do, maybe someone here on the list is willing to help out). Bye, Alexander. -- Ferengi Rule of Acquisition #139: Wives serve, brothers inherit. -- ST:DS9, "Necessary Evil" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From bugmaster at FreeBSD.org Mon May 5 11:07:03 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 5 11:07:08 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200805051107.m45B72AG070660@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/117010 emulation [linux] linux_getdents() get something like buffer ove 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/41543 emulation [patch] [request] easier wine/w23 support a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s f kern/73777 emulation [linux] [patch] linux emulation: root dir special hand o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/122318 emulation [linux] [cmake]: Segmentation fault when running Linux 10 problems total. From jhb at freebsd.org Mon May 5 13:56:20 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon May 5 13:56:40 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080503131139.GA37131@saturn.kn-bremen.de> References: <20080429222458.GA20855@saturn.kn-bremen.de> <200805011335.06415.jhb@freebsd.org> <20080503131139.GA37131@saturn.kn-bremen.de> Message-ID: <200805050950.57484.jhb@freebsd.org> On Saturday 03 May 2008 09:11:39 am Juergen Lock wrote: > On Thu, May 01, 2008 at 01:35:06PM -0400, John Baldwin wrote: > > On Thursday 01 May 2008 11:53:04 am Juergen Lock wrote: > > > On Thu, May 01, 2008 at 10:11:06AM -0400, John Baldwin wrote: > > > > On Thursday 01 May 2008 06:19:51 am Juergen Lock wrote: > > > > > On Wed, Apr 30, 2008 at 12:24:58AM +0200, Juergen Lock wrote: > > > > > > Yeah, the amd64 kernel reuses the same gdt to setup all cpus, > > > > > > causing kqemu to end up restoring the interrupt stackpointer > > > > > > (after running guest code using its own cpu state) from the tss > > > > > > of the last cpu, regardless which cpu it happened to run on. And > > > > > > that then causes the last cpu's (usually) idle thread's stack to > > > > > > get smashed and the host doing multiple panics... (Which also > > > > > > explains why pinning qemu onto > > > > cpu > > > > > > > > 1 worked on a 2-way host.) > > > > > > > > > > Hmm maybe the following is a little more clear: kqemu sets up its > > > > > own cpu state and has to save and restore the original state > > > > > because of > > > > that, > > > > > > > so among other things it does an str insn (store task register), > > > > > and > > > > later > > > > > > > an ltr insn (load task register) using the value it got from the > > > > > first str insn. That ltr insn loads the selector for the tss which > > > > > is stored in the gdt, and that entry in the gdt is different for > > > > > each cpu, but > > > > since > > > > > > > a single gdt was reused to setup the cpus at boot (in > > > > > init_secondary() > > > > in > > > > > > > /sys/amd64/amd64/mp_machdep.c), it still points to the tss for the > > > > > last cpu, instead of to the right one for the cpu the ltr insn gets > > > > > executed > > > > on. > > > > > > > That is what the kqemu_tss_workaround() in the patch `fixes'... > > > > > > > > Perhaps kqemu shouldn't be doing str/ltr on amd64 instead? The > > > > things > > > > i386 > > > > > > uses a separate tss for in the kernel (separate stack for double > > > > faults) > > > > is > > > > > > handled differently on amd64 (on amd64 we make the double fault > > > > handler > > > > use > > > > > > one of the IST stacks). > > > > > > Well, kqemu uses its own gdt, tss and everything while running guest > > > code in its monitor, so it kinda has to do the str/ltr.s to setup its > > > stuff, run guest code, and then restore the original state of things. > > > (And `restore original state of things' is what failed here.) > > > > > > Oh and also the tss does seem to be used for the interrupt stack on > > > amd64 too, at least thats the one that ended up wrong and caused the > > > panics I saw... > > > > The single TSS holds the IST pointers. On i386 we use a separate TSS for > > double faults, but on amd64 a double fault uses the same TSS but uses the > > IST pointers from that same TSS. The TSS also holds the ring stack > > pointer for when syscalls, interrupts, and traps from userland cross from > > ring 3 to ring 0 which is probably why you got a panic. > > Yeah thats where it happened. > > > Because of the fact that amd64 in normal operation never changes the task > > register (and that the gdt isn't used quite the same either, all the > > per-cpu stuff is via FSBASE and GSBASE) I don't expect the kernel to > > change to use a per-cpu gdt or the like. I think you will need to use > > the current approach of patching kqemu to fixup the tss/gdt when > > reloading the task register. You might want to make it a regular part of > > the code rather than a workaround as a result. > > Hmm okay, how would you call it then, kqemu_tss_fixup? Sure. -- John Baldwin From nox at jelal.kn-bremen.de Tue May 6 18:21:29 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Tue May 6 18:21:35 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <200805050950.57484.jhb@freebsd.org> References: <20080429222458.GA20855@saturn.kn-bremen.de> <200805011335.06415.jhb@freebsd.org> <20080503131139.GA37131@saturn.kn-bremen.de> <200805050950.57484.jhb@freebsd.org> Message-ID: <20080506181931.GA22856@saturn.kn-bremen.de> On Mon, May 05, 2008 at 09:50:57AM -0400, John Baldwin wrote: > On Saturday 03 May 2008 09:11:39 am Juergen Lock wrote: > > On Thu, May 01, 2008 at 01:35:06PM -0400, John Baldwin wrote: > > > On Thursday 01 May 2008 11:53:04 am Juergen Lock wrote: > > > > On Thu, May 01, 2008 at 10:11:06AM -0400, John Baldwin wrote: > > > > > On Thursday 01 May 2008 06:19:51 am Juergen Lock wrote: > > > > > > On Wed, Apr 30, 2008 at 12:24:58AM +0200, Juergen Lock wrote: > > > > > > > Yeah, the amd64 kernel reuses the same gdt to setup all cpus, > > > > > > > causing kqemu to end up restoring the interrupt stackpointer > > > > > > > (after running guest code using its own cpu state) from the tss > > > > > > > of the last cpu, regardless which cpu it happened to run on. And > > > > > > > that then causes the last cpu's (usually) idle thread's stack to > > > > > > > get smashed and the host doing multiple panics... (Which also > > > > > > > explains why pinning qemu onto > > > > > > cpu > > > > > > > > > > 1 worked on a 2-way host.) > > > > > > > > > > > > Hmm maybe the following is a little more clear: kqemu sets up its > > > > > > own cpu state and has to save and restore the original state > > > > > > because of > > > > > > that, > > > > > > > > > so among other things it does an str insn (store task register), > > > > > > and > > > > > > later > > > > > > > > > an ltr insn (load task register) using the value it got from the > > > > > > first str insn. That ltr insn loads the selector for the tss which > > > > > > is stored in the gdt, and that entry in the gdt is different for > > > > > > each cpu, but > > > > > > since > > > > > > > > > a single gdt was reused to setup the cpus at boot (in > > > > > > init_secondary() > > > > > > in > > > > > > > > > /sys/amd64/amd64/mp_machdep.c), it still points to the tss for the > > > > > > last cpu, instead of to the right one for the cpu the ltr insn gets > > > > > > executed > > > > > > on. > > > > > > > > > That is what the kqemu_tss_workaround() in the patch `fixes'... > > > > > > > > > > Perhaps kqemu shouldn't be doing str/ltr on amd64 instead? The > > > > > things > > > > > > i386 > > > > > > > > uses a separate tss for in the kernel (separate stack for double > > > > > faults) > > > > > > is > > > > > > > > handled differently on amd64 (on amd64 we make the double fault > > > > > handler > > > > > > use > > > > > > > > one of the IST stacks). > > > > > > > > Well, kqemu uses its own gdt, tss and everything while running guest > > > > code in its monitor, so it kinda has to do the str/ltr.s to setup its > > > > stuff, run guest code, and then restore the original state of things. > > > > (And `restore original state of things' is what failed here.) > > > > > > > > Oh and also the tss does seem to be used for the interrupt stack on > > > > amd64 too, at least thats the one that ended up wrong and caused the > > > > panics I saw... > > > > > > The single TSS holds the IST pointers. On i386 we use a separate TSS for > > > double faults, but on amd64 a double fault uses the same TSS but uses the > > > IST pointers from that same TSS. The TSS also holds the ring stack > > > pointer for when syscalls, interrupts, and traps from userland cross from > > > ring 3 to ring 0 which is probably why you got a panic. > > > > Yeah thats where it happened. > > > > > Because of the fact that amd64 in normal operation never changes the task > > > register (and that the gdt isn't used quite the same either, all the > > > per-cpu stuff is via FSBASE and GSBASE) I don't expect the kernel to > > > change to use a per-cpu gdt or the like. I think you will need to use > > > the current approach of patching kqemu to fixup the tss/gdt when > > > reloading the task register. You might want to make it a regular part of > > > the code rather than a workaround as a result. > > > > Hmm okay, how would you call it then, kqemu_tss_fixup? > > Sure. Okay, I shall rename it at the next kqemu commit. Thanx, Juergen From bsd at kuehlbox.de Tue May 6 19:35:43 2008 From: bsd at kuehlbox.de (Teufel) Date: Tue May 6 19:35:47 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080501101951.GA30274@saturn.kn-bremen.de> References: <20080429222458.GA20855@saturn.kn-bremen.de> <20080501101951.GA30274@saturn.kn-bremen.de> Message-ID: <4820AC9A.1070803@kuehlbox.de> Juergen Lock wrote: > The patch applied with offsets (I still had debug code in when I made it), > here is a rebased version: > > Index: kqemu-freebsd.c > @@ -33,6 +33,11 @@ > > #include > #include > +#ifdef __x86_64__ > +#include > +#include > +#include > +#endif > > #include "kqemu-kernel.h" > > @@ -234,6 +239,19 @@ > va_end(ap); > } > > +#ifdef __x86_64__ > +/* called with interrupts disabled */ > +void CDECL kqemu_tss_workaround(void) > +{ > + int gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); > + > + gdt_segs[GPROC0_SEL].ssd_base = (long) &common_tss[PCPU_GET(cpuid)]; > + ssdtosyssd(&gdt_segs[GPROC0_SEL], > + (struct system_segment_descriptor *)&gdt[GPROC0_SEL]); > + ltr(gsel_tss); > +} > +#endif > + > struct kqemu_instance { > #if __FreeBSD_version >= 500000 > TAILQ_ENTRY(kqemu_instance) kqemu_ent; > Index: common/kernel.c > @@ -1025,6 +1025,9 @@ > #ifdef __x86_64__ > uint16_t saved_ds, saved_es; > unsigned long fs_base, gs_base; > +#ifdef __FreeBSD__ > + struct kqemu_global_state *g = s->global_state; > +#endif > #endif > > #ifdef PROFILE > @@ -1188,6 +1191,13 @@ > apic_restore_nmi(s, apic_nmi_mask); > } > profile_record(s); > +#ifdef __FreeBSD__ > +#ifdef __x86_64__ > + spin_lock(&g->lock); > + kqemu_tss_workaround(); > + spin_unlock(&g->lock); > +#endif > +#endif > > if (s->mon_req == MON_REQ_IRQ) { > struct kqemu_exception_regs *r; > Index: kqemu-kernel.h > @@ -44,4 +44,10 @@ > > void CDECL kqemu_log(const char *fmt, ...); > > +#ifdef __FreeBSD__ > +#ifdef __x86_64__ > +void CDECL kqemu_tss_workaround(void); > +#endif > +#endif > + > #endif /* KQEMU_KERNEL_H */ > applied the patch and kqemu works now with quad core CPU running 7-stable amd64 smp. However, running a win2k3 guest results in many "fpudna in kernel mode!" kernel messages, regardless if -kernel-mode is used or not (but with kqemu-user enabled). What needs to be done to fix that? Greetings, Xat From bsd at kuehlbox.de Tue May 6 20:02:54 2008 From: bsd at kuehlbox.de (Teufel) Date: Tue May 6 20:02:59 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080506194800.876695B4C@mail.bitblocks.com> References: <20080506194800.876695B4C@mail.bitblocks.com> Message-ID: <4820B954.7040603@kuehlbox.de> Bakul Shah wrote: >> at needs to be done to fix that? >> > > Comment it out in amd64/amd64/trap.c! > getting rid of the message, yes.. but without further issues? From bakul at bitblocks.com Tue May 6 20:08:28 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Tue May 6 20:08:31 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: Your message of "Tue, 06 May 2008 21:08:10 +0200." <4820AC9A.1070803@kuehlbox.de> Message-ID: <20080506194800.876695B4C@mail.bitblocks.com> > applied the patch and kqemu works now with quad core CPU running > 7-stable amd64 smp. However, running a win2k3 guest results in many > "fpudna in kernel mode!" kernel messages, regardless if -kernel-mode is > used or not (but with kqemu-user enabled). > What needs to be done to fix that? Comment it out in amd64/amd64/trap.c! From bakul at bitblocks.com Tue May 6 20:45:12 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Tue May 6 20:45:17 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: Your message of "Tue, 06 May 2008 22:02:28 +0200." <4820B954.7040603@kuehlbox.de> Message-ID: <20080506204511.E1A945B3B@mail.bitblocks.com> On Tue, 06 May 2008 22:02:28 +0200 Teufel wrote: > Bakul Shah wrote: > >> at needs to be done to fix that? > >> > > > > Comment it out in amd64/amd64/trap.c! > > > getting rid of the message, yes.. but without further issues? The message is there "because you are not supposed to do it" See for instance http://docs.freebsd.org/cgi/getmsg.cgi?fetch=100953+0+archive/2007/freebsd-emulation/20070415.freebsd-emulation This seems to have not caused any problem in practice. And any way taking out the message doesn't change the essential behavior (the invariant is still broken) but it can speed up your emulation considerably. From edwin at mavetju.org Wed May 7 03:37:50 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Wed May 7 03:38:11 2008 Subject: QEMU with network boot Message-ID: <20080507032231.GA29548@k7.mavetju> Hello, First time user with QEMU, trying to get things up and running... I got routing working, I can reach the internet from my emulated FreeBSD 6.3 OS. Thanks to nox on #bsdports for that. When I start the qemu host with "-boot n", I see the DHCP requests and answers going over the wire (... tap device ...) but the NIC keeps saying that it can't get an IP address. This is the network output of it: --------------------------------------------------------------------------- TIME: 13:18:21.306194 IP: > (52:54:00:12:34:56) > (ff:ff:ff:ff:ff:ff) OP: 1 (BOOTPREQUEST) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 00157da3 SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 0.0.0.0 SIADDR: 0.0.0.0 GIADDR: 0.0.0.0 CHADDR: 52:54:00:12:34:56:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 1 (DHCPDISCOVER) OPTION: 57 ( 2) Maximum DHCP message size 1500 OPTION: 60 ( 13) Vendor class identifier Etherboot-5.4 OPTION: 55 ( 4) Parameter Request List 1 (Subnet mask) 3 (Routers) 12 (Host name) 43 (Vendor specific info) OPTION: 150 ( 11) ??? af050110ec8139b1 ......9. 020300 ... --------------------------------------------------------------------------- TIME: 13:18:22.003805 IP: > (00:bd:5c:dc:5d:00) > (52:54:00:12:34:56) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 00157da3 SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 192.168.253.24 SIADDR: 0.0.0.0 GIADDR: 0.0.0.0 CHADDR: 52:54:00:12:34:56:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: pxeboot. OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER) OPTION: 54 ( 4) Server identifier 192.168.253.1 OPTION: 51 ( 4) IP address leasetime 600 (10m) OPTION: 1 ( 4) Subnet mask 255.255.255.0 OPTION: 3 ( 4) Routers 192.168.253.1 OPTION: 12 ( 8) Host name qemu63-1 --------------------------------------------------------------------------- It is giving option 150, which I don't really know what for. And it is asking for vendor specific information, which I don't really know which one that is neither. Has anybody managed to get this working? How did the relevant part of your dhcp.conf look like? Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From edwin at mavetju.org Wed May 7 03:43:14 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Wed May 7 03:43:18 2008 Subject: QEMU with network boot In-Reply-To: <20080507032231.GA29548@k7.mavetju> References: <20080507032231.GA29548@k7.mavetju> Message-ID: <20080507034312.GA38256@k7.mavetju> On Wed, May 07, 2008 at 01:22:31PM +1000, Edwin Groothuis wrote: > When I start the qemu host with "-boot n", I see the DHCP requests > and answers going over the wire (... tap device ...) but the NIC > keeps saying that it can't get an IP address. This is the network > output of it: http://pxe.dev.aboveaverageurl.com/index.php/PXE_Booting gave the hint: I needed a next-server statement. It's now through to its TFTP phase. Sorry about the noise! Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From edwin at mavetju.org Wed May 7 06:01:23 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Wed May 7 06:01:27 2008 Subject: QEMU with network boot In-Reply-To: <20080507034312.GA38256@k7.mavetju> References: <20080507032231.GA29548@k7.mavetju> <20080507034312.GA38256@k7.mavetju> Message-ID: <20080507060119.GA50020@k7.mavetju> On Wed, May 07, 2008 at 01:43:12PM +1000, Edwin Groothuis wrote: > On Wed, May 07, 2008 at 01:22:31PM +1000, Edwin Groothuis wrote: > > When I start the qemu host with "-boot n", I see the DHCP requests > > and answers going over the wire (... tap device ...) but the NIC > > keeps saying that it can't get an IP address. This is the network > > output of it: > > http://pxe.dev.aboveaverageurl.com/index.php/PXE_Booting gave the > hint: I needed a next-server statement. I'll submit a PR for the manpage of pxeboot for this, because the behaviour of the ISC-DHCP has changed with version 3.0.3 about this (See http://www.mavetju.org/weblog/html/00110.html, I knew I had seen this before) > It's now through to its TFTP phase. Sorry about the noise! I have moved the file /boot/pxeboot to my tftpboot directory, it gets loaded but then QEMU complains about: ......TFTP download complete, but Unable to load file. And restarts. Not sure what goes wrong... Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From brde at optusnet.com.au Wed May 7 08:14:20 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Wed May 7 08:14:23 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080506204511.E1A945B3B@mail.bitblocks.com> References: <20080506204511.E1A945B3B@mail.bitblocks.com> Message-ID: <20080507154914.W52560@besplex.bde.org> On Tue, 6 May 2008, Bakul Shah wrote: > On Tue, 06 May 2008 22:02:28 +0200 Teufel wrote: >> Bakul Shah wrote: >>>> at needs to be done to fix that? >>> >>> Comment it out in amd64/amd64/trap.c! Bletch. >> getting rid of the message, yes.. but without further issues? > > The message is there "because you are not supposed to do it" s/you/kqemu/ (or interpret what you are not supposed to do as "running kqemu". > See for instance > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=100953+0+archive/2007/freebsd-emulation/20070415.freebsd-emulation > > This seems to have not caused any problem in practice. And > any way taking out the message doesn't change the essential > behavior (the invariant is still broken) but it can speed up > your emulation considerably. I should have changed it to a panic long ago. That would give the correct number of messages (1) :-). i386 still doesn't even print a message (perhaps it never did). The bug would probably never have existed in any FreeBSD version of kqemu if i386 had had enough invariant checking. Bruce From bakul at bitblocks.com Wed May 7 08:38:28 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Wed May 7 08:38:31 2008 Subject: QEMU with network boot In-Reply-To: Your message of "Wed, 07 May 2008 16:01:19 +1000." <20080507060119.GA50020@k7.mavetju> Message-ID: <20080507082108.72C0E5B47@mail.bitblocks.com> On Wed, 07 May 2008 16:01:19 +1000 Edwin Groothuis wrote: > On Wed, May 07, 2008 at 01:43:12PM +1000, Edwin Groothuis wrote: > > On Wed, May 07, 2008 at 01:22:31PM +1000, Edwin Groothuis wrote: > > > When I start the qemu host with "-boot n", I see the DHCP requests > > > and answers going over the wire (... tap device ...) but the NIC > > > keeps saying that it can't get an IP address. This is the network > > > output of it: > > > > http://pxe.dev.aboveaverageurl.com/index.php/PXE_Booting gave the > > hint: I needed a next-server statement. > > I'll submit a PR for the manpage of pxeboot for this, because the > behaviour of the ISC-DHCP has changed with version 3.0.3 about this > (See http://www.mavetju.org/weblog/html/00110.html, I knew I had > seen this before) > > > It's now through to its TFTP phase. Sorry about the noise! > > I have moved the file /boot/pxeboot to my tftpboot directory, it > gets loaded but then QEMU complains about: > > ......TFTP download complete, but Unable to load file. > > And restarts. Not sure what goes wrong... See my message to Freebsd-emulation, dated 23 Apr 2007 12:23:09 PDT. With the patched and recompiled etherboom ROM now it gets to pxeboot loader's OK prompt. NFS MOUNT fails but it gets further than I remember! $ qemu-system-x86_64 \ -net tap -net nic,macaddr=52:54:0:12:34:56,model=rtl8139 \ -option-rom pxe-rtl8129.bin -boot n \ -curses img ------------------------------------------------------------------------------- ....................................................................PXE2done PXE3PXE Loader 1.00 Building the boot loader arguments Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 PXE version 2.1, real mode entry point @9f00:0680 BIOS 639kB/128967kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (bakul@free.bitblocks.com, Tue Apr 24 10:30:38 PDT 2007) pxe_open: server addr: 172.20.0.1 pxe_open: server path: /usr/tftproot pxe_open: gateway ip: 172.20.0.1 NFS MOUNT RPC error: 13 \ can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK ------------------------------------------------------------------------------- From bakul at bitblocks.com Wed May 7 09:07:23 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Wed May 7 09:07:27 2008 Subject: QEMU with network boot In-Reply-To: Your message of "Wed, 07 May 2008 01:21:08 PDT." <20080507082108.72C0E5B47@mail.bitblocks.com> Message-ID: <20080507090723.241405B50@mail.bitblocks.com> On Wed, 07 May 2008 01:21:08 PDT Bakul Shah wrote: > On Wed, 07 May 2008 16:01:19 +1000 Edwin Groothuis wrote > : > > On Wed, May 07, 2008 at 01:43:12PM +1000, Edwin Groothuis wrote: > > > On Wed, May 07, 2008 at 01:22:31PM +1000, Edwin Groothuis wrote: > > See my message to Freebsd-emulation, dated 23 Apr 2007 > 12:23:09 PDT. With the patched and recompiled etherboom ROM > now it gets to pxeboot loader's OK prompt. NFS MOUNT fails > but it gets further than I remember! > > $ qemu-system-x86_64 \ > -net tap -net nic,macaddr=52:54:0:12:34:56,model=rtl8139 \ > -option-rom pxe-rtl8129.bin -boot n \ > -curses img > > NFS MOUNT RPC error: 13 This was due to a misspelled root-path in my dhcpd.conf. Now it boots fine. From edwin at mavetju.org Wed May 7 12:14:40 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Wed May 7 12:14:44 2008 Subject: QEMU with network boot In-Reply-To: <20080507082108.72C0E5B47@mail.bitblocks.com> References: <20080507060119.GA50020@k7.mavetju> <20080507082108.72C0E5B47@mail.bitblocks.com> Message-ID: <20080507121437.GB44028@k7.mavetju> On Wed, May 07, 2008 at 01:21:08AM -0700, Bakul Shah wrote: > > I have moved the file /boot/pxeboot to my tftpboot directory, it > > gets loaded but then QEMU complains about: > > > > ......TFTP download complete, but Unable to load file. > > > > And restarts. Not sure what goes wrong... > > See my message to Freebsd-emulation, dated 23 Apr 2007 > 12:23:09 PDT. With the patched and recompiled etherboom ROM > now it gets to pxeboot loader's OK prompt. NFS MOUNT fails > but it gets further than I remember! Thanks for your reply, I've managed to create my new rtl8139.zrom. And it works like a charm! --------------------- 8< ---------------------------------- Loading 192.168.253.1:/boot/pxeboot ..(PXE)..................................... ................................................................................ ................................................................................ ................................................................................ ................................................................................ .......................................................................done PXE Loader 1.00 Building the boot loader arguments Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.01 Consoles: internal video/keyboard BIOS drive C: is disk0 PXE version 2.1, real mode entry point @9f00:0680 int=0000000d err=00000000 efl=00020002 eip=00000916 eax=0009cb90 ebx=000008eb ecx=00000000 edx=00003c54 esi=00000000 edi=00000000 ebp=0009cf62 esp=000003d2 cs=9f00 ds=9f00 es=0000 fs=0000 gs=0000 ss=9cb9 cs:eip=66 0f 01 97 52 00 0f 20-c0 0c 01 0f 22 c0 66 ff af 6a 00 66 b8 10 00 8e-d0 89 ec 8e d8 8e c0 8e ss:esp=00 00 00 00 71 00 00 00-00 00 00 00 e2 f6 09 00 00 9f b9 9c 00 00 00 00-00 00 00 00 00 00 02 02 BTX halted --------------------- 8< ---------------------------------- Nearly like a charm. Well, the PXE part does work now, but the BTX part is not good. It doesn't matter if I use an pxeboot from an 6.3 system or an 7.0 system. This happens with both emulators/qemu as with emulators/qemu-devel. Any idea where to look now? Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From edwin at mavetju.org Wed May 7 12:18:32 2008 From: edwin at mavetju.org (Edwin Groothuis) Date: Wed May 7 12:18:35 2008 Subject: QEMU with network boot In-Reply-To: <20080507121437.GB44028@k7.mavetju> References: <20080507060119.GA50020@k7.mavetju> <20080507082108.72C0E5B47@mail.bitblocks.com> <20080507121437.GB44028@k7.mavetju> Message-ID: <20080507121830.GA81479@k7.mavetju> On Wed, May 07, 2008 at 10:14:37PM +1000, Edwin Groothuis wrote: > On Wed, May 07, 2008 at 01:21:08AM -0700, Bakul Shah wrote: > > > I have moved the file /boot/pxeboot to my tftpboot directory, it > > > gets loaded but then QEMU complains about: > > > > > > ......TFTP download complete, but Unable to load file. > > > > > > And restarts. Not sure what goes wrong... > > > > See my message to Freebsd-emulation, dated 23 Apr 2007 > > 12:23:09 PDT. With the patched and recompiled etherboom ROM > > now it gets to pxeboot loader's OK prompt. NFS MOUNT fails > > but it gets further than I remember! > > Thanks for your reply, I've managed to create my new rtl8139.zrom. > And it works like a charm! > > --------------------- 8< ---------------------------------- > Loading 192.168.253.1:/boot/pxeboot ..(PXE)..................................... > ................................................................................ > ................................................................................ > ................................................................................ > ................................................................................ > .......................................................................done > PXE Loader 1.00 > > Building the boot loader arguments > Relocating the loader and the BTX > Starting the BTX loader > > BTX loader 1.00 BTX version is 1.01 > Consoles: internal video/keyboard > BIOS drive C: is disk0 > > PXE version 2.1, real mode entry point @9f00:0680 > > int=0000000d err=00000000 efl=00020002 eip=00000916 > eax=0009cb90 ebx=000008eb ecx=00000000 edx=00003c54 > esi=00000000 edi=00000000 ebp=0009cf62 esp=000003d2 > cs=9f00 ds=9f00 es=0000 fs=0000 gs=0000 ss=9cb9 > cs:eip=66 0f 01 97 52 00 0f 20-c0 0c 01 0f 22 c0 66 ff > af 6a 00 66 b8 10 00 8e-d0 89 ec 8e d8 8e c0 8e > ss:esp=00 00 00 00 71 00 00 00-00 00 00 00 e2 f6 09 00 > 00 9f b9 9c 00 00 00 00-00 00 00 00 00 00 02 02 > > BTX halted > --------------------- 8< ---------------------------------- > > Nearly like a charm. Well, the PXE part does work now, but the BTX > part is not good. > > It doesn't matter if I use an pxeboot from an 6.3 system or an 7.0 > system. This happens with both emulators/qemu as with emulators/qemu-devel. > > Any idea where to look now? http://www.mavetju.org/mail/view_message.php?list=freebsd-emulation&id=2550189 of course. I need to start writing things up on this so others will have less troubles than I have :-) Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From kostikbel at gmail.com Wed May 7 12:31:08 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed May 7 12:31:14 2008 Subject: QEMU with network boot In-Reply-To: <20080507121830.GA81479@k7.mavetju> References: <20080507060119.GA50020@k7.mavetju> <20080507082108.72C0E5B47@mail.bitblocks.com> <20080507121437.GB44028@k7.mavetju> <20080507121830.GA81479@k7.mavetju> Message-ID: <20080507123013.GC18958@deviant.kiev.zoral.com.ua> On Wed, May 07, 2008 at 10:18:30PM +1000, Edwin Groothuis wrote: > On Wed, May 07, 2008 at 10:14:37PM +1000, Edwin Groothuis wrote: > > On Wed, May 07, 2008 at 01:21:08AM -0700, Bakul Shah wrote: > > > > I have moved the file /boot/pxeboot to my tftpboot directory, it > > > > gets loaded but then QEMU complains about: > > > > > > > > ......TFTP download complete, but Unable to load file. > > > > > > > > And restarts. Not sure what goes wrong... > > > > > > See my message to Freebsd-emulation, dated 23 Apr 2007 > > > 12:23:09 PDT. With the patched and recompiled etherboom ROM > > > now it gets to pxeboot loader's OK prompt. NFS MOUNT fails > > > but it gets further than I remember! > > > > Thanks for your reply, I've managed to create my new rtl8139.zrom. > > And it works like a charm! > > > > --------------------- 8< ---------------------------------- > > Loading 192.168.253.1:/boot/pxeboot ..(PXE)..................................... > > ................................................................................ > > ................................................................................ > > ................................................................................ > > ................................................................................ > > .......................................................................done > > PXE Loader 1.00 > > > > Building the boot loader arguments > > Relocating the loader and the BTX > > Starting the BTX loader > > > > BTX loader 1.00 BTX version is 1.01 > > Consoles: internal video/keyboard > > BIOS drive C: is disk0 > > > > PXE version 2.1, real mode entry point @9f00:0680 > > > > int=0000000d err=00000000 efl=00020002 eip=00000916 > > eax=0009cb90 ebx=000008eb ecx=00000000 edx=00003c54 > > esi=00000000 edi=00000000 ebp=0009cf62 esp=000003d2 > > cs=9f00 ds=9f00 es=0000 fs=0000 gs=0000 ss=9cb9 > > cs:eip=66 0f 01 97 52 00 0f 20-c0 0c 01 0f 22 c0 66 ff > > af 6a 00 66 b8 10 00 8e-d0 89 ec 8e d8 8e c0 8e > > ss:esp=00 00 00 00 71 00 00 00-00 00 00 00 e2 f6 09 00 > > 00 9f b9 9c 00 00 00 00-00 00 00 00 00 00 02 02 > > > > BTX halted > > --------------------- 8< ---------------------------------- > > > > Nearly like a charm. Well, the PXE part does work now, but the BTX > > part is not good. > > > > It doesn't matter if I use an pxeboot from an 6.3 system or an 7.0 > > system. This happens with both emulators/qemu as with emulators/qemu-devel. > > > > Any idea where to look now? > > http://www.mavetju.org/mail/view_message.php?list=freebsd-emulation&id=2550189 > of course. > > I need to start writing things up on this so others will have less > troubles than I have :-) jhb@ implemented the real-mode BTX and committed it into CVS. It is in HEAD and RELENG_7, and I believe it is in RELENG_6 too. You need either to update your sources or to take new btx from the head of desired branch. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080507/9625e577/attachment.pgp From alex.wilkinson at dsto.defence.gov.au Wed May 7 13:58:30 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Wed May 7 13:58:39 2008 Subject: QEMU with network boot In-Reply-To: <20080507123013.GC18958@deviant.kiev.zoral.com.ua> References: <20080507060119.GA50020@k7.mavetju> <20080507082108.72C0E5B47@mail.bitblocks.com> <20080507121437.GB44028@k7.mavetju> <20080507121830.GA81479@k7.mavetju> <20080507123013.GC18958@deviant.kiev.zoral.com.ua> Message-ID: <20080507124147.GF1456@stlux503.dsto.defence.gov.au> 0n Wed, May 07, 2008 at 03:30:13PM +0300, Kostik Belousov wrote: >jhb@ implemented the real-mode BTX and committed it into CVS. It is in >HEAD and RELENG_7, and I believe it is in RELENG_6 too. You need either >to update your sources or to take new btx from the head of desired branch. What is "real-mode BTX" ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From alex.wilkinson at dsto.defence.gov.au Wed May 7 13:58:30 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Wed May 7 13:58:39 2008 Subject: QEMU with network boot In-Reply-To: <20080507032231.GA29548@k7.mavetju> References: <20080507032231.GA29548@k7.mavetju> Message-ID: <20080507115011.GB1456@stlux503.dsto.defence.gov.au> 0n Wed, May 07, 2008 at 01:22:31PM +1000, Edwin Groothuis wrote: > --------------------------------------------------------------------------- > TIME: 13:18:21.306194 > IP: > (52:54:00:12:34:56) > (ff:ff:ff:ff:ff:ff) > OP: 1 (BOOTPREQUEST) > HTYPE: 1 (Ethernet) > HLEN: 6 > HOPS: 0 > XID: 00157da3 > SECS: 0 > FLAGS: 0 > CIADDR: 0.0.0.0 > YIADDR: 0.0.0.0 > SIADDR: 0.0.0.0 > GIADDR: 0.0.0.0 > CHADDR: 52:54:00:12:34:56:00:00:00:00:00:00:00:00:00:00 > SNAME: . > FNAME: . > OPTION: 53 ( 1) DHCP message type 1 (DHCPDISCOVER) > OPTION: 57 ( 2) Maximum DHCP message size 1500 > OPTION: 60 ( 13) Vendor class identifier Etherboot-5.4 > OPTION: 55 ( 4) Parameter Request List 1 (Subnet mask) > 3 (Routers) > 12 (Host name) > 43 (Vendor specific info) > > OPTION: 150 ( 11) ??? af050110ec8139b1 ......9. > 020300 ... > --------------------------------------------------------------------------- Edwin, I'm curious, what tool did you use to gather this output ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From bakul at bitblocks.com Wed May 7 16:03:39 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Wed May 7 16:03:42 2008 Subject: QEMU with network boot In-Reply-To: Your message of "Wed, 07 May 2008 22:14:37 +1000." <20080507121437.GB44028@k7.mavetju> Message-ID: <20080507160338.9784E5B47@mail.bitblocks.com> On Wed, 07 May 2008 22:14:37 +1000 Edwin Groothuis wrote: > Nearly like a charm. Well, the PXE part does work now, but the BTX > part is not good. > > It doesn't matter if I use an pxeboot from an 6.3 system or an 7.0 > system. This happens with both emulators/qemu as with emulators/qemu-devel. > > Any idea where to look now? I should've mentioned I am using FreeBSD-current which has a working pxeboot thanks to jhb. It netboots with my patched etherboot bios but fails with bioses distributed with qemu. My year old patch works around etherboot's length related bug -- a TFTP data mode packet with length=0 confuses qemu's roms. I just realized we can make a fix elsewhere to make the stock qemu bios work! It is a complicated fix so be prepared to really understand it. Ready? Here is how: echo >> $tftproot/boot/pxebot :-) The default NE2000 NIC works fine too but you may want to use rtl8139 for better performance. From bakul at bitblocks.com Wed May 7 16:27:14 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Wed May 7 16:27:16 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: Your message of "Wed, 07 May 2008 15:54:56 +1000." <20080507154914.W52560@besplex.bde.org> Message-ID: <20080507162713.73A3A5B47@mail.bitblocks.com> On Wed, 07 May 2008 15:54:56 +1000 Bruce Evans wrote: > On Tue, 6 May 2008, Bakul Shah wrote: > > > On Tue, 06 May 2008 22:02:28 +0200 Teufel wrote: > >> Bakul Shah wrote: > >>>> at needs to be done to fix that? > >>> > >>> Comment it out in amd64/amd64/trap.c! > > Bletch. > > >> getting rid of the message, yes.. but without further issues? > > > > The message is there "because you are not supposed to do it" > > s/you/kqemu/ (or interpret what you are not supposed to do as "running kqemu" > . > > > See for instance > > > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=100953+0+archive/2007/freebsd- > emulation/20070415.freebsd-emulation > > > > This seems to have not caused any problem in practice. And > > any way taking out the message doesn't change the essential > > behavior (the invariant is still broken) but it can speed up > > your emulation considerably. > > I should have changed it to a panic long ago. That would give the correct > number of messages (1) :-). Too late now for you to go fundamentalist :-) > i386 still doesn't even print a message (perhaps it never did). The > bug would probably never have existed in any FreeBSD version of kqemu if > i386 had had enough invariant checking. It does (in isa/npx.c) and I've disabled it! I seem to recall it is not just qemu but also some ndis drivers that trigger this fpudna/npxdna message? Didn't someone (Attilio?) has ported dragonfly code to allow FPU register use in kernel mode? Whatever happened to it? From higinsjessy123 at gmail.com Thu May 8 06:15:15 2008 From: higinsjessy123 at gmail.com (Christopher Simon) Date: Thu May 8 06:15:20 2008 Subject: need a DRIVER for WINE TASTING in Santa Barbara??? Message-ID: <015d5b17$39575$01079586895949@owner-20877af31> Christopher Simon 805-291-7319 WEBSITE: WWW.IDRIVEUEVERYWHERE.COM Experienced male driver will happily drive you through wine tasting country near Santa Barbara in the beautiful Santa Ynez Valley. You have only to enjoy the fun of sight, sound and drink without the hassles or worries. (must provide vehicle) - References upon request. TRUSTED, RELIABLE and FUN * Make your reservations *Available 24/7* I charge an affordable hourly rate of $25.00 Tipping is allowed Contact: Christopher Simon (805) 291-7319 NOTE: for situations where you need more than one driver I have two friends that also drive. From brde at optusnet.com.au Thu May 8 12:00:17 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Thu May 8 12:00:23 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080507162713.73A3A5B47@mail.bitblocks.com> References: <20080507162713.73A3A5B47@mail.bitblocks.com> Message-ID: <20080508195843.G17500@delplex.bde.org> On Wed, 7 May 2008, Bakul Shah wrote: > On Wed, 07 May 2008 15:54:56 +1000 Bruce Evans wrote: >> On Tue, 6 May 2008, Bakul Shah wrote: >>> See for instance >>> >>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=100953+0+archive/2007/freebsd- >> emulation/20070415.freebsd-emulation >>> >>> This seems to have not caused any problem in practice. And >>> any way taking out the message doesn't change the essential >>> behavior (the invariant is still broken) but it can speed up >>> your emulation considerably. >> >> I should have changed it to a panic long ago. That would give the correct >> number of messages (1) :-). > > Too late now for you to go fundamentalist :-) > >> i386 still doesn't even print a message (perhaps it never did). The >> bug would probably never have existed in any FreeBSD version of kqemu if >> i386 had had enough invariant checking. > > It does (in isa/npx.c) and I've disabled it! Not too late to go fundamentalist for that :-). I wrote it correctly. It paniced, but it was broken to a printf in rev.1.131 when I wasn't watching closely enough (though the log claims that I reviewed the patch, ISTR looking mainly at the parts in machdep.c). The message in npx.c is actually about violation of an even more fundamental invariant -- the invariant that owning the FPU includes having the TS flag clear so that DNA traps cannot occur. The bug in kqemu seems to be mismanagement of the TS flag related to this. I forget if it is the host or the target TS flag that seems to be mismanaged. For the target, it would take a bug in the virtualization of the TS flag to break this invariant (assuming no related bugs in the target kernel). The message in amd64/machdep.c is about violation of the invariant that the kernel cannot cause DNA traps. Spurious DNA traps in the target kernel might be caused either by violation of the previous invariant (then we might get a spurious DNA trap as part of non-broken target kernel FPU handling, after we have properly acquired ownership of the FPU). Non-spurious but wrong DNA traps in the host kernel might be caused by not properly acquiring ownership of the FPU before using it. This bug would be easier to implement, but I now remember more of the previous discussion and doubt that it is the bug in kqemu. It was said that kqemu never uses the FPU directly (not even for fxsave/fxrstor?) The second bug was implemented 3 years ago in the i386 linux emulator in rev.1.136 of linux_sysvec.c, but the bug is not detected because there is not even a printf about it in the i386 trap.c :-( and it is not a bug at the level of npx.c. The implementation is simply to hack on the FPU directly to set the control word. This is also a layering violation, but the API intended to be used for this initialization (npxinit()) is no longer used for this and no longer works for this. Direct hacking on the FPU works almost correctly here. It mainly wastes time by defeating the lazy reinitialization of the FPU on exec. > I seem to recall it is not just qemu but also some ndis > drivers that trigger this fpudna/npxdna message? I think that is from just hacking on the FPU directly. Windows drivers could easily have a bug like that. > Didn't > someone (Attilio?) has ported dragonfly code to allow FPU > register use in kernel mode? Whatever happened to it? I objected to it, and Attilio found better things to work on. Parts of it give a cleaner implementation of allowing controlled use of the FPU in the kernel, but even it didn't allow arbitrary use (as might be necessary for bad Windows drivers), and there are no known useful uses for the FPU/SSE in the kernel except on old systems: - Copying through SSE2 can be up to twice as fast as copying through 32-bit integer registers, but not-so-old systems in 64-bit mode can use 64-bit integer registers. Also, it is hard to find a real application where the speedups possible from copying through SSE2 affects more than the noise, since it takes very large data for copying running at multi-GB/S to take very long, but very large data is too large to cache and copying through SSE2 makes no difference in the uncached case.) - some multimedia instructions might be useful in the kernel. But it is hard to find a useful use that executes enough of them to justify a FPU context switch just to use them. Bruce From nirv199 at yahoo.com Thu May 8 12:54:55 2008 From: nirv199 at yahoo.com (Paulo Roberto) Date: Thu May 8 12:55:00 2008 Subject: dynamips / dynagen network interface problem on 802.1q Message-ID: <378987.73328.qm@web37105.mail.mud.yahoo.com> Hi, Not sure if this is the correct mail list to post this question, please excuse me if not. I updated to the lateste devel-version of both dynamips+dynagen ports (emulators), and I can only get the ethernet virtual switch to output untagged frames out my interface. When using dot1q, no frames are sent over the wire. The strange part is that freebsd tcpdump sees those dot1q tagged frames, but the interface (using bge) does not wire them. I have compiled the kernel with both bge and vlan support. FreeBSD 6.3. Dynagen config: [[ETHSW SW]] 0 = dot1q 1 NIO_gen_eth:bge0 Anyone have any idea of what might be wrong? Thanks ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From chagin.dmitry at gmail.com Fri May 9 15:03:19 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Fri May 9 15:03:23 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: <20080508210641.GA81647@freebsd.org> References: <20080506214738.GA31134@freebsd.org> <20080508165244.GA68088@freebsd.org> <20080508170819.GA68720@freebsd.org> <20080508172503.GA69463@freebsd.org> <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> Message-ID: hi. Recently with Roman have decided to make emulation linux-x86-64. Here a patch: http://81.200.6.196/linux-x86-64.diff.tar.gz That's made: created module infrastructure. existing files are copied (removed unsupported syscalls, commented some code, etc...) signals unsupported yet. The module is compiled, but linux64 binaries hangs at loading libc: ora# /compat/linux/bin/pwd 6078: 6078: file=libc.so.6 [0]; needed by /compat/linux/bin/pwd [0] 6078: find library=libc.so.6 [0]; searching 6078: search cache=/etc/ld.so.cache 6078: search path=/lib64/tls:/lib64:/usr/lib64/tls:/usr/lib64 (system search path) 6078: trying file=/lib64/tls/libc.so.6 6078: trying file=/lib64/libc.so.6 /compat/linux/bin/pwd: error while loading shared libraries: /lib64/libc.so.6: c annot read file data: Error 9 Work proceeds further :) That is necessary: review && comments about modificated existing sys/compat/linux files. The help from glibc experts - now i shall not understand where it is fallen off. thnx! -- Have fun! chd From chagin.dmitry at gmail.com Fri May 9 15:14:10 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Fri May 9 15:14:14 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: References: <20080506214738.GA31134@freebsd.org> <20080508165244.GA68088@freebsd.org> <20080508170819.GA68720@freebsd.org> <20080508172503.GA69463@freebsd.org> <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> Message-ID: On Fri, 9 May 2008, Chagin Dmitry wrote: > ora# /compat/linux/bin/pwd > 6078: > 6078: file=libc.so.6 [0]; needed by /compat/linux/bin/pwd [0] > 6078: find library=libc.so.6 [0]; searching > 6078: search cache=/etc/ld.so.cache > 6078: search path=/lib64/tls:/lib64:/usr/lib64/tls:/usr/lib64 > (system search path) > 6078: trying file=/lib64/tls/libc.so.6 > 6078: trying file=/lib64/libc.so.6 > /compat/linux/bin/pwd: error while loading shared libraries: > /lib64/libc.so.6: c > annot read file data: Error 9 ups... incorrect example, sorry. ldconfig hangs ora# /compat/linux/sbin/ldconfig -r /compat/linux ?????? ???????????(core dumped) traced syscalls: newuname brk(0) brk(0x6adf20) arch_prctl(0x1002, 0x6ad860) brk(0x6cef20) brk(0x6cf000) pid 6362 (ldconfig), uid 0: exited on signal 11 (core dumped) thnx! -- Have fun! chd From nox at jelal.kn-bremen.de Fri May 9 22:12:11 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Fri May 9 22:12:14 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080508195843.G17500@delplex.bde.org> References: <20080507162713.73A3A5B47@mail.bitblocks.com> <20080508195843.G17500@delplex.bde.org> Message-ID: <20080509220922.GA13480@saturn.kn-bremen.de> On Thu, May 08, 2008 at 09:59:57PM +1000, Bruce Evans wrote: > On Wed, 7 May 2008, Bakul Shah wrote: > >> On Wed, 07 May 2008 15:54:56 +1000 Bruce Evans >> wrote: >>> On Tue, 6 May 2008, Bakul Shah wrote: >>>> See for instance >>>> >>>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=100953+0+archive/2007/freebsd- >>> emulation/20070415.freebsd-emulation >>>> >>>> This seems to have not caused any problem in practice. And >>>> any way taking out the message doesn't change the essential >>>> behavior (the invariant is still broken) but it can speed up >>>> your emulation considerably. >>> >>> I should have changed it to a panic long ago. That would give the >>> correct >>> number of messages (1) :-). >> >> Too late now for you to go fundamentalist :-) >> >>> i386 still doesn't even print a message (perhaps it never did). The >>> bug would probably never have existed in any FreeBSD version of kqemu if >>> i386 had had enough invariant checking. >> >> It does (in isa/npx.c) and I've disabled it! > > Not too late to go fundamentalist for that :-). I wrote it correctly. > It paniced, but it was broken to a printf in rev.1.131 when I wasn't > watching closely enough (though the log claims that I reviewed the > patch, ISTR looking mainly at the parts in machdep.c). > > The message in npx.c is actually about violation of an even more > fundamental invariant -- the invariant that owning the FPU includes > having the TS flag clear so that DNA traps cannot occur. The bug in > kqemu seems to be mismanagement of the TS flag related to this. I > forget if it is the host or the target TS flag that seems to be mismanaged. > For the target, it would take a bug in the virtualization of the TS flag > to break this invariant (assuming no related bugs in the target kernel). > Well the `fpcurthread == curthread' bug has been fixed quite a while ago already, or do you mean another one? > The message in amd64/machdep.c is about violation of the invariant > that the kernel cannot cause DNA traps. Spurious DNA traps in the > target kernel might be caused either by violation of the previous > invariant (then we might get a spurious DNA trap as part of non-broken > target kernel FPU handling, after we have properly acquired ownership > of the FPU). Non-spurious but wrong DNA traps in the host kernel might > be caused by not properly acquiring ownership of the FPU before using > it. This bug would be easier to implement, but I now remember more > of the previous discussion and doubt that it is the bug in kqemu. It > was said that kqemu never uses the FPU directly (not even for > fxsave/fxrstor?) > Okay I _think_ I know a little more about this now... kqemu itself doesn't use the fpu, but the guest code it runs can, and in that case the DNA trap is just used for (host) lazy fpu context switching like as if the code was running in userland regularly. And I just tested the following patch that should get rid of the message by calling fpudna/npxdna directly (files/patch-fpucontext is the interesting part:) Index: Makefile =================================================================== RCS file: /home/pcvs/ports/emulators/kqemu-kmod/Makefile,v retrieving revision 1.23 diff -u -p -r1.23 Makefile --- Makefile 1 May 2008 13:29:16 -0000 1.23 +++ Makefile 9 May 2008 19:53:08 -0000 @@ -7,7 +7,7 @@ PORTNAME= kqemu PORTVERSION= 1.3.0.p11 -PORTREVISION= 4 +PORTREVISION= 5 CATEGORIES= emulators kld MASTER_SITES= http://fabrice.bellard.free.fr/qemu/ \ http://qemu.org/ \ Index: files/patch-tssworkaround =================================================================== RCS file: /home/pcvs/ports/emulators/kqemu-kmod/files/patch-tssworkaround,v retrieving revision 1.1 diff -u -p -r1.1 patch-tssworkaround --- files/patch-tssworkaround 1 May 2008 13:29:16 -0000 1.1 +++ files/patch-tssworkaround 9 May 2008 19:34:12 -0000 @@ -1,8 +1,8 @@ Index: kqemu-freebsd.c -@@ -33,6 +33,11 @@ - - #include - #include +@@ -38,6 +38,11 @@ + #else + #include + #endif +#ifdef __x86_64__ +#include +#include @@ -11,13 +11,13 @@ Index: kqemu-freebsd.c #include "kqemu-kernel.h" -@@ -234,6 +239,19 @@ +@@ -248,6 +253,19 @@ va_end(ap); } +#ifdef __x86_64__ +/* called with interrupts disabled */ -+void CDECL kqemu_tss_workaround(void) ++void CDECL kqemu_tss_fixup(void) +{ + int gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); + @@ -49,7 +49,7 @@ Index: common/kernel.c +#ifdef __FreeBSD__ +#ifdef __x86_64__ + spin_lock(&g->lock); -+ kqemu_tss_workaround(); ++ kqemu_tss_fixup(); + spin_unlock(&g->lock); +#endif +#endif @@ -63,7 +63,7 @@ Index: kqemu-kernel.h +#ifdef __FreeBSD__ +#ifdef __x86_64__ -+void CDECL kqemu_tss_workaround(void); ++void CDECL kqemu_tss_fixup(void); +#endif +#endif + Index: files/patch-fpucontext @@ -0,0 +1,76 @@ +Index: common/kernel.c +@@ -1240,6 +1240,9 @@ + case MON_REQ_EXCEPTION: + exec_exception(s->arg0); + break; ++ case MON_REQ_LOADFPUCONTEXT: ++ kqemu_loadfpucontext(s->arg0); ++ break; + default: + kqemu_log("invalid mon request: %d\n", s->mon_req); + break; +Index: common/kqemu_int.h +@@ -523,6 +523,7 @@ + MON_REQ_LOCK_USER_PAGE, + MON_REQ_UNLOCK_USER_PAGE, + MON_REQ_EXCEPTION, ++ MON_REQ_LOADFPUCONTEXT, + } MonitorRequest; + + #define INTERRUPT_ENTRY_SIZE 16 +Index: common/monitor.c +@@ -1995,8 +1995,13 @@ + raise_exception_err(s, EXCP07_PREX, 0); + } else { + /* the host needs to restore the FPU state for us */ ++#ifndef __FreeBSD__ + s->mon_req = MON_REQ_EXCEPTION; + s->arg0 = 0x07; ++#else ++ s->mon_req = MON_REQ_LOADFPUCONTEXT; ++ s->arg0 = (unsigned long)s->cpu_state.cpl; ++#endif + monitor2kernel1(s); + } + } +Index: kqemu-freebsd.c +@@ -33,6 +33,11 @@ + + #include + #include ++#ifdef __x86_64__ ++#include ++#else ++#include ++#endif + + #include "kqemu-kernel.h" + +@@ -172,6 +177,15 @@ + { + } + ++void CDECL kqemu_loadfpucontext(unsigned long cpl) ++{ ++#ifdef __x86_64__ ++ fpudna(); ++#else ++ npxdna(); ++#endif ++} ++ + #if __FreeBSD_version < 500000 + static int + curpriority_cmp(struct proc *p) +Index: kqemu-kernel.h +@@ -40,6 +40,10 @@ + void * CDECL kqemu_io_map(unsigned long page_index, unsigned int size); + void CDECL kqemu_io_unmap(void *ptr, unsigned int size); + ++#ifdef __FreeBSD__ ++void CDECL kqemu_loadfpucontext(unsigned long cpl); ++#endif ++ + int CDECL kqemu_schedule(void); + + void CDECL kqemu_log(const char *fmt, ...); From rdivacky at freebsd.org Sat May 10 10:50:44 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sat May 10 10:50:47 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: References: <20080508165244.GA68088@freebsd.org> <20080508170819.GA68720@freebsd.org> <20080508172503.GA69463@freebsd.org> <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> Message-ID: <20080510105008.GA71225@freebsd.org> On Fri, May 09, 2008 at 07:02:05PM +0400, Chagin Dmitry wrote: > > hi. > > Recently with Roman have decided to make emulation linux-x86-64. > Here a patch: http://81.200.6.196/linux-x86-64.diff.tar.gz witten ~# fetch http://81.200.6.196/linux-x86-64.diff.tar.gz fetch: http://81.200.6.196/linux-x86-64.diff.tar.gz: No route to host > That's made: > created module infrastructure. > existing files are copied (removed unsupported syscalls, > commented some code, etc...) signals unsupported yet. > The module is compiled, but linux64 binaries hangs at loading libc: > > ora# /compat/linux/bin/pwd > 6078: > 6078: file=libc.so.6 [0]; needed by /compat/linux/bin/pwd [0] > 6078: find library=libc.so.6 [0]; searching > 6078: search cache=/etc/ld.so.cache > 6078: search path=/lib64/tls:/lib64:/usr/lib64/tls:/usr/lib64 > (system search path) > 6078: trying file=/lib64/tls/libc.so.6 > 6078: trying file=/lib64/libc.so.6 > /compat/linux/bin/pwd: error while loading shared libraries: > /lib64/libc.so.6: c > annot read file data: Error 9 > > Work proceeds further :) > > That is necessary: review && comments about modificated existing > sys/compat/linux files. The help from glibc experts - now i shall not > understand where it is fallen off. Dmitry has fixed this (a wrong AUX entry). I think we should sponsor him with a p4 account... great work! roman From chagin.dmitry at gmail.com Sat May 10 11:36:15 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Sat May 10 11:36:19 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: <20080510105008.GA71225@freebsd.org> References: <20080508165244.GA68088@freebsd.org> <20080508170819.GA68720@freebsd.org> <20080508172503.GA69463@freebsd.org> <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> <20080510105008.GA71225@freebsd.org> Message-ID: On Sat, 10 May 2008, Roman Divacky wrote: > On Fri, May 09, 2008 at 07:02:05PM +0400, Chagin Dmitry wrote: >> >> hi. >> >> Recently with Roman have decided to make emulation linux-x86-64. >> Here a patch: http://81.200.6.196/linux-x86-64.diff.tar.gz > > witten ~# fetch http://81.200.6.196/linux-x86-64.diff.tar.gz > fetch: http://81.200.6.196/linux-x86-64.diff.tar.gz: No route to host > you have got at that time when i reloaded a server with a new kernel and have flow on a panic :) (bad malloc/free in re0 probably - i see later) now all works > > Dmitry has fixed this (a wrong AUX entry). I think we should sponsor > him with a p4 account... > now /compat/linux/bin/pwd exited without SIGSEGV, but on former can't load libc -- Have fun! chd From brde at optusnet.com.au Sat May 10 12:29:08 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Sat May 10 12:29:13 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080509220922.GA13480@saturn.kn-bremen.de> References: <20080507162713.73A3A5B47@mail.bitblocks.com> <20080508195843.G17500@delplex.bde.org> <20080509220922.GA13480@saturn.kn-bremen.de> Message-ID: <20080510213519.P3083@besplex.bde.org> On Sat, 10 May 2008, Juergen Lock wrote: > On Thu, May 08, 2008 at 09:59:57PM +1000, Bruce Evans wrote: >> The message in npx.c is actually about violation of an even more >> fundamental invariant -- the invariant that owning the FPU includes >> having the TS flag clear so that DNA traps cannot occur. The bug in >> kqemu seems to be mismanagement of the TS flag related to this. I >> forget if it is the host or the target TS flag that seems to be mismanaged. >> For the target, it would take a bug in the virtualization of the TS flag >> to break this invariant (assuming no related bugs in the target kernel). >> > Well the `fpcurthread == curthread' bug has been fixed quite a while > ago already, or do you mean another one? I didn't know what is already fixed. >> The message in amd64/machdep.c is about violation of the invariant >> that the kernel cannot cause DNA traps. Spurious DNA traps in the >> ... >> > Okay I _think_ I know a little more about this now... kqemu itself > doesn't use the fpu, but the guest code it runs can, and in that case the > DNA trap is just used for (host) lazy fpu context switching like as if the > code was running in userland regularly. And I just tested the following > patch that should get rid of the message by calling fpudna/npxdna directly > (files/patch-fpucontext is the interesting part:) This seems reasonable. Is the following summary of my understanding of kqemu's implementation of this and your change correct?: - kqemu runs in kernel mode on the host and needs to have exactly the same effect as a DNA exception on the target. - having exactly the same effect requires calling the host DNA exception handler. - now it uses a software int $7 (dna) to implement the above, but this is not permitted in kernel mode (although the software int could be permitted, it is hard to distinguish from a hardware exception for unintentional use). - your change makes it call the DNA trap handler directly. This gives the same effect as a permitted software int $7. It is also faster. It would be better to use an official API for this, but none exists. > ... > +Index: kqemu-freebsd.c > +@@ -33,6 +33,11 @@ > + > + #include > + #include > ++#ifdef __x86_64__ > ++#include > ++#else > ++#include > ++#endif > + > + #include "kqemu-kernel.h" > + > +@@ -172,6 +177,15 @@ > + { > + } > + > ++void CDECL kqemu_loadfpucontext(unsigned long cpl) > ++{ > ++#ifdef __x86_64__ > ++ fpudna(); > ++#else > ++ npxdna(); > ++#endif > ++} Just be sure that the system state is not too different from that of trap() (directly below a syscall or trap from userland) when this is called. Better not have any interrupts disabled or locks held, though I think npxdna() doesn't care. The FPU must not be owned already at this point. > ++ > + #if __FreeBSD_version < 500000 > + static int > + curpriority_cmp(struct proc *p) I guess kqemu duplicates this old mistake instead of calling it because it is static. npxdna() is already public so it can be abused easily :-), Bruce From rdivacky at freebsd.org Sat May 10 15:46:41 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sat May 10 15:46:45 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: References: <20080508170819.GA68720@freebsd.org> <20080508172503.GA69463@freebsd.org> <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> <20080510105008.GA71225@freebsd.org> Message-ID: <20080510154605.GA83247@freebsd.org> On Sat, May 10, 2008 at 03:30:07AM +0400, Chagin Dmitry wrote: > On Sat, 10 May 2008, Roman Divacky wrote: > > >On Fri, May 09, 2008 at 07:02:05PM +0400, Chagin Dmitry wrote: > >> > >>hi. > >> > >>Recently with Roman have decided to make emulation linux-x86-64. > >>Here a patch: http://81.200.6.196/linux-x86-64.diff.tar.gz > > > >witten ~# fetch http://81.200.6.196/linux-x86-64.diff.tar.gz > >fetch: http://81.200.6.196/linux-x86-64.diff.tar.gz: No route to host > > > > you have got at that time when i reloaded a server with a new kernel and > have flow on a panic :) (bad malloc/free in re0 probably - i see later) > now all works if you need an account for hosting patches etc. just ask me.. I'll provide one (in .cz so RTT should be reasonable even for online work) > > > >Dmitry has fixed this (a wrong AUX entry). I think we should sponsor > >him with a p4 account... > > > > now /compat/linux/bin/pwd exited without SIGSEGV, but on former can't > load libc please... post more technical details if you want us to help you. if you mean this as "blog" entry only it's fine as it is :) but I suggest to establish an official blog (ask flz@ about one) for this announcements :) anyway... impressive work! roman From rdivacky at freebsd.org Sat May 10 20:59:18 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sat May 10 20:59:22 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: References: <20080508170819.GA68720@freebsd.org> <20080508172503.GA69463@freebsd.org> <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> <20080510105008.GA71225@freebsd.org> Message-ID: <20080510205833.GA29591@freebsd.org> > now /compat/linux/bin/pwd exited without SIGSEGV, but on former can't > load libc I think you have wrong AUX entries... please take a look at netbsd source sys/compat/linux/arch/amd64/linux_exec_machdep.c around line 180... I believe they have it correct. Also, dont define LINUX_CLOCK_PER_SEC to be 100 but use "hz" instead. geeee. I wish you already have the p4 account :) From bsd at kuehlbox.de Sat May 10 21:01:46 2008 From: bsd at kuehlbox.de (Teufel) Date: Sat May 10 21:01:51 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080509220922.GA13480@saturn.kn-bremen.de> References: <20080507162713.73A3A5B47@mail.bitblocks.com> <20080508195843.G17500@delplex.bde.org> <20080509220922.GA13480@saturn.kn-bremen.de> Message-ID: <48260CF7.5050700@kuehlbox.de> > Okay I _think_ I know a little more about this now... kqemu itself > doesn't use the fpu, but the guest code it runs can, and in that case the > DNA trap is just used for (host) lazy fpu context switching like as if the > code was running in userland regularly. And I just tested the following > patch that should get rid of the message by calling fpudna/npxdna directly > (files/patch-fpucontext is the interesting part:) Applied the patch today and I can confirm, there are no more dna messages as expected. A win2k3 guest runs now couple of hours with some stress test and the kernel is still fine. I think this patch solves the broken kqemu on amd64. Great work. From chagin.dmitry at gmail.com Sat May 10 21:12:20 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Sat May 10 21:12:24 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: <20080510154605.GA83247@freebsd.org> References: <20080508170819.GA68720@freebsd.org> <20080508172503.GA69463@freebsd.org> <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> <20080510105008.GA71225@freebsd.org> <20080510154605.GA83247@freebsd.org> Message-ID: On Sat, 10 May 2008, Roman Divacky wrote: >> now /compat/linux/bin/pwd exited without SIGSEGV, but on former can't >> load libc > > please... post more technical details if you want us to help you. if you > mean this as "blog" entry only it's fine as it is :) but I suggest to > establish an official blog (ask flz@ about one) for this announcements :) > ooo, no blog ) about technical details: now problem in getdents syscall's family trace of ldconfig look like this kernel: linux(26702): open(/lib, 0x90800, 0x6bdae0) kernel: linux(26702): open returns error 0 kernel: retval[0]: 0x3 / 3 kernel: linux(26702): newfstat(3, *) kernel: retval[0]: 0x0 / 0 kernel: linux(26702): fcntl(3, 00000001, *) kernel: retval[0]: 0x0 / 0 kernel: linux(26702): fcntl(3, 00000002, *) kernel: retval[0]: 0x0 / 0 kernel: linux(26702): getdents(3, *, 8192) kernel: retval[0]: 0x88 / 136 kernel: trap! kernel: frame->tf_trapno: 0x12 kernel: frame->tf_rip: 0x420608 kernel: frame->tf_rcx: 0x4205e5 kernel: frame->tf_rsp: 0x7fffffffd810 kernel: frame->tf_rbp: 0xffe00 kernel: frame->tf_rbx: 0x6cdbf0 kernel: frame->tf_rax: 0x88 kernel: frame->tf_addr: 0xffe10 ups ))) kernel: frame->tf_cs: 0x2b kernel: frame->tf_ss: 0x23 -------> here we are die 420608: 0f b7 45 10 movzwl 0x10(%rbp),%eax 42060c: 48 8d 5d 12 lea 0x12(%rbp),%rbx 420610: 48 89 df mov %rbx,%rdi this code is in function search_dir in elf/ldconfig.c (glibc) here i think that is it :) -- Have fun! chd From chagin.dmitry at gmail.com Sat May 10 21:16:48 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Sat May 10 21:16:52 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: <20080510205833.GA29591@freebsd.org> References: <20080508170819.GA68720@freebsd.org> <20080508172503.GA69463@freebsd.org> <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> <20080510105008.GA71225@freebsd.org> <20080510205833.GA29591@freebsd.org> Message-ID: On Sat, 10 May 2008, Roman Divacky wrote: >> now /compat/linux/bin/pwd exited without SIGSEGV, but on former can't >> load libc > > I think you have wrong AUX entries... please take a look at netbsd source > > sys/compat/linux/arch/amd64/linux_exec_machdep.c i fix all at the morning - i shall update patch, it's outdated > > around line 180... I believe they have it correct. Also, dont define > LINUX_CLOCK_PER_SEC to be 100 but use "hz" instead. thnx :) shall know now > > geeee. I wish you already have the p4 account :) no, it's git-diff :) -- Have fun! chd From rdivacky at freebsd.org Sat May 10 21:20:31 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sat May 10 21:20:35 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: References: <20080508172503.GA69463@freebsd.org> <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> <20080510105008.GA71225@freebsd.org> <20080510154605.GA83247@freebsd.org> Message-ID: <20080510211951.GA31390@freebsd.org> On Sun, May 11, 2008 at 01:12:25AM +0400, Chagin Dmitry wrote: > On Sat, 10 May 2008, Roman Divacky wrote: > > >>now /compat/linux/bin/pwd exited without SIGSEGV, but on former can't > >>load libc > > > >please... post more technical details if you want us to help you. if you > >mean this as "blog" entry only it's fine as it is :) but I suggest to > >establish an official blog (ask flz@ about one) for this announcements :) > > > > ooo, no blog ) > about technical details: > now problem in getdents syscall's family > trace of ldconfig look like this > > kernel: linux(26702): open(/lib, 0x90800, 0x6bdae0) > kernel: linux(26702): open returns error 0 > kernel: retval[0]: 0x3 / 3 > kernel: linux(26702): newfstat(3, *) > kernel: retval[0]: 0x0 / 0 > kernel: linux(26702): fcntl(3, 00000001, *) > kernel: retval[0]: 0x0 / 0 > kernel: linux(26702): fcntl(3, 00000002, *) > kernel: retval[0]: 0x0 / 0 > kernel: linux(26702): getdents(3, *, 8192) > kernel: retval[0]: 0x88 / 136 > > kernel: trap! > kernel: frame->tf_trapno: 0x12 + 0, /* 18 T_DIVIDE */ how can integer divide trap happen in "movzwl"? Are trap numbers the same on i386 and on amd64? is this machine-dependant or os-dependant? From rdivacky at freebsd.org Sat May 10 21:21:42 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sat May 10 21:21:49 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: References: <20080508172503.GA69463@freebsd.org> <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> <20080510105008.GA71225@freebsd.org> <20080510205833.GA29591@freebsd.org> Message-ID: <20080510212059.GB31390@freebsd.org> On Sun, May 11, 2008 at 01:16:56AM +0400, Chagin Dmitry wrote: > On Sat, 10 May 2008, Roman Divacky wrote: > > >>now /compat/linux/bin/pwd exited without SIGSEGV, but on former can't > >>load libc > > > >I think you have wrong AUX entries... please take a look at netbsd source > > > > sys/compat/linux/arch/amd64/linux_exec_machdep.c > > i fix all at the morning - i shall update patch, it's outdated please version the patches.... ie. linux-foo.1.patch, linux-foo.2.patch etc. > > > >around line 180... I believe they have it correct. Also, dont define > >LINUX_CLOCK_PER_SEC to be 100 but use "hz" instead. > > thnx :) shall know now just a small nit :) > > > >geeee. I wish you already have the p4 account :) > > no, it's git-diff :) I mean... I could comment every commit :) From rdivacky at freebsd.org Sat May 10 21:32:19 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Sat May 10 21:32:22 2008 Subject: [patch] linux-x86-64 (for comments) In-Reply-To: <20080510211951.GA31390@freebsd.org> References: <20080508195310.GA74606@freebsd.org> <20080508210641.GA81647@freebsd.org> <20080510105008.GA71225@freebsd.org> <20080510154605.GA83247@freebsd.org> <20080510211951.GA31390@freebsd.org> Message-ID: <20080510213134.GA31988@freebsd.org> On Sat, May 10, 2008 at 11:19:51PM +0200, Roman Divacky wrote: > On Sun, May 11, 2008 at 01:12:25AM +0400, Chagin Dmitry wrote: > > On Sat, 10 May 2008, Roman Divacky wrote: > > > > >>now /compat/linux/bin/pwd exited without SIGSEGV, but on former can't > > >>load libc > > > > > >please... post more technical details if you want us to help you. if you > > >mean this as "blog" entry only it's fine as it is :) but I suggest to > > >establish an official blog (ask flz@ about one) for this announcements :) > > > > > > > ooo, no blog ) > > about technical details: > > now problem in getdents syscall's family > > trace of ldconfig look like this > > > > kernel: linux(26702): open(/lib, 0x90800, 0x6bdae0) > > kernel: linux(26702): open returns error 0 > > kernel: retval[0]: 0x3 / 3 > > kernel: linux(26702): newfstat(3, *) > > kernel: retval[0]: 0x0 / 0 > > kernel: linux(26702): fcntl(3, 00000001, *) > > kernel: retval[0]: 0x0 / 0 > > kernel: linux(26702): fcntl(3, 00000002, *) > > kernel: retval[0]: 0x0 / 0 > > kernel: linux(26702): getdents(3, *, 8192) > > kernel: retval[0]: 0x88 / 136 > > > > kernel: trap! > > kernel: frame->tf_trapno: 0x12 > > + 0, /* 18 T_DIVIDE */ > > how can integer divide trap happen in "movzwl"? Are trap numbers > the same on i386 and on amd64? is this machine-dependant or os-dependant? nevermind the previous. I slept only 3 hours last night ;) take a look at arch/x86_64/kernel/traps.c around line 541 (linux 2.6.16) it defines trap 18 to be "reserved" and intstructs the kernel to send a SIGSEGV signal to the process... no idea why :) please fix all the issues we have found a fix for and report back what's going on thnx! roman From nox at jelal.kn-bremen.de Sun May 11 10:48:29 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun May 11 10:48:32 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <20080510213519.P3083@besplex.bde.org> References: <20080507162713.73A3A5B47@mail.bitblocks.com> <20080508195843.G17500@delplex.bde.org> <20080509220922.GA13480@saturn.kn-bremen.de> <20080510213519.P3083@besplex.bde.org> Message-ID: <20080511103356.GA30088@saturn.kn-bremen.de> On Sat, May 10, 2008 at 10:28:53PM +1000, Bruce Evans wrote: > On Sat, 10 May 2008, Juergen Lock wrote: > >> On Thu, May 08, 2008 at 09:59:57PM +1000, Bruce Evans wrote: >>> The message in amd64/machdep.c is about violation of the invariant >>> that the kernel cannot cause DNA traps. Spurious DNA traps in the >>> ... >>> >> Okay I _think_ I know a little more about this now... kqemu itself >> doesn't use the fpu, but the guest code it runs can, and in that case the >> DNA trap is just used for (host) lazy fpu context switching like as if the >> code was running in userland regularly. And I just tested the following >> patch that should get rid of the message by calling fpudna/npxdna directly >> (files/patch-fpucontext is the interesting part:) > > This seems reasonable. Is the following summary of my understanding of > kqemu's implementation of this and your change correct?: > - kqemu runs in kernel mode on the host and needs to have exactly the > same effect as a DNA exception on the target. > - having exactly the same effect requires calling the host DNA exception > handler. > - now it uses a software int $7 (dna) to implement the above, but this is > not permitted in kernel mode (although the software int could be > permitted, > it is hard to distinguish from a hardware exception for unintentional > use). > - your change makes it call the DNA trap handler directly. This gives the > same effect as a permitted software int $7. It is also faster. > Yup thats basically it. > It would be better to use an official API for this, but none exists. > :) >> ... >> +Index: kqemu-freebsd.c >> +@@ -33,6 +33,11 @@ >> + >> + #include >> + #include >> ++#ifdef __x86_64__ >> ++#include >> ++#else >> ++#include >> ++#endif >> + >> + #include "kqemu-kernel.h" >> + >> +@@ -172,6 +177,15 @@ >> + { >> + } >> + >> ++void CDECL kqemu_loadfpucontext(unsigned long cpl) >> ++{ >> ++#ifdef __x86_64__ >> ++ fpudna(); >> ++#else >> ++ npxdna(); >> ++#endif >> ++} > > Just be sure that the system state is not too different from that of > trap() (directly below a syscall or trap from userland) when this is > called. Better not have any interrupts disabled or locks held, though > I think npxdna() doesn't care. The FPU must not be owned already at > this point. > Yes, all of that is true. >> ++ >> + #if __FreeBSD_version < 500000 >> + static int >> + curpriority_cmp(struct proc *p) > > I guess kqemu duplicates this old mistake instead of calling it because it > is static. npxdna() is already public so it can be abused easily :-), Well this (curpriority_cmp) is code for 4.x anyway. (Yes I guess I could axe it, but maybe there are still some poor souls out there that still need it...) Juergen From nox at jelal.kn-bremen.de Sun May 11 11:03:38 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun May 11 11:03:41 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test patch :) In-Reply-To: <48260CF7.5050700@kuehlbox.de> References: <20080507162713.73A3A5B47@mail.bitblocks.com> <20080508195843.G17500@delplex.bde.org> <20080509220922.GA13480@saturn.kn-bremen.de> <48260CF7.5050700@kuehlbox.de> Message-ID: <20080511110122.GA31223@saturn.kn-bremen.de> On Sat, May 10, 2008 at 11:00:39PM +0200, Teufel wrote: > >> Okay I _think_ I know a little more about this now... kqemu itself >> doesn't use the fpu, but the guest code it runs can, and in that case the >> DNA trap is just used for (host) lazy fpu context switching like as if the >> code was running in userland regularly. And I just tested the following >> patch that should get rid of the message by calling fpudna/npxdna directly >> (files/patch-fpucontext is the interesting part:) > Applied the patch today and I can confirm, there are no more dna messages > as expected. A win2k3 guest runs now couple of hours with some stress test > and the kernel is still fine. I think this patch solves the broken kqemu on > amd64. Great work. Thanx! :) And I just committed the update. Juergen From nox at jelal.kn-bremen.de Sun May 11 16:09:32 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun May 11 16:09:36 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) In-Reply-To: <200805011335.06415.jhb@freebsd.org> References: <20080429222458.GA20855@saturn.kn-bremen.de> <200805011011.06951.jhb@freebsd.org> <20080501155304.GB2940@saturn.kn-bremen.de> <200805011335.06415.jhb@freebsd.org> Message-ID: <20080511160748.GA38480@saturn.kn-bremen.de> On Thu, May 01, 2008 at 01:35:06PM -0400, John Baldwin wrote: > On Thursday 01 May 2008 11:53:04 am Juergen Lock wrote: > > On Thu, May 01, 2008 at 10:11:06AM -0400, John Baldwin wrote: > > > On Thursday 01 May 2008 06:19:51 am Juergen Lock wrote: > > > > On Wed, Apr 30, 2008 at 12:24:58AM +0200, Juergen Lock wrote: > > > > > Yeah, the amd64 kernel reuses the same gdt to setup all cpus, causing > > > > > kqemu to end up restoring the interrupt stackpointer (after running > > > > > guest code using its own cpu state) from the tss of the last cpu, > > > > > regardless which cpu it happened to run on. And that then causes the > > > > > last cpu's (usually) idle thread's stack to get smashed and the host > > > > > doing multiple panics... (Which also explains why pinning qemu onto > cpu > > > > > 1 worked on a 2-way host.) > > > > > > > > Hmm maybe the following is a little more clear: kqemu sets up its own > > > > cpu state and has to save and restore the original state because of > that, > > > > so among other things it does an str insn (store task register), and > later > > > > an ltr insn (load task register) using the value it got from the first > > > > str insn. That ltr insn loads the selector for the tss which is stored > > > > in the gdt, and that entry in the gdt is different for each cpu, but > since > > > > a single gdt was reused to setup the cpus at boot (in init_secondary() > in > > > > /sys/amd64/amd64/mp_machdep.c), it still points to the tss for the last > > > > cpu, instead of to the right one for the cpu the ltr insn gets executed > on. > > > > That is what the kqemu_tss_workaround() in the patch `fixes'... > > > > > > Perhaps kqemu shouldn't be doing str/ltr on amd64 instead? The things > i386 > > > uses a separate tss for in the kernel (separate stack for double faults) > is > > > handled differently on amd64 (on amd64 we make the double fault handler > use > > > one of the IST stacks). > > > > Well, kqemu uses its own gdt, tss and everything while running guest code > > in its monitor, so it kinda has to do the str/ltr.s to setup its stuff, run > > guest code, and then restore the original state of things. (And `restore > > original state of things' is what failed here.) > > > > Oh and also the tss does seem to be used for the interrupt stack on > > amd64 too, at least thats the one that ended up wrong and caused the panics > > I saw... > > The single TSS holds the IST pointers. On i386 we use a separate TSS for > double faults, but on amd64 a double fault uses the same TSS but uses the IST > pointers from that same TSS. The TSS also holds the ring stack pointer for > when syscalls, interrupts, and traps from userland cross from ring 3 to ring > 0 which is probably why you got a panic. > > Because of the fact that amd64 in normal operation never changes the task > register (and that the gdt isn't used quite the same either, all the per-cpu > stuff is via FSBASE and GSBASE) I don't expect the kernel to change to use a > per-cpu gdt or the like. I think you will need to use the current approach > of patching kqemu to fixup the tss/gdt when reloading the task register. You > might want to make it a regular part of the code rather than a workaround as > a result. Ok I renamed the function now. I was mad aware of another problem tho, (hi Yamagi! :) - running multiple qemu instances can still panic/reboot the box probably because the hardware does some lazy evaluation/loading (or maybe its a cache coherency issue?), so I thought it was safer to use seperate per-cpu gdts after all. The following patch survived a quick test that the old version didn't (two 7.0-livefs guests running find /dist in fixit), tho I'm not sure about the correctness of the values I used to reload MSR_KGSBASE and MSR_FSBASE after lgdt() (anyone here know offhand? Yeah I could just save/reload them like the rest of the code does, but if they can be set from available data instead...) Here comes the patch (also at http://people.freebsd.org/~nox/qemu/kqemu-kmod-tss-cpldt.patch ) Index: Makefile =================================================================== RCS file: /home/pcvs/ports/emulators/kqemu-kmod/Makefile,v retrieving revision 1.24 diff -u -p -r1.24 Makefile --- Makefile 11 May 2008 10:59:20 -0000 1.24 +++ Makefile 11 May 2008 15:06:08 -0000 @@ -7,7 +7,7 @@ PORTNAME= kqemu PORTVERSION= 1.3.0.p11 -PORTREVISION= 5 +PORTREVISION= 6 CATEGORIES= emulators kld MASTER_SITES= http://fabrice.bellard.free.fr/qemu/ \ http://qemu.org/ \ Index: files/patch-tssworkaround =================================================================== RCS file: /home/pcvs/ports/emulators/kqemu-kmod/files/patch-tssworkaround,v retrieving revision 1.2 diff -u -p -r1.2 patch-tssworkaround --- files/patch-tssworkaround 11 May 2008 10:59:20 -0000 1.2 +++ files/patch-tssworkaround 11 May 2008 15:08:41 -0000 @@ -1,29 +1,70 @@ Index: kqemu-freebsd.c -@@ -38,6 +38,11 @@ +@@ -38,6 +38,14 @@ #else #include #endif +#ifdef __x86_64__ ++#include +#include ++#include ++#include +#include +#include +#endif #include "kqemu-kernel.h" -@@ -248,6 +253,19 @@ +@@ -248,6 +256,57 @@ va_end(ap); } +#ifdef __x86_64__ ++int kqemu_cpu0gdtfixed; ++int kqemu_gdts_used; ++struct user_segment_descriptor *kqemu_gdts; ++struct region_descriptor kqemu_r_newgdt; ++extern struct pcpu __pcpu[]; ++ +/* called with interrupts disabled */ -+void CDECL kqemu_tss_fixup(void) ++void CDECL kqemu_tss_fixup(unsigned long kerngdtbase) +{ + int gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); ++ unsigned cpuid = PCPU_GET(cpuid); ++ struct user_segment_descriptor *newgdt = gdt; + -+ gdt_segs[GPROC0_SEL].ssd_base = (long) &common_tss[PCPU_GET(cpuid)]; ++ if (mp_ncpus <= 1 || kerngdtbase != (unsigned long)&gdt) ++ /* UP host or gdt already moved, nothing to do */ ++ return; ++ if (cpuid) { ++ /* move gdts of all but first cpu */ ++ if (!kqemu_gdts) ++ /* ++ * XXX gdt is allocated as ++ * struct user_segment_descriptor gdt[NGDT * MAXCPU]; ++ * so it has room for the moved copies; need to allocate at ++ * kldload (and only free if kqemu_gdts_used is zero) should this ++ * change in the future ++ */ ++ kqemu_gdts = &gdt[NGDT]; ++ ++kqemu_gdts_used; ++ newgdt = &kqemu_gdts[NGDT * (cpuid - 1)]; ++ bcopy(&gdt, newgdt, NGDT * sizeof(gdt[0])); ++ kqemu_r_newgdt.rd_limit = NGDT * sizeof(gdt[0]) - 1; ++ kqemu_r_newgdt.rd_base = (long) newgdt; ++ } else { ++ if (kqemu_cpu0gdtfixed) ++ return; ++ ++kqemu_cpu0gdtfixed; ++ } ++ gdt_segs[GPROC0_SEL].ssd_base = (long) &common_tss[cpuid]; + ssdtosyssd(&gdt_segs[GPROC0_SEL], -+ (struct system_segment_descriptor *)&gdt[GPROC0_SEL]); ++ (struct system_segment_descriptor *)&newgdt[GPROC0_SEL]); ++ if (cpuid) { ++ lgdt(&kqemu_r_newgdt); ++ wrmsr(MSR_GSBASE, (u_int64_t)&__pcpu[cpuid]); ++ wrmsr(MSR_KGSBASE, curthread->td_pcb->pcb_gsbase); ++ wrmsr(MSR_FSBASE, 0); ++ } + ltr(gsel_tss); +} +#endif @@ -49,7 +90,7 @@ Index: common/kernel.c +#ifdef __FreeBSD__ +#ifdef __x86_64__ + spin_lock(&g->lock); -+ kqemu_tss_fixup(); ++ kqemu_tss_fixup(s->kernel_gdt.base); + spin_unlock(&g->lock); +#endif +#endif @@ -57,13 +98,13 @@ Index: common/kernel.c if (s->mon_req == MON_REQ_IRQ) { struct kqemu_exception_regs *r; Index: kqemu-kernel.h -@@ -44,4 +44,10 @@ +@@ -48,4 +48,10 @@ void CDECL kqemu_log(const char *fmt, ...); +#ifdef __FreeBSD__ +#ifdef __x86_64__ -+void CDECL kqemu_tss_fixup(void); ++void CDECL kqemu_tss_fixup(unsigned long kerngdtbase); +#endif +#endif + From bakul at bitblocks.com Sun May 11 19:27:46 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Sun May 11 19:27:49 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) In-Reply-To: Your message of "Sun, 11 May 2008 18:07:48 +0200." <20080511160748.GA38480@saturn.kn-bremen.de> Message-ID: <20080511192745.6F3625B4D@mail.bitblocks.com> Juergen, With your latest patch things are looking pretty good! - Multiple qemus on a MP FreeBSD amd64 works with kqemu enabled for user code. Some running 64 bit kernels (freebsd), some running 32 bit kernels (freebsd and plan9). - Nested qemus work! That is, qemu*x86_64 under qemu*x86_64, both with user mode kqemu. A 32 bit 7.0 kernel under it ran fine. Ideally qemus should nest as long as there is enough memory (a torture test for emulation fidelity). - As mentioned in another thread netbooting works well enough but you have to use pxeboot from -current and append a byte to it to work around an etherboot tftp bug. Now the bugs (probably most having to do with qemu/kqemu, not the freebsd port): 1. kernel mode kqemu seems to cause crashes. Generally this happens right after the guest freebsd kernel comes up. 2. After the above crash VM reboots automatically but now it can't find the root device so it hangs at the root selection prompt. 3. Ocassionally plan9 and (less often FreeBSD) crashes on boot. Looks like a race condition of some sort. If they boot, there are no further problems traceable to qemu/kqemu. 4. "calcru: runtime went backwards from usec to for pid ()" is back! Also, ntpd seems to get very confused and after syncing with another clock shifts mostly correct time by a few hours. 5. An initial getty gets killed as it "exceeded maximum CPU limit" This could an emulation bug or related to time issues. Random thoughts: - If qemu is made scriptable we can automate a lot of testing. For qemu/kqemu and freebsd. - We need to add a section on qemu in the handbook. From kostikbel at gmail.com Sun May 11 19:33:14 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun May 11 19:33:19 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) In-Reply-To: <20080511192745.6F3625B4D@mail.bitblocks.com> References: <20080511160748.GA38480@saturn.kn-bremen.de> <20080511192745.6F3625B4D@mail.bitblocks.com> Message-ID: <20080511193302.GA18958@deviant.kiev.zoral.com.ua> On Sun, May 11, 2008 at 12:27:45PM -0700, Bakul Shah wrote: > Juergen, > > With your latest patch things are looking pretty good! > > - Multiple qemus on a MP FreeBSD amd64 works with kqemu > enabled for user code. Some running 64 bit kernels > (freebsd), some running 32 bit kernels (freebsd and plan9). > > - Nested qemus work! That is, qemu*x86_64 under qemu*x86_64, > both with user mode kqemu. A 32 bit 7.0 kernel under it ran > fine. Ideally qemus should nest as long as there is enough > memory (a torture test for emulation fidelity). > > - As mentioned in another thread netbooting works well enough > but you have to use pxeboot from -current and append a byte > to it to work around an etherboot tftp bug. > > Now the bugs (probably most having to do with qemu/kqemu, > not the freebsd port): > > 1. kernel mode kqemu seems to cause crashes. Generally this > happens right after the guest freebsd kernel comes up. > > 2. After the above crash VM reboots automatically but now it > can't find the root device so it hangs at the root > selection prompt. > > 3. Ocassionally plan9 and (less often FreeBSD) crashes on > boot. Looks like a race condition of some sort. If they > boot, there are no further problems traceable to > qemu/kqemu. > > 4. "calcru: runtime went backwards from usec to for > pid ()" is back! Also, ntpd seems to get very > confused and after syncing with another clock shifts > mostly correct time by a few hours. > > 5. An initial getty gets killed as it "exceeded maximum CPU limit" > This could an emulation bug or related to time issues. The #5 usually means the thread' kernel stack overflow. > > Random thoughts: > - If qemu is made scriptable we can automate a lot of > testing. For qemu/kqemu and freebsd. > > - We need to add a section on qemu in the handbook. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080511/293b2393/attachment.pgp From nox at jelal.kn-bremen.de Sun May 11 21:09:55 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun May 11 21:09:59 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) In-Reply-To: <20080511193302.GA18958@deviant.kiev.zoral.com.ua> References: <20080511160748.GA38480@saturn.kn-bremen.de> <20080511192745.6F3625B4D@mail.bitblocks.com> <20080511193302.GA18958@deviant.kiev.zoral.com.ua> Message-ID: <20080511210759.GB46475@saturn.kn-bremen.de> On Sun, May 11, 2008 at 10:33:02PM +0300, Kostik Belousov wrote: > On Sun, May 11, 2008 at 12:27:45PM -0700, Bakul Shah wrote: > > [...] > > 5. An initial getty gets killed as it "exceeded maximum CPU limit" > > This could an emulation bug or related to time issues. > The #5 usually means the thread' kernel stack overflow. > Oh I didn't know that. You could test a kernel with KSTACK_PAGES increased to verify... Juergen From nox at jelal.kn-bremen.de Sun May 11 21:09:55 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun May 11 21:10:04 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) In-Reply-To: <20080511192745.6F3625B4D@mail.bitblocks.com> References: <20080511160748.GA38480@saturn.kn-bremen.de> <20080511192745.6F3625B4D@mail.bitblocks.com> Message-ID: <20080511210518.GA46475@saturn.kn-bremen.de> On Sun, May 11, 2008 at 12:27:45PM -0700, Bakul Shah wrote: > Juergen, > > With your latest patch things are looking pretty good! > > - Multiple qemus on a MP FreeBSD amd64 works with kqemu > enabled for user code. Some running 64 bit kernels > (freebsd), some running 32 bit kernels (freebsd and plan9). > > - Nested qemus work! That is, qemu*x86_64 under qemu*x86_64, > both with user mode kqemu. A 32 bit 7.0 kernel under it ran > fine. Ideally qemus should nest as long as there is enough > memory (a torture test for emulation fidelity). > > - As mentioned in another thread netbooting works well enough > but you have to use pxeboot from -current and append a byte > to it to work around an etherboot tftp bug. > > Now the bugs (probably most having to do with qemu/kqemu, > not the freebsd port): > > 1. kernel mode kqemu seems to cause crashes. Generally this > happens right after the guest freebsd kernel comes up. > Yeah I posted one of those on the qemu list, http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00233.html 32 bit linux guests seem to work fine tho at least. > 2. After the above crash VM reboots automatically but now it > can't find the root device so it hangs at the root > selection prompt. > Hmm. > 3. Ocassionally plan9 and (less often FreeBSD) crashes on > boot. Looks like a race condition of some sort. If they > boot, there are no further problems traceable to > qemu/kqemu. > Hmm. > 4. "calcru: runtime went backwards from usec to for > pid ()" is back! Well, the clock never was very accurate thats true... > Also, ntpd seems to get very > confused and after syncing with another clock shifts > mostly correct time by a few hours. > Ouch. > 5. An initial getty gets killed as it "exceeded maximum CPU limit" > This could an emulation bug or related to time issues. > > Random thoughts: > - If qemu is made scriptable we can automate a lot of > testing. For qemu/kqemu and freebsd. > Hmm what exactly do you want to script there? > - We need to add a section on qemu in the handbook. Hmmm... :) Juergen From bakul at bitblocks.com Sun May 11 23:51:40 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Sun May 11 23:51:43 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) In-Reply-To: Your message of "Sun, 11 May 2008 23:05:18 +0200." <20080511210518.GA46475@saturn.kn-bremen.de> Message-ID: <20080511235139.C9ECD5B58@mail.bitblocks.com> On Sun, 11 May 2008 23:05:18 +0200 Juergen Lock wrote: > > 4. "calcru: runtime went backwards from usec to for > > pid ()" is back! > > Well, the clock never was very accurate thats true... Simulated time will be slower than the real time by some indeterminate amount but still all times ought to be monotonically increasing. > > Random thoughts: > > - If qemu is made scriptable we can automate a lot of > > testing. For qemu/kqemu and freebsd. > > > Hmm what exactly do you want to script there? I don't have an "exact" idea but lots of vague ideas that need fleshing out! Ideally, after every significant update, all the useful qemu options get automatically tested. For that you need to be able to control qemu's operation (and the guest OS!) and capture useful information in case of bugs or crashes. Right now you can emulate keyboard input via qemu's monitor interface but you don't know how the guest OS reacts to it. May be even snapshotting the console display to a .png file on certain conditions can be very useful. You want to be able run a test manually and create an automated script from it (e.g. when I run these set of things, this is what the screen looks like except for that rectangle in the bottom right corner!). And this has to happen relative to the qemu's virtual time. For testing a guest OS such as FreeBSD, one would like to bootstrap a freshly built kernel and run a variety automated tests against it. In case of the OS crashing you capture backtrace, save the memory image in a dump file and contiue testing. Doing this after a real machine crash is much more painful. With qemu (or vmware) you just start up a whole bunch of virtual machines (depending on available resources) and do testing in parallel. All testing is repetitious so it needs to be automated. > > - We need to add a section on qemu in the handbook. > > Hmmm... :) You just need to extend chapter 21 on Virtualization that already talks about vmware, parallels, xen and virual PC. :-) From bugmaster at FreeBSD.org Mon May 12 11:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 12 11:06:59 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200805121106.m4CB6swW037964@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/117010 emulation [linux] linux_getdents() get something like buffer ove 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/41543 emulation [patch] [request] easier wine/w23 support a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s f kern/73777 emulation [linux] [patch] linux emulation: root dir special hand o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/122318 emulation [linux] [cmake]: Segmentation fault when running Linux 10 problems total. From nox at jelal.kn-bremen.de Mon May 12 19:35:21 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Mon May 12 19:35:24 2008 Subject: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) In-Reply-To: <20080511235139.C9ECD5B58@mail.bitblocks.com> References: <20080511210518.GA46475@saturn.kn-bremen.de> <20080511235139.C9ECD5B58@mail.bitblocks.com> Message-ID: <20080512193101.GB11046@saturn.kn-bremen.de> On Sun, May 11, 2008 at 04:51:39PM -0700, Bakul Shah wrote: > On Sun, 11 May 2008 23:05:18 +0200 Juergen Lock wrote: > > > 4. "calcru: runtime went backwards from usec to for > > > pid ()" is back! > > > > Well, the clock never was very accurate thats true... > > Simulated time will be slower than the real time by some > indeterminate amount but still all times ought to be > monotonically increasing. > Yeah not sure what kind of weird interaction causes this... > > > Random thoughts: > > > - If qemu is made scriptable we can automate a lot of > > > testing. For qemu/kqemu and freebsd. > > > > > Hmm what exactly do you want to script there? > > I don't have an "exact" idea but lots of vague ideas that need > fleshing out! > > Ideally, after every significant update, all the useful qemu > options get automatically tested. For that you need to be > able to control qemu's operation (and the guest OS!) and > capture useful information in case of bugs or crashes. Right > now you can emulate keyboard input via qemu's monitor > interface but you don't know how the guest OS reacts to it. > May be even snapshotting the console display to a .png file > on certain conditions can be very useful. Well you can use -nographic with a guest configured for serial console, then you have the guest on qemu's tty. (Ok this doesn't help much when you want to test under X, maybe there are special vnc clients for that, dunno...) > You want to be > able run a test manually and create an automated script from > it (e.g. when I run these set of things, this is what the > screen looks like except for that rectangle in the bottom > right corner!). And this has to happen relative to the > qemu's virtual time. > Hmm. > For testing a guest OS such as FreeBSD, one would like to > bootstrap a freshly built kernel and run a variety automated > tests against it. In case of the OS crashing you capture > backtrace, save the memory image in a dump file and contiue > testing. Hmm, maybe use qemu's gdbstub, set breakpoints on panic and trap_fatal and do a bt when they are reached; maybe you can even script kgdb to do that, dunno... Oh and btw if you run from an image you can actually mdconfig that and then fsck it as /dev/md0s1a etc. - thats sure faster than having the guest do it. > Doing this after a real machine crash is much more > painful. With qemu (or vmware) you just start up a whole > bunch of virtual machines (depending on available resources) > and do testing in parallel. All testing is repetitious so it > needs to be automated. > > > > - We need to add a section on qemu in the handbook. > > > > Hmmm... :) > > You just need to extend chapter 21 on Virtualization that > already talks about vmware, parallels, xen and virual PC. :-) Yeah, one of these days I guess... :) Juergen From avg at icyb.net.ua Tue May 13 20:10:13 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue May 13 20:10:19 2008 Subject: gizmo: linux libgconf Message-ID: <4829E947.2090002@icyb.net.ua> Anybody tried to use Linux application from gizmo project on FreeBSD? http://gizmo5.com/pc/ http://gizmo5.com/pc/download/linux/ [this is something similar to skype but SIP based] List of dependencies is quite small, but it needs libgconf (GConf2) and I am not sure which port (if any) provides it. Any advice on how to proceed? Thank you! -- Andriy Gapon From avg at icyb.net.ua Tue May 13 20:29:05 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue May 13 20:29:10 2008 Subject: gizmo: linux libgconf In-Reply-To: <44zlquc68x.fsf@be-well.ilk.org> References: <4829E947.2090002@icyb.net.ua> <44zlquc68x.fsf@be-well.ilk.org> Message-ID: <4829FA07.2030900@icyb.net.ua> on 13/05/2008 23:13 Lowell Gilbert said the following: > Andriy Gapon writes: > >> Anybody tried to use Linux application from gizmo project on FreeBSD? >> http://gizmo5.com/pc/ >> http://gizmo5.com/pc/download/linux/ >> [this is something similar to skype but SIP based] > > And closed source. Could be more work than you expect. More closed than skype? :-) >> List of dependencies is quite small, but it needs libgconf (GConf2) >> and I am not sure which port (if any) provides it. > > devel/gconf2 That's native version, not Linux. >> Any advice on how to proceed? > > Try it and see what happens... Tried, (Linux) libgconf is not found. -- Andriy Gapon From avg at icyb.net.ua Tue May 13 20:30:13 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue May 13 20:30:16 2008 Subject: gizmo: linux libgconf In-Reply-To: References: <4829E947.2090002@icyb.net.ua> <44zlquc68x.fsf@be-well.ilk.org> Message-ID: <4829FA53.6070400@icyb.net.ua> on 13/05/2008 23:21 Jeremy Messenger said the following: > On Tue, 13 May 2008 15:13:18 -0500, Lowell Gilbert > wrote: > >> Andriy Gapon writes: >> >>> Anybody tried to use Linux application from gizmo project on FreeBSD? >>> http://gizmo5.com/pc/ >>> http://gizmo5.com/pc/download/linux/ >>> [this is something similar to skype but SIP based] >> >> And closed source. Could be more work than you expect. >> >>> List of dependencies is quite small, but it needs libgconf (GConf2) >>> and I am not sure which port (if any) provides it. >> >> devel/gconf2 > > I don't think it will working unless someone create a new linux-gconf2 > port. But I don't know if there will be problem(s) for linux-gconf2 and > gconf2 to be exist at the same time. I guess I could try to fetch a fedora package and try. I am just not sure how to install it properly, never worked on ports for Linux binaries before. > Cheers, > Mezz > >>> Any advice on how to proceed? >> >> Try it and see what happens... > > > -- Andriy Gapon From freebsd-ports-local at be-well.ilk.org Tue May 13 20:32:12 2008 From: freebsd-ports-local at be-well.ilk.org (Lowell Gilbert) Date: Tue May 13 20:32:28 2008 Subject: gizmo: linux libgconf In-Reply-To: <4829E947.2090002@icyb.net.ua> (Andriy Gapon's message of "Tue\, 13 May 2008 22\:17\:27 +0300") References: <4829E947.2090002@icyb.net.ua> Message-ID: <44zlquc68x.fsf@be-well.ilk.org> Andriy Gapon writes: > Anybody tried to use Linux application from gizmo project on FreeBSD? > http://gizmo5.com/pc/ > http://gizmo5.com/pc/download/linux/ > [this is something similar to skype but SIP based] And closed source. Could be more work than you expect. > List of dependencies is quite small, but it needs libgconf (GConf2) > and I am not sure which port (if any) provides it. devel/gconf2 > Any advice on how to proceed? Try it and see what happens... From mezz7 at cox.net Tue May 13 20:34:26 2008 From: mezz7 at cox.net (Jeremy Messenger) Date: Tue May 13 20:34:29 2008 Subject: gizmo: linux libgconf In-Reply-To: <44zlquc68x.fsf@be-well.ilk.org> References: <4829E947.2090002@icyb.net.ua> <44zlquc68x.fsf@be-well.ilk.org> Message-ID: On Tue, 13 May 2008 15:13:18 -0500, Lowell Gilbert wrote: > Andriy Gapon writes: > >> Anybody tried to use Linux application from gizmo project on FreeBSD? >> http://gizmo5.com/pc/ >> http://gizmo5.com/pc/download/linux/ >> [this is something similar to skype but SIP based] > > And closed source. Could be more work than you expect. > >> List of dependencies is quite small, but it needs libgconf (GConf2) >> and I am not sure which port (if any) provides it. > > devel/gconf2 I don't think it will working unless someone create a new linux-gconf2 port. But I don't know if there will be problem(s) for linux-gconf2 and gconf2 to be exist at the same time. Cheers, Mezz >> Any advice on how to proceed? > > Try it and see what happens... -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From vivek at khera.org Tue May 13 21:33:49 2008 From: vivek at khera.org (Vivek Khera) Date: Tue May 13 21:33:54 2008 Subject: gizmo: linux libgconf In-Reply-To: <4829E947.2090002@icyb.net.ua> References: <4829E947.2090002@icyb.net.ua> Message-ID: <43BDCE36-A9B5-4B6D-8CA1-FBFD2E84822C@khera.org> On May 13, 2008, at 3:17 PM, Andriy Gapon wrote: > [this is something similar to skype but SIP based] So you can use *any* SIP client with gizmo for voice, and for chat, any suitable XMPP (jabber) client. They even give you instructions on what server settings to use to tie into their service. Personally, I use a gizmo account with a dial-in number and a SIP adapter to a regular touch-tone phone, and my family doesn't even know they're using a VOIP line. The Gizmo client itself I find of little use other than to check call history and account balance, but that works on the web too, just not as nicely. From Alexander at Leidinger.net Wed May 14 05:36:52 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed May 14 05:36:56 2008 Subject: gizmo: linux libgconf In-Reply-To: <4829FA53.6070400@icyb.net.ua> References: <4829E947.2090002@icyb.net.ua> <44zlquc68x.fsf@be-well.ilk.org> <4829FA53.6070400@icyb.net.ua> Message-ID: <20080514073641.28185dk3mgg4pkw0@webmail.leidinger.net> Quoting Andriy Gapon (from Tue, 13 May 2008 23:30:11 +0300): > on 13/05/2008 23:21 Jeremy Messenger said the following: >> On Tue, 13 May 2008 15:13:18 -0500, Lowell Gilbert >> wrote: >> >>> Andriy Gapon writes: >>> >>>> Anybody tried to use Linux application from gizmo project on FreeBSD? >>>> http://gizmo5.com/pc/ >>>> http://gizmo5.com/pc/download/linux/ >>>> [this is something similar to skype but SIP based] >>> >>> And closed source. Could be more work than you expect. >>> >>>> List of dependencies is quite small, but it needs libgconf (GConf2) >>>> and I am not sure which port (if any) provides it. >>> >>> devel/gconf2 >> >> I don't think it will working unless someone create a new >> linux-gconf2 port. But I don't know if there will be problem(s) for >> linux-gconf2 and gconf2 to be exist at the same time. That's not a problem. A linux lib needs to be installed into LINUXBASE, and this is different from LOCALBASE. > I guess I could try to fetch a fedora package and try. > I am just not sure how to install it properly, never worked on ports > for Linux binaries before. Have a look at the linux-jpeg or linux-glib ports. It's not very hard Bye, Alexander. -- For a light heart lives long. -- Shakespeare, "Love's Labour's Lost" http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From mezz7 at cox.net Wed May 14 06:44:46 2008 From: mezz7 at cox.net (Jeremy Messenger) Date: Wed May 14 06:44:53 2008 Subject: gizmo: linux libgconf In-Reply-To: <20080514073641.28185dk3mgg4pkw0@webmail.leidinger.net> References: <4829E947.2090002@icyb.net.ua> <44zlquc68x.fsf@be-well.ilk.org> <4829FA53.6070400@icyb.net.ua> <20080514073641.28185dk3mgg4pkw0@webmail.leidinger.net> Message-ID: On Wed, 14 May 2008 00:36:41 -0500, Alexander Leidinger wrote: > Quoting Andriy Gapon (from Tue, 13 May 2008 23:30:11 > +0300): > >> on 13/05/2008 23:21 Jeremy Messenger said the following: >>> On Tue, 13 May 2008 15:13:18 -0500, Lowell Gilbert >>> wrote: >>> >>>> Andriy Gapon writes: >>>> >>>>> Anybody tried to use Linux application from gizmo project on FreeBSD? >>>>> http://gizmo5.com/pc/ >>>>> http://gizmo5.com/pc/download/linux/ >>>>> [this is something similar to skype but SIP based] >>>> >>>> And closed source. Could be more work than you expect. >>>> >>>>> List of dependencies is quite small, but it needs libgconf (GConf2) >>>>> and I am not sure which port (if any) provides it. >>>> >>>> devel/gconf2 >>> >>> I don't think it will working unless someone create a new linux-gconf2 >>> port. But I don't know if there will be problem(s) for linux-gconf2 >>> and gconf2 to be exist at the same time. > > That's not a problem. A linux lib needs to be installed into LINUXBASE, > and this is different from LOCALBASE. It's not library that I am thinking about. ;-) Just that gconf settings when applications install in etc/gconf/* and storage in ~/.gconf*. Do we want gconf settings to be into one for linux-* and native? Or not? Sometime it can causes rare problem like old linux-gnome-volume-manager (non-exist, just example) and new gnome-volume-manager for not able to share ~/.gconf*. >> I guess I could try to fetch a fedora package and try. >> I am just not sure how to install it properly, never worked on ports >> for Linux binaries before. > > Have a look at the linux-jpeg or linux-glib ports. It's not very hard Also, be sure to check in our gconf2 and bsd.gnome.mk (GCONF_SCHEMAS) for how our ports handle with gconf stuff. Cheers, Mezz > Bye, > Alexander. -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From Alexander at Leidinger.net Wed May 14 07:26:44 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed May 14 07:26:50 2008 Subject: gizmo: linux libgconf In-Reply-To: References: <4829E947.2090002@icyb.net.ua> <44zlquc68x.fsf@be-well.ilk.org> <4829FA53.6070400@icyb.net.ua> <20080514073641.28185dk3mgg4pkw0@webmail.leidinger.net> Message-ID: <20080514092636.11666seb600sm30o@webmail.leidinger.net> Quoting Jeremy Messenger (from Wed, 14 May 2008 01:47:02 -0500): > On Wed, 14 May 2008 00:36:41 -0500, Alexander Leidinger > wrote: > >> Quoting Andriy Gapon (from Tue, 13 May 2008 >> 23:30:11 +0300): >> >>> on 13/05/2008 23:21 Jeremy Messenger said the following: >>>> I don't think it will working unless someone create a new >>>> linux-gconf2 port. But I don't know if there will be problem(s) >>>> for linux-gconf2 and gconf2 to be exist at the same time. >> >> That's not a problem. A linux lib needs to be installed into >> LINUXBASE, and this is different from LOCALBASE. > > It's not library that I am thinking about. ;-) Just that gconf > settings when applications install in etc/gconf/* and storage in > ~/.gconf*. Do we want gconf settings to be into one for linux-* and > native? Or not? Sometime it can causes rare problem like old > linux-gnome-volume-manager (non-exist, just example) and new > gnome-volume-manager for not able to share ~/.gconf*. Yes we want it to use the native one. We already use the native fontconfig settings (And other stuff), so a compatible version of linux-gconf needs to be used. Bye, Alexander. -- Pardo's First Postulate: Anything good in life is either illegal, immoral, or fattening. Arnold's Addendum: Everything else causes cancer in rats. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From avg at icyb.net.ua Wed May 14 09:42:51 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed May 14 09:43:09 2008 Subject: gizmo: linux libgconf In-Reply-To: <4829E947.2090002@icyb.net.ua> References: <4829E947.2090002@icyb.net.ua> Message-ID: <482AB412.9040400@icyb.net.ua> Vivek Khera said: > So you can use *any* SIP client with gizmo for voice, and for chat, > any suitable XMPP (jabber) client. They even give you instructions on > what server settings to use to tie into their service. > > Personally, I use a gizmo account with a dial-in number and a SIP > adapter to a regular touch-tone phone, and my family doesn't even know > they're using a VOIP line. > > The Gizmo client itself I find of little use other than to check call > history and account balance, but that works on the web too, just not > as nicely. Hmm, I haven't even thought about this possibility. Thank you! BTW, can anyone recommend good software SIP client for FreeBSD? Thanks. -- Andriy Gapon From tsw5 at duke.edu Wed May 14 21:24:06 2008 From: tsw5 at duke.edu (Todd Wasson) Date: Wed May 14 21:24:11 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches Message-ID: I've been following the discussion on this list about solving the SMP amd64 kqemu issues pretty closely and have been testing out the modules as I've gone along, and as of kqemu 1.3.0.p11_4 it was working pretty well for me. However, I just built kqemu 1.3.0.p11_6 and with qemu 0.9.1_7 it's locking my machine up hard. It isn't leaving me a dump in /var/crash after I manually reset it, so I'm not sure what to look for. Without kqemu, it's running fine albeit expectedly slowly. Does anyone have any suggestions for solutions, or ways to generate logs of whatever the problem may be short of attaching a debugger or something equally unwieldy? Thanks! Todd From tsw5 at duke.edu Thu May 15 02:53:22 2008 From: tsw5 at duke.edu (Todd Wasson) Date: Thu May 15 02:53:26 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: <200805142333.m4ENXhdi014634@saturn.kn-bremen.de> References: <200805142333.m4ENXhdi014634@saturn.kn-bremen.de> Message-ID: <880CC127-204C-415C-AF59-903F5DA1CAA3@duke.edu> Hi Juergen. No, I'm running it in a screen session on a headless machine and using VNC as a display device. I run it from the console and it hangs before anything useful shows up. Specifically, it spits this out before hanging: oss: Could not initialize DAC oss: Failed to open `/dev/dsp' oss: Reason: No such file or directory oss: Could not initialize DAC oss: Failed to open `/dev/dsp' oss: Reason: No such file or directory audio: Failed to create voice `pcspk' pcspk: Could not open voice So yeah, it's complaining about the sound hardware. Anyway, if I watch it in VNC, it hangs immediately when trying to boot the linux kernel; the only VM I've tried with it is a kubuntu install. It goes through the BIOS init, kicks off grub, and then says "Starting up ..." and then hangs. I've attached my dmesg. Thanks for whatever time you can put into this. Todd -------------- next part -------------- Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Genuine Intel(R) CPU 2160 @ 1.80GHz (1800.07-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f2 Stepping = 2 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 6418894848 (6121 MB) avail memory = 6193192960 (5906 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cf600000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 9D, should be 98 [20070320] est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 928092806000928 device_attach: est1 attach returned 6 p4tcc1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xbc00-0xbc07 mem 0xfe900000-0xfe97ffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on pci0 vgapci1: mem 0xfe980000-0xfe9fffff at device 2.1 on pci0 uhci0: port 0xb480-0xb49f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb800-0xb81f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xb880-0xb89f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfe7fbc00-0xfe7fbfff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered umass0: on uhub3 pci0: at device 27.0 (no driver attached) pcib1: irq 17 at device 28.0 on pci0 pci3: on pcib1 pcib2: irq 17 at device 28.4 on pci0 pci2: on pcib2 atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f irq 16 at device 0.0 on pci2 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] pcib3: irq 16 at device 28.5 on pci0 pci1: on pcib3 mskc0: port 0xc800-0xc8ff mem 0xfeafc000-0xfeafffff irq 17 at device 0.0 on pci1 msk0: on mskc0 msk0: Ethernet address: 00:1d:60:6d:99:85 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FILTER] uhci3: port 0xb000-0xb01f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xb080-0xb09f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xb400-0xb41f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xfe7fb800-0xfe7fbbff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib4: at device 30.0 on pci0 pci4: on pcib4 dc0: port 0xe800-0xe8ff mem 0xfebffc00-0xfebfffff irq 16 at device 0.0 on pci4 miibus1: on dc0 ukphy0: PHY 1 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:14:bf:5a:c6:42 dc0: [ITHREAD] fwohci0: port 0xec00-0xec7f mem 0xfebff000-0xfebff7ff irq 20 at device 2.0 on pci4 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:01:77:14:ed fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x12b0000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:d8:77:14:ed fwe0: Ethernet address: 02:11:d8:77:14:ed fwip0: on firewire0 fwip0: Firewire address: 00:11:d8:00:01:77:14:ed @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x9c00-0x9c07,0x9880-0x9883,0x9800-0x9807,0x9480-0x9483,0x9400-0x940f,0x9080-0x908f irq 22 at device 31.2 on pci0 atapci1: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f,0xa080-0xa08f irq 22 at device 31.5 on pci0 atapci2: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] acpi_button0: on acpi0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 plip0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cryptosoft0: on motherboard sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec hptrr: no controller detefirewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) cted. ad4: 152627MB at ata2-master UDMA100 ad6: 381554MB at ata3-master SATA300 ad8: 381554MB at ata4-master SATA300 ad10: 476940MB at ata5-master SATA300 ad12: 476940MB at ata6-master SATA300 SMP: AP CPU #1 Launched! cd0 at umass-sim0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 40.000MB/s transfers cd0: cd present [1 x 2048 byte records] Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 100 files 1 WARNING: /var was not properly dismounted WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 dc0: TX underrun -- increasing TX threshold tap0: Ethernet address: 00:bd:42:59:28:00 bridge0: Ethernet address: ce:a0:69:9b:57:94 tap0: promiscuous mode enabled dc0: promiscuous mode enabled tap1: Ethernet address: 00:bd:3e:f5:28:01 tap2: Ethernet address: 00:bd:3f:f5:28:02 tap3: Ethernet address: 00:bd:3f:f5:28:03 tap4: Ethernet address: 00:bd:3f:f5:28:04 tap5: Ethernet address: 00:bd:40:f5:28:05 tap6: Ethernet address: 00:bd:40:f5:28:06 tap7: Ethernet address: 00:bd:40:f5:28:07 tap8: Ethernet address: 00:bd:41:f5:28:08 tap9: Ethernet address: 00:bd:41:f5:28:09 kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=3134224kB. -------------- next part -------------- On May 14, 2008, at 7:33 PM, Juergen Lock wrote: > In article you write: >> I've been following the discussion on this list about solving the SMP >> amd64 kqemu issues pretty closely and have been testing out the >> modules as I've gone along, and as of kqemu 1.3.0.p11_4 it was >> working >> pretty well for me. However, I just built kqemu 1.3.0.p11_6 and with >> qemu 0.9.1_7 it's locking my machine up hard. It isn't leaving me a >> dump in /var/crash after I manually reset it, so I'm not sure what to >> look for. Without kqemu, it's running fine albeit expectedly slowly. >> Does anyone have any suggestions for solutions, or ways to generate >> logs of whatever the problem may be short of attaching a debugger or >> something equally unwieldy? > > Are you running qemu under X? You could try on the console to see > if there's anything printed there (like with the qemu-devel port that > has -curses which works at least for FreeBSD isos.) > > Anyway, I can't look at this today, but could you send me a dmesg of > the box in question? > > Thanx, > Juergen From tsw5 at duke.edu Thu May 15 03:06:48 2008 From: tsw5 at duke.edu (Todd Wasson) Date: Thu May 15 03:06:52 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: <20080515002952.62ADA5B46@mail.bitblocks.com> References: <20080515002952.62ADA5B46@mail.bitblocks.com> Message-ID: I'm running 7.0-RELEASE. The machine hangs when I use qemu, specifically with a linux VM, and more specifically after grub loads the kernel and it spits out the "Starting up ..." message. Then... nothing. Just before the crash, I see complaints about my sound hardware on the console; it doesn't seem related, but here it is: oss: Could not initialize DAC oss: Failed to open `/dev/dsp' oss: Reason: No such file or directory oss: Could not initialize DAC oss: Failed to open `/dev/dsp' oss: Reason: No such file or directory audio: Failed to create voice `pcspk' pcspk: Could not open voice I haven't touched /usr/include since I used freebsd-update to go from the last RC to RELEASE, and I'm using the -RELEASE GENERIC kernel, so I presume they're in sync. I am definitely loading the correct kqemu; I rebuilt it to check the md5sum against the one being loaded by kldload (in /boot/modules/). I suspect I might need to enable kernel debugging. I'll check the handbook and do that if necessary. If need be, what should I be looking for / post? Thanks a lot for your help. Todd On May 14, 2008, at 8:29 PM, Bakul Shah wrote: > On Wed, 14 May 2008 17:08:27 EDT Todd Wasson wrote: >> I've been following the discussion on this list about solving the SMP >> amd64 kqemu issues pretty closely and have been testing out the >> modules as I've gone along, and as of kqemu 1.3.0.p11_4 it was >> working >> pretty well for me. However, I just built kqemu 1.3.0.p11_6 and with >> qemu 0.9.1_7 it's locking my machine up hard. It isn't leaving me a >> dump in /var/crash after I manually reset it, so I'm not sure what to >> look for. Without kqemu, it's running fine albeit expectedly slowly. >> Does anyone have any suggestions for solutions, or ways to generate >> logs of whatever the problem may be short of attaching a debugger or >> something equally unwieldy? > > What kernel are you running? -current or -release? When does > the machine hang, when you load kqemu or when you try to use > qemu? What do you see on the console just before the crash? > > You may want to check some standard things: Is /usr/include > in sync with the kernel? Are you loading the correct kqemu? > Try rebuilding and reinstalling. > > If everything checks out and there is no print out on the console > you may have to build a kernel with debugging on. From bakul at bitblocks.com Thu May 15 08:09:49 2008 From: bakul at bitblocks.com (Bakul Shah) Date: Thu May 15 08:09:54 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: Your message of "Wed, 14 May 2008 23:06:47 EDT." Message-ID: <20080515080948.3B1F15B47@mail.bitblocks.com> When you said an earlier kqemu version worked, was it on the same hardware, with the same amount of memory and 7.0 release? For the same image? Can you try it again to see if it still works? Can you show the exact qemu command line? Some more things to try: In your earlier response I see > kqemu version 0x00010300 > kqemu: KQEMU installed, max_locked_mem=3134224kB. This makes me wonder if the amount of max_locked_mem is the problem. To test this, change kqemu-freebsd.c:554 to max_locked_pages = MIN(physmem / 2, 0x1fffffff / PAGE_SIZE); This will allocate no more than 512B for max locked pages. If this works keep doubling the size until it breaks. You can enable kqemu debug prints by sysctl debug.kqemu_debug=1 before starting qemu. May be we will find something unusual there. To rule out audio you can disable it from the qemu command line. If you can, remove zfs during testing. From nox at jelal.kn-bremen.de Thu May 15 17:31:33 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu May 15 17:31:37 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: <880CC127-204C-415C-AF59-903F5DA1CAA3@duke.edu> References: <200805142333.m4ENXhdi014634@saturn.kn-bremen.de> <880CC127-204C-415C-AF59-903F5DA1CAA3@duke.edu> Message-ID: <20080515172836.GA7890@saturn.kn-bremen.de> On Wed, May 14, 2008 at 10:53:20PM -0400, Todd Wasson wrote: > Hi Juergen. No, I'm running it in a screen session on a headless machine > and using VNC as a display device. I run it from the console and it hangs > before anything useful shows up. Specifically, it spits this out before > hanging: > > oss: Could not initialize DAC > oss: Failed to open `/dev/dsp' > oss: Reason: No such file or directory > oss: Could not initialize DAC > oss: Failed to open `/dev/dsp' > oss: Reason: No such file or directory > audio: Failed to create voice `pcspk' > pcspk: Could not open voice > > So yeah, it's complaining about the sound hardware. Oh that's _probably_ unrelated. > Anyway, if I watch it > in VNC, it hangs immediately when trying to boot the linux kernel; the only > VM I've tried with it is a kubuntu install. It goes through the BIOS init, > kicks off grub, and then says "Starting up ..." and then hangs. > > I've attached my dmesg. Thanks for whatever time you can put into this. Thanx. Can you try the folloing patch? (also at http://people.freebsd.org/~nox/qemu/kqemu-kmod-tss-cpldt2.patch ) Index: Makefile =================================================================== RCS file: /home/pcvs/ports/emulators/kqemu-kmod/Makefile,v retrieving revision 1.25 diff -u -p -r1.25 Makefile --- Makefile 12 May 2008 19:09:52 -0000 1.25 +++ Makefile 15 May 2008 17:07:33 -0000 @@ -7,7 +7,7 @@ PORTNAME= kqemu PORTVERSION= 1.3.0.p11 -PORTREVISION= 6 +PORTREVISION= 7 CATEGORIES= emulators kld MASTER_SITES= http://fabrice.bellard.free.fr/qemu/ \ http://qemu.org/ \ Index: files/patch-tssworkaround =================================================================== RCS file: /home/pcvs/ports/emulators/kqemu-kmod/files/patch-tssworkaround,v retrieving revision 1.3 diff -u -p -r1.3 patch-tssworkaround --- files/patch-tssworkaround 12 May 2008 19:09:52 -0000 1.3 +++ files/patch-tssworkaround 15 May 2008 17:04:38 -0000 @@ -14,7 +14,7 @@ Index: kqemu-freebsd.c #include "kqemu-kernel.h" -@@ -248,6 +256,57 @@ +@@ -248,6 +256,60 @@ va_end(ap); } @@ -26,7 +26,7 @@ Index: kqemu-freebsd.c +extern struct pcpu __pcpu[]; + +/* called with interrupts disabled */ -+void CDECL kqemu_tss_fixup(unsigned long kerngdtbase) ++void CDECL kqemu_tss_fixup(unsigned long kerngdtbase, uint16_t kernldtsel) +{ + int gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); + unsigned cpuid = PCPU_GET(cpuid); @@ -64,6 +64,9 @@ Index: kqemu-freebsd.c + wrmsr(MSR_GSBASE, (u_int64_t)&__pcpu[cpuid]); + wrmsr(MSR_KGSBASE, curthread->td_pcb->pcb_gsbase); + wrmsr(MSR_FSBASE, 0); ++ ssdtosyssd(&gdt_segs[GPROC0_SEL], ++ (struct system_segment_descriptor *)&newgdt[GPROC0_SEL]); ++ lldt(kernldtsel); + } + ltr(gsel_tss); +} @@ -90,7 +93,7 @@ Index: common/kernel.c +#ifdef __FreeBSD__ +#ifdef __x86_64__ + spin_lock(&g->lock); -+ kqemu_tss_fixup(s->kernel_gdt.base); ++ kqemu_tss_fixup(s->kernel_gdt.base, s->kernel_ldt_sel); + spin_unlock(&g->lock); +#endif +#endif @@ -104,7 +107,7 @@ Index: kqemu-kernel.h +#ifdef __FreeBSD__ +#ifdef __x86_64__ -+void CDECL kqemu_tss_fixup(unsigned long kerngdtbase); ++void CDECL kqemu_tss_fixup(unsigned long kerngdtbase, uint16_t kernldtsel); +#endif +#endif + From tsw5 at duke.edu Thu May 15 21:43:02 2008 From: tsw5 at duke.edu (Todd Wasson) Date: Thu May 15 21:43:06 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: <20080515172836.GA7890@saturn.kn-bremen.de> References: <200805142333.m4ENXhdi014634@saturn.kn-bremen.de> <880CC127-204C-415C-AF59-903F5DA1CAA3@duke.edu> <20080515172836.GA7890@saturn.kn-bremen.de> Message-ID: <9AFAF61B-D2C4-4785-8FCA-D2A10FFD0381@duke.edu> I tried that patch and it still hung at about the same point. I think it may have printed one more line to the VNC session, about initializing the PIIX3 controller, but then nothing. Interestingly, I tried rolling back to 1.3.0.p11_4 to see if it still worked, and it did. So then I went to 1.3.0.p11_5 and it also worked. Therefore whatever is causing this is in the 1.3.0.p11_6 patch, as far as I can tell. Todd On May 15, 2008, at 1:28 PM, Juergen Lock wrote: > On Wed, May 14, 2008 at 10:53:20PM -0400, Todd Wasson wrote: >> Hi Juergen. No, I'm running it in a screen session on a headless >> machine >> and using VNC as a display device. I run it from the console and >> it hangs >> before anything useful shows up. Specifically, it spits this out >> before >> hanging: >> >> oss: Could not initialize DAC >> oss: Failed to open `/dev/dsp' >> oss: Reason: No such file or directory >> oss: Could not initialize DAC >> oss: Failed to open `/dev/dsp' >> oss: Reason: No such file or directory >> audio: Failed to create voice `pcspk' >> pcspk: Could not open voice >> >> So yeah, it's complaining about the sound hardware. > > Oh that's _probably_ unrelated. > >> Anyway, if I watch it >> in VNC, it hangs immediately when trying to boot the linux kernel; >> the only >> VM I've tried with it is a kubuntu install. It goes through the >> BIOS init, >> kicks off grub, and then says "Starting up ..." and then hangs. >> >> I've attached my dmesg. Thanks for whatever time you can put into >> this. > > Thanx. Can you try the folloing patch? (also at > http://people.freebsd.org/~nox/qemu/kqemu-kmod-tss-cpldt2.patch > ) > > Index: Makefile > =================================================================== > RCS file: /home/pcvs/ports/emulators/kqemu-kmod/Makefile,v > retrieving revision 1.25 > diff -u -p -r1.25 Makefile > --- Makefile 12 May 2008 19:09:52 -0000 1.25 > +++ Makefile 15 May 2008 17:07:33 -0000 > @@ -7,7 +7,7 @@ > > PORTNAME= kqemu > PORTVERSION= 1.3.0.p11 > -PORTREVISION= 6 > +PORTREVISION= 7 > CATEGORIES= emulators kld > MASTER_SITES= http://fabrice.bellard.free.fr/qemu/ \ > http://qemu.org/ \ > Index: files/patch-tssworkaround > =================================================================== > RCS file: /home/pcvs/ports/emulators/kqemu-kmod/files/patch- > tssworkaround,v > retrieving revision 1.3 > diff -u -p -r1.3 patch-tssworkaround > --- files/patch-tssworkaround 12 May 2008 19:09:52 -0000 1.3 > +++ files/patch-tssworkaround 15 May 2008 17:04:38 -0000 > @@ -14,7 +14,7 @@ Index: kqemu-freebsd.c > > #include "kqemu-kernel.h" > > -@@ -248,6 +256,57 @@ > +@@ -248,6 +256,60 @@ > va_end(ap); > } > > @@ -26,7 +26,7 @@ Index: kqemu-freebsd.c > +extern struct pcpu __pcpu[]; > + > +/* called with interrupts disabled */ > -+void CDECL kqemu_tss_fixup(unsigned long kerngdtbase) > ++void CDECL kqemu_tss_fixup(unsigned long kerngdtbase, uint16_t > kernldtsel) > +{ > + int gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); > + unsigned cpuid = PCPU_GET(cpuid); > @@ -64,6 +64,9 @@ Index: kqemu-freebsd.c > + wrmsr(MSR_GSBASE, (u_int64_t)&__pcpu[cpuid]); > + wrmsr(MSR_KGSBASE, curthread->td_pcb->pcb_gsbase); > + wrmsr(MSR_FSBASE, 0); > ++ ssdtosyssd(&gdt_segs[GPROC0_SEL], > ++ (struct system_segment_descriptor *)&newgdt[GPROC0_SEL]); > ++ lldt(kernldtsel); > + } > + ltr(gsel_tss); > +} > @@ -90,7 +93,7 @@ Index: common/kernel.c > +#ifdef __FreeBSD__ > +#ifdef __x86_64__ > + spin_lock(&g->lock); > -+ kqemu_tss_fixup(s->kernel_gdt.base); > ++ kqemu_tss_fixup(s->kernel_gdt.base, s->kernel_ldt_sel); > + spin_unlock(&g->lock); > +#endif > +#endif > @@ -104,7 +107,7 @@ Index: kqemu-kernel.h > > +#ifdef __FreeBSD__ > +#ifdef __x86_64__ > -+void CDECL kqemu_tss_fixup(unsigned long kerngdtbase); > ++void CDECL kqemu_tss_fixup(unsigned long kerngdtbase, uint16_t > kernldtsel); > +#endif > +#endif > + From tsw5 at duke.edu Thu May 15 22:05:54 2008 From: tsw5 at duke.edu (Todd Wasson) Date: Thu May 15 22:05:59 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: <20080515080948.3B1F15B47@mail.bitblocks.com> References: <20080515080948.3B1F15B47@mail.bitblocks.com> Message-ID: Yes, it was on this same system, configured in exactly the same with, with the same image. I tried it again with 1.3.0.p11_4 and it still works, so I tried it with 1.3.0.p11_5. That worked too. The problem must be in 1.3.0.p11_6. The command line I've been using is "qemu-system-x86_64 -hda test.img - net nic -net tap -localtime -m 1536 -vnc :2 -usbdevice tablet -soundhw es1370,pcspk". I've tried running without ZFS (I unloaded the module), sound, and networking and it still crashes. I enabled the debugging sysctl and just saw a lot of kqemu_vmalloc_to_phys calls before it crashed. I haven't started playing with max_locked_mem yet, but will do so if narrowing it down specifically to the changes between 1.3.0.p11_5 and 1.3.0.p11_6 isn't helpful enough. The main reason I'm hesitant is that repeatedly crashing my box is rather undesirable and problematic for me, but I will resort to this if I can't learn more in another way. Thanks for your help. Todd On May 15, 2008, at 4:09 AM, Bakul Shah wrote: > When you said an earlier kqemu version worked, was it on the same > hardware, with the same amount of memory and 7.0 release? For the > same image? Can you try it again to see if it still works? > > Can you show the exact qemu command line? > > Some more things to try: > > In your earlier response I see >> kqemu version 0x00010300 >> kqemu: KQEMU installed, max_locked_mem=3134224kB. > > This makes me wonder if the amount of max_locked_mem is the > problem. To test this, change kqemu-freebsd.c:554 to > > max_locked_pages = MIN(physmem / 2, 0x1fffffff / PAGE_SIZE); > > This will allocate no more than 512B for max locked pages. > If this works keep doubling the size until it breaks. > > You can enable kqemu debug prints by > > sysctl debug.kqemu_debug=1 > > before starting qemu. May be we will find something unusual there. > > To rule out audio you can disable it from the qemu command line. > > If you can, remove zfs during testing. From nox at jelal.kn-bremen.de Thu May 15 23:08:41 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu May 15 23:08:43 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: <9AFAF61B-D2C4-4785-8FCA-D2A10FFD0381@duke.edu> References: <200805142333.m4ENXhdi014634@saturn.kn-bremen.de> <880CC127-204C-415C-AF59-903F5DA1CAA3@duke.edu> <20080515172836.GA7890@saturn.kn-bremen.de> <9AFAF61B-D2C4-4785-8FCA-D2A10FFD0381@duke.edu> Message-ID: <20080515230659.GA16021@saturn.kn-bremen.de> On Thu, May 15, 2008 at 05:43:00PM -0400, Todd Wasson wrote: > I tried that patch and it still hung at about the same point. I think it > may have printed one more line to the VNC session, about initializing the > PIIX3 controller, but then nothing. > > Interestingly, I tried rolling back to 1.3.0.p11_4 to see if it still > worked, and it did. So then I went to 1.3.0.p11_5 and it also worked. > Therefore whatever is causing this is in the 1.3.0.p11_6 patch, as far as I > can tell. Hmm I wonder what that is then, apparently it is not liking the moving of the gdt, but what about it doesn't it like? Is anyone else here seeing this problem that could invistigate? Its a little difficult debugging something that works just fine here... Oh I see you have like 6 GB RAM, could you try booting with hw.physmem lowered to, say, 2 GB to see if the problem has something to do with RAM size? Thanx, Juergen From nox at jelal.kn-bremen.de Thu May 15 23:25:24 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Thu May 15 23:25:27 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: References: <20080515080948.3B1F15B47@mail.bitblocks.com> Message-ID: <200805152323.m4FNNO7H017348@saturn.kn-bremen.de> In article you write: >Yes, it was on this same system, configured in exactly the same with, >with the same image. I tried it again with 1.3.0.p11_4 and it still >works, so I tried it with 1.3.0.p11_5. That worked too. The problem >must be in 1.3.0.p11_6. > >The command line I've been using is "qemu-system-x86_64 -hda test.img - >net nic -net tap -localtime -m 1536 -vnc :2 -usbdevice tablet -soundhw >es1370,pcspk". You could also try a smaller -m arg, like -m 256... Oh and you said you have sound issues (do you even have sound configured on the host?), you could also try without -soundhw. (Even tho this is most likely unrelated as I said...) Good luck, :) Juergen From scf at FreeBSD.org Thu May 15 23:43:09 2008 From: scf at FreeBSD.org (Sean C. Farley) Date: Thu May 15 23:43:12 2008 Subject: QEMU AIO patch Message-ID: Awhile ago, I wrote a patch to take advantage of FreeBSD's aio_waitcomplete() call in the QEMU raw block code. It took some doing, but I finally found a copy of the patch[1] on a laptop that started dying about a year ago. Using aio_waitcomplete() should reduce the number of context switches present in the current code. I have not truly tested the patch to see how well it helps. Since it is FreeBSD-only, I am posting it here instead of directly to the QEMU mailing list. Sean 1. http://www.farley.org/freebsd/tmp/qemu-aio.patch -- scf@FreeBSD.org From pfgshield-freebsd at yahoo.com Fri May 16 15:46:27 2008 From: pfgshield-freebsd at yahoo.com (pfgshield-freebsd@yahoo.com) Date: Fri May 16 15:46:31 2008 Subject: Open POSIX testsuite results Message-ID: <991810.69175.qm@web32701.mail.mud.yahoo.com> Hello; I saw on the linux-kernel wiki that you need reference output from Linux to compare. I just updated the misc/posixtestsuite port and I noticed they have some reference output on their website: http://posixtest.sourceforge.net/testpass/PTS_1.5.1-2.6.10-PAIO_ia32.htm hope that helps, Pedro. ___________________________________ Scopri il Blog di Yahoo! Mail: trucchi, novit?, consigli... e la tua opinione! http://www.ymailblogit.com/blog/ From tsw5 at duke.edu Fri May 16 22:07:35 2008 From: tsw5 at duke.edu (Todd Wasson) Date: Fri May 16 22:07:38 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: <200805152323.m4FNNO7H017348@saturn.kn-bremen.de> References: <20080515080948.3B1F15B47@mail.bitblocks.com> <200805152323.m4FNNO7H017348@saturn.kn-bremen.de> Message-ID: Using -m 256 doesn't help, though interestingly 1.3.0.p11_5 crashes (but doesn't take down the machine) with -m 1536 but is fine with -m 256. 1.3.0.p11_6 hangs the machine regardless, though. I haven't been using -soundhw at all recently, but yes, I do actually have sound on the host. Lowering hw.physmem to 2GB and using -m 256 still results in a hang. I'm going to keep these and try the max_locked_pages changes that Bakul Shah suggested. I'll post the results to the list. Thanks again. Todd On May 15, 2008, at 7:23 PM, Juergen Lock wrote: > In article you write: >> Yes, it was on this same system, configured in exactly the same with, >> with the same image. I tried it again with 1.3.0.p11_4 and it still >> works, so I tried it with 1.3.0.p11_5. That worked too. The problem >> must be in 1.3.0.p11_6. >> >> The command line I've been using is "qemu-system-x86_64 -hda >> test.img - >> net nic -net tap -localtime -m 1536 -vnc :2 -usbdevice tablet - >> soundhw >> es1370,pcspk". > > You could also try a smaller -m arg, like -m 256... > > Oh and you said you have sound issues (do you even have sound > configured > on the host?), you could also try without -soundhw. (Even tho this is > most likely unrelated as I said...) > > Good luck, :) > Juergen From tsw5 at duke.edu Fri May 16 22:23:01 2008 From: tsw5 at duke.edu (Todd Wasson) Date: Fri May 16 22:23:04 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: <20080515080948.3B1F15B47@mail.bitblocks.com> References: <20080515080948.3B1F15B47@mail.bitblocks.com> Message-ID: <480D1B99-CAE6-4164-B435-5A2AF08393F3@duke.edu> Hi Bakul. I tried changing max_locked_pages, as well as lowering hw.physmem to 2GB and in the dmesg it printed "kqemu: KQEMU installed, max_locked_mem=524284kB." I ran qemu with -m 256 after all of this, and it still hung in the same spot. Argh. I'm not sure if I should just keep arbitrarily lowering it and praying, or what. My filesystems keep getting trashed though thanks to the hanging, so I'm not inclined to take that path unless I have to... Any other ideas? Thanks for your help so far, I really appreciate it. Todd On May 15, 2008, at 4:09 AM, Bakul Shah wrote: > When you said an earlier kqemu version worked, was it on the same > hardware, with the same amount of memory and 7.0 release? For the > same image? Can you try it again to see if it still works? > > Can you show the exact qemu command line? > > Some more things to try: > > In your earlier response I see >> kqemu version 0x00010300 >> kqemu: KQEMU installed, max_locked_mem=3134224kB. > > This makes me wonder if the amount of max_locked_mem is the > problem. To test this, change kqemu-freebsd.c:554 to > > max_locked_pages = MIN(physmem / 2, 0x1fffffff / PAGE_SIZE); > > This will allocate no more than 512B for max locked pages. > If this works keep doubling the size until it breaks. > > You can enable kqemu debug prints by > > sysctl debug.kqemu_debug=1 > > before starting qemu. May be we will find something unusual there. > > To rule out audio you can disable it from the qemu command line. > > If you can, remove zfs during testing. From vwe at FreeBSD.org Sun May 18 09:22:23 2008 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Sun May 18 09:22:24 2008 Subject: kern/73777: [linux] [patch] linux emulation: root dir special handling useless and harmful Message-ID: <200805180922.m4I9MLN0043984@freefall.freebsd.org> Synopsis: [linux] [patch] linux emulation: root dir special handling useless and harmful State-Changed-From-To: feedback->open State-Changed-By: vwe State-Changed-When: Sun May 18 09:22:03 UTC 2008 State-Changed-Why: feedback and new patch provided http://www.freebsd.org/cgi/query-pr.cgi?pr=73777 From nox at jelal.kn-bremen.de Sun May 18 14:26:36 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun May 18 14:26:39 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: References: <20080515080948.3B1F15B47@mail.bitblocks.com> <200805152323.m4FNNO7H017348@saturn.kn-bremen.de> Message-ID: <20080518142427.GA20876@saturn.kn-bremen.de> On Fri, May 16, 2008 at 06:07:32PM -0400, Todd Wasson wrote: > Using -m 256 doesn't help, though interestingly 1.3.0.p11_5 crashes (but > doesn't take down the machine) with -m 1536 but is fine with -m 256. > 1.3.0.p11_6 hangs the machine regardless, though. > > I haven't been using -soundhw at all recently, but yes, I do actually have > sound on the host. > > Lowering hw.physmem to 2GB and using -m 256 still results in a hang. > > I'm going to keep these and try the max_locked_pages changes that Bakul > Shah suggested. I'll post the results to the list. > > Thanks again. OK can you try the following kernel patch with the latest kqemu (also at http://people.freebsd.org/~nox/qemu/patch-sys-amd64-seperate-gdt.txt - untested because my amd64 smp box is in the middle of a portupgrade that was long overdue...) Index: src/sys/amd64/amd64/mp_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/amd64/amd64/mp_machdep.c,v retrieving revision 1.287.2.2 diff -u -p -u -r1.287.2.2 mp_machdep.c --- src/sys/amd64/amd64/mp_machdep.c 28 Nov 2007 23:24:06 -0000 1.287.2.2 +++ src/sys/amd64/amd64/mp_machdep.c 18 May 2008 13:45:32 -0000 @@ -457,10 +457,18 @@ init_secondary(void) common_tss[cpu].tss_iobase = sizeof(struct amd64tss); common_tss[cpu].tss_ist1 = (long)&doublefault_stack[PAGE_SIZE]; + /* Use a seperate gdt for each cpu because the tss differs + * This avoids complications for e.g. virtualization software + * that needs to reload the task register and otherwise would + * then end up using the last cpu's tss on others + */ + bcopy(&gdt[0], &gdt[NGDT * cpu], NGDT * sizeof(gdt[0])); + gdt_segs[GPROC0_SEL].ssd_base = (long) &common_tss[cpu]; ssdtosyssd(&gdt_segs[GPROC0_SEL], - (struct system_segment_descriptor *)&gdt[GPROC0_SEL]); + (struct system_segment_descriptor *)&gdt[NGDT * cpu + GPROC0_SEL]); + r_gdt.rd_base = (long) &gdt[NGDT * cpu]; lgdt(&r_gdt); /* does magic intra-segment return */ /* Get per-cpu data */ From tsw5 at duke.edu Sun May 18 22:16:23 2008 From: tsw5 at duke.edu (Todd Wasson) Date: Sun May 18 22:16:27 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: <20080518142427.GA20876@saturn.kn-bremen.de> References: <20080515080948.3B1F15B47@mail.bitblocks.com> <200805152323.m4FNNO7H017348@saturn.kn-bremen.de> <20080518142427.GA20876@saturn.kn-bremen.de> Message-ID: Hi Juergen. That patch seems to have fixed the problem for me, as verified with both kqemu-kmod-1.3.0.p11_6 and kqemu-kmod-1.3.0.p11_7. However, I'm somewhat uneasy about using this patch on my system long- term, since it hasn't been rigorously tested. Are there putative implications of this patch with other software that I should be aware of? Is this kernel patch considered to be the final fix, or just a band-aid until the underlying cause can be addressed from within kqemu alone? Thanks again for your help with this. On a side note, what is the status of kqemu kernel mode support on SMP amd64 (i.e. qemu-system- x86_64 -kernel-kqemu)? Even though kqemu is more or less working for me now, it's still quite slow and I presume this to be why. Todd On May 18, 2008, at 10:24 AM, Juergen Lock wrote: > On Fri, May 16, 2008 at 06:07:32PM -0400, Todd Wasson wrote: >> Using -m 256 doesn't help, though interestingly 1.3.0.p11_5 crashes >> (but >> doesn't take down the machine) with -m 1536 but is fine with -m 256. >> 1.3.0.p11_6 hangs the machine regardless, though. >> >> I haven't been using -soundhw at all recently, but yes, I do >> actually have >> sound on the host. >> >> Lowering hw.physmem to 2GB and using -m 256 still results in a hang. >> >> I'm going to keep these and try the max_locked_pages changes that >> Bakul >> Shah suggested. I'll post the results to the list. >> >> Thanks again. > > OK can you try the following kernel patch with the latest kqemu > (also at > http://people.freebsd.org/~nox/qemu/patch-sys-amd64-seperate-gdt.txt > - untested because my amd64 smp box is in the middle of a > portupgrade that > was long overdue...) > > Index: src/sys/amd64/amd64/mp_machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/amd64/amd64/mp_machdep.c,v > retrieving revision 1.287.2.2 > diff -u -p -u -r1.287.2.2 mp_machdep.c > --- src/sys/amd64/amd64/mp_machdep.c 28 Nov 2007 23:24:06 -0000 > 1.287.2.2 > +++ src/sys/amd64/amd64/mp_machdep.c 18 May 2008 13:45:32 -0000 > @@ -457,10 +457,18 @@ init_secondary(void) > common_tss[cpu].tss_iobase = sizeof(struct amd64tss); > common_tss[cpu].tss_ist1 = (long)&doublefault_stack[PAGE_SIZE]; > > + /* Use a seperate gdt for each cpu because the tss differs > + * This avoids complications for e.g. virtualization software > + * that needs to reload the task register and otherwise would > + * then end up using the last cpu's tss on others > + */ > + bcopy(&gdt[0], &gdt[NGDT * cpu], NGDT * sizeof(gdt[0])); > + > gdt_segs[GPROC0_SEL].ssd_base = (long) &common_tss[cpu]; > ssdtosyssd(&gdt_segs[GPROC0_SEL], > - (struct system_segment_descriptor *)&gdt[GPROC0_SEL]); > + (struct system_segment_descriptor *)&gdt[NGDT * cpu + > GPROC0_SEL]); > > + r_gdt.rd_base = (long) &gdt[NGDT * cpu]; > lgdt(&r_gdt); /* does magic intra-segment return */ > > /* Get per-cpu data */ From nox at jelal.kn-bremen.de Sun May 18 23:07:48 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun May 18 23:07:52 2008 Subject: kqemu locking my machine hard on amd64 smp, with most recent patches In-Reply-To: References: <20080515080948.3B1F15B47@mail.bitblocks.com> <200805152323.m4FNNO7H017348@saturn.kn-bremen.de> <20080518142427.GA20876@saturn.kn-bremen.de> Message-ID: <20080518230419.GA48991@saturn.kn-bremen.de> On Sun, May 18, 2008 at 06:16:21PM -0400, Todd Wasson wrote: > Hi Juergen. That patch seems to have fixed the problem for me, as verified > with both kqemu-kmod-1.3.0.p11_6 and kqemu-kmod-1.3.0.p11_7. However, I'm > somewhat uneasy about using this patch on my system long-term, since it > hasn't been rigorously tested. Are there putative implications of this > patch with other software that I should be aware of? Well, `regular' software shouldn't care about the gdt being shared or not id say, this is a very lowlevel implementation detail that this patch changes. (The gdt also isn't shared on i386, fwiw.) > Is this kernel patch > considered to be the final fix, or just a band-aid until the underlying > cause can be addressed from within kqemu alone? > No actually I'd call this kernel patch a more `proper' fix, what kqemu now does is move the gdts of all but the first cpu after the fact (if they are shared), this patch sets them up seperate from the beginning. (Actually I updated the patch after the original post, but the changes are only cosmetic.) I can't speak for the src people tho, so I don't know whether they may deem it commit-worthy later, but using it _should_ be safe. > Thanks again for your help with this. On a side note, what is the status > of kqemu kernel mode support on SMP amd64 (i.e. qemu-system-x86_64 > -kernel-kqemu)? Even though kqemu is more or less working for me now, it's > still quite slow and I presume this to be why. -kernel-kqemu is just less well debugged on amd64 than on i386, it may still work with some guests. (The problem with kqemu is it gets kinda neglected these days by the linux guys since they have all these other virtualization solutions now that people seem to like better...) Juergen From bugmaster at FreeBSD.org Mon May 19 11:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 19 11:06:58 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200805191106.m4JB6oBF011533@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/117010 emulation [linux] linux_getdents() get something like buffer ove 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/41543 emulation [patch] [request] easier wine/w23 support a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/122318 emulation [linux] [cmake]: Segmentation fault when running Linux 10 problems total. From avg at icyb.net.ua Mon May 19 14:45:46 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon May 19 14:45:50 2008 Subject: wine rebuilds font smth every time Message-ID: <48318E4D.1070009@icyb.net.ua> Every time I run wine it starts rebuilding something related to fonts. This takes quite long, only after that a windows program is actually executed. Very annoying. This is wine-0.9.59,1, installed from a package, no extra configuration. What could be causing this? Any way to fix/workaround? Big thanks in advance! -- Andriy Gapon From uspoerlein at gmail.com Mon May 19 15:52:08 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Mon May 19 15:52:12 2008 Subject: Running IBM DB2 Client V8.1 under FreeBSD Message-ID: <7ad7ddd90805190825j4ab17560k3b0296ac00c4a4c9@mail.gmail.com> Hi, did anyone accomplish this feat? I have a DB/2 Client installation copied over to a FreeBSD 6.3 system and while the db2(1) binary starts, it runs into an endless loop. 89938 db2 RET getdomainname 0 89938 db2 CALL open(0xbfbfc7e8,0x801,0) 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" 89938 db2 RET open JUSTRETURN 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) 89938 db2 RET getdomainname 0 89938 db2 CALL open(0xbfbfc7e8,0x801,0) 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" 89938 db2 RET open JUSTRETURN 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) 89938 db2 RET getdomainname 0 89938 db2 CALL open(0xbfbfc7e8,0x801,0) 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" 89938 db2 RET open JUSTRETURN 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) 89938 db2 RET getdomainname 0 89938 db2 CALL open(0xbfbfc7e8,0x801,0) 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" 89938 db2 RET open JUSTRETURN 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) 89938 db2 RET getdomainname 0 89938 db2 CALL open(0xbfbfc7e8,0x801,0) 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" 89938 db2 RET open JUSTRETURN 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) Google seems to be suspiciously silent about DB2 on FreeBSD. Ciao, Uli From chagin.dmitry at gmail.com Mon May 19 16:11:26 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Mon May 19 16:11:32 2008 Subject: Running IBM DB2 Client V8.1 under FreeBSD In-Reply-To: <7ad7ddd90805190825j4ab17560k3b0296ac00c4a4c9@mail.gmail.com> References: <7ad7ddd90805190825j4ab17560k3b0296ac00c4a4c9@mail.gmail.com> Message-ID: On Mon, 19 May 2008, Ulrich Spoerlein wrote: > Hi, > > did anyone accomplish this feat? I have a DB/2 Client installation > copied over to a FreeBSD 6.3 system and while the db2(1) binary > starts, it runs into an endless loop. > > 89938 db2 RET getdomainname 0 > 89938 db2 CALL open(0xbfbfc7e8,0x801,0) > 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" > 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" > 89938 db2 RET open JUSTRETURN > 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) > 89938 db2 RET getdomainname 0 > 89938 db2 CALL open(0xbfbfc7e8,0x801,0) > 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" > 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" > 89938 db2 RET open JUSTRETURN > 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) > 89938 db2 RET getdomainname 0 > 89938 db2 CALL open(0xbfbfc7e8,0x801,0) > 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" > 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" > 89938 db2 RET open JUSTRETURN > 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) > 89938 db2 RET getdomainname 0 > 89938 db2 CALL open(0xbfbfc7e8,0x801,0) > 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" > 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" > 89938 db2 RET open JUSTRETURN > 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) > 89938 db2 RET getdomainname 0 > 89938 db2 CALL open(0xbfbfc7e8,0x801,0) > 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" > 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" > 89938 db2 RET open JUSTRETURN > 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) > > Google seems to be suspiciously silent about DB2 on FreeBSD. > JUSTRETURN in linuxolator means ENOENT - 'No such file or directory' error. -- Have fun! chd From bsam at ipt.ru Mon May 19 16:31:28 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Mon May 19 16:31:37 2008 Subject: wine rebuilds font smth every time In-Reply-To: <48318E4D.1070009@icyb.net.ua> (Andriy Gapon's message of "Mon\, 19 May 2008 17\:27\:25 +0300") References: <48318E4D.1070009@icyb.net.ua> Message-ID: <93743292@ipt.ru> On Mon, 19 May 2008 17:27:25 +0300 Andriy Gapon wrote: > Every time I run wine it starts rebuilding something related to fonts. > This takes quite long, only after that a windows program is actually > executed. > Very annoying. > This is wine-0.9.59,1, installed from a package, no extra configuration. > What could be causing this? > Any way to fix/workaround? The current version of wine is 0.9.61,1. Sometime ago wine has got rid of fontconfig dependency and the distribution contains fonts. -- HTH and WBR, bsam From itetcu at FreeBSD.org Mon May 19 19:01:10 2008 From: itetcu at FreeBSD.org (Ion-Mihai Tetcu) Date: Mon May 19 19:34:09 2008 Subject: ports with bad plist when NO{DOCS,EXAMPLES,PORTDATA} defined Message-ID: <20080519215010.68ce1dff@it.buh.tecnik93.com> Hi, If this problem is already fixed, please ignore this email. Out ports infrastructure provides a set of variables to control the installation of various types of documentation: NO_INSTALL_MANPAGES, NOPORTDOCS, NOPORTEXAMPLES, NOPORTDATA. A description for each of them can be found in ports/Mk/bsd.port.mk. They can be used to build stripped-down packages from our ports, a useful feature for systems where disk space is a premium (like embedded systems, etc.) In theory, for any port built with a NO* var defined the corresponding dirs and files shouldn't be installed. In practice we don't stress this, but at minimum we require is that the plist is correct - and this is what I tested. I will continue with the other categories, then I'll start testing for NO_INSTALL_MANPAGES. I'm also setting up an semi-automated system to test the ports as near to commit time as my available hardware permits. I have just finished a test build of devel/* ports and their dependencies on my amd64 tinderbox with: > m /usr/local/tinderbox/portstrees/FreeBSD/portstree.env export FORCE_PACKAGE=yes export NOPORTDOCS=yes export NOPORTEXAMPLES=yes export NOPORTDATA=yes The relevant version details: System FreeBSD 7 (RELENG_7) 2008-05-09 23:13:31 Ports Tree FreeBSD ports tree 2008-05-10 00:22:00 The build was done via: ./tc addPort -b ${_build} -r -d ${PORT} -o ./tinderbuild -noduds -nullfs -plistcheck -b ${_build} ${PORT} The following ports fail with 3 types of errors: - they install docs, examples or data files or dirs when they shouldn't because of above vars being defined and they don't list them in the plist. - they don't install some docs, examples or data files or dirs but they list them in the plist. - they confuse the meaning of one of the above NO* variables with an other or with NO_INSTALL_MANPAGES A common mistake seems to be the patting of portlint(1) by adding %%PORTDOCS%% without checking if those files are installed or not. Please try to make your port obey the NO* vars, not "fix" it by installing those files unconditionally. The build logs can be found at: http://t64.tecnik93.com/index.php?action=failed_buildports&build=7-STABLE-FTP If you commit a fix please let me know; if you submit a PR to fix your port please CC me on it and I'll commit it; also please let as know if you intend to work on the unmaintained ports so that we don't duplicate our efforts. This is the list of ports that fail and their maintianers: devel/vstr - ports@FreeBSD.org devel/tigcc - jaj@hcl-club.lu devel/templ - ports@FreeBSD.org devel/tclcheck - ports@FreeBSD.org devel/styx - ports@FreeBSD.org devel/avr-libc - joerg@freebsd.org devel/silc-toolkit - ports@FreeBSD.org devel/py-spark - ports@FreeBSD.org devel/ruby-rbprof - sean@chittenden.org graphics/ruby-cairo - mezz@FreeBSD.org graphics/cairomm - gnome@FreeBSD.org graphics/linux-png - freebsd-emulation@FreeBSD.org devel/quilt - doj@cubic.org devel/py-cxx - lwhsu@FreeBSD.org devel/py-turbojson - nivit@FreeBSD.org devel/py-pycallgraph - lwhsu@FreeBSD.org devel/ice - shoesoft@gmx.net devel/py-grouch - ports@FreeBSD.org www/apache20 - clement@FreeBSD.org devel/ppl - ports@FreeBSD.org dns/libidn - krion@FreeBSD.org devel/picasm - ports@FreeBSD.org devel/pcre++ - ports@FreeBSD.org x11-toolkits/xmhtml - ports@FreeBSD.org security/gnupg1 - kuriyama@FreeBSD.org devel/p5-Class-MOP - lbr@FreeBSD.org devel/cdk - MrL0Lz@gmail.com devel/ocaml-sem - argentoff@gmail.com devel/ipython - dryice@FreeBSD.org devel/ncurses - rafan@FreeBSD.org devel/ncc - vs@FreeBSD.org devel/naturaldocs - laszlof@FreeBSD.org devel/monotone - lapo@lapo.it devel/mercurial - roberto@FreeBSD.org devel/makeplus - sergei@FreeBSD.org devel/m17n-docs - ports@FreeBSD.org devel/libslang2 - garga@FreeBSD.org textproc/xerces-c2 - kenm@icarz.com devel/libdict - ports@FreeBSD.org devel/libcheck - mikeh@FreeBSD.org lang/ghc - haskell@FreeBSD.org devel/glibmm-reference - gnome@FreeBSD.org devel/gengetopt - laszlof@FreeBSD.org lang/gauche - erik@smluc.org devel/fpp - ports@FreeBSD.org devel/flatzebra - edwin@mavetju.org net/skstream - oliver@FreeBSD.org devel/epm - openoffice@FreeBSD.org devel/cvsmapfs - rip@pinetec.co.za devel/cons - rv@gnu.org devel/cogito - anholt@FreeBSD.org devel/c4 - araujo@FreeBSD.org Thanks for your work on making FreeBSD better, -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080519/356ea0ce/signature.pgp From avg at icyb.net.ua Tue May 20 09:46:02 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue May 20 09:46:05 2008 Subject: wine rebuilds font smth every time In-Reply-To: <93743292@ipt.ru> References: <48318E4D.1070009@icyb.net.ua> <93743292@ipt.ru> Message-ID: <48329DD7.2070909@icyb.net.ua> on 19/05/2008 19:30 Boris Samorodov said the following: > On Mon, 19 May 2008 17:27:25 +0300 Andriy Gapon wrote: > >> Every time I run wine it starts rebuilding something related to fonts. >> This takes quite long, only after that a windows program is actually >> executed. >> Very annoying. >> This is wine-0.9.59,1, installed from a package, no extra configuration. > >> What could be causing this? >> Any way to fix/workaround? > > The current version of wine is 0.9.61,1. Sometime ago wine has got rid > of fontconfig dependency and the distribution contains fonts. Thank you! I usually use pre-built packages on this system, but made an exception for this port. Now everything works great. BTW, is there a schedule for package builds (6-stable and 7-stable)? -- Andriy Gapon From bsam at ipt.ru Tue May 20 16:06:48 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Tue May 20 16:06:59 2008 Subject: wine rebuilds font smth every time In-Reply-To: <48329DD7.2070909@icyb.net.ua> (Andriy Gapon's message of "Tue\, 20 May 2008 12\:45\:59 +0300") References: <48318E4D.1070009@icyb.net.ua> <93743292@ipt.ru> <48329DD7.2070909@icyb.net.ua> Message-ID: <52614981@ipt.ru> On Tue, 20 May 2008 12:45:59 +0300 Andriy Gapon wrote: > on 19/05/2008 19:30 Boris Samorodov said the following: > > On Mon, 19 May 2008 17:27:25 +0300 Andriy Gapon wrote: > > > >> Every time I run wine it starts rebuilding something related to fonts. > >> This takes quite long, only after that a windows program is actually > >> executed. > >> Very annoying. > >> This is wine-0.9.59,1, installed from a package, no extra configuration. > > > >> What could be causing this? > >> Any way to fix/workaround? > > > > The current version of wine is 0.9.61,1. Sometime ago wine has got rid > > of fontconfig dependency and the distribution contains fonts. > Thank you! I usually use pre-built packages So do I. But I prepare them myself with the help of ports-mgmt/tinderbox. Try it and you'll like it. > on this system, but made > an exception for this port. Now everything works great. > BTW, is there a schedule for package builds (6-stable and 7-stable)? -- WBR, bsam From uspoerlein at gmail.com Tue May 20 16:42:48 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Tue May 20 16:42:53 2008 Subject: Running IBM DB2 Client V8.1 under FreeBSD In-Reply-To: References: <7ad7ddd90805190825j4ab17560k3b0296ac00c4a4c9@mail.gmail.com> Message-ID: <20080520160343.GA1562@roadrunner.spoerlein.net> On Mon, 19.05.2008 at 16:10:11 +0400, Chagin Dmitry wrote: > On Mon, 19 May 2008, Ulrich Spoerlein wrote: > > did anyone accomplish this feat? I have a DB/2 Client installation > > copied over to a FreeBSD 6.3 system and while the db2(1) binary > > starts, it runs into an endless loop. > > > > 89938 db2 CALL open(0xbfbfc7e8,0x801,0) > > 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" > > 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" > > 89938 db2 RET open JUSTRETURN > > 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) > > > > JUSTRETURN in linuxolator means ENOENT - 'No such file or directory' error. Thanks for the hint. I should've looked more carefully, turns out this was a permissions problem. (The directory in question was owned by the user, but 755 instead of 775, wtf?) Anyway, the db2 CLI client seems to be working fine, but getting the Perl DBD::DB2 module to work seems to be impossible. It compiles fine, but it will result in a FreeBSD perl library, which itself is linked against a Linux library. Is there a way to make this work? Short of using a linux perl binary+module? Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From chagin.dmitry at gmail.com Tue May 20 18:27:30 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Tue May 20 18:27:34 2008 Subject: Running IBM DB2 Client V8.1 under FreeBSD In-Reply-To: <20080520160343.GA1562@roadrunner.spoerlein.net> References: <7ad7ddd90805190825j4ab17560k3b0296ac00c4a4c9@mail.gmail.com> <20080520160343.GA1562@roadrunner.spoerlein.net> Message-ID: On Tue, 20 May 2008, Ulrich Spoerlein wrote: > On Mon, 19.05.2008 at 16:10:11 +0400, Chagin Dmitry wrote: >> On Mon, 19 May 2008, Ulrich Spoerlein wrote: >> > did anyone accomplish this feat? I have a DB/2 Client installation >> > copied over to a FreeBSD 6.3 system and while the db2(1) binary >> > starts, it runs into an endless loop. >> > >> > 89938 db2 CALL open(0xbfbfc7e8,0x801,0) >> > 89938 db2 NAMI "/compat/linux/home/dtinst/sqllib/tmp/R1116180A8942" >> > 89938 db2 NAMI "/home/dtinst/sqllib/tmp/R1116180A8942" >> > 89938 db2 RET open JUSTRETURN >> > 89938 db2 CALL getdomainname(0xbfbfc930,0xbfbfc938) >> > >> >> JUSTRETURN in linuxolator means ENOENT - 'No such file or directory' error. > > Thanks for the hint. I should've looked more carefully, turns out this > was a permissions problem. (The directory in question was owned by the > user, but 755 instead of 775, wtf?) > > Anyway, the db2 CLI client seems to be working fine, but getting the > Perl DBD::DB2 module to work seems to be impossible. It compiles fine, > but it will result in a FreeBSD perl library, which itself is linked > against a Linux library. > > Is there a way to make this work? Short of using a linux perl > binary+module? > i think that you need to make at first linux-perl port. -- Have fun! chd From chagin.dmitry at gmail.com Wed May 21 05:23:03 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Wed May 21 05:23:07 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org In-Reply-To: <200805191106.m4JB6oBF011533@freefall.freebsd.org> References: <200805191106.m4JB6oBF011533@freefall.freebsd.org> Message-ID: On Mon, 19 May 2008, FreeBSD bugmaster wrote: > Current FreeBSD problem reports > Critical problems > Serious problems > > S Tracker Resp. Description > -------------------------------------------------------------------------------- > o kern/21463 emulation [linux] Linux compatability mode should not allow setu > o kern/97326 emulation [linux] file descriptor leakage in linux emulation > o kern/117010 emulation [linux] linux_getdents() get something like buffer ove > about 117010... Can somebody test this patch on amd64 and i386? It is necessary linux_base-f8, 2.6.16, -current. thnx! diff --git a/src/sys/compat/linux/linux_file.c b/src/sys/compat/linux/linux_file.c index a843659..0acd07f 100644 --- a/src/sys/compat/linux/linux_file.c +++ b/src/sys/compat/linux/linux_file.c @@ -240,6 +240,7 @@ linux_lseek(struct thread *td, struct linux_lseek_args *args) return error; } +#if defined(__i386__) || (defined(__amd64__) && defined(COMPAT_LINUX32)) int linux_llseek(struct thread *td, struct linux_llseek_args *args) { @@ -278,6 +279,7 @@ linux_readdir(struct thread *td, struct linux_readdir_args *args) lda.count = 1; return linux_getdents(td, &lda); } +#endif /* __i386__ || (__amd64__ && COMPAT_LINUX32) */ /* * Note that linux_getdents(2) and linux_getdents64(2) have the same @@ -289,7 +291,7 @@ linux_readdir(struct thread *td, struct linux_readdir_args *args) */ struct l_dirent { - l_long d_ino; + l_ino_t d_ino; l_off_t d_off; l_ushort d_reclen; char d_name[LINUX_NAME_MAX + 1]; @@ -536,6 +538,7 @@ linux_getdents64(struct thread *td, struct linux_getdents64_args *args) return (getdents_common(td, args, 1)); } + /* * These exist mainly for hooks for doing /compat/linux translation. */ @@ -905,6 +908,7 @@ linux_truncate(struct thread *td, struct linux_truncate_args *args) return (error); } +#if defined(__i386__) || (defined(__amd64__) && defined(COMPAT_LINUX32)) int linux_truncate64(struct thread *td, struct linux_truncate64_args *args) { @@ -922,6 +926,8 @@ linux_truncate64(struct thread *td, struct linux_truncate64_args *args) LFREEPATH(path); return (error); } +#endif /* __i386__ || (__amd64__ && COMPAT_LINUX32) */ + int linux_ftruncate(struct thread *td, struct linux_ftruncate_args *args) { @@ -1119,6 +1125,7 @@ linux_mount(struct thread *td, struct linux_mount_args *args) return (error); } +#if defined(__i386__) || (defined(__amd64__) && defined(COMPAT_LINUX32)) int linux_oldumount(struct thread *td, struct linux_oldumount_args *args) { @@ -1128,6 +1135,7 @@ linux_oldumount(struct thread *td, struct linux_oldumount_args *args) args2.flags = 0; return (linux_umount(td, &args2)); } +#endif /* __i386__ || (__amd64__ && COMPAT_LINUX32) */ int linux_umount(struct thread *td, struct linux_umount_args *args) @@ -1258,7 +1266,7 @@ bsd_to_linux_flock64(struct flock *bsd_flock, struct l_flock64 *linux_flock) #endif /* __i386__ || (__amd64__ && COMPAT_LINUX32) */ static int -fcntl_common(struct thread *td, struct linux_fcntl64_args *args) +fcntl_common(struct thread *td, struct linux_fcntl_args *args) { struct l_flock linux_flock; struct flock bsd_flock; @@ -1382,17 +1390,13 @@ fcntl_common(struct thread *td, struct linux_fcntl64_args *args) int linux_fcntl(struct thread *td, struct linux_fcntl_args *args) { - struct linux_fcntl64_args args64; #ifdef DEBUG if (ldebug(fcntl)) printf(ARGS(fcntl, "%d, %08x, *"), args->fd, args->cmd); #endif - args64.fd = args->fd; - args64.cmd = args->cmd; - args64.arg = args->arg; - return (fcntl_common(td, &args64)); + return (fcntl_common(td, args)); } #if defined(__i386__) || (defined(__amd64__) && defined(COMPAT_LINUX32)) @@ -1401,6 +1405,7 @@ linux_fcntl64(struct thread *td, struct linux_fcntl64_args *args) { struct l_flock64 linux_flock; struct flock bsd_flock; + struct linux_fcntl_args fcntl_args; int error; #ifdef DEBUG @@ -1441,7 +1446,10 @@ linux_fcntl64(struct thread *td, struct linux_fcntl64_args *args) (intptr_t)&bsd_flock)); } - return (fcntl_common(td, args)); + fcntl_args.fd = args->fd; + fcntl_args.cmd = args->cmd; + fcntl_args.arg = args->arg; + return (fcntl_common(td, &fcntl_args)); } #endif /* __i386__ || (__amd64__ && COMPAT_LINUX32) */ -- Have fun! chd From Alexander at Leidinger.net Wed May 21 06:08:27 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed May 21 06:08:31 2008 Subject: Running IBM DB2 Client V8.1 under FreeBSD In-Reply-To: <20080520160343.GA1562@roadrunner.spoerlein.net> References: <7ad7ddd90805190825j4ab17560k3b0296ac00c4a4c9@mail.gmail.com> <20080520160343.GA1562@roadrunner.spoerlein.net> Message-ID: <20080521080820.427629jjtsoea6ac@webmail.leidinger.net> Quoting Ulrich Spoerlein (from Tue, 20 May 2008 18:03:43 +0200): > Anyway, the db2 CLI client seems to be working fine, but getting the > Perl DBD::DB2 module to work seems to be impossible. It compiles fine, > but it will result in a FreeBSD perl library, which itself is linked > against a Linux library. > > Is there a way to make this work? Short of using a linux perl > binary+module? AFAIK a perl module is just some kind of a library (from a compiler point of view), so it depends on which symbols the linux library uses and if you are willing to write some compat-shims. In the icc port we have some black magic to be able to link the linux-libs which come with icc to create a native FreeBSD program, maybe you can borrow some of this (objcpy in the Makefile and some stuff in files/). Feel free to ask here if you have some specific questions regarding the icc black magic. Bye, Alexander. -- Don't ever slam a door; you might want to go back. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From rdivacky at freebsd.org Wed May 21 08:05:05 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Wed May 21 08:05:08 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org In-Reply-To: References: <200805191106.m4JB6oBF011533@freefall.freebsd.org> Message-ID: <20080521080422.GA69849@freebsd.org> On Wed, May 21, 2008 at 01:09:17AM +0400, Chagin Dmitry wrote: > On Mon, 19 May 2008, FreeBSD bugmaster wrote: > > >Current FreeBSD problem reports > >Critical problems > >Serious problems > > > >S Tracker Resp. Description > >-------------------------------------------------------------------------------- > >o kern/21463 emulation [linux] Linux compatability mode should not > >allow setu > >o kern/97326 emulation [linux] file descriptor leakage in linux > >emulation > >o kern/117010 emulation [linux] linux_getdents() get something like > >buffer ove > > > > about 117010... > Can somebody test this patch on amd64 and i386? > It is necessary linux_base-f8, 2.6.16, -current. can you describe the idea behind the patch? why do you think it's correct to replace fcntl64 with fcntl args? I'll take a look at this some further but I want to know the rationale behind this thnx! roman From chagin.dmitry at gmail.com Wed May 21 17:39:16 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Wed May 21 17:39:19 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org In-Reply-To: <20080521080422.GA69849@freebsd.org> References: <200805191106.m4JB6oBF011533@freefall.freebsd.org> <20080521080422.GA69849@freebsd.org> Message-ID: On Wed, 21 May 2008, Roman Divacky wrote: > On Wed, May 21, 2008 at 01:09:17AM +0400, Chagin Dmitry wrote: >> On Mon, 19 May 2008, FreeBSD bugmaster wrote: >> >> >Current FreeBSD problem reports >> >Critical problems >> >Serious problems >> > >> >S Tracker Resp. Description >> >-------------------------------------------------------------------------------- >> >o kern/21463 emulation [linux] Linux compatability mode should not >> >allow setu >> >o kern/97326 emulation [linux] file descriptor leakage in linux >> >emulation >> >o kern/117010 emulation [linux] linux_getdents() get something like >> >buffer ove >> > >> >> about 117010... >> Can somebody test this patch on amd64 and i386? >> It is necessary linux_base-f8, 2.6.16, -current. > > can you describe the idea behind the patch? why do you think > it's correct to replace fcntl64 with fcntl args? > this diff from linux64 port, therefore in it a lot of not concerning to getdents(), but it will not prevent test fcntl64 with fcntl have identical args in linux, but linux x86-64 has no fcntl64 syscall to getdents concerns only changes of ino member of struct l_dirent, essence in that i too had problem with getdents. and i have not understood after what changes it have worked correctly. it disturbs me. -- Have fun! chd From rdivacky at freebsd.org Wed May 21 17:42:42 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Wed May 21 17:42:46 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org In-Reply-To: References: <200805191106.m4JB6oBF011533@freefall.freebsd.org> <20080521080422.GA69849@freebsd.org> Message-ID: <20080521174200.GA15241@freebsd.org> On Wed, May 21, 2008 at 09:39:01PM +0400, Chagin Dmitry wrote: > On Wed, 21 May 2008, Roman Divacky wrote: > > >On Wed, May 21, 2008 at 01:09:17AM +0400, Chagin Dmitry wrote: > >>On Mon, 19 May 2008, FreeBSD bugmaster wrote: > >> > >>>Current FreeBSD problem reports > >>>Critical problems > >>>Serious problems > >>> > >>>S Tracker Resp. Description > >>>-------------------------------------------------------------------------------- > >>>o kern/21463 emulation [linux] Linux compatability mode should not > >>>allow setu > >>>o kern/97326 emulation [linux] file descriptor leakage in linux > >>>emulation > >>>o kern/117010 emulation [linux] linux_getdents() get something like > >>>buffer ove > >>> > >> > >>about 117010... > >>Can somebody test this patch on amd64 and i386? > >>It is necessary linux_base-f8, 2.6.16, -current. > > > >can you describe the idea behind the patch? why do you think > >it's correct to replace fcntl64 with fcntl args? > > > > this diff from linux64 port, therefore in it a lot of not concerning > to getdents(), but it will not prevent test > > fcntl64 with fcntl have identical args in linux, but linux x86-64 has > no fcntl64 syscall > > to getdents concerns only changes of ino member of struct l_dirent, > essence in that i too had problem with getdents. and i have not > understood after what changes it have worked correctly. it disturbs me. so.. you are saying that you dont know why but it fixes the problem for you. right? btw.. your git repo seems to be down From chagin.dmitry at gmail.com Wed May 21 19:26:00 2008 From: chagin.dmitry at gmail.com (Chagin Dmitry) Date: Wed May 21 19:26:04 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org In-Reply-To: <20080521174200.GA15241@freebsd.org> References: <200805191106.m4JB6oBF011533@freefall.freebsd.org> <20080521080422.GA69849@freebsd.org> <20080521174200.GA15241@freebsd.org> Message-ID: On Wed, 21 May 2008, Roman Divacky wrote: > On Wed, May 21, 2008 at 09:39:01PM +0400, Chagin Dmitry wrote: >> On Wed, 21 May 2008, Roman Divacky wrote: >> >> >On Wed, May 21, 2008 at 01:09:17AM +0400, Chagin Dmitry wrote: >> >>On Mon, 19 May 2008, FreeBSD bugmaster wrote: >> >> >> >>>Current FreeBSD problem reports >> >>>Critical problems >> >>>Serious problems >> >>> >> >>>S Tracker Resp. Description >> >>>-------------------------------------------------------------------------------- >> >>>o kern/21463 emulation [linux] Linux compatability mode should not >> >>>allow setu >> >>>o kern/97326 emulation [linux] file descriptor leakage in linux >> >>>emulation >> >>>o kern/117010 emulation [linux] linux_getdents() get something like >> >>>buffer ove >> >>> >> >> >> >>about 117010... >> >>Can somebody test this patch on amd64 and i386? >> >>It is necessary linux_base-f8, 2.6.16, -current. >> > >> >can you describe the idea behind the patch? why do you think >> >it's correct to replace fcntl64 with fcntl args? >> > >> >> this diff from linux64 port, therefore in it a lot of not concerning >> to getdents(), but it will not prevent test >> >> fcntl64 with fcntl have identical args in linux, but linux x86-64 has >> no fcntl64 syscall >> >> to getdents concerns only changes of ino member of struct l_dirent, >> essence in that i too had problem with getdents. and i have not >> understood after what changes it have worked correctly. it disturbs me. > > so.. you are saying that you dont know why but it fixes the problem for > you. right? ugu, i don't know what fixed the problem, it disturbs me ) > > btw.. your git repo seems to be down ups... firewall, now all ok. sorry, i have forgotten about it. -- Have fun! chd From bsam at ipt.ru Sat May 24 09:05:33 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Sat May 24 09:05:37 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <20080524073145.M76509@martymac.com> (Ganael LAPLANCHE's message of "Sat\, 24 May 2008 10\:08\:56 +0200 \(CEST\)") References: <20080524073145.M76509@martymac.com> Message-ID: <07923414@ipt.ru> (the topic is emulation@ relevant, added to CC) On Sat, 24 May 2008 10:08:56 +0200 (CEST) Ganael LAPLANCHE wrote: > Hi everybody, > One of my ports, archivers/linux-par2cmdline, uses a RPM that contains > documentation, but does not (yet) handle the NOPORTDOCS option. An error is > generated in Tinderbox and complains that documentation files remain on the > filesystem after deinstallation. See : > http://t64.tecnik93.com/logs/7-STABLE-FTP/linux-par2cmdline-0.4.log > as reported by Itetcu. > My port uses both the USE_LINUX_RPM facility and PORTDOCS variable. > What happens is that passing NOPORTDOCS=yes to the port is ignored by > bsd.linux-rpm.mk's do-install target which installs documentation anyway (as any > other file). As I have also declared documentation files with the PORTDOCS > variable, they are *not* deinstalled when using NOPORTDOCS=yes. > So, I am a bit stuck since bsd.linux-rpm.mk does not seem to provide a way to > handle that case... > I see two options : > - Override the do-install target and do things manually, which seems a bad idea > since several actions are involved in installing linux files (brandelf, cpio, ...) > - Do not use PORTDOCS option anymore and treat doc files as any other file, but > this implies installing documentation files even if it has not been requested by > the user. I could even use AUTOMATIC_PLIST for that... > What would be the best option ? Would you have any other idea ? I'd suggest another option. What about fixing bsd.linux-rpm.mk? Ex., one may introduce, say, a pre-install target (or even do it at the very beginning of a do-install stage) and conditionally delete unneeded files from WRKDIR (so they won't get installed at do-install stage). -- WBR, bsam From ganael.laplanche at martymac.com Sat May 24 15:43:49 2008 From: ganael.laplanche at martymac.com (Ganael LAPLANCHE) Date: Sat May 24 15:43:53 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <07923414@ipt.ru> References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> Message-ID: <20080524150909.M12444@martymac.com> On Sat, 24 May 2008 13:04:57 +0400, Boris Samorodov wrote > I'd suggest another option. What about fixing bsd.linux-rpm.mk? Ex., > one may introduce, say, a pre-install target (or even do it at the > very beginning of a do-install stage) and conditionally delete > unneeded files from WRKDIR (so they won't get installed at do-install > stage). Thanks for your answer :) Of course, fixing bsd.linux-rpm.mk would be the best option ! Your idea is good, but PORTDOCS would not be useable for that purpose. It cannot be used to identify files to delete because it is relative to the destination target (DOCSDIR), not to WRKDIR or WRKSRC. A good idea may be to introduce a new variable, say RMWRKDIRFILES= (something like that) and a target, as you suggest, that would delete all those files relative to WRKDIR, before the install target. Note that this idea is not limited to bsd.linux.mk and could be introduced more generally in bsd.port.mk. Of course, considering my original post and port problem, I can do this manually if this idea is not a good one :p Gana?l LAPLANCHE ganael.laplanche@martymac.com http://www.martymac.com From ganael.laplanche at martymac.com Sat May 24 16:05:43 2008 From: ganael.laplanche at martymac.com (Ganael LAPLANCHE) Date: Sat May 24 16:05:50 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <20080524150909.M12444@martymac.com> References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> <20080524150909.M12444@martymac.com> Message-ID: <20080524160433.M17651@martymac.com> On Sat, 24 May 2008 17:27:04 +0200 (CEST), Ganael LAPLANCHE wrote > On Sat, 24 May 2008 13:04:57 +0400, Boris Samorodov wrote > > > I'd suggest another option. What about fixing bsd.linux-rpm.mk? Ex., > > one may introduce, say, a pre-install target (or even do it at the > > very beginning of a do-install stage) and conditionally delete > > unneeded files from WRKDIR (so they won't get installed at do-install > > stage). > > Thanks for your answer :) > > Of course, fixing bsd.linux-rpm.mk would be the best option ! > > Your idea is good, but PORTDOCS would not be useable for that purpose. > It cannot be used to identify files to delete because it is relative > to the destination target (DOCSDIR), not to WRKDIR or WRKSRC. Wait... DOCSDIR_REL (relative to PREFIX) is derived from DOCSDIR and *may* be also always relative to WRKDIR for linux RPMs, since RPM installation is just a copy of a tree structure which is relative to PREFIX. So maybe I was wrong here. Anyway, if I add that to my archivers/linux-par2cmdline port's Makefile : .if defined(NOPORTDOCS) post-extract: .for x in ${PORTDOCS} @${RM} ${WRKDIR}/${DOCSDIR_REL}/${x} .endfor @${RMDIR} ${WRKDIR}/${DOCSDIR_REL}/ .endif It works :) So I think I'll stick to that solution at the moment. Note that two other linux ports are subject to the same problem as mine : /usr/ports/graphics/linux-png and /usr/ports/graphics/linux-png10. Best regards, Gana?l LAPLANCHE ganael.laplanche@martymac.com http://www.martymac.com From bsam at ipt.ru Sat May 24 16:50:03 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Sat May 24 16:50:09 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <20080524160433.M17651@martymac.com> (Ganael LAPLANCHE's message of "Sat\, 24 May 2008 18\:05\:42 +0200 \(CEST\)") References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> <20080524150909.M12444@martymac.com> <20080524160433.M17651@martymac.com> Message-ID: <15111974@ipt.ru> On Sat, 24 May 2008 18:05:42 +0200 (CEST) Ganael LAPLANCHE wrote: > On Sat, 24 May 2008 17:27:04 +0200 (CEST), Ganael LAPLANCHE wrote > > On Sat, 24 May 2008 13:04:57 +0400, Boris Samorodov wrote > > > > > I'd suggest another option. What about fixing bsd.linux-rpm.mk? Ex., > > > one may introduce, say, a pre-install target (or even do it at the > > > very beginning of a do-install stage) and conditionally delete > > > unneeded files from WRKDIR (so they won't get installed at do-install > > > stage). > > > > Thanks for your answer :) > > > > Of course, fixing bsd.linux-rpm.mk would be the best option ! > > > > Your idea is good, but PORTDOCS would not be useable for that purpose. > > It cannot be used to identify files to delete because it is relative > > to the destination target (DOCSDIR), not to WRKDIR or WRKSRC. > Wait... DOCSDIR_REL (relative to PREFIX) is derived from DOCSDIR and *may* be > also always relative to WRKDIR for linux RPMs, since RPM installation is just a > copy of a tree structure which is relative to PREFIX. So maybe I was wrong here. > Anyway, if I add that to my archivers/linux-par2cmdline port's Makefile : > .if defined(NOPORTDOCS) > post-extract: > .for x in ${PORTDOCS} > @${RM} ${WRKDIR}/${DOCSDIR_REL}/${x} > .endfor > @${RMDIR} ${WRKDIR}/${DOCSDIR_REL}/ > .endif > It works :) So I think I'll stick to that solution at the moment. Great, but I'd say that it should be done a little bit later (may be at pre-install stage). "Extract" stage according to bsd.ports.mk "Unpacks ${DISTFILES} into ${WRKDIR}". > Note that two > other linux ports are subject to the same problem as mine : > /usr/ports/graphics/linux-png and /usr/ports/graphics/linux-png10. Yes, that's why I said that fixing bsd.linux-rpm.mk is a better idea. If you can suggest a patch and send-pr it, that would be great! -- WBR, bsam From ganael.laplanche at martymac.com Sat May 24 17:25:05 2008 From: ganael.laplanche at martymac.com (Ganael LAPLANCHE) Date: Sat May 24 17:25:13 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <15111974@ipt.ru> References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> <20080524150909.M12444@martymac.com> <20080524160433.M17651@martymac.com> <15111974@ipt.ru> Message-ID: <20080524171811.M48751@martymac.com> On Sat, 24 May 2008 20:49:29 +0400, Boris Samorodov wrote > Great, but I'd say that it should be done a little bit later (may be > at pre-install stage). Not sure about that because when using AUTOMATIC_PLIST in bsd.linux-rpm.mk, pre-install depends on target linux-rpm-generate-plist. So, plist is generated *before* pre-install target. Removing files at pre-install target would break the plist generated. Or am I wrong ? Moreover, I like to know that after the post-extract stage, WRKDIR is clean and has each file I want to work with... > Yes, that's why I said that fixing bsd.linux-rpm.mk is a better idea. > If you can suggest a patch and send-pr it, that would be great! I'll try to, but I won't have much time these days :p Gana?l LAPLANCHE ganael.laplanche@martymac.com http://www.martymac.com From Alexander at Leidinger.net Sat May 24 17:35:55 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat May 24 17:36:03 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <15111974@ipt.ru> References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> <20080524150909.M12444@martymac.com> <20080524160433.M17651@martymac.com> <15111974@ipt.ru> Message-ID: <20080524193545.0167e8a4@deskjail> Quoting Boris Samorodov (Sat, 24 May 2008 20:49:29 +0400): > On Sat, 24 May 2008 18:05:42 +0200 (CEST) Ganael LAPLANCHE wrote: > > On Sat, 24 May 2008 17:27:04 +0200 (CEST), Ganael LAPLANCHE wrote > > > On Sat, 24 May 2008 13:04:57 +0400, Boris Samorodov wrote > > > > > > > I'd suggest another option. What about fixing bsd.linux-rpm.mk? Ex., > > > > one may introduce, say, a pre-install target (or even do it at the > > > > very beginning of a do-install stage) and conditionally delete > > > > unneeded files from WRKDIR (so they won't get installed at do-install > > > > stage). > > > > > > Thanks for your answer :) > > > > > > Of course, fixing bsd.linux-rpm.mk would be the best option ! > > > > > > Your idea is good, but PORTDOCS would not be useable for that purpose. > > > It cannot be used to identify files to delete because it is relative > > > to the destination target (DOCSDIR), not to WRKDIR or WRKSRC. > > > Wait... DOCSDIR_REL (relative to PREFIX) is derived from DOCSDIR and *may* be > > also always relative to WRKDIR for linux RPMs, since RPM installation is just a > > copy of a tree structure which is relative to PREFIX. So maybe I was wrong here. > > Anyway, if I add that to my archivers/linux-par2cmdline port's Makefile : > > > .if defined(NOPORTDOCS) > > post-extract: > > .for x in ${PORTDOCS} > > @${RM} ${WRKDIR}/${DOCSDIR_REL}/${x} > > .endfor > > @${RMDIR} ${WRKDIR}/${DOCSDIR_REL}/ > > .endif > > > It works :) So I think I'll stick to that solution at the moment. > > Great, but I'd say that it should be done a little bit later (may be > at pre-install stage). "Extract" stage according to bsd.ports.mk > "Unpacks ${DISTFILES} into ${WRKDIR}". Removing unwanted stuff in post-extract is not uncommon. I don't think a patch for linux-rpm.mk with something like this would be a bad solution. Bye, Alexander. -- Cats, no less liquid than their shadows, offer no angles to the wind. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From Alexander at Leidinger.net Sat May 24 17:38:55 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat May 24 17:38:59 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <20080524171811.M48751@martymac.com> References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> <20080524150909.M12444@martymac.com> <20080524160433.M17651@martymac.com> <15111974@ipt.ru> <20080524171811.M48751@martymac.com> Message-ID: <20080524193844.44143bdc@deskjail> Quoting "Ganael LAPLANCHE" (Sat, 24 May 2008 19:25:03 +0200 (CEST)): > On Sat, 24 May 2008 20:49:29 +0400, Boris Samorodov wrote > > > Great, but I'd say that it should be done a little bit later (may be > > at pre-install stage). > > Not sure about that because when using AUTOMATIC_PLIST in bsd.linux-rpm.mk, AUTOMATIC_PLIST is evil. For linux-rpm ports I see absolutely no value in using it (we just added it to cut down the noise from one committer, one or two ports out of all the ones we have is not going to hurt us that much). So don't care about it. Bye, Alexander. -- BOFH excuse #235: The new frame relay network hasn't bedded down the software loop transmitter yet http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From ganael.laplanche at martymac.com Sat May 24 18:00:18 2008 From: ganael.laplanche at martymac.com (Ganael LAPLANCHE) Date: Sat May 24 18:00:27 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <20080524193844.44143bdc@deskjail> References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> <20080524150909.M12444@martymac.com> <20080524160433.M17651@martymac.com> <15111974@ipt.ru> <20080524171811.M48751@martymac.com> <20080524193844.44143bdc@deskjail> Message-ID: <20080524175654.M92183@martymac.com> On Sat, 24 May 2008 19:38:44 +0200, Alexander Leidinger wrote > > Not sure about that because when using AUTOMATIC_PLIST in bsd.linux-rpm.mk, > > AUTOMATIC_PLIST is evil. For linux-rpm ports I see absolutely no value > in using it (we just added it to cut down the noise from one committer, > one or two ports out of all the ones we have is not going to hurt us > that much). So don't care about it. Ok. > > Great, but I'd say that it should be done a little bit later (may be > > at pre-install stage). "Extract" stage according to bsd.ports.mk > > "Unpacks ${DISTFILES} into ${WRKDIR}". > > Removing unwanted stuff in post-extract is not uncommon. I don't think > a patch for linux-rpm.mk with something like this would be a bad > solution. Ok, great. As I said earlier, I'll try to provide a patch to bsd.linux-rpm.mk to handle that. Thanks for your help :) Gana?l LAPLANCHE ganael.laplanche@martymac.com http://www.martymac.com From jhein at timing.com Sat May 24 18:37:08 2008 From: jhein at timing.com (John E Hein) Date: Sat May 24 18:37:17 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <20080524193545.0167e8a4@deskjail> References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> <20080524150909.M12444@martymac.com> <20080524160433.M17651@martymac.com> <15111974@ipt.ru> <20080524193545.0167e8a4@deskjail> Message-ID: <18488.23459.464314.727238@gromit.timing.com> Alexander Leidinger wrote at 19:35 +0200 on May 24, 2008: > Removing unwanted stuff in post-extract is not uncommon. I don't think > a patch for linux-rpm.mk with something like this would be a bad > solution. Removing things in post-extract _should_ be uncommon. If I want to look at the extraction of the distfile(s), running 'make extract' should give me that without removing things. I think I've heard others echo that sentiment. Why not pre- or post-patch - part of a stage that implies a modification of unpacked distfile(s)? From ganael.laplanche at martymac.com Sat May 24 19:44:13 2008 From: ganael.laplanche at martymac.com (Ganael LAPLANCHE) Date: Sat May 24 19:44:18 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <18488.23459.464314.727238@gromit.timing.com> References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> <20080524150909.M12444@martymac.com> <20080524160433.M17651@martymac.com> <15111974@ipt.ru> <20080524193545.0167e8a4@deskjail> <18488.23459.464314.727238@gromit.timing.com> Message-ID: <20080524193744.M30720@martymac.com> On Sat, 24 May 2008 12:17:07 -0600, John E Hein wrote > Why not pre- or post-patch - part of a stage that implies a > modification of unpacked distfile(s)? You are right, pre-patch may be better than post-extract in this way. I think pre-patch is better than post-patch because one does not want to patch files that won't be used in any way. It would also allow to avoid errors, not working on files that will be deleted :p I have successfully tested this patch against bsd.linux-rpm.mk with archivers/linux-par2cmdline, graphics/linux-png and /usr/ports/graphics/linux-png10 : 8<----------------------- --- bsd.linux-rpm.mk.orig 2008-05-24 20:46:04.931665759 +0200 +++ bsd.linux-rpm.mk 2008-05-24 21:32:51.721449935 +0200 @@ -105,6 +105,20 @@ BRANDELF_DIRS?= BRANDELF_FILES?= +# For ports that define PORTDOCS, be sure not to install +# documentation if NOPORTDOCS is defined +.if defined(PORTDOCS) && defined(NOPORTDOCS) +pre-patch: linux-rpm-clean-portdocs + +. if !target(linux-rpm-clean-portdocs) +linux-rpm-clean-portdocs: +.for x in ${PORTDOCS} + @${RM} -f ${WRKDIR}/${DOCSDIR_REL}/${x} +.endfor + @${RMDIR} ${WRKDIR}/${DOCSDIR_REL} +. endif +.endif + . if defined(AUTOMATIC_PLIST) . if ${USE_LINUX} == "fc4" || ${USE_LINUX:L} == "yes" 8<----------------------- Any opinion welcome ;-) Gana?l LAPLANCHE ganael.laplanche@martymac.com http://www.martymac.com From bsam at ipt.ru Sat May 24 20:01:33 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Sat May 24 20:01:41 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <20080524193744.M30720@martymac.com> (Ganael LAPLANCHE's message of "Sat\, 24 May 2008 21\:44\:12 +0200 \(CEST\)") References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> <20080524150909.M12444@martymac.com> <20080524160433.M17651@martymac.com> <15111974@ipt.ru> <20080524193545.0167e8a4@deskjail> <18488.23459.464314.727238@gromit.timing.com> <20080524193744.M30720@martymac.com> Message-ID: <49030486@ipt.ru> On Sat, 24 May 2008 21:44:12 +0200 (CEST) Ganael LAPLANCHE wrote: > On Sat, 24 May 2008 12:17:07 -0600, John E Hein wrote > > Why not pre- or post-patch - part of a stage that implies a > > modification of unpacked distfile(s)? > You are right, pre-patch may be better than post-extract in this way. I think > pre-patch is better than post-patch because one does not want to patch files > that won't be used in any way. It would also allow to avoid errors, not working > on files that will be deleted :p > I have successfully tested this patch against bsd.linux-rpm.mk with > archivers/linux-par2cmdline, graphics/linux-png and > /usr/ports/graphics/linux-png10 : > 8<----------------------- > --- bsd.linux-rpm.mk.orig 2008-05-24 20:46:04.931665759 +0200 > +++ bsd.linux-rpm.mk 2008-05-24 21:32:51.721449935 +0200 > @@ -105,6 +105,20 @@ > BRANDELF_DIRS?= > BRANDELF_FILES?= > +# For ports that define PORTDOCS, be sure not to install > +# documentation if NOPORTDOCS is defined > +.if defined(PORTDOCS) && defined(NOPORTDOCS) > +pre-patch: linux-rpm-clean-portdocs > + > +. if !target(linux-rpm-clean-portdocs) > +linux-rpm-clean-portdocs: > +.for x in ${PORTDOCS} > + @${RM} -f ${WRKDIR}/${DOCSDIR_REL}/${x} > +.endfor > + @${RMDIR} ${WRKDIR}/${DOCSDIR_REL} > +. endif > +.endif > + > . if defined(AUTOMATIC_PLIST) > . if ${USE_LINUX} == "fc4" || ${USE_LINUX:L} == "yes" > 8<----------------------- > Any opinion welcome ;-) Seems that we found a consensus here ;-) The patch is OK to me, thanks! -- WBR, bsam From ganael.laplanche at martymac.com Sat May 24 20:14:13 2008 From: ganael.laplanche at martymac.com (Ganael LAPLANCHE) Date: Sat May 24 20:14:22 2008 Subject: USE_LINUX_RPM and PORTDOCS In-Reply-To: <49030486@ipt.ru> References: <20080524073145.M76509@martymac.com> <07923414@ipt.ru> <20080524150909.M12444@martymac.com> <20080524160433.M17651@martymac.com> <15111974@ipt.ru> <20080524193545.0167e8a4@deskjail> <18488.23459.464314.727238@gromit.timing.com> <20080524193744.M30720@martymac.com> <49030486@ipt.ru> Message-ID: <20080524201330.M26904@martymac.com> On Sun, 25 May 2008 00:00:57 +0400, Boris Samorodov wrote > Seems that we found a consensus here ;-) > The patch is OK to me, thanks! Great, so I'm gonna file a PR for that one... Best regards, Gana?l LAPLANCHE ganael.laplanche@martymac.com http://www.martymac.com From edwin at FreeBSD.org Sat May 24 20:50:10 2008 From: edwin at FreeBSD.org (edwin@FreeBSD.org) Date: Sat May 24 20:50:16 2008 Subject: ports/123964: Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS Message-ID: <200805242050.m4OKoANj032302@freefall.freebsd.org> Synopsis: Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS Responsible-Changed-From-To: freebsd-ports-bugs->emulation Responsible-Changed-By: edwin Responsible-Changed-When: Sat May 24 20:50:09 UTC 2008 Responsible-Changed-Why: bsd.linux-rpm.mk is emulation territory (via the GNATS Auto Assign Tool) http://www.freebsd.org/cgi/query-pr.cgi?pr=123964 From itetcu at FreeBSD.org Sat May 24 21:26:31 2008 From: itetcu at FreeBSD.org (itetcu@FreeBSD.org) Date: Sat May 24 21:26:33 2008 Subject: ports/123960: Port fix: archivers/linux-par2cmdline - better handling of NOPORTDOCS Message-ID: <200805242126.m4OLQVRi035001@freefall.freebsd.org> Synopsis: Port fix: archivers/linux-par2cmdline - better handling of NOPORTDOCS Responsible-Changed-From-To: itetcu->emulation Responsible-Changed-By: itetcu Responsible-Changed-When: Sat May 24 21:26:31 UTC 2008 Responsible-Changed-Why: This is superceeded by 123964, if 123964 is accepted or an other solution is found; please bounce it back to me if you reject 123964. Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=123960 From samflanker at gmail.com Sun May 25 11:55:21 2008 From: samflanker at gmail.com (Vladimir Ermakov) Date: Sun May 25 11:55:26 2008 Subject: Linux kernel library Message-ID: <48394D06.2020209@gmail.com> Hello interesting project http://ixlabs.cs.pub.ro/projects/linux-kernel-library/ ==================================================== Project description The Linux kernel is an immense deposit of high quality code: over 7 million lines as of version 2.6.20. While some parts could be used in other projects, the tasks of identification, separation and maintenance of the needed chunks of code require many resources, a good understanding of the Linux architecture and high C skills. The purpose of the Linux Kernel Library project is to organize the Linux code in a library which can be used in third party projects. Example of such projects: * Linux filesystem drivers for other operating systems * schedulers for applications that need to manage some tasks * applications that would need swapping, caching or other memory management features * applications that use filesystem images ==================================================== /Vladimir Ermakov From bugmaster at FreeBSD.org Mon May 26 11:06:46 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 26 11:07:05 2008 Subject: Current problem reports assigned to freebsd-emulation@FreeBSD.org Message-ID: <200805261106.m4QB6kRR064854@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/21463 emulation [linux] Linux compatability mode should not allow setu o kern/97326 emulation [linux] file descriptor leakage in linux emulation o kern/117010 emulation [linux] linux_getdents() get something like buffer ove 3 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/11165 emulation [ibcs2] IBCS2 doesn't work correctly with PID_MAX 9999 o kern/29698 emulation [linux] [patch] linux ipcs doesn'work o kern/39201 emulation [linux] [patch] ptrace(2) and rfork(RFLINUXTHPN) confu o kern/41543 emulation [patch] [request] easier wine/w23 support a kern/72920 emulation [linux]: path "prefixing" is not done on unix domain s o kern/73777 emulation [linux] [patch] linux emulation: root dir special hand o kern/91293 emulation [svr4] [patch] *Experimental* Update to the SVR4 emula o ports/91318 emulation [fix] graphics/linux_dri: works on amd64 too o ports/121800 emulation x11-toolkits/linux-openmotif - OpenMotif upgrade to 2. o kern/122318 emulation [linux] [cmake]: Segmentation fault when running Linux o ports/123960 emulation Port fix: archivers/linux-par2cmdline - better handlin o ports/123964 emulation Mk fix: bsd.linux-rpm.mk - Handling of NOPORTDOCS 12 problems total. From itetcu at people.tecnik93.com Wed May 28 14:44:21 2008 From: itetcu at people.tecnik93.com (Ion-Mihai Tetcu) Date: Wed May 28 14:44:31 2008 Subject: graphics/linux-png: bad plist Message-ID: <20080528172804.60fdbf2d@it.buh.tecnik93.com> Hi, Bad plist (on 7-STABLE-amd64) with export FORCE_PACKAGE=yes export NOPORTDOCS=yes export NOPORTEXAMPLES=yes export NOPORTDATA=yes ======================================== ===> Building package for linux-png-1.2.8_2 Creating package /tmp/packages/All/linux-png-1.2.8_2.tbz Registering depends: linux_base-fc-4_13. Creating bzip'd tar ball in '/tmp/packages/All/linux-png-1.2.8_2.tbz' Deleting linux-png-1.2.8_2 ================================================================ === Checking filesystem state list of extra files and directories in / (not present before this port was installed but present after it was deinstalled) 15214889 4 drwxr-xr-x 2 root wheel 512 May 28 12:44 compat/linux/usr/share/doc/libpng-1.2.8 15214890 156 -rw-r--r-- 1 root wheel 79441 May 28 12:44 compat/linux/usr/share/doc/libpng-1.2.8/CHANGES 15214891 12 -rw-r--r-- 1 root wheel 4105 May 28 12:44 compat/linux/usr/share/doc/libpng-1.2.8/LICENSE 15214892 28 -rw-r--r-- 1 root wheel 13988 May 28 12:44 compat/linux/usr/share/doc/libpng-1.2.8/README 15214893 4 -rw-r--r-- 1 root wheel 1182 May 28 12:44 compat/linux/usr/share/doc/libpng-1.2.8/TODO 15214894 60 -rw-r--r-- 1 root wheel 29793 May 28 12:44 compat/linux/usr/share/doc/libpng-1.2.8/example.c 15214895 252 -rw-r--r-- 1 root wheel 127770 May 28 12:44 compat/linux/usr/share/doc/libpng-1.2.8/libpng.txt ================================================================ build of /usr/ports/graphics/linux-png ended at Wed May 28 12:44:55 UTC 2008 Thanks for your work on making FreeBSD better, -- (__) IOnut (__) (.''/// \\\'',) ^ / \/ \/ \ ^ (_\. /. .\. /_) ============================== We do not colonize. We conquer. We rule. There is no other way for us. -- Rojan, "By Any Other Name", stardate 4657.5 From rdivacky at freebsd.org Thu May 29 21:49:15 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu May 29 21:49:18 2008 Subject: [RFC]: switch to 2.6 linux emulation on default Message-ID: <20080529214829.GA79810@freebsd.org> hi, FreeBSD 7.0 contains support for running emulation of Linux 2.6 (= NPTL, futexes, TLS basically) and I'd like to switch this on default in HEAD to see if we can ship 8.0 with this emulation running on default. The advantages are obvious - ability to have newer Fedora base system (which requires 2.6 kernel), more software running better or running at all. For some time epoll() support was considered to be the last thing needed before this switch taking place but my patch is incomplete and I don't want this to hold the switch back. (yes, I am going to finish the epoll() and commit that, but it's not a matter of days) so... I'd like to switch the 2.6 emulation on default in HEAD in a week. This will help test the Linuxulator and probably squeeze out some more bugs (the getdents comes to mind), also this is a prerequisite for Linuxulator64 hitting the tree (Dmitry, BIG thanks for doing this work!) and we can always switch back if things don't work out before 8.0 is to be branches, hence... I am asking you to express your attitude towards switching to 2.6 emulation on default in a week. Speak now or forever hold your peace... thank you! roman p.s. sorry for cross-posting, please reply on emulation@ only -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080529/728c0e23/attachment.pgp From jhein at timing.com Thu May 29 22:09:53 2008 From: jhein at timing.com (John E Hein) Date: Thu May 29 22:09:56 2008 Subject: [RFC]: switch to 2.6 linux emulation on default In-Reply-To: <20080529214829.GA79810@freebsd.org> References: <20080529214829.GA79810@freebsd.org> Message-ID: <18495.10669.315131.533466@gromit.timing.com> Roman Divacky wrote at 23:48 +0200 on May 29, 2008: > I am asking you to express your attitude towards switching > to 2.6 emulation on default in a week. Speak now or forever hold > your peace... I say we do it (last month). Users can always go back via sysctl if needed. That's no problem for -current users. Notes in UPDATING files would be useful, of course. From ed at 80386.nl Fri May 30 05:06:54 2008 From: ed at 80386.nl (Ed Schouten) Date: Fri May 30 05:06:57 2008 Subject: [RFC]: switch to 2.6 linux emulation on default In-Reply-To: <20080529214829.GA79810@freebsd.org> References: <20080529214829.GA79810@freebsd.org> Message-ID: <20080530050453.GX64397@hoeg.nl> Hello Roman, * Roman Divacky wrote: > FreeBSD 7.0 contains support for running emulation of Linux 2.6 > (= NPTL, futexes, TLS basically) and I'd like to switch this > on default in HEAD to see if we can ship 8.0 with this emulation > running on default. Speaking about Linux emulation: a couple of days ago I added Linux support to my TTY code in the mpsafetty branch. This means that it can handle the things done in posix_openpt() and ptsname(). Because Linux wants the minor number to be within a certain region, the PTY driver creates a linux_device_handler for each device. ptsname() seems to do an fstat() on the controller descriptor, followed by looping on the files in /dev and /dev/pts, to find the matching device number. Unfortunately sendmsg() seems broken on amd64 with COMPAT_LINUX32. This means that SSH'ing to a Linux jail only works on i386, or on amd64 when logging in as root (in that case sshd seems to be taking a shortcut, not causing sendmsg() to be called). -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080530/ae39fcde/attachment.pgp From Alexander at Leidinger.net Fri May 30 08:50:20 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri May 30 08:50:24 2008 Subject: [RFC]: switch to 2.6 linux emulation on default In-Reply-To: <18495.10669.315131.533466@gromit.timing.com> References: <20080529214829.GA79810@freebsd.org> <18495.10669.315131.533466@gromit.timing.com> Message-ID: <20080530105011.18637q5e7hes9mtc@webmail.leidinger.net> Quoting John E Hein (from Thu, 29 May 2008 16:09:49 -0600): > Roman Divacky wrote at 23:48 +0200 on May 29, 2008: > > I am asking you to express your attitude towards switching > > to 2.6 emulation on default in a week. Speak now or forever hold > > your peace... > > I say we do it (last month). Users can always go back via sysctl if > needed. That's no problem for -current users. Notes in UPDATING > files would be useful, of course. s:useful:mandatory: Bye, Alexander. -- It is undignified for a woman to play servant to a man who is not hers. -- Spock, "Amok Time", stardate 3372.7 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From Alexander at Leidinger.net Fri May 30 09:40:46 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Fri May 30 09:40:50 2008 Subject: [RFC]: switch to 2.6 linux emulation on default In-Reply-To: <20080530050453.GX64397@hoeg.nl> References: <20080529214829.GA79810@freebsd.org> <20080530050453.GX64397@hoeg.nl> Message-ID: <20080530114038.92102g7uj7m3haqs@webmail.leidinger.net> Quoting Ed Schouten (from Fri, 30 May 2008 07:04:53 +0200): > Hello Roman, > > * Roman Divacky wrote: >> FreeBSD 7.0 contains support for running emulation of Linux 2.6 >> (= NPTL, futexes, TLS basically) and I'd like to switch this >> on default in HEAD to see if we can ship 8.0 with this emulation >> running on default. > > Speaking about Linux emulation: a couple of days ago I added Linux > support to my TTY code in the mpsafetty branch. This means that it can > handle the things done in posix_openpt() and ptsname(). > > Because Linux wants the minor number to be within a certain region, the > PTY driver creates a linux_device_handler for each device. ptsname() There's already something like a device handler or wrapper or whatever (I hadn't a close look at this) for some devices. Does your work use this existing infrastructure or is this something else? > seems to do an fstat() on the controller descriptor, followed by looping > on the files in /dev and /dev/pts, to find the matching device number. > > Unfortunately sendmsg() seems broken on amd64 with COMPAT_LINUX32. This The LTP test (http://wiki.freebsd.org/linux-kernel/ltp) for sendmsg tells it is broken on all architectures. Did you test on a i386 system too? > means that SSH'ing to a Linux jail only works on i386, or on amd64 when > logging in as root (in that case sshd seems to be taking a shortcut, not > causing sendmsg() to be called). That's not nice, this should work even for normal users. I think we should raise the priority for the sendmsg part. Bye, Alexander. -- Hawkeye's Conclusion: It's not easy to play the clown when you've got to run the whole circus. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From gary.jennejohn at freenet.de Fri May 30 09:40:48 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Fri May 30 09:40:56 2008 Subject: [RFC]: switch to 2.6 linux emulation on default In-Reply-To: <20080529214829.GA79810@freebsd.org> References: <20080529214829.GA79810@freebsd.org> Message-ID: <20080530114045.7b3d8a6c@peedub.jennejohn.org> On Thu, 29 May 2008 23:48:29 +0200 Roman Divacky wrote: > I am asking you to express your attitude towards switching > to 2.6 emulation on default in a week. Speak now or forever hold > your peace... > I switched a month or so ago and haven't experienced any problems. I'm all for it! --- Gary Jennejohn From ed at 80386.nl Fri May 30 09:51:18 2008 From: ed at 80386.nl (Ed Schouten) Date: Fri May 30 09:51:20 2008 Subject: [RFC]: switch to 2.6 linux emulation on default In-Reply-To: <20080530114038.92102g7uj7m3haqs@webmail.leidinger.net> References: <20080529214829.GA79810@freebsd.org> <20080530050453.GX64397@hoeg.nl> <20080530114038.92102g7uj7m3haqs@webmail.leidinger.net> Message-ID: <20080530094911.GY64397@hoeg.nl> * Alexander Leidinger wrote: > Quoting Ed Schouten (from Fri, 30 May 2008 07:04:53 +0200): > >> Hello Roman, >> >> * Roman Divacky wrote: >>> FreeBSD 7.0 contains support for running emulation of Linux 2.6 >>> (= NPTL, futexes, TLS basically) and I'd like to switch this >>> on default in HEAD to see if we can ship 8.0 with this emulation >>> running on default. >> >> Speaking about Linux emulation: a couple of days ago I added Linux >> support to my TTY code in the mpsafetty branch. This means that it can >> handle the things done in posix_openpt() and ptsname(). >> >> Because Linux wants the minor number to be within a certain region, the >> PTY driver creates a linux_device_handler for each device. ptsname() > > There's already something like a device handler or wrapper or whatever > (I hadn't a close look at this) for some devices. Does your work use > this existing infrastructure or is this something else? It just calls linux_device_register_handler() to create the mapping. I'm not entirely happy with this yet, because this means our pts(4) driver needs to be recompiled to work with Linux binary compatibility. In CVS, there is already some code in place to make the mapping work for /dev/pts/XXX (see linux_stats.c), but it always returns the same device number for all pts devices. I should probably just change that code to parse the device number and base the major/minor number on that. >> seems to do an fstat() on the controller descriptor, followed by looping >> on the files in /dev and /dev/pts, to find the matching device number. >> >> Unfortunately sendmsg() seems broken on amd64 with COMPAT_LINUX32. This > > The LTP test (http://wiki.freebsd.org/linux-kernel/ltp) for sendmsg > tells it is broken on all architectures. Did you test on a i386 system > too? On i386, it works good enough to at least make sshd work. On amd64 it returns EINVAL, using the same Linux binaries. >> means that SSH'ing to a Linux jail only works on i386, or on amd64 when >> logging in as root (in that case sshd seems to be taking a shortcut, not >> causing sendmsg() to be called). > > That's not nice, this should work even for normal users. I think we > should raise the priority for the sendmsg part. Yes, we should. Unfortunately I don't I have the time to look into that. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080530/3301add2/attachment.pgp From ivoras at freebsd.org Fri May 30 10:05:03 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Fri May 30 10:05:06 2008 Subject: [RFC]: switch to 2.6 linux emulation on default In-Reply-To: <20080529214829.GA79810@freebsd.org> References: <20080529214829.GA79810@freebsd.org> Message-ID: Roman Divacky wrote: > I am asking you to express your attitude towards switching > to 2.6 emulation on default in a week. Speak now or forever hold > your peace... Speaking purely as a user: if it won't crash the machine often, go for it :) I'll take this opportunity to again suggest the default Linux base be CentOS (free clone of Red Hat Enterprise Linux) instead of Fedora (the "desktop" variant). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20080530/d7ac161c/signature.pgp From rdivacky at freebsd.org Fri May 30 10:28:39 2008 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri May 30 10:28:41 2008 Subject: [RFC]: switch to 2.6 linux emulation on default In-Reply-To: References: <20080529214829.GA79810@freebsd.org> Message-ID: <20080530102752.GA13932@freebsd.org> On Fri, May 30, 2008 at 11:08:30AM +0200, Ivan Voras wrote: > Roman Divacky wrote: > > > I am asking you to express your attitude towards switching > > to 2.6 emulation on default in a week. Speak now or forever hold > > your peace... > > Speaking purely as a user: if it won't crash the machine often, go for it :) well.. the main point of the switch is to see if it does not crash your machine often :) From jhein at timing.com Fri May 30 13:08:04 2008 From: jhein at timing.com (John E Hein) Date: Fri May 30 13:08:09 2008 Subject: [RFC]: switch to 2.6 linux emulation on default In-Reply-To: References: <20080529214829.GA79810@freebsd.org> Message-ID: <18495.64561.653123.65054@gromit.timing.com> Ivan Voras wrote at 11:08 +0200 on May 30, 2008: > I'll take this opportunity to again suggest the default Linux base be > CentOS (free clone of Red Hat Enterprise Linux) instead of Fedora (the > "desktop" variant). Before the default can change to CentOS, someone should submit/maintain the linux_base-centos flavored port to have it available for people to try as a non-default base. From Alexander at Leidinger.net Sat May 31 07:18:10 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Sat May 31 07:18:15 2008 Subject: [RFC]: switch to 2.6 linux emulation on default In-Reply-To: <20080530094911.GY64397@hoeg.nl> References: <20080529214829.GA79810@freebsd.org> <20080530050453.GX64397@hoeg.nl> <20080530114038.92102g7uj7m3haqs@webmail.leidinger.net> <20080530094911.GY64397@hoeg.nl> Message-ID: <20080531091759.1acaa6c4@deskjail> Quoting Ed Schouten (Fri, 30 May 2008 11:49:11 +0200): > * Alexander Leidinger wrote: > > Quoting Ed Schouten (from Fri, 30 May 2008 07:04:53 +0200): > > > >> Hello Roman, > >> > >> * Roman Divacky wrote: > >>> FreeBSD 7.0 contains support for running emulation of Linux 2.6 > >>> (= NPTL, futexes, TLS basically) and I'd like to switch this > >>> on default in HEAD to see if we can ship 8.0 with this emulation > >>> running on default. > >> > >> Speaking about Linux emulation: a couple of days ago I added Linux > >> support to my TTY code in the mpsafetty branch. This means that it can > >> handle the things done in posix_openpt() and ptsname(). > >> > >> Because Linux wants the minor number to be within a certain region, the > >> PTY driver creates a linux_device_handler for each device. ptsname() > > > > There's already something like a device handler or wrapper or whatever > > (I hadn't a close look at this) for some devices. Does your work use > > this existing infrastructure or is this something else? > > It just calls linux_device_register_handler() to create the mapping. I'm > not entirely happy with this yet, because this means our pts(4) driver > needs to be recompiled to work with Linux binary compatibility. We don't have a function in the kernel linker available which you can use to lookup the function, and if you get a good pointer back, call it? > In CVS, there is already some code in place to make the mapping work for > /dev/pts/XXX (see linux_stats.c), but it always returns the same device > number for all pts devices. I should probably just change that code to > parse the device number and base the major/minor number on that. > > >> seems to do an fstat() on the controller descriptor, followed by looping > >> on the files in /dev and /dev/pts, to find the matching device number. > >> > >> Unfortunately sendmsg() seems broken on amd64 with COMPAT_LINUX32. This > > > > The LTP test (http://wiki.freebsd.org/linux-kernel/ltp) for sendmsg > > tells it is broken on all architectures. Did you test on a i386 system > > too? > > On i386, it works good enough to at least make sshd work. On amd64 it > returns EINVAL, using the same Linux binaries. Thanks for the data point. Bye, Alexander. -- YOU!! Give me the CUTEST, PINKEST, most charming little VICTORIAN DOLLHOUSE you can find!! An make it SNAPPY!! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137