* Strange Network behaviour @ 2004-07-02 15:30 Hermann Gottschalk 2004-07-04 16:46 ` bert hubert 0 siblings, 1 reply; 29+ messages in thread From: Hermann Gottschalk @ 2004-07-02 15:30 UTC (permalink / raw) To: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1208 bytes --] Hi, following Situation: 4 Servers involved Hardware: - Motherboard: MSI MS-6728 - Onboard Gigabit NetworkInterface: Intel 82562EZ (e1000) - 100 MBit NetworkInterface: D-Link DFE-530TX (via-rhine) Connected through a 1GB-Switch and a 100MBit-Switch. The second connects about 40 X-Terminals too. On all Servers is a SuSE Linux 9.0 professional installed; online updates every night. When they start up, everything is fine. After some hours when i want to do a tcpdump on one of the Interfaces i get: 'tcpdump: socket: Address family not supported by protocol' ethereal doesn't find any interface. Sometimes some of the 100MBit-IFs didn't answer anymore. The only cure was to reboot. Neither rcnetwork restart nore unloading the network-module did help. This happend for a long time until there was a kernel patch from 2.4.21-215 to 2.4.21-266. Since it is installed this error doesn't appear anymore. On my home-system with a sis900 NW-IF the same happend once. But there too is kernel 2.4.21-266 now. Does someone has have made the same experience or does someone has an idea what was the reason. Thanks for any ideas in advance Greetings Hermann [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange Network behaviour 2004-07-02 15:30 Strange Network behaviour Hermann Gottschalk @ 2004-07-04 16:46 ` bert hubert 2004-07-14 8:00 ` Hermann Gottschalk 0 siblings, 1 reply; 29+ messages in thread From: bert hubert @ 2004-07-04 16:46 UTC (permalink / raw) To: Hermann Gottschalk; +Cc: linux-kernel On Fri, Jul 02, 2004 at 05:30:28PM +0200, Hermann Gottschalk wrote: > This happend for a long time until there was a kernel patch from > 2.4.21-215 to 2.4.21-266. Since it is installed this error doesn't > appear anymore. If it ever happens again, supply the output of ifconfig after it happens, and dmesg, and lspci -v -v -v. Sure looks like a weird error though, probably not related to your network interfaces. 'Protocol not available' is a weird one. Perhaps something with modules? -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing & Traffic Control HOWTO ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange Network behaviour 2004-07-04 16:46 ` bert hubert @ 2004-07-14 8:00 ` Hermann Gottschalk 2004-07-14 9:02 ` Roger Luethi 0 siblings, 1 reply; 29+ messages in thread From: Hermann Gottschalk @ 2004-07-14 8:00 UTC (permalink / raw) To: bert hubert; +Cc: linux-kernel On Sun, Jul 04, 2004 at 06:46:54PM +0200, bert hubert wrote: > On Fri, Jul 02, 2004 at 05:30:28PM +0200, Hermann Gottschalk wrote: > > > This happend for a long time until there was a kernel patch from > > 2.4.21-215 to 2.4.21-266. Since it is installed this error doesn't > > appear anymore. > > If it ever happens again, supply the output of ifconfig after it happens, > and dmesg, and lspci -v -v -v. Sure looks like a weird error though, > probably not related to your network interfaces. > > 'Protocol not available' is a weird one. > > Perhaps something with modules? OK, now after an "update" to 2.4.21-231 (SuSE 9.0) some similar Errors occur: 1) The via-rhine IF isn't accessible anymore. It's up but doesn't work. 2) We work with lvm and lvm-snapshots can't be removed anymore. I get a segmentation fault. Here the ouputs: ifconfig --------- eth0 Link encap:Ethernet HWaddr 00:0C:76:3F:D6:C4 inet addr:172.16.0.12 Bcast:172.16.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:207507 errors:0 dropped:0 overruns:0 frame:0 TX packets:196605 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:92145974 (87.8 Mb) TX bytes:64863064 (61.8 Mb) Interrupt:5 Base address:0xbc00 Memory:fe9e0000-fea00000 eth0:0 Link encap:Ethernet HWaddr 00:0C:76:3F:D6:C4 inet addr:172.16.2.12 Bcast:172.16.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:5 Base address:0xbc00 Memory:fe9e0000-fea00000 eth1 Link encap:Ethernet HWaddr 00:0D:88:4F:24:9B inet addr:192.168.0.12 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:12 Base address:0xc800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:130 errors:0 dropped:0 overruns:0 frame:0 TX packets:130 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11491 (11.2 Kb) TX bytes:11491 (11.2 Kb) --------- dmesg --------- : IRQ (10) already programmed PIC: IRQ (5) already programmed PIC: IRQ (12) already programmed ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 9 00:03:09[A] -> IRQ 9 Mode 1 Trigger 1 ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 9 PIC: IRQ (9) already programmed ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11 PIC: IRQ (11) already programmed PIC: IRQ (12) already programmed PIC: IRQ (9) already programmed PIC: IRQ (9) already programmed PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16) apm: overridden by ACPI. Starting kswapd bigpage subsystem: allocated 0 bigpages (=0MB). allocated 32 pages and 32 bhs reserved for the highmem bounces kinoded started VFS: Disk quotas vdquot_6.5.1 aio_setup: num_physpages = 131068 aio_setup: sizeof(struct page) = 48 vesafb: framebuffer at 0xf0000000, mapped to 0xf8817000, size 65536k vesafb: mode is 1024x768x16, linelength=2048, pages=1 vesafb: protected mode interface info at c000:ec70 vesafb: scrolling: redraw vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0 bootsplash 3.0.9-2003/09/08: looking for picture.... silenjpeg size 22326 bytes, found (1024x768, 11098 bytes, v3). bootsplash: silent jpeg found. bootsplash: silent jpeg found. Console: switching to colour frame buffer device 118x38 fb0: VESA VGA frame buffer device Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A keyboard: Timeout - AT keyboard not present?(ed) keyboard: Timeout - AT keyboard not present?(f4) Real Time Clock Driver v1.10e Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize loop: loaded (max 16 devices) Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX-4: IDE controller at PCI slot 00:1f.1 PCI: Enabling device 00:1f.1 (0005 -> 0007) PIIX-4: chipset revision 2 PIIX-4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio hdc: JLMS XJ-HD166S, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 ide-floppy driver 0.99.newide ide-floppy driver 0.99.newide md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 16384 buckets, 128Kbytes TCP: Hash tables configured (established 524288 bind 65536) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. cryptoapi: loaded RAMDISK: Compressed image found at block 0 Freeing initrd memory: 395k freed VFS: Mounted root (ext2 filesystem). SCSI subsystem driver Revision: 1.00 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 <Adaptec 29160 Ultra160 SCSI adapter> aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs (scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit) Vendor: MAXTOR Model: ATLAS10K4_73WLS Rev: DFV0 Type: Direct-Access ANSI SCSI revision: 03 scsi0:A:0:0: Tagged Queuing enabled. Depth 32 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sda: 143666192 512-byte hdwr sectors (73557 MB) Partition check: sda: sda1 sda2 sda3 sda4 < sda5 sda6 > Journalled Block Device driver loaded kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Trying to move old root to /initrd ... failed Unmounting old root Trying to free ramdisk memory ... okay Freeing unused kernel memory: 160k freed md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,3), internal journal lvm-mp: allocating 42 lowmem entries at c39b9000 LVM version 1.0.5+(mp-v6d)(22/07/2002) module loaded Adding Swap: 2104472k swap-space (priority 42) EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,3), internal journal kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,2), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,5), internal journal EXT3-fs: mounted filesystem with ordered data mode. ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on lvm(58,0), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on lvm(58,3), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on lvm(58,2), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on lvm(58,1), internal journal EXT3-fs: mounted filesystem with ordered data mode. bootsplash: silent jpeg found. Intel(R) PRO/1000 Network Driver - version 5.2.16 Copyright (c) 1999-2003 Intel Corporation. PCI: Setting latency timer of device 02:01.0 to 64 eth0: Intel(R) PRO/1000 Network Connection via-rhine.c:v1.10-LK1.1.17 March-1-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html eth1: VIA VT6105 Rhine-III at 0xc800, 00:0d:88:4f:24:9b, IRQ 12. eth1: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. raw1394: /dev/raw1394 device initialized usb.c: registered new driver usbdevfs usb.c: registered new driver hub PCI: Setting latency timer of device 00:1d.7 to 64 ehci_hcd 00:1d.7: Intel Corp. 82801EB USB2 Enhanced Host Controller ehci_hcd 00:1d.7: irq 12, pci mem fc995c00 usb.c: new USB bus registered, assigned bus number 1 ehci_hcd 00:1d.7: enabled 64bit PCI DMA PCI: 00:1d.7 PCI cache line size set incorrectly (0 bytes) by BIOS/FW. PCI: 00:1d.7 PCI cache line size corrected to 32. ehci_hcd 00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-19/2.4 hub.c: USB hub found hub.c: 8 ports detected usb-uhci.c: $Revision: 1.275 $ time 16:12:56 Jun 28 2004 usb-uhci.c: High bandwidth mode enabled PCI: Setting latency timer of device 00:1d.0 to 64 usb-uhci.c: USB UHCI at I/O 0xe000, IRQ 11 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected PCI: Setting latency timer of device 00:1d.1 to 64 usb-uhci.c: USB UHCI at I/O 0xe400, IRQ 12 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 3 hub.c: USB hub found hub.c: 2 ports detected PCI: Setting latency timer of device 00:1d.2 to 64 usb-uhci.c: USB UHCI at I/O 0xe800, IRQ 5 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 4 hub.c: USB hub found hub.c: 2 ports detected PCI: Setting latency timer of device 00:1d.3 to 64 usb-uhci.c: USB UHCI at I/O 0xec00, IRQ 11 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 5 hub.c: USB hub found hub.c: 2 ports detected usb-uhci.c: v1.275:USB Universal Host Controller Interface driver uhci.c: USB Universal Host Controller Interface driver v1.1 mice: PS/2 mouse device common for all mice e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex ACPI: Power Button (FF) [PWRF] ACPI: Processor [CPU1] (supports C1, 8 throttling states) ACPI: Processor [CPU2] (supports C1, 8 throttling states) Installing knfsd (copyright (C) 1996 okir@monad.swb.de). bootsplash: silent jpeg found. keyboard: Timeout - AT keyboard not present?(f4) eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found keyboard: Timeout - AT keyboard not present?(f4) keyboard: Timeout - AT keyboard not present?(f4) keyboard: Timeout - AT keyboard not present?(f4) keyboard: Timeout - AT keyboard not present?(f4) keyboard: Timeout - AT keyboard not present?(f4) keyboard: Timeout - AT keyboard not present?(f4) NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. device eth0 entered promiscuous mode device eth0 left promiscuous mode eth1: Promiscuous mode enabled. device eth1 entered promiscuous mode device eth1 left promiscuous mode eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. kernel BUG at memory.c:531! invalid operand: 0000 2.4.21-231-default #1 Mon Jun 28 15:39:34 UTC 2004 CPU: 0 EIP: 0010:[<c012db64>] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: c10db0b0 ecx: 0000000b edx: c27ffd40 esi: c2802670 edi: 00000000 ebp: 00000006 esp: caa93d7c ds: 0018 es: 0018 ss: 0018 Process lvremove (pid: 28873, stackpage=caa93000) Stack: c10db0b0 c39a2220 c012dfd7 c10db0b0 c3946c00 c3946c00 c3946600 c3975447 c39a2220 c39a2220 c39ed000 c39736c4 c3946c00 c3946770 4004fe21 00000000 c39ed000 bffff300 c3970940 00000000 c3979ca0 ffffffff c54c6a00 c5c377e8 Call Trace: [<c012dfd7>] (20) [<c3975447>] (16) [<c39736c4>] (28) [<c3970940>] (08) [<c3979ca0>] (16) [<c012f795>] (44) [<c0118718>] (28) [<c022615b>] (12) [<c02262b2>] (08) [<c024daf8>] (40) [<c022615b>] (12) [<c02262b2>] (04) [<c013437e>] (12) [<c0134488>] (36) [<c012f2d3>] (72) [<c014ed80>] (24) [<c0151c8a>] (16) [<c014492b>] (48) [<c0144a94>] (24) [<c01438f4>] (28) [<c01437b0>] (24) [<c0152e26>] (32) [<c0143b0c>] (20) [<c0108e13>] (60) Modules: [(lvm-mod:<c3970060>:<c397f644>)] Code: 0f 0b 13 02 a6 22 2a c0 eb dc 89 f6 55 57 56 53 57 57 83 7c <6>NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. NETDEV WATCHDOG: eth1: transmit timed out eth1: Transmit timed out, status 0000, PHY status 786d, resetting... eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. via-rhine.c:v1.10-LK1.1.17 March-1-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html via-rhine: Reset not complete yet. Trying harder. eth1: VIA VT6105 Rhine-III at 0xc800, 00:0d:88:4f:24:9b, IRQ 12. eth1: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1. eth1: Reset not complete yet. Trying harder. eth1: Setting full-duplex based on MII #1 link partner capability of 45e1. --------- lspci -v -v -v --------- 00:00.0 Host bridge: Intel Corp. 82865G/PE/P Processor to I/O Controller (rev 02) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7280 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M] Capabilities: [e4] #09 [2106] Capabilities: [a0] AGP version 3.0 Status: RQ=32 Iso- ArqSz=2 Cal=2 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP- GART64- 64bit- FW- Rate=<none> 00:01.0 PCI bridge: Intel Corp. 82865G/PE/P Processor to AGP Controller (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: 0000f000-00000fff Memory behind bridge: fc800000-fe8fffff Prefetchable memory behind bridge: efe00000-f7dfffff BridgeCtl: Parity+ SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B- 00:03.0 PCI bridge: Intel Corp. 82865G/PE/P Processor to PCI to CSA Bridge (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 0000b000-0000bfff Memory behind bridge: fe900000-fe9fffff Prefetchable memory behind bridge: fff00000-000fffff BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- 00:1d.0 USB Controller: Intel Corp. 82801EB USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7280 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 4: I/O ports at e000 [size=32] 00:1d.1 USB Controller: Intel Corp. 82801EB USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7280 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 12 Region 4: I/O ports at e400 [size=32] 00:1d.2 USB Controller: Intel Corp. 82801EB USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7280 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin C routed to IRQ 5 Region 4: I/O ports at e800 [size=32] 00:1d.3 USB Controller: Intel Corp. 82801EB USB (rev 02) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7280 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 4: I/O ports at ec00 [size=32] 00:1d.7 USB Controller: Intel Corp. 82801EB USB2 (rev 02) (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7280 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin D routed to IRQ 12 Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] #0a [20a0] 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI Bridge (rev c2) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR+ Latency: 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=32 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: fea00000-feafffff Prefetchable memory behind bridge: f7e00000-f7efffff BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- 00:1f.0 ISA bridge: Intel Corp. 82801EB LPC Interface Controller (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 00:1f.1 IDE interface: Intel Corp. 82801EB Ultra ATA Storage Controller (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7280 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 5 Region 0: I/O ports at <unassigned> Region 1: I/O ports at <unassigned> Region 2: I/O ports at <unassigned> Region 3: I/O ports at <unassigned> Region 4: I/O ports at fc00 [size=16] Region 5: Memory at 80000000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corp. 82801EB SMBus Controller (rev 02) Subsystem: Micro-Star International Co., Ltd.: Unknown device 7280 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin B routed to IRQ 10 Region 4: I/O ports at 0c00 [size=32] 01:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a4) (prog-if 00 [VGA]) Subsystem: LeadTek Research Inc.: Unknown device 2924 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 (1250ns min, 250ns max) Interrupt: pin A routed to IRQ 11 Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at f0000000 (32-bit, prefetchable) [size=64M] Expansion ROM at fe8e0000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 3.0 Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none> 02:01.0 Ethernet controller: Intel Corp.: Unknown device 1019 Subsystem: Micro-Star International Co., Ltd.: Unknown device 728c Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 (63750ns min), cache line size 08 Interrupt: pin A routed to IRQ 5 Region 0: Memory at fe9e0000 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at bc00 [size=32] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- 03:01.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02) Subsystem: Adaptec 29160 Ultra160 SCSI Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 (10000ns min, 6250ns max), cache line size 08 Interrupt: pin A routed to IRQ 10 BIST result: 00 Region 0: I/O ports at cc00 [disabled] [size=256] Region 1: Memory at feaff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at feac0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 03:03.0 Ethernet controller: VIA Technologies, Inc. VT6105 [Rhine-III] (rev 86) Subsystem: D-Link System Inc: Unknown device 1403 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 (750ns min, 2000ns max), cache line size 08 Interrupt: pin A routed to IRQ 12 Region 0: I/O ports at c800 [size=256] Region 1: Memory at feafef00 (32-bit, non-prefetchable) [size=256] Expansion ROM at feab0000 [disabled] [size=64K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- --------- Any ideas? Greetings Hermann -- ___ ___ _____ ___ ___ _ _ _ / _ \/ __|_ _/ __| / __|_ __ | |__| || | | (_) \__ \ | || (__ | (_ | ' \| '_ \ __ | \___/|___/ |_| \___| \___|_|_|_|_.__/_||_| ---------------------------------------------- OSTC Open Source Training and Consulting GmbH 90425 Nürnberg Web: http://www.ostc.de ---------------------------------------------- PGP-Key: 0x0B2D8EEA No HTML-Mails; 72 Characters per line ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange Network behaviour 2004-07-14 8:00 ` Hermann Gottschalk @ 2004-07-14 9:02 ` Roger Luethi 2004-07-14 10:28 ` Hermann Gottschalk 0 siblings, 1 reply; 29+ messages in thread From: Roger Luethi @ 2004-07-14 9:02 UTC (permalink / raw) To: Hermann Gottschalk; +Cc: bert hubert, linux-kernel On Wed, 14 Jul 2004 10:00:36 +0200, Hermann Gottschalk wrote: > OK, now after an "update" to 2.4.21-231 (SuSE 9.0) some similar > Errors occur: > > 1) The via-rhine IF isn't accessible anymore. It's up but doesn't work. > > 2) We work with lvm and lvm-snapshots can't be removed anymore. I > get a segmentation fault. Looks like you have more than one problem. The lvm related trace is hardly due to via-rhine (and you need to send it through ksymoops to get something useful). If you set debug in via-rhine to 3, you'll get a more interesting log. Does booting with noacpi help at all? Roger ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange Network behaviour 2004-07-14 9:02 ` Roger Luethi @ 2004-07-14 10:28 ` Hermann Gottschalk 2004-07-14 10:33 ` Roger Luethi 2004-07-14 16:13 ` Gene Heskett 0 siblings, 2 replies; 29+ messages in thread From: Hermann Gottschalk @ 2004-07-14 10:28 UTC (permalink / raw) To: Roger Luethi; +Cc: linux-kernel On Wed, Jul 14, 2004 at 11:02:08AM +0200, Roger Luethi wrote: > On Wed, 14 Jul 2004 10:00:36 +0200, Hermann Gottschalk wrote: > > OK, now after an "update" to 2.4.21-231 (SuSE 9.0) some similar > > Errors occur: > > > > 1) The via-rhine IF isn't accessible anymore. It's up but doesn't work. > > > > 2) We work with lvm and lvm-snapshots can't be removed anymore. I > > get a segmentation fault. > > Looks like you have more than one problem. The lvm related trace is > hardly due to via-rhine (and you need to send it through ksymoops > to get something useful). > > If you set debug in via-rhine to 3, you'll get a more interesting > log. Does booting with noacpi help at all? I will try noapic. Could it be a problem with lvm and nfs? The nfs-connection is sometimes very slow even there is no networkproblem on the e1000-IFs... -- ___ ___ _____ ___ ___ _ _ _ / _ \/ __|_ _/ __| / __|_ __ | |__| || | | (_) \__ \ | || (__ | (_ | ' \| '_ \ __ | \___/|___/ |_| \___| \___|_|_|_|_.__/_||_| ---------------------------------------------- OSTC Open Source Training and Consulting GmbH 90425 Nürnberg Web: http://www.ostc.de ---------------------------------------------- PGP-Key: 0x0B2D8EEA No HTML-Mails; 72 Characters per line ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange Network behaviour 2004-07-14 10:28 ` Hermann Gottschalk @ 2004-07-14 10:33 ` Roger Luethi 2004-07-14 10:40 ` Hermann Gottschalk 2004-07-14 16:13 ` Gene Heskett 1 sibling, 1 reply; 29+ messages in thread From: Roger Luethi @ 2004-07-14 10:33 UTC (permalink / raw) To: Hermann Gottschalk; +Cc: linux-kernel On Wed, 14 Jul 2004 12:28:49 +0200, Hermann Gottschalk wrote: > > If you set debug in via-rhine to 3, you'll get a more interesting > > log. Does booting with noacpi help at all? > > I will try noapic. noapic != noacpi Both ACPI and APIC have been known to cause problems, though. Roger ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange Network behaviour 2004-07-14 10:33 ` Roger Luethi @ 2004-07-14 10:40 ` Hermann Gottschalk 2004-07-14 10:48 ` Roger Luethi 0 siblings, 1 reply; 29+ messages in thread From: Hermann Gottschalk @ 2004-07-14 10:40 UTC (permalink / raw) To: Roger Luethi; +Cc: linux-kernel On Wed, Jul 14, 2004 at 12:33:12PM +0200, Roger Luethi wrote: > On Wed, 14 Jul 2004 12:28:49 +0200, Hermann Gottschalk wrote: > > > If you set debug in via-rhine to 3, you'll get a more interesting > > > log. Does booting with noacpi help at all? > > > > I will try noapic. > > noapic != noacpi > Both ACPI and APIC have been known to cause problems, though. noacpi doesn't exist as kernel-parameter (/usr/src/linux/Documentation/kernel-parameters.txt) -- ___ ___ _____ ___ ___ _ _ _ / _ \/ __|_ _/ __| / __|_ __ | |__| || | | (_) \__ \ | || (__ | (_ | ' \| '_ \ __ | \___/|___/ |_| \___| \___|_|_|_|_.__/_||_| ---------------------------------------------- OSTC Open Source Training and Consulting GmbH Hermann Gottschalk eMail: hg@ostc.de Dipl.-Phys. Univ. Tel: +49 911-18 06 25 6 Mobil: +49 173-36 00 68 0 Delsenbachweg 32 Fax: +49 911-18 06 27 7 90425 Nürnberg Web: http://www.ostc.de ---------------------------------------------- PGP-Key: 0x0B2D8EEA No HTML-Mails; 72 Characters per line ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange Network behaviour 2004-07-14 10:40 ` Hermann Gottschalk @ 2004-07-14 10:48 ` Roger Luethi [not found] ` <20040714105546.GA12380@ostc.de> 0 siblings, 1 reply; 29+ messages in thread From: Roger Luethi @ 2004-07-14 10:48 UTC (permalink / raw) To: Hermann Gottschalk; +Cc: linux-kernel On Wed, 14 Jul 2004 12:40:08 +0200, Hermann Gottschalk wrote: > On Wed, Jul 14, 2004 at 12:33:12PM +0200, Roger Luethi wrote: > > On Wed, 14 Jul 2004 12:28:49 +0200, Hermann Gottschalk wrote: > > > > If you set debug in via-rhine to 3, you'll get a more interesting > > > > log. Does booting with noacpi help at all? > > > > > > I will try noapic. > > > > noapic != noacpi > > Both ACPI and APIC have been known to cause problems, though. > > noacpi doesn't exist as kernel-parameter > (/usr/src/linux/Documentation/kernel-parameters.txt) Correct. acpi=off does. Roger ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <20040714105546.GA12380@ostc.de>]
[parent not found: <20040714110348.GA6393@k3.hellgate.ch>]
* Re: Strange Network behaviour [not found] ` <20040714110348.GA6393@k3.hellgate.ch> @ 2004-07-14 12:51 ` Hermann Gottschalk 0 siblings, 0 replies; 29+ messages in thread From: Hermann Gottschalk @ 2004-07-14 12:51 UTC (permalink / raw) To: Roger Luethi; +Cc: linux-kernel On Wed, Jul 14, 2004 at 01:03:48PM +0200, Roger Luethi wrote: > On Wed, 14 Jul 2004 12:55:46 +0200, Hermann Gottschalk wrote: > > After restart with noapic lvm causes the same problems... > > This seems unrelated to via-rhine. And please use ksymoops(8) to make > stack traces meaningful. Here what dmesg | ksymoops give: 0100000 (reserved) 1151MB HIGHMEM available. e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex kernel BUG at memory.c:531! invalid operand: 0000 2.4.21-231-default #1 Mon Jun 28 15:39:34 UTC 2004 CPU: 0 EIP: 0010:[<c012db64>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: c10e47a0 ecx: 0000000b edx: c27ffd40 esi: c28031f0 edi: 00000000 ebp: 00000004 esp: ca121d7c ds: 0018 es: 0018 ss: 0018 Process lvremove (pid: 8434, stackpage=ca121000) Stack: c10e47a0 c4485120 c012dfd7 c10e47a0 c4462800 c4462800 c4462000 c4495447 c4485120 c4485120 c44fa000 c44936c4 c4462800 c4462170 4004fe21 00000000 c44fa000 bffff320 c4490940 00000000 c4499ca0 ffffffff ca3f09a0 ca124ed0 Call Trace: [<c012dfd7>] (20) [<c4495447>] (16) [<c44936c4>] (28) [<c4490940>] (08) [<c4499ca0>] (16) [<c012f795>] (44) [<c0118718>] (56) [<c01c0d05>] (32) [<c013ab0c>] (16) [<c013437e>] (28) [<c86f2924>] (20) [<c012f2d3>] (72) [<c014ed80>] (24) [<c0151c8a>] (16) [<c014492b>] (16) [<c010c5b8>] (32) [<c0144a94>] (24) [<c01438f4>] (28) [<c01437b0>] (24) [<c0152e26>] (32) [<c0143b0c>] (20) [<c0108e13>] (60) Code: 0f 0b 13 02 a6 22 2a c0 eb dc 89 f6 55 57 56 53 57 57 83 7c >>EIP; c012db64 <unpin_pte_page+34/40> <===== >>ebx; c10e47a0 <_end+d0fbfc/2d8b4bc> >>edx; c27ffd40 <_end+242b19c/2d8b4bc> >>esi; c28031f0 <_end+242e64c/2d8b4bc> >>esp; ca121d7c <[af_packet]packet_socks_nr+53edd8/43bd0bc> Trace; c012dfd7 <unmap_kiobuf+17/50> Trace; c4495447 <[lvm-mod]lvm_snapshot_release+87/e0> Trace; c44936c4 <[lvm-mod]lvm_do_lv_remove+114/2f0> Trace; c4490940 <[lvm-mod]lvm_chr_ioctl+500/640> Trace; c4499ca0 <[lvm-mod]lv_req+0/a0> Trace; c012f795 <handle_mm_fault+95/150> Trace; c0118718 <do_page_fault+1b8/5b0> Trace; c01c0d05 <pty_write+115/150> Trace; c013ab0c <activate_page+8c/a0> Trace; c013437e <filemap_nopage+ce/200> Trace; c86f2924 <[e1000]e1000_clean_rx_irq+184/400> Trace; c012f2d3 <do_no_page+c3/3b0> Trace; c014ed80 <cached_lookup+10/60> Trace; c0151c8a <__link_path_walk+67a/6b0> Trace; c014492b <get_chrfops+ab/e0> Trace; c010c5b8 <call_do_IRQ+5/d> Trace; c0144a94 <chrdev_open+44/50> Trace; c01438f4 <dentry_open+134/1a0> Trace; c01437b0 <filp_open+50/60> Trace; c0152e26 <sys_ioctl+1d6/26a> Trace; c0143b0c <sys_open+5c/90> Trace; c0108e13 <system_call+33/40> Code; c012db64 <unpin_pte_page+34/40> 00000000 <_EIP>: Code; c012db64 <unpin_pte_page+34/40> <===== 0: 0f 0b ud2a <===== Code; c012db66 <unpin_pte_page+36/40> 2: 13 02 adc (%edx),%eax Code; c012db68 <unpin_pte_page+38/40> 4: a6 cmpsb %es:(%edi),%ds:(%esi) Code; c012db69 <unpin_pte_page+39/40> 5: 22 2a and (%edx),%ch Code; c012db6b <unpin_pte_page+3b/40> 7: c0 eb dc shr $0xdc,%bl Code; c012db6e <unpin_pte_page+3e/40> a: 89 f6 mov %esi,%esi Code; c012db70 <__get_user_pages+0/2c0> c: 55 push %ebp Code; c012db71 <__get_user_pages+1/2c0> d: 57 push %edi Code; c012db72 <__get_user_pages+2/2c0> e: 56 push %esi Code; c012db73 <__get_user_pages+3/2c0> f: 53 push %ebx Code; c012db74 <__get_user_pages+4/2c0> 10: 57 push %edi Code; c012db75 <__get_user_pages+5/2c0> 11: 57 push %edi Code; c012db76 <__get_user_pages+6/2c0> 12: 83 7c 00 00 00 cmpl $0x0,0x0(%eax,%eax,1) 1 warning issued. Results may not be reliable. -- ___ ___ _____ ___ ___ _ _ _ / _ \/ __|_ _/ __| / __|_ __ | |__| || | | (_) \__ \ | || (__ | (_ | ' \| '_ \ __ | \___/|___/ |_| \___| \___|_|_|_|_.__/_||_| ---------------------------------------------- OSTC Open Source Training and Consulting GmbH 90425 Nürnberg Web: http://www.ostc.de ---------------------------------------------- PGP-Key: 0x0B2D8EEA No HTML-Mails; 72 Characters per line ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange Network behaviour 2004-07-14 10:28 ` Hermann Gottschalk 2004-07-14 10:33 ` Roger Luethi @ 2004-07-14 16:13 ` Gene Heskett 1 sibling, 0 replies; 29+ messages in thread From: Gene Heskett @ 2004-07-14 16:13 UTC (permalink / raw) To: linux-kernel On Wednesday 14 July 2004 06:28, Hermann Gottschalk wrote: [...] >> If you set debug in via-rhine to 3, you'll get a more interesting >> log. Does booting with noacpi help at all? > >I will try noapic. > Thats a different option, he wrote 'noacpi' -- Cheers, Gene There are 4 boxes to be used in defense of liberty. Soap, ballot, jury, and ammo. Please use in that order, starting now. -Ed Howdershelt, Author Additions to this message made by Gene Heskett are Copyright 2004, Maurice E. Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Strange network behaviour
@ 2007-12-04 22:44 Mike
[not found] ` <4755D859.4090805-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>
0 siblings, 1 reply; 29+ messages in thread
From: Mike @ 2007-12-04 22:44 UTC (permalink / raw)
To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hello,
I already spoke to Izik Eidus. He told me to publish the results to the
problem at the mailinglist.
Some time ago I wrote to the kvm-devel mailinglist that I had a problem
with my guests' networking dying.
I got the hint to change the network card emulation. That worked.
Now I noticed a strange behaviour.
I have a gameserver running in a guest os. No problems on performance
side, really fast.
The only thing, when I make a ping test after unspecific time periods I
get this: (this peaks are even there if the gameserver isn't running)
Reply from 195.24.77.170: bytes=32 time=36ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=123ms TTL=57
Reply from 195.24.77.170: bytes=32 time=98ms TTL=57
Reply from 195.24.77.170: bytes=32 time=116ms TTL=57
Reply from 195.24.77.170: bytes=32 time=241ms TTL=57
Reply from 195.24.77.170: bytes=32 time=72ms TTL=57
Reply from 195.24.77.170: bytes=32 time=382ms TTL=57
Reply from 195.24.77.170: bytes=32 time=135ms TTL=57
Reply from 195.24.77.170: bytes=32 time=397ms TTL=57
Reply from 195.24.77.170: bytes=32 time=647ms TTL=57
Reply from 195.24.77.170: bytes=32 time=857ms TTL=57
Reply from 195.24.77.170: bytes=32 time=1156ms TTL=57
Reply from 195.24.77.170: bytes=32 time=692ms TTL=57
Reply from 195.24.77.170: bytes=32 time=604ms TTL=57
Reply from 195.24.77.170: bytes=32 time=35ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=35ms TTL=57
Reply from 195.24.77.170: bytes=32 time=188ms TTL=57
Reply from 195.24.77.170: bytes=32 time=39ms TTL=57
Reply from 195.24.77.170: bytes=32 time=46ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=39ms TTL=57
This ping peaks are on *all* guests I'm currently running.
I did a ping test the same time to the Host, with this result:
Reply from 195.24.77.169: bytes=32 time=38ms TTL=57
Reply from 195.24.77.169: bytes=32 time=34ms TTL=57
Reply from 195.24.77.169: bytes=32 time=39ms TTL=57
Reply from 195.24.77.169: bytes=32 time=33ms TTL=57
Reply from 195.24.77.169: bytes=32 time=38ms TTL=57
Reply from 195.24.77.169: bytes=32 time=34ms TTL=57
Reply from 195.24.77.169: bytes=32 time=34ms TTL=57
Reply from 195.24.77.169: bytes=32 time=33ms TTL=57
Reply from 195.24.77.169: bytes=32 time=35ms TTL=57
Reply from 195.24.77.169: bytes=32 time=40ms TTL=57
Reply from 195.24.77.169: bytes=32 time=33ms TTL=57
Reply from 195.24.77.169: bytes=32 time=33ms TTL=57
Reply from 195.24.77.169: bytes=32 time=34ms TTL=57
Reply from 195.24.77.169: bytes=32 time=35ms TTL=57
Reply from 195.24.77.169: bytes=32 time=34ms TTL=57
Reply from 195.24.77.169: bytes=32 time=35ms TTL=57
Reply from 195.24.77.169: bytes=32 time=37ms TTL=57
Reply from 195.24.77.169: bytes=32 time=33ms TTL=57
Reply from 195.24.77.169: bytes=32 time=33ms TTL=57
Reply from 195.24.77.169: bytes=32 time=35ms TTL=57
Reply from 195.24.77.169: bytes=32 time=33ms TTL=57
Reply from 195.24.77.169: bytes=32 time=34ms TTL=57
Reply from 195.24.77.169: bytes=32 time=34ms TTL=57
Reply from 195.24.77.169: bytes=32 time=33ms TTL=57
As you can see, no peaks.
Example of start command from a guest:
kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net
nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic
-daemonize
Here the pings from the guest started with the command line listed above:
Reply from 195.24.77.171: bytes=32 time=37ms TTL=57
Reply from 195.24.77.171: bytes=32 time=37ms TTL=57
Reply from 195.24.77.171: bytes=32 time=97ms TTL=57
Reply from 195.24.77.171: bytes=32 time=60ms TTL=57
Reply from 195.24.77.171: bytes=32 time=186ms TTL=57
Reply from 195.24.77.171: bytes=32 time=363ms TTL=57
Reply from 195.24.77.171: bytes=32 time=368ms TTL=57
Reply from 195.24.77.171: bytes=32 time=972ms TTL=57
Reply from 195.24.77.171: bytes=32 time=673ms TTL=57
Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57
Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57
Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57
Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57
Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57
Reply from 195.24.77.171: bytes=32 time=2006ms TTL=57
Reply from 195.24.77.171: bytes=32 time=2638ms TTL=57
Reply from 195.24.77.171: bytes=32 time=3590ms TTL=57
Reply from 195.24.77.171: bytes=32 time=383ms TTL=57
Reply from 195.24.77.171: bytes=32 time=35ms TTL=57
Reply from 195.24.77.171: bytes=32 time=35ms TTL=57
Reply from 195.24.77.171: bytes=32 time=34ms TTL=57
Reply from 195.24.77.171: bytes=32 time=35ms TTL=57
Reply from 195.24.77.171: bytes=32 time=34ms TTL=57
So I tried disabling kvm when starting a guest.
and here the guest *with* -no-kvm in the command line:
Reply from 195.24.77.170: bytes=32 time=35ms TTL=57
Reply from 195.24.77.170: bytes=32 time=36ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=35ms TTL=57
Reply from 195.24.77.170: bytes=32 time=36ms TTL=57
Reply from 195.24.77.170: bytes=32 time=37ms TTL=57
Reply from 195.24.77.170: bytes=32 time=33ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=38ms TTL=57
Reply from 195.24.77.170: bytes=32 time=33ms TTL=57
Reply from 195.24.77.170: bytes=32 time=35ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=35ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=37ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=33ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
Reply from 195.24.77.170: bytes=32 time=34ms TTL=57
The other guest, without -no-kvm have the ping peaks. Also here, no ping
peaks from the host.
Server load is really really low at the moment of the tests.
Maybe you have an idea where this peaks are coming from?
I'm using KVM-55 on Ubuntu 7.10 server with Kernel Linux A050
2.6.22-14-server #1 SMP Sun Oct 14 22:09:15 GMT 2007 x86_64 GNU/Linux.
My CPU is an AMD Athlon 64 X2 5600+ (Dual Core) with 8GByte of RAM.
Greetings from Luxembourg.
Mike Weimichkirch
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
^ permalink raw reply [flat|nested] 29+ messages in thread[parent not found: <4755D859.4090805-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <4755D859.4090805-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> @ 2007-12-05 7:53 ` Lynn Kerby [not found] ` <52FC3F66-4055-4C6C-9920-8FE4C6BD2CCA-br2HoPxSX4msTnJN9+BGXg@public.gmane.org> 2007-12-05 10:29 ` Avi Kivity 1 sibling, 1 reply; 29+ messages in thread From: Lynn Kerby @ 2007-12-05 7:53 UTC (permalink / raw) To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Hi Mike, Glad to hear that your networks are up now, but what are you using to connect/bridge them? Those response times are horrible across the board! All my VMs are connected to my internal network via a bridge on the host through their tap interfaces and a few lucky machines share another bridge that is on my DMZ with static IPs. I think the network bridge method I use is based on some stuff I picked up a few years ago when working with the UML virtualization stuff. I see sub millisecond ping responses in both directions and to all VMs (usually I've got 3 or 4 active, soon to expand to a few more). My HOST config is similar though I've got a only 4GB of memory and I'm still running KVM-52 modules. My guests are Ubuntu 7.10, Fedora 8, and FreeBSD 6.2 at the moment with Mint4.0 and JeOS on the drawing board. Lynn Kerby San Martin, CA On Dec 4, 2007, at 2:44 PM, Mike wrote: > Hello, > I already spoke to Izik Eidus. He told me to publish the results to > the > problem at the mailinglist. > > Some time ago I wrote to the kvm-devel mailinglist that I had a > problem > with my guests' networking dying. > I got the hint to change the network card emulation. That worked. > > Now I noticed a strange behaviour. > I have a gameserver running in a guest os. No problems on performance > side, really fast. > The only thing, when I make a ping test after unspecific time > periods I > get this: (this peaks are even there if the gameserver isn't running) > > Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=123ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=98ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=116ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=241ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=72ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=382ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=135ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=397ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=647ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=857ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=1156ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=692ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=604ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=188ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=46ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 > > This ping peaks are on *all* guests I'm currently running. > I did a ping test the same time to the Host, with this result: > > Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=39ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=40ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=37ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 > > As you can see, no peaks. > Example of start command from a guest: > kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net > nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic > -daemonize > > Here the pings from the guest started with the command line listed > above: > > Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=2006ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=2638ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=3590ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=383ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 > > So I tried disabling kvm when starting a guest. > and here the guest *with* -no-kvm in the command line: > > Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=38ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 > > The other guest, without -no-kvm have the ping peaks. Also here, no > ping > peaks from the host. > Server load is really really low at the moment of the tests. > > Maybe you have an idea where this peaks are coming from? > I'm using KVM-55 on Ubuntu 7.10 server with Kernel Linux A050 > 2.6.22-14-server #1 SMP Sun Oct 14 22:09:15 GMT 2007 x86_64 GNU/Linux. > My CPU is an AMD Athlon 64 X2 5600+ (Dual Core) with 8GByte of RAM. > > Greetings from Luxembourg. > Mike Weimichkirch > > ---------------------------------------------------------------------- > --- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > kvm-devel mailing list > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <52FC3F66-4055-4C6C-9920-8FE4C6BD2CCA-br2HoPxSX4msTnJN9+BGXg@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <52FC3F66-4055-4C6C-9920-8FE4C6BD2CCA-br2HoPxSX4msTnJN9+BGXg@public.gmane.org> @ 2007-12-05 9:06 ` Mike [not found] ` <47566A0B.8040105-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> 0 siblings, 1 reply; 29+ messages in thread From: Mike @ 2007-12-05 9:06 UTC (permalink / raw) To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Hello Lynn, I'm using a bridge, which is configured in my /etc/network/interfaces like this: auto br0 iface br0 inet static address 195.24.77.169 netmask 255.255.255.0 gateway 195.24.77.1 bridge_ports eth0 bridge_stp off bridge_maxwait 5 an I have a file called qemu-ifup in /etc which has the following content: #!/bin/sh /sbin/ifconfig $1 0.0.0.0 promisc up /usr/sbin/brctl addif br0 $1 sleep 2 Every guest has it's own tap device, atm tap0 - tap4 are in use. Those peaks are coming after +/- 10 mins (not always the same time, sometimes after 5 mins, it changes). Within this time, the guests have normal pings. Lynn Kerby schrieb: > Hi Mike, > > Glad to hear that your networks are up now, but what are you using to > connect/bridge them? Those response times are horrible across the > board! > > All my VMs are connected to my internal network via a bridge on the > host through their tap interfaces and a few lucky machines share > another bridge that is on my DMZ with static IPs. I think the > network bridge method I use is based on some stuff I picked up a few > years ago when working with the UML virtualization stuff. I see sub > millisecond ping responses in both directions and to all VMs (usually > I've got 3 or 4 active, soon to expand to a few more). > > My HOST config is similar though I've got a only 4GB of memory and > I'm still running KVM-52 modules. My guests are Ubuntu 7.10, Fedora > 8, and FreeBSD 6.2 at the moment with Mint4.0 and JeOS on the drawing > board. > > Lynn Kerby > San Martin, CA > > On Dec 4, 2007, at 2:44 PM, Mike wrote: > > >> Hello, >> I already spoke to Izik Eidus. He told me to publish the results to >> the >> problem at the mailinglist. >> >> Some time ago I wrote to the kvm-devel mailinglist that I had a >> problem >> with my guests' networking dying. >> I got the hint to change the network card emulation. That worked. >> >> Now I noticed a strange behaviour. >> I have a gameserver running in a guest os. No problems on performance >> side, really fast. >> The only thing, when I make a ping test after unspecific time >> periods I >> get this: (this peaks are even there if the gameserver isn't running) >> >> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=123ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=98ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=116ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=241ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=72ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=382ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=135ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=397ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=647ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=857ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=1156ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=692ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=604ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=188ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=46ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 >> >> This ping peaks are on *all* guests I'm currently running. >> I did a ping test the same time to the Host, with this result: >> >> Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=39ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=40ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=37ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >> >> As you can see, no peaks. >> Example of start command from a guest: >> kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net >> nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic >> -daemonize >> >> Here the pings from the guest started with the command line listed >> above: >> >> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=2006ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=2638ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=3590ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=383ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 >> >> So I tried disabling kvm when starting a guest. >> and here the guest *with* -no-kvm in the command line: >> >> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=38ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >> >> The other guest, without -no-kvm have the ping peaks. Also here, no >> ping >> peaks from the host. >> Server load is really really low at the moment of the tests. >> >> Maybe you have an idea where this peaks are coming from? >> I'm using KVM-55 on Ubuntu 7.10 server with Kernel Linux A050 >> 2.6.22-14-server #1 SMP Sun Oct 14 22:09:15 GMT 2007 x86_64 GNU/Linux. >> My CPU is an AMD Athlon 64 X2 5600+ (Dual Core) with 8GByte of RAM. >> >> Greetings from Luxembourg. >> Mike Weimichkirch >> >> ---------------------------------------------------------------------- >> --- >> SF.Net email is sponsored by: The Future of Linux Business White Paper >> from Novell. From the desktop to the data center, Linux is going >> mainstream. Let it simplify your IT future. >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >> _______________________________________________ >> kvm-devel mailing list >> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >> https://lists.sourceforge.net/lists/listinfo/kvm-devel >> > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > kvm-devel mailing list > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <47566A0B.8040105-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <47566A0B.8040105-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> @ 2007-12-05 9:17 ` Dor Laor [not found] ` <47566CB2.9060706-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 0 siblings, 1 reply; 29+ messages in thread From: Dor Laor @ 2007-12-05 9:17 UTC (permalink / raw) To: Mike; +Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f [-- Attachment #1.1: Type: text/plain, Size: 10831 bytes --] Mike wrote: > Hello Lynn, > > I'm using a bridge, which is configured in my /etc/network/interfaces > like this: > auto br0 > iface br0 inet static > address 195.24.77.169 > netmask 255.255.255.0 > gateway 195.24.77.1 > bridge_ports eth0 > bridge_stp off > bridge_maxwait 5 > > an I have a file called qemu-ifup in /etc which has the following content: > #!/bin/sh > /sbin/ifconfig $1 0.0.0.0 promisc up > /usr/sbin/brctl addif br0 $1 > sleep 2 > > Every guest has it's own tap device, atm tap0 - tap4 are in use. > Those peaks are coming after +/- 10 mins (not always the same time, > sometimes after 5 mins, it changes). Within this time, the guests have > normal pings. > > > It might be related to swapping (the host swaps guest pages). Please check the ram size used by the guest. Can you re-run the test with a single test or with disabling the swapping? Thanks, Dor. > Lynn Kerby schrieb: > >> Hi Mike, >> >> Glad to hear that your networks are up now, but what are you using to >> connect/bridge them? Those response times are horrible across the >> board! >> >> All my VMs are connected to my internal network via a bridge on the >> host through their tap interfaces and a few lucky machines share >> another bridge that is on my DMZ with static IPs. I think the >> network bridge method I use is based on some stuff I picked up a few >> years ago when working with the UML virtualization stuff. I see sub >> millisecond ping responses in both directions and to all VMs (usually >> I've got 3 or 4 active, soon to expand to a few more). >> >> My HOST config is similar though I've got a only 4GB of memory and >> I'm still running KVM-52 modules. My guests are Ubuntu 7.10, Fedora >> 8, and FreeBSD 6.2 at the moment with Mint4.0 and JeOS on the drawing >> board. >> >> Lynn Kerby >> San Martin, CA >> >> On Dec 4, 2007, at 2:44 PM, Mike wrote: >> >> >> >>> Hello, >>> I already spoke to Izik Eidus. He told me to publish the results to >>> the >>> problem at the mailinglist. >>> >>> Some time ago I wrote to the kvm-devel mailinglist that I had a >>> problem >>> with my guests' networking dying. >>> I got the hint to change the network card emulation. That worked. >>> >>> Now I noticed a strange behaviour. >>> I have a gameserver running in a guest os. No problems on performance >>> side, really fast. >>> The only thing, when I make a ping test after unspecific time >>> periods I >>> get this: (this peaks are even there if the gameserver isn't running) >>> >>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=123ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=98ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=116ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=241ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=72ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=382ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=135ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=397ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=647ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=857ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=1156ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=692ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=604ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=188ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=46ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 >>> >>> This ping peaks are on *all* guests I'm currently running. >>> I did a ping test the same time to the Host, with this result: >>> >>> Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=39ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=40ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>> >>> As you can see, no peaks. >>> Example of start command from a guest: >>> kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net >>> nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic >>> -daemonize >>> >>> Here the pings from the guest started with the command line listed >>> above: >>> >>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=2006ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=2638ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=3590ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=383ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 >>> >>> So I tried disabling kvm when starting a guest. >>> and here the guest *with* -no-kvm in the command line: >>> >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=38ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>> >>> The other guest, without -no-kvm have the ping peaks. Also here, no >>> ping >>> peaks from the host. >>> Server load is really really low at the moment of the tests. >>> >>> Maybe you have an idea where this peaks are coming from? >>> I'm using KVM-55 on Ubuntu 7.10 server with Kernel Linux A050 >>> 2.6.22-14-server #1 SMP Sun Oct 14 22:09:15 GMT 2007 x86_64 GNU/Linux. >>> My CPU is an AMD Athlon 64 X2 5600+ (Dual Core) with 8GByte of RAM. >>> >>> Greetings from Luxembourg. >>> Mike Weimichkirch >>> >>> ---------------------------------------------------------------------- >>> --- >>> SF.Net email is sponsored by: The Future of Linux Business White Paper >>> from Novell. From the desktop to the data center, Linux is going >>> mainstream. Let it simplify your IT future. >>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >>> _______________________________________________ >>> kvm-devel mailing list >>> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >>> https://lists.sourceforge.net/lists/listinfo/kvm-devel >>> >>> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: The Future of Linux Business White Paper >> from Novell. From the desktop to the data center, Linux is going >> mainstream. Let it simplify your IT future. >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >> _______________________________________________ >> kvm-devel mailing list >> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >> https://lists.sourceforge.net/lists/listinfo/kvm-devel >> >> >> > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > kvm-devel mailing list > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > [-- Attachment #1.2: Type: text/html, Size: 11667 bytes --] [-- Attachment #2: Type: text/plain, Size: 309 bytes --] ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 [-- Attachment #3: Type: text/plain, Size: 186 bytes --] _______________________________________________ kvm-devel mailing list kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/kvm-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <47566CB2.9060706-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <47566CB2.9060706-atKUWr5tajBWk0Htik3J/w@public.gmane.org> @ 2007-12-05 9:42 ` Mike 2007-12-05 9:46 ` Izik Eidus 1 sibling, 0 replies; 29+ messages in thread From: Mike @ 2007-12-05 9:42 UTC (permalink / raw) To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f I did a single test, only 1 guest running with kvm activated. The ping peaks are still there. How do I disable swapping? Mike Dor Laor schrieb: > Mike wrote: >> Hello Lynn, >> >> I'm using a bridge, which is configured in my /etc/network/interfaces >> like this: >> auto br0 >> iface br0 inet static >> address 195.24.77.169 >> netmask 255.255.255.0 >> gateway 195.24.77.1 >> bridge_ports eth0 >> bridge_stp off >> bridge_maxwait 5 >> >> an I have a file called qemu-ifup in /etc which has the following content: >> #!/bin/sh >> /sbin/ifconfig $1 0.0.0.0 promisc up >> /usr/sbin/brctl addif br0 $1 >> sleep 2 >> >> Every guest has it's own tap device, atm tap0 - tap4 are in use. >> Those peaks are coming after +/- 10 mins (not always the same time, >> sometimes after 5 mins, it changes). Within this time, the guests have >> normal pings. >> >> >> > It might be related to swapping (the host swaps guest pages). > Please check the ram size used by the guest. > > Can you re-run the test with a single test or with disabling the swapping? > Thanks, > Dor. >> Lynn Kerby schrieb: >> >>> Hi Mike, >>> >>> Glad to hear that your networks are up now, but what are you using to >>> connect/bridge them? Those response times are horrible across the >>> board! >>> >>> All my VMs are connected to my internal network via a bridge on the >>> host through their tap interfaces and a few lucky machines share >>> another bridge that is on my DMZ with static IPs. I think the >>> network bridge method I use is based on some stuff I picked up a few >>> years ago when working with the UML virtualization stuff. I see sub >>> millisecond ping responses in both directions and to all VMs (usually >>> I've got 3 or 4 active, soon to expand to a few more). >>> >>> My HOST config is similar though I've got a only 4GB of memory and >>> I'm still running KVM-52 modules. My guests are Ubuntu 7.10, Fedora >>> 8, and FreeBSD 6.2 at the moment with Mint4.0 and JeOS on the drawing >>> board. >>> >>> Lynn Kerby >>> San Martin, CA >>> >>> On Dec 4, 2007, at 2:44 PM, Mike wrote: >>> >>> >>> >>>> Hello, >>>> I already spoke to Izik Eidus. He told me to publish the results to >>>> the >>>> problem at the mailinglist. >>>> >>>> Some time ago I wrote to the kvm-devel mailinglist that I had a >>>> problem >>>> with my guests' networking dying. >>>> I got the hint to change the network card emulation. That worked. >>>> >>>> Now I noticed a strange behaviour. >>>> I have a gameserver running in a guest os. No problems on performance >>>> side, really fast. >>>> The only thing, when I make a ping test after unspecific time >>>> periods I >>>> get this: (this peaks are even there if the gameserver isn't running) >>>> >>>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=123ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=98ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=116ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=241ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=72ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=382ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=135ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=397ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=647ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=857ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=1156ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=692ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=604ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=188ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=46ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 >>>> >>>> This ping peaks are on *all* guests I'm currently running. >>>> I did a ping test the same time to the Host, with this result: >>>> >>>> Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=39ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=40ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> >>>> As you can see, no peaks. >>>> Example of start command from a guest: >>>> kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net >>>> nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic >>>> -daemonize >>>> >>>> Here the pings from the guest started with the command line listed >>>> above: >>>> >>>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=2006ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=2638ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=3590ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=383ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 >>>> >>>> So I tried disabling kvm when starting a guest. >>>> and here the guest *with* -no-kvm in the command line: >>>> >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=38ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> >>>> The other guest, without -no-kvm have the ping peaks. Also here, no >>>> ping >>>> peaks from the host. >>>> Server load is really really low at the moment of the tests. >>>> >>>> Maybe you have an idea where this peaks are coming from? >>>> I'm using KVM-55 on Ubuntu 7.10 server with Kernel Linux A050 >>>> 2.6.22-14-server #1 SMP Sun Oct 14 22:09:15 GMT 2007 x86_64 GNU/Linux. >>>> My CPU is an AMD Athlon 64 X2 5600+ (Dual Core) with 8GByte of RAM. >>>> >>>> Greetings from Luxembourg. >>>> Mike Weimichkirch >>>> >>>> ---------------------------------------------------------------------- >>>> --- >>>> SF.Net email is sponsored by: The Future of Linux Business White Paper >>>> from Novell. From the desktop to the data center, Linux is going >>>> mainstream. Let it simplify your IT future. >>>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >>>> _______________________________________________ >>>> kvm-devel mailing list >>>> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >>>> https://lists.sourceforge.net/lists/listinfo/kvm-devel >>>> >>>> >>> ------------------------------------------------------------------------- >>> SF.Net email is sponsored by: The Future of Linux Business White Paper >>> from Novell. From the desktop to the data center, Linux is going >>> mainstream. Let it simplify your IT future. >>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >>> _______________________________________________ >>> kvm-devel mailing list >>> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >>> https://lists.sourceforge.net/lists/listinfo/kvm-devel >>> >>> >>> >> >> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: The Future of Linux Business White Paper >> from Novell. From the desktop to the data center, Linux is going >> mainstream. Let it simplify your IT future. >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >> _______________________________________________ >> kvm-devel mailing list >> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >> https://lists.sourceforge.net/lists/listinfo/kvm-devel >> >> > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > ------------------------------------------------------------------------ > > _______________________________________________ > kvm-devel mailing list > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel > ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange network behaviour [not found] ` <47566CB2.9060706-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 2007-12-05 9:42 ` Mike @ 2007-12-05 9:46 ` Izik Eidus 1 sibling, 0 replies; 29+ messages in thread From: Izik Eidus @ 2007-12-05 9:46 UTC (permalink / raw) To: dor.laor-atKUWr5tajBWk0Htik3J/w Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Mike Dor Laor wrote: > Mike wrote: >> Hello Lynn, >> >> I'm using a bridge, which is configured in my /etc/network/interfaces >> like this: >> auto br0 >> iface br0 inet static >> address 195.24.77.169 >> netmask 255.255.255.0 >> gateway 195.24.77.1 >> bridge_ports eth0 >> bridge_stp off >> bridge_maxwait 5 >> >> an I have a file called qemu-ifup in /etc which has the following content: >> #!/bin/sh >> /sbin/ifconfig $1 0.0.0.0 promisc up >> /usr/sbin/brctl addif br0 $1 >> sleep 2 >> >> Every guest has it's own tap device, atm tap0 - tap4 are in use. >> Those peaks are coming after +/- 10 mins (not always the same time, >> sometimes after 5 mins, it changes). Within this time, the guests have >> normal pings. >> >> >> > It might be related to swapping (the host swaps guest pages). > Please check the ram size used by the guest. it doesnt look like swapping, beacuse all the qemu memory is swappable, so i guess this not the reason > > Can you re-run the test with a single test or with disabling the swapping? > Thanks, > Dor. >> Lynn Kerby schrieb: >> >>> Hi Mike, >>> >>> Glad to hear that your networks are up now, but what are you using to >>> connect/bridge them? Those response times are horrible across the >>> board! >>> >>> All my VMs are connected to my internal network via a bridge on the >>> host through their tap interfaces and a few lucky machines share >>> another bridge that is on my DMZ with static IPs. I think the >>> network bridge method I use is based on some stuff I picked up a few >>> years ago when working with the UML virtualization stuff. I see sub >>> millisecond ping responses in both directions and to all VMs (usually >>> I've got 3 or 4 active, soon to expand to a few more). >>> >>> My HOST config is similar though I've got a only 4GB of memory and >>> I'm still running KVM-52 modules. My guests are Ubuntu 7.10, Fedora >>> 8, and FreeBSD 6.2 at the moment with Mint4.0 and JeOS on the drawing >>> board. >>> >>> Lynn Kerby >>> San Martin, CA >>> >>> On Dec 4, 2007, at 2:44 PM, Mike wrote: >>> >>> >>> >>>> Hello, >>>> I already spoke to Izik Eidus. He told me to publish the results to >>>> the >>>> problem at the mailinglist. >>>> >>>> Some time ago I wrote to the kvm-devel mailinglist that I had a >>>> problem >>>> with my guests' networking dying. >>>> I got the hint to change the network card emulation. That worked. >>>> >>>> Now I noticed a strange behaviour. >>>> I have a gameserver running in a guest os. No problems on performance >>>> side, really fast. >>>> The only thing, when I make a ping test after unspecific time >>>> periods I >>>> get this: (this peaks are even there if the gameserver isn't running) >>>> >>>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=123ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=98ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=116ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=241ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=72ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=382ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=135ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=397ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=647ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=857ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=1156ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=692ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=604ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=188ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=46ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=39ms TTL=57 >>>> >>>> This ping peaks are on *all* guests I'm currently running. >>>> I did a ping test the same time to the Host, with this result: >>>> >>>> Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=39ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=38ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=40ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.169: bytes=32 time=33ms TTL=57 >>>> >>>> As you can see, no peaks. >>>> Example of start command from a guest: >>>> kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net >>>> nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic >>>> -daemonize >>>> >>>> Here the pings from the guest started with the command line listed >>>> above: >>>> >>>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=2006ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=2638ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=3590ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=383ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=34ms TTL=57 >>>> >>>> So I tried disabling kvm when starting a guest. >>>> and here the guest *with* -no-kvm in the command line: >>>> >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=36ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=38ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=35ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=33ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> Reply from 195.24.77.170: bytes=32 time=34ms TTL=57 >>>> >>>> The other guest, without -no-kvm have the ping peaks. Also here, no >>>> ping >>>> peaks from the host. >>>> Server load is really really low at the moment of the tests. >>>> >>>> Maybe you have an idea where this peaks are coming from? >>>> I'm using KVM-55 on Ubuntu 7.10 server with Kernel Linux A050 >>>> 2.6.22-14-server #1 SMP Sun Oct 14 22:09:15 GMT 2007 x86_64 GNU/Linux. >>>> My CPU is an AMD Athlon 64 X2 5600+ (Dual Core) with 8GByte of RAM. >>>> >>>> Greetings from Luxembourg. >>>> Mike Weimichkirch >>>> >>>> ---------------------------------------------------------------------- >>>> --- >>>> SF.Net email is sponsored by: The Future of Linux Business White Paper >>>> from Novell. From the desktop to the data center, Linux is going >>>> mainstream. Let it simplify your IT future. >>>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >>>> _______________________________________________ >>>> kvm-devel mailing list >>>> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >>>> https://lists.sourceforge.net/lists/listinfo/kvm-devel >>>> >>>> >>> ------------------------------------------------------------------------- >>> SF.Net email is sponsored by: The Future of Linux Business White Paper >>> from Novell. From the desktop to the data center, Linux is going >>> mainstream. Let it simplify your IT future. >>> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >>> _______________________________________________ >>> kvm-devel mailing list >>> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >>> https://lists.sourceforge.net/lists/listinfo/kvm-devel >>> >>> >>> >> >> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: The Future of Linux Business White Paper >> from Novell. From the desktop to the data center, Linux is going >> mainstream. Let it simplify your IT future. >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >> _______________________________________________ >> kvm-devel mailing list >> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >> https://lists.sourceforge.net/lists/listinfo/kvm-devel >> >> > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > ------------------------------------------------------------------------ > > _______________________________________________ > kvm-devel mailing list > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel > ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange network behaviour [not found] ` <4755D859.4090805-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> 2007-12-05 7:53 ` Lynn Kerby @ 2007-12-05 10:29 ` Avi Kivity [not found] ` <47567D6D.8060802-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 1 sibling, 1 reply; 29+ messages in thread From: Avi Kivity @ 2007-12-05 10:29 UTC (permalink / raw) To: Mike; +Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Mike wrote: > Now I noticed a strange behaviour. > I have a gameserver running in a guest os. No problems on performance > side, really fast. > The only thing, when I make a ping test after unspecific time periods I > get this: (this peaks are even there if the gameserver isn't running) > > > As you can see, no peaks. > Example of start command from a guest: > kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net > nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic > -daemonize > > Here the pings from the guest started with the command line listed above: > > Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 > Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 > What guest are you running? 'kvm' isn't the name of the binary generated by make. Are you sure it is actually the binary from kvm-55? -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <47567D6D.8060802-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <47567D6D.8060802-atKUWr5tajBWk0Htik3J/w@public.gmane.org> @ 2007-12-05 10:39 ` Mike [not found] ` <47567FC7.9040106-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> 2007-12-05 10:55 ` Pelle 1 sibling, 1 reply; 29+ messages in thread From: Mike @ 2007-12-05 10:39 UTC (permalink / raw) To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Avi Kivity schrieb: > Mike wrote: > >> Now I noticed a strange behaviour. >> I have a gameserver running in a guest os. No problems on performance >> side, really fast. >> The only thing, when I make a ping test after unspecific time periods I >> get this: (this peaks are even there if the gameserver isn't running) >> >> >> As you can see, no peaks. >> Example of start command from a guest: >> kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net >> nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic >> -daemonize >> >> Here the pings from the guest started with the command line listed above: >> >> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 >> >> > > What guest are you running? > > 'kvm' isn't the name of the binary generated by make. Are you sure it > is actually the binary from kvm-55? > > I'm running debian etch with kernel Linux 2.6.18-5-486 #1 Tue Oct 2 23:38:54 UTC 2007 i686 GNU/Linux as guest. All the guests are running this distr. My kvm is pointing to /usr/local/bin/qemu-system-x86_64 2007-12-04 15:29 /usr/local/bin/qemu-system-x86_64 That's the time I compiled kvm-55. ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <47567FC7.9040106-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <47567FC7.9040106-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> @ 2007-12-05 10:43 ` Avi Kivity [not found] ` <475680E8.4060508-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 0 siblings, 1 reply; 29+ messages in thread From: Avi Kivity @ 2007-12-05 10:43 UTC (permalink / raw) To: Mike; +Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Mike wrote: > Avi Kivity schrieb: > >> Mike wrote: >> >> >>> Now I noticed a strange behaviour. >>> I have a gameserver running in a guest os. No problems on performance >>> side, really fast. >>> The only thing, when I make a ping test after unspecific time periods I >>> get this: (this peaks are even there if the gameserver isn't running) >>> >>> >>> As you can see, no peaks. >>> Example of start command from a guest: >>> kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net >>> nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic >>> -daemonize >>> >>> Here the pings from the guest started with the command line listed above: >>> >>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 >>> Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 >>> >>> >>> >> What guest are you running? >> >> 'kvm' isn't the name of the binary generated by make. Are you sure it >> is actually the binary from kvm-55? >> >> >> > I'm running debian etch with kernel Linux 2.6.18-5-486 #1 Tue Oct 2 > 23:38:54 UTC 2007 i686 GNU/Linux > as guest. All the guests are running this distr. > My kvm is pointing to /usr/local/bin/qemu-system-x86_64 > 2007-12-04 15:29 /usr/local/bin/qemu-system-x86_64 > Ok. How long does it take for the latency to appear? If it isn't too long, please run kvm with strace -fF -ttT -o /tmp/trace kvm ... Note the time that latency appears so we can correlate with the logs. Be aware the logs can be quite large, so make sure you have some disk space ready. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <475680E8.4060508-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <475680E8.4060508-atKUWr5tajBWk0Htik3J/w@public.gmane.org> @ 2007-12-05 11:22 ` Mike [not found] ` <475689E0.5020901-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> 0 siblings, 1 reply; 29+ messages in thread From: Mike @ 2007-12-05 11:22 UTC (permalink / raw) To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f You can download the requested trace at http://www.eliteserver.biz/trace.tar.gz the peaks were around 12:04:30 Mike Avi Kivity schrieb: > Mike wrote: > >> Avi Kivity schrieb: >> >> >>> Mike wrote: >>> >>> >>> >>>> Now I noticed a strange behaviour. >>>> I have a gameserver running in a guest os. No problems on performance >>>> side, really fast. >>>> The only thing, when I make a ping test after unspecific time periods I >>>> get this: (this peaks are even there if the gameserver isn't running) >>>> >>>> >>>> As you can see, no peaks. >>>> Example of start command from a guest: >>>> kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net >>>> nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic >>>> -daemonize >>>> >>>> Here the pings from the guest started with the command line listed above: >>>> >>>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 >>>> Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 >>>> >>>> >>>> >>>> >>> What guest are you running? >>> >>> 'kvm' isn't the name of the binary generated by make. Are you sure it >>> is actually the binary from kvm-55? >>> >>> >>> >>> >> I'm running debian etch with kernel Linux 2.6.18-5-486 #1 Tue Oct 2 >> 23:38:54 UTC 2007 i686 GNU/Linux >> as guest. All the guests are running this distr. >> My kvm is pointing to /usr/local/bin/qemu-system-x86_64 >> 2007-12-04 15:29 /usr/local/bin/qemu-system-x86_64 >> >> > > Ok. How long does it take for the latency to appear? If it isn't too > long, please run kvm with > > strace -fF -ttT -o /tmp/trace kvm ... > > Note the time that latency appears so we can correlate with the logs. > Be aware the logs can be quite large, so make sure you have some disk > space ready. > > > ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <475689E0.5020901-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <475689E0.5020901-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> @ 2007-12-05 11:46 ` Uri Lublin 2007-12-05 13:18 ` Avi Kivity 1 sibling, 0 replies; 29+ messages in thread From: Uri Lublin @ 2007-12-05 11:46 UTC (permalink / raw) To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Mike wrote: > You can download the requested trace at > http://www.eliteserver.biz/trace.tar.gz > > the peaks were around 12:04:30 > > Mike > > Avi Kivity schrieb: > >> Mike wrote: >> >>> Avi Kivity schrieb: >>> >>>> Mike wrote: >>>> >>>>> Now I noticed a strange behaviour. >>>>> I have a gameserver running in a guest os. No problems on performance >>>>> side, really fast. >>>>> The only thing, when I make a ping test after unspecific time periods I >>>>> get this: (this peaks are even there if the gameserver isn't running) >>>>> >>>>> >>>>> As you can see, no peaks. >>>>> Example of start command from a guest: >>>>> kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net >>>>> nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic >>>>> -daemonize >>>>> >>>>> Here the pings from the guest started with the command line listed above: >>>>> >>>>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 >>>>> Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 >>>>> >> Ok. How long does it take for the latency to appear? If it isn't too >> long, please run kvm with >> >> strace -fF -ttT -o /tmp/trace kvm ... >> >> Note the time that latency appears so we can correlate with the logs. >> Be aware the logs can be quite large, so make sure you have some disk >> space ready. >> > Does using a different clock helps ( add "-clock hpet" or "-clock rtc" or "-clock unix" to kvm command line) ? ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange network behaviour [not found] ` <475689E0.5020901-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> 2007-12-05 11:46 ` Uri Lublin @ 2007-12-05 13:18 ` Avi Kivity [not found] ` <4756A538.1050303-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 1 sibling, 1 reply; 29+ messages in thread From: Avi Kivity @ 2007-12-05 13:18 UTC (permalink / raw) To: Mike; +Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Mike wrote: > You can download the requested trace at > http://www.eliteserver.biz/trace.tar.gz > > the peaks were around 12:04:30 > > Can you rerun, this time with additional options '-x -s 80' to strace (so I can identify the pings from random broadcast noise on the network). Also please run ping on the host itself, so I get regular timing without jitter from the Internet. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <4756A538.1050303-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <4756A538.1050303-atKUWr5tajBWk0Htik3J/w@public.gmane.org> @ 2007-12-05 14:13 ` Mike [not found] ` <4756B1F6.5080102-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> 0 siblings, 1 reply; 29+ messages in thread From: Mike @ 2007-12-05 14:13 UTC (permalink / raw) To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Sure, here the ping results from the host to the guest atm of the peaks: 64 bytes from postfix (195.24.77.173): icmp_seq=347 ttl=64 time=10.6 ms 64 bytes from postfix (195.24.77.173): icmp_seq=348 ttl=64 time=11.6 ms 64 bytes from postfix (195.24.77.173): icmp_seq=349 ttl=64 time=11.6 ms 64 bytes from postfix (195.24.77.173): icmp_seq=350 ttl=64 time=465 ms 64 bytes from postfix (195.24.77.173): icmp_seq=351 ttl=64 time=455 ms 64 bytes from postfix (195.24.77.173): icmp_seq=352 ttl=64 time=349 ms 64 bytes from postfix (195.24.77.173): icmp_seq=353 ttl=64 time=314 ms 64 bytes from postfix (195.24.77.173): icmp_seq=354 ttl=64 time=483 ms 64 bytes from postfix (195.24.77.173): icmp_seq=355 ttl=64 time=871 ms 64 bytes from postfix (195.24.77.173): icmp_seq=357 ttl=64 time=1889 ms 64 bytes from postfix (195.24.77.173): icmp_seq=358 ttl=64 time=1635 ms 64 bytes from postfix (195.24.77.173): icmp_seq=359 ttl=64 time=1973 ms 64 bytes from postfix (195.24.77.173): icmp_seq=360 ttl=64 time=1796 ms 64 bytes from postfix (195.24.77.173): icmp_seq=361 ttl=64 time=1961 ms 64 bytes from postfix (195.24.77.173): icmp_seq=362 ttl=64 time=2029 ms 64 bytes from postfix (195.24.77.173): icmp_seq=363 ttl=64 time=1994 ms 64 bytes from postfix (195.24.77.173): icmp_seq=364 ttl=64 time=1689 ms 64 bytes from postfix (195.24.77.173): icmp_seq=365 ttl=64 time=932 ms 64 bytes from postfix (195.24.77.173): icmp_seq=366 ttl=64 time=899 ms 64 bytes from postfix (195.24.77.173): icmp_seq=367 ttl=64 time=752 ms 64 bytes from postfix (195.24.77.173): icmp_seq=368 ttl=64 time=860 ms 64 bytes from postfix (195.24.77.173): icmp_seq=369 ttl=64 time=483 ms 64 bytes from postfix (195.24.77.173): icmp_seq=370 ttl=64 time=244 ms 64 bytes from postfix (195.24.77.173): icmp_seq=371 ttl=64 time=7.89 ms 64 bytes from postfix (195.24.77.173): icmp_seq=372 ttl=64 time=5.98 ms 64 bytes from postfix (195.24.77.173): icmp_seq=373 ttl=64 time=6.31 ms The peaks started @ +/- 14:53:39 and ended @ +/- 14:53:59 You can download the trace file at: http://www.eliteserver.biz/trace2.tar.gz Avi Kivity schrieb: > Mike wrote: > >> You can download the requested trace at >> http://www.eliteserver.biz/trace.tar.gz >> >> the peaks were around 12:04:30 >> >> >> > > Can you rerun, this time with additional options '-x -s 80' to strace > (so I can identify the pings from random broadcast noise on the > network). Also please run ping on the host itself, so I get regular > timing without jitter from the Internet. > > > ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <4756B1F6.5080102-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <4756B1F6.5080102-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> @ 2007-12-05 15:56 ` Avi Kivity [not found] ` <4756CA29.5030501-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 0 siblings, 1 reply; 29+ messages in thread From: Avi Kivity @ 2007-12-05 15:56 UTC (permalink / raw) To: Mike; +Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Mike wrote: > Sure, > here the ping results from the host to the guest atm of the peaks: > 64 bytes from postfix (195.24.77.173): icmp_seq=347 ttl=64 time=10.6 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=348 ttl=64 time=11.6 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=349 ttl=64 time=11.6 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=350 ttl=64 time=465 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=351 ttl=64 time=455 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=352 ttl=64 time=349 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=353 ttl=64 time=314 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=354 ttl=64 time=483 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=355 ttl=64 time=871 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=357 ttl=64 time=1889 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=358 ttl=64 time=1635 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=359 ttl=64 time=1973 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=360 ttl=64 time=1796 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=361 ttl=64 time=1961 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=362 ttl=64 time=2029 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=363 ttl=64 time=1994 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=364 ttl=64 time=1689 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=365 ttl=64 time=932 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=366 ttl=64 time=899 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=367 ttl=64 time=752 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=368 ttl=64 time=860 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=369 ttl=64 time=483 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=370 ttl=64 time=244 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=371 ttl=64 time=7.89 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=372 ttl=64 time=5.98 ms > 64 bytes from postfix (195.24.77.173): icmp_seq=373 ttl=64 time=6.31 ms > > The peaks started @ +/- 14:53:39 and ended @ +/- 14:53:59 > You can download the trace file at: > http://www.eliteserver.biz/trace2.tar.gz > > > The traces show that the periods of latency correspond to floods of broadcast packets on the network > 10 29895 14:53:25 > 9 29895 14:53:26 > 9 29895 14:53:27 > 9 29895 14:53:28 > 16 29895 14:53:29 > 19 29895 14:53:30 > 19 29895 14:53:31 > 14 29895 14:53:32 > 13 29895 14:53:33 > 12 29895 14:53:34 > 205 29895 14:53:35 > 203 29895 14:53:36 > 276 29895 14:53:37 > 234 29895 14:53:38 > 234 29895 14:53:39 > 243 29895 14:53:40 > 234 29895 14:53:41 > 259 29895 14:53:42 > 228 29895 14:53:43 > 325 29895 14:53:44 > 242 29895 14:53:45 > 271 29895 14:53:46 > 251 29895 14:53:47 > 227 29895 14:53:48 > 178 29895 14:53:49 > 166 29895 14:53:50 > 271 29895 14:53:51 > 244 29895 14:53:52 > 287 29895 14:53:53 > 196 29895 14:53:54 > 215 29895 14:53:55 > 83 29895 14:53:56 > 65 29895 14:53:57 > 10 29895 14:53:58 > 9 29895 14:53:59 > 10 29895 14:54:00 > 14 29895 14:54:01 > 14 29895 14:54:02 > 12 29895 14:54:03 > 13 29895 14:54:04 > 16 29895 14:54:05 The first column is the number of packets delivered at the time in the third column. The broadcast packets are clearly visible in the trace as having \xff in the first 6 bytes of the packet. The ping packet is getting queued behind the broadcasts and thus delayed. However, kvm is capable of much more than 200 packets/sec. I get about 6500 here with a flood ping. Can you try this on the host: ping -f -q guest-ip Hit ctrl-C after a second or two and send the output. You can also try running wireshark on the host to capture the broadcast packets. Maybe they cause some processing on the guest and slow it down. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <4756CA29.5030501-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <4756CA29.5030501-atKUWr5tajBWk0Htik3J/w@public.gmane.org> @ 2007-12-05 17:21 ` Mike [not found] ` <4756DE36.2020502-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> 0 siblings, 1 reply; 29+ messages in thread From: Mike @ 2007-12-05 17:21 UTC (permalink / raw) To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Avi Kivity schrieb: > Mike wrote: >> Sure, >> here the ping results from the host to the guest atm of the peaks: >> 64 bytes from postfix (195.24.77.173): icmp_seq=347 ttl=64 time=10.6 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=348 ttl=64 time=11.6 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=349 ttl=64 time=11.6 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=350 ttl=64 time=465 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=351 ttl=64 time=455 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=352 ttl=64 time=349 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=353 ttl=64 time=314 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=354 ttl=64 time=483 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=355 ttl=64 time=871 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=357 ttl=64 time=1889 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=358 ttl=64 time=1635 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=359 ttl=64 time=1973 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=360 ttl=64 time=1796 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=361 ttl=64 time=1961 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=362 ttl=64 time=2029 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=363 ttl=64 time=1994 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=364 ttl=64 time=1689 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=365 ttl=64 time=932 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=366 ttl=64 time=899 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=367 ttl=64 time=752 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=368 ttl=64 time=860 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=369 ttl=64 time=483 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=370 ttl=64 time=244 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=371 ttl=64 time=7.89 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=372 ttl=64 time=5.98 ms >> 64 bytes from postfix (195.24.77.173): icmp_seq=373 ttl=64 time=6.31 ms >> >> The peaks started @ +/- 14:53:39 and ended @ +/- 14:53:59 >> You can download the trace file at: >> http://www.eliteserver.biz/trace2.tar.gz >> >> >> > > The traces show that the periods of latency correspond to floods of > broadcast packets on the network > >> 10 29895 14:53:25 >> 9 29895 14:53:26 >> 9 29895 14:53:27 >> 9 29895 14:53:28 >> 16 29895 14:53:29 >> 19 29895 14:53:30 >> 19 29895 14:53:31 >> 14 29895 14:53:32 >> 13 29895 14:53:33 >> 12 29895 14:53:34 >> 205 29895 14:53:35 >> 203 29895 14:53:36 >> 276 29895 14:53:37 >> 234 29895 14:53:38 >> 234 29895 14:53:39 >> 243 29895 14:53:40 >> 234 29895 14:53:41 >> 259 29895 14:53:42 >> 228 29895 14:53:43 >> 325 29895 14:53:44 >> 242 29895 14:53:45 >> 271 29895 14:53:46 >> 251 29895 14:53:47 >> 227 29895 14:53:48 >> 178 29895 14:53:49 >> 166 29895 14:53:50 >> 271 29895 14:53:51 >> 244 29895 14:53:52 >> 287 29895 14:53:53 >> 196 29895 14:53:54 >> 215 29895 14:53:55 >> 83 29895 14:53:56 >> 65 29895 14:53:57 >> 10 29895 14:53:58 >> 9 29895 14:53:59 >> 10 29895 14:54:00 >> 14 29895 14:54:01 >> 14 29895 14:54:02 >> 12 29895 14:54:03 >> 13 29895 14:54:04 >> 16 29895 14:54:05 > > The first column is the number of packets delivered at the time in the > third column. The broadcast packets are clearly visible in the trace > as having \xff in the first 6 bytes of the packet. The ping packet is > getting queued behind the broadcasts and thus delayed. > > However, kvm is capable of much more than 200 packets/sec. I get > about 6500 here with a flood ping. Can you try this on the host: > > ping -f -q guest-ip > > Hit ctrl-C after a second or two and send the output. > > You can also try running wireshark on the host to capture the > broadcast packets. Maybe they cause some processing on the guest and > slow it down. > 9066 packets transmitted, 9055 received, 0% packet loss, time 1956ms rtt min/avg/max/mdev = 0.078/0.171/16.659/0.181 ms, pipe 2, ipg/ewma 0.215/0.213 ms The same time a tried a ping over the internet. No peaks. I also tried over a longer time, no peaks. ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <4756DE36.2020502-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <4756DE36.2020502-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org> @ 2007-12-05 18:05 ` Simon Gao [not found] ` <4756E86B.8050402-g4dUTk+gKbW4mfPA/iJWtA@public.gmane.org> 0 siblings, 1 reply; 29+ messages in thread From: Simon Gao @ 2007-12-05 18:05 UTC (permalink / raw) To: Mike; +Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Mike wrote: > Avi Kivity schrieb: > >> Mike wrote: >> >>> Sure, >>> here the ping results from the host to the guest atm of the peaks: >>> 64 bytes from postfix (195.24.77.173): icmp_seq=347 ttl=64 time=10.6 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=348 ttl=64 time=11.6 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=349 ttl=64 time=11.6 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=350 ttl=64 time=465 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=351 ttl=64 time=455 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=352 ttl=64 time=349 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=353 ttl=64 time=314 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=354 ttl=64 time=483 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=355 ttl=64 time=871 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=357 ttl=64 time=1889 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=358 ttl=64 time=1635 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=359 ttl=64 time=1973 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=360 ttl=64 time=1796 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=361 ttl=64 time=1961 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=362 ttl=64 time=2029 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=363 ttl=64 time=1994 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=364 ttl=64 time=1689 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=365 ttl=64 time=932 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=366 ttl=64 time=899 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=367 ttl=64 time=752 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=368 ttl=64 time=860 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=369 ttl=64 time=483 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=370 ttl=64 time=244 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=371 ttl=64 time=7.89 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=372 ttl=64 time=5.98 ms >>> 64 bytes from postfix (195.24.77.173): icmp_seq=373 ttl=64 time=6.31 ms >>> >>> The peaks started @ +/- 14:53:39 and ended @ +/- 14:53:59 >>> You can download the trace file at: >>> http://www.eliteserver.biz/trace2.tar.gz >>> >>> >>> >>> >> The traces show that the periods of latency correspond to floods of >> broadcast packets on the network >> >> >>> 10 29895 14:53:25 >>> 9 29895 14:53:26 >>> 9 29895 14:53:27 >>> 9 29895 14:53:28 >>> 16 29895 14:53:29 >>> 19 29895 14:53:30 >>> 19 29895 14:53:31 >>> 14 29895 14:53:32 >>> 13 29895 14:53:33 >>> 12 29895 14:53:34 >>> 205 29895 14:53:35 >>> 203 29895 14:53:36 >>> 276 29895 14:53:37 >>> 234 29895 14:53:38 >>> 234 29895 14:53:39 >>> 243 29895 14:53:40 >>> 234 29895 14:53:41 >>> 259 29895 14:53:42 >>> 228 29895 14:53:43 >>> 325 29895 14:53:44 >>> 242 29895 14:53:45 >>> 271 29895 14:53:46 >>> 251 29895 14:53:47 >>> 227 29895 14:53:48 >>> 178 29895 14:53:49 >>> 166 29895 14:53:50 >>> 271 29895 14:53:51 >>> 244 29895 14:53:52 >>> 287 29895 14:53:53 >>> 196 29895 14:53:54 >>> 215 29895 14:53:55 >>> 83 29895 14:53:56 >>> 65 29895 14:53:57 >>> 10 29895 14:53:58 >>> 9 29895 14:53:59 >>> 10 29895 14:54:00 >>> 14 29895 14:54:01 >>> 14 29895 14:54:02 >>> 12 29895 14:54:03 >>> 13 29895 14:54:04 >>> 16 29895 14:54:05 >>> >> The first column is the number of packets delivered at the time in the >> third column. The broadcast packets are clearly visible in the trace >> as having \xff in the first 6 bytes of the packet. The ping packet is >> getting queued behind the broadcasts and thus delayed. >> >> However, kvm is capable of much more than 200 packets/sec. I get >> about 6500 here with a flood ping. Can you try this on the host: >> >> ping -f -q guest-ip >> >> Hit ctrl-C after a second or two and send the output. >> >> You can also try running wireshark on the host to capture the >> broadcast packets. Maybe they cause some processing on the guest and >> slow it down. >> >> > 9066 packets transmitted, 9055 received, 0% packet loss, time 1956ms > rtt min/avg/max/mdev = 0.078/0.171/16.659/0.181 ms, pipe 2, ipg/ewma > 0.215/0.213 ms > > The same time a tried a ping over the internet. No peaks. > > I also tried over a longer time, no peaks. > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > kvm-devel mailing list > kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/kvm-devel > I also saw the similar problem. However, it happens with I have several KVM guests running and sharing the same network bridge. If just one single KVM guest, then everything works fine. Simon ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <4756E86B.8050402-g4dUTk+gKbW4mfPA/iJWtA@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <4756E86B.8050402-g4dUTk+gKbW4mfPA/iJWtA@public.gmane.org> @ 2007-12-05 19:49 ` Lynn Kerby 0 siblings, 0 replies; 29+ messages in thread From: Lynn Kerby @ 2007-12-05 19:49 UTC (permalink / raw) To: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Dec 5, 2007, at 10:05 AM, Simon Gao wrote: > I also saw the similar problem. However, it happens with I have > several > KVM guests running and sharing the same network bridge. If just one > single KVM guest, then everything works fine. > > Simon I think I've been through similar problems as well. Initially my guests would experience massive packet losses and huge delays somtime shortly after the second guest started. Often the first guest continued to operate fairly well, but it was noticably degraded. That is when I switched from the default QEMU ne2k device to the rtl8139 for all my virtual network taps. A bunch of debugging eventually led me to check the mac addresses of all my guests on the bridge. Not the host side TAP address, but the guest's mac address. In my environment I found cases where more than one of the guests on the bridge had the same mac address and rewrote my startup scripts and configs to always assign a unique mac address to each network device. I thought perhaps this may be related to something in KVM-55, but I've just shutdown and restarted my VMs on the KVM-55 modules and userspace and am not seeing any network problems with my VMs. Here are the kvm/qemu command lines for 3 of my machines: (2 FreeBSD-6.2 servers and a Ubuntu-7.10 server) > /usr/local/bin/qemu-system-x86_64 -name FreeBSD_6.2 -hda /vm_img/ > bsd_dz1/disk0.qcow -m 256 -boot c -smp 1 -usb -usbdevice tablet - > vnc :0 -serial telnet::4100,server,nowait -monitor telnet:: > 4200,server,nowait -net > nic,vlan=0,macaddr=52:54:00:12:34:56,model=rtl8139 -net > tap,vlan=0,ifname=tap0,script=/etc/kvm/kvm-ifup -net > nic,vlan=1,model=rtl8139 -net tap,vlan=1,ifname=dmz0,script=/etc/ > kvm/kvm-ifup > /usr/local/bin/qemu-system-x86_64 -name DOM9-BSD62 -hda /vm_img/ > bsd_in1/dom9-disk1.qcow -hdb /vm_img/bsd_in1/dom9-disk2.raw -m 512 - > boot c -smp 2 -usb -usbdevice tablet -vnc :9 -serial telnet:: > 4109,server,nowait -monitor telnet::4209,server,nowait -net > nic,vlan=0,macaddr=52:54:09:12:34:56,model=rtl8139 -net > tap,vlan=0,ifname=tap1,script=/etc/kvm/kvm-ifup > /usr/local/bin/qemu-system-x86_64 -name DOMT2-UbuSrv7.10 -hda /dev/ > vg_r5/dom_t2 -m 512 -boot c -smp 1 -vnc :8 -serial telnet:: > 4108,server,nowait -monitor telnet::4208,server,nowait -net > nic,vlan=0,macaddr=52:54:08:12:34:56,model=rtl8139 -net > tap,vlan=0,ifname=tap2,script=/etc/kvm/kvm-ifup The kvm-ifup script referenced in these commands is very similar to the standard qemu-ifup except that it deals with multiple bridges, based on the interface name. It may be worth noting that I'm not explicitly assigning a mac address to interface dmz0 in the first example, but other interfaces on that network all have unique mac addresses so it isn't critical. You might want to examine the output of 'brctl showmacs br0' (use your bridge name in place of br0) and also check the interface stats on the bridge and any troublesome tap interfaces. Lynn Kerby San Martin, CA ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Strange network behaviour [not found] ` <47567D6D.8060802-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 2007-12-05 10:39 ` Mike @ 2007-12-05 10:55 ` Pelle [not found] ` <475683A6.5050900-5JapdU7xTciEVqv0pETR8A@public.gmane.org> 1 sibling, 1 reply; 29+ messages in thread From: Pelle @ 2007-12-05 10:55 UTC (permalink / raw) To: Avi Kivity; +Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Mike Hi, Is there a fast and simple way to tell the version of the binary? I think I remember something about that on this mailing list, but I can't find it in 'qemu-system-x86_64 -h' Avi Kivity wrote: > Mike wrote: > >> Now I noticed a strange behaviour. >> I have a gameserver running in a guest os. No problems on performance >> side, really fast. >> The only thing, when I make a ping test after unspecific time periods I >> get this: (this peaks are even there if the gameserver isn't running) >> >> >> As you can see, no peaks. >> Example of start command from a guest: >> kvm -hda apache.img -hdb apache_storage.img -m 512 -boot c -net >> nic,vlan=0,macaddr=00:16:3e:00:00:01,model=rtl8139 -net tap -nographic >> -daemonize >> >> Here the pings from the guest started with the command line listed above: >> >> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=37ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=97ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=60ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=186ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=363ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=368ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=972ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=673ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=1133ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=1198ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=1881ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=2341ms TTL=57 >> Reply from 195.24.77.171: bytes=32 time=2401ms TTL=57 >> >> > > What guest are you running? > > 'kvm' isn't the name of the binary generated by make. Are you sure it > is actually the binary from kvm-55? > > ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <475683A6.5050900-5JapdU7xTciEVqv0pETR8A@public.gmane.org>]
* Re: Strange network behaviour [not found] ` <475683A6.5050900-5JapdU7xTciEVqv0pETR8A@public.gmane.org> @ 2007-12-05 12:39 ` Avi Kivity 0 siblings, 0 replies; 29+ messages in thread From: Avi Kivity @ 2007-12-05 12:39 UTC (permalink / raw) To: Pelle; +Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Mike Pelle wrote: > Hi, > > Is there a fast and simple way to tell the version of the binary? > I think I remember something about that on this mailing list, but I > can't find it in 'qemu-system-x86_64 -h' Right now, only the kernel module (see dmesg). kvm-56's qemu will also report its version number. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2007-12-05 19:49 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-02 15:30 Strange Network behaviour Hermann Gottschalk
2004-07-04 16:46 ` bert hubert
2004-07-14 8:00 ` Hermann Gottschalk
2004-07-14 9:02 ` Roger Luethi
2004-07-14 10:28 ` Hermann Gottschalk
2004-07-14 10:33 ` Roger Luethi
2004-07-14 10:40 ` Hermann Gottschalk
2004-07-14 10:48 ` Roger Luethi
[not found] ` <20040714105546.GA12380@ostc.de>
[not found] ` <20040714110348.GA6393@k3.hellgate.ch>
2004-07-14 12:51 ` Hermann Gottschalk
2004-07-14 16:13 ` Gene Heskett
-- strict thread matches above, loose matches on Subject: below --
2007-12-04 22:44 Strange network behaviour Mike
[not found] ` <4755D859.4090805-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>
2007-12-05 7:53 ` Lynn Kerby
[not found] ` <52FC3F66-4055-4C6C-9920-8FE4C6BD2CCA-br2HoPxSX4msTnJN9+BGXg@public.gmane.org>
2007-12-05 9:06 ` Mike
[not found] ` <47566A0B.8040105-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>
2007-12-05 9:17 ` Dor Laor
[not found] ` <47566CB2.9060706-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-12-05 9:42 ` Mike
2007-12-05 9:46 ` Izik Eidus
2007-12-05 10:29 ` Avi Kivity
[not found] ` <47567D6D.8060802-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-12-05 10:39 ` Mike
[not found] ` <47567FC7.9040106-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>
2007-12-05 10:43 ` Avi Kivity
[not found] ` <475680E8.4060508-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-12-05 11:22 ` Mike
[not found] ` <475689E0.5020901-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>
2007-12-05 11:46 ` Uri Lublin
2007-12-05 13:18 ` Avi Kivity
[not found] ` <4756A538.1050303-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-12-05 14:13 ` Mike
[not found] ` <4756B1F6.5080102-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>
2007-12-05 15:56 ` Avi Kivity
[not found] ` <4756CA29.5030501-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-12-05 17:21 ` Mike
[not found] ` <4756DE36.2020502-kcIQ9yavhvsV/sYkb9DZNQ@public.gmane.org>
2007-12-05 18:05 ` Simon Gao
[not found] ` <4756E86B.8050402-g4dUTk+gKbW4mfPA/iJWtA@public.gmane.org>
2007-12-05 19:49 ` Lynn Kerby
2007-12-05 10:55 ` Pelle
[not found] ` <475683A6.5050900-5JapdU7xTciEVqv0pETR8A@public.gmane.org>
2007-12-05 12:39 ` Avi Kivity
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.