On 04/07/2015 02:44 PM, Peter Lieven wrote:
Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Hi David,
Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert:
Any particular workload or reproducer?
Workload is almost zero. I try to figure out if there is a way to trigger it.
Maybe playing a role: Machine type is -M pc1.2 and we set -kvmclock as
CPU flag since kvmclock seemed to be quite buggy in 2.6.16...
Exact cmdline is:
/usr/bin/qemu-2.2.1 -enable-kvm -M pc-1.2 -nodefaults -netdev
type=tap,id=guest2,script=no,downscript=no,ifname=tap2 -device
e1000,netdev=guest2,mac=52:54:00:ff:00:65 -drive
format=raw,file=iscsi://172.21.200.53/iqn.2001-05.com.equallogic:4-52aed6-88a7e99a4-d9e00040fdc509a3-XXX-hd0/0,if=ide,cache=writeback,aio=native
-serial null -parallel null -m 1024 -smp 2,sockets=1,cores=2,threads=1
-monitor tcp:0:4003,server,nowait -vnc :3 -qmp tcp:0:3003,server,nowait -name
'XXX' -boot order=c,once=dc,menu=off -drive
index=2,media=cdrom,if=ide,cache=unsafe,aio=native,readonly=on -k de
-incoming tcp:0:5003 -pidfile /var/run/qemu/vm-146.pid -mem-path /hugepages
-mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu
qemu64,-kvmclock
Exact kernel is:
2.6.16.46-0.12-smp (i think this is SLES10 or sth.)
The machine does not hang. It seems just I/O is hanging. So you can type at the
console or ping the system, but no longer login.
Thank you,
Peter
Interesting observation: Migrating the vServer again seems to fix to problem
(at least in one case I could test just now).
2.6.8-24-smp is also affected.
How often does it fail - you say 'sometimes' - is it a 1/10 or a 1/1000 ?
Its more often than 1/10 I would say.
OK, that's not too bad - it's the 1/1000 that are really nasty to find.
In your setup, how easy would it be for you to try :
with either 2.1 or current head?
with a newer machine-type?
without the cdrom?
Its all possible. I can clone the system and try everything on my test systems.
I hope
it reproduces there.
Has the cdrom the power of taking down the bus?
Peter
I don't know if CDROM could stall the entire bus, but I suspect the
reason for asking is this: dgilbert and I had tracked down a problem
previously where during migration, outstanding requests being handled by
the ATAPI code can get lost during migration if, for instance, the user
has only prepared the command (via bmdma) but has not yet written to the
register to activate the command yet.
So if something like this happens:
- User writes to the ATA registers to program a command
- Migration occurs
- User writes to the BMDMA register to initiate the command
We can lose some of the state and data of the request. David had checked
in a workaround for at least ATAPI that simply coaxes the guest OS into
trying the command again to unstick it.
I think we determined last time that we couldn't fix this problem
without changing the migration format, so we opted not to do it for 2.3.
We had also only noticed it with ATAPI drives, not HDDs, so a proper fix
got kicked down the road since we thought the workaround was sufficient.
IIRC our success rate with reproducing it was something on the order of
1/50, too.
If you can reproduce it without a CDROM but using the BMDMA interface,
that's a good data point. If you can't reproduce it using the ISA
interface, that's a phenomenal data point and implicates BMDMA pretty
heavily.
--js
