Re: [Xen-users] Gplpv drivers make reset raid controller

[Stephan Seitz <s.seitz@xxxxxxxxxxx>]

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