Bug#603802: linux-image-2.6.32-5-xen-amd64: DomU not really resumed (hangs) after restore from disk after Dom0 restart

2010-11-17 Thread Artur Linhart
Package: linux-2.6
Version: 2.6.32-27
Severity: important

If the kernel is used for paravirtual DomU, then the DomU is normally started 
orshutdown. Ifthe xm save and xm restore 
is invoked explicitely,then the DomU also restores normally. Only in the case 
the DomU is 
restored automatically via xendomains script facility on Dom0 start it is 
restored, so visible in the list
(xm list), but also after a lot of time it does not consume any processor time 
(shows always 0.0 as  consumed processor time) and
after switch to the instance (xm console) the console is not responding to any 
key.
The same problem was (at least) also in the package version 2.6.32-25 and 
2.6.32-23.
If starting the same DomU with kernel from package version 2.6.32-21, then it 
works correctly

-- Package-specific info:
** Version:
Linux version 2.6.32-5-xen-amd64 (Debian 2.6.32-27) (m...@debian.org) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sat Oct 30 17:04:10 UTC 2010

** Command line:
root=/dev/sda1 ro console=tty0 vga=773 swiotlb=65536

** Not tainted

** Kernel log:
[   78.883733] vif8.1: no IPv6 routers present
[   79.151732] vif8.2: no IPv6 routers present
[   80.575300] device vif10.0 entered promiscuous mode
[   80.579516] perbr: port 5(vif10.0) entering learning state
[   83.099729] locbr: port 1(vif8.1) entering forwarding state
[   83.435229] tap8.1: no IPv6 routers present
[   83.487745] perbr: port 1(vif8.2) entering forwarding state
[   83.655218] tap8.2: no IPv6 routers present
[   83.791158]   alloc irq_desc for 1210 on node 0
[   83.791162]   alloc kstat_irqs on node 0
[   84.043221] tap8.0: no IPv6 routers present
[   84.131388] device tap10.0 entered promiscuous mode
[   84.132646] perbr: port 6(tap10.0) entering learning state
[   84.181362]   alloc irq_desc for 1209 on node 0
[   84.181365]   alloc kstat_irqs on node 0
[   84.607717] vif9.0: no IPv6 routers present
[   84.699718] vif9.2: no IPv6 routers present
[   84.905506] vif9.1: no IPv6 routers present
[   85.075718] vif9.3: no IPv6 routers present
[   86.209157] vif9.6: no IPv6 routers present
[   86.212755] vif9.4: no IPv6 routers present
[   86.239161] vif9.5: no IPv6 routers present
[   88.245200] locbr: port 2(tap8.1) entering forwarding state
[   88.259224] perbr: port 2(tap8.2) entering forwarding state
[   88.647215] tap9.2: no IPv6 routers present
[   88.983212] tap9.1: no IPv6 routers present
[   89.264206] tap9.6: no IPv6 routers present
[   89.275208] tap9.3: no IPv6 routers present
[   89.339202] tap9.0: no IPv6 routers present
[   89.451215] perbr: port 3(vif9.0) entering forwarding state
[   89.519208] devhazbr: port 1(vif9.1) entering forwarding state
[   89.555234] tap9.5: no IPv6 routers present
[   89.560204] tap9.4: no IPv6 routers present
[   89.599212] devsafebr: port 3(vif9.2) entering forwarding state
[   89.967706] tsthazbr: port 1(vif9.3) entering forwarding state
[   90.147225] tstsafebr: port 1(vif9.4) entering forwarding state
[   90.303212] prodhazbr: port 1(vif9.5) entering forwarding state
[   90.513625] prodsafebr: port 6(vif9.6) entering forwarding state
[   91.207274] vif10.0: no IPv6 routers present
[   93.451213] perbr: port 4(tap9.0) entering forwarding state
[   93.463200] devhazbr: port 2(tap9.1) entering forwarding state
[   93.475204] devsafebr: port 4(tap9.2) entering forwarding state
[   93.488702] tsthazbr: port 2(tap9.3) entering forwarding state
[   93.665415] tstsafebr: port 2(tap9.4) entering forwarding state
[   93.675194] prodhazbr: port 2(tap9.5) entering forwarding state
[   93.675199] prodsafebr: port 7(tap9.6) entering forwarding state
[   94.351238] tap10.0: no IPv6 routers present
[   95.580705] perbr: port 5(vif10.0) entering forwarding state
[   99.127185] perbr: port 6(tap10.0) entering forwarding state
[  188.551522] prodsafebr: port 2(vif4.0) entering disabled state
[  188.567361] prodsafebr: port 2(vif4.0) entering disabled state
[  191.152151] device vif11.0 entered promiscuous mode
[  191.156126] prodsafebr: port 2(vif11.0) entering learning state
[  192.262854] blkback: ring-ref 8, event-channel 8, protocol 1 (x86_64-abi)
[  192.329113] blkback: ring-ref 9, event-channel 9, protocol 1 (x86_64-abi)
[  201.855967] vif11.0: no IPv6 routers present
[  206.154960] prodsafebr: port 2(vif11.0) entering forwarding state
[  758.603354] psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost 
synchronization, throwing 2 bytes away.
[  760.095479] psmouse.c: resync failed, issuing reconnect request
[ 1038.325725] prodsafebr: port 2(vif11.0) entering disabled state
[ 1038.337513] prodsafebr: port 2(vif11.0) entering disabled state
[ 1040.199589] device vif12.0 entered promiscuous mode
[ 1040.203589] prodsafebr: port 2(vif12.0) entering learning state
[ 1041.523037] blkback: ring-ref 770, event-channel 9, protocol 1 (x86_64-abi)
[ 1041.594397] blkback: ring-ref 771, event-channel 10, protocol 1 (x86_64-abi)
[ 1050.517183] vif12.0: no IPv6 routers present
[ 1055.201170] prodsafebr: port 2(vif12.0) 

