Re: UFS corruption panic
Am 15.01.2012 um 05:20 schrieb Joe Holden: > Guys > > Is a panic **really** appropriate for a filesystem that isn't even in > fstab? > > ie; > panic: ufs_dirbad: /mnt: bad dir ino 3229 at offset 0: mangled entry > > Which happened to be an file-backed md volume that got changed as I forgot > to unmount it beforehand, however as a result there is now inconsistencies > and probably data corruption or even missing data on other important > filesystems (ie; /, /var etc) because there wasn't even a sync or any kind > of other sensible behaviour. Yes, a panic is the correct action here. While I agree that it's super annoying, the filesystem notices that something is *really* wrong. Instead of letting the problem fester and continue to corrupt data, it stops the system. Most filesystems work under the assumption that they're the sole owner of the disk. This means that any changes to the on-disk data must come from filesystem code itself; if that data is inconstistent, it must be a bug in the filesystem code. At this point, panic is the only course of action to avoid even greater damage to the data. In other words: don't do that then :-) Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UFS corruption panic
On 15/01/2012, at 18:42, Stefan Bethke wrote: > Most filesystems work under the assumption that they're the sole owner of the > disk. This means that any changes to the on-disk data must come from > filesystem code itself; if that data is inconstistent, it must be a bug in > the filesystem code. At this point, panic is the only course of action to > avoid even greater damage to the data. > > In other words: don't do that then :-) OP didn't do anything silly, it really is a bug from the user POV. From the kernel programmer POV it might not be, and certainly wasn't. Times change though, every disk media is hot swappable these days, and in any case assumptions change. That said, changing all those code paths which panic because of corruption to instead re-mount read only (or similar) is a decidedly non trivial task :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UFS corruption panic
On 15/01/2012 08:12, Stefan Bethke wrote: Yes, a panic is the correct action here. While I agree that it's super annoying, the filesystem notices that something is *really* wrong. Instead of letting the problem fester and continue to corrupt data, it stops the system. One could argue instead that for non-root filesystems the correct action is to stop all operations on that filesystem but let the rest of the system continue. -- Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UFS corruption panic
Actually, that would be a safe assumption especially now that the installer rightly or wrongly defaults to a single / filesystem, but perhaps if it could be tunable via mount flags that would be sensible also... Thanks, J On Sun, Jan 15, 2012 at 12:48 PM, Bruce Cran wrote: > > On 15/01/2012 08:12, Stefan Bethke wrote: >> >> Yes, a panic is the correct action here. While I agree that it's super >> annoying, the filesystem notices that something is *really* wrong. Instead >> of letting the problem fester and continue to corrupt data, it stops the >> system. > > > One could argue instead that for non-root filesystems the correct action is > to stop all operations on that filesystem but let the rest of the system > continue. > > -- > Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Can't boot 9.0-RELEASE on sparc64
Hi, I'm trying to boot 9.0-RELEASE on sparc64, but I'm getting stuck at: panic: kmem_suballoc: bad status return of 3 cpuid = 0 KDB: stack backtrace: #0 0xc079841c at ??+0 #1 0xc04ca59c at ??+0 #2 0xc0487f90 at ??+0 #3 0xc0098028 at ??+0 I'm not able to break into the kernel debugger from there. This is a SunBlade 1500 with 2GB of RAM, booting from cdrom. The same machine boots 8.2-RELEASE from disk without any problems. boot -v of 8.2 yields: Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RELEASE #0: Thu Feb 17 06:57:44 UTC 2011 r...@araz.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64 Preloaded elf kernel "/boot/GENERIC/kernel" at 0xc0b9c000. real memory = 2147483648 (2048 MB) avail memory = 2079563776 (1983 MB) machine: SUNW,Sun-Blade-1500-S cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) mask=0x34 maxtl=5 maxwin=7 wlan: <802.11 Link Layer> firmware: 'isp_1000' version 1: 20142 bytes loaded at 0xc0725d38 ispfw: registered firmware firmware: 'isp_1040' version 1: 22944 bytes loaded at 0xc072abe6 ispfw: registered firmware firmware: 'isp_1040_it' version 1: 32942 bytes loaded at 0xc0730586 ispfw: registered firmware firmware: 'isp_1080' version 1: 31350 bytes loaded at 0xc0738634 ispfw: registered firmware firmware: 'isp_1080_it' version 1: 40644 bytes loaded at 0xc07400aa ispfw: registered firmware firmware: 'isp_12160' version 1: 28050 bytes loaded at 0xc0749f6e ispfw: registered firmware firmware: 'isp_12160_it' version 1: 40604 bytes loaded at 0xc0750d00 ispfw: registered firmware firmware: 'isp_2100' version 1: 76770 bytes loaded at 0xc075ab9c ispfw: registered firmware firmware: 'isp_2200' version 1: 77214 bytes loaded at 0xc076d77e ispfw: registered firmware firmware: 'isp_2300' version 1: 106640 bytes loaded at 0xc078051c ispfw: registered firmware firmware: 'isp_2322' version 1: 108856 bytes loaded at 0xc079a5ac ispfw: registered firmware firmware: 'isp_2400' version 1: 177416 bytes loaded at 0xc07b8164 ispfw: registered firmware firmware: 'isp_2400_multi' version 1: 193652 bytes loaded at 0xc07efe54 ispfw: registered firmware firmware: 'isp_2500' version 1: 140732 bytes loaded at 0xc082c140 ispfw: registered firmware firmware: 'isp_2500_multi' version 1: 164528 bytes loaded at 0xc085d0c4 ispfw: registered firmware null: random: nfslock: pseudo-device kbd0 at kbdmux0 openfirm: mem: nexus0: pcib0: mem 0x4000f60-0x4000f60afff,0x4000f41-0x4000f41701f,0x7fe-0x7fe00ff,0x4000f78-0x4000f78 irq 1970,1968,1969,1972,1953 on nexus0 pcib0: Tomatillo, version 4, IGN 0x1e, bus A, 33MHz Timecounter "pcib0" frequency 16700 Hz quality -100 pcib0: DVMA map: 0xc000 to 0xdfff 65536 entries pcib0: PROM IOTSB size: 1 (2048 entries) pcib0: adding PROM IOTSB slot 0 (kernel slot 63488) TTE: 0x80013fde0012 pcib0: adding PROM IOTSB slot 1 (kernel slot 63489) TTE: 0x80013fde2012 pcib0: adding PROM IOTSB slot 2 (kernel slot 63490) TTE: 0x80013fde4012 pcib0: adding PROM IOTSB slot 3 (kernel slot 63491) TTE: 0x80013fde6012 pcib0: adding PROM IOTSB slot 4 (kernel slot 63492) TTE: 0x80013fde8012 pcib0: adding PROM IOTSB slot 5 (kernel slot 63493) TTE: 0x80013fdea012 pcib0: adding PROM IOTSB slot 6 (kernel slot 63494) TTE: 0x80013fdec012 pcib0: adding PROM IOTSB slot 7 (kernel slot 63495) TTE: 0x80013fdee012 pcib0: adding PROM IOTSB slot 8 (kernel slot 63496) TTE: 0x80013fdf0012 pcib0: adding PROM IOTSB slot 9 (kernel slot 63497) TTE: 0x80013fdf2012 pcib0: adding PROM IOTSB slot 10 (kernel slot 63498) TTE: 0x80013fdf4012 pcib0: adding PROM IOTSB slot 11 (kernel slot 63499) TTE: 0x80013fdf6012 pcib0: adding PROM IOTSB slot 12 (kernel slot 63500) TTE: 0x80013fdf8012 pcib0: adding PROM IOTSB slot 13 (kernel slot 63501) TTE: 0x80013fdfa012 pcib0: adding PROM IOTSB slot 14 (kernel slot 63502) TTE: 0x80013fdfc012 pcib0: adding PROM IOTSB slot 15 (kernel slot 63503) TTE: 0x80013fdfe012 pcib0: adding PROM IOTSB slot 16 (kernel slot 63504) TTE: 0x80013fe00012 pcib0: adding PROM IOTSB slot 17 (kernel slot 63505) TTE: 0x80013fe02012 pcib0: adding PROM IOTSB slot 18 (kernel slot 63506) TTE: 0x80013fe04012 pcib0: adding PROM IOTSB slot 19 (kernel slot 63507) TTE: 0x80013fe06012 pcib0: adding PROM IOTSB slot 20 (kernel slot 63508) TTE: 0x80013fe08012 pcib0: adding PROM IOTSB slot 21 (kernel slot 63509) TTE: 0x80013fe0a012 pcib0: adding PROM IOTSB slot 22 (kernel slot 63510) TTE: 0x80013fe0c012 pcib0: adding PROM IOTSB slot 23 (kernel slot 63511) TTE: 0x80013fe0e012 pcib0: adding PROM IOTSB slot 24 (kernel slot 63512) TTE: 0x80013fe10012 pcib0: adding PROM IOTSB slot 25 (kernel slot 63513) TTE: 0x80013fe12012 pcib0: adding PROM
Re: Can't boot 9.0-RELEASE on sparc64
On Sun, Jan 15, 2012 at 5:02 PM, C. P. Ghost wrote: > Hi, > > I'm trying to boot 9.0-RELEASE on sparc64, but I'm > getting stuck at: > > panic: kmem_suballoc: bad status return of 3 > cpuid = 0 > KDB: stack backtrace: > #0 0xc079841c at ??+0 > #1 0xc04ca59c at ??+0 > #2 0xc0487f90 at ??+0 > #3 0xc0098028 at ??+0 > > I'm not able to break into the kernel debugger from > there. > > This is a SunBlade 1500 with 2GB of RAM, booting > from cdrom. Just a little follow-up: If I set hw.physmem=1048576000 in the loader, 9.0 finally boots. What's going on? Are there some memory holes above 1G that 9.0 can't deal with (but 8.2 can)? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HPN-SSH question
- Original Message - From: "Bjoern A. Zeeb" To: "Steven Hartland" Cc: "ml-freebsd-stable Stable" Sent: Sunday, January 15, 2012 1:41 AM Subject: Re: HPN-SSH question On 14. Jan 2012, at 23:56 , Steven Hartland wrote: On a similar note I'm actually quite concerned by the inclusion of these patches by default in the OS version of ssh as we've seen several cases of it causing noticeable performance degradation instead of improvement. I've not tested on 9, but this was certainly the case on 8.2. 8.2 did not shipped them so you had installed them yourself? What kind of performance degradations and in which kind of environment an how "noticeable"? Yep we installed openssh-portable + HPN and experienced noticeably reduced transfer rates on high latency links, exactly the opposite as one would expect. I don't have the exact figures I'm afraid as we just went straight back to standard ssh. I'll try and get some time to retest and provide some proper results. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GENERIC make buildkernel error / fails - posix_fadvise
On Sat, 14 Jan 2012 23:37:50 -0800 Jeremy Chadwick wrote: > On Sun, Jan 15, 2012 at 02:24:41AM -0500, Rob Clark wrote: > > On Thu, 12 Jan 2012 08:15:50 -0500 > > John Baldwin wrote: > > > > > On Wednesday, January 11, 2012 4:11:10 pm Rob Clark wrote: > > > > System: Dell 600sc > > > > Currently running: 8.2-RELEASE > > > > > > > > In attempting to update this system to 8-STABLE I did > > > > what I usually do to update a system (see below). > > > > make buildworld completes successfully, but make > > > > buildkernel does not. I usually create a custom > > > > kernel, but for this system I went with GENERIC as > > > > is. > > > > > > > > The error message is: > > > > /usr/src/sys/kern/init_sysent.c:568: error: invalid > > > > application of 'sizeof' to incomplete type 'struct > > > > posix_fadvise_args' /usr/src/sys/kern/init_sysent.c:568: > > > > error: 'posix_fadvise' undeclared here (not in a > > > > function) *** Error code 1 > > > > > > This sounds like you have an incomplete tree that only got part of a > > > change > > > (specifically, /usr/src/sys/sys/sysproto.h seems stale). Have you tried > > > a > > > different cvsup mirror? > > > > > > -- > > > John Baldwin > > > > Sorry for the late follow-up, just got the system > > up and running yesterday. It appears that choosing a > > different mirror did the trick. > > Can you please disclose what cvsup mirror you were using? This kind of > problem may be affecting other people, so you may want to report it to > freebsd-h...@freebsd.org to make the maintainer of the mirror aware. > > Otherwise, ""corruption"" (for lack of better term) between what's in > /var/db/sup and what's on your filesystem is something I've seen before, > particularly when changing release tags in a supfile. > > | Jeremy Chadwick j...@parodius.com | Absolutely, the mirror initially used when I received the error (see above) during "buildkernel" was: cvsup17.FreeBSD.org Using cvsup11.FreeBSD.org I had no issues. Of course, I am not saying that cvsup17 was at fault here, just that buildkernel worked following a csup with cvsup11 (in my case anyway). -- Rob Clark cc: freebsd-h...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Random 'Connection reset' issues between jails on same host
Hi all, We're trying to implement our puppet infrastructure, and have discovered something strange about TCP connections between jails on the same host. As our jails haven't generally been doing a lot of connections between each other, this issue hasn't popped up before. We have two 100% equal host systems, on FreeBSD 8.2-RELEASE-p4. These are 8-core Intel systems, with 16GB RAM each. I have just upgraded one of the two systems to 9.0-RELEASE, and it shows the same problem. When the puppetmaster jail is running on the same host as the jail running puppet agent, connections from the puppet agent randomly fails with 'Connection reset by peer'. This happens at random stages of configuration sync. Now if either of the jails are moved to another system (jail stop, zfs snaphot, zfs send/recv, jail start) on the same physical network, there are no such problems. It is not a hardware issue, as this happens no matter which of the two hosts we use. If both puppetmaster and puppet agent reside on the same physical box, the errors will show up. There used to be a somewhat similar problem with FTP between jails on the same host, but this was taken care of some time after 8.0-RELEASE IIRC. That problem manifested itself in a combination of random connection failures (had to try 2-3 times to establish a connection) and very slow transfer rates (at most 150kbyte/s between jails on the same host, but >50mbyte/s between jails on different hosts on the same network). Has anyone seen this before? Is there anything I have missed, sysctls I should set/adjust? The /etc/rc.conf settings for the jails are very simple - the following differing from the default: jail_sysvipc_allow="YES" jail_mount_enable="YES" jail_devfs_enable="YES" /etc/sysctl.conf contains the following jail-related: security.jail.enforce_statfs=0 security.jail.mount_allowed=1 security.jail.allow_raw_sockets=1 Thanks, /Eirik___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Random 'Connection reset' issues between jails on same host
On Jan 15, 2012, at 18:44, Eirik Øverby wrote: > Hi all, > > We're trying to implement our puppet infrastructure, and have discovered > something strange about TCP connections between jails on the same host. As > our jails haven't generally been doing a lot of connections between each > other, this issue hasn't popped up before. > > We have two 100% equal host systems, on FreeBSD 8.2-RELEASE-p4. These are > 8-core Intel systems, with 16GB RAM each. I have just upgraded one of the two > systems to 9.0-RELEASE, and it shows the same problem. > > When the puppetmaster jail is running on the same host as the jail running > puppet agent, connections from the puppet agent randomly fails with > 'Connection reset by peer'. This happens at random stages of configuration > sync. Now if either of the jails are moved to another system (jail stop, zfs > snaphot, zfs send/recv, jail start) on the same physical network, there are > no such problems. It is not a hardware issue, as this happens no matter which > of the two hosts we use. If both puppetmaster and puppet agent reside on the > same physical box, the errors will show up. Replying to myself here: Assignig a cpuset with a single CPU to the jail with puppetmaster seems to cure the symptom. I've made a few thousand connects now and no failures so far. Repeatable on 8 and 9. This is obviously only a workaround - but may give some hints as to where the problem is. /Eirik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Random 'Connection reset' issues between jails on same host
Hi all, We're trying to implement our puppet infrastructure, and have discovered something strange about TCP connections between jails on the same host. As our jails haven't generally been doing a lot of connections between each other, this issue hasn't popped up before. We have two 100% equal host systems, on FreeBSD 8.2-RELEASE-p4. These are 8-core Intel systems, with 16GB RAM each. When the puppetmaster jail is running on the same host as the jail running puppet agent, connections from the puppet agent randomly fails with 'Connection reset by peer'. This happens at random stages of configuration sync. Now if either of the jails are moved to another system (jail stop, zfs snaphot, zfs send/recv, jail start) on the same physical network, there are no such problems. It is not a hardware issue, as this happens no matter which of the two hosts we use. If both puppetmaster and puppet agent reside on the same physical box, the errors will show up. There used to be a somewhat similar problem with FTP between jails on the same host, but this was taken care of some time after 8.0-RELEASE IIRC. That problem manifested itself in a combination of random connection failures (had to try 2-3 times to establish a connection) and very slow transfer rates (at most 150kbyte/s between jails on the same host, but >50mbyte/s between jails on different hosts on the same network). I am going to try to repeat this on 9.0-RELEASE - but in the meantime, has anyone seen this before? Is there anything I have missed, sysctls I should set/adjust? The /etc/rc.conf settings for the jails are very simple - the following differing from the default: jail_sysvipc_allow="YES" jail_mount_enable="YES" jail_devfs_enable="YES" /etc/sysctl.conf contains the following jail-related: security.jail.enforce_statfs=0 security.jail.mount_allowed=1 security.jail.allow_raw_sockets=1 Thanks, /Eirik___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HPN-SSH question
On 15. Jan 2012, at 16:28 , Steven Hartland wrote: > Yep we installed openssh-portable + HPN and experienced noticeably > reduced transfer rates on high latency links, exactly the opposite > as one would expect. I don't have the exact figures I'm afraid as > we just went straight back to standard ssh. > > I'll try and get some time to retest and provide some proper > results. Thanks. If you do please try the bundled version in 8-STABLE or 9 and also gather the usual meta data (latency, packet loss, IPv4/v6, any socket buffer tuning, ...). /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
problem with sound in FreeBSD VBOX guest
I have a problem with sound in FreeBSD9 stable as a VBOX guest. The problem happens about 30-45 minutes after boot. While playing a stream from the web the sound will suddenly stop. I see the following in the log: Jan 15 16:36:06 BSD9 kernel: pcm0: chn_write(): pcm0:virtual:dsp0.vp0: play interrupt timeout, channel dead Jan 15 16:38:06 BSD9 kernel: pcm0: chn_write(): pcm0:virtual:dsp0.vp1: play interrupt timeout, channel dead I am using the hda driver in the FreeBSD guest, however I have tried others and they do not work any better. Below is relevant info from the VBOX host and the FreeBSD guest: VBOX HOST INFO (Opensuse 11.4 x86_64) VirtualBox ver. 4.1.8 -Version- Kernel : Linux 2.6.37.6-0.9-desktop (x86_64) Compiled: #1 SMP PREEMPT 2011-10-19 22:33:27 +0200 C Library : GNU C Library version 2.11.3 (20110203) (stable) Default C Compiler : GNU C Compiler version 4.5.1 20101208 [gcc-4_5-branch revision 167585] (SUSE Linux) Distribution: openSUSE 11.4 (x86_64) -Current Session- Desktop Environment : GNOME 2.32.1 -Display- Resolution : 1280x1024 pixels Vendor : The X.Org Foundation Version : 1.9.3 -Monitors- Monitor 0 : 1280x1024 pixels -Extensions- BIG-REQUESTS -OpenGL- Vendor : Advanced Micro Devices, Inc. Renderer: Mesa DRI R600 (RS880 9710) 20090101 TCL DRI2 Version : 2.1 Mesa 7.10.2 Direct Rendering: Yes -PCI Devices- Host bridge : Advanced Micro Devices [AMD] RS880 Host Bridge PCI bridge : Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge PCI bridge : Advanced Micro Devices [AMD] RS780 PCI to PCI bridge PCI bridge : Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge SATA controller : ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] USB Controller : ATI Technologies Inc SB700/SB800 USB OHCI0 Controller USB Controller : ATI Technologies Inc SB700 USB OHCI1 Controller USB Controller : ATI Technologies Inc SB700/SB800 USB EHCI Controller USB Controller : ATI Technologies Inc SB700/SB800 USB OHCI0 Controller USB Controller : ATI Technologies Inc SB700 USB OHCI1 Controller USB Controller : ATI Technologies Inc SB700/SB800 USB EHCI Controller SMBus : ATI Technologies Inc SBx00 SMBus Controller Audio device: ATI Technologies Inc SBx00 Azalia ISA bridge : ATI Technologies Inc SB700/SB800 LPC host controller PCI bridge : ATI Technologies Inc SBx00 PCI to PCI Bridge Host bridge : Advanced Micro Devices [AMD] Family 10h Processor HyperTransport Configuration Host bridge : Advanced Micro Devices [AMD] Family 10h Processor Address Map Host bridge : Advanced Micro Devices [AMD] Family 10h Processor DRAM Controller Host bridge : Advanced Micro Devices [AMD] Family 10h Processor Miscellaneous Control Host bridge : Advanced Micro Devices [AMD] Family 10h Processor Link Control VGA compatible controller : ATI Technologies Inc RS880 [Radeon HD 4200] Audio device : ATI Technologies Inc RS880 Audio Device [Radeon HD 4200] Network controller : RaLink Device 5390 Ethernet controller : Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller -I/O Ports- -0cf7 : PCI Bus :00 -001f: dma1 0020-0021: pic1 0040-0043: timer0 0050-0053: timer1 0060-0060: keyboard 0064-0064: keyboard 0070-0071: rtc0 0080-008f: dma page reg 00a0-00a1: pic2 00c0-00df: dma2 00f0-00ff: fpu 03c0-03df: vesafb 040b-040b: pnp 00:08 04d0-04d1: pnp 00:08 04d6-04d6: pnp 00:08 0800-089f: pnp 00:08 0800-0803 : ACPI PM1a_EVT_BLK 0804-0805 : ACPI PM1a_CNT_BLK 0808-080b : ACPI PM_TMR 0810-0815 : ACPI CPU throttle 0820-0827 : ACPI GPE0_BLK 0900-090f: pnp 00:08 0910-091f: pnp 00:08 0b00-0b0f: pnp 00:08 0b00-0b07 : piix4_smbus 0b20-0b3f: pnp 00:08 0c00-0c01: pnp 00:08 0c14-0c14: pnp 00:08 0c50-0c51: pnp 00:08 0c52-0c52: pnp 00:08 0c6c-0c6c: pnp 00:08 0c6f-0c6f: pnp 00:08 0cd0-0cd1: pnp 00:08 0cd2-0cd3: pnp 00:08 0cd4-0cd5: pnp 00:08 0cd6-0cd7: pnp 00:08 0cd8-0cdf: pnp 00:08 0cf8-0cff : PCI conf1 0d00- : PCI Bus :00 0e00-0e0f: pnp 00:09 0e80-0e8f: pnp 00:09 0f40-0f4f: pnp 0
Re: HPN-SSH question
On Sun, Jan 15, 2012 at 10:58 AM, Bjoern A. Zeeb < bzeeb-li...@lists.zabbadoz.net> wrote: > On 15. Jan 2012, at 16:28 , Steven Hartland wrote: > > > Yep we installed openssh-portable + HPN and experienced noticeably > > reduced transfer rates on high latency links, exactly the opposite > > as one would expect. I don't have the exact figures I'm afraid as > > we just went straight back to standard ssh. > > > > I'll try and get some time to retest and provide some proper > > results. > > Thanks. If you do please try the bundled version in 8-STABLE or 9 and > also gather the usual meta data (latency, packet loss, IPv4/v6, any > socket buffer tuning, ...). > And, if it happens with 9, any chance of a tcpdump capture of all of the headers for analysis? (No packet data needed.) We use the HPN version extensively on high latency links (often trans-oceanic) and have never seen that. I'd find running tcptrace and generating time plots very useful for looking at this sort of performance issue. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HPN-SSH question
On 16. Jan 2012, at 04:56 , Kevin Oberman wrote: > On Sun, Jan 15, 2012 at 10:58 AM, Bjoern A. Zeeb < > bzeeb-li...@lists.zabbadoz.net> wrote: > >> On 15. Jan 2012, at 16:28 , Steven Hartland wrote: >> >>> Yep we installed openssh-portable + HPN and experienced noticeably >>> reduced transfer rates on high latency links, exactly the opposite >>> as one would expect. I don't have the exact figures I'm afraid as >>> we just went straight back to standard ssh. >>> >>> I'll try and get some time to retest and provide some proper >>> results. >> >> Thanks. If you do please try the bundled version in 8-STABLE or 9 and >> also gather the usual meta data (latency, packet loss, IPv4/v6, any >> socket buffer tuning, ...). >> > > And, if it happens with 9, any chance of a tcpdump capture of all of the > headers for analysis? (No packet data needed.) We use the HPN version > extensively on high latency links (often trans-oceanic) and have never seen > that. I'd find running tcptrace and generating time plots very useful for > looking at this sort of performance issue. Or using siftr. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
