Xen Project Q&A Forum: First Line Help for Simple Questions
This is your chance to ask questions and provide answers about basic use of the Xen Project software. For debugging problems and for more complex issues, consider using the xen-users mailing list instead. You can find information about xen-users under "HELP | Mailing Lists" in the navigation bar above.
I have tried reinstalling Xen with 4.3.1-0 and 4.3.0-4 but had the same issue with both. I've been very happy with the setup until now.
I only run into this issue when transferring large amounts of data between my Windows VM and my unRAID vm. In this case it was my 80GB photo library, so lots of small files - not one giant one, that reliably causes this kernel panic. It happens after less than 1 minute into the transfer.
I frequently transfer 10GB+ movie files from another VM, which runs Arch also, as my usenet box. This occurs without issue several times a day so it appears to me that the issue lies in the Windows / unRAID communication specifically. Beyond me to know what though. HELP!?
I'm not sure what other information would be needed to help me so please if you need more, just ask.
------------[ cut here ]------------ kernel BUG at drivers/net/xen-netfront.c:306! invalid opcode: 0000 [#1] SMP Modules linked in: md_mod sg ahci mvsas libsas libahci scsi_transport_sas coretemp hwmon Pid: 0, comm: swapper/0 Not tainted 3.9.6p-unRAID #1 EIP: 0061: EFLAGS: 00010286 CPU: 0 EIP is at xennet_alloc_rx_buffers+0x1bc/0x2bd EAX: 00000292 EBX: dc4c8440 ECX: 0000005e EDX: 0000005e ESI: 000002bd EDI: dce873c0 EBP: c1571d74 ESP: c1571d3c DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069 CR0: 80050033 CR2: 40ea7000 CR3: 1c587000 CR4: 00042660 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process swapper/0 (pid: 0, ti=c1570000 task=c158004c task.ti=c1570000) Stack: 00000000 0000005d dc4c9110 005ea3ac dcdac000 0000005d 00000049 dc4c8ce4 dc4c8000 00010215 0001025e dc4c8440 dc4c8440 00000040 c1571e2c c1345836 c3ae26c0 c10296bf 00017e80 c15ab100 00000750 c10296bf c1571e00 c1571df0 Call Trace:  xennet_poll+0x9b6/0xa30  ? pvclock_clocksource_read+0x99/0xbb  ? pvclock_clocksource_read+0x99/0xbb  ? xen_clocksource_read+0x19/0x1b  ? gnttab_end_foreign_transfer_ref_v1+0xe/0x54  net_rx_action+0x5d/0x16f  __do_softirq+0x96/0x158  irq_exit+0x38/0x71  xen_evtchn_do_upcall+0x20/0x2a  xen_do_upcall+0x7/0xc  ? xen_hypercall_sched_op+0x7/0x20  ? xen_safe_halt+0x12/0x1f  default_idle+0x1f/0x35  cpu_idle+0x55/0x74  rest_init+0x58/0x5a  start_kernel+0x2c4/0x2ca  ? repair_env_string+0x53/0x53  i386_start_kernel+0x79/0x7d  xen_start_kernel+0x614/0x61f Code: 00 00 c7 47 04 00 00 00 00 89 42 04 89 10 8b 55 e8 89 57 14 0f b6 4d f0 0f b7 d1 8d 82 34 02 00 00 66 89 4d d6 83 3c 83 00 74 04 0b eb fe 89 3c 83 8b 45 d0 89 55 cc e8 79 c7 f7 ff 8b 55 cc EIP:  xennet_alloc_rx_buffers+0x1bc/0x2bd SS:ESP 0069:c1571d3c ---[ end trace f1245c97afa1ffd0 ]--- Kernel panic - not syncing: Fatal exception in interrupt
Accepted AnswerRussell PavlicekOffline
Accepted AnswerRussell PavlicekOffline0A response to this query from the xen-devel list from Annie:
"Although I am not so sure, this is likely the recent issue which was finally fixed by http://lists.xen.org/archives/html/xen-devel/2013-09/msg01143.html.
That fix mainly connects with larger MTU(for example, 9000), and using less MTU size does not hit that issue. Could you check this in your setup?"