>>> On 3/3/2016 at 05:27 PM, in message <caflbxzaf5fjoj6dgbcmsm4kda5_xihowshqhos1zwwxju9b...@mail.gmail.com>, George Dunlap <george.dun...@eu.citrix.com> wrote: > On Thu, Mar 3, 2016 at 2:59 AM, Chun Yan Liu <cy...@suse.com> wrote: >>>>> On 3/3/2016 at 02:46 AM, in message <56d7350f.7010...@citrix.com>, George > > Dunlap <george.dun...@citrix.com> wrote: > >> Sorry, just looked through the rest of the series, and there's one more > >> thing. > >> > >> Neither here nor in the man page do we explain what to do if something > >> goes wrong with the detach. I think the best thing to do is probably to > >> make the logged error messages more helpful. > >> > >> What about something like this: > >> > >> * On failure to unbind: "Error removing device from guest. Try running > >> usbdev-detach again." > >> > >> * On failure to rebind: "USB device removed from guest, but couldn't > >> re-bind to domain 0. Try removing and re-inserting the USB device or > >> reloading the driver modules." > > Here, user could first try 'echo xxx > sysfs_driver_path/bind", so maybe: > > "Try binding USB device to original driver by echoing the device to > > [driver_path]/bind, or removing and re-inserting the USB device, or > > reloading the driver modules." > > Yes, I had thought about the idea of giving the user specific commands > to retry. The question is how much we can expect the user to do to > recover the state. At some point "reloading the driver module" was > seen as something reasonable for a reasonably advanced user, while > "messing around with sysfs" was seen to be something too technical. > But as you say, giving them the exact command to cut-and-paste might > be somewhat more reasonable. > > I'm still inclined to say that we should just stick with module > reloading and removing and re-inserting the device, but I wouldn't > insist on it.
I see. Just use what you suggested. Will update and repost. Thanks, Chunyan > > If we do print this kind of help message, then we should make sure to > print a more complete message that includes cut-and-paste commands for > *all* remaining unbound interfaces. > > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
