|
All of kernels i mention before are official opensuse kernels (3.4 from http://download.opensuse.org/repositories/Kernel:/openSUSE-12.2/standard
, 3.9 from http://download.opensuse.org/repositories/Kernel:/stable/standard )
Also i try kernels from http://download.opensuse.org/repositories/Kernel:/HEAD/standard for double-checking the fact that is problem is kernel-related/opensuse-xen build related.
We use 3.4 kernels in production, 3.4.37-1-xen and 3.4.45-2 are working without this problems, a couple of days ago i started to test 3.9.
VM configuration:
name="test2"
memory = 2048
vcpus = 4
cpu_weight = 256
maxvcpus = 8
maxmem = 4096
superpages = 1
bootloader = "pygrub"
bootargs = "--entry=xvda1:/boot/vmlinuz-xen,/boot/initrd-xen"
vfb = [ 'type=vnc,vnclisten=0.0.0.0,vncdisplay=2,vncpasswd=vnc' ]
disk=[
"tap:raw:/storage/images/manual/test2.raw,xvda,w",
"tap:raw:/storage/images/manual/test2_storage.raw,xvdb,w",
]
vif =[
"script=/etc/xen/scripts/vif-ovs,mac=AA:00:AA:BB:02:01,bridge=vlannet.2512.9000",
]
We use simple vif-to-OVS bash mapper and it work fine.
BTW, only VM runs iperf server (-s) is affected, VM runs iperf client is working normally.
Logs (test1 - iperf server, test2 - iperf client):
Dom0:
1) tailf /var/log/xen/xl-test1.log (turned just before bug) - xl-test1.log
2) tailf /var/log/xen/xl-test2.log (turned just before bug) - xl-test2.log
3) tailf /var/log/messages (turned just before bug) - messages.log
4) xl create log - xl_creation.log
DomU:
1) dmesg - domu_dmesg
Do you need any kernel dumps?
--
Best regards,
Eugene Istomin
On Friday, May 17, 2013 11:45:19 AM Jan Beulich wrote:
> >>> On 17.05.13 at 11:37, Eugene Istomin <e.istomin@xxxxxxx> wrote:
> > [ 38.447860] BUG: unable to handle kernel paging request at
> > ffff88007928b000
> > [ 38.447898] IP: [<ffffffffa001a75c>] netif_poll+0x49c/0xe80 [xennet]
> > [ 38.447927] PGD a83067 PUD a93067 PMD 7fc28067 PTE
> > 801000007928b065
> > [ 38.447955] Oops: 0003 [#1] SMP
> > [ 38.447970] Modules linked in: af_packet hwmon domctl crc32_pclmul
> > crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw
> > aes_x86_64 xts gf128mul joydev autofs4 scsi_dh_emc scsi_dh_alua
> > scsi_dh_rdac scsi_dh_hp_sw scsi_dh xenblk cdrom xennet ata_generic
> > ata_piix
> > [ 38.448091] CPU 0
> > [ 38.448100] Pid: 0, comm: swapper/0 Not tainted 3.9.2-4.756ee56-xen
> > #1
> > [ 38.448125] RIP: e030:[<ffffffffa001a75c>] [<ffffffffa001a75c>]
> > netif_poll+0x49c/0xe80 [xennet]
> > [ 38.448158] RSP: e02b:ffff88007b403d18 EFLAGS: 00010286
> > [ 38.448176] RAX: ffff88007da68cd0 RBX: ffff88007928aec0 RCX:
> > ffff88007928b000
> >
> >
> >
> >
> > This trace is viewed only using xl console, DomUs had no records in logs.
> > You are right, may be this is Dom0 trace.
>
> Output of "xl console" can hardly be Dom0 kernel output. The fact
> that various modules (most prominently domctl) are present here that
> would normally only be expected in Dom0 may be confusing us. Init
> scripts might be loading those for no reason...
>
> But - you still didn't give us a full guest kernel log, so we're still left
> in the dark as to what may have gone wrong earlier, and what the call stack
> is that got us here. Nor did you tell us what kernel version you used last
> without seeing that issue.
>
> Plus, should in depth analysis of the stack turn out necessary, using
> a random build will make this more complicated than necessary (as
> those builds vanish as newer ones appear).
>
> Jan | 
