Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Dec 2009 22:04:55 +0100
From:      Juergen Lock <nox@jelal.kn-bremen.de>
To:        Juergen Lock <nox@jelal.kn-bremen.de>
Cc:        freebsd-emulation@FreeBSD.org, Jung-uk Kim <jkim@FreeBSD.org>
Subject:   pcap woes (was: FreeBSD qemu-devel 0.12.0-rc2 port update available for testing)
Message-ID:  <20091226210455.GA3372@triton8.kn-bremen.de>
In-Reply-To: <20091214220648.GA76692@triton8.kn-bremen.de>
References:  <20091214220648.GA76692@triton8.kn-bremen.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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:[<c03254da>] 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:
 [<e08e2da8>] ? e1000_clean_rx_irq+0x268/0x4b0 [e1000]
 [<e08e2da8>] ? e1000_clean_rx_irq+0x268/0x4b0 [e1000]
 [<e08e5a7c>] ? e1000_clean+0x1ec/0x550 [e1000]
 [<c012ae4f>] ? enqueue_entity+0x11f/0x190
 [<e0979039>] ? sym_interrupt+0x29/0x750 [sym53c8xx]
 [<c032e546>] ? net_rx_action+0x126/0x230
 [<c013e10f>] ? __do_softirq+0xcf/0x1d0
 [<c011a3ea>] ? ack_apic_level+0x7a/0x270
 [<c013e24d>] ? do_softirq+0x3d/0x40
 [<c013e425>] ? irq_exit+0x65/0x80
 [<c0105a60>] ? do_IRQ+0x50/0xc0
 [<c0104089>] ? common_interrupt+0x29/0x30
 [<c011fe72>] ? native_safe_halt+0x2/0x10
 [<c010b4a8>] ? default_idle+0x68/0x130
 [<c010b94c>] ? c1e_idle+0x4c/0x110
 [<c0102a02>] ? cpu_idle+0x52/0x90
 [<c04c788a>] ? start_kernel+0x2f8/0x35b
 [<c04c736d>] ? 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: [<c03254da>] 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:
 [<c03c14fb>] ? panic+0x4d/0xfd
 [<c010767c>] ? oops_end+0xbc/0xd0
 [<c0104ad0>] ? do_invalid_op+0x0/0x90
 [<c0104b4f>] ? do_invalid_op+0x7f/0x90
 [<c03254da>] ? skb_put+0x8a/0x90
 [<c02f6880>] ? serial8250_console_write+0x0/0x130
 [<c01536b1>] ? up+0x11/0x40
 [<c0138dd1>] ? release_console_sem+0x191/0x1e0
 [<c033b15a>] ? sk_filter+0x9a/0xb0
 [<c03c42d6>] ? error_code+0x66/0x6c
 [<c0104ad0>] ? do_invalid_op+0x0/0x90
 [<c03254da>] ? skb_put+0x8a/0x90
 [<e08e2da8>] ? e1000_clean_rx_irq+0x268/0x4b0 [e1000]
 [<e08e2da8>] ? e1000_clean_rx_irq+0x268/0x4b0 [e1000]
 [<e08e5a7c>] ? e1000_clean+0x1ec/0x550 [e1000]
 [<c012ae4f>] ? enqueue_entity+0x11f/0x190
 [<e0979039>] ? sym_interrupt+0x29/0x750 [sym53c8xx]
 [<c032e546>] ? net_rx_action+0x126/0x230
 [<c013e10f>] ? __do_softirq+0xcf/0x1d0
 [<c011a3ea>] ? ack_apic_level+0x7a/0x270
 [<c013e24d>] ? do_softirq+0x3d/0x40
 [<c013e425>] ? irq_exit+0x65/0x80
 [<c0105a60>] ? do_IRQ+0x50/0xc0
 [<c0104089>] ? common_interrupt+0x29/0x30
 [<c011fe72>] ? native_safe_halt+0x2/0x10
 [<c010b4a8>] ? default_idle+0x68/0x130
 [<c010b94c>] ? c1e_idle+0x4c/0x110
 [<c0102a02>] ? cpu_idle+0x52/0x90
 [<c04c788a>] ? start_kernel+0x2f8/0x35b
 [<c04c736d>] ? unknown_bootoption+0x0/0x1d7
QEMU 0.11.1 monitor - type 'help' for more information
(qemu) q



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091226210455.GA3372>