[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


--


Exxoss
Matthieu Lejeune, System Engineer | Gsm: +32(0)491/52.70.66
Exxoss, SPRL
Rue de la station, 2, 4347, Fexhe-le-haut-clocher | Telephone: +32(0)4/341.25.81 | Fax: +32(0)4/371.94.06
Twitter Facebook Linked
              In


 
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.