[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] BUG 4.2.2: xl cd-insert corrupts xenstore state
On 01/05/13 16:59, Ian Jackson wrote: George Dunlap writes ("Re: BUG 4.2.2: xl cd-insert corrupts xenstore state"):Turns out I already fixed this once! commit c3556e2a1aee3c9b7dda5d57e85e8867fff1b9da Author: George Dunlap <george.dunlap@xxxxxxxxxxxxx> Commit: George Dunlap <george.dunlap@xxxxxxxxxxxxx>Here's the backport, which was nearly trivial. I'll push this to 4.2 staging unless someone objevts. FYI, I'm pretty sure the effect this will have is to change the failure I was seeing in 4.2 (xl crashing) to the failure Fabio and I were seeing in 4.3 with cd-eject and cd-insert. I think the situation without this patch is: * cd-eject messes up xenstore, causes future block commands to crash * cd-insert works With this patch, I think what happen sis: * cd-eject fails but does not mess up xenstore * cd-insert also failsIt should be noted that this is only true *if blktap is available*; if blktap is not available, libxl uses qdev and everything works fine. (And I should emphasize, this is prediction based on my recent experience with unstable, and hasn't been verified by testing.) The problem actually turns out to be that if blktap is available, that libxl will choose it for cdroms, but the cd-insert and cd-eject stuff don't work with blktap. I think I'm going to submit a patch for 4.3 that prevents blktap from being used for cdroms -- you may want to wait and backport them both. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |