From owner-freebsd-emulation@FreeBSD.ORG Sat Dec 26 21:08:50 2009 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AEE21065670; Sat, 26 Dec 2009 21:08:50 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 10C668FC1B; Sat, 26 Dec 2009 21:08:50 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 597431E00756; Sat, 26 Dec 2009 22:08:49 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id nBQL4tTE003761; Sat, 26 Dec 2009 22:04:55 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id nBQL4teX003760; Sat, 26 Dec 2009 22:04:55 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Sat, 26 Dec 2009 22:04:55 +0100 To: Juergen Lock Message-ID: <20091226210455.GA3372@triton8.kn-bremen.de> References: <20091214220648.GA76692@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091214220648.GA76692@triton8.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-emulation@FreeBSD.org, Jung-uk Kim Subject: pcap woes (was: FreeBSD qemu-devel 0.12.0-rc2 port update available for testing) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2009 21:08:50 -0000 On Mon, Dec 14, 2009 at 11:06:48PM +0100, Juergen Lock wrote: > Hi! > > I updated my git head snapshot qemu-devel port update to 0.12.0-rc2 > today (that was just announced: > http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg01514.html > - the Subject says rc1 but in fact its rc2) so people can test that > version on FreeBSD more easily: > http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.0-rc2.patch > resp. > http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.0-rc2.shar > > (As mentioned before 0.11 was the last qemu branch that supported kqemu > so this is probably only interesting for those FreeBSD users that want > to emulate non-x86 guests or when performance doesn't matter. But the > others are probably already moving to virtualbox now anyway... :) > > I have updated the FreeBSD pcap patch just enough so that it still runs > (it probably will never be committed upstream anyway since Linux pcap > doesn't have BIOCFEEDBACK i.e. can't talk to the host, only to other > machines on the network) and I still see this weird issue here that > packets `sometimes' are only processed with a delay (when the nic is > otherwise idle?), i.e. pinging the host or another box on the lan with e.g. > -i5 from the guest sees many packets with >5000ms roundtrip time. Can > anyone else reproduce this or is that `just me'? This is on stable/8 > now (amd64) but it also happened with earlier versions, tested with > qemu 8.0-RELEASE-i386-dvd1.iso -m 256 -net nic,model=e1000 -net pcap,ifname=em0 > via fixit->cdrom. And this is most likely pcap related, I don't see > anything like it with tap networking. I found another issue: pcap_send (actuall the callback pcap_callback()) sometimes receives too large packets (or multiple packets in one go?), causing a linux guest's e1000 driver to panic like below when wget'ing a file from the host. This hack applied on top of the pcap patch (simply truncating the packets) makes the panics go away: (but still doesn't fix the delays) --- a/net.c +++ b/net.c @@ -841,11 +841,20 @@ static ssize_t pcap_receive(VLANClientSt return pcap_inject(s->handle, (u_char*)buf, size); } +#define MAX_ETH_FRAME_SIZE 1514 + static void pcap_callback(u_char *user, struct pcap_pkthdr *phdr, u_char *pdata) { VLANClientState *vc = (VLANClientState *)user; + int len = phdr->len; - qemu_send_packet(vc, pdata, phdr->len); + if (len > MAX_ETH_FRAME_SIZE) { + fprintf(stderr, + "pcap_send: packet size > %d (%d), truncating\n", + MAX_ETH_FRAME_SIZE, len); + len = MAX_ETH_FRAME_SIZE; + } + qemu_send_packet(vc, pdata, len); } static void pcap_send(void *opaque) Here comes the panic, apparently its in this line: http://fxr.watson.org/fxr/source/net/core/skbuff.c?v=linux-2.6#L1015 --------snip------------- skb_over_panic: text:e08e2da8 len:1770 put:1770 head:dd761800 data:dd761822 tail:0xdd761f0c end:0xdd761e20 dev:eth0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:127! invalid opcode: 0000 [#1] PREEMPT SMP last sysfs file: /sys/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0/block/sda/size Modules linked in: ipv6 ppdev lp cpufreq_stats cpufreq_powersave cpufreq_performance cpufreq_ondemand freq_table cpufreq_conservative af_packet virtio_balloon rtc_cmos psmouse evdev rtc_core pcspkr serio_raw i2c_piix4 rtc_lib i2c_core parport_pc parport processor button aufs squashfs loop nls_utf8 isofs nls_base dm_mod sg sd_mod sr_mod cdrom ata_generic pata_acpi virtio_net ata_piix libata sym53c8xx scsi_transport_spi virtio_pci e1000 floppy scsi_mod thermal fan [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Not tainted (2.6.31-6.slh.1-sidux-686 #1) EIP: 0060:[] EFLAGS: 00000292 CPU: 0 EIP is at skb_put+0x8a/0x90 EAX: 0000007a EBX: dd761f0c ECX: 00000086 EDX: 00ee5000 ESI: 000006ea EDI: dd749580 EBP: ddc71a80 ESP: c0493da8 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process swapper (pid: 0, ti=c0492000 task=c04993a0 task.ti=c0492000) Stack: c0467e4c e08e2da8 000006ea 000006ea dd761800 dd761822 dd761f0c dd761e20 <0> df02b000 000006ea 000006ee e08e2da8 df0254cc c1409bc0 c0493eac dd7495c0 <0> df02b320 00000007 df02b388 df02b610 c03cbfc0 df02b508 df02b000 df04f800 Call Trace: [] ? e1000_clean_rx_irq+0x268/0x4b0 [e1000] [] ? e1000_clean_rx_irq+0x268/0x4b0 [e1000] [] ? e1000_clean+0x1ec/0x550 [e1000] [] ? enqueue_entity+0x11f/0x190 [] ? sym_interrupt+0x29/0x750 [sym53c8xx] [] ? net_rx_action+0x126/0x230 [] ? __do_softirq+0xcf/0x1d0 [] ? ack_apic_level+0x7a/0x270 [] ? do_softirq+0x3d/0x40 [] ? irq_exit+0x65/0x80 [] ? do_IRQ+0x50/0xc0 [] ? common_interrupt+0x29/0x30 [] ? native_safe_halt+0x2/0x10 [] ? default_idle+0x68/0x130 [] ? c1e_idle+0x4c/0x110 [] ? cpu_idle+0x52/0x90 [] ? start_kernel+0x2f8/0x35b [] ? unknown_bootoption+0x0/0x1d7 Code: 24 14 8b 81 b0 00 00 00 89 74 24 0c 89 44 24 10 8b 41 50 c7 04 24 4c 7e 46 c0 89 44 24 08 8b 44 24 2c 89 44 24 04 e8 d1 c0 09 00 <0f> 0b eb fe 66 90 55 89 c5 57 56 53 83 ec 14 89 54 24 04 89 0c EIP: [] skb_put+0x8a/0x90 SS:ESP 0068:c0493da8 ---[ end trace a7dfb09442504800 ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 0, comm: swapper Tainted: G D 2.6.31-6.slh.1-sidux-686 #1 Call Trace: [] ? panic+0x4d/0xfd [] ? oops_end+0xbc/0xd0 [] ? do_invalid_op+0x0/0x90 [] ? do_invalid_op+0x7f/0x90 [] ? skb_put+0x8a/0x90 [] ? serial8250_console_write+0x0/0x130 [] ? up+0x11/0x40 [] ? release_console_sem+0x191/0x1e0 [] ? sk_filter+0x9a/0xb0 [] ? error_code+0x66/0x6c [] ? do_invalid_op+0x0/0x90 [] ? skb_put+0x8a/0x90 [] ? e1000_clean_rx_irq+0x268/0x4b0 [e1000] [] ? e1000_clean_rx_irq+0x268/0x4b0 [e1000] [] ? e1000_clean+0x1ec/0x550 [e1000] [] ? enqueue_entity+0x11f/0x190 [] ? sym_interrupt+0x29/0x750 [sym53c8xx] [] ? net_rx_action+0x126/0x230 [] ? __do_softirq+0xcf/0x1d0 [] ? ack_apic_level+0x7a/0x270 [] ? do_softirq+0x3d/0x40 [] ? irq_exit+0x65/0x80 [] ? do_IRQ+0x50/0xc0 [] ? common_interrupt+0x29/0x30 [] ? native_safe_halt+0x2/0x10 [] ? default_idle+0x68/0x130 [] ? c1e_idle+0x4c/0x110 [] ? cpu_idle+0x52/0x90 [] ? start_kernel+0x2f8/0x35b [] ? unknown_bootoption+0x0/0x1d7 QEMU 0.11.1 monitor - type 'help' for more information (qemu) q