On Fri, 2016-01-29 at 15:59 +, Andy Smith wrote:
> Hi Ian,
>
> On Fri, Jan 29, 2016 at 02:57:23PM +, Ian Campbell wrote:
> > I spent a bit of time investigating this, but sadly I'm not able to
> > reproduce the basis failure.
>
> FWIW it was me who reported this with the packages in Debia
Hi Ian,
On Fri, Jan 29, 2016 at 02:57:23PM +, Ian Campbell wrote:
> I spent a bit of time investigating this, but sadly I'm not able to
> reproduce the basis failure.
FWIW it was me who reported this with the packages in Debian stable
(linux-image-3.16.0-4-amd64 3.16.7-ckt20-1+deb8u3,
xen-hyp
On Wed, 2016-01-27 at 10:57 +, Ian Campbell wrote:
>
> I'm still unable to spot what might have changed between 3.16.7-ckt20-
> 1+deb8u2 and 4.3.3-5 though to explain it going away, which I'd still
> quite liketo get to the bottom of in order to fix in Jessie.
I spent a bit of time investigat
On 2016-01-27 05:57, Ian Campbell wrote:
To summarise what I can tell from this bug log the following combinations
are/are not prone to this issue:
xen-??? xen-4.1 xen-4.4.1 4.4.1-9+deb8u3 xen-4.6.0
3.14.15-2Y[1]
3
On Tue, 2016-01-26 at 19:46 +0200, KSB wrote:
> > This is actually useful, because it shows that the issue occurs even
> > with
> > Xen 4.6, which I think rules out a Xen side issue (otherwise we'd have
> > had
> > lots more reports from 4.4 through to 4.6) and points to a kernel side
> > issue som
This is actually useful, because it shows that the issue occurs even with
Xen 4.6, which I think rules out a Xen side issue (otherwise we'd have had
lots more reports from 4.4 through to 4.6) and points to a kernel side
issue somewhere.
But I checked logs more thoroughly and found it even on mor
On Mon, 2016-01-25 at 20:36 +0200, KSB wrote:
> > Do you have a package version which you know to be good? How confident
> > are
> > you that it is ok (sometimes the problem is intermittent)?
> >
> > Lastly, is there any chance you upgraded the Xen packages at the same
> > time?
> > I'm starting t
On Mon, 2016-01-25 at 20:36 +0200, KSB wrote:
> > Do you have a package version which you know to be good? How confident
> > are
> > you that it is ok (sometimes the problem is intermittent)?
> >
> > Lastly, is there any chance you upgraded the Xen packages at the same
> > time?
> > I'm starting t
Do you have a package version which you know to be good? How confident are
you that it is ok (sometimes the problem is intermittent)?
Lastly, is there any chance you upgraded the Xen packages at the same time?
I'm starting to wonder if maybe this is not a kernel issue.
Sorry, but there is chanc
On Fri, 2016-01-22 at 21:38 +0200, KSB wrote:
> Seen this behavior on earlier kernels (i.e. 3.14-2-amd64 pkg 3.14.15-2.)
> and seems to be gone at least in 4.3
That's useful info thanks, I've been unable to pinpoint a culprit for this
for ages now.
Do you have a package version which you know to
Seen this behavior on earlier kernels (i.e. 3.14-2-amd64 pkg 3.14.15-2.)
and seems to be gone at least in 4.3
Hi,
I'm also seeing this.
With:
GRUB_CMDLINE_XEN="dom0_mem=1024M,max:1024M …"
I see a flurry of "xen:balloon: Cannot add additional memory (-17)"
messages every time a domU is shut down.
In this configuration I note that I also see with "free -m" that
dom0 has 929M, though "xl list" shows 1024
Hello,
I'm seeing the same.
After a fresh boot before starting any guests xl shows:
root@tank0:~# xl list 0
NameID Mem VCPUs State Time(s)
Domain-0 0 4096 8 r- 8.4
I did run "xl mem-set 0 4096
I'm experiencing this bug too. The effect is that one particular guest
cannot transmit on its vif.
xl.conf has 'autoballoon="off"', /etc/default/grub has
'GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=2048M,max:2048M"'
Trying the 'xl mem-set 0 4065' from earlier in the thread results in:
root@xen4:/sy
On Wednesday, 27.05.2015 at 10:05, Martin Lucina wrote:
> > Does "xl mem-set 0 4051" make the messages stop? If not what about using
> > 4050?
>
> I'm not sure if this is due to my rebooting the dom0 since I reported this
> issue, it now appears to be using a slightly different amount of memory
>
On Sunday, 17.05.2015 at 15:19, Ian Campbell wrote:
> One last thing... If you are able to try it then it would be interesting
> to know if the 4.0.x kernel from sid exhibits this behaviour too.
I can try this at some point next week when I have time to go and
physically kick the box in case it do
On Sunday, 17.05.2015 at 15:14, Ian Campbell wrote:
> On Thu, 2015-05-07 at 21:02 +0200, Martin Lucina wrote:
> > Note that despite the memory setting above, the dom0 has not been allocated
> > exactly the amount asked for:
> >
> > # xl list 0
> > NameID M
On Sun, 2015-05-17 at 15:14 +0100, Ian Campbell wrote:
> On Thu, 2015-05-07 at 21:02 +0200, Martin Lucina wrote:
> > Note that despite the memory setting above, the dom0 has not been allocated
> > exactly the amount asked for:
> >
> > # xl list 0
> > NameID
On Thu, 2015-05-07 at 21:02 +0200, Martin Lucina wrote:
> Note that despite the memory setting above, the dom0 has not been allocated
> exactly the amount asked for:
>
> # xl list 0
> NameID Mem VCPUsState Time(s)
> Domain-0
On Sun, 2015-05-17 at 14:51 +0100, Ian Campbell wrote:
> On Thu, 2015-05-07 at 21:02 +0200, Martin Lucina wrote:
> > Bug #776448 claims to have fixed this problem, however it seems that the
> > fix is incomplete?
>
> Yes, it was. It looks like I was even told and didn't notice:
> http://article.gm
On Thu, 2015-05-07 at 21:02 +0200, Martin Lucina wrote:
> Bug #776448 claims to have fixed this problem, however it seems that the
> fix is incomplete?
Yes, it was. It looks like I was even told and didn't notice:
http://article.gmane.org/gmane.comp.emulators.xen.devel/230401 :-/
I'll queue fd8b7
Package: linux-image-3.16.0-4-amd64
Version: 3.16.7-ckt9-3~deb8u1
Severity: normal
Dear maintainer,
my Xen dom0 is printing thousands of these messages to its logs:
# journalctl -b |grep "xen:balloon: Cannot add additional memory (-17)" | wc -l
126892
# uptime
20:50:08 up 3 days, 8:28, 7 user
22 matches
Mail list logo
