| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] blkback stuck in infinite loop in xen_blkbk_discard()
>>> On 28.09.11 at 23:40, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> I just "xl destroy"d a domain, and now my dom0 kernel is sitting there
> infinitely spewing:
>
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
> vbd vbd-83-51712: 5 reading type
>
> which seems to be coming from the error case in
> drivers/block/xen-blkback/xenbus.c:xen_blkbk_discard().
>
> I don't know what the backtrace is. The system seems overall fine,
> despite the console spew, though I have a pile of dying domains sitting
> in odd states rather than being cleaned up.
I wonder how the function gets called during destroy in the first place,
and how that would prevent destroying a domain (unless there's a
feedback loop due to the use of xenbus_dev_fatal() here, causing
some xenstore entry to get written over and over again, triggering
the respective watch that blkback has active).
But irrespective of this I would think the function should bail without
doing anything if blkif->blk_backend_type was already set (or
couldn't get set). But that would then also indicate a more general
problem in connect(), as that function shouldn't do anything either
when a domain gets destroyed.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home