Re: current dom0 panic on domu launch

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Wed, Oct 21, 2009 at 05:24:33PM +1100, Sarton O'Brien wrote:
> [...]
>
> I tested by starting a domu, stopping a domu ... and all seemed fine up  
> until I had around 4 domu running. Then when stopping, the same problem  
> presented itself, domu gone but xvifs/vnds still there.

And at this point, could you determine from the logs if xenbackendd
did call the scripts to detach the backend devices ?

> ## dmesg - Start one domU ##
> xvif1.0: Ethernet address 00:16:3e:3c:07:01
> sysctl_createv: sysctl_create(xvif1.0) returned 22
> xvif1.0: could not attach sysctl nodes
> xbd backend: attach device vnd0d (size 83886080) for domain 1
> xbd backend: attach device sd0a (size 1953525168) for domain 1
> xbd backend 0x0 for domain 1 using event channel 17, protocol x86_64-abi
> xbd backend 0x1 for domain 1 using event channel 18, protocol x86_64-abi
>
> ## dmesg - Stop one domU ##
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 120 rsp_prod 119 rsp_prod_pvt 119 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 121 rsp_prod 120 rsp_prod_pvt 120 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 122 rsp_prod 121 rsp_prod_pvt 121 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 123 rsp_prod 122 rsp_prod_pvt 122 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 124 rsp_prod 123 rsp_prod_pvt 123 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 125 rsp_prod 124 rsp_prod_pvt 124 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 126 rsp_prod 125 rsp_prod_pvt 125 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 127 rsp_prod 126 rsp_prod_pvt 126 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 128 rsp_prod 127 rsp_prod_pvt 127 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 129 rsp_prod 128 rsp_prod_pvt 128 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 130 rsp_prod 129 rsp_prod_pvt 129 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 131 rsp_prod 130 rsp_prod_pvt 130 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 132 rsp_prod 131 rsp_prod_pvt 131 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 133 rsp_prod 132 rsp_prod_pvt 132 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 134 rsp_prod 133 rsp_prod_pvt 133 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 135 rsp_prod 134 rsp_prod_pvt 134 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 136 rsp_prod 135 rsp_prod_pvt 135 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 137 rsp_prod 136 rsp_prod_pvt 136 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 138 rsp_prod 137 rsp_prod_pvt 137 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 139 rsp_prod 138 rsp_prod_pvt 138 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 140 rsp_prod 139 rsp_prod_pvt 139 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 141 rsp_prod 140 rsp_prod_pvt 140 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 142 rsp_prod 141 rsp_prod_pvt 141 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 143 rsp_prod 142 rsp_prod_pvt 142 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 144 rsp_prod 143 rsp_prod_pvt 143 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 145 rsp_prod 144 rsp_prod_pvt 144 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 146 rsp_prod 145 rsp_prod_pvt 145 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 147 rsp_prod 146 rsp_prod_pvt 146 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 148 rsp_prod 147 rsp_prod_pvt 147 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 149 rsp_prod 148 rsp_prod_pvt 148 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 150 rsp_prod 149 rsp_prod_pvt 149 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 151 rsp_prod 150 rsp_prod_pvt 150 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 152 rsp_prod 151 rsp_prod_pvt 151 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 153 rsp_prod 152 rsp_prod_pvt 152 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 154 rsp_prod 153 rsp_prod_pvt 153 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 155 rsp_prod 154 rsp_prod_pvt 154 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 156 rsp_prod 155 rsp_prod_pvt 155 i 1
> xvif1.0 GNTTABOP_transfer[0] -1
> xvif1.0: req_prod 256 req_cons 157 rsp_prod 156 rsp_prod_pvt 156 i 1

That could be because the domU did go away, so the grant table is not
valid any more. Yet the kernel didn't notice that this device have
dissapeared.

At this point the output of xenstore-ls for this device would be interesting
(something like xenstore-ls /local/domain/0/backend/vif is what we
need I guess, and the same for vbd).

> The logs don't seem to contain anything other than what they usually do,  
> they don't seem to be very verbose. Should I be booting a debug xen 
> kernel?

that could help; debug messages will be in 'xm dmesg' 

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--