On Mon, Jan 2, 2017 at 7:32 AM, Bart Van Assche <Bart.VanAssche@xxxxxxxxxxx> wrote: > On Mon, 2017-01-02 at 07:00 -0500, DAVID S wrote: >> Also, Bart, you mentioned FCoE in your reply to Scott, but I believe >> he is probably using straight FC. This issue appears to only be a >> problem with hypervisors utilizing FC targets, so this seems to >> further cement the original hypothesis that the issue is the way that >> targetcli handles VAAI/ODX. This also seems to confirm that the issue >> isn't with a specific hypervisor, since the original problems reported >> by me and a few others were with ESXi, and Scott's hosts are Hyper-V. >> >> Again, please let me know if I can assist in testing new patches, etc. > > Hello David, > > Does this mean that both Scott and you are using the tcm_qla2xxx driver at > the target side? Since you are suspecting VAAI/ODX, have you already tried > to configure the ESXi initiator such that it does not use VAAI? I'm not > proposing this as a permanent solution but as an approach to narrow down > what code at the target side is causing the misbehavior. > > Next time you run into a lockup at the target side, can you run echo w > > /proc/sysrq-trigger and provide the data that has been added to the system > log by running that command? > > Bart. Hi Bart, Yes, I am using the same driver on the target side. I have disabled VAAI in ESXi already as a testing measure (and it is still disabled) and the crashes still occur. They are not predictable, but I can at least trigger them consistently by running storage tests inside of a VM on a datastore running on the target server. I'll try to trigger a lockup now and I'll reply back with the results of that command. Running it prior to a lockup outputs the following: Jan 2 08:09:30 storage kernel: sysrq: SysRq : This sysrq operation is disabled. Do I need to enable it somehow before I begin testing? Thanks, David -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
