On Tue, Jan 25, 2011 at 09:40:22AM -0600, Dale Rahn wrote:
> THIS IS WRONG.
And the wrong code is still in the qemu-old port.
Index: Makefile
===
RCS file: /home/cvs/ports/emulators/qemu-old/Makefile,v
retrieving revision 1.12
diff
On Tue, Jan 25, 2011 at 09:40:22AM -0600, Dale Rahn wrote:
> On Mon, Jan 24, 2011 at 03:43:30PM +, Federico G. Schwindt wrote:
> > On Mon, Jan 24, 2011 at 05:03:23PM +0900, Ryan McBride wrote:
> > > This patch helps a lot. I couldn't even get through an install before.
> > > But please don't re
On Mon, Jan 24, 2011 at 03:43:30PM +, Federico G. Schwindt wrote:
> On Mon, Jan 24, 2011 at 05:03:23PM +0900, Ryan McBride wrote:
> > This patch helps a lot. I couldn't even get through an install before.
> > But please don't remove qemu-old yet: I'm using UDP multicast sockets to
> > build vir
On Sun, Jan 23, 2011 at 09:04:46PM +0100, Stefan Sperling wrote:
> With this patch to libpthread, an OpenBSD guest in a qemu run with
> pthreads (not rthreads) has finished a cvs checkout and a kernel build.
> I'm starting a make build on it now.
The qemu instance run with this patch has finished
On Mon, Jan 24, 2011 at 04:59:46PM -0800, Matthew Dempsky wrote:
> On Mon, Jan 24, 2011 at 03:43:30PM +, Federico G. Schwindt wrote:
> > +--- net/socket.c.orig Mon Jan 24 15:34:58 2011
> > net/socket.c Mon Jan 24 15:35:01 2011
> > +@@ -195,7 +195,7 @@ static int net_socket_mcast_cre
On Mon, Jan 24, 2011 at 03:43:30PM +, Federico G. Schwindt wrote:
> +--- net/socket.c.origMon Jan 24 15:34:58 2011
> net/socket.c Mon Jan 24 15:35:01 2011
> +@@ -195,7 +195,7 @@ static int net_socket_mcast_create(struct sockaddr_in
> + /* Force mcast msgs to loopback (eg.
On Mon, Jan 24, 2011 at 08:04:05PM -0500, Brad wrote:
> Can you also check the rest of socket.c for the other uses of
> setsockopt(), specifically
> the SO_REUSEADDR cases?
Those are fine, they take an int as optval. See setsockopt(2).
(also, the code works correctly with only the IP_MULTICAST_LO
On 24/01/11 10:43 AM, Federico G. Schwindt wrote:
On Mon, Jan 24, 2011 at 05:03:23PM +0900, Ryan McBride wrote:
This patch helps a lot. I couldn't even get through an install before.
But please don't remove qemu-old yet: I'm using UDP multicast sockets to
build virtual networks, and they fail on
On Tue, Jan 25, 2011 at 12:33:08AM +, Federico G. Schwindt wrote:
> erhm, I take you didn't see the diff i sent earlier today?
>
ah. Well, I've seen it now. :-)
I like yours better, ok by me.
On Tue, Jan 25, 2011 at 08:45:38AM +0900, Ryan McBride wrote:
> On Mon, Jan 24, 2011 at 05:03:23PM +0900, Ryan McBride wrote:
> > $ sudo qemu -m 128 -no-fd-bootchk \
> > -hda virtual.img -boot n -nographic \
> > -net nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:34:03 \
> > -
On Mon, Jan 24, 2011 at 05:03:23PM +0900, Ryan McBride wrote:
> $ sudo qemu -m 128 -no-fd-bootchk \
> -hda virtual.img -boot n -nographic \
> -net nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:34:03 \
> -net user -tftp /usr/src/sys/arch/i386/compile/TEST -bootp pxeboot \
>
On Mon, Jan 24, 2011 at 09:33:40AM -0800, Philip Guenther wrote:
> The other thing I need to finish double checking is whether the nesting of
> _thread_kern_in_sched vs _queue_signals is correct here:
>
> > @@ -481,6 +487,9 @@ _thread_kern_sched(struct sigcontext * s
> > */
>
On Sun, 23 Jan 2011, Stefan Sperling wrote:
> The patch protects the region around _thread_machdep_restore_float_state(),
> which severly messes with the stack of the current thread, from being
> interrupted by signals.
> Please test. This problem could also affect other applications.
>
> I'm not
On Sun, Jan 23, 2011 at 09:04:46PM +0100, Stefan Sperling wrote:
> On Sun, Jan 23, 2011 at 02:18:10PM +0100, Stefan Sperling wrote:
> > Turns out qemu is running into libpthreads bugs.
>
> > Some crashes had similar traces as the one seen before, with
> > _thread_kern_sig_defer() apparently calli
On Mon, Jan 24, 2011 at 05:03:23PM +0900, Ryan McBride wrote:
> This patch helps a lot. I couldn't even get through an install before.
> But please don't remove qemu-old yet: I'm using UDP multicast sockets to
> build virtual networks, and they fail on 0.13.0:
>
> $ sudo qemu -m 128 -no-fd-bootch
00, Stefan Sperling wrote:
> I've run into a qemu crash with the following trace:
>
> #0 _thread_kern_sig_undefer ()
> at /usr/src/lib/libpthread/uthread/uthread_kern.c:1003
> 1003if (curthread->sig_defer_count > 1) {
> (gdb) p c
On Sun, Jan 23, 2011 at 09:04:46PM +0100, Stefan Sperling wrote:
> With this patch to libpthread, an OpenBSD guest in a qemu run with
> pthreads (not rthreads) has finished a cvs checkout and a kernel build.
> I'm starting a make build on it now.
Forgot to mention: The earlier patches to qemu are
On Sun, Jan 23, 2011 at 02:18:10PM +0100, Stefan Sperling wrote:
> Turns out qemu is running into libpthreads bugs.
> Some crashes had similar traces as the one seen before, with
> _thread_kern_sig_defer() apparently calling _thread_kern_sig_undefer().
> Some had an apparently corrupt stack -- wh
On Fri, Jan 21, 2011 at 06:39:17PM +0100, Stefan Sperling wrote:
> On Fri, Jan 21, 2011 at 12:18:28PM +0100, Stefan Sperling wrote:
> > It would be interesting to know if this helps others who have seen qemu
> > crash.
>
> Well it did eventually crash again, but with a none
On Fri, Jan 21, 2011 at 12:18:28PM +0100, Stefan Sperling wrote:
> It would be interesting to know if this helps others who have seen qemu crash.
Well it did eventually crash again, but with a nonesense trace this time.
Meanwhile I've been looking at some of the signal handlers and t
On Fri, Jan 21, 2011 at 12:25 PM, Stuart Henderson wrote:
> On 2011/01/21 12:18, Stefan Sperling wrote:
>> I've run into a qemu crash with the following trace:
>
> Cool! On the occasions when I have been able to obtain a valid
> backtrace after a crash, it has always look
On 2011/01/21 12:18, Stefan Sperling wrote:
> I've run into a qemu crash with the following trace:
Cool! On the occasions when I have been able to obtain a valid
backtrace after a crash, it has always looked like this.
Since there have been a number of people who have been
complaining a
I've run into a qemu crash with the following trace:
#0 _thread_kern_sig_undefer ()
at /usr/src/lib/libpthread/uthread/uthread_kern.c:1003
1003if (curthread->sig_defer_count > 1) {
(gdb) p curthread
$1 = (struct pthread *) 0x8
(gdb) bt
#0 _thread_kern_sig_undefer ()
On Sunday 07 December 2008 23:47:08 Todd T. Fries wrote:
> I suspect newer qemu has better code for fxp network card emulation, but
> for now (i.e. until the newer qemu comes out) if you want reliable behavior
> stick with what works (i.e. realtek of one form or fashion).
No, it does not.
--
Thi
As recommended during anytime you pkg_add qemu, please use the ne2k_pci.
I've also had luck with model=rl8139.
Anything else is slightly experimental at best.
I suspect newer qemu has better code for fxp network card emulation, but for
now (i.e. until the newer qemu comes out) if you want reliab
Same, I tried all fxp.
On Mon, Dec 01, 2008 at 10:09:20PM -0500, Brad wrote:
> On Monday 01 December 2008 22:02:37 Marco Peereboom wrote:
> > No one cares?
> >
> > On Wed, Nov 26, 2008 at 08:49:57PM -0600, Marco Peereboom wrote:
> > > assertion "!"feature is missing in this emulation: " "unknown w
On Monday 01 December 2008 22:02:37 Marco Peereboom wrote:
> No one cares?
>
> On Wed, Nov 26, 2008 at 08:49:57PM -0600, Marco Peereboom wrote:
> > assertion "!"feature is missing in this emulation: " "unknown word read""
> > failed: file "/usr/obj/i386/qemu-0.9.1p4/qemu-0.9.1/hw/eepro100.c", line
No one cares?
On Wed, Nov 26, 2008 at 08:49:57PM -0600, Marco Peereboom wrote:
> assertion "!"feature is missing in this emulation: " "unknown word read""
> failed: file "/usr/obj/i386/qemu-0.9.1p4/qemu-0.9.1/hw/eepro100.c", line
> 1202, function "eepro100_read2"
>
> when running with fxp in qe
assertion "!"feature is missing in this emulation: " "unknown word read""
failed: file "/usr/obj/i386/qemu-0.9.1p4/qemu-0.9.1/hw/eepro100.c", line 1202,
function "eepro100_read2"
when running with fxp in qemu like:
qemu -nographic -hda boot.img -net nic,model=i82551 -net tap
29 matches
Mail list logo
