On 14/09/10 16:33, Michael Tokarev wrote:
14.09.2010 12:26, Brad Campbell wrote:
[]
Just a data point. An idle XP guest for me without -usb sees the host
running at about 8,000 context switches a second. With the guest using
-usb -usbdevice tablet, the host runs at between 15,000 - 18,000
On 11/09/10 00:03, Avi Kivity wrote:
On 09/10/2010 06:03 PM, Michael Tokarev wrote:
Strange. Can you also post a few lines of 'vmstat 1'?
Maybe we'll see a lot of context switches in there.
Not that many. Still running the same w7 guest, still
~25..27% CPU usage reported by top for the kvm
On 05/08/11 01:33, bugzilla-dae...@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=40542
--- Comment #2 from Slawek Rozbickisla...@rozbicki.eu 2011-08-04 17:33:52
---
http port is DNATed by iptables to gentoo guest on tap virtio adapter.
This looks like the bug
On 07/08/11 23:08, Avi Kivity wrote:
On 08/07/2011 04:39 PM, Brad Campbell wrote:
This looks like the bug I've been fighting with on and off.
What's the bugzilla number for that?
(unfortunately, no great insight except for CLOSED DUPLICATE)
hopefully someone from netdev can take a look
On 07/06/11 21:37, Eric Dumazet wrote:
Le mardi 07 juin 2011 à 21:27 +0800, Brad Campbell a écrit :
On 07/06/11 04:22, Eric Dumazet wrote:
Could you please try latest linux-2.6 tree ?
We fixed many networking bugs that could explain your crash.
No good I'm afraid.
[ 543.040056
G'day all,
I'm running a pretty standard home server
x86_64 Phenom-II 6 Core
16GB DDR 3
I run some virtual machines under that. 3 x Debian 64 Bit, 1 x XP 32
Bit. These run at boot.
When I fire up another XP 32 bit instance and play with it for more than
about 2 minutes, I get the panics
On 31/05/11 13:47, Borislav Petkov wrote:
Looks like a KSM issue. Disabling CONFIG_KSM should at least stop your
machine from oopsing.
Adding linux-mm.
I initially thought that, so the second panic was produced with KSM
disabled from boot.
echo 0 /sys/kernel/mm/ksm/run
If you still
On 31/05/11 18:38, Borislav Petkov wrote:
On Tue, May 31, 2011 at 05:26:10PM +0800, Brad Campbell wrote:
On 31/05/11 13:47, Borislav Petkov wrote:
Looks like a KSM issue. Disabling CONFIG_KSM should at least stop your
machine from oopsing.
Adding linux-mm.
I initially thought that, so
On 01/06/11 06:31, Hugh Dickins wrote:
Brad, my suspicion is that in each case the top 16 bits of RDX have been
mysteriously corrupted from to , causing the general protection
faults. I don't understand what that has to do with KSM.
No, nor do I. The panic I reproduced with KSM off
On 01/06/11 06:31, Hugh Dickins wrote:
Brad, my suspicion is that in each case the top 16 bits of RDX have been
mysteriously corrupted from to , causing the general protection
faults. I don't understand what that has to do with KSM.
But it's only a suspicion, because I can't make
On 01/06/11 09:15, Andrea Arcangeli wrote:
Hello,
On Wed, Jun 01, 2011 at 08:37:25AM +0800, Brad Campbell wrote:
On 01/06/11 06:31, Hugh Dickins wrote:
Brad, my suspicion is that in each case the top 16 bits of RDX have been
mysteriously corrupted from to , causing the general
On 01/06/11 12:52, Hugh Dickins wrote:
I guess Brad could try SLUB debugging, boot with slub_debug=P
for poisoning perhaps; though it might upset alignments and
drive the problem underground. Or see if the same happens
with SLAB instead of SLUB.
Not much use I'm afraid.
This is all I get in
On 01/06/11 17:41, Avi Kivity wrote:
On 06/01/2011 12:40 PM, Avi Kivity wrote:
bridge and netfilter, IIRC this was also the problem last time.
Do you have any ebtables loaded?
Never heard of them, but making a cursory check just in case..
brad@srv:/raid10/src/linux-2.6.39$ grep EBTABLE
On 01/06/11 19:18, CaT wrote:
On Wed, Jun 01, 2011 at 06:53:31PM +0800, Brad Campbell wrote:
I rebooted into a netfilter kernel, and did all the steps I'd used
on the no-netfilter kernel and it ticked along happily.
So the result of the experiment is inconclusive. Having said
On 02/06/11 07:03, CaT wrote:
On Wed, Jun 01, 2011 at 07:52:33PM +0800, Brad Campbell wrote:
Unfortunately the only interface that is mentioned by name anywhere
in my firewall is $DMZ (which is ppp0 and not part of any bridge).
All of the nat/dnat and other horrible hacks are based on IP
On 03/06/11 23:50, Bernhard Held wrote:
Am 03.06.2011 15:38, schrieb Brad Campbell:
On 02/06/11 07:03, CaT wrote:
On Wed, Jun 01, 2011 at 07:52:33PM +0800, Brad Campbell wrote:
Unfortunately the only interface that is mentioned by name anywhere
in my firewall is $DMZ (which is ppp0
On 05/06/11 16:14, Avi Kivity wrote:
On 06/03/2011 04:38 PM, Brad Campbell wrote:
Is there anyone who can point me at the appropriate cage to rattle? I
know it appears to be a netfilter issue, but I don't seem to be able
to get a message to the list (and I am subscribed to it and have been
On 07/06/11 04:10, Bart De Schuymer wrote:
Hi Brad,
This has probably nothing to do with ebtables, so please rmmod in case
it's loaded.
A few questions I didn't directly see an answer to in the threads I
scanned...
I'm assuming you actually use the bridging firewall functionality. So,
what
On 07/06/11 04:22, Eric Dumazet wrote:
Could you please try latest linux-2.6 tree ?
We fixed many networking bugs that could explain your crash.
No good I'm afraid.
[ 543.040056]
=
[ 543.040136] BUG
On 07/06/11 21:30, Patrick McHardy wrote:
On 07.06.2011 05:33, Brad Campbell wrote:
On 07/06/11 04:10, Bart De Schuymer wrote:
Hi Brad,
This has probably nothing to do with ebtables, so please rmmod in case
it's loaded.
A few questions I didn't directly see an answer to in the threads I
On 08/06/11 02:04, Bart De Schuymer wrote:
If the bug is easily triggered with your guest os, then you could try to
capture the traffic with wireshark (or something else) in a
configuration that doesn't crash your system. Save the traffic in a pcap
file. Then you can see if resending that
On 08/06/11 06:57, Patrick McHardy wrote:
On 07.06.2011 20:31, Eric Dumazet wrote:
Le mardi 07 juin 2011 à 17:35 +0200, Patrick McHardy a écrit :
The main suspects would be NAT and TCPMSS. Did you also try whether
the crash occurs with only one of these these rules?
I've just compiled out
On 07/06/11 23:35, Patrick McHardy wrote:
The main suspects would be NAT and TCPMSS. Did you also try whether
the crash occurs with only one of these these rules?
To be honest I'm actually having trouble finding where TCPMSS is
actually set in that ruleset. This is a production machine so I
On 08/06/11 11:59, Eric Dumazet wrote:
Well, a bisection definitely should help, but needs a lot of time in
your case.
Yes. compile, test, crash, walk out to the other building to press
reset, lather, rinse, repeat.
I need a reset button on the end of a 50M wire, or a hardware watchdog!
G'day all,
I'm at a bit of a loss. I run a CCTV storage server on a Windows XP
guest running on an AMD64 (Piledriver) host with 64 bit kernel and
userspace. This has been running well for a number of years.
I recently upgraded from a 3.15 kernel to 3.17 and now 3.18. The 3.15
kernel runs
On 16/03/15 23:10, Saso Slavicic wrote:
Hi,
I'm fairly experienced with KVM (Centos 5/6), running about a dozen servers
with 20-30 different (Linux MS platform) systems.
I have one Windows XP machine that acts very strangely - it freezes. I get
ping timeout for the VM from my monitoring and
On 31/03/15 05:11, Paolo Bonzini wrote:
On 22/03/2015 16:31, Brad Campbell wrote:
No help I'm afraid, but at least I can conclusively say that 3.16 is
good, and 3.17 is bad.
Can you try more specifically around the first KVM pull request? That
would be between c9b88e958182 (presumed good
On 31/03/15 14:29, Saso Slavicic wrote:
From: Brad Campbell
Sent: Tuesday, March 31, 2015 2:28 AM
If someone could give me some hard tests to do along the lines of what
Saso is up to I could probably get that done faster. With the right
bad kernel I can reproduce this lockup in a matter
On 31/03/15 16:56, Paolo Bonzini wrote:
On 31/03/2015 09:18, Brad Campbell wrote:
Better than that, it's recording h264 rtsp streams from 3 CCTV cameras,
so there is a constant network load of about 1.5-2MB/s (bytes not bits).
Come to think of it, out of the 3 XP VM's I have
On 31/03/15 05:11, Paolo Bonzini wrote:
On 22/03/2015 16:31, Brad Campbell wrote:
No help I'm afraid, but at least I can conclusively say that 3.16 is
good, and 3.17 is bad.
Can you try more specifically around the first KVM pull request? That
would be between c9b88e958182 (presumed good
On 13/04/15 22:02, Paolo Bonzini wrote:
Actually, if you have time to change your course of action, please
revert the one that Nadav pointed out (f210f7572bed, KVM: x86:
Fix lost interrupt on irr_pending race) or cherry-pick it on top of 3.17.
Ok, I've done just that. Started on a 3.17
On 13/04/15 20:38, Paolo Bonzini wrote:
On 13/04/2015 06:07, Brad Campbell wrote:
On 31/03/15 05:11, Paolo Bonzini wrote:
On 22/03/2015 16:31, Brad Campbell wrote:
No help I'm afraid, but at least I can conclusively say that 3.16 is
good, and 3.17 is bad.
Can you try more specifically
On 31/03/15 19:23, Paolo Bonzini wrote:
On 31/03/2015 13:16, Brad Campbell wrote:
If you look at the bisect point I'm currently at it's a mix of i2c and
arm. The only vaguely relevant (as far as I can see) commit is the
addition of the getrandom() syscall, so my bisect is looking dodgy
On 19/04/15 23:48, Nadav Amit wrote:
Brad Campbell lists2...@fnarfbargle.com wrote:
On 13/04/15 22:02, Paolo Bonzini wrote:
On 13/04/2015 14:45, Brad Campbell wrote:
G'day Paolo,
Yes, on AMD and I've tried hard to reproduce it on Intel and been unable
to thus far.
Now you mention it may
On 13/04/15 22:02, Paolo Bonzini wrote:
On 13/04/2015 14:45, Brad Campbell wrote:
G'day Paolo,
Yes, on AMD and I've tried hard to reproduce it on Intel and been unable
to thus far.
Now you mention it may be AMD specific, I have a spare motherboard and
processor sitting in a drawer. I'll
35 matches
Mail list logo