Bug#603802: linux-image-2.6.32-5-xen-amd64: DomU not really resumed (hangs) after restore from disk after Dom0 restart

2010-11-17 Thread Timo Juhani Lindfors
Artur Linhart al.li...@bcpraha.com writes:
 If the kernel is used for paravirtual DomU, then the DomU is
 normally started orshutdown. Ifthe xm save and xm restore is invoked
 explicitely,then the DomU also restores normally. Only in the case
 the DomU is restored automatically via xendomains script facility on
 Dom0 start it is restored, so visible in the list

This is most likely a duplicate of my bug

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602273

Can you please test the patch that is included in that bug report?






-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#603802: linux-image-2.6.32-5-xen-amd64: DomU not really resumed (hangs) after restore from disk after Dom0 restart

2010-11-17 Thread Artur Linhart
Yes, it seems to be the same bug. I have figured out, I made a mistake, the 
statement xm unpause does not help. But I have a
little bit other behavior - I have more DomUs and some from them were restored 
and started correctly, some not. I cannot recognize
any general difference between them...

Unfortunately, I will not have the chance to test the patch directly, I use 
vanilla kernel from the package only...

-Original Message-
From: Timo Juhani Lindfors [mailto:timo.lindf...@iki.fi] 
Sent: Wednesday, November 17, 2010 2:11 PM
To: Artur Linhart
Cc: 603...@bugs.debian.org
Subject: Re: Bug#603802: linux-image-2.6.32-5-xen-amd64: DomU not really 
resumed (hangs) after restore from disk after Dom0 restart

Artur Linhart al.li...@bcpraha.com writes:
 If the kernel is used for paravirtual DomU, then the DomU is
 normally started orshutdown. Ifthe xm save and xm restore is invoked
 explicitely,then the DomU also restores normally. Only in the case
 the DomU is restored automatically via xendomains script facility on
 Dom0 start it is restored, so visible in the list

This is most likely a duplicate of my bug

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602273

Can you please test the patch that is included in that bug report?




__ Informace od NOD32 5626 (20101117) __

Tato zprava byla proverena antivirovym systemem NOD32.
http://www.nod32.cz





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#603802: linux-image-2.6.32-5-xen-amd64: DomU not really resumed (hangs) after restore from disk after Dom0 restart

2010-11-17 Thread Artur Linhart
One more correctlion to my last message - I have figured out, some instances 
have had still the kernel from version 2.6.32-21 what
was the reason why they started correctly... So it seems the effect can be seen 
on all DomUs with the kernel from package version
2.6.32-27





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org