Re: Source upgrade from 5.5 to 6.X not safe?
In general, is it possible that the installkernel did /not/ complete correctly before I shut down? Is it ever possible that the machine could get put into an indeterminate state when doing installkernel on a running machine? HP-UX used to behave horribly when a binary got clobbered for a process that was running, but I have no idea how FreeBSD copes with changing disk images of a running process. If a binary/library that is currently used gets removed/replaced, it will be copied to memory. The process will not even recognize this. Only restarting the process will remove the old version from memory and cause the new one to be used. I thought every OS did it like that, so I'm surprised that there are systems causing problems in this case. For the kernel likewise. The kernel and the loaded modules remain in memory, but of course you cannot load the newly built modules until you have rebooted with the new kernel (because there's no other way to restart a kernel). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ok, so now what? Binary upgrade to 6.2-RELEASE fails
Clint Olsen wrote: On Nov 02, [LoN]Kamikaze wrote: I think you might have no choice but to omit the reboots, because the world contains lots of stuff that has to do with the kernel (like mounting). So just go into single user mode and do the usual stuff: # make installkernel # mergemaster -p # make installworld # mergemaster # shutdown -r now and pray to your deity of choice. If the reason for your problem is something else however you're stuck with a system that can not run with your old kernel. So better backup before you try. I attempted to just do a binary upgrade, assuming that I botched the source upgrade somehow. After installing FreeBSD 6.2-RELEASE, I was left with a system that would not boot (similar errors on boot as before). Reverting the kernel of course was of limited help because userland was all expecting 6.2. So, I had a couple of tarballs from my last backup and I attempted to bandage up / and /usr and was able to resurrect my 5.5-STABLE image. This is f'n scary. I've never had this much trouble upgrading a system before. Does anyone have any idea what remnant could be remaining after a binary upgrade that would keep it from booting yet I can boot from the 6.2-RELEASE iso's just fine? I am very apprehensive to do a newfs and wipe the drives now that I've failed both source and binary upgrade paths. -Clint That's strange, I've gone right from 5.3 through to RELENG_7 without ever doing the reboots during the install process (I know that's not recommended) and I never ran into trouble. Did you accidently turn off compat6x in the kernel before you built? Did your remember to install the misc/compat6x port? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ok, so now what? Binary upgrade to 6.2-RELEASE fails
On Nov 11, [LoN]Kamikaze wrote: That's strange, I've gone right from 5.3 through to RELENG_7 without ever doing the reboots during the install process (I know that's not recommended) and I never ran into trouble. Did you accidently turn off compat6x in the kernel before you built? Did your remember to install the misc/compat6x port? Well, I wasn't upgrading to RELENG_7, so compat6x shouldn't have been an issue. And any compatibility library should not have been necessary when doing a binary upgrade. I was trying to boot a GENERIC kernel in the upgrade process. My 5.5 kernel is only slightly customized as a superset of the original 5.X kernel. I don't have the misc/compat5x installed on my system. I don't remember seeing that in the upgrading section of the handbook, so I didn't do that. I can see this as being necessary for running certain legacy applications, but I should still be able to boot the kernel. Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ok, so now what? Binary upgrade to 6.2-RELEASE fails
Clint Olsen wrote: I attempted to just do a binary upgrade, assuming that I botched the source upgrade somehow. After installing FreeBSD 6.2-RELEASE, I was left with a system that would not boot (similar errors on boot as before). Any chance you could post some of these error messages? And if possible, backtraces, etc? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot-time pass for geli on 7.0-BETA2 (and RELENG_7) not working for me.
On Thu, Nov 08, 2007 at 05:09:34PM +0100, Thorsten Trampisch wrote: Hello, today I updated from 6.2-RELEASE-p8 to 7.0-BETA2 as well. I've ran into the same problem with the password input to GELI on boot time. Chars are showing up after several keypresses. After removing the new dcons driver from my KERNEL config, recompiling and rebooting, it does work normally like under 6.2R Thanks, I tried it, but alas, to no avail... Still the same symptoms. :-/ Marc pgpRfmEWdkDDo.pgp Description: PGP signature
Re: ZFS deadlock ?
Pawel Jakub Dawidek wrote: On Sat, Nov 10, 2007 at 12:39:27PM +0100, Henri Hennebert wrote: Pawel Jakub Dawidek wrote: On Fri, Nov 09, 2007 at 05:37:00PM +0100, Henri Hennebert wrote: hello To push zfs, I launch 2 scrub at the same time, after ~20 seconds the system freeze: [...] I found a deadlock too. If it's reproducable for you, can you try this patch: I reproduce it after 30 minutes, si I try you patch. http://people.freebsd.org/~pjd/patches/zgd_done.patch when I try to load zfs.ko I get: # kldload zfs link_elf: symbol kproc_create undefined kldload: can't load zfs: No such file or directory What must I add to my config to resolve this symbol / problem Ouch, you don't use HEAD. Try changing kproc_*() to kthread_*(). Today, after more than 10 scrubs, no deadlock. This patch is effective. Thanks Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 7.0 BETA 2 crashes when starts up with USB disk plugged in
Dear all, I encountered another crash when using FreeBSD 7.0 BETA 2. The following is the kgdb output: kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Unread portion of the kernel message buffer: Copyright (c) 1992-2007 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 7.0-BETA2 #6: Mon Nov 5 23:28:18 CST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MERCURY Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Hammer Family processor - Model Unknown (1750.01-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20fc2 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow! AMD Features2=0x1LAHF real memory = 1073676288 (1023 MB) avail memory = 1037295616 (989 MB) ACPI APIC Table: Nvidia AWRDACPI ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: Nvidia AWRDACPI on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3fef (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff,0xcf0-0xcf3 on acpi0 pci0: ACPI PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 pci0: serial bus, SMBus at device 1.1 (no driver attached) ohci0: OHCI (generic) USB controller mem 0xe5001000-0xe5001fff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 4 ports with 4 removable, self powered ohci1: OHCI (generic) USB controller mem 0xe5002000-0xe5002fff irq 22 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: OHCI (generic) USB controller on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 4 ports with 4 removable, self powered ehci0: NVIDIA nForce3 250 USB 2.0 controller mem 0xe5003000-0xe50030ff irq 23 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: NVIDIA nForce3 250 USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb2 uhub2: 8 ports with 8 removable, self powered uhub2: port 5 reset failed atapci0: nVidia nForce3 Pro UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 8.0 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] atapci1: nVidia nForce3 Pro SATA150 controller port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xc400-0xc40f,0xc800-0xc87f irq 21 at device 10.0 on pci0 atapci1: [ITHREAD] ata2: ATA channel 0 on atapci1 ata2: [ITHREAD] ata3: ATA channel 1 on atapci1 ata3: [ITHREAD] pcib1: ACPI PCI-PCI bridge at device 11.0 on pci0 pci1: ACPI PCI bus on pcib1 nvidia0: GeForce4 MX 4000 mem 0xe000-0xe0ff,0xd800-0xdfff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib2: ACPI PCI-PCI bridge at device 14.0 on pci0 pci2: ACPI PCI bus on pcib2 fxp0: Intel 82558 Pro/100 Ethernet port 0x9000-0x901f mem 0xe400-0xe4000fff,0xe300-0xe30f irq 17 at device 7.0 on pci2 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:00:4c:93:56:88 fxp0: [ITHREAD] pcm0: CMedia CMI8738 port 0x9400-0x94ff irq 19 at device 9.0 on pci2 pcm0: [ITHREAD] rl0: RealTek 8139 10/100BaseTX port 0x9800-0x98ff mem 0xe310-0xe31000ff irq 16 at device 13.0 on pci2 miibus1: MII bus on rl0 rlphy0: RealTek internal media interface PHY 0 on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:13:d3:3b:f1:02 rl0: [ITHREAD] fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
Please try the attached patch. I have committed this to head and it somehow slipped through the cracks in terms of an MFC (patch /etc/defaults/devfs.rules) On Thu, Nov 08, 2007 at 07:30:39PM +0200, Dan Epure wrote: I can provide more info on request. - Forwarded message from Dan Epure [EMAIL PROTECTED] - Date: Wed, 7 Nov 2007 19:25:08 +0200 From: Dan Epure [EMAIL PROTECTED] To: Tom Evans [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: openpty() and jail in RELENG_7 Thank you for your answer. This is not Xin Li's scenario. Description: the host of the jail - H (192.168.168.2/24) the jail running on H - J (192.168.168.254/32) the testing system - T (192.168.168.253/24) 1. I start the ssh daemon on H: === cut here === H# /usr/sbin/sshd -d debug1: sshd version OpenSSH_4.5p1 FreeBSD-20061110 debug1: read PEM private key done: type DSA debug1: private host key: #0 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on 192.168.168.2. Server listening on 192.168.168.2 port 22. === and here === 2. On T I run: === cut here === T# ssh 192.168.168.2 -l test2 === and here === 3. On H I see: === cut here === Debug1: fd 4 clearing O_NONBLOCK Debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 debug1: res_init() Connection from 192.168.168.253 port 60155 debug1: Client protocol version 2.0; client software version OpenSSH_4.6p1 Debian-5 debug1: match: OpenSSH_4.6p1 Debian-5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client-server aes128-cbc hmac-md5 none debug1: kex: server-client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user test2 service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for test2 debug1: userauth-request for user test2 service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: PAM: setting PAM_RHOST to 192.168.168.253 debug1: test whether pkalg/pkblob are acceptable debug1: trying public key file /home/test2/.ssh/authorized_keys debug1: trying public key file /home/test2/.ssh/authorized_keys2 Failed publickey for test2 from 192.168.168.253 port 60155 ssh2 debug1: audit_event: unhandled event 6 debug1: userauth-request for user test2 service ssh-connection method keyboard-interactive debug1: attempt 2 failures 2 debug1: keyboard-interactive devs debug1: auth2_challenge: user=test2 devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called Accepted keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: monitor_child_preauth: test2 has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_new: init debug1: session_new: session 0 debug1: session_pty_req: session 0 alloc /dev/pts/3 debug1: Ignoring unsupported tty mode opcode 37 (0x25) debug1: Ignoring unsupported tty mode opcode 52 (0x34) debug1: Ignoring unsupported tty mode opcode 71 (0x47) debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: PAM: setting PAM_TTY to /dev/pts/3 debug1: Setting controlling tty using TIOCSCTTY. === and here === 4. On T I am logged in on H: === cut here === Password: H$ === and here === 5. I start the jail on H: === cut here === H#
Re: 7.0-BETA2: rpc.lockd fails to start
On Sun, 11 Nov 2007, Eugene Grosbein wrote: I've in /etc/rc.conf: nfs_server_enable=YES rpcbind_enable=YES rpc_lockd_enable=YES rpc.lockd depends on rpc.statd running, try enabling that also? I sort of thought someone had added something to force rpc.statd to be started if rpc.lockd is started, but apparently not. Robert N M Watson Computer Laboratory University of Cambridge At boot: Starting mountd. Starting nfsd. Starting lockd. Nov 11 02:56:25 daemon.err grosbein rpc.lockd: 100024 RPC: Program not registered And rpc.lockd exits. Kernel and world are built with IPv6 disabled, here is /etc/src.conf: WITHOUT_ATM= WITHOUT_AUDIT= WITHOUT_AUTHPF= WITHOUT_ZFS= WITHOUT_CDDL= WITHOUT_FORTRAN= WITHOUT_GCOV= WITHOUT_HTML= WITHOUT_I4B= WITHOUT_INET6= WITHOUT_IPFILTER= WITHOUT_IPX= WITHOUT_KERBEROS= WITHOUT_NIS= WITHOUT_PF= WITHOUT_PROFILE= Should I worry abouth non-functional rpc.lockd? Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.0-BETA2 Panic after ifconfig
On Fri, 9 Nov 2007, Alexandre Biancalana wrote: Yesterday I updated my system from BETA-1 to BETA2 and after that I'm getting the following panic after a simple ifconfig. If you run this from single-user mode, do you get the same result? What is the general network configuration of the system, and what sorts of services are running? Could you confirm that you aren't using any third party kernel modules or modules from ports, or that if you are, they've been update following the upgrade to matching source? Robert N M Watson Computer Laboratory University of Cambridge Follow the panic and trace # ifconfig bge0 10.5.0.253 netmask 255.255.0.0 panic: Bad list head 0xc444a0c4 first-prev != head KDB; enter: panic [thread pid 1142 tid 100108 ] Stopped at kdb_enter=0x32:leave dbbt Tracing pid 1142 tid 100108 td 0xc5c3f840 kdb_enter(c07499fd,c07c5760,c0730fca,e6fbeaec,6fbeaec,...) at kdb_enter+0x32 panic(c0730fca,c444a0c4,c074e9942,e6fbeb14,c057abc9,...) at panic+0xc5 in_ifinit(0,c567d3000,0,0,c0755e1a,...) at in_ifinit+0x15c in_control(c5cfe18c, 8040691a,c5c84e40,c448e800,c5c3f840,...) at in_control+0xa6a ifioctl(c5cfe18c,8040691a,c5c84e40,c5c3f840,c5c3f840,...) at ifioctl+0x3ce soo_ioctl(c47406c0,8040691a,c5c84e40,c5411800,c5c3f840,...) at soo-ioctl+0x3a4 kern_ioctl(c5c3f840,3,8040691a,c5c84e40,0,...) at kern_ioctl+0x243 ioctl(c5c3f840,e6fbecfc,c,c07722a1,c,...) at ioctl+0x134 syscall(e6fbed38) at syscall+0x2c4 Xint0x80_syscall() at Xint0x80_syscall+0x20 ---syscall (54, FreeBSD ELF32, ioctl), eip = 0x481670f3, esp = 0x bfbfe51c, ebp = 0xvfvfe548 I'm with the machine stopped at db prompt, I can send any other information needed to solve this... Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-BETA2 Available
Ken Smith wrote: The 7.0-BETA2 builds have completed and are on many of the FreeBSD mirror sites. If you want to update an existing machine using cvsup use RELENG_7 as the branch tag. Instructions on using FreeBSD Update to perform a binary upgrade from FreeBSD 6.x to 7.0-BETA2 will be provided via the freebsd-stable list when available. As promised, instructions on upgrading from FreeBSD 6.x to 7.0-BETA2 are now available: http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html Colin Percival FreeBSD Security Officer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
Hi. Kris Kennaway wrote: In the good case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the good and bad times, since it only provides counters and an average rate over the uptime of the system. Now I'm running 10-process lighttpd and the problem became no so big. I collected interrupt stats and it shows no relation beetween ionterrupts and slowdowns. Here is it: http://83.167.98.162/gprof/intr-graph/ Also I have similiar statistics on mutex profiling and it shows there's no problem in mutexes. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ I have no idea what else to check. I don't know what this graph is showing me :) When precisely is the system behaving poorly? Take a look at Disk Load % picture at http://83.167.98.162/gprof/intr-graph/ At ~ 17:00, 03:00-04:00, 13:00-14:00, 00:30-01:30, 11:00-13:00 it shows peaks of disk activity which really never happen. As I said in the beginning of the thread in this peak moments disk becomes slow and vmstat shows 100% disk load while performing 10 tps. Other grafs at this page shows that there's no relation to interrupts rate of amr or em device. You advised me to check it. When I was using single-process lighttpd the problem was much harder as you can see at http://83.167.98.162/gprof/graph/ . At first picture on this page you can see disk load peaks at 18:00 and 15:00 which leaded to decreasing network output because disk was too slow. Back in this thread we suspected UMA mutexes. In order to check it I collected mutex profiling stats and draw graphs over time and they also didn't show anything interesting. All mutex graphs were smooth while disk load peaks. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ With best regards, Alexey Popov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
I just used the patch and it is working. Thank you, Gepu On Sun, Nov 11, 2007 at 09:31:12AM -0600, Christian S.J. Peron wrote: Please try the attached patch. I have committed this to head and it somehow slipped through the cracks in terms of an MFC (patch /etc/defaults/devfs.rules) On Thu, Nov 08, 2007 at 07:30:39PM +0200, Dan Epure wrote: I can provide more info on request. - Forwarded message from Dan Epure [EMAIL PROTECTED] - Date: Wed, 7 Nov 2007 19:25:08 +0200 From: Dan Epure [EMAIL PROTECTED] To: Tom Evans [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: openpty() and jail in RELENG_7 Thank you for your answer. This is not Xin Li's scenario. Description: the host of the jail - H (192.168.168.2/24) the jail running on H - J (192.168.168.254/32) the testing system - T (192.168.168.253/24) 1. I start the ssh daemon on H: === cut here === H# /usr/sbin/sshd -d debug1: sshd version OpenSSH_4.5p1 FreeBSD-20061110 debug1: read PEM private key done: type DSA debug1: private host key: #0 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on 192.168.168.2. Server listening on 192.168.168.2 port 22. === and here === 2. On T I run: === cut here === T# ssh 192.168.168.2 -l test2 === and here === 3. On H I see: === cut here === Debug1: fd 4 clearing O_NONBLOCK Debug1: Server will not fork when running in debugging mode. debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 debug1: res_init() Connection from 192.168.168.253 port 60155 debug1: Client protocol version 2.0; client software version OpenSSH_4.6p1 Debian-5 debug1: match: OpenSSH_4.6p1 Debian-5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client-server aes128-cbc hmac-md5 none debug1: kex: server-client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user test2 service ssh-connection method none debug1: attempt 0 failures 0 debug1: PAM: initializing for test2 debug1: userauth-request for user test2 service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: PAM: setting PAM_RHOST to 192.168.168.253 debug1: test whether pkalg/pkblob are acceptable debug1: trying public key file /home/test2/.ssh/authorized_keys debug1: trying public key file /home/test2/.ssh/authorized_keys2 Failed publickey for test2 from 192.168.168.253 port 60155 ssh2 debug1: audit_event: unhandled event 6 debug1: userauth-request for user test2 service ssh-connection method keyboard-interactive debug1: attempt 2 failures 2 debug1: keyboard-interactive devs debug1: auth2_challenge: user=test2 devs= debug1: kbdint_alloc: devices 'pam' debug1: auth2_challenge_start: trying authentication method 'pam' Postponed keyboard-interactive for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: do_pam_account: called Accepted keyboard-interactive/pam for test2 from 192.168.168.253 port 60155 ssh2 debug1: monitor_child_preauth: test2 has been authenticated by privileged process debug1: PAM: reinitializing credentials debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_new: init debug1: session_new: session 0 debug1: session_pty_req: session 0 alloc /dev/pts/3 debug1: Ignoring unsupported tty mode opcode 37 (0x25) debug1: Ignoring unsupported tty mode opcode 52 (0x34) debug1: Ignoring unsupported tty mode opcode 71 (0x47) debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0
Re: Ok, so now what? Binary upgrade to 6.2-RELEASE fails
On Nov 11, Dimitry Andric wrote: Any chance you could post some of these error messages? And if possible, backtraces, etc? The messages amounted to page fault while in kernel mode or similar. The problem is the system attempts to reboot itself within 15 seconds. I know there is a way to postpone that, but how do I get more information from the crash other than the screen dump? I know in some crash instances it's possible to get a kernel image dump, but I've never seen this as far as I know. Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FBSD-7-B2 Freeze
I am experiencing fairly consistent system freezes which seem to coincide with using the ndis driver and nvidia driver at the same time. I had worst problems using the nvidia binary driver, but I did also experience a freeze one time with the xorg nv driver, which I am now using. Sometimes the wireless card works extremely slowly when I am using the nvidia driver. I have a Dell Latitude D800. I enclose dmesg. Any advice on how to either further diagnose, or fix the problem will be welcome. Copyright (c) 1992-2007 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 7.0-BETA2 #0: Sat Nov 10 12:48:18 CST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.70GHz (1698.56-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6d6 Stepping = 6 Features=0xafe9f9bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE Features2=0x180EST,TM2 real memory = 536535040 (511 MB) avail memory = 511066112 (487 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: DELL CPi R on motherboard acpi0: [ITHREAD] acpi0: reservation of 0, 9fc00 (3) failed acpi0: reservation of 10, 1fef (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 acpi_acad0: AC Adapter on acpi0 battery0: ACPI Control Method Battery on acpi0 battery1: ACPI Control Method Battery on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci_link1: BIOS IRQ 11 for 0.31.INTB is invalid pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display mem 0xfc00-0xfcff,0xd000-0xdfff irq 11 at device 0.0 on pci1 uhci0: Intel 82801DB (ICH4) USB controller USB-A port 0xbf80-0xbf9f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801DB (ICH4) USB controller USB-B port 0xbf40-0xbf5f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801DB (ICH4) USB controller USB-C port 0xbf20-0xbf3f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: Intel 82801DB/L/M (ICH4) USB 2.0 controller mem 0xf4fffc00-0xf4ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: Intel 82801DB/L/M (ICH4) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb3 uhub3: 6 ports with 6 removable, self powered pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci_link1: BIOS IRQ 11 for 2.3.INTA is invalid pci2: ACPI PCI bus on pcib2 pci0:2:0:0: bad VPD cksum, remain 14 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x3001 mem 0xfaff-0xfaff irq 11 at device 0.0 on pci2 miibus0: MII bus on bge0 brgphy0: BCM5705 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:0f:1f:21:d5:92 bge0: [ITHREAD] cbb0: TI7510 PCI-CardBus Bridge at device 1.0 on pci2 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb0: [ITHREAD] cbb1: TI7610 PCI-CardBus Bridge irq 11 at device 1.1 on pci2 cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 cbb1: [ITHREAD] fwohci0: 1394 Open Host Controller Interface mem 0xfafef800-0xfafe,0xfafe8000-0xfafebfff irq 11 at device 1.2 on pci2 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 48:4f:c0:00:36:a9:44:a1 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 4a:4f:c0:a9:44:a1
Re: Ok, so now what? Binary upgrade to 6.2-RELEASE fails
Quoting Clint Olsen [EMAIL PROTECTED]: On Nov 11, Dimitry Andric wrote: Any chance you could post some of these error messages? And if possible, backtraces, etc? The messages amounted to page fault while in kernel mode or similar. The problem is the system attempts to reboot itself within 15 seconds. I know there is a way to postpone that, but how do I get more information from the crash other than the screen dump? I know in some crash instances it's possible to get a kernel image dump, but I've never seen this as far as I know. It's as simple as making your swap slice available for dumping, and adding a line in your rc.conf file. Of course you'll need to lift the information of interest from the vmcore, for the dump to be of any value. :) Further reading/details can easily be obtained at the following links: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html It's really a simple process. Best wishes. --Chris Thanks, -Clint ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: I just used the patch and it is working. Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On 11/11/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: I just used the patch and it is working. Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. Unfortunately, this doesn't fix the problems with screen :( -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On Sun, Nov 11, 2007 at 10:17:31PM +0200, Vlad GALU wrote: On 11/11/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: I just used the patch and it is working. Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. Unfortunately, this doesn't fix the problems with screen :( Which? I can look into it. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On 11/12/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 10:17:31PM +0200, Vlad GALU wrote: On 11/11/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Sun, Nov 11, 2007 at 08:11:57PM +0200, Dan Epure wrote: I just used the patch and it is working. Good to hear. I have submitted the request to get this merged to RELENG_7. Thanks for the quick response. Unfortunately, this doesn't fix the problems with screen :( Which? I can look into it. This one: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038054.html Thanks! -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On Mon, Nov 12, 2007 at 01:14:14AM +0200, Vlad GALU wrote: [..] This one: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038054.html Thanks! Ah.. ok. At first glance this doesn't look like a problem. This is actually looks like a side effect of devices which support cloning. Even though a device has been closed, it's existence will persist within the devfs directory entries. devfs should garbage collect this when its required. But I will confirm. -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: openpty() and jail in RELENG_7]
On 11/12/07, Christian S.J. Peron [EMAIL PROTECTED] wrote: On Mon, Nov 12, 2007 at 01:14:14AM +0200, Vlad GALU wrote: [..] This one: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038054.html Thanks! Ah.. ok. At first glance this doesn't look like a problem. This is actually looks like a side effect of devices which support cloning. Even though a device has been closed, it's existence will persist within the devfs directory entries. devfs should garbage collect this when its required. But I will confirm. I tested by setting kern.pts.max to an appropriately small value, such as 20-30, then opening many ptys from within screen. Even after closing all of them and exiting screen, the cleanup wasn't done. Thanks once again for your attention! -- Christian S.J. Peron [EMAIL PROTECTED] FreeBSD Committer -- Mahnahmahnah! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amrd disk performance drop after running under high load
On Nov 11, 2007 7:26 PM, Alexey Popov [EMAIL PROTECTED] wrote: Hi. Kris Kennaway wrote: In the good case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the good and bad times, since it only provides counters and an average rate over the uptime of the system. Now I'm running 10-process lighttpd and the problem became no so big. I collected interrupt stats and it shows no relation beetween ionterrupts and slowdowns. Here is it: http://83.167.98.162/gprof/intr-graph/ Also I have similiar statistics on mutex profiling and it shows there's no problem in mutexes. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ I have no idea what else to check. I don't know what this graph is showing me :) When precisely is the system behaving poorly? Take a look at Disk Load % picture at http://83.167.98.162/gprof/intr-graph/ At ~ 17:00, 03:00-04:00, 13:00-14:00, 00:30-01:30, 11:00-13:00 it shows peaks of disk activity which really never happen. As I said in the beginning of the thread in this peak moments disk becomes slow and vmstat shows 100% disk load while performing 10 tps. Other grafs at this page shows that there's no relation to interrupts rate of amr or em device. You advised me to check it. When I was using single-process lighttpd the problem was much harder as you can see at http://83.167.98.162/gprof/graph/ . At first picture on this page you can see disk load peaks at 18:00 and 15:00 which leaded to decreasing network output because disk was too slow. Back in this thread we suspected UMA mutexes. In order to check it I collected mutex profiling stats and draw graphs over time and they also didn't show anything interesting. All mutex graphs were smooth while disk load peaks. http://83.167.98.162/gprof/mtx-graph/mtxgifnew/ With best regards, Alexey Popov Hello, what is your RAID controller configuration (read ahead/cache/write policy)? I have seen weird/bogus numbers (~100% busy) reported by systat -v when read ahead was enabled on LSI/amr controllers. Regards, Panagiotis Christias ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 7.0-BETA2 Available
Thanks! Worked beautifully updating to 7.0-BETA2. The freebsd-update that was in my 7.0-Beta1.5 did not have the upgrade ability like I guess it should have, your script worked exactly as advertised though. -- Dario Perovich WebNX.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
