|
Hi,
Thanks for your help. I'll make some test.
I have this problem with one DomU at time and just on the boot
when Windows is loading drivers.
I use this version of the kernel : Linux version
2.6.32-5-xen-amd64 (Debian 2.6.32-45)
This version of the Areca Driver : arcmsr.1.20.0X.15-111012.zip
And the last firmware of the Arc-1882i
Thanks
Matthieu
I use Le 10/07/12 16:26, Stephan Seitz a écrit :
Am Dienstag, den 10.07.2012, 12:34 +0000 schrieb James Harper:
> Hi,
>
> I have make more test and on the same hardware, when I running just one
> dom U with a Win 2008R2 it's ok.
> After installing Gplpv drivers
> (http://apt.univention.de/download/addons/gplpv-drivers/
> gplpv_Vista2008x64_signed_0.11.0.356.msi) the raid controler make HW
> Reset like in my last post.
>
> We have found a workaround by exporting the volume group with iscsi-scst.
> With the exported disk there is no problem.
> So the problem is only when the domU write directly to the physical disk.
>
One guess... with GPLPV you can probably send a lot more commands to the RAID than with an emulated IDE driver and maybe this is causing timeouts in the array... when you start up the second DomU does the scsi reset happen very quickly or just after a while? If its only after a while, can you start just one Windows 2008R2 DomU then try and generate a lot of write traffic on the RAID in Dom0?
Also, what kernel are you using? I can't find the text "scsi cmnd aborted" in any kernel source anywhere...
That message is generated by int arcmsr_abort(struct scsi_cmnd
*cmd) inside the areca arcmsr driver.
I didn't peek inside kernel-tree, it's at least at the out-of-tree
driver provided by areca [1].
That driver has been added to the vanilla kernel around 2.6.16, so
i'ld expect no big differences.
[1] http://www.areca.us/support/s_linux/driver/arcmsr.1.20.0X.15-111012.zip
As written a few days ago, I'm also guessing the gplpv drivers are
not the source of the
problem, but a potential trigger. matthieu 's pointed out, that
looping through iscsi has
solved the issue, but I assume with iscsi, it just slowed down and
kept below "critical" i/o.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users
|
