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
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
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,
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
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]
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
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
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
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
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
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
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
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:
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
just
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 Mem VCPUs
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
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 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 Mem
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
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:
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
22 matches
Mail list logo
