[Top][All Lists]

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

Re: [qemu-s390x] [PATCH 00/15] s390: vfio-ccw dasd ipl support

From: Jason J. Herne
Subject: Re: [qemu-s390x] [PATCH 00/15] s390: vfio-ccw dasd ipl support
Date: Wed, 12 Dec 2018 09:47:35 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 12/12/18 9:34 AM, Cornelia Huck wrote:
On Wed, 12 Dec 2018 09:11:03 -0500
"Jason J. Herne" <address@hidden> wrote:

Hm, I think you need to adjust your cc: list. I added some more folks
(and removed Dong Jia, whose address is no longer valid AFAIK).

Correct. I forgot to update my list before I sent.

NOTE: It has been a while, but I've finally chased down my infamous "reset bug".
On subsystem reset (I see this right after host ipl) we sometimes end up getting
an unexpected unit check status from a dasd device. This causes the first start
subchannel instruction to fail due to the pending unit check status. My solution
to this problem, as advised by the kernel folks, is to simply retry my ssch
instructions before declaring failure when unexpected unit checks happen. In the
event of a persistent error, after two retries we'll give up and print some
useful error info for the user.

So, is that a status we only see because the vfio-ccw driver keeps the
subchannel enabled (as by the other recent thread)?

Is there any value in distinguishing different unit checks, or is retry
the best strategy in any case?

It is status only, yes. I'm not sure if there is value in treating different unit checks differently. I discussed the problem with some of the kernel i/o devs and the suggestion I got was to simply retry. In the event of a real I/O error I doubt there is much we'd be able to do to recover so I think showing the user all of the relevant info (see patch s390-bios: cio error handling) and exiting is the right thing to do.

-- Jason J. Herne (address@hidden)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]