From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 00:08:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09AF916A407 for ; Sun, 12 Nov 2006 00:08:56 +0000 (UTC) (envelope-from kirk@strauser.com) Received: from kanga.honeypot.net (kanga.honeypot.net [208.162.254.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BD2C43D53 for ; Sun, 12 Nov 2006 00:08:55 +0000 (GMT) (envelope-from kirk@strauser.com) Received: from localhost (localhost [127.0.0.1]) by kanga.honeypot.net (Postfix) with ESMTP id EE8E82086C7 for ; Sat, 11 Nov 2006 18:08:54 -0600 (CST) X-Virus-Scanned: amavisd-new at honeypot.net Received: from kanga.honeypot.net ([127.0.0.1]) by localhost (kanga.honeypot.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC5aeo1xNBXU for ; Sat, 11 Nov 2006 18:08:51 -0600 (CST) Received: from kanga.honeypot.net (kanga.honeypot.net [IPv6:2001:470:1f01:224:1::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by kanga.honeypot.net (Postfix) with ESMTP id E2EE4208697 for ; Sat, 11 Nov 2006 18:08:50 -0600 (CST) From: Kirk Strauser To: freebsd-stable@freebsd.org Date: Sat, 11 Nov 2006 18:08:39 -0600 User-Agent: KMail/1.9.4 References: <6f50eac40611111312t43c792bdlb03af9a1435f9c4d@mail.gmail.com> In-Reply-To: <6f50eac40611111312t43c792bdlb03af9a1435f9c4d@mail.gmail.com> X-Face: &'; cS03F?rr_w2Qce.d2f7xmwXfcJWDs>}CkpDw.c]ZJJ_)i0Nx Subject: Re: nvidia-driver-1.0.8776 was giving me READ_DMA timeouts X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 00:08:56 -0000 --nextPart4601315.jI6ukqNF77 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 11 November 2006 15:12, Indigo 23 wrote: > I also had similar problems with the latest nvidia drivers on FreeBSD > 6.1-STABLE. My box used to run rock solid, then after the update to > .8776, it started locking up under heavy loads when X was running. > Any idea if this is a known bug in the drivers (i.e. nvidia is aware > of the problem)? Not a clue. I just figured it out and have been stress testing since then. =2D-=20 Kirk Strauser --nextPart4601315.jI6ukqNF77 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFVmYQ5sRg+Y0CpvERAgEOAJ4lxfGC5QIx8X/2gvRlJMBds1N0qACfUXbZ uoZvL74dC9k9HuXAMoKG6TE= =nVOy -----END PGP SIGNATURE----- --nextPart4601315.jI6ukqNF77-- From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 04:12:58 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E650116A407; Sun, 12 Nov 2006 04:12:58 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92A4543D60; Sun, 12 Nov 2006 04:12:58 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAC4CvxL001660; Sat, 11 Nov 2006 23:12:57 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAC4CuIB035746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Nov 2006 23:12:56 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611120412.kAC4CuIB035746@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 11 Nov 2006 23:13:05 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <455570D8.6070000@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 04:12:59 -0000 At 01:42 AM 11/11/2006, Scott Long wrote: driver. What will help me is if you can hook up a serial console to >your machine and see if it can be made to drop to the debugger while it >is under load and otherwise unresponsive. If you can, getting a process >dump might help confirm where each CPU is spending its time. ./netblast 192.168.88.218 500 110 1000 I compiled in the various debugging options and on the serial console I get a few Expensive timeout(9) function: 0xc0601e48(0) 0.024135749 s and the serial console telnet> send break Expensive timeout(9) function: 0xc0561444(0xc63f1d80) 0.072485748 s KDB: enter: Line break on console [thread pid 27 tid 100017 ] Stopped at kdb_enter+0x2b: nop db> db> ps pid ppid pgrp uid state wmesg wchan cmd 1206 1123 1206 0 R+ ifstat 1155 1154 1155 0 R+ csh 1154 1 1154 0 Ss+ wait 0xc6722218 login 1123 1122 1123 0 S+ pause 0xc6722894 csh 1122 1117 1122 1002 S+ wait 0xc6739430 su 1117 1116 1117 1002 Ss+ pause 0xc6aa024c csh 1116 1114 1114 1002 R sshd 1114 1028 1114 0 Ss sbwait 0xc6893370 sshd 1112 1 1112 0 Ss+ ttyin 0xc65ba810 getty 1111 1 1111 0 Ss+ ttyin 0xc65bac10 getty 1110 1 1110 0 Ss+ ttyin 0xc65bb010 getty 1109 1 1109 0 Ss+ ttyin 0xc65bc410 getty 1108 1 1108 0 Ss+ ttyin 0xc65b4010 getty 1107 1 1107 0 Ss+ ttyin 0xc65bd010 getty 1106 1 1106 0 Ss+ ttyin 0xc65bcc10 getty 1105 1 1105 0 Ss+ ttyin 0xc65b2010 getty 1044 1 1044 0 Ss nanslp 0xc076ecac cron 1038 1 1038 25 Ss pause 0xc6ab2aac sendmail 1034 1 1034 0 Rs sendmail 1028 1 1028 0 Ss select 0xc07bc004 sshd 898 1 898 0 Ss bo_wwait 0xc6ac9130 syslogd 846 1 846 0 Ss select 0xc07bc004 devd 445 1 445 65 Ss select 0xc07bc004 dhclient 425 1 43 0 S+ select 0xc07bc004 dhclient 124 1 124 0 Ss pause 0xc6739034 adjkerntz 42 0 0 0 SL - 0xe8ff9d04 [schedcpu] 41 0 0 0 SL sdflush 0xc07c50f4 [softdepflush] 40 0 0 0 RL [syncer] 39 0 0 0 RL [vnlru] 38 0 0 0 SL psleep 0xc07bc56c [bufdaemon] 37 0 0 0 SL pgzero 0xc07c6064 [pagezero] 36 0 0 0 SL psleep 0xc07c5bb4 [vmdaemon] 35 0 0 0 SL psleep 0xc07c5b70 [pagedaemon] 34 0 0 0 WL [irq1: atkbd0] 33 0 0 0 WL [irq7: ppc0] 32 0 0 0 WL [swi0: sio] 31 0 0 0 RL [acpi_cooling0] 30 0 0 0 SL tzpoll 0xc08cd838 [acpi_thermal] 29 0 0 0 WL [irq19: bge1] 28 0 0 0 WL [irq16: bge0+] 27 0 0 0 RL CPU 1 [irq18: em1] 26 0 0 0 WL [irq17: em0] 25 0 0 0 WL [irq23: nve0] 24 0 0 0 WL [irq22: atapci2] 23 0 0 0 WL [irq21: atapci1] 22 0 0 0 WL [irq15: ata1] 21 0 0 0 WL [irq14: ata0] 20 0 0 0 WL [irq9: acpi0] 9 0 0 0 SL - 0xc645f080 [kqueue taskq] 19 0 0 0 WL [swi2: cambio] 8 0 0 0 SL - 0xc645f280 [acpi_task_2] 7 0 0 0 SL - 0xc645f280 [acpi_task_1] 6 0 0 0 SL - 0xc645f280 [acpi_task_0] 18 0 0 0 WL [swi5: +] 5 0 0 0 SL - 0xc645f400 [thread taskq] 17 0 0 0 WL [swi6: Giant taskq] 16 0 0 0 WL [swi6: task queue] 15 0 0 0 RL [yarrow] 4 0 0 0 RL [g_down] 3 0 0 0 RL [g_up] 2 0 0 0 RL [g_event] 14 0 0 0 WL [swi3: vm] 13 0 0 0 RL CPU 0 [swi4: clock sio] 12 0 0 0 WL [swi1: net] 11 0 0 0 RL [idle: cpu0] 10 0 0 0 RL [idle: cpu1] 1 0 1 0 SLs wait 0xc63f5000 [init] 0 0 0 0 WLs [swapper] db> db> show intr irq1: atkbd0 (pid 34) irq4: sio0 (no thread) irq7: ppc0 (pid 33) irq9: acpi0 (pid 20) irq14: ata0 (pid 21) {ENTROPY} irq15: ata1 (pid 22) {ENTROPY} irq16: bge0+ (pid 28) irq17: em0 (pid 26) irq18: em1 (pid 27) irq19: bge1 (pid 29) irq21: atapci1 (pid 23) {ENTROPY} irq22: atapci2 (pid 24) {ENTROPY} irq23: nve0 (pid 25) swi1: net (pid 12) {SOFT} swi4: clock sio (pid 13) {SOFT, NEED} swi3: vm (pid 14) {SOFT} swi6: task queue (pid 16) {SOFT} swi6: Giant taskq (pid 17) {SOFT} swi5: + (pid 18) {SOFT} swi2: cambio (pid 19) {SOFT} swi0: sio (pid 32) {SOFT} db> db> show pcpu cpuid = 1 curthread = 0xc63f2900: pid 27 "irq18: em1" curpcb = 0xe500dd90 fpcurthread = none idlethread = 0xc63f1600: pid 10 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 db> db> show intrcnt irq4: sio0 901 irq14: ata0 1425 irq16: bge0+ 35 irq17: em0 33705 irq18: em1 26846 irq19: bge1 2001 irq21: atapci1 42 irq22: atapci2 33 cpu0: timer 2834932 cpu1: timer 2826571 db> db> show irqs irq0: (no thread) irq1: atkbd0 (pid 34) irq3: (no thread) irq4: sio0 (no thread) irq5: (no thread) irq6: (no thread) irq7: ppc0 (pid 33) irq8: (no thread) irq9: acpi0 (pid 20) irq10: (no thread) irq11: (no thread) irq12: (no thread) irq13: (no thread) irq14: ata0 (pid 21) {ENTROPY} irq15: ata1 (pid 22) {ENTROPY} irq16: bge0+ (pid 28) irq17: em0 (pid 26) irq18: em1 (pid 27) irq19: bge1 (pid 29) irq20: (no thread) irq21: atapci1 (pid 23) {ENTROPY} irq22: atapci2 (pid 24) {ENTROPY} irq23: nve0 (pid 25) db> Let me know if there is anything else you want me to print out From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 04:35:46 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18C2716A407 for ; Sun, 12 Nov 2006 04:35:46 +0000 (UTC) (envelope-from lamont@scriptkiddie.org) Received: from sploit.scriptkiddie.org (sploit.scriptkiddie.org [216.231.47.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDE9943D55 for ; Sun, 12 Nov 2006 04:35:45 +0000 (GMT) (envelope-from lamont@scriptkiddie.org) Received: from sploit (sploit [216.231.47.214]) by sploit.scriptkiddie.org (8.12.11/8.12.11) with ESMTP id kAC4Zjid027076 for ; Sat, 11 Nov 2006 20:35:45 -0800 (PST) Date: Sat, 11 Nov 2006 20:35:45 -0800 (PST) From: Lamont Granquist To: freebsd-stable@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: ath0 issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 04:35:46 -0000 i've got an ath0 issue similar to this one: http://lists.freebsd.org/pipermail/freebsd-stable/2006-July/027050.html this is on 6.2-PRERELEASE from Nov 3 FreeBSD warez.scriptkiddie.org 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Fri Nov 3 09:00:14 PST 2006 lamont@warez.scriptkiddie.org:/usr/obj/usr/src/sys/WAREZ i386 my ath0 dmesg looks like: > dmesg | egrep ath0 ath0: mem 0xef100000-0xef10ffff irq 21 at device 9.0 on pci2 ath0: Ethernet address: 00:09:5b:c8:78:9c ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 and my ath0 ifconfig: > ifconfig ath0 ath0: flags=8843 mtu 1500 inet 192.168.70.1 netmask 0xffffff00 broadcast 192.168.70.255 ether 00:09:5b:c8:78:9c media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c authmode OPEN privacy OFF deftxkey 1 txpowmax 30 bmiss 7 protmode CTS burst dtimperiod 1 bintval 100 the freebsd ath0 device is running in hostap mode acting as a router. i've tried turning off pf on the machine and that doesn't help, and i don't see the issue on the internet ethernet network it is also acting as a nat gateway for. the other side of the wireless connection is an intel 3945ABG running the latest 10.5.1.68 version of the WinXP driver with ad hoc power management disabled. what i've seen on tcpdump on the ath0 is that outbound packets seem to buffer up, often until it receives a packet on the interface. below is a tcpdump of an ssh session which is just while(1) { echo "foo" ; sleep 1 } which should be producing output every second. the 192.168.70.1 side is the server with the ath0 connection, and you can see in the tcpdump that where there are large jumps in time that its followed by 192.168.70.1 pushing out a lot of buffered up output. i can also make the buffers transmit on one tcp connection like this just by having another session going across the interface that i'm typing on. if there are any better ways to debug this please let me know, i don't know anything about how to debug wireless... here's the tcpdump: 19:05:51.659703 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 3007149784 win 16244 19:05:55.080365 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1:117(116) ack 0 win 65535 19:05:55.080374 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 117:233(116) ack 0 win 65535 19:05:55.080377 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1:233(232) ack 0 win 65535 19:05:55.080380 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 233:349(116) ack 0 win 65535 19:05:55.084195 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 233 win 17520 19:05:55.085769 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 233 win 17520 19:05:55.281034 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 349 win 17404 19:05:55.333330 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 349:465(116) ack 0 win 65535 19:05:55.482215 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 465 win 17288 19:05:58.097585 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 465:581(116) ack 0 win 65535 19:05:58.097593 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 581:697(116) ack 0 win 65535 19:05:58.099547 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 697 win 17056 19:06:01.466165 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 697:813(116) ack 0 win 65535 19:06:01.466173 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 813:929(116) ack 0 win 65535 19:06:01.466175 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 929:1045(116) ack 0 win 65535 19:06:01.466177 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1045:1161(116) ack 0 win 65535 19:06:01.466179 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 697:1161(464) ack 0 win 65535 19:06:01.470001 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 929 win 16824 19:06:01.470818 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 1161 win 16592 19:06:01.471968 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 1161 win 16592 19:06:04.030770 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1161:1277(116) ack 0 win 65535 19:06:04.030775 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1277:1393(116) ack 0 win 65535 19:06:04.033830 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 1393 win 16360 19:06:16.103948 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1393:1509(116) ack 0 win 65535 19:06:16.103955 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1509:1625(116) ack 0 win 65535 19:06:16.103957 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1625:1741(116) ack 0 win 65535 19:06:16.103959 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1741:1857(116) ack 0 win 65535 19:06:16.103962 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1393:1857(464) ack 0 win 65535 19:06:16.103964 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1857:1973(116) ack 0 win 65535 19:06:16.103966 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1973:2089(116) ack 0 win 65535 19:06:16.103968 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 2089:2205(116) ack 0 win 65535 19:06:16.103971 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 2205:2321(116) ack 0 win 65535 19:06:16.103972 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 2321:2437(116) ack 0 win 65535 19:06:16.103975 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 2437:2553(116) ack 0 win 65535 19:06:16.103977 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 2553:2669(116) ack 0 win 65535 19:06:16.103979 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 2669:2785(116) ack 0 win 65535 19:06:16.103981 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 1393:2785(1392) ack 0 win 65535 19:06:16.107073 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 1625 win 16128 19:06:16.107812 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 1857 win 17520 19:06:16.108272 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 1857 win 17520 19:06:16.113934 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 2089 win 17288 19:06:16.114733 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 2321 win 17056 19:06:16.116361 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 2553 win 16824 19:06:16.116729 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 2785 win 16592 19:06:16.117807 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 2785 win 16592 19:06:19.131458 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 2785:2901(116) ack 0 win 65535 19:06:19.131463 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 2901:3017(116) ack 0 win 65535 19:06:19.131465 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 3017:3133(116) ack 0 win 65535 19:06:19.134734 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 3017 win 16360 19:06:19.331775 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 3133 win 16244 19:06:19.359317 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 3133:3249(116) ack 0 win 65535 19:06:19.531435 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 3249 win 16128 19:06:20.843763 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 3249:3365(116) ack 0 win 65535 19:06:21.031443 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 3365 win 17520 19:06:25.055172 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 3365:3481(116) ack 0 win 65535 19:06:25.055179 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 3481:3597(116) ack 0 win 65535 19:06:25.055182 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 3597:3713(116) ack 0 win 65535 19:06:25.055184 IP 192.168.70.1.ssh > 192.168.70.5.1063: P 3713:3829(116) ack 0 win 65535 19:06:25.058306 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 3597 win 17288 19:06:25.059205 IP 192.168.70.5.1063 > 192.168.70.1.ssh: . ack 3829 win 17056 From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 05:51:48 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EE3D16A416 for ; Sun, 12 Nov 2006 05:51:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5167C43D62 for ; Sun, 12 Nov 2006 05:51:44 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAC5pZr5064210; Sat, 11 Nov 2006 22:51:40 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4556B666.20107@samsco.org> Date: Sat, 11 Nov 2006 22:51:34 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Josh Paetzel References: <1162852746.32694.23.camel@bigapple.omnis.ch> <200611071005.28853.josh@tcbug.org> <4550AFFD.9090104@samsco.org> <200611071500.20686.josh@tcbug.org> In-Reply-To: <200611071500.20686.josh@tcbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-stable@freebsd.org Subject: Re: Still have BCE driver issues (dell pe 1950) and NFS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 05:51:48 -0000 Josh Paetzel wrote: > On Tuesday 07 November 2006 10:10, Scott Long wrote: >> Josh Paetzel wrote: >>> On Tuesday 07 November 2006 03:30, Fredrik Widlund wrote: >>>> Hi, >>>> >>>> Will a fix/this fix be part of the 6.2 Release? We will be >>>> relying heavily on fbsd6.2 and pe1950 and are worried about the >>>> BCE stability? >>>> >>>> Kind regards, >>>> Fredrik Widlund >>>> >>>> Scott Long wrote: >>>>> Olivier Mueller wrote: >>>>>> Le 7 nov. 06 à 01:15, Scott Long a écrit : >>>>>>> Olivier Mueller wrote: >>>>>>>> NFS Server: dell poweredge 1950, with the 1.2.2.6 version of >>>>>>>> if_bce.c: bce0: >>>>>>> (B1), v0.9.6> mem - Start a directory listing on it: >>>>>>>> immediate (network) crash of the NFS >>>>>>>> server. (reproduced 3 times) >>>>>>> Do the following, then retry your test: >>>>>>> ifconfig bce0 -txcsum >>>>>> Oh, this way it looks much better, thanks. Directory listing >>>>>> was fine, and copying files during 2-3 minutes over NFS worked >>>>>> as well. More tests will follow tomorrow. >>>>>> >>>>>> Next step? :-) Should I put that command somewhere in my init >>>>>> scripts, or even directly in rc.conf, or wait for a new >>>>>> if_bce0.c version? I am available for any other >>>>>> PE1950-related tests if this may help. >>>>>> >>>>>> Regards, >>>>>> Olivier >>>>> Change /sys/dev/bce/if_bcereg.h so that BCE_IF_HWASSIST is >>>>> defined to 0. Then recompile. >>>>> >>>>> Scott >>> I know I've brought this up before, but I have a PE1950 with a >>> pair of bce nics that get pounded on 24/7. I've been using 6.1-R >>> with the 0.9.6 version of the bce driver for a couple of months >>> now. The driver is available here: >>> http://yogurt.org/FreeBSD/if_bce.c I've emailed the author of >>> the driver and I've at least mentioned it to Scott once but I >>> really can't understand why we don't just import this driver into >>> the tree. >> What you just posted is exactly what committed to CVS for 7-CURRENT >> and 6-STABLE, and what was proven to break down under moderate to >> heavy UDP traffic. I don't doubt that your servers have a load >> that doesn't trigger the problem, but if you're curious I can send >> you a couple of very simple test cases that will cause your driver >> to panic and your network interface to wedge. >> >> Scott > > My bad. Thanks for clearing this up. (In my case pretty much all of > the traffic is TCP which I guess would explain why it's working for > me) > Actually, I think that I was a little unclear. The link that you posted is what was in FreeBSD prior to me fixing all of the problems. What is in FreeBSD now fixes just about every problem for every person. There are still a few reports of mystery problems, but they are in very rare and specialized cases. In all, the driver works now. Scott From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 07:29:39 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF22216A407 for ; Sun, 12 Nov 2006 07:29:39 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (dsl081-163-122.sea1.dsl.speakeasy.net [64.81.163.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7955C43D45 for ; Sun, 12 Nov 2006 07:29:38 +0000 (GMT) (envelope-from jcw@highperformance.net) Received: from [192.168.1.16] (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.6/8.13.4) with ESMTP id kAC6SV7r016065; Sat, 11 Nov 2006 22:28:31 -0800 (PST) (envelope-from jcw@highperformance.net) Message-ID: <4556BF10.9030002@highperformance.net> Date: Sat, 11 Nov 2006 22:28:32 -0800 From: "Jason C. Wells" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "O. Hartmann" References: <4554D43E.5010700@highperformance.net> <20061110222434.GA76724@icarus.home.lan> <200611111019.43944.doconnor@gsoft.com.au> <45560E17.6070306@mail.zedat.fu-berlin.de> In-Reply-To: <45560E17.6070306@mail.zedat.fu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on s4.stradamotorsports.com Cc: freebsd-stable@freebsd.org Subject: Re: Compiler Options X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 07:29:39 -0000 O. Hartmann wrote: > Daniel O'Connor wrote: > >> On Saturday 11 November 2006 08:54, Jeremy Chadwick wrote: >> >> >>> The kernel itself _will not_ use any SSE or MMX operations when built. >>> This is because these optimisations are known to break the FreeBSD >>> kernel. This applies to all i386 architectures, and probably 64-bit >>> architectures too (not sure). >>> >>> >> I think this is mainly because the kernel has no FPU context so you can't >> actually use any FPU operation (including SSE & MMX) without potentially >> trashing userland data. >> >> > > This is a good question to ask why. Still a relict from FreeBSDs BSD4.4 > legacy root? > >> Also, the cost of saving/restoring the context is quite high so potential >> benefits are largely negated. >> >> > > Well, this is often subject of lectures even at universities today and > even it is so, modern hardware design should be aware of those > disadvantages. > Ans this leads to the question whether this is in FreeBSD so because it > is really still a disadvantage (what I do not believe, even on i386 > hardware) or it is said to be so due to nobody has taken care about > that. As I remember myself, modern Linux kernels use MMX/SSE registers > even for purposes of getting an advantage in speed. > Peter Wemm once had this to say about that. http://lists.freebsd.org/pipermail/freebsd-amd64/2005-February/003663.html From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 12:14:10 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 985EE16A492 for ; Sun, 12 Nov 2006 12:14:10 +0000 (UTC) (envelope-from ask@develooper.com) Received: from x8.develooper.com (x8.develooper.com [216.52.237.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33C7E43D53 for ; Sun, 12 Nov 2006 12:14:06 +0000 (GMT) (envelope-from ask@develooper.com) Received: (qmail 18154 invoked from network); 12 Nov 2006 12:14:05 -0000 Received: from gw.develooper.com (HELO ?10.0.201.111?) (ask@cleverpeople.org@64.81.84.140) by smtp.develooper.com with (AES128-SHA encrypted) SMTP; 12 Nov 2006 12:14:05 -0000 In-Reply-To: <3720CF60-DC4E-47E4-BA87-3CF8D335D286@khera.org> References: <453D49D2.1010705@rogers.com> <3861E2E8-4232-4C46-8D0A-1B6079BCA07D@mac.com> <453D53ED.5050403@rogers.com> <3720CF60-DC4E-47E4-BA87-3CF8D335D286@khera.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E89703C-987A-45A6-8281-D714FF9D4036@develooper.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?= Date: Sun, 12 Nov 2006 04:14:04 -0800 To: Vivek Khera X-Mailer: Apple Mail (2.752.2) Cc: stable@freebsd.org Subject: Re: Running large DB's on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 12:14:10 -0000 On Oct 24, 2006, at 7:27 AM, Vivek Khera wrote: >> I believe the front-end application is MySQL dependent, but what >> is so much better about PostgreSQL? I understand that it has some >> more advanced features, but if they are not used, then what is the >> advantage? (I really like the InnooDB storage in MySQL) > > So after billions and billions of inserts/updates/deletes, how do > you reclaim all that lost space in innodb? dump + reload is what I > hear. If you've configured it properly you can just do "optimize table foo". > also, do you value your data? ie, if you insert data which cannot > be stored should the DB silently alter it or should it throw back > an error for your application to decide what to do? guess which DB > does which... Not MySQL if you configure/ask it not to. - ask -- http://www.askbjoernhansen.com/ From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 13:45:18 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC6DE16A4B3 for ; Sun, 12 Nov 2006 13:45:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFDFC43D80 for ; Sun, 12 Nov 2006 13:45:12 +0000 (GMT) (envelope-from adrian.chadd@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so851351wxc for ; Sun, 12 Nov 2006 05:45:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=qJuPR7KKwG3b0WdZaKCVRi5CLIYIqYgGUxcoCTscANMgB4uJ/rjx1llExdzR4php6IzPfzi6AvA3DWsazDEVCwImW5a9lOY/9niVN1JFONNb5UyDd3KxlB+1flFyfVN8XRquYpodCmK5BnYgZV+4Zvm1tYvzwH6NjQWAgra/BCU= Received: by 10.90.63.16 with SMTP id l16mr2423088aga.1163339111445; Sun, 12 Nov 2006 05:45:11 -0800 (PST) Received: by 10.90.31.4 with HTTP; Sun, 12 Nov 2006 05:45:11 -0800 (PST) Message-ID: Date: Sun, 12 Nov 2006 21:45:11 +0800 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "Jack Vogel" In-Reply-To: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> X-Google-Sender-Auth: 086a612427ad5095 Cc: freebsd-stable@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 13:45:19 -0000 Should fiddling with the interrupt-coalescing stuff in the em driver via sysctl be tried? None of the recent tests in reply to your email indicate any particular tx/rx threshold settings. adrian -- Adrian Chadd - adrian@freebsd.org From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 15:15:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D94EB16A4F4; Sun, 12 Nov 2006 15:15:44 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BF3443D88; Sun, 12 Nov 2006 15:15:38 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kACFFcoI066538; Sun, 12 Nov 2006 10:15:38 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kACFFb5J038582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 10:15:37 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611121515.kACFFb5J038582@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Nov 2006 10:15:46 -0500 To: "Adrian Chadd" , "Jack Vogel" From: Mike Tancsa In-Reply-To: References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 15:15:44 -0000 At 08:45 AM 11/12/2006, Adrian Chadd wrote: >Should fiddling with the interrupt-coalescing stuff in the em driver >via sysctl be tried? >None of the recent tests in reply to your email indicate any >particular tx/rx threshold settings. > I was using whatever is the default. What would you like me to test ? # sysctl -A dev.em dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.2.9 dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x115e class=0x020000 dev.em.0.%parent: pci6 dev.em.0.debug_info: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection Version - 6.2.9 dev.em.1.%driver: em dev.em.1.%location: slot=0 function=1 dev.em.1.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x115e class=0x020000 dev.em.1.%parent: pci6 dev.em.1.debug_info: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 >adrian > >-- >Adrian Chadd - adrian@freebsd.org >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 16:42:06 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39EDC16A403; Sun, 12 Nov 2006 16:42:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F0DC43D45; Sun, 12 Nov 2006 16:41:54 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kACGfl9i068088; Sun, 12 Nov 2006 09:41:52 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45574ECA.4080207@samsco.org> Date: Sun, 12 Nov 2006 09:41:46 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> In-Reply-To: <200611120412.kAC4CuIB035746@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 16:42:06 -0000 Mike Tancsa wrote: > At 01:42 AM 11/11/2006, Scott Long wrote: > driver. What will help me is if you can hook up a serial console to >> your machine and see if it can be made to drop to the debugger while it >> is under load and otherwise unresponsive. If you can, getting a process >> dump might help confirm where each CPU is spending its time. > > > ./netblast 192.168.88.218 500 110 1000 > > I compiled in the various debugging options and on the serial console I > get a few > > Expensive timeout(9) function: 0xc0601e48(0) 0.024135749 s > and the serial console > One CPU seems to be stuck in softclock. My guess here is that there is significant lock contention. Please try the following: 1. Use addr2line or gdb on the kernel to find out what function is at 0xc0601e48 (the address that was printed above). This address will change every time you recompile the kernel, so you'll need to reacquire it from the console each time. 2. Try compiling in WITNESS and running the test as before, then break into the debugger as before. Run 'show locks'. I'm not sure how fruitful this will be, WITNESS might make it unbearably slow. 3. Turn on MUTEX_PROFILING according to the text in /sys/conf/NOTES and the man page by the same name. 4. Remove ADAPTIVE_GIANT from your config and retest. If that doesn't show a difference, then try setting NO_ADAPTIVE_MUTEXES. Thanks, Scott From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 18:33:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 011AE16A47C for ; Sun, 12 Nov 2006 18:33:42 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC58A43D99 for ; Sun, 12 Nov 2006 18:33:35 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=[192.168.0.4]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1GjK98-0003bQ-Cx for freebsd-stable@freebsd.org; Sun, 12 Nov 2006 21:33:34 +0300 Message-ID: <455768F3.4000407@FreeBSD.org> Date: Sun, 12 Nov 2006 21:33:23 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 1.5.0.7 (X11/20061001) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 18:33:42 -0000 Do you know an old sio driver is hardly usable? There are many silo overflows, working with a terminal device is a nightmare. There was a report about one crash with a message about a spinlock holed more than 5 seconds (there is no core dump because it has not repeated). After a discussion in a Russian FIDO group I've change it on uart and the problems gone. I think a default driver should be changed from sio to uart until it will be fixed. -- Dixi. Sem. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 18:48:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 658BC16A403 for ; Sun, 12 Nov 2006 18:48:54 +0000 (UTC) (envelope-from todorov@paladin.bulgarpress.com) Received: from gregorian.transpress.bg (gregorian.transpress.bg [82.147.129.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB1DA43D46 for ; Sun, 12 Nov 2006 18:48:53 +0000 (GMT) (envelope-from todorov@paladin.bulgarpress.com) Received: from localhost (unknown [127.0.0.1]) by gregorian.transpress.bg (Postfix) with ESMTP id E5F3BE6 for ; Sun, 12 Nov 2006 20:50:24 +0200 (EET) X-Virus-Scanned: amavisd-new at gregorian.transpress.bg Received: from gregorian.transpress.bg ([127.0.0.1]) by localhost (gregorian.transpress.bg [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P5--nhv8QpE for ; Sun, 12 Nov 2006 20:50:22 +0200 (EET) Received: from [192.168.6.8] (87-126-7-81.btc-net.bg [87.126.7.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gregorian.transpress.bg (Postfix) with ESMTP id CB10FCE for ; Sun, 12 Nov 2006 20:50:21 +0200 (EET) Message-ID: <45576C8D.5080809@paladin.bulgarpress.com> Date: Sun, 12 Nov 2006 20:48:45 +0200 From: "Todorov @ Paladin" User-Agent: Mozilla Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Subject: Migration 5.3{4} to 6.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 18:48:54 -0000 Hi group, what is your opinion - will there be directly supported way to upgrade from source 5.3 & 5.4 to upcomming 6.2 ? I'll appreciate your answers. Thanks. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 19:34:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C54E16A403 for ; Sun, 12 Nov 2006 19:34:36 +0000 (UTC) (envelope-from lamont@scriptkiddie.org) Received: from sploit.scriptkiddie.org (sploit.scriptkiddie.org [216.231.47.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3AA243DD8 for ; Sun, 12 Nov 2006 19:32:58 +0000 (GMT) (envelope-from lamont@scriptkiddie.org) Received: from sploit (sploit [216.231.47.214]) by sploit.scriptkiddie.org (8.12.11/8.12.11) with ESMTP id kACJWw3J029216 for ; Sun, 12 Nov 2006 11:32:58 -0800 (PST) Date: Sun, 12 Nov 2006 11:32:58 -0800 (PST) From: Lamont Granquist To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: ath0 issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 19:34:36 -0000 i did the same thing with running: while(1) echo foo sleep 1 end in a window ssh'd into the machine with the ath0 driver, but with the kernel recompiled with ATH_DEBUG and sysctl dev.ath.0.debug=0xffffffff -- there should be packets sent every second while doing this. i saw the same behavior where tx packets would tend to spool up and buffer. here's the output of one second where a bunch of spooled up packets were sent alont with the previous second and following second and with a note on how long it had been before any ath*tx* routine had been called. hopefully this is useful for debugging -- i've got copious amounts of debugging logs, so let me know if i've guessed wrongly about what is relevant... this is the previous debugging notice for ath*tx* which i believe indicates nothing sent out on the interface since 11:17:36: Nov 12 11:17:36 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 11/1/1 [..snip..] here is the second prior to the spooled up packets being sent: Nov 12 11:17:46 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:46 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:46 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:46 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:46 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:46 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:46 warez kernel: R[ 0] (DS.V:0xed2833f0 DS.P:0x3e7fa3f0) L:3e7fa420 D:3e7c1000 * Nov 12 11:17:46 warez kernel: 00000000 00000800 2224801c 13ef0903 Nov 12 11:17:46 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 24M +34 Nov 12 11:17:46 warez kernel: 4811 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 00e5 a750 81ed Nov 12 11:17:46 warez kernel: R[ 0] (DS.V:0xed283420 DS.P:0x3e7fa420) L:3e7fa450 D:3e7eb800 Nov 12 11:17:46 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:46 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:46 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:46 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:46 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:46 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:46 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:46 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:46 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:46 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:46 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:46 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:46 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:46 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:46 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:46 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:46 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:46 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:46 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:46 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:46 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:46 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:46 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:46 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:46 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:46 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:46 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:46 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:46 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:46 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:46 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:46 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:46 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:46 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:46 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:46 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:46 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:46 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:46 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:46 warez kernel: R[ 0] (DS.V:0xed283420 DS.P:0x3e7fa420) L:3e7fa450 D:3e7eb800 * Nov 12 11:17:46 warez kernel: 00000000 00000800 2214801c 13e20903 Nov 12 11:17:46 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 24M +33 Nov 12 11:17:46 warez kernel: 4801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 10e5 bac4 31a6 Nov 12 11:17:46 warez kernel: R[ 0] (DS.V:0xed283450 DS.P:0x3e7fa450) L:3e7fa480 D:3e7a1800 Nov 12 11:17:46 warez kernel: 00000000 00000800 00000000 00000000 here is the second where spooled up packets are sent: Nov 12 11:17:47 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:47 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:47 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:47 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:47 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:47 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283450 DS.P:0x3e7fa450) L:3e7fa480 D:3e7a1800 * Nov 12 11:17:47 warez kernel: 00000000 00000800 2204801c 33f00903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 24M +32 Nov 12 11:17:47 warez kernel: 4811 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 20e5 0574 0578 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283480 DS.P:0x3e7fa480) L:3e7fa4b0 D:3e7d3000 Nov 12 11:17:47 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:47 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:47 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:47 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:47 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:47 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:47 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:47 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:47 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:47 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:47 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:47 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:47 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:47 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:47 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:47 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:47 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:47 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:47 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283480 DS.P:0x3e7fa480) L:3e7fa4b0 D:3e7d3000 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060080 1bb30903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 30e5 aaaa 0300 0000 0800 4500 005c 0403 4000 8006 e941 c0a8 4605 c0a8 4601 040d 0016 cc76 e243 7545 cd61 5018 4310 8dba 0000 6984 e7ce 87cd e3e6 1abe a1d1 f4ac f876 fbef b495 21be 9a85 2258 0b23 eec6 da28 c1cf e1a9 54b6 ffae 525d a2ff 136e c579 37c1 141d 8391 d3a7 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed2834b0 DS.P:0x3e7fa4b0) L:3e7fa4e0 D:3e1ba000 Nov 12 11:17:47 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc595e000 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0822 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c 7045 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e793c30 2c732036 411e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 2f0d9740 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: TXDP[1] = 0x3e793c00 (0xed292c00) depth 1 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc4e35900 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5ath_intr: status 0x1000040 Nov 12 11:17:47 warez kernel: ath_tx_processq: tx queue 1 head 0x3e793c00 link 0xed292c30 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed292c00 DS.P:0x3e793c00) L:3e793c30 D:2c732036 F:041 Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed292c30 DS.P:0x3e793c30) L:00000000 D:2f0d9740 F:041 Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc4e2fd00 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0822 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c 9045 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e7905d0 3e443d36 411e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 3e7e2140 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed292c30)=0x3e7905a0 (0xed28f5a0) depth 2 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc4c4c500 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0822 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c a045 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e795c10 3e6c0536 411e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 3e443640 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed28f5d0)=0x3e795be0 (0xed294be0) depth 3 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc595fa00 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0822 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c b045 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e792790 2c153a36 411e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 2b115e40 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed294c10)=0x3e792760 (0xed291760) depth 4 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc4bedd00 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0822 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c c045 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e793870 3e7e1d36 411e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 3e6c0440 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed291790)=0x3e793840 (0xed292840) depth 5 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc4bef600 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0822 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c d045 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e797830 3e7e3636 611e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 3e505540 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed292870)=0x3e797800 (0xed296800) depth 6 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc5962400 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0822 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c e045 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e795fd0 2bd56436 411e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 3e7e0a40 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed296830)=0x3e795fa0 (0xed294fa0) depth 7 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc5962a00 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0822 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c f045 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e797650 2bd56a36 411e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 2f1b8740 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed294fd0)=0x3e797620 (0xed296620) depth 8 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc5963800 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0822 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c 0046 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e796b10 2be77836 411e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 3e7e5540 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed296650)=0x3e796ae0 (0xed295ae0) depth 9 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc4e34900 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 54M Nov 12 11:17:47 warez kernel: 0802 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c 1046 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e795490 3e608936 411e0080 00009020 03328000 00006d0c Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 3e7df940 00000000 0000005c 03328000 00006d0c Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed295b10)=0x3e795460 (0xed294460) depth 10 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc4fa7000 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0802 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c 2046 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e7921f0 2edbb036 611e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 2f2dca40 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed294490)=0x3e7921c0 (0xed2911c0) depth 11 Nov 12 11:17:47 warez kernel: ath_intr: status 0x10000c0 Nov 12 11:17:47 warez kernel: ath_tx_processq: tx queue 1 head 0x3e7921c0 link 0xed2911f0 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed292c00 DS.P:0x3e793c00) L:3e793c30 D:2c732036 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed292c30 DS.P:0x3e793c30) L:3e7905a0 D:2f0d9740 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65a70001 01043d4d Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed28f5a0 DS.P:0x3e7905a0) L:3e7905d0 D:3e443d36 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed28f5d0 DS.P:0x3e7905d0) L:3e795be0 D:3e7e2140 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65a70001 01043d4f Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed294be0 DS.P:0x3e795be0) L:3e795c10 D:3e6c0536 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed294c10 DS.P:0x3e795c10) L:3e792760 D:3e443640 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65a70001 01043d51 Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed291760 DS.P:0x3e792760) L:3e792790 D:2c153a36 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed291790 DS.P:0x3e792790) L:3e793840 D:2b115e40 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65a70001 01045d53 Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed292840 DS.P:0x3e793840) L:3e793870 D:3e7e1d36 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed292870 DS.P:0x3e793870) L:3e797800 D:3e6c0440 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65a70001 01043d55 Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed296800 DS.P:0x3e797800) L:3e797830 D:3e7e3636 F:0411 * Nov 12 11:17:47 warez kernel: 611e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed296830 DS.P:0x3e797830) L:3e795fa0 D:3e505540 F:0411 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65a80001 01043d57 Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed294fa0 DS.P:0x3e795fa0) L:3e795fd0 D:2bd56436 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed294fd0 DS.P:0x3e795fd0) L:3e797620 D:3e7e0a40 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65a80001 01043d59 Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed296620 DS.P:0x3e797620) L:3e797650 D:2bd56a36 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed296650 DS.P:0x3e797650) L:3e796ae0 D:2f1b8740 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65a80001 01043d5b Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed295ae0 DS.P:0x3e796ae0) L:3e796b10 D:2be77836 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed295b10 DS.P:0x3e796b10) L:3e795460 D:3e7e5540 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65a80001 01043d5d Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed294460 DS.P:0x3e795460) L:3e795490 D:3e608936 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d0c 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed294490 DS.P:0x3e795490) L:3e7921c0 D:3e7df940 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d0c 65a80101 01043d5f Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 11/1/2 Nov 12 11:17:47 warez kernel: update_stats: 00:18:de:85:d0:5e size 250 sample rate 108 tries (1/2) tt 1157 avg_tt (509/444) status 0 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed2911c0 DS.P:0x3e7921c0) L:3e7921f0 D:2edbb036 F:0411 * Nov 12 11:17:47 warez kernel: 611e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed2911f0 DS.P:0x3e7921f0) L:00000000 D:2f2dca40 F:0411 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65a80001 01043d61 Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: ath_intr: status 0x10000c9 Nov 12 11:17:47 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed2834b0 DS.P:0x3e7fa4b0) L:3e7fa4e0 D:3e1ba000 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060058 23450903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 40e5 aaaa 0300 0000 0800 4500 0034 0404 4000 8006 e968 c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cd95 8010 42dc ad4a 0000 0101 050a 7545 cdc9 7545 cdfd a915 da56 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed2834e0 DS.P:0x3e7fa4e0) L:3e7fa510 D:3e7eb000 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060058 23ed0903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 50e5 aaaa 0300 0000 0800 4500 0034 0405 4000 8006 e967 c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cd95 8010 42dc ad16 0000 0101 050a 7545 cdc9 7545 ce31 25cd dc2f Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283510 DS.P:0x3e7fa510) L:3e7fa540 D:2f667000 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060058 24830903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 60e5 aaaa 0300 0000 0800 4500 0034 0406 4000 8006 e966 c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cd95 8010 42dc ace2 0000 0101 050a 7545 cdc9 7545 ce65 3366 5b69 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283540 DS.P:0x3e7fa540) L:3e7fa570 D:3e7d7800 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060058 253d0903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 70e5 aaaa 0300 0000 0800 4500 0034 0407 4000 8006 e965 c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cd95 8010 42dc acae 0000 0101 050a 7545 cdc9 7545 ce99 9590 0f62 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283570 DS.P:0x3e7fa570) L:3e7fa5a0 D:3e65d000 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060058 25b80903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 80e5 aaaa 0300 0000 0800 4500 0034 0408 4000 8006 e964 c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cd95 8010 42dc ac7a 0000 0101 050a 7545 cdc9 7545 cecd b35c d3d6 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed2835a0 DS.P:0x3e7fa5a0) L:3e7fa5d0 D:3e7ee000 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060058 26600903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 90e5 aaaa 0300 0000 0800 4500 0034 0409 4000 8006 e963 c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cd95 8010 42dc ac46 0000 0101 050a 7545 cdc9 7545 cf01 523f a5f2 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed2835d0 DS.P:0x3e7fa5d0) L:3e7fa600 D:2ec2e000 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060058 273e0903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c a0e5 aaaa 0300 0000 0800 4500 0034 040a 4000 8006 e962 c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cd95 8010 42dc ac12 0000 0101 050a 7545 cdc9 7545 cf35 a8aa ba91 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283600 DS.P:0x3e7fa600) L:3e7fa630 D:2ec0c800 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060058 27f80903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c b0e5 aaaa 0300 0000 0800 4500 0034 040b 4000 8006 e961 c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cd95 8010 42dc abde 0000 0101 050a 7545 cdc9 7545 cf69 28f7 46ff Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283630 DS.P:0x3e7fa630) L:3e7fa660 D:3e55c000 Nov 12 11:17:47 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:47 warez kernel: ath_tx_processq: tx queue 1 head 0x3e7921c0 link 0 Nov 12 11:17:47 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:47 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283630 DS.P:0x3e7fa630) L:3e7fa660 D:3e55c000 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060058 28a00903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c c0e5 aaaa 0300 0000 0800 4500 0034 040c 4000 8006 e960 c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cd95 8010 42dc abaa 0000 0101 050a 7545 cdc9 7545 cf9d d624 7a75 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283660 DS.P:0x3e7fa660) L:3e7fa690 D:2ee9a800 Nov 12 11:17:47 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:47 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:47 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283660 DS.P:0x3e7fa660) L:3e7fa690 D:2ee9a800 * Nov 12 11:17:47 warez kernel: 00000000 00000800 22060058 29510903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c d0e5 aaaa 0300 0000 0800 4500 0034 040d 4000 8006 e95f c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cd95 8010 42dc ab76 0000 0101 050a 7545 cdc9 7545 cfd1 2a94 7d6b Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283690 DS.P:0x3e7fa690) L:3e7fa6c0 D:3e6e4800 Nov 12 11:17:47 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:47 warez kernel: b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0822 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c 8045 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e798730 3dba9936 411e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 3e7df040 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: TXDP[1] = 0x3e798700 (0xed297700) depth 1 Nov 12 11:17:47 warez kernel: ath_intr: status 0x1000040 Nov 12 11:17:47 warez kernel: ath_tx_processq: tx queue 1 head 0x3e798700 link 0xed297730 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed297700 DS.P:0x3e798700) L:3e798730 D:3dba9936 F:041 Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed297730 DS.P:0x3e798730) L:00000000 D:3e7df040 F:041 Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: ath_tx_start: m 0xc4fa5700 len 128 Nov 12 11:17:47 warez kernel: FRDS 00:09:5b:c8:78:9c->00:18:de:85:d0:5e(00:09:5b:c8:78:9c) data 48M Nov 12 11:17:47 warez kernel: 0802 2c00 0018 de85 d05e 0009 5bc8 789c 0009 5bc8 789c 3046 aaaa 0300 0000 0800 Nov 12 11:17:47 warez kernel: ath_tx_start: 0: 3e798550 2f0d9736 411e0080 00009020 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: 1: 00000000 3e443d40 00000000 0000005c 03328000 00006d08 Nov 12 11:17:47 warez kernel: ath_tx_start: link[1](0xed297730)=0x3e798520 (0xed297520) depth 2 Nov 12 11:17:47 warez kernel: ath_intr: status 0x1000040 Nov 12 11:17:47 warez kernel: ath_tx_processq: tx queue 1 head 0x3e798520 link 0xed297550 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed297700 DS.P:0x3e798700) L:3e798730 D:3dba9936 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed297730 DS.P:0x3e798730) L:3e798520 D:3e7df040 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65aa0001 01043d63 Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: Q1[ 0] (DS.V:0xed297520 DS.P:0x3e798520) L:3e798550 D:2f0d9736 F:041 * Nov 12 11:17:47 warez kernel: 411e0080 00009020 03328000 00006d08 00000000 00000000 Nov 12 11:17:47 warez kernel: (DS.V:0xed297550 DS.P:0x3e798550) L:00000000 D:3e443d40 F:041 * Nov 12 11:17:47 warez kernel: 00000000 0000005c 03328000 00006d08 65aa0001 01045d65 Nov 12 11:17:47 warez kernel: ath_rate_tx_complete: 00:18:de:85:d0:5e size 250 status 0 rate/try 10/1/1 Nov 12 11:17:47 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:47 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283690 DS.P:0x3e7fa690) L:3e7fa6c0 D:3e6e4800 * Nov 12 11:17:47 warez kernel: 00000000 00000800 2206004c 2c530903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c e0e5 aaaa 0300 0000 0800 4500 0028 040e 4000 8006 e96a c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cfd1 5010 40a0 69b4 0000 bf57 d245 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed2836c0 DS.P:0x3e7fa6c0) L:3e7fa6f0 D:2f198800 Nov 12 11:17:47 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:47 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:47 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed2836c0 DS.P:0x3e7fa6c0) L:3e7fa6f0 D:2f198800 * Nov 12 11:17:47 warez kernel: 00000000 00000800 2206004c 2d120903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 54M +32 Nov 12 11:17:47 warez kernel: 0801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c f0e5 aaaa 0300 0000 0800 4500 0028 040f 4000 8006 e969 c0a8 4605 c0a8 4601 040d 0016 cc76 e277 7545 cfd1 5010 40a0 69b4 0000 4699 6801 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed2836f0 DS.P:0x3e7fa6f0) L:3e7fa720 D:3e6e6800 Nov 12 11:17:47 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:47 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:47 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:47 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:47 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:47 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:47 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed2836f0 DS.P:0x3e7fa6f0) L:3e7fa720 D:3e6e6800 * Nov 12 11:17:47 warez kernel: 00000000 00000800 2204801c 3d500903 Nov 12 11:17:47 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 24M +32 Nov 12 11:17:47 warez kernel: 4811 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 00e6 1d01 8874 Nov 12 11:17:47 warez kernel: R[ 0] (DS.V:0xed283720 DS.P:0x3e7fa720) L:3e7fa750 D:3de15800 Nov 12 11:17:47 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:47 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:47 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:47 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:47 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:47 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:47 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:47 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:47 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:47 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:47 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:47 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:47 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) and here is the following second: Nov 12 11:17:48 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:48 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:48 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:48 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:48 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:48 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:48 warez kernel: R[ 0] (DS.V:0xed283720 DS.P:0x3e7fa720) L:3e7fa750 D:3de15800 * Nov 12 11:17:48 warez kernel: 00000000 00000800 2224801c 340f0903 Nov 12 11:17:48 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 24M +34 Nov 12 11:17:48 warez kernel: 4801 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 10e6 0095 383f Nov 12 11:17:48 warez kernel: R[ 0] (DS.V:0xed283750 DS.P:0x3e7fa750) L:3e7fa000 D:3e7e9800 Nov 12 11:17:48 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:48 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:48 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:48 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:48 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:48 warez kernel: ath_intr: status 0x1000009 Nov 12 11:17:48 warez kernel: ath_rx_proc: pending 1 Nov 12 11:17:48 warez kernel: R[ 0] (DS.V:0xed283750 DS.P:0x3e7fa750) L:3e7fa000 D:3e7e9800 * Nov 12 11:17:48 warez kernel: 00000000 00000800 2214801c 53f00903 Nov 12 11:17:48 warez kernel: TODS 00:18:de:85:d0:5e->00:09:5b:c8:78:9c(00:09:5b:c8:78:9c) data 24M +33 Nov 12 11:17:48 warez kernel: 4811 2c00 0009 5bc8 789c 0018 de85 d05e 0009 5bc8 789c 20e6 bf25 0ce1 Nov 12 11:17:48 warez kernel: R[ 0] (DS.V:0xed283000 DS.P:0x3e7fa000) L:3e7fa030 D:2f525800 Nov 12 11:17:48 warez kernel: 00000000 00000800 00000000 00000000 Nov 12 11:17:48 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:48 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:48 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:48 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:48 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:48 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:48 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:48 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:48 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:48 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:48 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:48 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:48 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:48 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:48 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:48 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:48 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:48 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:48 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:48 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:48 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:48 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:48 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:48 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:48 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:48 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:48 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:48 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) Nov 12 11:17:48 warez kernel: ath_intr: status 0x1010000 Nov 12 11:17:48 warez kernel: ath_beacon_proc: pending 0 Nov 12 11:17:48 warez kernel: ath_beacon_setup: m 0xc4bf2000 len 75 Nov 12 11:17:48 warez kernel: ath_beacon_proc: TXDP[9] = 0x3e7d5000 (0xed29b000) From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 20:41:02 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD8E316A412; Sun, 12 Nov 2006 20:41:02 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1846A43D5C; Sun, 12 Nov 2006 20:41:01 +0000 (GMT) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.62) with esmtp (envelope-from ) id <1GjM8S-0001DR-2a>; Sun, 12 Nov 2006 21:41:00 +0100 Received: from e178047023.adsl.alicedsl.de ([85.178.47.23] helo=[192.168.1.128]) by inpost2.zedat.fu-berlin.de (Exim 4.62) with esmtpsa (envelope-from ) id <1GjM8S-0002rY-0B>; Sun, 12 Nov 2006 21:41:00 +0100 Message-ID: <455786DB.4020807@mail.zedat.fu-berlin.de> Date: Sun, 12 Nov 2006 21:40:59 +0100 From: "O. Hartmann" User-Agent: Thunderbird 1.5.0.8 (X11/20061110) MIME-Version: 1.0 To: Sergey Matveychuk References: <455768F3.4000407@FreeBSD.org> In-Reply-To: <455768F3.4000407@FreeBSD.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.47.23 Cc: freebsd-stable@freebsd.org Subject: Re: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:41:02 -0000 Sergey Matveychuk wrote: > Do you know an old sio driver is hardly usable? > > There are many silo overflows, working with a terminal device is a > nightmare. There was a report about one crash with a message about a > spinlock holed more than 5 seconds (there is no core dump because it has > not repeated). > > After a discussion in a Russian FIDO group I've change it on uart and > the problems gone. > > I think a default driver should be changed from sio to uart until it > will be fixed. > Had those overflows many times when I used FreeBSD 6.0-STABLE, 6.1-STABLE and a modem. But this never had a so bad influence forcing me into using uart. Regards, Oliver From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 20:43:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E89B16A407 for ; Sun, 12 Nov 2006 20:43:07 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E6443D5F for ; Sun, 12 Nov 2006 20:43:05 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anc (anb.matik.com.br [200.152.88.34] (may be forged)) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id kACKgwak026950 for ; Sun, 12 Nov 2006 17:42:58 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Sun, 12 Nov 2006 18:42:19 -0200 User-Agent: KMail/1.9.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200611121842.20173.joao@matik.com.br> X-Spam-Status: No, score=0.3 required=5.0 tests=ALL_TRUSTED,AWL, J_CHICKENPOX_35,MONOTONE_WORDS_15_2,MR_DIFF_MID autolearn=no version=3.1.3 X-Spam-Checker-Version: Antispam Datacenter Matik msrv.matik.com.br X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: ath0 issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:43:07 -0000 On Sunday 12 November 2006 17:32, Lamont Granquist wrote: > i saw the same behavior where tx packets would tend to > spool up and buffer. =A0here's the output of one second > where a bunch of spooled up packets were sent alont with > the previous second and following second and with a note > on how long it had been before any ath*tx* routine had > been called. =A0hopefully this is useful for debugging -- > i've got copious amounts of debugging logs, so let me > know if i've guessed wrongly about what is relevant... yes and when you then look at athstats you probably see the=20 tx buffer is filled up until the interface stops=20 transmitting sooner or later It seems to me that the tx buffer never becomes empty=20 anymore when the interface raised once "tx stopped because=20 out of txbuffer" until it then completly stops tx, if you=20 are present when it happens you can get it back with=20 ifconfig down/up but when you are late you need to reset it=20 or reboot. It does not matter how high you set the=20 ath.txbuf it seems the problem comes up later when setting higher=20 values for dev.ath.0.acktimeout and dev.ath.0.ctstimeout=20 but I am still testing =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 20:59:59 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2324816A40F for ; Sun, 12 Nov 2006 20:59:59 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B5C743D7D for ; Sun, 12 Nov 2006 20:59:53 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.80] ([10.0.0.80]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kACKxqFg030064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 12:59:53 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <45578B48.1090704@errno.com> Date: Sun, 12 Nov 2006 12:59:52 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Lamont Granquist References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ath0 issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:59:59 -0000 Lamont Granquist wrote: > > i did the same thing with running: > > while(1) > echo foo > sleep 1 > end > > in a window ssh'd into the machine with the ath0 driver, but with the > kernel recompiled with ATH_DEBUG and sysctl dev.ath.0.debug=0xffffffff > -- there should be packets sent every second while doing this. Not usually a good idea to enable so much debugging. The console printfs will alter operation. > > i saw the same behavior where tx packets would tend to spool up and > buffer. here's the output of one second where a bunch of spooled up > packets were sent alont with the previous second and following second > and with a note on how long it had been before any ath*tx* routine had > been called. hopefully this is useful for debugging -- i've got copious > amounts of debugging logs, so let me know if i've guessed wrongly about > what is relevant... > > this is the previous debugging notice for ath*tx* which i believe > indicates nothing > sent out on the interface since 11:17:36: If tx stops in ap mode you need to figure out whether the h/w tx q is stalled or something else "above" is blocking outbound traffic. The usual things to check are: 1. are there resources in the driver to send a packet (e.g. buffers on the queue); if the tx q is full then the OACTIVE bit will be marked on the interface and visible with ifconfig 2. if packets are queued to the h/w and not going out then you need to identify whether a higher priority frame is blocking them; this is harder but can occur when something like a beacon frame fails to go out or if there is cabq traffic q'd up behind the beacon frame that doesn't make it out 3. if none of the above is blocking traffic then h/w may consider the media busy; this can happen if your ap is operating in a busy environment and things like protection are being used heavily, or if you have an overlapping BSS that is operating in 11b Often problems such as this are most easily understood by sniffing traffic from another station and looking for traffic patterns coincident with the event on the ap. More useful information can be found in the statistics collected by the driver (use athstats). Sam From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 21:56:11 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FA0316A415 for ; Sun, 12 Nov 2006 21:56:11 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id F38DC43D90 for ; Sun, 12 Nov 2006 21:56:07 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=[192.168.0.4]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1GjNJ8-0007Fh-NB; Mon, 13 Nov 2006 00:56:06 +0300 Message-ID: <4557986B.6050900@FreeBSD.org> Date: Mon, 13 Nov 2006 00:55:55 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 1.5.0.7 (X11/20061001) MIME-Version: 1.0 To: "O. Hartmann" References: <455768F3.4000407@FreeBSD.org> <455786DB.4020807@mail.zedat.fu-berlin.de> In-Reply-To: <455786DB.4020807@mail.zedat.fu-berlin.de> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 21:56:11 -0000 O. Hartmann wrote: > Had those overflows many times when I used FreeBSD 6.0-STABLE, > 6.1-STABLE and a modem. > But this never had a so bad influence forcing me into using uart. I tried to configure cisco router plugged in a serial port. It was very uncomfortable. It hangs for a few tens seconds after every a few minutes. -- Dixi. Sem. From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 20:26:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B169A16A4C2 for ; Sun, 12 Nov 2006 20:26:44 +0000 (UTC) (envelope-from bab@acciodata.com) Received: from smtpout10-04.prod.mesa1.secureserver.net (smtpout10-04.prod.mesa1.secureserver.net [64.202.165.238]) by mx1.FreeBSD.org (Postfix) with SMTP id D14CC43D68 for ; Sun, 12 Nov 2006 20:26:39 +0000 (GMT) (envelope-from bab@acciodata.com) Received: (qmail 7769 invoked from network); 12 Nov 2006 20:26:39 -0000 Received: from unknown (66.68.10.54) by smtpout10-04.prod.mesa1.secureserver.net (64.202.165.238) with ESMTP; 12 Nov 2006 20:26:38 -0000 Received: from bravo.acciodata.com (bab@localhost [127.0.0.1]) by bravo.acciodata.com (8.13.8/8.13.6) with ESMTP id kACKQbUc053646; Sun, 12 Nov 2006 14:26:37 -0600 (CST) (envelope-from bab@bravo.acciodata.com) Received: (from bab@localhost) by bravo.acciodata.com (8.13.6/8.13.4/Submit) id kACKQai4053643; Sun, 12 Nov 2006 14:26:36 -0600 (CST) (envelope-from bab) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17751.33660.897403.267059@gargle.gargle.HOWL> Date: Sun, 12 Nov 2006 14:26:36 -0600 To: "Jack Vogel" In-Reply-To: <2a41acea0611101447j29acdc3k820276de92204735@mail.gmail.com> References: <17748.37662.708865.764722@gargle.gargle.HOWL> <20061110150840.GK32700@cell.sick.ru> <17748.53164.372871.270153@gargle.gargle.HOWL> <17748.64782.579350.492909@gargle.gargle.HOWL> <2a41acea0611101447j29acdc3k820276de92204735@mail.gmail.com> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid From: Barry Boes X-Mailman-Approved-At: Sun, 12 Nov 2006 22:10:24 +0000 Cc: RelEng , John Baldwin , freebsd-net , Barry Boes , Gleb Smirnoff , Prafulla Deuskar , jfv@freebsd.org, freebsd-stable@freebsd.org Subject: Re: EM stability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Barry Boes List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:26:44 -0000 After the last hang I added giant locks back in and the machine has been up since. I don't have a serial console, just a graphic console. When the machine hangs it stops replying to ethernet packets at all protocol levels and doesn't respond to keyboard input in any way, virtual console or otherwise. If I run a script of the form while(1) sleep 1 date >> datelog end the file stops updating when the machine hangs. I will define the debugger in the kernel (options DDB, right?), attach a serial console, and do what I can to get more information on the problem. -Barry Jack Vogel writes: > On 11/10/06, Barry Boes wrote: > > > > Luck ran out. Hard "must press the reset button" hang. No console > > messages. The system was idle at the time. > > Is there anything you'd like me to do to attempt to narrow down the > > problem or get debugging output? I do not know if the freeze was > > related to em or something else. > > Is this a machine running some graphic head? If not can you see anything > on the console? Are you sure the machine is dead, like can you get in > over the network... ? One thing I often do when you are dealing with > unpredictable hangs is run 'vmstat 3' on one of the virtual terminals. > > You might also define the kernel debugger into your kernel, its best to have > a serial console for this, I've seen the hardware console be locked but the > serial will still work. > > The only way we will track this down is thru repetitive reproduction I'm > afraid. > > Jack From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 22:40:14 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E00FE16A412 for ; Sun, 12 Nov 2006 22:40:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.FreeBSD.org (Postfix) with SMTP id 4986C43D46 for ; Sun, 12 Nov 2006 22:40:14 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 22084 invoked by uid 399); 12 Nov 2006 22:40:13 -0000 Received: from localhost (HELO ?192.168.0.7?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 12 Nov 2006 22:40:13 -0000 Message-ID: <4557A2C7.5020802@FreeBSD.org> Date: Sun, 12 Nov 2006 14:40:07 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061111) MIME-Version: 1.0 To: "Todorov @ Paladin" References: <45576C8D.5080809@paladin.bulgarpress.com> In-Reply-To: <45576C8D.5080809@paladin.bulgarpress.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: Migration 5.3{4} to 6.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 22:40:15 -0000 Todorov @ Paladin wrote: > Hi group, > > what is your opinion - will there be directly supported way to upgrade > from source 5.3 & 5.4 to upcomming 6.2 ? The "officially supported" way is always to do a backup then clean reinstall. That said, it's been reported on the list several times that source upgrades work from 5.x to 6.x, and are fairly painless. Your best bet would be to first upgrade to the latest code in RELENG_5, then upgrade to RELENG_6, but you can try it without that step first if you're adventurous. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 23:02:51 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0615B16A403 for ; Sun, 12 Nov 2006 23:02:51 +0000 (UTC) (envelope-from steve@stevenwills.com) Received: from stevenwills.com (cpe-024-163-080-004.nc.res.rr.com [24.163.80.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3E5043D7E for ; Sun, 12 Nov 2006 23:02:44 +0000 (GMT) (envelope-from steve@stevenwills.com) Received: from [192.168.0.182] ([192.168.0.182]) (authenticated bits=0) by stevenwills.com (8.13.1/8.13.1) with ESMTP id kACN2hu9094046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 12 Nov 2006 18:02:43 -0500 (EST) (envelope-from steve@stevenwills.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <9ABCABF7-2D44-496D-84A2-4C3CA4527355@stevenwills.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-stable@freebsd.org From: Steve Wills Date: Sun, 12 Nov 2006 18:02:42 -0500 X-Mailer: Apple Mail (2.752.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (stevenwills.com [24.163.80.4]); Sun, 12 Nov 2006 18:02:43 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.4/2188/Sun Nov 12 15:32:01 2006 on tigger.example.com X-Virus-Status: Clean Subject: audit and quota don't get along X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:02:51 -0000 I thought I'd try out the new audit support in 6.2-PRE and discovered that having quota enabled causes: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0695278 stack pointer = 0x28:0xce19ac34 frame pointer = 0x28:0xce19ac3c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 564 (auditd) trap number = 12 panic: page fault when trying to start auditd. I can provide backtrace, but it seems pretty reproducible. Steve From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 23:12:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A07A16A403 for ; Sun, 12 Nov 2006 23:12:54 +0000 (UTC) (envelope-from lamont@scriptkiddie.org) Received: from sploit.scriptkiddie.org (sploit.scriptkiddie.org [216.231.47.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id D86E143DD3 for ; Sun, 12 Nov 2006 23:12:26 +0000 (GMT) (envelope-from lamont@scriptkiddie.org) Received: from sploit (sploit [216.231.47.214]) by sploit.scriptkiddie.org (8.12.11/8.12.11) with ESMTP id kACNCKCm029838; Sun, 12 Nov 2006 15:12:20 -0800 (PST) Date: Sun, 12 Nov 2006 15:12:20 -0800 (PST) From: Lamont Granquist To: Sam Leffler In-Reply-To: <45578B48.1090704@errno.com> Message-ID: References: <45578B48.1090704@errno.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: ath0 issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 23:12:54 -0000 On Sun, 12 Nov 2006, Sam Leffler wrote: > If tx stops in ap mode you need to figure out whether the h/w tx q is > stalled or something else "above" is blocking outbound traffic. The > usual things to check are: > > 1. are there resources in the driver to send a packet (e.g. buffers on > the queue); if the tx q is full then the OACTIVE bit will be marked on > the interface and visible with ifconfig during one of the period where tx was blocking i got ifconfigs that looked like: ath0: flags=8843 mtu 1500 inet 192.168.70.1 netmask 0xffffff00 broadcast 192.168.70.255 ether 00:09:5b:c8:78:9c media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c authmode OPEN privacy OFF txpowmax 30 bmiss 7 protmode CTS burst dtimperiod 1 bintval 100 ath0: flags=8843 mtu 1500 inet 192.168.70.1 netmask 0xffffff00 broadcast 192.168.70.255 ether 00:09:5b:c8:78:9c media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c authmode OPEN privacy OFF txpowmax 30 bmiss 7 protmode CTS burst dtimperiod 1 bintval 100 > 2. if packets are queued to the h/w and not going out then you need to > identify whether a higher priority frame is blocking them; this is > harder but can occur when something like a beacon frame fails to go out > or if there is cabq traffic q'd up behind the beacon frame that doesn't > make it out > 3. if none of the above is blocking traffic then h/w may consider the > media busy; this can happen if your ap is operating in a busy > environment and things like protection are being used heavily, or if you > have an overlapping BSS that is operating in 11b i'm not certain how to go about collecting that information, but this is a very lightly used wireless network with only the freebsd box and the windows machine participating and the traffic is limited to the ssh sessions that i setup and the usual windoze and dhcp chatter... > Often problems such as this are most easily understood by sniffing > traffic from another station and looking for traffic patterns coincident > with the event on the ap. i've only got the two wireless points right now, so i can't get a third machine up to sniff... > More useful information can be found in the > statistics collected by the driver (use athstats). here's a before and after of athstats which brackets one of these events: warez# ./athstats 2243 data frames received 2925 data frames transmit 50 tx frames with an alternate rate 947 long on-chip tx retries 115 tx failed 'cuz too many retries 2M current transmit rate 982 tx management frames 6 tx frames discarded prior to association 242 tx frames with no ack marked 2828 tx frames with short preamble 2439 rx failed 'cuz of bad CRC 28137 rx failed 'cuz of PHY err 19620 OFDM timing 8517 CCK timing 150622 beacons transmitted 534 periodic calibrations 16 rssi of last ack 19 avg recv rssi -96 rx noise floor 1 cabq frames transmitted 33 switched default/rx antenna Antenna profile: [1] tx 1862 rx 6345 [2] tx 1927 rx 6371 warez# ./athstats 2252 data frames received 2937 data frames transmit 50 tx frames with an alternate rate 947 long on-chip tx retries 115 tx failed 'cuz too many retries 2M current transmit rate 982 tx management frames 6 tx frames discarded prior to association 242 tx frames with no ack marked 2840 tx frames with short preamble 2440 rx failed 'cuz of bad CRC 28145 rx failed 'cuz of PHY err 19623 OFDM timing 8522 CCK timing 150659 beacons transmitted 535 periodic calibrations 22 rssi of last ack 22 avg recv rssi -96 rx noise floor 1 cabq frames transmitted 33 switched default/rx antenna Antenna profile: [1] tx 1874 rx 6371 [2] tx 1927 rx 6371 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 00:40:59 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3355B16A492; Mon, 13 Nov 2006 00:40:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69EC743D6E; Mon, 13 Nov 2006 00:40:57 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAD0euPP019886; Sun, 12 Nov 2006 19:40:56 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAD0etbp040637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 19:40:55 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611130040.kAD0etbp040637@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Nov 2006 19:40:45 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <45574ECA.4080207@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 00:40:59 -0000 At 11:41 AM 11/12/2006, Scott Long wrote: >Mike Tancsa wrote: >>At 01:42 AM 11/11/2006, Scott Long wrote: >>driver. What will help me is if you can hook up a serial console to >>>your machine and see if it can be made to drop to the debugger while it >>>is under load and otherwise unresponsive. If you can, getting a process >>>dump might help confirm where each CPU is spending its time. >> >>./netblast 192.168.88.218 500 110 1000 >>I compiled in the various debugging options and on the serial >>console I get a few >>Expensive timeout(9) function: 0xc0601e48(0) 0.024135749 s >>and the serial console > >One CPU seems to be stuck in softclock. My guess here is that there >is significant lock contention. Please try the following: > >1. Use addr2line or gdb on the kernel to find out what function is at >0xc0601e48 (the address that was printed above). This address will >change every time you recompile the kernel, so you'll need to reacquire >it from the console each time. # addr2line 0xc0601e48 -e kernel.debug -f nfsrv_timer /usr/src/sys/nfsserver/nfs_srvsock.c:809 # and # addr2line 0xc0561444 -e kernel.debug -f sleepq_timeout /usr/src/sys/kern/subr_sleepqueue.c:724 I dont have any nfs activity on the box >2. Try compiling in WITNESS and running the test as before, then break >into the debugger as before. Run 'show locks'. I'm not sure how >fruitful this will be, WITNESS might make it unbearably slow. It was in that kernel already All it would generally show is exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 But I did notice in /var/log/kernel Nov 12 00:04:09 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 Nov 12 00:04:09 R2 kernel: exclusive sleep mutex em1 (network driver) r = 0 (0xc64bc9d4) locked @ /usr/src/sys/dev/ em/if_em.c:3569 Nov 12 00:04:09 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 Nov 12 19:27:39 R2 kernel: KDB: enter: Line break on console Nov 12 19:27:39 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 Nov 12 19:28:13 R2 kernel: KDB: enter: Line break on console Nov 12 19:28:13 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 Nov 12 19:31:37 R2 kernel: KDB: enter: Line break on console Nov 12 19:31:37 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 Nov 12 19:34:22 R2 kernel: KDB: enter: Line break on console Nov 12 19:34:22 R2 kernel: exclusive spin mutex sio r = 0 (0xc07c81c0) locked @ /usr/src/sys/dev/sio/sio.c:1390 >3. Turn on MUTEX_PROFILING according to the text in /sys/conf/NOTES and >the man page by the same name. >4. Remove ADAPTIVE_GIANT from your config and retest. If that doesn't >show a difference, then try setting NO_ADAPTIVE_MUTEXES. OK, did this recompiling without WITNESS and INVARIANTS and took out ADAPTIVE_GIANT as instructed in the man pages # sysctl -a | grep mutex debug.mutex.prof.enable: 1 debug.mutex.prof.acquisitions: 584672946 debug.mutex.prof.records: 450 debug.mutex.prof.maxrecords: 1000 debug.mutex.prof.rejected: 0 debug.mutex.prof.hashsize: 1009 debug.mutex.prof.collisions: 75 debug.mutex.prof.stats: 10 1263 226 5 0 0 /usr/src/sys/kern/sys_pipe.c:1345 (pipe mutex) 3 682 369 1 13 6908 /usr/src/sys/vm/vm_fault.c:851 (vm page queue mutex) 10 2256 623 3 23 15 /usr/src/sys/i386/i386/pmap.c:1891 (vm page queue mutex) 120 883 401 2 15 26 /usr/src/sys/vm/vm_fault.c:909 (vm page queue mutex) 25 25 1 25 0 0 /usr/src/sys/i386/i386/pmap.c:2572 (vm page queue mutex) 19 169 33 5 1 1 /usr/src/sys/vm/vm_object.c:1801 (vm page queue mutex) 4 24 9 2 0 0 /usr/src/sys/vm/vm_object.c:646 (vm page queue mutex) 3 23 8 2 1 1 /usr/src/sys/kern/vfs_bio.c:3384 (vm page queue mutex) 2 12 6 2 0 0 /usr/src/sys/vm/vm_pageout.c:1511 (vm page queue mutex) 4 120 44 2 0 0 /usr/src/sys/kern/vfs_bio.c:3315 (vm page queue mutex) 3 100 44 2 0 0 /usr/src/sys/kern/vfs_bio.c:3120 (vm page queue mutex) 3 9 4 2 0 0 /usr/src/sys/kern/vfs_bio.c:3577 (vm page queue mutex) 1 1 1 1 0 4 /usr/src/sys/kern/sys_pipe.c:1270 (pipe mutex) 2 16 8 2 0 0 /usr/src/sys/vm/vm_page.c:1481 (vm page queue mutex) 2 8 4 2 0 0 /usr/src/sys/kern/kern_exec.c:871 (vm page queue mutex) 145 713 14 50 5 4 /usr/src/sys/vm/vm_map.c:1504 (vm page queue mutex) 2 7 4 1 0 0 /usr/src/sys/vm/vm_glue.c:273 (vm page queue mutex) 2 8 4 2 0 0 /usr/src/sys/vm/vm_glue.c:309 (vm page queue mutex) 2 8 4 2 0 0 /usr/src/sys/kern/kern_exec.c:893 (vm page queue mutex) 36 357 42 8 2 1 /usr/src/sys/i386/i386/pmap.c:1624 (vm page queue mutex) 5 152 64 2 2 2 /usr/src/sys/vm/vm_fault.c:346 (vm page queue mutex) 2 61 24 2 2 1 /usr/src/sys/vm/vm_fault.c:136 (vm page queue mutex) 5 48 10 4 0 2 /usr/src/sys/i386/i386/pmap.c:1782 (vm page queue mutex) 11 1451 193 7 24 13 /usr/src/sys/vm/vm_fault.c:1009 (vm page queue mutex) 3 3868 1692 2 8 4 /usr/src/sys/kern/sys_pipe.c:993 (pipe mutex) 6 4681 1692 2 46 6 /usr/src/sys/kern/sys_pipe.c:1145 (pipe mutex) 2 643 372 1 0 0 /usr/src/sys/vm/vm_fault.c:1092 (vm page queue mutex) 3 3235 1648 1 5 44 /usr/src/sys/kern/sys_pipe.c:591 (pipe mutex) 5 4235 1647 2 2 2 /usr/src/sys/kern/sys_pipe.c:628 (pipe mutex) 1 331 222 1 0 0 /usr/src/sys/vm/vm_kern.c:367 (vm page queue mutex) 2 337 222 1 0 0 /usr/src/sys/vm/vm_kern.c:404 (vm page queue mutex) debug.mutex.prof.reset: 0 >Thanks, > >Scott From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 01:48:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EE7416A415; Mon, 13 Nov 2006 01:48:07 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5679543D5E; Mon, 13 Nov 2006 01:48:05 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAD1lxBT071427; Sun, 12 Nov 2006 18:48:04 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4557CECD.2000609@samsco.org> Date: Sun, 12 Nov 2006 18:47:57 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> In-Reply-To: <200611130040.kAD0etbp040637@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 01:48:07 -0000 Mike Tancsa wrote: > At 11:41 AM 11/12/2006, Scott Long wrote: >> Mike Tancsa wrote: >>> At 01:42 AM 11/11/2006, Scott Long wrote: >>> driver. What will help me is if you can hook up a serial console to >>>> your machine and see if it can be made to drop to the debugger while it >>>> is under load and otherwise unresponsive. If you can, getting a >>>> process >>>> dump might help confirm where each CPU is spending its time. >>> >>> ./netblast 192.168.88.218 500 110 1000 >>> I compiled in the various debugging options and on the serial console >>> I get a few >>> Expensive timeout(9) function: 0xc0601e48(0) 0.024135749 s >>> and the serial console >> >> One CPU seems to be stuck in softclock. My guess here is that there >> is significant lock contention. Please try the following: >> >> 1. Use addr2line or gdb on the kernel to find out what function is at >> 0xc0601e48 (the address that was printed above). This address will >> change every time you recompile the kernel, so you'll need to reacquire >> it from the console each time. > > # addr2line 0xc0601e48 -e kernel.debug -f > nfsrv_timer > /usr/src/sys/nfsserver/nfs_srvsock.c:809 > # > Can you try removing NFS from your kernel? > and > > # addr2line 0xc0561444 -e kernel.debug -f > sleepq_timeout > /usr/src/sys/kern/subr_sleepqueue.c:724 This is sched_lock contention. > > I dont have any nfs activity on the box > >> 2. Try compiling in WITNESS and running the test as before, then break >> into the debugger as before. Run 'show locks'. I'm not sure how >> fruitful this will be, WITNESS might make it unbearably slow. > > It was in that kernel already So you're seeing the livelock under load while also having WITNESS enabled? Have you tried your test without WITNESS? What about INVARIANTS? Scott From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 01:51:00 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76BB416A415 for ; Mon, 13 Nov 2006 01:51:00 +0000 (UTC) (envelope-from wildefire@brotay.net) Received: from mail.brotay.net (DS1070.servadmin.com [12.158.190.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1736243D5C for ; Mon, 13 Nov 2006 01:50:58 +0000 (GMT) (envelope-from wildefire@brotay.net) Received: from [192.168.16.150] (cpe-24-162-25-102.houston.res.rr.com [24.162.25.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.brotay.net (Postfix) with ESMTP id 8ACD260D9 for ; Sun, 12 Nov 2006 19:50:57 -0600 (CST) Message-ID: <4557CF80.4080503@brotay.net> Date: Sun, 12 Nov 2006 19:50:56 -0600 From: Brock Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: stable@freebsd.org References: <6eb82e0611050847i54d16638x89c428c9dffcc106@mail.gmail.com> In-Reply-To: <6eb82e0611050847i54d16638x89c428c9dffcc106@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------010406030009060001000005" Cc: Subject: Re: panic when portupgrade in jail (devfs related?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 01:51:00 -0000 This is a multi-part message in MIME format. --------------010406030009060001000005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I'm seeing this crash too. Trying to build pfSense while chrooted following the directions at http://wiki.pfsense.com/wikka.php?wakka=BuildingpFSense I've got a dump and can reproduce this fairly reliably by running the build_embedded script. (1 in ~3 tries does it). I'll try to come up with a script that can reproduce it faster. Backtrace follows: Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 01 fault virtual address = 0x3b3057d8 fault code = supervisor read, page not present instruction pointer = 0x20:0xc059b250 stack pointer = 0x28:0xf1315a94 frame pointer = 0x28:0xf1315aa0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 24988 (script) Dumping 1023 MB (3 chunks) chunk 0: 1MB (158 pages) ... ok chunk 1: 1022MB (261616 pages) 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 ... ok chunk 2: 1MB (128 pages) #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04573c9 in db_fncall (dummy1=0, dummy2=0, dummy3=1999, dummy4=0xf131589c "") at /usr/src/sys/ddb/db_command.c:492 #2 0xc0457142 in db_command (last_cmdp=0xc07b1cc4, cmd_table=0x0, aux_cmd_tablep=0xc0774d84, aux_cmd_tablep_end=0xc0774d88) at /usr/src/sys/ddb/db_command.c:350 #3 0xc045724a in db_command_loop () at /usr/src/sys/ddb/db_command.c:458 #4 0xc045930a in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #5 0xc057af8e in kdb_trap (type=0, code=0, tf=0xf1315a54) at /usr/src/sys/kern/subr_kdb.c:473 #6 0xc070d64b in trap_fatal (frame=0xf1315a54, eva=0) at /usr/src/sys/i386/i386/trap.c:828 #7 0xc070d337 in trap_pfault (frame=0xf1315a54, usermode=0, eva=993023960) at /usr/src/sys/i386/i386/trap.c:745 #8 0xc070cf1d in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -991068160, tf_esi = -981443664, tf_ebp = -248423776, tf_isp = -248423808, tf_ebx = -991536128, tf_edx = -987051008, tf_ecx = -1065648064, tf_eax = -559038242, tf_trapno = 12, tf_err = 0, tf_eip = -1067863472, tf_cs = 32, tf_eflags = 66178, tf_esp = 6, tf_ss = -986671872}) at /usr/src/sys/i386/i386/trap.c:435 #9 0xc06f667a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #10 0xc059b250 in ptcclose (dev=0xdeadc0de, flags=3, fmt=8192, td=0xc4ed8000) at linedisc.h:136 #11 0xc052e44f in giant_close (dev=0xc5309500, fflag=-559038242, devtype=-559038242, td=0xdeadc0de) at /usr/src/sys/kern/kern_conf.c:284 #12 0xc04f6919 in devfs_close (ap=0xf1315b44) at /usr/src/sys/fs/devfs/devfs_vnops.c:357 #13 0xc07220be in VOP_CLOSE_APV (vop=0xdeadc0de, a=0xf1315b44) at vnode_if.c:426 #14 0xc05d112c in vn_close (vp=0xc5805bb0, flags=3, file_cred=0xdeadc0de, td=0xc4ed8000) at vnode_if.h:227 #15 0xc05d2189 in vn_closefile (fp=0xc5bd0d80, td=0xdeadc0de) at /usr/src/sys/kern/vfs_vnops.c:867 #16 0xc04f6979 in devfs_close_f (fp=0xdeadc0de, td=0xdeadc0de) at /usr/src/sys/fs/devfs/devfs_vnops.c:369 #17 0xc053931e in fdrop_locked (fp=0xc5bd0d80, td=0xdeadc0de) at file.h:295 #18 0xc053924c in fdrop (fp=0xc5bd0d80, td=0xdeadc0de) at /usr/src/sys/kern/kern_descrip.c:2134 #19 0xc0537747 in closef (fp=0xc5bd0d80, td=0xc4ed8000) at /usr/src/sys/kern/kern_descrip.c:1954 #20 0xc053460e in close (td=0xc4ed8000, uap=0xdeadc0de) at /usr/src/sys/kern/kern_descrip.c:1012 #21 0xc070d9d2 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 1, tf_esi = 0, tf_ebp = -1077944904, tf_isp = -248423068, tf_ebx = -1077944872, tf_edx = 672570784, tf_ecx = 0, tf_eax = 6, tf_trapno = 12, tf_err = 2, tf_eip = 672420611, tf_cs = 51, tf_eflags = 582, tf_esp = -1077944932, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 #22 0xc06f66cf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #23 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) My system's RELENG_6 as of Nov. 4th around 7:30 CST. dmesg.boot/kernel config/kldstat attached. --------------010406030009060001000005 Content-Type: text/plain; name="SARCASM" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="SARCASM" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.441 2006/04/10 20:04:22 ps Exp $ machine i386 cpu I686_CPU ident SARCASM # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols #options SCHED_ULE # ULE scheduler options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options GEOM_MIRROR # Gmirror options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device ataraid # ATA RAID drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device mpt # LSI-Logic MPT-Fusion device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device uscanner # Scanners # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) --------------010406030009060001000005 Content-Type: text/plain; name="dmesg.boot" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.boot" Copyright (c) 1992-2006 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 6.2-PRERELEASE #0: Sat Nov 4 19:47:37 CST 2006 root@sarcasm.brotay.net:/usr/obj/usr/src/sys/SARCASM ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1200.05-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc0480800 real memory = 1073217536 (1023 MB) avail memory = 1041010688 (992 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff,0x8000-0x807f,0x8080-0x80ff iomem 0xd8000-0xdbfff on acpi0 pci0: on pcib0 agp0: port 0x1410-0x1413 mem 0xea000000-0xebffffff,0xe9b00000-0xe9b00fff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 7.3 (no driver attached) pcib2: at device 8.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 amr0: mem 0xf0000000-0xf7ffffff irq 20 at device 0.0 on pci3 amr0: Firmware G170, BIOS F316, 128MB RAM pci2: at device 1.0 (no driver attached) mpt0: port 0x1000-0x10ff mem 0xe8020000-0xe803ffff,0xe8000000-0xe800ffff irq 21 at device 9.0 on pci0 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.0.0.0 mpt0: mpt_read_cfg_page: Config Info Status 20 mpt0: failed to read FC page 1 mpt0: WARN: mpt_intr index == 65535 (reply_desc == 0x9f4c4380) mpt0: mpt_wait_req(14) timed out mpt0: personality mpt_cam attached but would not enable (5) pcib4: at device 16.0 on pci0 pci4: on pcib4 ohci0: mem 0xe8220000-0xe8220fff irq 19 at device 0.0 on pci4 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib5: at device 4.0 on pci4 pci5: on pcib5 dc0: port 0x4000-0x407f mem 0xe9800000-0xe98003ff irq 16 at device 4.0 on pci5 miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:c0:95:e2:33:d0 dc1: port 0x4080-0x40ff mem 0xe9800400-0xe98007ff irq 17 at device 5.0 on pci5 miibus1: on dc1 dcphy1: on miibus1 dcphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: Ethernet address: 00:c0:95:e2:33:d1 sym0: <875> port 0x3000-0x30ff mem 0xe8223800-0xe82238ff,0xe8221000-0xe8221fff irq 17 at device 5.0 on pci4 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: [GIANT-LOCKED] sym1: <875> port 0x3400-0x34ff mem 0xe8223c00-0xe8223cff,0xe8222000-0xe8222fff irq 18 at device 5.1 on pci4 sym1: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: [GIANT-LOCKED] pci4: at device 6.0 (no driver attached) fwohci0: port 0x3800-0x387f mem 0xe8223000-0xe82237ff irq 19 at device 7.0 on pci4 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:50:22:66:00:22:33:a3 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x3880-0x38ff mem 0xe8224000-0xe822407f irq 19 at device 8.0 on pci4 miibus2: on xl0 ukphy0: on miibus2 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:e0:81:29:3d:9b atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: PRINTER MLC,MFPDTF1,PCL,PJL lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff,0xca000-0xcd7ff,0xe0000-0xe3fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 umass0: Lexar Media CF READER ?, rev 1.00/0.01, addr 2 Timecounters tick every 1.000 msec acd0: CDRW at ata1-master PIO4 Waiting 5 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. amrd0: on amr0 amrd0: 350030MB (716861440 sectors) RAID 5 (optimal) da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) SMP: AP CPU #1 Launched! da2 at umass-sim0 bus 0 target 0 lun 0 da2: Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: 122MB (250368 512 byte sectors: 64H 32S/T 122C) GEOM_MIRROR: Device sys0 created (id=3225984353). GEOM_MIRROR: Device sys0: provider da0s1 detected. GEOM_MIRROR: Device sys0: provider da1s1 detected. GEOM_MIRROR: Device sys0: provider da1s1 activated. GEOM_MIRROR: Device sys0: provider da0s1 activated. GEOM_MIRROR: Device sys0: provider mirror/sys0 launched. Trying to mount root from ufs:/dev/mirror/sys0a --------------010406030009060001000005 Content-Type: text/plain; name="kldstat" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kldstat" Id Refs Address Size Name 1 4 0xc0400000 4884f8 kernel 2 1 0xc0889000 b43c amr.ko 3 1 0xc0895000 65f9c acpi.ko --------------010406030009060001000005-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 01:58:41 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FF6A16A403; Mon, 13 Nov 2006 01:58:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3D9E43D5E; Mon, 13 Nov 2006 01:58:40 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAD1wdnL060097; Sun, 12 Nov 2006 20:58:40 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAD1wdKE040908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 20:58:39 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611130158.kAD1wdKE040908@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Nov 2006 20:58:49 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <4557CECD.2000609@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 01:58:41 -0000 At 08:47 PM 11/12/2006, Scott Long wrote: >>>2. Try compiling in WITNESS and running the test as before, then break >>>into the debugger as before. Run 'show locks'. I'm not sure how >>>fruitful this will be, WITNESS might make it unbearably slow. >>It was in that kernel already > >So you're seeing the livelock under load while also having WITNESS >enabled? Have you tried your test without WITNESS? What about INVARIANTS? Sorry, by it was in the kernel already, it was from last nights tests where you asked me to break into the debugger to see what was going on. I figured you would want it in there. My original tests were all without WITNESS and INVARIANTS and they were showing the same behaviour (locking up on the management interface) with and without WITNESS and INVARIANTS Removing ADAPTIVE_GIANT seems to be very key in this! If I remove it, the box no longer locks up under a high packet rate! Its still a little sluggish on the bge OOB interface, but its not totally locking up like before Running ifstat -b from the management interface, here is the traffic pattern first with one blast running and then the second kicks in. The Kbps/s out on em1 drops in half, but the box is still responsive and bge1... Certainly responsive enough to see the output of ifstat. 218028.4 0.00 0.00 216389.9 0.47 1.17 218971.2 0.00 0.00 217123.1 0.94 2.34 217754.7 0.00 0.00 215677.2 0.94 1.17 215763.1 0.00 0.00 214578.5 0.47 1.17 217850.3 0.00 0.00 216138.7 1.40 2.34 217668.0 0.00 0.00 215888.3 0.47 1.17 em0 em1 bge1 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 217382.3 0.00 0.00 216293.8 1.26 1.59 218247.9 118916.5 234167.3 124972.1 0.47 2.17 215973.4 220459.9 393350.0 54875.64 1.40 2.34 217697.7 210984.5 398543.3 58165.20 0.94 3.09 217183.6 200424.9 399096.5 61845.74 0.94 1.17 217788.7 221212.9 400129.8 53716.38 0.47 1.17 217040.0 204934.2 396628.7 61247.34 1.40 2.34 217105.9 201295.5 399274.1 61710.76 0.94 3.09 215605.6 225012.4 397533.5 53237.31 0.94 1.17 217933.3 200346.4 395949.3 62734.52 0.47 1.17 216783.7 205114.1 395923.0 61042.17 0.94 1.17 217885.7 88513.41 159056.4 151418.9 0.47 1.17 216927.2 0.00 0.00 215450.4 0.94 1.17 217454.1 0.00 0.00 215466.6 0.47 1.17 216810.6 0.00 0.00 215564.2 1.40 1.17 217608.3 0.00 0.00 216061.8 0.47 1.17 217452.8 0.00 0.00 215627.1 0.94 1.17 217185.0 0.00 0.00 216079.7 0.47 1.17 However, if I turn on fastforwarding, its back to the old behavior with it locking up. This was with the stock driver. I will try the same test with #define EM_FAST_INTR 1 as well as taking out the nfs option from the kernel driver. Anything else to tune with ? ---Mike >Scott From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 03:56:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9566C16A412 for ; Mon, 13 Nov 2006 03:56:36 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADDC143D49 for ; Mon, 13 Nov 2006 03:56:35 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by nf-out-0910.google.com with SMTP id l23so335920nfc for ; Sun, 12 Nov 2006 19:56:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IiT6g+EA/wT+qHEXysrQ5qfetPya0qWQFF2KWl77zTUkrfOADnv7pf8AEfmu9L6VMbTEUa7AJlDlrcAxt4kwIWv7BusDbvI+pDOVmhlcZG9t/c8Gxelp2N2d4LQLNUSRdgAmGyEaFTkpBt0NRF1SV00rmB6zH6qql0Oz+krKRAM= Received: by 10.78.69.7 with SMTP id r7mr5701956hua.1163390194234; Sun, 12 Nov 2006 19:56:34 -0800 (PST) Received: by 10.78.199.15 with HTTP; Sun, 12 Nov 2006 19:56:34 -0800 (PST) Message-ID: <7579f7fb0611121956n4bf77bc2g7443e7390923bb03@mail.gmail.com> Date: Sun, 12 Nov 2006 19:56:34 -0800 From: "Matthew Jacob" To: "Sergey Matveychuk" In-Reply-To: <455768F3.4000407@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455768F3.4000407@FreeBSD.org> Cc: freebsd-stable@freebsd.org Subject: Re: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 03:56:36 -0000 YMMV and your message is content free. I use sio all the time as a console@115200 w/o any problems. On 11/12/06, Sergey Matveychuk wrote: > Do you know an old sio driver is hardly usable? > > There are many silo overflows, working with a terminal device is a > nightmare. There was a report about one crash with a message about a > spinlock holed more than 5 seconds (there is no core dump because it has > not repeated). > > After a discussion in a Russian FIDO group I've change it on uart and > the problems gone. > > I think a default driver should be changed from sio to uart until it > will be fixed. > -- > Dixi. > Sem. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 04:05:48 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45D5216A500; Mon, 13 Nov 2006 04:05:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B36DB43D45; Mon, 13 Nov 2006 04:05:47 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAD45eMI072024; Sun, 12 Nov 2006 21:05:46 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4557EF13.9060305@samsco.org> Date: Sun, 12 Nov 2006 21:05:39 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> In-Reply-To: <200611130158.kAD1wdKE040908@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 04:05:48 -0000 Mike Tancsa wrote: > However, if I turn on fastforwarding, its back to the old behavior with > it locking up. This was with the stock driver. I will try the same test > with > > #define EM_FAST_INTR 1 > > as well as taking out the nfs option from the kernel driver. Anything > else to tune with ? > > ---Mike > Would you mind going so far as to adding NO_ADAPTIVE_MUTEXES? This is excellent data, thanks a lot for working on it. Scott From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 04:54:59 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 976AC16A407; Mon, 13 Nov 2006 04:54:59 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E50E43D49; Mon, 13 Nov 2006 04:54:41 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kAD4saZk039190; Sun, 12 Nov 2006 23:54:36 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAD4sZwe041556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 23:54:35 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611130454.kAD4sZwe041556@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Nov 2006 23:54:37 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <4557EF13.9060305@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 04:54:59 -0000 At 11:05 PM 11/12/2006, Scott Long wrote: >Mike Tancsa wrote: >>However, if I turn on fastforwarding, its back to the old behavior >>with it locking up. This was with the stock driver. I will try the >>same test with >>#define EM_FAST_INTR 1 >>as well as taking out the nfs option from the kernel >>driver. Anything else to tune with ? >> ---Mike > >Would you mind going so far as to adding NO_ADAPTIVE_MUTEXES? This is Wow, it totally survives 2 streams (2 in one direction or 2 in opposite directions)... AND it almost can survive a 3rd! It does seem to be dropping packets on em1 when I add in a second stream blasting in the same direction, but its survives. You can see at ** I add in the second stream, and the outbound on em1 drops, even though more packets are going through. I stop the second stream then add a stream going in the other direction. Oddly enough, with a UP kernel it cant do 2 streams, just the one. I thought the extra locking on SMP would make it worse ? In this case it seems no. em0 em1 bge1 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 0.00 0.00 0.00 0.00 0.47 1.17 0.00 0.00 0.00 0.00 0.47 1.17 0.00 0.00 0.00 0.00 0.94 1.17 184837.3 0.00 0.00 184634.5 0.47 1.17 416856.2 0.00 0.00 416232.3 0.94 1.17 414080.2 0.00 0.00 413829.7 0.47 1.17 415656.3 0.00 0.00 415449.1 1.40 1.17 413015.0 0.00 0.00 412519.6 0.94 1.17 415094.8 0.00 0.00 414795.6 1.87 1.17 415548.6 0.00 0.00 415323.7 0.47 1.17 416629.6 0.00 0.00 416046.7 1.40 1.17 417032.5 0.00 0.00 416854.1 0.47 1.17 416606.9 0.00 0.00 416217.9 0.94 1.17 591084.4 0.00 0.00 307308.9 0.47 1.17** 692232.6 0.00 0.00 248915.3 1.41 2.34 692837.6 0.00 0.00 248765.0 0.47 1.17 690216.7 0.00 0.00 245400.2 1.26 1.59 697517.9 0.00 0.00 245689.7 0.94 2.34 697039.0 0.00 0.00 245553.8 1.40 3.09 697424.1 0.00 0.00 244360.9 0.47 1.17 692166.5 0.00 0.00 245316.4 0.94 1.17 697102.3 0.00 0.00 244969.0 0.47 1.17 560005.0 0.00 0.00 329704.8 0.94 3.09 405189.2 0.00 0.00 404969.8 0.94 1.17 417511.0 0.00 0.00 416902.5 0.47 1.17 415029.0 0.00 0.00 414745.3 0.94 1.17 411610.7 15798.46 49760.74 347870.8 0.94 1.17 417520.1 55251.77 174393.0 187379.1 1.40 2.34 414477.5 56203.05 174188.7 185302.4 0.47 1.17 em0 em1 bge1 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 416985.7 55063.17 174285.5 186733.5 0.94 2.34 415291.6 55358.65 174493.7 184466.1 1.41 5.01 409410.6 57657.47 174494.3 186945.9 0.94 1.17 417197.4 55271.79 173405.6 189667.3 0.94 3.09 415310.8 55503.47 174283.4 186058.0 0.94 1.17 417290.4 55983.99 174279.4 185274.7 0.94 4.59 418032.6 55648.61 174424.4 186057.0 0.94 1.17 416777.8 55283.73 174886.1 185034.6 0.47 1.17 414412.4 33989.34 105397.4 276853.1 0.94 1.17 416477.8 0.00 0.00 415984.6 0.47 1.17 416656.7 0.00 0.00 416117.0 0.94 1.17 416527.4 0.00 0.00 416372.2 0.47 1.17 250260.8 0.00 0.00 250029.2 0.94 1.17 0.00 0.00 0.00 0.00 0.47 1.17 0.00 0.00 0.00 0.00 0.94 1.17 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 05:15:49 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7F3116A4C9; Mon, 13 Nov 2006 05:15:49 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 477C043D58; Mon, 13 Nov 2006 05:15:48 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAD5Feaj072384; Sun, 12 Nov 2006 22:15:47 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4557FF7A.8020704@samsco.org> Date: Sun, 12 Nov 2006 22:15:38 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> In-Reply-To: <200611130454.kAD4sZwe041556@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 05:15:50 -0000 Mike Tancsa wrote: > At 11:05 PM 11/12/2006, Scott Long wrote: >> Mike Tancsa wrote: >>> However, if I turn on fastforwarding, its back to the old behavior >>> with it locking up. This was with the stock driver. I will try the >>> same test with >>> #define EM_FAST_INTR 1 >>> as well as taking out the nfs option from the kernel driver. >>> Anything else to tune with ? >>> ---Mike >> >> Would you mind going so far as to adding NO_ADAPTIVE_MUTEXES? This is > > Wow, it totally survives 2 streams (2 in one direction or 2 in opposite > directions)... AND it almost can survive a 3rd! It does seem to be > dropping packets on em1 when I add in a second stream blasting in the > same direction, but its survives. You can see at ** I add in the second > stream, and the outbound on em1 drops, even though more packets are > going through. I stop the second stream then add a stream going in the > other direction. Oddly enough, with a UP kernel it cant do 2 streams, > just the one. I thought the extra locking on SMP would make it worse ? > In this case it seems no. > Is this with EM_INTR_FAST enabled also? Scott From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 07:35:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 998F016A403 for ; Mon, 13 Nov 2006 07:35:42 +0000 (UTC) (envelope-from Florian.Prester@rrze.uni-erlangen.de) Received: from max71.rrze.uni-erlangen.de (max71.rrze.uni-erlangen.de [131.188.3.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A37E43D58 for ; Mon, 13 Nov 2006 07:35:40 +0000 (GMT) (envelope-from Florian.Prester@rrze.uni-erlangen.de) Received: from max71.rrze.uni-erlangen.de (max71.rrze.uni-erlangen.de [131.188.3.181]) by max71.rrze.uni-erlangen.de with ESMTP for freebsd-stable@freebsd.org; Mon, 13 Nov 2006 08:34:10 +0100 Received: from max71.rrze.uni-erlangen.de ([131.188.3.181]) by max71.rrze.uni-erlangen.de (max71.rrze.uni-erlangen.de [127.0.0.1]) (amavisd-new) with ESMTP id 25288-01-7661 for ; Mon, 13 Nov 2006 08:34:10 +0100 (MET) Received: from [131.188.3.175] ([131.188.3.175] [131.188.3.175]) by mailhub.rrze.uni-erlangen.de with ESMTP for freebsd-stable@freebsd.org; Mon, 13 Nov 2006 08:34:10 +0100 Message-Id: <45581FF2.10006@rrze.uni-erlangen.de> Date: Mon, 13 Nov 2006 08:34:10 +0100 From: Florian Prester User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616 (RRZE) on max71.rrze.uni-erlangen.de X-Spam-PYZOR: Reported 0 times. X-Spam-DCC: rrze-dcc:boeck2 1202; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.1.7-rrze_40 (2006-10-05) on boeck2.rrze.uni-erlangen.de X-Spam-Status: No, score=-3.8 tests=ALL_TRUSTED=-3.3, AWL=-0.339, BAYES_40=-0.185 autolearn=ham X-Spam-RBL: X-Spam-Eval: ham X-Spam-RRZE-Info: Diese Mail wurde einer automatischen Spam-Analyse unterzogen, siehe: http://www.rrze.uni-erlangen.de/dienste/e-mail/spam-analyse/ Subject: Apache2 mod_perl2 and libapreq2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 07:35:42 -0000 Hi all, I try to isntall libapreq2 by ports, but it fails!! Everything just works fine, until: ... Writing Makefile for libapreq2 cd perl; gmake gmake[2]: Entering directory `/usr/ports/www/libapreq2/work/libapreq2-2.08/glue/perl' cp lib/Apache2/Cookie.pm blib/lib/Apache2/Cookie.pm cp lib/Apache2/Upload.pm blib/lib/Apache2/Upload.pm cp lib/Apache2/Request.pm blib/lib/Apache2/Request.pm make: don't know how to make w. Stop gmake[2]: *** [subdirs] Error 2 gmake[2]: Leaving directory `/usr/ports/www/libapreq2/work/libapreq2-2.08/glue/perl' gmake[1]: *** [perl_glue] Error 2 gmake[1]: Leaving directory `/usr/ports/www/libapreq2/work/libapreq2-2.08/glue' gmake: *** [all-recursive] Error 1 *** Error code 2 Stop in /usr/ports/www/libapreq2. Any Ideas? I use FreeBSD-5.4 with Current-Ports! Thanks Florian -- Dipl. Inf. Florian Prester Network Administration Regionales RechenZentrum Erlangen Universitaet Erlangen-Nuernberg Martensstr. 1 91052 Erlangen Germany Tel.: +499131 8527813 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 09:07:18 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EF2B16A5FA for ; Mon, 13 Nov 2006 09:07:18 +0000 (UTC) (envelope-from dkirhlarov@oilspace.com) Received: from office.oilspace.com (ns2.oilspace.com [194.129.65.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B79D43D46 for ; Mon, 13 Nov 2006 09:07:16 +0000 (GMT) (envelope-from dkirhlarov@oilspace.com) Received: from dkirhlarov.mow.oilspace.com (proxy-mow.oilspace.com [81.222.156.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.oilspace.com (Postfix) with ESMTP id 2260F17A9F5 for ; Mon, 13 Nov 2006 08:44:34 +0000 (GMT) Received: from dkirhlarov.mow.oilspace.com (localhost [127.0.0.1]) by dkirhlarov.mow.oilspace.com (8.13.8/8.13.8) with ESMTP id kAD8iVMO060502 for ; Mon, 13 Nov 2006 11:44:31 +0300 (MSK) (envelope-from dkirhlarov@dkirhlarov.mow.oilspace.com) Received: (from dkirhlarov@localhost) by dkirhlarov.mow.oilspace.com (8.13.8/8.13.8/Submit) id kAD8iVqF060501 for stable@freebsd.org; Mon, 13 Nov 2006 11:44:31 +0300 (MSK) (envelope-from dkirhlarov) Date: Mon, 13 Nov 2006 11:44:31 +0300 From: Dmitriy Kirhlarov To: stable@freebsd.org Message-ID: <20061113084430.GE59604@dimma.mow.oilspace.com> Mail-Followup-To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailer: Mutt-ng devel (2005-03-13) based on Mutt 1.5.9 X-Operating-System: FreeBSD 6.2-PRERELEASE User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Subject: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 09:07:18 -0000 Hi, list. One from my monitoring servers running with FreeBSD 6.2-PRERELEASE #0: Fri Nov 10 11:03:10 UTC 2006 i386 Under heavy load it panic several times per day. Backtrace accesable: http://clh.higis.ru/~dimma/btfull.0 Can somebody take a look? I send Problem Report, but not get feed back now from gnats. Also, after replacing kernel, I has other easy reproduceble panic. String if_vlan_load="YES" in /boot/loader.conf and device vlan in kernel. I use fxp network cards, if it important. I don't have backtrace for this situation now, but, if it needed, I will make it. -- Dmitriy Kirhlarov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7247 ext.208 F:+7 495 105 7246 E:DmitriyKirhlarov@oilspace.com OILspace - The resource enriched - www.oilspace.com From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 10:01:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 885A716A492 for ; Mon, 13 Nov 2006 10:01:45 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EAF643D46 for ; Mon, 13 Nov 2006 10:01:42 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from [87.240.16.199] (helo=[192.168.0.2]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1GjYdI-0005hN-5b; Mon, 13 Nov 2006 13:01:40 +0300 Message-ID: <45584284.9050501@FreeBSD.org> Date: Mon, 13 Nov 2006 13:01:40 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Matthew Jacob References: <455768F3.4000407@FreeBSD.org> <7579f7fb0611121956n4bf77bc2g7443e7390923bb03@mail.gmail.com> In-Reply-To: <7579f7fb0611121956n4bf77bc2g7443e7390923bb03@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 10:01:45 -0000 Matthew Jacob wrote: > YMMV and your message is content free. I use sio all the time as a > console@115200 w/o any problems. > > On 11/12/06, Sergey Matveychuk wrote: >> Do you know an old sio driver is hardly usable? >> >> There are many silo overflows, working with a terminal device is a >> nightmare. There was a report about one crash with a message about a >> spinlock holed more than 5 seconds (there is no core dump because it has >> not repeated). >> >> After a discussion in a Russian FIDO group I've change it on uart and >> the problems gone. >> >> I think a default driver should be changed from sio to uart until it >> will be fixed. On Proliant DL360 I had a problem with sio. Input/output was jammed for 20-40 seconds every 1-3 minutes. On the FIDO group I found a few reports like mine. After a discussion it was offered to change sio driver with uart. After I do so, the problem gone. It's a common serial port. Nothing special. Now it detects as uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 dmesg.boot: Copyright (c) 1992-2006 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 6.2-PRERELEASE #1: Sat Nov 11 14:57:30 MSK 2006 root@xxx:/usr/obj/usr/src/sys/XXX ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3065.81-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf25 Stepping = 5 Features=0xbfebfbff Features2=0x4400> Logical CPUs per core: 2 real memory = 1073717248 (1023 MB) avail memory = 1041727488 (993 MB) MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 on motherboard ioapic3 irqs 48-63 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x920-0x923 on acpi0 cpu0: on acpi0 pcib0: on acpi0 pci0: on pcib0 pci0: at device 3.0 (no driver attached) ciss0: port 0x2800-0x28ff mem 0xf5f80000-0xf5fbffff,0xf5 df0000-0xf5df3fff irq 31 at device 4.0 on pci0 ciss0: [GIANT-LOCKED] pci0: at device 5.0 (no driver attached) pci0: at device 5.2 (no driver attached) isab0: at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x17 7,0x376,0x2000-0x200f at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 ohci0: mem 0xf5e70000-0xf5e70fff irq 10 at devic e 15.2 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered pcib1: on acpi0 pci1: on pcib1 bge0: mem 0xf7ef0000-0xf7efffff irq 30 a t device 2.0 on pci1 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge0: Ethernet address: 00:11:85:d5:ba:6b pcib2: on acpi0 pci4: on pcib2 bge1: mem 0xf7ff0000-0xf7ffffff irq 29 a t device 2.0 on pci4 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX -FDX, auto bge1: Ethernet address: 00:11:85:d5:ba:47 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xcc000-0xcd7ff ,0xee000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 ugen0: American Power Conversion Smart-UPS 1500 RM FW:617.3.I USB FW:1.5, rev 1. 10/0.06, addr 2 Timecounter "TSC" frequency 3065813092 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, defau lt to deny, logging unlimited acd0: CDROM at ata0-master PIO4 da0 at ciss0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 135.168MB/s transfers da0: 140006MB (286734240 512 byte sectors: 255H 32S/T 35139C) -- Dixi. Sem. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 11:08:01 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5BBD16A492 for ; Mon, 13 Nov 2006 11:08:01 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D2B643D64 for ; Mon, 13 Nov 2006 11:08:01 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GjZfK-00056h-Oi for freebsd-stable@freebsd.org; Mon, 13 Nov 2006 12:07:50 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 12:07:50 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 12:07:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 13 Nov 2006 12:07:43 +0100 Lines: 39 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: Sender: news Subject: Re: Cruel and unusual problems with Proliant ML350 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 11:08:01 -0000 Ivan Voras wrote: > - The showstopper: Sysinstall completes (though slowly), but on reboot > the loader doesn't go further than the "F1 prompt" :( This is very > curious, since when booting from install CD the loader shows it > recognizes the CD drive and drives A: and C:, so BIOS seems to be ok. If > I understand the loader correctly, after the "F1 prompt" phase, the > loader should transfer control to the boot block of the first slice? There's something unusual going on and I don't know what else to try. Finally, after fiddling with various options, I've sort-of got it to work by creating two slices (s1, s2), setting root partition on s1a and the rest (/usr, /var, etc.) on s2. Now, the "F1 prompt" boot stage behaves like this: - if I leave F1 to be the default, boot fails, beeping when trying to boot like before. Nothing changes when pressing F1 multiple time (it always fails and beeps). - if I leave F2 to be the default, boot fails with "invalid partition" message and escapes to the boot: prompt - if I press F1 and then F2, it beeps on F1 but after F2 is pressed it proceeds to boot from s1a! I really don't know what is going on. The disk array is supposed to be "clean", without hidden partitions (at least, fdisk doesn't see any). Is the loader re-reading the table after a failed boot (with F1), and something corrupts the data on first read? Or maybe it's a boot0 bug? Any ideas? As it stands, the machine can't boot unattended, which makes it unusable. More info: at the /boot/loader stage, lsdev shows disk0 as A:, but the floppy doesn't exist on this machine, and disk1 as C:, with normal partitions (e.g. disk1s1a, etc.) From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 11:17:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8878A16A417 for ; Mon, 13 Nov 2006 11:17:32 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 309BD43D4C for ; Mon, 13 Nov 2006 11:17:30 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1GjZof-0008ji-5M; Mon, 13 Nov 2006 11:17:29 +0000 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GjZoe-0003Kl-OX; Mon, 13 Nov 2006 11:17:28 +0000 To: freebsd-stable@freebsd.org, ivoras@fer.hr In-Reply-To: Message-Id: From: Pete French Date: Mon, 13 Nov 2006 11:17:28 +0000 Cc: Subject: Re: Cruel and unusual problems with Proliant ML350 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 11:17:32 -0000 > There's something unusual going on and I don't know what else to try. > Finally, after fiddling with various options, I've sort-of got it to > work by creating two slices (s1, s2), setting root partition on s1a and > the rest (/usr, /var, etc.) on s2. Now, the "F1 prompt" boot stage > behaves like this: [snip] This sounds similar to a Compaq machine I used to have with a SMART RAID in it. I had 3 drives - a SCSI, and two on the RAID. It would beep at F1 as well. I had to press F5 3 times to cycle through all the drives, but then when I got back to the original I could press F1 and it would now boot fine. I never solved it, aand eventually changed machine (though not the hardware). At the time it did not matter so much as the machine was a server so when booted would just run until it manually needed to be restarted. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 12:22:31 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E98D16A412; Mon, 13 Nov 2006 12:22:31 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 679C443D49; Mon, 13 Nov 2006 12:22:30 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id kADCME0S068075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 15:22:14 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id kADCMDLC068074; Mon, 13 Nov 2006 15:22:13 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 13 Nov 2006 15:22:13 +0300 From: Gleb Smirnoff To: Barry Boes Message-ID: <20061113122212.GN32700@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Barry Boes , Jack Vogel , jfv@freebsd.org, Scott Long , John Baldwin , RelEng , Prafulla Deuskar , freebsd-stable@freebsd.org, freebsd-net References: <17748.37662.708865.764722@gargle.gargle.HOWL> <20061110150840.GK32700@cell.sick.ru> <17748.53164.372871.270153@gargle.gargle.HOWL> <17748.64782.579350.492909@gargle.gargle.HOWL> <2a41acea0611101447j29acdc3k820276de92204735@mail.gmail.com> <17751.33660.897403.267059@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <17751.33660.897403.267059@gargle.gargle.HOWL> User-Agent: Mutt/1.5.6i Cc: RelEng , John Baldwin , freebsd-net , Prafulla Deuskar , Jack Vogel , jfv@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: EM stability X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 12:22:31 -0000 On Sun, Nov 12, 2006 at 02:26:36PM -0600, Barry Boes wrote: B> After the last hang I added giant locks back in and the machine has B> been up since. B> B> I don't have a serial console, just a graphic console. When the B> machine hangs it stops replying to ethernet packets at all protocol B> levels and doesn't respond to keyboard input in any way, virtual B> console or otherwise. If I run a script of the form B> while(1) B> sleep 1 B> date >> datelog B> end B> B> the file stops updating when the machine hangs. B> B> I will define the debugger in the kernel (options DDB, right?), attach B> a serial console, and do what I can to get more information on the B> problem. Yes, this looks like something is running in an endless loop. Once you compile kernel with debugger, you should enter in several times and see the backtraces. Usually, they will be inside this cycle. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 12:48:48 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9984A16A4AB; Mon, 13 Nov 2006 12:48:48 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA31B43D58; Mon, 13 Nov 2006 12:48:47 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kADCmkaA003746; Mon, 13 Nov 2006 07:48:46 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kADCmieP043730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 07:48:45 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611131248.kADCmieP043730@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Nov 2006 07:48:56 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <4557FF7A.8020704@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Status: Clean Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 12:48:48 -0000 At 12:15 AM 11/13/2006, Scott Long wrote: >Is this with EM_INTR_FAST enabled also? Yes. Havent done the stock case yet, but will do so later today. ---Mike From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 11:36:13 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85D8216A403; Mon, 13 Nov 2006 11:36:13 +0000 (UTC) (envelope-from spartak@aif.ru) Received: from mail.aif.ru (mail.aif.ru [85.21.212.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A842143D4C; Mon, 13 Nov 2006 11:36:12 +0000 (GMT) (envelope-from spartak@aif.ru) Received: from ppp85-141-144-35.pppoe.mtu-net.ru ([85.141.144.35] helo=[192.168.0.2]) by mail.aif.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1Gja6k-0003Ax-R4; Mon, 13 Nov 2006 14:36:11 +0300 Message-ID: <455858A3.9060701@aif.ru> Date: Mon, 13 Nov 2006 14:36:03 +0300 From: =?KOI8-R?Q?=F3=D0=C1=D2=D4=C1=CB_=F2=C1=C4=DE=C5=CE=CB=CF?= User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <455768F3.4000407@FreeBSD.org> <455786DB.4020807@mail.zedat.fu-berlin.de> In-Reply-To: <455786DB.4020807@mail.zedat.fu-berlin.de> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -4.0 (----) X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.4 AWL AWL: From: address is in the auto white-list X-Mailman-Approved-At: Mon, 13 Nov 2006 12:54:21 +0000 Cc: "O. Hartmann" , sem@FreeBSD.org Subject: Re: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 11:36:13 -0000 O. Hartmann ÐÉÛÅÔ: > Sergey Matveychuk wrote: > >> Do you know an old sio driver is hardly usable? >> >> There are many silo overflows, working with a terminal device is a >> nightmare. There was a report about one crash with a message about a >> spinlock holed more than 5 seconds (there is no core dump because it has >> not repeated). >> >> After a discussion in a Russian FIDO group I've change it on uart and >> the problems gone. >> >> I think a default driver should be changed from sio to uart until it >> will be fixed. >> >> > > Had those overflows many times when I used FreeBSD 6.0-STABLE, > 6.1-STABLE and a modem. > But this never had a so bad influence forcing me into using uart. > I had serious problems with sio on Intel STL2 motherboard and recent stable. Massive silo overflows (modem was almost unusable) and at least 1 sio-related panic (spinlock held for more than 5 sec). Now I changed sio to uart ant it works like a charm. All problems gone. -- Spartak Radchenko SVR1-RIPE From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 13:16:46 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C093916A4D1 for ; Mon, 13 Nov 2006 13:16:46 +0000 (UTC) (envelope-from ivoras@geri.cc.fer.hr) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC0B843D68 for ; Mon, 13 Nov 2006 13:15:06 +0000 (GMT) (envelope-from ivoras@geri.cc.fer.hr) Received: from geri.cc.fer.hr (localhost.cc.fer.hr [127.0.0.1]) by geri.cc.fer.hr (8.13.6/8.13.6) with ESMTP id kADDErYo009782; Mon, 13 Nov 2006 14:14:53 +0100 (CET) (envelope-from ivoras@geri.cc.fer.hr) Received: from localhost (ivoras@localhost) by geri.cc.fer.hr (8.13.6/8.13.6/Submit) with ESMTP id kADDEm2f009775; Mon, 13 Nov 2006 14:14:48 +0100 (CET) (envelope-from ivoras@geri.cc.fer.hr) Date: Mon, 13 Nov 2006 14:14:48 +0100 (CET) From: Ivan Voras To: Pete French In-Reply-To: Message-ID: <20061113141033.Y9445@geri.cc.fer.hr> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Cruel and unusual problems with Proliant ML350 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 13:16:46 -0000 On Mon, 13 Nov 2006, Pete French wrote: >> There's something unusual going on and I don't know what else to try. >> Finally, after fiddling with various options, I've sort-of got it to >> work by creating two slices (s1, s2), setting root partition on s1a and >> the rest (/usr, /var, etc.) on s2. Now, the "F1 prompt" boot stage >> behaves like this: > > [snip] > > This sounds similar to a Compaq machine I used to have with a SMART RAID > in it. I had 3 drives - a SCSI, and two on the RAID. It would beep > at F1 as well. I had to press F5 3 times to cycle through all the drives, > but then when I got back to the original I could press F1 and it would now > boot fine. > > I never solved it, aand eventually changed machine (though not the > hardware). At the time it did not matter so much as the machine was > a server so when booted would just run until it manually needed to be > restarted. Hmm, it looks like it's a bug in boot0. I've replaced it with ports/sysutils/extipl and the machine boots fine now. Btw. I can confirm extipl works on amd64, so ONLY_FOR_ARCHS line can be updated now. Grub still doesn't. -- Things Mr Welch Cannot Do During An RPG: 135. I cannot demand payment in electrum, backrubs or bubblewrap. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 15:03:16 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B92C16A4D1 for ; Mon, 13 Nov 2006 15:03:16 +0000 (UTC) (envelope-from mvoorhis@cs.wpi.edu) Received: from mail1.wpi.edu (MAIL1.WPI.EDU [130.215.36.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 653D643F5F for ; Mon, 13 Nov 2006 14:51:06 +0000 (GMT) (envelope-from mvoorhis@cs.wpi.edu) Received: from mcafee.wpi.edu (MCAFEE.WPI.EDU [130.215.36.86]) by mail1.wpi.edu (8.13.8/8.13.8) with SMTP id kADEoWQH007847; Mon, 13 Nov 2006 09:50:32 -0500 Received: from (130.215.36.186) by mcafee.wpi.edu via smtp id 06bf_4fda9fd8_7326_11db_827e_0013725b2d50; Mon, 13 Nov 2006 09:50:31 -0500 Received: from [130.215.29.46] (ERESSEA.WPI.EDU [130.215.29.46]) by SMTP.WPI.EDU (8.13.8/8.13.8) with ESMTP id kADEoU4a013949; Mon, 13 Nov 2006 09:50:31 -0500 (envelope-from mvoorhis@cs.wpi.edu) Message-ID: <45588636.8060906@cs.wpi.edu> Date: Mon, 13 Nov 2006 09:50:30 -0500 From: Mike Voorhis User-Agent: Thunderbird 1.5.0.8 (X11/20061110) MIME-Version: 1.0 To: Mike Voorhis References: <455768F3.4000407@FreeBSD.org> <455786DB.4020807@mail.zedat.fu-berlin.de> <455858A3.9060701@aif.ru> In-Reply-To: <455858A3.9060701@aif.ru> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 15:03:16 -0000 óÐÁÒÔÁË òÁÄÞÅÎËÏ wrote: > I had serious problems with sio on Intel STL2 motherboard and recent > stable. Massive silo overflows (modem was almost unusable) and at least > 1 sio-related panic (spinlock held for more than 5 sec). Now I changed > sio to uart ant it works like a charm. All problems gone. Since we're posting annecdotes, I feel I should mention that I've used "device sio" on a modem box used for remote-access serial terminal connections for several years (FreeBSD-5 and FreeBSD-6) without any trouble. No crashes, no complaints, no lockups. The machine is a Dell Optiplex gx260 machine with an attatched US Robotocs modem. The machine serves a few other network-related tasks as well and has performed flawlessly. Right now, the machine currently runs 6.2-Prerelease from a few days ago. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 15:25:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A41D16A4B3 for ; Mon, 13 Nov 2006 15:25:36 +0000 (UTC) (envelope-from jbozza@qlinksmedia.com) Received: from mail.thinkburst.com (mail.thinkburst.com [66.210.222.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B7A743D80 for ; Mon, 13 Nov 2006 15:20:56 +0000 (GMT) (envelope-from jbozza@qlinksmedia.com) Received: from mailgate.thinkburstmedia.com (gateway.thinkburstmedia.com [66.210.222.36]) by mail.thinkburst.com (Postfix) with ESMTP id DA2571CC27 for ; Mon, 13 Nov 2006 09:20:49 -0600 (CST) Received: from thinkburst.com (bacchus.thinkburst.com [10.1.1.25]) by mailgate.thinkburstmedia.com (Postfix) with ESMTP id CE28317046 for ; Mon, 13 Nov 2006 09:20:49 -0600 (CST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Nov 2006 09:20:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: In-Reply-To: <032501c705c5$6cefa790$9603a8c0@claylaptop> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6-STABLE oddity Thread-Index: AccFxtFw8jWrKELmSEuEsxxVi/4n0wBbyy9A From: "Jaime Bozza" To: Subject: RE: 6-STABLE oddity X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 15:25:36 -0000 > Download, burn to CD and run http://www.memtest86.com/ >=20 > Usually problems of this sort are faulty ram. > I had a buddy getting odd errors on copying files that happenned at > random. > Turned out to be bad ram too. I recently had this same problem with a recent 6-STABLE and thought the same thing. Ran memtest for over 48 hours and never came up with any errors. I would cvsup source and run an md5 check to compare with another "known good" system and seemed to always have 1-2 files bad. It seemed to always be just 1 bit off. Tried swapping cables, cards (SCSI), etc. The system was running gmirror on two 18G SCSI drives using an Adaptec controller. If I disabled the 2nd drive, I didn't have a single problem after a ton of testing. Turned out that I hadn't formatted the 2nd drive using the Adaptec tools. The drives had been out of service for about 3 years. Once I went through a format/verify I wasn't able to duplicate the problem no matter what I tried. So, RAM is definitely the easiest thing to test but keep in mind that there are other areas that may also cause an issue. Jaime Bozza From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 16:18:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48F5F16A417 for ; Mon, 13 Nov 2006 16:18:45 +0000 (UTC) (envelope-from spartak@aif.ru) Received: from mail.aif.ru (mail.aif.ru [85.21.212.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26FAB43E07 for ; Mon, 13 Nov 2006 16:10:34 +0000 (GMT) (envelope-from spartak@aif.ru) Received: from spartak.intranet ([192.168.71.10]) by mail.aif.ru with esmtps (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1GjeNx-000GMh-Ec for freebsd-stable@freebsd.org; Mon, 13 Nov 2006 19:10:13 +0300 Message-ID: <455898E4.6000100@aif.ru> Date: Mon, 13 Nov 2006 19:10:12 +0300 From: Spartak Radchenko User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <455768F3.4000407@FreeBSD.org> <455786DB.4020807@mail.zedat.fu-berlin.de> <455858A3.9060701@aif.ru> <200611131447.kADElvjo044200@lava.sentex.ca> In-Reply-To: <200611131447.kADElvjo044200@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -4.1 (----) X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list Subject: Re: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 16:18:45 -0000 Mike Tancsa wrote: > At 06:36 AM 11/13/2006, > =?KOI8-R?Q?=F3=D0=C1=D2=D4=C1=CB_=F2=C1=C4=DE=C5=CE=CB=CF?= wrote: >> O. Hartmann ÐÉÛÅÔ: >>> Sergey Matveychuk wrote: >>> >>>> Do you know an old sio driver is hardly usable? >>>> >>>> There are many silo overflows, working with a terminal device is a >>>> nightmare. There was a report about one crash with a message about a >>>> spinlock holed more than 5 seconds (there is no core dump because >>>> it has >>>> not repeated). >>>> >>>> After a discussion in a Russian FIDO group I've change it on uart and >>>> the problems gone. >>>> >>>> I think a default driver should be changed from sio to uart until it >>>> will be fixed. >>>> >>>> >>> >>> Had those overflows many times when I used FreeBSD 6.0-STABLE, >>> 6.1-STABLE and a modem. >>> But this never had a so bad influence forcing me into using uart. >>> >> I had serious problems with sio on Intel STL2 motherboard and recent >> stable. Massive silo overflows (modem was almost unusable) and at >> least 1 sio-related panic (spinlock held for more than 5 sec). Now I >> changed sio to uart ant it works like a charm. All problems gone. > > How do you switch it from sio to uart on RELENG_6 ? I compiled a new kernel with device uart instead of sio (not sure it was necessary, but I did it) and edited /boot/device.hints (sio -> uart). Kernel config was standard SMP from FreeBSD distribution. Also edited /etc/ttys and /etc/ppp/* to switch from ttyd? to ttyu?. -- Spartak Radchenko SVR1-RIPE From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 16:24:32 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F41216A4EE for ; Mon, 13 Nov 2006 16:24:32 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47E2F43E00 for ; Mon, 13 Nov 2006 16:23:11 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (jktuxo@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kADGMfiP072568; Mon, 13 Nov 2006 17:22:46 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kADGMair072567; Mon, 13 Nov 2006 17:22:36 +0100 (CET) (envelope-from olli) Date: Mon, 13 Nov 2006 17:22:36 +0100 (CET) Message-Id: <200611131622.kADGMair072567@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, aburke@nullplusone.net, gamato@users.sourceforge.net, avg@icyb.net.ua In-Reply-To: <4554B8E3.1050604@icyb.net.ua> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 13 Nov 2006 17:22:47 +0100 (CET) Cc: Subject: Re: adding an extra hard disk and adding space to /usr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, aburke@nullplusone.net, gamato@users.sourceforge.net, avg@icyb.net.ua List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 16:24:32 -0000 Andriy Gapon wrote: > Oliver Fromme wrote: > > Aaron Burke wrote: > > > SNIP > > > > > (FreeBSD 4.x) : cd /usr; tar clpf - . | (cd /mnt; tar xvf -) > > > > > (FreeBSD 5.x+) : cd /usr; gtar clpf - . | (cd /mnt; gtar xvf -) > > > > iirc tar(1) has changed in 5.3. why do you use gtar please? is new tar > > > > missing something? > > > Well, technically no, but it requires more typing. > > > > That's why I prefer to use cpio: > > > > cd /usr; find -dx . | cpio -dump /mnt > > > > which works on _any_ version of FreeBSD out of the box. > > $ pax rw /usr /mnt > is even less typing and works on any system with POSIX-compliant > utilities :-) For certain definitions of "works". :-) At the very least you have to add "-p e" (preserve UID/GID and file mode). And if you don't use it for local copy mode, you have to remember to add "-x cpio", or otherwise it won't copy long path names correctly. I like the find|cpio combination for the great flexibility that find(1) provides. And while cpio isn't in the current POSIX standard (neither is tar, FWIW), it's present on all UNIX systems that I'm using. It's also important to know that pax doesn't preserve file flags (cpio neither, though). To make a real 1:1 copy including file flags, cpdup is easy to use and efficient (ports/sysutils/cpdup). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard." -- Peter van der Linden From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 16:34:38 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC67516A47E for ; Mon, 13 Nov 2006 16:34:38 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCABF43D7E for ; Mon, 13 Nov 2006 16:33:53 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (etwvar@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kADGXOU1073081; Mon, 13 Nov 2006 17:33:29 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kADGXO8J073080; Mon, 13 Nov 2006 17:33:24 +0100 (CET) (envelope-from olli) Date: Mon, 13 Nov 2006 17:33:24 +0100 (CET) Message-Id: <200611131633.kADGXO8J073080@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, ivoras@fer.hr In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 13 Nov 2006 17:33:29 +0100 (CET) Cc: Subject: Re: Cruel and unusual problems with Proliant ML350 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, ivoras@fer.hr List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 16:34:39 -0000 Ivan Voras wrote: > - The less serious problem: It looks like a whole bunch of built-in > devices is routed to irq 29: bce, ciss, ohci and ehci. I notice last > three are giant locked, which doesn't look good, especially since this > should be a loaded web server. If it's really only a web server, then you probably don't need the USB ports. In that case you should remove ohci and ehci from your kernel. The USB interrupt handler is quite heavy-weight, so it can have a noticeable impact if the interrupt is shared with other devices. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. (On the statement print "42 monkeys" + "1 snake":) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when the answer is clearly "41 monkeys and 1 fat snake". -- Jim Fulton From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 17:27:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7190016A51B for ; Mon, 13 Nov 2006 17:27:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from alnrmhc12.comcast.net (alnrmhc12.comcast.net [206.18.177.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12BBF43F66 for ; Mon, 13 Nov 2006 17:19:46 +0000 (GMT) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-67-174-220-97.hsd1.ca.comcast.net[67.174.220.97]) by comcast.net (alnrmhc12) with ESMTP id <20061113171946b1200n2seve>; Mon, 13 Nov 2006 17:19:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F412F1FA01D; Mon, 13 Nov 2006 09:19:45 -0800 (PST) Date: Mon, 13 Nov 2006 09:19:45 -0800 From: Jeremy Chadwick To: freebsd-stable@FreeBSD.ORG, ivoras@fer.hr Message-ID: <20061113171945.GA26567@icarus.home.lan> Mail-Followup-To: freebsd-stable@FreeBSD.ORG, ivoras@fer.hr References: <200611131633.kADGXO8J073080@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611131633.kADGXO8J073080@lurza.secnetix.de> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: Cruel and unusual problems with Proliant ML350 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 17:27:53 -0000 On Mon, Nov 13, 2006 at 05:33:24PM +0100, Oliver Fromme wrote: > If it's really only a web server, then you probably don't > need the USB ports. In that case you should remove ohci > and ehci from your kernel. The USB interrupt handler is > quite heavy-weight, so it can have a noticeable impact if > the interrupt is shared with other devices. I'll agree with this (re: webservers not needing USB), except in regards to one item: keyboards. More and more x86 PCs these days are expecting keyboards to be USB-based. Yes, PS/2 ports are still present on most (but not all) motherboards, but eventually that will be phased out. I like the idea of being able to go to my co-location facility and plug in a USB keyboard to begin working on a server, and when finished remove the keyboard and leave. PS/2 was never intended to be hot-swappable, and as I'm sure many can attest to, removing or adding a PS/2 keyboard is generally frowned upon (it works here, it doesn't work there, etc.). I've seen some recent commits to the keyboard code which address being able to plug in a PS/2 keyboard while the machine is powered on (thus not having to reboot), for what it's worth. Summary: ukbd is one reason USB is useful on servers. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 17:51:02 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AED916A40F for ; Mon, 13 Nov 2006 17:51:02 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.htnet.hr (ls405.t-com.hr [195.29.150.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52E9F43DD4 for ; Mon, 13 Nov 2006 17:49:35 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from ls422.t-com.hr (ls422.t-com.hr [195.29.150.237]) by ls405.htnet.hr (Postfix) with ESMTP id DA875146B4E; Mon, 13 Nov 2006 18:49:17 +0100 (CET) Received: from ls422.t-com.hr (localhost.localdomain [127.0.0.1]) by ls422.t-com.hr (Qmlai) with ESMTP id B6D88C90069; Mon, 13 Nov 2006 18:49:17 +0100 (CET) X-Envelope-Sender-Info: KDHLkYIFXCRHG7zIR7FVXir0zIzpDLK2N+NOR3B6cHjI2TUK5Co2GKgXDZaTq6Oi X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.100] (83-131-168-146.adsl.net.t-com.hr [83.131.168.146])by ls422.t-com.hr (Qmlai) with ESMTP id 47647130806A; Mon, 13 Nov 2006 18:49:17 +0100 (CET) Message-ID: <4558B027.10602@fer.hr> Date: Mon, 13 Nov 2006 18:49:27 +0100 From: Ivan Voras User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG, ivoras@fer.hr References: <200611131633.kADGXO8J073080@lurza. secnetix.de> <20061113171945.GA26567@icarus.home.lan> In-Reply-To: <20061113171945.GA26567@icarus.home.lan> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-imss-version: 2.044 X-imss-result: Passed X-imss-scores: Clean:52.79118 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: Subject: Re: Cruel and unusual problems with Proliant ML350 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 17:51:02 -0000 Jeremy Chadwick wrote: > On Mon, Nov 13, 2006 at 05:33:24PM +0100, Oliver Fromme wrote: >> If it's really only a web server, then you probably don't >> need the USB ports. In that case you should remove ohci >> and ehci from your kernel. The USB interrupt handler is >> quite heavy-weight, so it can have a noticeable impact if >> the interrupt is shared with other devices. > > I'll agree with this (re: webservers not needing USB), except in > regards to one item: keyboards. Yup. And iLO. In fact, it appears that there's some builtin connection between USB, iLO, ethernet and ciss - changing IRQ of one of them in BIOS changes it for all of them :( > finished remove the keyboard and leave. PS/2 was never intended > to be hot-swappable, and as I'm sure many can attest to, removing And it's shaped worse than USB. > Summary: ukbd is one reason USB is useful on servers. Yes. From what I can see, these days the number of servers *without any* PS/2 connectors is passing 50%. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 17:52:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D336A16A4D4 for ; Mon, 13 Nov 2006 17:52:56 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37B9643DC7 for ; Mon, 13 Nov 2006 17:51:42 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gjfwv-0007sb-G1 for freebsd-stable@freebsd.org; Mon, 13 Nov 2006 18:50:25 +0100 Received: from 83-131-168-146.adsl.net.t-com.hr ([83.131.168.146]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 18:50:25 +0100 Received: from ivoras by 83-131-168-146.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Nov 2006 18:50:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 13 Nov 2006 18:50:28 +0100 Lines: 8 Message-ID: References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> <200611131248.kADCmieP043730@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-168-146.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) In-Reply-To: <200611131248.kADCmieP043730@lava.sentex.ca> Sender: news Cc: freebsd-net@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 17:52:57 -0000 Mike Tancsa wrote: > At 12:15 AM 11/13/2006, Scott Long wrote: > >> Is this with EM_INTR_FAST enabled also? > > Yes. Havent done the stock case yet, but will do so later today. Do you have a comparison with Linux under the same circumstances? From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 18:36:27 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61E9E16A4E6 for ; Mon, 13 Nov 2006 18:36:27 +0000 (UTC) (envelope-from om-lists-bsd@omx.ch) Received: from omega.omnis.ch (omega.omnis.ch [195.134.143.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 8D30844289 for ; Mon, 13 Nov 2006 18:30:20 +0000 (GMT) (envelope-from om-lists-bsd@omx.ch) Received: (qmail 24416 invoked from network); 13 Nov 2006 18:30:09 -0000 Received: from bigapple.omnis.ch ([195.134.148.35]) by omega.omnis.ch ([195.134.143.43]) with ESMTP via TCP; 13 Nov 2006 18:30:09 -0000 From: Olivier Mueller To: freebsd-stable@FreeBSD.ORG Content-Type: text/plain Date: Mon, 13 Nov 2006 19:30:09 +0100 Message-Id: <1163442609.10865.59.camel@bigapple.omnis.ch> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit Cc: Subject: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 18:36:27 -0000 Hello, I will soon get some new servers with more than 4 GB of RAM, and I am wondering if they will work fine even with the PAE option activated: are all the required drivers (RAID mfid, bce on the Dell, ciss0 on the HP) 100% compatible, or should I expect trouble? If you have a working "/usr/src/sys/i386/conf/xxxx" with active PAE on one of these servers, I'd be interested :) Btw, when will we see these new servers listed under: http://www.freebsd.org/platforms/amd64/motherboards.html ? Or should I use send-pr ? :) Thanks & regards, Olivier From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 18:53:50 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF9F116A4F5 for ; Mon, 13 Nov 2006 18:53:50 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E3854419A for ; Mon, 13 Nov 2006 18:45:32 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 41C061A4D84 for ; Mon, 13 Nov 2006 10:45:16 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 828225138B; Mon, 13 Nov 2006 13:45:05 -0500 (EST) Date: Mon, 13 Nov 2006 13:45:05 -0500 From: Kris Kennaway To: stable@freebsd.org Message-ID: <20061113184505.GA51659@xor.obsecurity.org> References: <20061113084430.GE59604@dimma.mow.oilspace.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <20061113084430.GE59604@dimma.mow.oilspace.com> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 18:53:51 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2006 at 11:44:31AM +0300, Dmitriy Kirhlarov wrote: > Hi, list. >=20 > One from my monitoring servers running with > FreeBSD 6.2-PRERELEASE #0: Fri Nov 10 11:03:10 UTC 2006 i386 >=20 > Under heavy load it panic several times per day. Backtrace accesable: > http://clh.higis.ru/~dimma/btfull.0=20 > Can somebody take a look? > I send Problem Report, but not get feed back now from gnats. Please provide your kernel config. > Also, after replacing kernel, I has other easy reproduceble panic. > String > if_vlan_load=3D"YES" > in /boot/loader.conf and > device vlan > in kernel. > I use fxp network cards, if it important. > I don't have backtrace for this situation now, but, if it needed, I > will make it. Yes, you'll need to provide a backtrace for this too. Please post it separately to avoid confusion between the two problems. Kris --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWL0xWry0BWjoQKURAu97AKDhRRuvSwN3igIm71fHOepr+mH9fQCgifBP lXS18BcwKW2AJ3AunRpye5o= =UoPf -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 19:00:02 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A63516A4AB for ; Mon, 13 Nov 2006 19:00:02 +0000 (UTC) (envelope-from mikej@rogers.com) Received: from smtp100.rog.mail.re2.yahoo.com (smtp100.rog.mail.re2.yahoo.com [206.190.36.78]) by mx1.FreeBSD.org (Postfix) with SMTP id DD15043DD2 for ; Mon, 13 Nov 2006 18:58:30 +0000 (GMT) (envelope-from mikej@rogers.com) Received: (qmail 36816 invoked from network); 13 Nov 2006 18:57:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TMVjg/C12/vZphEJtF3QcO81qOQ1k+iOatg3pnqWX2vbQfl90M6SZEnonV619xx09HSadjJQgzx6TcZNuU7c6joTXWeXuBsn2UpWQgziy5VTsmnF5wlTd6IfRPHhP7OJxkt57i9uGS+IxgceAKPoeTweBhEWQcKabG3ctZYtR7M= ; Received: from unknown (HELO ?172.16.0.200?) (mikej@rogers.com@74.111.253.239 with plain) by smtp100.rog.mail.re2.yahoo.com with SMTP; 13 Nov 2006 18:57:51 -0000 X-YMail-OSG: IiGv4NcVM1lRD008PtS.gNroPWLTDg2V8YBGiHp3iGH4wEYGEsETTft7uuc6EZifsGWlSohgbDo9M00SXbuBU6MoYZHZqjYXxxHIKn0_aePYwQiE8uyd Message-ID: <4558C02E.4030509@rogers.com> Date: Mon, 13 Nov 2006 13:57:50 -0500 From: Mike Jakubik User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Olivier Mueller References: <1163442609.10865.59.camel@bigapple.omnis.ch> In-Reply-To: <1163442609.10865.59.camel@bigapple.omnis.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 19:00:02 -0000 Olivier Mueller wrote: > Hello, > > I will soon get some new servers with more than 4 GB of RAM, and > I am wondering if they will work fine even with the PAE > option activated: are all the required drivers (RAID mfid, bce > on the Dell, ciss0 on the HP) 100% compatible, or should I expect > trouble? > Why not use AMD64 mode instead of PAE? From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 19:16:46 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3165F16A4D2 for ; Mon, 13 Nov 2006 19:16:46 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BA6243E01 for ; Mon, 13 Nov 2006 19:14:49 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id A48C95E22; Mon, 13 Nov 2006 22:14:48 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 832745E07; Mon, 13 Nov 2006 22:14:48 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kADJEsYV066122; Mon, 13 Nov 2006 22:14:54 +0300 (MSK) (envelope-from ru) Date: Mon, 13 Nov 2006 22:14:54 +0300 From: Ruslan Ermilov To: Olivier Mueller Message-ID: <20061113191454.GB66013@rambler-co.ru> References: <1163442609.10865.59.camel@bigapple.omnis.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline In-Reply-To: <1163442609.10865.59.camel@bigapple.omnis.ch> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-stable@freebsd.org Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 19:16:46 -0000 --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2006 at 07:30:09PM +0100, Olivier Mueller wrote: > Hello, >=20 > I will soon get some new servers with more than 4 GB of RAM, and > I am wondering if they will work fine even with the PAE > option activated: are all the required drivers (RAID mfid, bce > on the Dell, ciss0 on the HP) 100% compatible, or should I expect > trouble?=20 >=20 Drivers that are either known to NOT work with PAE or were not tested with PAE are excluded by the PAE config file, you can check there. : 0 edoofus:ttyp2:/sys/i386/conf >egrep 'ciss|mfi|bce' GENERIC PAE : GENERIC:device ciss # Compaq Smart RAID 5* : GENERIC:device mfi # LSI MegaRAID SAS : GENERIC:device bce # Broadcom BCM5706/BCM5708 Gigabi= t Ethernet So it looks like all of them should work fine with PAE. > If you have a working "/usr/src/sys/i386/conf/xxxx" with active > PAE on one of these servers, I'd be interested :) >=20 > Btw, when will we see these new servers listed under: > http://www.freebsd.org/platforms/amd64/motherboards.html ?=20 > Or should I use send-pr ? :) >=20 And you absolutely have no option of running FreeBSD/amd64 on them? What a PITA! :-) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWMQuqRfpzJluFF4RAp4/AJ90IJFQCFfAnSRLMAgunQEWNuf9VQCgjYBb LQRD6wT7EvO176MHoULL6ts= =ms2q -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 19:18:44 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AE1616A403 for ; Mon, 13 Nov 2006 19:18:44 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [74.92.149.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FB2943E13 for ; Mon, 13 Nov 2006 19:16:59 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id D0913B80F; Mon, 13 Nov 2006 14:16:54 -0500 (EST) In-Reply-To: <20061111022925.Q953@it.hackers> References: <453D49D2.1010705@rogers.com> <6DBE5906-CD84-44C5-AF40-FFCC78C7561E@khera.org> <20061024202408.U923@it.hackers> <6611C68B-1492-48A7-9425-3E23271CC940@khera.org> <20061111022925.Q953@it.hackers> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9-454619936; protocol="application/pkcs7-signature" Message-Id: <92D6756F-12EA-43CF-95C3-33CB8A25FDC0@khera.org> From: Vivek Khera Date: Mon, 13 Nov 2006 14:16:53 -0500 To: Nguyen Tam Chinh X-Mailer: Apple Mail (2.752.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: Running large DB's on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 19:18:44 -0000 --Apple-Mail-9-454619936 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 10, 2006, at 6:35 PM, Nguyen Tam Chinh wrote: >> For the pg configuration, I use this on a 4Gb box: >> >> max_connections = 100 >> shared_buffers = 70000 # min 16 or >> max_connections*2, 8KB each >> work_mem = 262144 # min 64, size in KB > > Thank you very much. And how did you set the semaphore's > parameters? Do you have any trick or experience? I just think it's > just weird to inceremently increase ipc.shm* and ipc.sem* to get > the right values. The documentation of PostGreSQL gives us some > examples but without explanation how they found those values. The SEM parameters are the bare minimum. Pg uses a small number of semaphores, so unless you have a bazillion connections allowed, just use these settings: kern.ipc.semmsl=512 kern.ipc.semmap=256 kern.ipc.semmni=32 kern.ipc.semmns=512 Now, for the SHM usage, it is just arithmetic. You now how many buffers you're asking for, you know how big they are, and you just need to add some for overhead and you've got your number. If you want Pg to compute it for you, just read the error log when you fire up Pg with a small shm setting in the OS. --Apple-Mail-9-454619936-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 19:22:47 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CEAF16A407 for ; Mon, 13 Nov 2006 19:22:47 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 785F343D64 for ; Mon, 13 Nov 2006 19:22:42 +0000 (GMT) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (localhost.aoes.com [127.0.0.1]) by core.byshenk.net (8.13.8/8.13.8) with ESMTP id kADJMdLC027964 for ; Mon, 13 Nov 2006 20:22:39 +0100 (CET) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.13.8/8.13.8/Submit) id kADJMdJk027963 for freebsd-stable@FreeBSD.ORG; Mon, 13 Nov 2006 20:22:39 +0100 (CET) (envelope-from byshenknet) Date: Mon, 13 Nov 2006 20:22:39 +0100 From: Greg Byshenk To: freebsd-stable@FreeBSD.ORG Message-ID: <20061113192239.GA1092@core.byshenk.net> References: <200611131633.kADGXO8J073080@lurza.secnetix.de> <20061113171945.GA26567@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061113171945.GA26567@icarus.home.lan> User-Agent: Mutt/1.4.2.2i X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.byshenk.net Cc: Subject: Re: Cruel and unusual problems with Proliant ML350 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 19:22:47 -0000 On Mon, Nov 13, 2006 at 09:19:45AM -0800, Jeremy Chadwick wrote: > I'll agree with this (re: webservers not needing USB), except in > regards to one item: keyboards. > > More and more x86 PCs these days are expecting keyboards to be > USB-based. Yes, PS/2 ports are still present on most (but not all) > motherboards, but eventually that will be phased out. > > I like the idea of being able to go to my co-location facility and > plug in a USB keyboard to begin working on a server, and when > finished remove the keyboard and leave. Don't you really need to have a monitor, as well? I _have_ worked "blind" before, but I didn't enjoy it. I can imagine having a keyboard with me when wandering around, but wouldn't normally have a monitor. I had always thought that the preferred solution for this sort of case was to use a serial console. And what seems to be becoming common on servers is a BIOS that allows you to fully redirect to serial, including BIOS configuration. The servers that I have recently purchased have had a keyboard and monitor plugged into them _once_ -- for the first BIOS setup -- and then never again. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 20:40:55 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6190F16A4EC for ; Mon, 13 Nov 2006 20:40:55 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from bart.milos.co.za (bart.milos.co.za [196.38.18.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96AA343DD4 for ; Mon, 13 Nov 2006 20:32:35 +0000 (GMT) (envelope-from clay@milos.co.za) Received: (qmail 44828 invoked by uid 89); 13 Nov 2006 20:32:14 -0000 Received: from unknown (HELO claylaptop) (clay@milos.za.net@192.168.3.254) by bart.milos.co.za with SMTP; 13 Nov 2006 20:32:14 -0000 Message-ID: <007601c70762$c83c6860$9603a8c0@claylaptop> From: "Clayton Milos" To: References: <200611131633.kADGXO8J073080@lurza.secnetix.de><20061113171945.GA26567@icarus.home.lan> <20061113192239.GA1092@core.byshenk.net> Date: Mon, 13 Nov 2006 22:32:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: Subject: Re: Cruel and unusual problems with Proliant ML350 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 20:40:55 -0000 Same for me Greg. Everything I use runs on serial console including my *BSD servers, SUN, DSLAMs etc. I would say any server worth it's weight has serial redirection in it's BIOS. Most of the servers I admin are international and I use the sesrial console to fix problems if and when they arise. The majority are SUN which supports lights out management even. Then again when you're paying for SUN and running Oracle in clussters you kind of expect these kind of features. Saying that my 2 servers at home are Tyan motherboards with SMP. Both of them support serial redirection in in the BIOS and they are not particularly fancy motherboards. I use mainly WTI serial console management boxes. They have a few models which fit every need I've ever had. VPN into customer private LAN then telnetting into the console server sure as hell beats flying 4000 miles to sort something out. It's cheaper and faster. And besides that I have console access to the servers wherever I happen to be that and an internet connection. ----- Original Message ----- From: "Greg Byshenk" To: Sent: Monday, November 13, 2006 9:22 PM Subject: Re: Cruel and unusual problems with Proliant ML350 > On Mon, Nov 13, 2006 at 09:19:45AM -0800, Jeremy Chadwick wrote: > >> I'll agree with this (re: webservers not needing USB), except in >> regards to one item: keyboards. >> >> More and more x86 PCs these days are expecting keyboards to be >> USB-based. Yes, PS/2 ports are still present on most (but not all) >> motherboards, but eventually that will be phased out. >> >> I like the idea of being able to go to my co-location facility and >> plug in a USB keyboard to begin working on a server, and when >> finished remove the keyboard and leave. > > Don't you really need to have a monitor, as well? I _have_ worked > "blind" before, but I didn't enjoy it. I can imagine having a > keyboard with me when wandering around, but wouldn't normally have > a monitor. I had always thought that the preferred solution for > this sort of case was to use a serial console. > > And what seems to be becoming common on servers is a BIOS that allows > you to fully redirect to serial, including BIOS configuration. The > servers that I have recently purchased have had a keyboard and monitor > plugged into them _once_ -- for the first BIOS setup -- and then never > again. > > > -- > greg byshenk - gbyshenk@byshenk.net - Leiden, NL > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 20:45:39 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED4EA16A512 for ; Mon, 13 Nov 2006 20:45:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from sccrmhc15.comcast.net (sccrmhc15.comcast.net [63.240.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17D7143E1C for ; Mon, 13 Nov 2006 20:41:29 +0000 (GMT) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-67-174-220-97.hsd1.ca.comcast.net[67.174.220.97]) by comcast.net (sccrmhc15) with ESMTP id <2006111320404401500q1019e>; Mon, 13 Nov 2006 20:40:44 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1AE701FA01D; Mon, 13 Nov 2006 12:40:44 -0800 (PST) Date: Mon, 13 Nov 2006 12:40:44 -0800 From: Jeremy Chadwick To: Greg Byshenk Message-ID: <20061113204044.GA28811@icarus.home.lan> Mail-Followup-To: Greg Byshenk , freebsd-stable@FreeBSD.ORG References: <200611131633.kADGXO8J073080@lurza.secnetix.de> <20061113171945.GA26567@icarus.home.lan> <20061113192239.GA1092@core.byshenk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061113192239.GA1092@core.byshenk.net> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Cruel and unusual problems with Proliant ML350 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 20:45:40 -0000 On Mon, Nov 13, 2006 at 08:22:39PM +0100, Greg Byshenk wrote: > Don't you really need to have a monitor, as well? I _have_ worked > "blind" before, but I didn't enjoy it. I can imagine having a > keyboard with me when wandering around, but wouldn't normally have > a monitor. I had always thought that the preferred solution for > this sort of case was to use a serial console. Sure do (re: monitor). Most co-location facilities provide a "cart" that contains both keyboards and monitors on it, which you can wheel around and use for VGA console configuration. If you notice, though, most keyboard vendors (Logitech, Microsoft, Kensington, Dell, Apple, and I'm sure many others) are now selling USB-only keyboards. They do not include a USB-to-PS/2 adapter (and I'll remind people: the USB-to-PS/2 adapters you get for your mice *will not* work with PS/2 keyboards! Different protocol, same socket). So it's becoming hard to get PS/2 keyboards too! > And what seems to be becoming common on servers is a BIOS that allows > you to fully redirect to serial, including BIOS configuration. The > servers that I have recently purchased have had a keyboard and monitor > plugged into them _once_ -- for the first BIOS setup -- and then never > again. And I can speak about this a bit too, because I've spent the past 5 years fighting with serial console on x86 architecture in general. BIOS-level serial console, generally speaking, is utter garbage on most x86 servers I've dealt with. Sparcs have OpenBoot (or whatever it's called), which is apparently fantastic. Take SuperMicro, for example. These BIOSes provide only 3 options: what COM port you want serial console to use, what speed, and "leave Agent enabled after BIOS config". Some (hardly all) provide a 4th option: what terminal emulation you want (ANSI, VT100+, etc.). I won't talk about the emulation aspect, because anyone familiar with BIOS-level serial console knows what you get: crap. Full screen redraw a hundred times a second across a 9600bps connection? Yeah, sounds good! Screen clears for no particular reason? Awesome. Hey, did you want to read that BIOS output about "Bank 2 memory bad?" Nope, too bad, it's gone, replaced with random escape characters and missing data. Did you want hardware flow control with that BIOS? No sorry, we don't offer that, you'll have to accept missing characters. (Okay, so maybe I did talk about it.) The "Agent enabled" option is what you want to use to get serial console redirection to work with things like boot0, yadda yadda: that is, redirect the literal 80x25 text VGA console to a serial port. The problem is this: the instant any software on the host machine touches the serial port interrupt in any way shape or form, the BIOS Agent locks up, and you stop getting serial output altogether. You get nothing. Dead in the water. Nada. Zilch. I've spent a lot of time trying to get FreeBSD to **not** touch the serial port in any way. I can get boot0 to behave, and even boot2/loader to comply. But the instant the kernel loads (if I remember right, you never even see the Copyright message), even with device.hints saying sio.0.disabled="1" __or__ building the kernel w/out any sio device at all, you lose the Agent. Now I'll mention this part: has anyone here tried talking to a motherboard vendor before about BIOS changes, fixes, or any- thing of that nature? Good luck. You'll be stonewalled by a technical support group who seems to think whatever it is you want is a result of you not knowing what you're doing. "No, your ACPI DSDT is incorrect, I need to talk to an engineer" "OK we have forward mail to engineer, thanks you". *blink* All of this is where two pieces of present-day technology win: KVM-over-IP devices, and iLO/LOM cards. Now, the problem with those: iLO/LOM are only available with specific vendors (HP/Compaq and Sun), and many are known to be implemented in a bizarre way (that is, "sharing" an Ethernet port with the actual host mainboard. HP/Compaq doesn't do this, their iLO cards have their own Ethernet port/NIC). The problem with the 'shared' method is that it causes all sort-of ARP madness on local networks. It reminds me of the problem with IPMI modules right now, where the board essentially answers with two separate MAC addresses, confusing ARP tables all over the place. As for KVM-over-IP devices: fantastic in every way... except for price. They're overpriced by 4x or so. What you get is a generic 1U box which usually runs Linux, has some D-sub and PS/2 break-out boxes (you have to buy each one for US$50 each or so), uses open-source software, and has some ADCs. The cost? Oh, a miniscule US$4500 lets you handle 8 devices. There is a third solution: one of those PC Weasel cards. Awesome idea, but overpriced. I'm not going to pay US$350 per PCI card, I'm sorry. But in defence of the vendor, it's apparently one guy building them and running the whole outfit, so I guess I can understand the need for a higher profit margin and what not... but still, overpriced by a ton when you think about the cost of ICs that are used (they're in the cents range). Don't forget that these might not fit into a low-profile 1U box (the height of the card might not work with a riser/extender). For administrators who run small non-profit (that is, literally no profit *and* no cash-flow of any kind) organisations like myself, these products are big bucks. I can afford to shell out US$4500 for a KVM-over-IP box, but the vendor had better be licking my boots if I need any sort-of support, and had better be giving me free firmware upgrades. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 20:50:43 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6064F16A4D0 for ; Mon, 13 Nov 2006 20:50:43 +0000 (UTC) (envelope-from ShopAETV@newsletters.aetv.com) Received: from mta.newsletters.aetv.com (mta.newsletters.aetv.com [198.31.62.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2685343DA8 for ; Mon, 13 Nov 2006 20:50:33 +0000 (GMT) (envelope-from ShopAETV@newsletters.aetv.com) Date: Mon, 13 Nov 2006 15:50:23 -0500 (EST) Message-Id: From: "The History Channel" To: stable@freebsd.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Subject: $1 Shipping on All Lesson Plans X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 20:50:43 -0000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get $1 Shipping on Your entire Purchase at The History Education Shop. (Offer ends 12/19) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Shop Now>> http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trf0ED Our latest release of award-winning interactive lesson plans on CD-ROM-Multimedia Classroom Global History Series! >From towering Mayan temples, to the trenches of WWII, through the winding path of the Great Wall of China...this series of interactive lessons brings Global History alive! View all our lessons currently available in Global and American History Series...Shop Now http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trg0EE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Featured Lesson Plans http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trg0EE" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Plague CD-ROM Lesson Plan Set with DVD It turned the world upside down, and it spread faster than it could be understood. The "Black Death" that raged through the world during the Middle Ages was the most devastating...Read On>> http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trh0EF China and the Great Wall CD-ROM Lesson Plan Set with DVD Spanning nearly four centuries, the complex history of the Great Wall mirrors the history of China itself. From agricultural beginnings to a communist state, from...Read On>> http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Tri0EG Secrets of the Koran CD-ROM Lesson Plan Set with DVD Studied by more than a billion people worldwide, the Koran has left an indelible imprint on the world. This lesson examines the history of the verses and traces the influence of the Koran from...Read On>> http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trj0EH Latin America CD-ROM Lesson Plan Set with DVD Latin America 3 pack set includes Ponce de Leon : The First Conquistador, Mexico: Courage and Conquest and The Maya. These CD-ROM lesson plans...Read On>> http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trk0EI Multimedia Classroom American History Series (Volume 1) CD-ROM Lesson Plan Set with DVD History at your fingertips -- and on your screen! The History Channel Multimedia Classroom is a set of exciting new social studies teaching tools drawn from its award-winning program content. Each unit contains the following: - Short video segments that bring history topics to life - Maps and other visual materials - Discussion and review questions - Easily printable primary source documents - Classroom activities and Internet-based activity links And much more...Read On>> http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trl0EJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Shop Favorites http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Tr20EL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Revolution: The Series DVD Set Available for the first time in a single DVD set, this remarkable DVD set presents the entire series, and hence the entire American Revolution, from...Read On>> http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trm0EK The Presidents DVD set - A panoramic look at the personalities who have occupied the Oval Office. - Based on the acclaimed book "To the Best of My Ability." - Visit historic sites nationwide and examine rare presidential artifacts...Read On>> http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trn0EL The Last Days Of World War II DVD set This two-volume DVD set examines the period leading toward victory and the stunning revelations of the complex aftermath...Read On>> http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Tro0EM The Assassination of "Bobby" - The Death of Robert F. Kennedy DVD Set - Get the full picture with rare archival materials and exclusive interviews with friends, family members and confidantes. - Could Sirhan Sirhan have acted alone? - Respected journalist Mike Wallace undertakes an in-depth examination of the summer of RFK's killing...Read On>> http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trp0EN QUESTIONS? > VISIT our website at history.com/education http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trq0EO > E-MAIL us directly at educationsupport@history.com > CALL us toll free 1-800-344-6336. Thanks for watching, Your friends at History Education http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trq0EO ------------------------------------------------- To ensure delivery of Special Offers from History Education to your inbox(not bulk or junk folders), please add ShopAETV@newsletters.aetv.com to your address book. Your email address, stable@freebsd.org, is signed up to receive new release info and offers from our store. If you do not wish to receive future email offers from our store, simply unsubscribe. Unsub_Shop@newsletters.aetv.com We respect your privacy. For more information, view our privacy policy: http://newsletters.aetv.com/cgi-bin15/DM/y/eXgs0K6nDL0EFr0Trr0EP A&E Television Networks, Email Marketing 250 Harbor Drive, Stamford, CT 06902 From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 20:55:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D28C16A532; Mon, 13 Nov 2006 20:55:28 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ABDB43DA5; Mon, 13 Nov 2006 20:54:18 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kADKsGLe014903; Mon, 13 Nov 2006 15:54:16 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kADKsFvK045726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 15:54:15 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611132054.kADKsFvK045726@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Nov 2006 15:54:27 -0500 To: Scott Long From: Mike Tancsa In-Reply-To: <4557FF7A.8020704@samsco.org> References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 20:55:28 -0000 At 12:15 AM 11/13/2006, Scott Long wrote: >Is this with EM_INTR_FAST enabled also? Without it, the 2 streams are definitely lossy on the management interface ---Mike From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 21:39:11 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BE1716A515; Mon, 13 Nov 2006 21:39:11 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEEA943E81; Mon, 13 Nov 2006 21:30:47 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kADLUBlc085111; Mon, 13 Nov 2006 14:30:16 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4558E3DC.6080800@samsco.org> Date: Mon, 13 Nov 2006 14:30:04 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> <200611132054.kADKsFvK045726@lava.sentex.ca> In-Reply-To: <200611132054.kADKsFvK045726@lava.sentex.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , glebius@freebsd.org, freebsd-stable@freebsd.org, Jack Vogel Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 21:39:11 -0000 Mike Tancsa wrote: > At 12:15 AM 11/13/2006, Scott Long wrote: > > >> Is this with EM_INTR_FAST enabled also? > > > Without it, the 2 streams are definitely lossy on the management interface > > > ---Mike > > Ok, and would you be able to test the polling options as well? Scott From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 21:59:38 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDC0B16A49E for ; Mon, 13 Nov 2006 21:59:38 +0000 (UTC) (envelope-from om-lists-bsd@omx.ch) Received: from omega.omnis.ch (omega.omnis.ch [195.134.143.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 0D50743DA4 for ; Mon, 13 Nov 2006 21:58:02 +0000 (GMT) (envelope-from om-lists-bsd@omx.ch) Received: (qmail 9078 invoked from network); 13 Nov 2006 21:57:52 -0000 Received: from bigapple.omnis.ch ([195.134.148.35]) by omega.omnis.ch ([195.134.143.43]) with ESMTP via TCP; 13 Nov 2006 21:57:52 -0000 From: Olivier Mueller To: Ruslan Ermilov In-Reply-To: <20061113191454.GB66013@rambler-co.ru> References: <1163442609.10865.59.camel@bigapple.omnis.ch> <20061113191454.GB66013@rambler-co.ru> Content-Type: text/plain Date: Mon, 13 Nov 2006 22:57:50 +0100 Message-Id: <1163455070.14157.9.camel@bigapple.omnis.ch> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 21:59:39 -0000 On Mon, 2006-11-13 at 22:14 +0300, Ruslan Ermilov wrote: > Drivers that are either known to NOT work with PAE or were not > tested with PAE are excluded by the PAE config file, you can > check there. > So it looks like all of them should work fine with PAE. merci! > > Btw, when will we see these new servers listed under: > > http://www.freebsd.org/platforms/amd64/motherboards.html ? > > > And you absolutely have no option of running FreeBSD/amd64 on > them? What a PITA! :-) Ehm well, I must admit I never tried that, for a simple (and silly?) reason: freebsd installation selects the i386 SMP kernel by default... But of course if you (and Mike Jakubik) strongly suggest it would be a good idea, why not, I will give a try asap :-) Any special thing I should take care of when switching from the i686 kernel to the amd64 one? Will the systems be quicker this way, or will it "just" help with this 4GB memory limit? (systems are going to be "simple" web & mail hosting servers, with mysql, php, qmail, clamav, etc.). Regards, Olivier From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 22:16:48 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5333A16A525 for ; Mon, 13 Nov 2006 22:16:48 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2B4843DE3 for ; Mon, 13 Nov 2006 22:15:32 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from collaborativefusion.com (mx01.pub.collaborativefusion.com [206.210.89.201]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Mon, 13 Nov 2006 17:15:31 -0500 id 00056414.4558EE83.0000143D Received: from Internal Mail-Server by mx01 (envelope-from wmoran@collaborativefusion.com) with AES256-SHA encrypted SMTP; 13 Nov 2006 17:15:29 -0500 Date: Mon, 13 Nov 2006 17:15:29 -0500 From: Bill Moran To: stable@freebsd.org Message-Id: <20061113171529.a75fe20a.wmoran@collaborativefusion.com> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.10.6; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: em interrupt storm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 22:16:48 -0000 Just experienced an "interrupt storm" on an em device that disabled a server until I could reboot it. My initial research turned up this thread: http://lists.freebsd.org/pipermail/freebsd-current/2005-November/058336.html Which seems related, even if it is a little old. I'm aware that there have been problems with recent versions of the em driver but I haven't been following them closely enough, and there's a LOT of mail traffic on this topic. Note that this is a FreeBSD 5.3-RELEASE-p37 system. An upgrade is possible, but this is a production system and the problem occurs infrequently, so I'm reluctant to schedule downtime unless I have good reason to believe that it will fix the problem. Anyone remember if the above problem was fixed in more recent versions, or knows enough about the issue to comment on whether I'm barking up the correct tree or not? I'm pretty early in the diagnosis on this, but I'm looking for pointers to keep me from doing random upgrades or other time-wasting activities. -- Bill Moran Collaborative Fusion Inc. wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 22:24:00 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA5FF16A49E; Mon, 13 Nov 2006 22:24:00 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8022243EC0; Mon, 13 Nov 2006 22:22:12 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kADMM9iH041530; Mon, 13 Nov 2006 17:22:09 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kADMM8er046074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 17:22:09 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611132222.kADMM8er046074@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Nov 2006 17:22:20 -0500 To: Ivan Voras , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> <200611131248.kADCmieP043730@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner4 X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 22:24:01 -0000 At 12:50 PM 11/13/2006, Ivan Voras wrote: >Mike Tancsa wrote: > > At 12:15 AM 11/13/2006, Scott Long wrote: > > > >> Is this with EM_INTR_FAST enabled also? > > > > Yes. Havent done the stock case yet, but will do so later today. > >Do you have a comparison with Linux under the same circumstances? I had a disk with 64bit already installed. I will try with 32bit tomorrow. I can also try FreeBSD AMD64 on the box to see how it does. ifstat gives a bit of an odd output, but its the same sort of pattern where adding a second stream in the same direction, slows down the first one. On the box R2 [root@amd64 ifstat-1.1]# ifstat -b eth0 eth1 eth3 eth4 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 0.00 0.00 0.00 0.00 0.00 0.00 4.89 3.74 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 0.00 0.00 0.00 0.00 1.00 1.45 160965.0 0.00 0.00 0.00 0.00 0.00 0.83 1.95 0.00 0.00 0.00 272056.4 0.00 0.00 1.00 1.45 393994.2 0.00 0.00 0.00 0.00 0.00 5.47 1.45 0.00 0.00 0.00 393543.7 0.00 0.00 4.25 1.45 392911.0 0.00 0.00 0.00 0.00 0.00 2.50 1.45 0.00 0.00 0.50 392756.4 0.00 0.00 1.25 1.45 392626.7 0.00 0.00 0.00 0.00 0.00 1.75 1.45 0.00 0.00 0.00 393233.9 0.00 0.00 6.44 1.45 424068.1 0.00 0.00 0.00 0.00 0.00 1.74 1.45** 0.00 0.00 0.00 460503.1 0.00 0.00 2.72 1.45 509218.1 0.00 0.00 0.00 0.00 0.00 0.99 1.45 0.00 0.00 0.00 507800.4 0.00 0.00 0.50 1.45 502649.5 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 0.00 0.50 507537.1 0.00 0.00 0.50 1.46 519717.9 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 0.00 0.00 525973.4 0.00 0.00 0.50 1.46 520609.0 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 0.00 0.00 517888.6 0.00 0.00 0.50 1.45 525957.3 0.00 0.00 0.00 0.00 0.00 1.00 1.46 0.00 0.00 0.00 524119.9 0.00 0.00 0.50 1.45 522671.1 0.00 0.00 0.00 0.00 0.00 0.99 1.44 0.00 0.00 0.00 494008.7 0.00 0.00 0.50 1.45 390666.3 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 0.00 0.00 273779.6 0.00 0.00 0.50 1.45 0.00 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 [root@amd64 ifstat-1.1]# I added the second stream, going in the same direction at ** On one of the targets running netreceive you can see the impact. [tyan-1u]# ifstat -b rl0 bge0 Kbps in Kbps out Kbps in Kbps out 0.94 1.42 182716.2 0.00 0.47 1.05 182299.5 0.00 0.94 1.05 182493.4 0.33 0.94 2.09 182588.7 0.00 0.94 1.05 181959.8 0.00 0.47 1.05 104949.7 0.00 0.94 1.05 95674.27 0.00 0.47 1.05 95930.79 0.00 0.94 1.05 98329.93 0.00 0.94 1.05 97940.21 0.00 0.94 1.05 100636.9 0.00 0.47 1.05 99879.34 0.00 ^C [tyan-1u]# When the packets are bi-directional, the impact is not as great in LINUX as it is on FreeBSD [root@amd64 ifstat-1.1]# ifstat -b eth0 eth1 eth3 eth4 Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out Kbps in Kbps out 0.00 0.00 0.00 0.00 0.00 0.00 3.65 10.81 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 0.00 0.00 0.00 0.00 0.83 1.95 0.00 0.00 0.00 0.00 0.00 0.00 1.50 8.03 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 0.00 0.00 0.00 0.00 1.00 1.45 0.00 230009.2 0.00 0.00 0.00 0.00 2.83 51.22 0.00 0.00 334969.3 0.00 0.00 0.00 1.00 1.45 0.00 369184.5 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 369294.2 0.00 0.00 0.00 3.33 51.10 0.00 367348.7 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 367185.5 0.00 0.00 0.00 1.00 1.45 2541.17 368707.6 0.00 0.00 0.00 0.00 2.82 51.12 0.00 0.00 363265.6 95798.38 0.00 0.00 0.99 1.44 330239.4 357706.3 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 354181.1 326599.7 0.00 0.00 4.11 51.17 328691.7 356129.1 0.00 0.00 0.00 0.00 0.50 1.44 0.00 0.00 358321.6 330567.1 0.00 0.00 1.50 1.45 329516.7 342389.2 0.00 0.00 0.00 0.00 0.99 14.99 0.00 0.00 334539.9 330647.5 0.00 0.00 0.99 1.44 330982.0 326772.6 0.00 0.00 0.00 0.00 0.50 1.44 0.00 0.00 329472.7 333109.3 0.00 0.00 2.32 14.45 324457.4 327537.4 0.00 0.00 0.00 0.00 0.50 1.44 0.00 0.00 329367.2 317784.0 0.00 0.00 0.99 1.44 308120.8 333789.8 0.00 0.00 0.00 0.00 1.80 20.78 0.00 0.00 331200.2 316116.3 0.00 0.00 1.00 1.45 370504.6 88001.99 0.00 0.00 0.00 0.00 0.50 1.44 0.00 0.00 0.50 392417.6 0.00 0.00 2.82 21.76 394057.2 0.00 0.00 0.00 0.00 0.00 0.83 1.95 0.00 0.00 0.00 394048.2 0.00 0.00 1.00 1.45 394306.3 0.00 0.00 0.00 0.00 0.00 3.66 52.56 0.00 0.00 0.00 393960.8 0.00 0.00 1.00 1.45 373321.8 0.00 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 0.00 261093.7 0.00 0.00 2.33 9.66 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 0.00 0.00 0.00 0.00 0.00 0.00 0.50 1.45 The box is totally responsive throughout with no packet loss on the management interface.... However, it seems quite a bit slower than FreeBSD when its tweaked with ADAPTIVE_GIANT removed... But again, this is 64bit so not quite apples to apples yet. Also, I need to check the default driver config to see if their NAPI or whatever its called is enabled. More tests to come. ---Mike >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 22:35:25 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FA9E16A4CE for ; Mon, 13 Nov 2006 22:35:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F32543E13 for ; Mon, 13 Nov 2006 22:30:52 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so789486pyh for ; Mon, 13 Nov 2006 14:30:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ek6PD136v/bAuJws6W39+Gy2MULWMDGTctfKsH9Zn7DVJtnHvWCbRt3bzonP1vc6peSAm9qkKkAOhgYyEysz5p6K6hW1BizllNL8HlkraNzsTe8sM9BFVW/93eUBY/GLHGm5ytimysSBUusrgl3PC4a4JkPeOf69pqbPR8ftO+8= Received: by 10.35.82.15 with SMTP id j15mr295160pyl.1163457001739; Mon, 13 Nov 2006 14:30:01 -0800 (PST) Received: by 10.35.118.6 with HTTP; Mon, 13 Nov 2006 14:30:01 -0800 (PST) Message-ID: <2a41acea0611131430x3c9206f4ua1ffe6cbf5e82202@mail.gmail.com> Date: Mon, 13 Nov 2006 14:30:01 -0800 From: "Jack Vogel" To: "Bill Moran" In-Reply-To: <20061113171529.a75fe20a.wmoran@collaborativefusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061113171529.a75fe20a.wmoran@collaborativefusion.com> Cc: stable@freebsd.org Subject: Re: em interrupt storm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 22:35:25 -0000 On 11/13/06, Bill Moran wrote: > > Just experienced an "interrupt storm" on an em device that disabled a > server until I could reboot it. > > My initial research turned up this thread: > http://lists.freebsd.org/pipermail/freebsd-current/2005-November/058336.html > > Which seems related, even if it is a little old. I'm aware that there > have been problems with recent versions of the em driver but I haven't > been following them closely enough, and there's a LOT of mail traffic > on this topic. > > Note that this is a FreeBSD 5.3-RELEASE-p37 system. An upgrade is > possible, but this is a production system and the problem occurs > infrequently, so I'm reluctant to schedule downtime unless I have good > reason to believe that it will fix the problem. > > Anyone remember if the above problem was fixed in more recent versions, > or knows enough about the issue to comment on whether I'm barking up > the correct tree or not? I'm pretty early in the diagnosis on this, > but I'm looking for pointers to keep me from doing random upgrades or > other time-wasting activities. There were fixes to things that MIGHT be a cause of an interrupt storm in the em driver, but without knowing more about your specific hardware and the event when it happened its hard to pontificate :) As an aside, I would think getting off 5.3 would be desireable in and of itself :) Can you give a vmstat -i, a pciconf -l, and maybe messages when the storm occurred? Thanks Bill, Jack From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 22:41:22 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FAB916A47B for ; Mon, 13 Nov 2006 22:41:22 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id D145543D73 for ; Mon, 13 Nov 2006 22:39:05 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 0C8B85EF0; Tue, 14 Nov 2006 01:38:59 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id DEF715ED9; Tue, 14 Nov 2006 01:38:58 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kADMd4E4084378; Tue, 14 Nov 2006 01:39:04 +0300 (MSK) (envelope-from ru) Date: Tue, 14 Nov 2006 01:39:04 +0300 From: Ruslan Ermilov To: Olivier Mueller Message-ID: <20061113223904.GB84153@rambler-co.ru> References: <1163442609.10865.59.camel@bigapple.omnis.ch> <20061113191454.GB66013@rambler-co.ru> <1163455070.14157.9.camel@bigapple.omnis.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FkmkrVfFsRoUs1wW" Content-Disposition: inline In-Reply-To: <1163455070.14157.9.camel@bigapple.omnis.ch> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-stable@freebsd.org Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 22:41:22 -0000 --FkmkrVfFsRoUs1wW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2006 at 10:57:50PM +0100, Olivier Mueller wrote: > On Mon, 2006-11-13 at 22:14 +0300, Ruslan Ermilov wrote: > > > Btw, when will we see these new servers listed under: > > > http://www.freebsd.org/platforms/amd64/motherboards.html ?=20 > > >=20 > > And you absolutely have no option of running FreeBSD/amd64 on > > them? What a PITA! :-) >=20 > Ehm well, I must admit I never tried that, for a simple (and silly?) > reason: freebsd installation selects the i386 SMP kernel by default... >=20 Because you're trying to install FreeBSD/i386 on it; download and burn the FreeBSD/amd64 ISOs instead -- it will select an amd64 SMP kernel then. > But of course if you (and Mike Jakubik) strongly suggest it would be a > good idea, why not, I will give a try asap :-) Any special thing I > should take care of when switching from the i686 kernel to the amd64 > one? >=20 It will be a 64-bit world with 64-bit time_t. ;) > Will the systems be quicker this way, or will it "just" help > with this 4GB memory limit? >=20 Quicker - probably not. Will certainly help with the 4G limit. > (systems are going to be "simple" web & > mail hosting servers, with mysql, php, qmail, clamav, etc.). >=20 It should be fine then. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --FkmkrVfFsRoUs1wW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWPQIqRfpzJluFF4RAsNnAJ0RWmrh6qylOX9QVDwRqssvcfoALgCfdH/5 HcowqVdWWWzwFNEHkg5fuT4= =hez4 -----END PGP SIGNATURE----- --FkmkrVfFsRoUs1wW-- From owner-freebsd-stable@FreeBSD.ORG Mon Nov 13 23:45:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17DCC16A416 for ; Mon, 13 Nov 2006 23:45:53 +0000 (UTC) (envelope-from pmurray@nevada.net.nz) Received: from bellagio.open2view.net (bellagio.open2view.net [210.48.79.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B183D43D5A for ; Mon, 13 Nov 2006 23:45:40 +0000 (GMT) (envelope-from pmurray@nevada.net.nz) Received: from [10.58.3.94] (ip-58-28-155-250.ubs-dsl.xnet.co.nz [58.28.155.250]) by bellagio.open2view.net (Postfix) with ESMTP id 7019568AF59 for ; Fri, 10 Nov 2006 12:01:18 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-stable@freebsd.org From: Philip Murray Date: Fri, 10 Nov 2006 12:01:07 +1300 X-Mailer: Apple Mail (2.752.3) Subject: Terrible (3Ware) disk performance in 6.2-BETA3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 23:45:53 -0000 Hi, I just installed FreeBSD 6.2-BETA3 (amd64) on a Dual Xeon DC 5140 w/ 4GB of RAM and a 3ware 9550SX connected to 8x Seagate 250GB SATA drives (RAID5) and instead of the normal great performance I get from FreeBSD, it's taking over an hour to do a 'portsnap extract' and while it's doing it, the system gets very unresponsive (trouble logging in via SSH, commands sit for several seconds before executing). On two other machines with the same 3Ware 9550SX (and disks) but dual Opteron 248s, the portsnap extract operation only takes a short (relatively) amount of time to complete. The RAID array is fine, it's not rebuilding or degraded of anything. I've tried turning the write cache on the controller on/off. Where do I start looking to find the culprit? gstat reports the following during the portsnap extract: L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 416 70 0 0 0.0 70 160 12149.0 101.7| da0 Cheers Phil dmesg: Copyright (c) 1992-2006 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 6.2-BETA3 #0: Mon Oct 30 22:03:42 UTC 2006 root@meyers.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5140 @ 2.33GHz (2333.43-MHz K8- class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e3bd,CX16,,,> AMD Features=0x20000800 AMD Features2=0x1 Cores per package: 2 real memory = 5368709120 (5120 MB) avail memory = 4114276352 (3923 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 cpu2: on acpi0 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 cpu3: on acpi0 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: irq 18 at device 2.0 on pci2 pci4: on pcib4 em0: port 0x2000-0x201f mem 0xc8200000-0xc821ffff irq 18 at device 0.0 on pci4 em0: Ethernet address: 00:30:48:88:a5:06 em1: port 0x2020-0x203f mem 0xc8220000-0xc823ffff irq 19 at device 0.1 on pci4 em1: Ethernet address: 00:30:48:88:a5:07 pcib5: at device 0.3 on pci1 pci5: on pcib5 3ware device driver for 9000 series storage controllers, version: 3.60.02.012 twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem 0xca000000-0xcbffffff,0xc8300000-0xc8300fff irq 24 at device 1.0 on pci5 twa0: [FAST] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-8LP, 8 ports, Firmware FE9X 3.01.01.028, BIOS BE9X 3.01.00.024 pci0: at device 8.0 (no driver attached) pcib6: irq 17 at device 28.0 on pci0 pci6: on pcib6 uhci0: port 0x1800-0x181f irq 17 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xc8000000-0xc80003ff irq 17 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib7: at device 30.0 on pci0 pci7: on pcib7 pci7: at device 1.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcc7ff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 100.000MB/s transfers da0: 1668856MB (3417817088 512 byte sectors: 255H 63S/T 212749C) Trying to mount root from ufs:/dev/da0s1a From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 00:07:36 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4A5216A412; Tue, 14 Nov 2006 00:07:36 +0000 (UTC) (envelope-from miroslav@svishtov.net) Received: from mail.svishtov.net (mail.svishtov.net [85.217.192.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id E32FD43D64; Tue, 14 Nov 2006 00:07:33 +0000 (GMT) (envelope-from miroslav@svishtov.net) X-Spam-Status: No, hits=4.8 required=7.5 tests=AWL: -1.141,BAYES_99: 4.07,HTML_50_60: 0.539, HTML_MESSAGE: 0.001,RCVD_NUMERIC_HELO: 1.348 X-Spam-Level: **** Received: from 85.217.217.217 ([85.217.217.217]) by mail.svishtov.net (Kerio MailServer 6.1.1) for miroslav@svishtov.net; Tue, 14 Nov 2006 01:15:23 +0200 From: =?utf-8?Q?=D0=9C=D0=B8=D1=80=D0=BE=D1=81=D0=BB=D0=B0=D0=B2?= =?utf-8?Q?_=D0=A1=D0=BB=D0=B0=D0=B2=D0=BA=D0=BE=D0=B2?= To: Mike Tancsa ,Ivan Voras ,freebsd-stable@freebsd.org In-Reply-To: <200611132222.kADMM8er046074@lava.sentex.ca> Message-ID: <20061113231523.b6d6a902@mail.svishtov.net> Date: Tue, 14 Nov 2006 01:15:23 +0200 X-Mailer: Kerio MailServer 6.1.1 WebMail X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 00:07:36 -0000 Hey. I've got one new machine for testing for 1-2 days... here's some = output.. With the latest drivers (cvsup'ed from yesterday) Send box: 2x Intel Xeon 5110 (1.6GHz), SuperMicro X7-DBE, Intel Pro/1000= MT Server Adapter CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (1600.01-MHz 686-cl= ass CPU) Origin =3D "GenuineIntel" Id =3D 0x6f6 Stepping =3D 6 Features=3D0xbfebfbff Features2=3D0x4e33d,CX16,,,> AMD Features=3D0x20100000 AMD Features2=3D0x1 Cores per package: 2 real memory =3D 1073086464 (1023 MB) avail memory =3D 1040961536 (992 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Recv box: AMD Sempron 3800+, (Some nVidia chipset.. maybe 4), Intel Pro/= 1000 PT Desktop Adapter system load is around 2 EM=5FINTR=5FFAST is defined (if not defined load is higher..5-6) [root@serverx ~]# iperf -c 172.16.133.2 -t 9999999 ------------------------------------------------------------ Client connecting to 172.16.133.2, TCP port 5001 TCP window size: 129 KByte (default) ------------------------------------------------------------ [ 3] local 172.16.133.1 port 58425 connected with 172.16.133.2 port 500= 1 ^C[ 3] 0.0-48.1 sec 4.87 GBytes 869 Mbits/sec [root@serverx ~]# ifstat -b em0 em2 Kbps in Kbps out Kbps in Kbps out 46117.87 885607.5 12.76 1.45 45892.97 879815.3 22.61 1.07 ifstat: warning: rollover for interface em0, reinitialising. 0.00 0.00 581.95 1.07 46436.31 890665.0 700.36 2.27 46062.60 884031.1 794.26 1.07 46576.76 893408.4 846.86 1.07 47117.81 903658.6 859.40 1.07 46141.71 885471.3 867.05 1.07 45926.92 881372.1 363.41 1.07 46003.51 883432.4 35.64 1.07 46052.45 884164.9 28.41 1.07 45863.03 880448.1 12.66 1.07 46152.73 885549.1 33.71 1.07 46737.09 896811.9 39.02 1.07 46188.92 885847.3 58.92 1.07 45770.39 878602.0 19.24 1.07 46743.62 896967.0 34.72 1.07 46412.27 890970.9 34.65 1.07 46322.73 888747.3 26.61 1.07 46002.64 882522.8 23.69 1.07 46450.56 891662.8 26.91 1.07 45991.55 882605.9 37.92 1.07 46067.28 883815.5 34.82 1.07 46120.28 885357.6 33.79 1.07 46133.17 885316.5 21.56 1.07 46700.43 895554.6 10.12 1.49 45476.68 873874.2 15.78 1.07 45791.88 878655.9 15.99 1.07 46344.84 889292.8 7.72 1.07 46577.31 893572.1 10.49 1.07 46065.09 884277.6 8.77 1.07 46566.97 892898.4 6.07 1.07 46232.46 886846.8 13.02 1.07 46165.29 886647.9 7.47 1.07 46080.80 884256.7 14.54 1.07 46757.57 896977.8 14.59 1.07 46182.78 885594.3 10.30 1.07 46103.81 885661.0 13.95 1.07 46469.89 891511.3 13.85 1.07 46470.86 891611.1 11.42 1.07 From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 00:50:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E76316A403; Tue, 14 Nov 2006 00:50:54 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7814643D8D; Tue, 14 Nov 2006 00:50:53 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAE0oaiA086650; Mon, 13 Nov 2006 17:50:42 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <455912DC.1020101@samsco.org> Date: Mon, 13 Nov 2006 17:50:36 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mike Tancsa References: <2a41acea0611081719h31be096eu614d2f2325aff511@mail.gmail.com> <200611091536.kA9FaltD018819@lava.sentex.ca> <45534E76.6020906@samsco.org> <200611092200.kA9M0q1E020473@lava.sentex.ca> <200611102004.kAAK4iO9027778@lava.sentex.ca> <2a41acea0611101400w5b8cef40ob84ed6de181f3e2c@mail.gmail.com> <200611102221.kAAML6ol028630@lava.sentex.ca> <455570D8.6070000@samsco.org> <200611120412.kAC4CuIB035746@lava.sentex.ca> <45574ECA.4080207@samsco.org> <200611130040.kAD0etbp040637@lava.sentex.ca> <4557CECD.2000609@samsco.org> <200611130158.kAD1wdKE040908@lava.sentex.ca> <4557EF13.9060305@samsco.org> <200611130454.kAD4sZwe041556@lava.sentex.ca> <4557FF7A.8020704@samsco.org> <200611131248.kADCmieP043730@lava.sentex.ca> <200611132222.kADMM8er046074@lava.sentex.ca> In-Reply-To: <200611132222.kADMM8er046074@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 00:50:54 -0000 Mike Tancsa wrote: > At 12:50 PM 11/13/2006, Ivan Voras wrote: >> Mike Tancsa wrote: >> > At 12:15 AM 11/13/2006, Scott Long wrote: >> > >> >> Is this with EM_INTR_FAST enabled also? >> > >> > Yes. Havent done the stock case yet, but will do so later today. >> >> Do you have a comparison with Linux under the same circumstances? > > I had a disk with 64bit already installed. I will try with 32bit > tomorrow. I can also try FreeBSD AMD64 on the box to see how it does. > > ifstat gives a bit of an odd output, but its the same sort of pattern > where adding a second stream in the same direction, slows down the first > one. On the box R2 ... > > The box is totally responsive throughout with no packet loss on the > management interface.... However, it seems quite a bit slower than > FreeBSD when its tweaked with ADAPTIVE_GIANT removed... But again, this > is 64bit so not quite apples to apples yet. Also, I need to check the > default driver config to see if their NAPI or whatever its called is > enabled. More tests to come. > > ---Mike More excellent data, thanks. I have some changes on the drawing board that should significantly improve forwarding and bridging in the em driver. Do you have a limit on how much more time you can spend on these tests? It might be a week or more before I have anything that can be tested. Scott From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 03:13:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD43F16A417; Tue, 14 Nov 2006 03:13:45 +0000 (UTC) (envelope-from michael@staff.openaccess.org) Received: from smtp.openaccess.org (smtp.openaccess.org [66.165.52.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6FA543D62; Tue, 14 Nov 2006 03:13:43 +0000 (GMT) (envelope-from michael@staff.openaccess.org) Received: from localhost (unknown [66.165.52.46]) by smtp.openaccess.org (Postfix) with ESMTP id 1BB336D4413; Mon, 13 Nov 2006 19:13:43 -0800 (PST) X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999.99 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=1.77] Received: from smtp.openaccess.org ([66.165.52.46]) by localhost (smtp.openaccess.org [66.165.52.46]) (amavisd-new, port 10024) with ESMTP id tjAnJiFd7Ho1; Mon, 13 Nov 2006 19:12:20 -0800 (PST) Received: from [192.168.2.151] (staff.openaccess.org [216.57.214.98]) by smtp.openaccess.org (Postfix) with ESMTP id 182946D42F2; Mon, 13 Nov 2006 19:12:20 -0800 (PST) In-Reply-To: <20061113231523.b6d6a902@mail.svishtov.net> References: <20061113231523.b6d6a902@mail.svishtov.net> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <55334658-D4A4-47AE-AF76-B76135881654@staff.openaccess.org> From: Michael DeMan Date: Mon, 13 Nov 2006 19:12:19 -0800 To: =?UTF-8?B?0JzQuNGA0L7RgdC70LDQsiDQodC70LDQstC60L7Qsg==?= X-Mailer: Apple Mail (2.752.2) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Proposed 6.2 em RELEASE patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 03:13:46 -0000 Hi All, Unfortunately our company hasn't had the resources to help FreeBSD =20 much over the years, but I do want to say thank you to the folks who =20 are helping sort out this issue with the em driver. That Intel gigabit interface is very, very common on server hardware =20 nowadays and it means a lot to us to make sure it (and FreeBSD 6.2 in =20= general) are stable. - mike Michael F. DeMan Director of Technology OpenAccess Network Services Bellingham, WA 98225 michael@staff.openaccess.org 360-647-0785 --- If your question is support related, please contact =20 support@openaccess.org directly for faster assistance --- On Nov 13, 2006, at 3:15 PM, =D0=9C=D0=B8=D1=80=D0=BE=D1=81=D0=BB=D0=B0=D0= =B2 =D0=A1=D0=BB=D0=B0=D0=B2=D0=BA=D0=BE=D0=B2 wrote: > Hey. I've got one new machine for testing for 1-2 days... here's =20 > some output.. > > With the latest drivers (cvsup'ed from yesterday) > > Send box: 2x Intel Xeon 5110 (1.6GHz), SuperMicro X7-DBE, Intel Pro/=20= > 1000 MT Server Adapter > > CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (1600.01-MHz =20 > 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x6f6 Stepping =3D 6 > =20 > Features=3D0xbfebfbff GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE=20= > > > =20 > Features2=3D0x4e33d,CX16,,,= =20 > > > AMD Features=3D0x20100000 > AMD Features2=3D0x1 > Cores per package: 2 > real memory =3D 1073086464 (1023 MB) > avail memory =3D 1040961536 (992 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > > Recv box: AMD Sempron 3800+, (Some nVidia chipset.. maybe 4), Intel =20= > Pro/1000 PT Desktop Adapter > > system load is around 2 > EM_INTR_FAST is defined (if not defined load is higher..5-6) > > [root@serverx ~]# iperf -c 172.16.133.2 -t 9999999 > ------------------------------------------------------------ > Client connecting to 172.16.133.2, TCP port 5001 > TCP window size: 129 KByte (default) > ------------------------------------------------------------ > [ 3] local 172.16.133.1 port 58425 connected with 172.16.133.2 =20 > port 5001 > ^C[ 3] 0.0-48.1 sec 4.87 GBytes 869 Mbits/sec > > > [root@serverx ~]# ifstat -b > em0 em2 > Kbps in Kbps out Kbps in Kbps out > 46117.87 885607.5 12.76 1.45 > 45892.97 879815.3 22.61 1.07 > ifstat: warning: rollover for interface em0, reinitialising. > 0.00 0.00 581.95 1.07 > 46436.31 890665.0 700.36 2.27 > 46062.60 884031.1 794.26 1.07 > 46576.76 893408.4 846.86 1.07 > 47117.81 903658.6 859.40 1.07 > 46141.71 885471.3 867.05 1.07 > 45926.92 881372.1 363.41 1.07 > 46003.51 883432.4 35.64 1.07 > 46052.45 884164.9 28.41 1.07 > 45863.03 880448.1 12.66 1.07 > 46152.73 885549.1 33.71 1.07 > 46737.09 896811.9 39.02 1.07 > 46188.92 885847.3 58.92 1.07 > 45770.39 878602.0 19.24 1.07 > 46743.62 896967.0 34.72 1.07 > 46412.27 890970.9 34.65 1.07 > 46322.73 888747.3 26.61 1.07 > 46002.64 882522.8 23.69 1.07 > 46450.56 891662.8 26.91 1.07 > 45991.55 882605.9 37.92 1.07 > 46067.28 883815.5 34.82 1.07 > 46120.28 885357.6 33.79 1.07 > 46133.17 885316.5 21.56 1.07 > 46700.43 895554.6 10.12 1.49 > 45476.68 873874.2 15.78 1.07 > 45791.88 878655.9 15.99 1.07 > 46344.84 889292.8 7.72 1.07 > 46577.31 893572.1 10.49 1.07 > 46065.09 884277.6 8.77 1.07 > 46566.97 892898.4 6.07 1.07 > 46232.46 886846.8 13.02 1.07 > 46165.29 886647.9 7.47 1.07 > 46080.80 884256.7 14.54 1.07 > 46757.57 896977.8 14.59 1.07 > 46182.78 885594.3 10.30 1.07 > 46103.81 885661.0 13.95 1.07 > 46469.89 891511.3 13.85 1.07 > 46470.86 891611.1 11.42 1.07 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 04:36:11 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E31BE16A403 for ; Tue, 14 Nov 2006 04:36:11 +0000 (UTC) (envelope-from lxv@omut.org) Received: from mail.omut.org (mail.omut.org [216.218.215.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99DC643D5A for ; Tue, 14 Nov 2006 04:36:11 +0000 (GMT) (envelope-from lxv@omut.org) Received: from tadpole.omut.org (mix-anchor.intranet [10.10.10.251]) by mail.omut.org (8.13.8/8.13.8) with ESMTP id kAE4a8IK057263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Nov 2006 20:36:08 -0800 (PST) (envelope-from lxv@omut.org) Received: from tadpole.intranet (localhost [127.0.0.1]) by tadpole.omut.org (8.13.8/8.13.8) with ESMTP id kAE4a75J088372 for ; Mon, 13 Nov 2006 23:36:07 -0500 (EST) (envelope-from lxv@tadpole.intranet) Received: (from lxv@localhost) by tadpole.intranet (8.13.8/8.13.8/Submit) id kAE4a1wZ088371 for freebsd-stable@freebsd.org; Mon, 13 Nov 2006 23:36:01 -0500 (EST) (envelope-from lxv) Date: Mon, 13 Nov 2006 23:36:01 -0500 From: Alex Vasylenko To: freebsd-stable@freebsd.org Message-ID: <20061114043601.GB88156@tadpole.intranet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Scanned-By: MIMEDefang 2.57 on 216.218.215.140 Subject: panic in swap_pager_swap_init (amd64/smp/6.2-pre) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Vasylenko List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 04:36:12 -0000 I tried to upgrade an amd64x2 box from "FreeBSD 6.1-STABLE #36: Mon Sep 4 11:22:15 EDT 2006" to "FreeBSD 6.2-PRERELEASE #1: Mon Nov 13 10:01:57 EST 2006" and found that a newly built kernel panics on boot and locks up solid after printing: SMP: AP CPU #1 Launched! panic: failed to create swap_zone. A few reboots later I also discovered that: - GENERIC (UP) kernel works fine; - SMP kernel fails in the same way; - my kernel (a stripped down SMP) with "options SMP" removed works; - my kernel with SMP enabled and either -v or -d (followed by cont) works. ("works" in the last case is defined as: I could upgrade gnome 2.14->2.16 with buildworld -j2 going at the same time) old dmesg: http://www.omut.org/~lxv/bbox-dmesg-20060824 new dmesg (-v): http://www.omut.org/~lxv/bbox-dmesg-20061113-v kernel config: http://www.omut.org/~lxv/bbox-GENERIC-BBOX Any advice is greatly appreciated. Thank you, -- Alex. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 04:44:54 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07FA516A403 for ; Tue, 14 Nov 2006 04:44:54 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65B6B43D46 for ; Tue, 14 Nov 2006 04:44:53 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id CA7A74D05F for ; Tue, 14 Nov 2006 04:44:56 +0000 (GMT) Received: from smitch7.jumbuck.com (unknown [206.112.99.82]) by p4.roq.com (Postfix) with ESMTP id 9F4E24D05C for ; Tue, 14 Nov 2006 04:44:56 +0000 (GMT) Received: from smitch7.jumbuck.com (mail.jumbuck.com [206.112.99.82]) by smitch7.jumbuck.com (Postfix) with ESMTP id 56C35411804; Tue, 14 Nov 2006 04:44:52 +0000 (UTC) Received: from [192.168.46.102] (ppp166-27.static.internode.on.net [150.101.166.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smitch7.jumbuck.com (Postfix) with ESMTP id 9D059411802; Tue, 14 Nov 2006 04:44:51 +0000 (UTC) Message-ID: <455949C1.8090105@thebeastie.org> Date: Tue, 14 Nov 2006 15:44:49 +1100 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.13) Gecko/20060727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Mueller References: <1163442609.10865.59.camel@bigapple.omnis.ch> In-Reply-To: <1163442609.10865.59.camel@bigapple.omnis.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 04:44:54 -0000 Olivier Mueller wrote: >Hello, > >I will soon get some new servers with more than 4 GB of RAM, and >I am wondering if they will work fine even with the PAE >option activated: are all the required drivers (RAID mfid, bce >on the Dell, ciss0 on the HP) 100% compatible, or should I expect >trouble? > >If you have a working "/usr/src/sys/i386/conf/xxxx" with active >PAE on one of these servers, I'd be interested :) > >Btw, when will we see these new servers listed under: >http://www.freebsd.org/platforms/amd64/motherboards.html ? >Or should I use send-pr ? :) > >Thanks & regards, >Olivier > >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > I have one of these. The ethernet device (bce) kept falling over on release as well as other stability problems (forget them all now) I am running stable from September the 8th on it which appears to be a good time as it was before any new funkier ethernet device commits where a lot of people started complaining about em and bce timeout probs. I posted a basic Ethernet speed of this machine a while back, 92mbytes/sec is bad but its not as fast with my Dells with em devices on 6.1 release. Bce HP to Em Dell HPDL380# cat /dev/zero | dd bs=1m | nc dell2 3000 ^C0+19648 records in 0+19648 records out 1287606272 bytes transferred in 13.926151 secs (92,459,594 bytes/sec) I don't really like these machines at all compared to the Dells, mainly because the bios is very disappointing and even 'stupid' in my opinion. Its important to note that in key areas its actually quite different from from the G4 and older generations, its hard to navigate/use and isn't as remotely useful compared to Dells bios, that said again is my opinion! They also skimp on a bunch of things that they know most people don't know about, like battery backed write cache in their controller cards, any of the mid to high end servers you see on the Dell web site specs list the battery backed controller card quite clearly. So with a default setup of these HP's you don't get any write cache from the 256meg controller cache unless you want to go down a more dodgey road manually enable it and risk data loss if you loose sudden power. I am also considering using PAE on it over its current AMD64 mode as I have special requirements. I had to get one of these as we needed a machine fast which they did come through on. Mike From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 05:34:51 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CACB16A40F for ; Tue, 14 Nov 2006 05:34:51 +0000 (UTC) (envelope-from jcw@highperformance.net) Received: from mx1.highperformance.net (dsl081-163-122.sea1.dsl.speakeasy.net [64.81.163.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 267C943D58 for ; Tue, 14 Nov 2006 05:34:51 +0000 (GMT) (envelope-from jcw@highperformance.net) Received: from [192.168.1.16] (w16.stradamotorsports.com [192.168.1.16]) by mx1.highperformance.net (8.13.6/8.13.4) with ESMTP id kAE5YkwY033712 for ; Mon, 13 Nov 2006 21:34:46 -0800 (PST) (envelope-from jcw@highperformance.net) Message-ID: <45595578.5070703@highperformance.net> Date: Mon, 13 Nov 2006 21:34:48 -0800 From: "Jason C. Wells" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on s4.stradamotorsports.com Subject: -mfpmath=sse? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 05:34:51 -0000 I am reading this document: http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/i386-and-x86_002d64-Options.html Does |-march=|pentium3 imply |-mfpmath=sse?| Thanks, Jason C. Wells From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 06:02:15 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20A1216A40F for ; Tue, 14 Nov 2006 06:02:15 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A03AB43D46 for ; Tue, 14 Nov 2006 06:02:14 +0000 (GMT) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id D75DD9A213C; Tue, 14 Nov 2006 07:02:09 +0100 (CET) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1kYUPc2cNPR4; Tue, 14 Nov 2006 07:02:04 +0100 (CET) Received: from [192.168.2.186] (catv-50635cb6.catv.broadband.hu [80.99.92.182]) by server.t-hosting.hu (Postfix) with ESMTP id 18D089A212D; Tue, 14 Nov 2006 07:02:04 +0100 (CET) Message-ID: <45595BD5.6020901@FreeBSD.org> Date: Tue, 14 Nov 2006 07:01:57 +0100 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Jason C. Wells" References: <45595578.5070703@highperformance.net> In-Reply-To: <45595578.5070703@highperformance.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: -mfpmath=sse? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 06:02:15 -0000 Jason C. Wells wrote: > I am reading this document: > > http://gcc.gnu.org/onlinedocs/gcc-3.4.4/gcc/i386-and-x86_002d64-Options.html > > > Does |-march=|pentium3 imply |-mfpmath=sse?| > > Thanks, > Jason C. Wells > No. I tried such flags, and there were some applications that failed with "-march=athlon64 -mfpmath=sse", but not with "-march=athlon64", so -march=pentium3 can't imply it either. -- Cheers, Gabor From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 06:06:33 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E60D516A403 for ; Tue, 14 Nov 2006 06:06:33 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A75D843D58 for ; Tue, 14 Nov 2006 06:06:33 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 8F4191A3C19; Mon, 13 Nov 2006 22:06:33 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B4AC25138B; Tue, 14 Nov 2006 01:06:22 -0500 (EST) Date: Tue, 14 Nov 2006 01:06:22 -0500 From: Kris Kennaway To: Alex Vasylenko Message-ID: <20061114060622.GA61080@xor.obsecurity.org> References: <20061114043601.GB88156@tadpole.intranet> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <20061114043601.GB88156@tadpole.intranet> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: panic in swap_pager_swap_init (amd64/smp/6.2-pre) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 06:06:34 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2006 at 11:36:01PM -0500, Alex Vasylenko wrote: > I tried to upgrade an amd64x2 box from "FreeBSD 6.1-STABLE #36: Mon Sep > 4 11:22:15 EDT 2006" to "FreeBSD 6.2-PRERELEASE #1: Mon Nov 13 10:01:57 > EST 2006" and found that a newly built kernel panics on boot and locks > up solid after printing: > SMP: AP CPU #1 Launched! > panic: failed to create swap_zone. >=20 > A few reboots later I also discovered that: > - GENERIC (UP) kernel works fine; > - SMP kernel fails in the same way; > - my kernel (a stripped down SMP) with "options SMP" removed works; > - my kernel with SMP enabled and either -v or -d (followed by cont) > works. > ("works" in the last case is defined as: I could upgrade gnome > 2.14->2.16 with buildworld -j2 going at the same time) That's quite odd, since afaik boot -v doesn't change any behaviour apart from some printfs. Is this still repeatable, i.e. it didn't in fact go away after you rebuilt your kernel from scratch during the course of the above testing? Kris --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWVzeWry0BWjoQKURAgEBAKCcBR2rGruoY4y328GWP8AdlwrjtgCeMgo3 9M40aCfz2ojrCY0VxRm+vWk= =Nexi -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 06:17:13 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E917F16A403; Tue, 14 Nov 2006 06:17:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D2F843D46; Tue, 14 Nov 2006 06:17:13 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kADElwfQ004667; Mon, 13 Nov 2006 09:47:58 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kADElvjo044200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2006 09:47:58 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611131447.kADElvjo044200@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Nov 2006 09:48:08 -0500 To: =?KOI8-R?Q?=F3=D0=C1=D2=D4=C1=CB_=F2=C1=C4=DE=C5=CE=CB=CF?= , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <455858A3.9060701@aif.ru> References: <455768F3.4000407@FreeBSD.org> <455786DB.4020807@mail.zedat.fu-berlin.de> <455858A3.9060701@aif.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: sem@freebsd.org Subject: Re: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 06:17:14 -0000 At 06:36 AM 11/13/2006,=20 =3D?KOI8-R?Q?=3DF3=3DD0=3DC1=3DD2=3DD4=3DC1=3DCB_=3DF2=3DC1=3DC4=3DDE=3DC5= =3DCE=3DCB=3DCF?=3D wrote: >O. Hartmann =D0=C9=DB=C5=D4: >>Sergey Matveychuk wrote: >> >>>Do you know an old sio driver is hardly usable? >>> >>>There are many silo overflows, working with a terminal device is a >>>nightmare. There was a report about one crash with a message about a >>>spinlock holed more than 5 seconds (there is no core dump because it has >>>not repeated). >>> >>>After a discussion in a Russian FIDO group I've change it on uart and >>>the problems gone. >>> >>>I think a default driver should be changed from sio to uart until it >>>will be fixed. >>> >>> >> >>Had those overflows many times when I used FreeBSD 6.0-STABLE, >>6.1-STABLE and a modem. >>But this never had a so bad influence forcing me into using uart. >> >I had serious problems with sio on Intel STL2=20 >motherboard and recent stable. Massive silo=20 >overflows (modem was almost unusable) and at=20 >least 1 sio-related panic (spinlock held for=20 >more than 5 sec). Now I changed sio to uart ant=20 >it works like a charm. All problems gone. How do you switch it from sio to uart on RELENG_6 ? ---Mike >-- >Spartak Radchenko SVR1-RIPE >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 06:34:48 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34F4F16A403 for ; Tue, 14 Nov 2006 06:34:48 +0000 (UTC) (envelope-from jgrosch@mooseriver.com) Received: from mooseriver.com (h-66-166-146-73.snvacaid.covad.net [66.166.146.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82A1E43D5E for ; Tue, 14 Nov 2006 06:34:47 +0000 (GMT) (envelope-from jgrosch@mooseriver.com) Received: by mooseriver.com (Postfix, from userid 200) id 62DB62E5C13; Mon, 13 Nov 2006 22:34:47 -0800 (PST) Date: Mon, 13 Nov 2006 22:34:47 -0800 From: Josef Grosch To: Mike Jakubik Message-ID: <20061114063447.GA6940@mooseriver.com> References: <1163442609.10865.59.camel@bigapple.omnis.ch> <4558C02E.4030509@rogers.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <4558C02E.4030509@rogers.com> User-Agent: Mutt/1.4.2.2i Organization: Moose River, LLC Cc: freebsd-stable@FreeBSD.ORG, Olivier Mueller Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jgrosch@MooseRiver.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 06:34:48 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2006 at 01:57:50PM -0500, Mike Jakubik wrote: > Olivier Mueller wrote: > >Hello, > > > >I will soon get some new servers with more than 4 GB of RAM, and > >I am wondering if they will work fine even with the PAE > >option activated: are all the required drivers (RAID mfid, bce > >on the Dell, ciss0 on the HP) 100% compatible, or should I expect > >trouble?=20 > > =20 >=20 > Why not use AMD64 mode instead of PAE? I vote for using AMD64 mode instead of PAE. I did some testing last month and found PAE to be very brittle. We were testing with HP DL360 (IIRC) and found that the onboard Broadcom ether did not like PAE. The system panicked when it went to initialize the device.=20 =20 Josef --=20 Josef Grosch | Another day closer to a | FreeBSD 6.1 jgrosch@MooseRiver.com | Micro$oft free world | Berkeley, Ca. --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFFWWOHy8prLS1GYSERAnX0AJ40DH/X2DQDGd1wOkmlR1k462UWLQCglLjn iNG25dv/9OGw1rj53zTNw+8= =Z2fY -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 07:19:06 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28FC216A40F for ; Tue, 14 Nov 2006 07:19:06 +0000 (UTC) (envelope-from raj@csub.edu) Received: from mailhub.csub.edu (mailhub.csub.edu [136.168.1.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id C76BD43D46 for ; Tue, 14 Nov 2006 07:19:05 +0000 (GMT) (envelope-from raj@csub.edu) Received: from eru.homelan (adsl-75-15-245-162.dsl.bkfd14.sbcglobal.net [75.15.245.162]) (authenticated bits=0) by mailhub.csub.edu (8.13.8/8.13.8) with ESMTP id kAE7J40k057224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Nov 2006 23:19:05 -0800 (PST) (envelope-from raj@csub.edu) Received: from eru.homelan (localhost [127.0.0.1]) by eru.homelan (8.13.8/8.13.8) with ESMTP id kAE7J35X027636 for ; Mon, 13 Nov 2006 23:19:03 -0800 (PST) (envelope-from raj@eru.homelan) Received: (from raj@localhost) by eru.homelan (8.13.8/8.13.8/Submit) id kAE7J3Dh027635 for freebsd-stable@freebsd.org; Mon, 13 Nov 2006 23:19:03 -0800 (PST) (envelope-from raj) Resent-From: raj@csub.edu Resent-Date: Mon, 13 Nov 2006 23:19:03 -0800 Resent-Message-ID: <20061114071903.GB26602@eru.homelan> Resent-To: freebsd-stable@freebsd.org Date: Mon, 13 Nov 2006 22:40:40 -0800 From: Russell Jackson To: Russell Jackson Message-ID: <20061114064040.GA26602@eru.homelan> References: <20061111075621.GA1279@cserv65.csub.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061111075621.GA1279@cserv65.csub.edu> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: update on dell precision 670 vs em death match X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 07:19:06 -0000 On Fri, Nov 10, 2006 at 11:56:21PM -0800, Russell Jackson wrote: > Whatever that last em commit was, it seems to have made the interrupt > issues better. It still seems high, but it's a lot better than the > 2000/s I was getting before. > > interrupt total rate > irq1: atkbd0 54 0 > irq6: fdc0 10 0 > irq14: ata0 16 0 > irq15: ata1 47 0 > irq16: nvidia0+++ 1095231 677 > irq18: uhci2+ 3421 2 > irq23: ehci0 1 0 > irq48: em0 115315 71 > cpu0: timer 3230219 1997 > cpu1: timer 3228221 1996 > Total 7672535 4744 > It appears that I hit upon a fluke. The machine finally hung again after a few days of use, and I found after the hard reset that the interrupt problem was back. So, I'm back to running sans apic for now. Actually, after re-reading all the previous threads again, it doesn't appear that any of the recent fixes to em had anything to do with the shared irq issues anyhow. I'm now left feeling a bit confused, but that may just be due to lack of sleep. -- Russell A. Jackson Network Analyst California State University, Bakersfield From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 07:50:25 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85F5316A403 for ; Tue, 14 Nov 2006 07:50:25 +0000 (UTC) (envelope-from dkirhlarov@oilspace.com) Received: from office.oilspace.com (office.oilspace.com [194.129.65.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2952443D73 for ; Tue, 14 Nov 2006 07:50:24 +0000 (GMT) (envelope-from dkirhlarov@oilspace.com) Received: from dkirhlarov.mow.oilspace.com (proxy-mow.oilspace.com [81.222.156.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.oilspace.com (Postfix) with ESMTP id 2356717A9F8 for ; Tue, 14 Nov 2006 07:50:23 +0000 (GMT) Received: from dkirhlarov.mow.oilspace.com (localhost [127.0.0.1]) by dkirhlarov.mow.oilspace.com (8.13.8/8.13.8) with ESMTP id kAE7oMAg001450 for ; Tue, 14 Nov 2006 10:50:22 +0300 (MSK) (envelope-from dkirhlarov@dkirhlarov.mow.oilspace.com) Received: (from dkirhlarov@localhost) by dkirhlarov.mow.oilspace.com (8.13.8/8.13.8/Submit) id kAE7oMUF001449 for stable@freebsd.org; Tue, 14 Nov 2006 10:50:22 +0300 (MSK) (envelope-from dkirhlarov) Date: Tue, 14 Nov 2006 10:50:21 +0300 From: Dmitriy Kirhlarov To: stable@freebsd.org Message-ID: <20061114075020.GA1154@dimma.mow.oilspace.com> Mail-Followup-To: stable@freebsd.org References: <20061113084430.GE59604@dimma.mow.oilspace.com> <20061113184505.GA51659@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061113184505.GA51659@xor.obsecurity.org> X-Mailer: Mutt-ng devel (2005-03-13) based on Mutt 1.5.9 X-Operating-System: FreeBSD 6.2-PRERELEASE User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 07:50:25 -0000 On Mon, Nov 13, 2006 at 01:45:05PM -0500, Kris Kennaway wrote: > On Mon, Nov 13, 2006 at 11:44:31AM +0300, Dmitriy Kirhlarov wrote: > > Hi, list. > > > > One from my monitoring servers running with > > FreeBSD 6.2-PRERELEASE #0: Fri Nov 10 11:03:10 UTC 2006 i386 > > > > Under heavy load it panic several times per day. Backtrace accesable: > > http://clh.higis.ru/~dimma/btfull.0 > > Can somebody take a look? > > I send Problem Report, but not get feed back now from gnats. > Please provide your kernel config. http://clh.higis.ru/~dimma/OILSPACE1DEB I open PR for this problem -- kern/105464 WBR Dmitriy From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 08:26:26 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A51C716A49E for ; Tue, 14 Nov 2006 08:26:26 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD2E643D45 for ; Tue, 14 Nov 2006 08:26:25 +0000 (GMT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id kAE8QNmf080667 for ; Tue, 14 Nov 2006 15:26:23 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id kAE8QMME080666 for stable@freebsd.org; Tue, 14 Nov 2006 15:26:22 +0700 (KRAT) (envelope-from eugen) Date: Tue, 14 Nov 2006 15:26:22 +0700 From: Eugene Grosbein To: stable@freebsd.org Message-ID: <20061114082622.GA79591@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Installing 6.2-BETA3 from floppies X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 08:26:26 -0000 Hi! I'm trying to install FreeBSD 6.x onto old Packard Bell machine, it is Pentium-166 with 80Mb RAM and 10Gb HDD ("Orlando" motherboard). 6.2-BETA3 boot-only CD is no-emulation one and CD loader cannot boot this machine. I've prepared 4 floppy disks and tried to boot from floppies. It successfully loads kernel and acpi.ko and shows menu formerly known as 'Beastie' (now draws 'FreeBSD' instead of Chuck). The menu shows that FreeBSD detects that this system does not have ACPI and will boot without ACPI support enabled. However, timer does not 'tick' and there is always 10 seconds left. I choose verbose mode, it starts to show its diagnostic output but last line it shows is 'Calibrating clocks...' then it halts: keyboard leds do not switch, there is no reaction on 'Ctrl-Alt-ESC'. What else should I try other than installing system to HDD using another box? Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 08:43:44 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7C0716A403 for ; Tue, 14 Nov 2006 08:43:44 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF32E43D5A for ; Tue, 14 Nov 2006 08:43:43 +0000 (GMT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id kAE8hgAF081441 for ; Tue, 14 Nov 2006 15:43:42 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id kAE8hgd0081440 for stable@freebsd.org; Tue, 14 Nov 2006 15:43:42 +0700 (KRAT) (envelope-from eugen) Date: Tue, 14 Nov 2006 15:43:41 +0700 From: Eugene Grosbein To: stable@freebsd.org Message-ID: <20061114084341.GA80973@svzserv.kemerovo.su> References: <20061114082622.GA79591@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061114082622.GA79591@svzserv.kemerovo.su> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Installing 6.2-BETA3 from floppies X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 08:43:44 -0000 On Tue, Nov 14, 2006 at 03:26:22PM +0700, Eugene Grosbein wrote: > I'm trying to install FreeBSD 6.x onto old Packard Bell machine, > it is Pentium-166 with 80Mb RAM and 10Gb HDD ("Orlando" motherboard). > > 6.2-BETA3 boot-only CD is no-emulation one and CD loader > cannot boot this machine. > > I've prepared 4 floppy disks and tried to boot from floppies. > It successfully loads kernel and acpi.ko and shows menu > formerly known as 'Beastie' (now draws 'FreeBSD' instead of Chuck). > The menu shows that FreeBSD detects that this system does not > have ACPI and will boot without ACPI support enabled. > > However, timer does not 'tick' and there is always 10 seconds left. > I choose verbose mode, it starts to show its diagnostic output > but last line it shows is 'Calibrating clocks...' then it halts: > keyboard leds do not switch, there is no reaction on 'Ctrl-Alt-ESC'. Hmm, I was too quick... The kernel has spent lots of minutes 'sitting in this pose' but suddenly said that clock calibration has failed and it will use default frequency. Then it booted Ok and I've installed the system to HDD using 6.1-RELEASE (I do not have complete 6.2-BETA3 CD here but plan to do binary upgrade over FTP). When installation process was finished, it rebooted from HDD but it now it sits again at the same stage trying to calibrate clock, 5 minutes are gone already. So the question is what should I do to skip this stage and have accurate timers still. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 09:30:23 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A48816A403 for ; Tue, 14 Nov 2006 09:30:23 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F7943D7B for ; Tue, 14 Nov 2006 09:30:22 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GjucU-0008Vc-PL for freebsd-stable@freebsd.org; Tue, 14 Nov 2006 10:30:19 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Nov 2006 10:30:18 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Nov 2006 10:30:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 14 Nov 2006 10:30:06 +0100 Lines: 11 Message-ID: References: <1163442609.10865.59.camel@bigapple.omnis.ch> <20061113191454.GB66013@rambler-co.ru> <1163455070.14157.9.camel@bigapple.omnis.ch> <20061113223904.GB84153@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <20061113223904.GB84153@rambler-co.ru> Sender: news Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 09:30:23 -0000 Ruslan Ermilov wrote: > On Mon, Nov 13, 2006 at 10:57:50PM +0100, Olivier Mueller wrote: >> Will the systems be quicker this way, or will it "just" help >> with this 4GB memory limit? >> > Quicker - probably not. Will certainly help with the 4G limit. On a low level sort of way amd64 actually might be quicker than PAE since AFAIK PAE introduces nontrivial kernel overhead to get to the "extra" memory. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 09:31:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A56916A417 for ; Tue, 14 Nov 2006 09:31:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 877A043D77 for ; Tue, 14 Nov 2006 09:31:05 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0540546E68; Tue, 14 Nov 2006 04:31:05 -0500 (EST) Date: Tue, 14 Nov 2006 09:31:04 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Steve Wills In-Reply-To: <9ABCABF7-2D44-496D-84A2-4C3CA4527355@stevenwills.com> Message-ID: <20061114092953.R50450@fledge.watson.org> References: <9ABCABF7-2D44-496D-84A2-4C3CA4527355@stevenwills.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: audit and quota don't get along X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 09:31:07 -0000 On Sun, 12 Nov 2006, Steve Wills wrote: > I thought I'd try out the new audit support in 6.2-PRE and discovered that > having quota enabled causes: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0695278 > stack pointer = 0x28:0xce19ac34 > frame pointer = 0x28:0xce19ac3c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 564 (auditd) > trap number = 12 > panic: page fault > > when trying to start auditd. I can provide backtrace, but it seems pretty > reproducible. A backtrace would be helpful. Are you using quotas on the file system targeted by the audit trail, or just on the system in general? Is compiling quotas in sufficient to reproduce the problem, or must quotas be enabled on at least one file system? Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 10:28:00 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E81716A407 for ; Tue, 14 Nov 2006 10:28:00 +0000 (UTC) (envelope-from spartak@aif.ru) Received: from mail.aif.ru (mail.aif.ru [85.21.212.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF29F43D62 for ; Tue, 14 Nov 2006 10:27:59 +0000 (GMT) (envelope-from spartak@aif.ru) Received: from ppp91-76-112-26.pppoe.mtu-net.ru ([91.76.112.26] helo=[192.168.0.2]) by mail.aif.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1GjvWG-000GFA-KI; Tue, 14 Nov 2006 13:27:56 +0300 Message-ID: <45599A25.5080709@aif.ru> Date: Tue, 14 Nov 2006 13:27:49 +0300 From: Spartak Radchenko User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Tancsa , freebsd-stable@freebsd.org References: <455768F3.4000407@FreeBSD.org> <455786DB.4020807@mail.zedat.fu-berlin.de> <455858A3.9060701@aif.ru> <200611131447.kADElvjo044200@lava.sentex.ca> In-Reply-To: <200611131447.kADElvjo044200@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -4.1 (----) X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.3 AWL AWL: From: address is in the auto white-list Cc: Subject: Re: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 10:28:00 -0000 Mike Tancsa wrote: > At 06:36 AM 11/13/2006, > =?KOI8-R?Q?=F3=D0=C1=D2=D4=C1=CB_=F2=C1=C4=DE=C5=CE=CB=CF?= wrote: >> O. Hartmann ÐÉÛÅÔ: >>> Sergey Matveychuk wrote: >>> >>>> Do you know an old sio driver is hardly usable? >>>> >>>> There are many silo overflows, working with a terminal device is a >>>> nightmare. There was a report about one crash with a message about a >>>> spinlock holed more than 5 seconds (there is no core dump because >>>> it has >>>> not repeated). >>>> >>>> After a discussion in a Russian FIDO group I've change it on uart and >>>> the problems gone. >>>> >>>> I think a default driver should be changed from sio to uart until it >>>> will be fixed. >>>> >>>> >>> >>> Had those overflows many times when I used FreeBSD 6.0-STABLE, >>> 6.1-STABLE and a modem. >>> But this never had a so bad influence forcing me into using uart. >>> >> I had serious problems with sio on Intel STL2 motherboard and recent >> stable. Massive silo overflows (modem was almost unusable) and at >> least 1 sio-related panic (spinlock held for more than 5 sec). Now I >> changed sio to uart ant it works like a charm. All problems gone. > > How do you switch it from sio to uart on RELENG_6 ? > Build a new kernel with device uart, change sio to uart tn the /boot/device.hints file. Maybe rebuilding a kernel is not needed, I never checked it. -- Spartak Radchenko SVR1-RIPE From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 10:52:31 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1976B16A407 for ; Tue, 14 Nov 2006 10:52:31 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4853543D6B for ; Tue, 14 Nov 2006 10:52:28 +0000 (GMT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id kAEAqPK6087996 for ; Tue, 14 Nov 2006 17:52:25 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id kAEAqOEs087995 for stable@freebsd.org; Tue, 14 Nov 2006 17:52:24 +0700 (KRAT) (envelope-from eugen) Date: Tue, 14 Nov 2006 17:52:24 +0700 From: Eugene Grosbein To: stable@freebsd.org Message-ID: <20061114105224.GA86908@svzserv.kemerovo.su> References: <20061114082622.GA79591@svzserv.kemerovo.su> <20061114084341.GA80973@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061114084341.GA80973@svzserv.kemerovo.su> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Installing 6.2-BETA3 from floppies X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 10:52:31 -0000 On Tue, Nov 14, 2006 at 03:43:41PM +0700, Eugene Grosbein wrote: > > I've prepared 4 floppy disks and tried to boot from floppies. > > It successfully loads kernel and acpi.ko and shows menu > > formerly known as 'Beastie' (now draws 'FreeBSD' instead of Chuck). > > The menu shows that FreeBSD detects that this system does not > > have ACPI and will boot without ACPI support enabled. > > > > However, timer does not 'tick' and there is always 10 seconds left. > > I choose verbose mode, it starts to show its diagnostic output > > but last line it shows is 'Calibrating clocks...' then it halts: > > keyboard leds do not switch, there is no reaction on 'Ctrl-Alt-ESC'. > > Hmm, I was too quick... The kernel has spent lots of minutes > 'sitting in this pose' but suddenly said that clock calibration > has failed and it will use default frequency. Then it booted Ok > and I've installed the system to HDD using 6.1-RELEASE (I do not > have complete 6.2-BETA3 CD here but plan to do binary upgrade > over FTP). > > When installation process was finished, it rebooted from HDD > but it now it sits again at the same stage trying to calibrate clock, > 5 minutes are gone already. So the question is what should I do > to skip this stage and have accurate timers still. I've rebuild kernel without any CALIBRATE_XXX options but it still tries to calibrate clock and hangs for 15 minutes exactly then proceedes to probe devices and boots Ok. When I first booted this old machine its BIOS said that Date/Time in CMOS are corrupted and asked to press F1 to enter SETUP to fix this or press ESC to continue booting. Enterins SETUP and correcting settings does not help and BIOS complains again that Date/Time are wrong and does not proceed without a key is pressed on keyboard. That's not suitable for small standalone router so I went to the store, bought Duracell DL2032 3V battary and replaced old Panasonic CD2032 3V battary. That satisfied BIOS POST and it no more complains about Date/Time. But FreeBSD spends 15 minutes to calibrate clock. Now I've put back old Panasonic CD2032 3V and hey, BIOS complains again but FreeBSD boots normally and completes clock calibration very quickly. I wonder, how new battery may affect clock calibration routines and why old bad battery does not affect it that way? Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 11:49:19 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4802C16A40F for ; Tue, 14 Nov 2006 11:49:19 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A27143D55 for ; Tue, 14 Nov 2006 11:49:18 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ktuxox@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAEBnAt2027827 for ; Tue, 14 Nov 2006 12:49:16 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAEBnAEM027826; Tue, 14 Nov 2006 12:49:10 +0100 (CET) (envelope-from olli) Date: Tue, 14 Nov 2006 12:49:10 +0100 (CET) Message-Id: <200611141149.kAEBnAEM027826@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <20061113171945.GA26567@icarus.home.lan> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 14 Nov 2006 12:49:16 +0100 (CET) Cc: Subject: Re: Cruel and unusual problems with Proliant ML350 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 11:49:19 -0000 Jeremy Chadwick wrote: > Oliver Fromme wrote: > > If it's really only a web server, then you probably don't > > need the USB ports. In that case you should remove ohci > > and ehci from your kernel. The USB interrupt handler is > > quite heavy-weight, so it can have a noticeable impact if > > the interrupt is shared with other devices. > > I'll agree with this (re: webservers not needing USB), except in > regards to one item: keyboards. > > More and more x86 PCs these days are expecting keyboards to be > USB-based. Yes, PS/2 ports are still present on most (but not all) > motherboards, but eventually that will be phased out. Personally I never buy hardware that requires me to connect a keyboard for management (no matter whether USB or PS/2). > I like the idea of being able to go to my co-location facility and > plug in a USB keyboard to begin working on a server, and when > finished remove the keyboard and leave. I don't like that idea at all. I like the idea of not having to go to my co-location facility, but instead be able to manage my servers completely remotely. We're not in the stone age anymore ... Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 11:59:31 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47E9C16A407 for ; Tue, 14 Nov 2006 11:59:31 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7235A43D66 for ; Tue, 14 Nov 2006 11:59:27 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (srqxab@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAEBxK78028264; Tue, 14 Nov 2006 12:59:25 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAEBxKql028263; Tue, 14 Nov 2006 12:59:20 +0100 (CET) (envelope-from olli) Date: Tue, 14 Nov 2006 12:59:20 +0100 (CET) Message-Id: <200611141159.kAEBxKql028263@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, om-lists-bsd@omx.ch In-Reply-To: <1163455070.14157.9.camel@bigapple.omnis.ch> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 14 Nov 2006 12:59:26 +0100 (CET) Cc: Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, om-lists-bsd@omx.ch List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 11:59:31 -0000 Olivier Mueller wrote: > Ruslan Ermilov wrote: > > And you absolutely have no option of running FreeBSD/amd64 on > > them? What a PITA! :-) > > Ehm well, I must admit I never tried that, for a simple (and silly?) > reason: freebsd installation selects the i386 SMP kernel by default... > > But of course if you (and Mike Jakubik) strongly suggest it would be a > good idea, why not, I will give a try asap :-) Any special thing I > should take care of when switching from the i686 kernel to the amd64 > one? The easiest way is to re-install with an /amd64 ISO. > Will the systems be quicker this way, When addressing more than 4 GB of physical RAM, a native 64bit system is certainly more efficient (hence quicker) than the PAE kludge. > or will it "just" help with this 4GB memory limit? Yes it will. With /amd64, the address space is larger than 4 GB. With /i386, it is always limited to 4 GB, no matter if you use PAE or not. (Actually the address space for user processes is even more limited: 4 GB minus the kernel's address space.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 12:20:14 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B996916A4A7 for ; Tue, 14 Nov 2006 12:20:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BCF043E11 for ; Tue, 14 Nov 2006 12:19:35 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (chobmt@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAECJSU2029155; Tue, 14 Nov 2006 13:19:34 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAECJSni029154; Tue, 14 Nov 2006 13:19:28 +0100 (CET) (envelope-from olli) Date: Tue, 14 Nov 2006 13:19:28 +0100 (CET) Message-Id: <200611141219.kAECJSni029154@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, eugen@www.svzserv.kemerovo.su In-Reply-To: <20061114084341.GA80973@svzserv.kemerovo.su> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 14 Nov 2006 13:19:34 +0100 (CET) Cc: Subject: Re: Installing 6.2-BETA3 from floppies X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, eugen@www.svzserv.kemerovo.su List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 12:20:14 -0000 Eugene Grosbein wrote: > Eugene Grosbein wrote: > > I'm trying to install FreeBSD 6.x onto old Packard Bell machine, > > it is Pentium-166 with 80Mb RAM and 10Gb HDD ("Orlando" motherboard). > > [...] > > However, timer does not 'tick' and there is always 10 seconds left. > > I choose verbose mode, it starts to show its diagnostic output > > but last line it shows is 'Calibrating clocks...' then it halts: > > keyboard leds do not switch, there is no reaction on 'Ctrl-Alt-ESC'. > > Hmm, I was too quick... The kernel has spent lots of minutes > 'sitting in this pose' but suddenly said that clock calibration > has failed and it will use default frequency. Apparently the RTC on that mainboard is dead. Did you try replacing its battery? It's usually a small lithium button cell, or (on very old boards) a small battery package. If that doesn't help, I guess the RTC chip itself is broken. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 12:50:09 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC10316A4AB for ; Tue, 14 Nov 2006 12:50:09 +0000 (UTC) (envelope-from om-lists-bsd@omx.ch) Received: from andromeda.insign.ch (andromeda.insign.ch [195.134.143.165]) by mx1.FreeBSD.org (Postfix) with SMTP id F40C543D46 for ; Tue, 14 Nov 2006 12:47:08 +0000 (GMT) (envelope-from om-lists-bsd@omx.ch) Received: (qmail 18972 invoked by uid 508); 14 Nov 2006 12:46:57 -0000 Received: from om-lists-bsd@omx.ch by andromeda3 by uid 502 with qmail-scanner-1.21 (avp(2004-05-12). Clear:RC:1(80.254.166.203):. Processed in 0.01789 secs); 14 Nov 2006 12:46:57 -0000 Received: from zux166-203.adsl.green.ch (HELO oli2.insign) ([80.254.166.203]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 14 Nov 2006 12:46:57 -0000 From: Olivier Mueller To: freebsd-stable@FreeBSD.ORG In-Reply-To: <200611141159.kAEBxKql028263@lurza.secnetix.de> References: <200611141159.kAEBxKql028263@lurza.secnetix.de> Content-Type: text/plain Date: Tue, 14 Nov 2006 13:46:58 +0100 Message-Id: <1163508418.24336.8.camel@oli2.insign.local> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit Cc: Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 12:50:10 -0000 Bonjour, On Tue, 2006-11-14 at 12:59 +0100, Oliver Fromme wrote: > > But of course if you (and Mike Jakubik) strongly suggest it would be a > > good idea, why not, I will give a try asap :-) Any special thing I > > should take care of when switching from the i686 kernel to the amd64 > > one? > > The easiest way is to re-install with an /amd64 ISO. On new servers, sure. But on already active (and in production) systems? I guess a make buildkernel is not enought, and that at least a make buildworld would be necessary? Or even some ports? I can go offline for a few minutes, but certainly not hours... :) > > Will the systems be quicker this way, > > When addressing more than 4 GB of physical RAM, a native > 64bit system is certainly more efficient (hence quicker) > than the PAE kludge. Ok, good point. Thanks for your feedback! regards, Olivier From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 13:10:35 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6755D16A407 for ; Tue, 14 Nov 2006 13:10:35 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 383B443D55 for ; Tue, 14 Nov 2006 13:10:33 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (varonk@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAEDARPY032155; Tue, 14 Nov 2006 14:10:32 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAEDAQQg032154; Tue, 14 Nov 2006 14:10:26 +0100 (CET) (envelope-from olli) Date: Tue, 14 Nov 2006 14:10:26 +0100 (CET) Message-Id: <200611141310.kAEDAQQg032154@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, om-lists-bsd@omx.ch In-Reply-To: <1163508418.24336.8.camel@oli2.insign.local> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 14 Nov 2006 14:10:32 +0100 (CET) Cc: Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, om-lists-bsd@omx.ch List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 13:10:35 -0000 Olivier Mueller wrote: > Oliver Fromme wrote: > > The easiest way is to re-install with an /amd64 ISO. > > On new servers, sure. But on already active (and in production) > systems? I guess a make buildkernel is not enought, and > that at least a make buildworld would be necessary? Or even > some ports? I can go offline for a few minutes, but certainly > not hours... :) To take full advantage, you have to recompile everything (kernel, world, ports), and the order of things is non- trivial, because amd64 and i386 are incompatible (even though FreeBSD/amd64 has a compatibility framework for running i386 binaries, somewhat similar to the Linux ABI). There have been detailed instructions on the amd64 list how to go from i386 to amd64 "the hard way", i.e. via the sources, but that's not the officially supported way, as far as I know. Simply re-installing from an ISO is faster and less error-prone. You'll have some downtime either way anyway. If you need to minimize downtime, it's probably a good idea to install on a separate HD, and switch HDs when you're ready. That approach also has the nice advantage that you have a very easy fall-back in case something goes wrong: simply switch to the first HD again. Of course, YMMV. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 14:18:54 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CA7A16A407 for ; Tue, 14 Nov 2006 14:18:54 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97CA743D46 for ; Tue, 14 Nov 2006 14:18:53 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A4C61.dip.t-dialin.net [84.154.76.97]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id kAEEInEa057999; Tue, 14 Nov 2006 15:18:50 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id kAEEIlcR003384; Tue, 14 Nov 2006 15:18:47 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost [127.0.0.1]) by fire.jhs.private (8.13.6/8.13.6) with ESMTP id kAEEIkTl021578; Tue, 14 Nov 2006 15:18:46 +0100 (CET) (envelope-from jhs@fire.jhs.private) Message-Id: <200611141418.kAEEIkTl021578@fire.jhs.private> To: Eugene Grosbein In-reply-to: <20061114105224.GA86908@svzserv.kemerovo.su> References: <20061114082622.GA79591@svzserv.kemerovo.su> <20061114084341.GA80973@svzserv.kemerovo.su> <20061114105224.GA86908@svzserv.kemerovo.su> Comments: In-reply-to Eugene Grosbein message dated "Tue, 14 Nov 2006 17:52:24 +0700." Date: Tue, 14 Nov 2006 15:18:46 +0100 From: "Julian H. Stacey" Cc: stable@freebsd.org Subject: Re: Installing 6.2-BETA3 from floppies X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 14:18:54 -0000 Eugene Grosbein wrote: > On Tue, Nov 14, 2006 at 03:43:41PM +0700, Eugene Grosbein wrote: > > > > I've prepared 4 floppy disks and tried to boot from floppies. > > > It successfully loads kernel and acpi.ko and shows menu > > > formerly known as 'Beastie' (now draws 'FreeBSD' instead of Chuck). > > > The menu shows that FreeBSD detects that this system does not > > > have ACPI and will boot without ACPI support enabled. > > > > > > However, timer does not 'tick' and there is always 10 seconds left. > > > I choose verbose mode, it starts to show its diagnostic output > > > but last line it shows is 'Calibrating clocks...' then it halts: > > > keyboard leds do not switch, there is no reaction on 'Ctrl-Alt-ESC'. > > > > Hmm, I was too quick... The kernel has spent lots of minutes > > 'sitting in this pose' but suddenly said that clock calibration > > has failed and it will use default frequency. Then it booted Ok > > and I've installed the system to HDD using 6.1-RELEASE (I do not > > have complete 6.2-BETA3 CD here but plan to do binary upgrade > > over FTP). > > > > When installation process was finished, it rebooted from HDD > > but it now it sits again at the same stage trying to calibrate clock, > > 5 minutes are gone already. So the question is what should I do > > to skip this stage and have accurate timers still. > > I've rebuild kernel without any CALIBRATE_XXX options > but it still tries to calibrate clock and hangs for 15 minutes exactly > then proceedes to probe devices and boots Ok. > > When I first booted this old machine its BIOS said that Date/Time in CMOS > are corrupted and asked to press F1 to enter SETUP to fix this > or press ESC to continue booting. Enterins SETUP and correcting > settings does not help and BIOS complains again that Date/Time are wrong > and does not proceed without a key is pressed on keyboard. > That's not suitable for small standalone router so I went to the store, > bought Duracell DL2032 3V battary and replaced old > Panasonic CD2032 3V battary. That satisfied BIOS POST and it no more > complains about Date/Time. But FreeBSD spends 15 minutes to calibrate clock. > > Now I've put back old Panasonic CD2032 3V and hey, BIOS complains again > but FreeBSD boots normally and completes clock calibration very quickly. > > I wonder, how new battery may affect clock calibration routines > and why old bad battery does not affect it that way? > > Eugene Grosbein After changing battery I'd assume every piece of your CMOS BIOS is potentialy wrong. I'd do a factory reset of BIOS (not just checking things (*)) & then set what I wanted in every position going through BIOS before wondering what the interaction with any OS was. (*) I've known a BIOS (Gigabyte 486-33 AMD I think, but principle applies to others), where I reset every CMOS field exactly how it should be, yet board didnt work right, then I did a factory reset, & set personal prefs again & then it did work. Lesson was that BIOS manuf. was resetting more than it displayed (& something must have got scrambled but not displayed) -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. http://berklix.org/free-software From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 14:26:38 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96E2016A412 for ; Tue, 14 Nov 2006 14:26:38 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41A7943D49 for ; Tue, 14 Nov 2006 14:26:38 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from collaborativefusion.com (mx01.pub.collaborativefusion.com [206.210.89.201]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Tue, 14 Nov 2006 09:26:37 -0500 id 00056436.4559D21D.000069CF Received: from Internal Mail-Server by mx01 (envelope-from wmoran@collaborativefusion.com) with AES256-SHA encrypted SMTP; 14 Nov 2006 09:26:36 -0500 Date: Tue, 14 Nov 2006 09:26:36 -0500 From: Bill Moran To: "Jack Vogel" Message-Id: <20061114092636.f76295c3.wmoran@collaborativefusion.com> In-Reply-To: <2a41acea0611131430x3c9206f4ua1ffe6cbf5e82202@mail.gmail.com> References: <20061113171529.a75fe20a.wmoran@collaborativefusion.com> <2a41acea0611131430x3c9206f4ua1ffe6cbf5e82202@mail.gmail.com> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.10.6; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: em interrupt storm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 14:26:38 -0000 In response to "Jack Vogel" : > On 11/13/06, Bill Moran wrote: > > > > Just experienced an "interrupt storm" on an em device that disabled a > > server until I could reboot it. > > > > My initial research turned up this thread: > > http://lists.freebsd.org/pipermail/freebsd-current/2005-November/058336.html > > > > Which seems related, even if it is a little old. I'm aware that there > > have been problems with recent versions of the em driver but I haven't > > been following them closely enough, and there's a LOT of mail traffic > > on this topic. > > > > Note that this is a FreeBSD 5.3-RELEASE-p37 system. An upgrade is > > possible, but this is a production system and the problem occurs > > infrequently, so I'm reluctant to schedule downtime unless I have good > > reason to believe that it will fix the problem. > > > > Anyone remember if the above problem was fixed in more recent versions, > > or knows enough about the issue to comment on whether I'm barking up > > the correct tree or not? I'm pretty early in the diagnosis on this, > > but I'm looking for pointers to keep me from doing random upgrades or > > other time-wasting activities. > > There were fixes to things that MIGHT be a cause of an interrupt storm > in the em driver, but without knowing more about your specific hardware > and the event when it happened its hard to pontificate :) Hell, it's hard just to spell "pontificate"! ;) > As an aside, I would think getting off 5.3 would be desireable in and of > itself :) It's on the TODO list, along with 1000 other things. If I can prove that 5.5 will fix a stability problem, that will move up the TODO list in priority. > Can you give a vmstat -i, a pciconf -l, and maybe messages when the > storm occurred? Sorry ... should have done that in the first email, but yesterday afternoon was a bit flustering ... There was a console message to the tune of "interrupt store on em0" ... I didn't bother to copy it down exactly, because I expected it would end up in /var/log/messages, but it didn't. vmstat -i interrupt total rate irq4: sio0 3 0 irq8: rtc 8027965 127 irq13: npx0 1 0 irq14: ata0 58 0 irq16: uhci0 286184 4 irq18: uhci2 221609 3 irq19: uhci1 3 0 irq23: atapci0 94 0 irq34: mpt0 221609 3 irq64: em0 286144 4 irq0: clk 6272009 99 Total 15315679 244 pciconf -l hostb0@pci0:0:0: class=0x060000 card=0x016c1028 chip=0x35908086 rev=0x09 hdr=0x00 pcib1@pci0:2:0: class=0x060400 card=0x00000050 chip=0x35958086 rev=0x09 hdr=0x01 pcib4@pci0:4:0: class=0x060400 card=0x00000050 chip=0x35978086 rev=0x09 hdr=0x01 pcib5@pci0:5:0: class=0x060400 card=0x00000050 chip=0x35988086 rev=0x09 hdr=0x01 pcib8@pci0:6:0: class=0x060400 card=0x00000050 chip=0x35998086 rev=0x09 hdr=0x01 uhci0@pci0:29:0: class=0x0c0300 card=0x016c1028 chip=0x24d28086 rev=0x02 hdr=0x00 uhci1@pci0:29:1: class=0x0c0300 card=0x016c1028 chip=0x24d48086 rev=0x02 hdr=0x00 uhci2@pci0:29:2: class=0x0c0300 card=0x016c1028 chip=0x24d78086 rev=0x02 hdr=0x00 none0@pci0:29:7: class=0x0c0320 card=0x016c1028 chip=0x24dd8086 rev=0x02 hdr=0x00 pcib9@pci0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0xc2 hdr=0x01 isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x24d08086 rev=0x02 hdr=0x00 atapci1@pci0:31:1: class=0x01018a card=0x016c1028 chip=0x24db8086 rev=0x02 hdr=0x00 pcib2@pci1:0:0: class=0x060400 card=0x00000044 chip=0x03298086 rev=0x09 hdr=0x01 pcib3@pci1:0:2: class=0x060400 card=0x00000044 chip=0x032a8086 rev=0x09 hdr=0x01 mpt0@pci3:5:0: class=0x010000 card=0x016c1028 chip=0x00301000 rev=0x08 hdr=0x00 pcib6@pci5:0:0: class=0x060400 card=0x00000044 chip=0x03298086 rev=0x09 hdr=0x01 pcib7@pci5:0:2: class=0x060400 card=0x00000044 chip=0x032a8086 rev=0x09 hdr=0x01 em0@pci6:7:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 em1@pci7:8:0: class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 none1@pci9:5:0: class=0xff0000 card=0x00111028 chip=0x00111028 rev=0x00 hdr=0x00 none2@pci9:5:1: class=0xff0000 card=0x00121028 chip=0x00121028 rev=0x00 hdr=0x00 none3@pci9:5:2: class=0xff0000 card=0x00141028 chip=0x00141028 rev=0x00 hdr=0x00 atapci0@pci9:6:0: class=0x010185 card=0x06801095 chip=0x06801095 rev=0x02 hdr=0x00 none4@pci9:13:0: class=0x030000 card=0x016c1028 chip=0x51591002 rev=0x00 hdr=0x00 -- Bill Moran Collaborative Fusion Inc. wmoran@collaborativefusion.com Phone: 412-422-3463x4023 **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 14:32:16 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03E7C16A415 for ; Tue, 14 Nov 2006 14:32:16 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from n126.sc0.cp.net (smtpout1071.sc0.he.tucows.com [64.97.144.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id E63AD43D5C for ; Tue, 14 Nov 2006 14:32:12 +0000 (GMT) (envelope-from eagletree@hughes.net) Received: from [192.168.1.100] (67.47.213.86) by n126.sc0.cp.net (7.2.069.1) (authenticated as eagletree@hughes.net) id 4558A79A0003F636 for freebsd-stable@freebsd.org; Tue, 14 Nov 2006 14:32:00 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <876647A0-1066-4B9C-A48A-1649FE3315C6@hughes.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-stable@freebsd.org From: Chris Date: Tue, 14 Nov 2006 06:31:45 -0800 X-Mailer: Apple Mail (2.752.2) Subject: 128 Bucket Free Count X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 14:32:16 -0000 I asked this question of Freebsd questions yesterday but realize it probably needs to go to this list. I have a Tyan S4882 quad opteron with 8GB RAM on 6.2 PR running a healthy load of webserver traffic. This machine is hanging occasionally (it was able to make 4 days this time we put it in, we are on day 5 of the second round). I've been through the hardware repeatedly since march when we bought it and at this point I don't think we have a hardware problem. Memory has been replaced and I went to 6.2 to pick up bge driver changes. I have it set up to dump if the problem occurs again and if we get a dump I'll certainly chase that as best as I can. Never done that process before so I have my doubts that I know what I'm doing. Taking another tack, I started dumping vmstat -z to another server every 2 minutes looking at the counters plus noting differences between when the system booted and current along with difference between last and current sample. I put in checks to determine anything that exceeded a 25% jump or drop in stats for any of the vm parameters. That turned out to be meaningless because approximately half make such jumps every cycle. I put in one additional check which was to look for anything that showed frequent changes yet had a Free Count that would go to zero often. I found that the stat called 128 Bucket gradually dropped down from a starting point of about 600 to 0 where it hovers between 0, 1 and 2 even as the used count gradually grows. Oddly at 12 midnight on Sunday, it totally freed up and popped back up above 500. One of the weekly cron cleanups? Does the sampling I'm doing have validity and what is a 128 Bucket? Coincidentally, yesterday people on the "questions" list discussed the 6.2 PR todo page. When I looked at it, I noted a panic related to 128 Bucket (the only reference on the net). The problem is I'm not getting a panic I don't think. But... I have to remotely cycle power to restart it because it started failing to reboot when I supped to 6.2. So I'm not really sure what is happening because I can't see the console. I set the acpi*reboot to 1 so I'm hoping that problem will disappear on the next failure. I also only allocated 8GB of swap so perhaps I've inhibited crashing correctly. Is it possible I'm seeing a related problem to the 128 Bucket Panic issue? Is it normal for 128 Bucket to sit at 0, 1, or 2 for a free count and only be reset on Sunday night at 12:00 midnight? Thank you, Chris Pratt From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 15:01:22 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24A3816A407 for ; Tue, 14 Nov 2006 15:01:22 +0000 (UTC) (envelope-from lxv@omut.org) Received: from mail.omut.org (mail.omut.org [216.218.215.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 536A843D76 for ; Tue, 14 Nov 2006 15:01:08 +0000 (GMT) (envelope-from lxv@omut.org) Received: from tadpole.omut.org (mix-anchor.intranet [10.10.10.251]) by mail.omut.org (8.13.8/8.13.8) with ESMTP id kAEF15Fs082186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Nov 2006 07:01:06 -0800 (PST) (envelope-from lxv@omut.org) Received: from tadpole.intranet (localhost [127.0.0.1]) by tadpole.omut.org (8.13.8/8.13.8) with ESMTP id kAEF0stP090593; Tue, 14 Nov 2006 10:01:04 -0500 (EST) (envelope-from lxv@tadpole.intranet) Received: (from lxv@localhost) by tadpole.intranet (8.13.8/8.13.8/Submit) id kAEF0mtt090592; Tue, 14 Nov 2006 10:00:48 -0500 (EST) (envelope-from lxv) Date: Tue, 14 Nov 2006 10:00:48 -0500 From: Alex Vasylenko To: Kris Kennaway Message-ID: <20061114150048.GA90548@tadpole.intranet> References: <20061114043601.GB88156@tadpole.intranet> <20061114060622.GA61080@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061114060622.GA61080@xor.obsecurity.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Scanned-By: MIMEDefang 2.57 on 216.218.215.140 Cc: freebsd-stable@freebsd.org Subject: Re: panic in swap_pager_swap_init (amd64/smp/6.2-pre) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Vasylenko List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 15:01:22 -0000 On Tue, Nov 14, 2006 at 01:06:22AM -0500, Kris Kennaway wrote: > > - GENERIC (UP) kernel works fine; > > - SMP kernel fails in the same way; > > - my kernel (a stripped down SMP) with "options SMP" removed works; > > - my kernel with SMP enabled and either -v or -d (followed by cont) > > works. > > ("works" in the last case is defined as: I could upgrade gnome > > 2.14->2.16 with buildworld -j2 going at the same time) > > That's quite odd, since afaik boot -v doesn't change any behaviour > apart from some printfs. Is this still repeatable, i.e. it didn't in > fact go away after you rebuilt your kernel from scratch during the > course of the above testing? nope, didn't go away, still does it with a brand new kernel built from fresh /usr/{src,obj}. lockup is not 100% guaranteed, sometimes it enters kdb: SMP: AP CPU #1 Launched! panic: failed to create swap_zone. cpuid = Trying to mou0 KDB: enter: nt root from ufpanic [thread pid 40 tid 100040 ] Stopped at kdb_enter+0x2f db> where Tracing pid 40 tid 100040 td 0xffffff003b9e24c0 kdb_enter() at kdb_enter+0x2f panic() at panic+0x291 swap_pager_swap_init() at swap_pager_swap_init+0x20c vm_pageout() at vm_pageout+0x17c fork_exit() at fork_exit+0x86 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffa753bd00, rbp = 0 --- db> -- Alex. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 15:10:29 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 711CC16A403 for ; Tue, 14 Nov 2006 15:10:29 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 340B043D64 for ; Tue, 14 Nov 2006 15:10:24 +0000 (GMT) (envelope-from dudu@dudu.ro) Received: by nz-out-0102.google.com with SMTP id i11so998258nzh for ; Tue, 14 Nov 2006 07:10:24 -0800 (PST) Received: by 10.65.100.14 with SMTP id c14mr811621qbm.1163517023889; Tue, 14 Nov 2006 07:10:23 -0800 (PST) Received: by 10.65.112.4 with HTTP; Tue, 14 Nov 2006 07:10:23 -0800 (PST) Message-ID: Date: Tue, 14 Nov 2006 17:10:23 +0200 From: "Vlad Galu" To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200610010015.k910F6Ba001594@cwsys.cwsent.com> <45475DEA.2030506@centtech.com> <20061031193139.GA27951@xor.obsecurity.org> Cc: Subject: Re: Frequent VFS crashes with RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 15:10:29 -0000 On 11/1/06, Vlad Galu wrote: > On 10/31/06, Kris Kennaway wrote: > > On Tue, Oct 31, 2006 at 04:34:59PM +0200, Vlad Galu wrote: > > > > > Yes, but for objective reasons I can't publish it :( > > > The only > > > debugging option that I didn't use was INVARIANTS. > > > > Which is coincidentally the most useful one ;-) > > > > Also turn on DEBUG_LOCKS and DEBUG_VFS_LOCKS then report the output of > > 'show lockedvnods' at the time of crash, as well. Upon Tor Egge's suggestion, I removed ZERO_COPY_SOCKETS from my kernel and the machine has been running nicely ever since. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 15:37:59 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B408E16A403 for ; Tue, 14 Nov 2006 15:37:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30BB943D62 for ; Tue, 14 Nov 2006 15:37:50 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (qjylqn@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAEFbgmS039374; Tue, 14 Nov 2006 16:37:48 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAEFbgIT039373; Tue, 14 Nov 2006 16:37:42 +0100 (CET) (envelope-from olli) Date: Tue, 14 Nov 2006 16:37:42 +0100 (CET) Message-Id: <200611141537.kAEFbgIT039373@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, jhs@flat.berklix.net In-Reply-To: <200611091923.kA9JNtN6042554@fire.jhs.private> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 14 Nov 2006 16:37:48 +0100 (CET) Cc: Subject: Re: Trouble: NFS via TCP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, jhs@flat.berklix.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 15:37:59 -0000 Sorry for the late answer, but I was offline (deliberately) during the weekend, and hadd too much work yesterday. Julian H. Stacey wrote: > Using a normal UDP mount I had eratic come & go problems with amd > until I added to rc.conf > nfs_server_flags="-u -t -n 10" > Turns out I had too few. 10 fixed it. Thanks for the suggestion, but I don't think it applies here. I'm using the default (-n 4), but this is the only mount from localhost, so that should be sufficient. Besides, the same problem occurs when trying to mount from a NetApp filer. Also, I don't have "erratic come & go problems", but the mount(8) command simply hangs right from the start. I'm not using amd, if that matters (I don't think it does). Since I weren't able to track this problem down, I now tend to think that it's a bug in the NIC (either broken hardware or a bug in the bge(4) driver) that makes it break TCP NFS packets somehow. I don't have any other explanation. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "... there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies and the other way is to make it so complicated that there are no _obvious_ deficiencies." -- C.A.R. Hoare, ACM Turing Award Lecture, 1980 From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 17:02:50 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F7F016A403; Tue, 14 Nov 2006 17:02:50 +0000 (UTC) (envelope-from steve@stevenwills.com) Received: from stevenwills.com (cpe-024-163-080-004.nc.res.rr.com [24.163.80.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F87F43D46; Tue, 14 Nov 2006 17:02:49 +0000 (GMT) (envelope-from steve@stevenwills.com) Received: from [10.0.0.58] ([208.44.167.67]) (authenticated bits=0) by stevenwills.com (8.13.1/8.13.1) with ESMTP id kAEH2feK008633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Nov 2006 12:02:43 -0500 (EST) (envelope-from steve@stevenwills.com) In-Reply-To: <20061114092953.R50450@fledge.watson.org> References: <9ABCABF7-2D44-496D-84A2-4C3CA4527355@stevenwills.com> <20061114092953.R50450@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Wills Date: Tue, 14 Nov 2006 12:02:43 -0500 To: Robert Watson X-Mailer: Apple Mail (2.752.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (stevenwills.com [24.163.80.4]); Tue, 14 Nov 2006 12:02:43 -0500 (EST) X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on tigger.example.com X-Virus-Scanned: ClamAV 0.88.4/2193/Tue Nov 14 09:03:11 2006 on tigger.example.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: audit and quota don't get along X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 17:02:50 -0000 On Nov 14, 2006, at 4:31 AM, Robert Watson wrote: > > A backtrace would be helpful. > Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06a1728 stack pointer = 0x28:0xcdb68c34 frame pointer = 0x28:0xcdb68c3c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 568 (auditd) [thread pid 568 tid 100047 ] Stopped at 0xc06a1728 = turnstile_broadcast+0x30: cmpl $0,0(% esi) db> bt Tracing pid 568 tid 100047 td 0xc247bc00 turnstile_broadcast(0,c247bc00,0,cdb68cdc,c07c1e1b,...) at 0xc06a1728 = turnstile_broadcast+0x30 _mtx_unlock_sleep(c09f7780,0,0,0) at 0xc06776a7 = _mtx_unlock_sleep+0x3f auditctl(c247bc00,cdb68d04) at 0xc07c1e1b = auditctl+0x14f syscall(3b,3b,3b,8054200,7,...) at 0xc08a154b = syscall+0x2cf Xint0x80_syscall() at 0xc088e94f = Xint0x80_syscall+0x1f --- syscall (453, FreeBSD ELF32, auditctl), eip = 0x280cbcb7, esp = 0xbfbfec1c, ebp = 0xbfbfec88 --- db> > Are you using quotas on the file system targeted by the audit > trail, or just on the system in general? Just on the system, but I'd like to have them together. > Is compiling quotas in sufficient to reproduce the problem, or must > quotas be enabled on at least one file system? Compiling quotas in is sufficient. Steve From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 17:16:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F388E16A403 for ; Tue, 14 Nov 2006 17:16:08 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out14.ilk.de [194.121.104.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5263643D49 for ; Tue, 14 Nov 2006 17:16:07 +0000 (GMT) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool58.ka.ilk.net [212.86.194.58]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id kAEHG5lB027986 for ; Tue, 14 Nov 2006 18:16:05 +0100 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.4+Sun/8.13.4) with ESMTP id kAEHFRXx014635 for ; Tue, 14 Nov 2006 18:15:32 +0100 (CET) Message-ID: <4559FAD5.2010806@smo.de> Date: Tue, 14 Nov 2006 18:20:21 +0100 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20061022 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Problems with man and less/more X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 17:16:09 -0000 Hi list, I just stumbled across a oddity when I use the `man'-command piped through `less' or `more'. What I do is the following: 1. $ man $some_program This works without problems. 2. $ man $some_program | less or: $ man $some_program | more This works without problems until I type `q' to return to the terminal. Then the following message appears on the screen[tm] an I get my shell-prompt: Error executing formatting or display command. system command exited with status 36096 Error executing formatting or display command. system command exited with status 36096 No manual entry for less $ For some man-pages (it seems the category doesn't matter), the message is two lines shorter: Error executing formatting or display command. system command exited with status 36096 No manual entry for X $ There's no difference whether I use `less' or `more'. My system is 6.2-PRERELEASE with sources from November 12th: $ uname -a FreeBSD herdubreid.xxx.xxx.de 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Sun Nov 12 16:02:01 CET 2006 pj@herdubreid.xxx.xxx.de:/usr/obj/usr/src/sys/HERDUBREIDKERNEL i386 Sorry if my report is unclear in some way. If you need more information, let me know. I will do my best to provide it ;) I can also provide some ktrace output if necessary. Regards, Philipp -- www.familie-ost.info/~pj From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 17:34:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C60316A407 for ; Tue, 14 Nov 2006 17:34:35 +0000 (UTC) (envelope-from jbrouwers@tritronics.com) Received: from smtp.tritronics.com (smtp.tritronics.com [63.162.185.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id E471143D77 for ; Tue, 14 Nov 2006 17:34:31 +0000 (GMT) (envelope-from jbrouwers@tritronics.com) Received: from exchange.tritronics.local (unknown [63.162.185.10]) by smtp.tritronics.com (Postfix) with ESMTP id ED27D1CC19 for ; Tue, 14 Nov 2006 10:34:25 -0700 (MST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 14 Nov 2006 10:34:16 -0700 Message-ID: <4B105A60788DFC4F906D026294B0B2AC018FF849@EXCHANGE.tritronics.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: init can't get /dev/console for controlling terminal: operation not permitted Thread-Index: AccIExuzH/SCA97tS8qXFfge70NT6A== From: "Jacques Brouwers" To: Subject: init can't get /dev/console for controlling terminal: operation not permitted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 17:34:35 -0000 Hi All, After upgrading (make buildworld ...) I do not receive the logon prompt anymore. I get the following message repeated on the screen numerous times.=20 "init: can't get /dev/console for controlling terminal: operation not permitted" Then every 10 minutes I get=20 "last message repeated 20 times" The ssh login method is still operational so I am not totally locked out of the system.=20 crw------- 1 root wheel 0, 10 Nov 14 10:28 console FreeBSD smtp.tritronics.com 6.1-SECURITY FreeBSD 6.1-SECURITY #0: Mon Aug 28 05:21:08 UTC 2006 root@builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD minimal install running postfix in a production environment. Thanks for any help, Jacques From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 17:41:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA02916A412; Tue, 14 Nov 2006 17:41:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id D262B43D53; Tue, 14 Nov 2006 17:41:08 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kAEHf1Tu077130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Nov 2006 19:41:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id kAEHf1cH001006; Tue, 14 Nov 2006 19:41:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kAEHf0fD001005; Tue, 14 Nov 2006 19:41:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 14 Nov 2006 19:41:00 +0200 From: Kostik Belousov To: Steve Wills Message-ID: <20061114174059.GB29623@deviant.kiev.zoral.com.ua> References: <9ABCABF7-2D44-496D-84A2-4C3CA4527355@stevenwills.com> <20061114092953.R50450@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: freebsd-stable@freebsd.org, Robert Watson Subject: Re: audit and quota don't get along X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 17:41:10 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 14, 2006 at 12:02:43PM -0500, Steve Wills wrote: > On Nov 14, 2006, at 4:31 AM, Robert Watson wrote: >=20 > > > >A backtrace would be helpful. > > >=20 > Fatal trap 12: page fault while in kernel mode > fault virtual address =3D 0x0 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc06a1728 > stack pointer =3D 0x28:0xcdb68c34 > frame pointer =3D 0x28:0xcdb68c3c > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D resume, IOPL =3D 0 > current process =3D 568 (auditd) > [thread pid 568 tid 100047 ] > Stopped at 0xc06a1728 =3D turnstile_broadcast+0x30: cmpl $0,0(%= =20 > esi) > db> bt > Tracing pid 568 tid 100047 td 0xc247bc00 > turnstile_broadcast(0,c247bc00,0,cdb68cdc,c07c1e1b,...) at 0xc06a1728 =20 > =3D turnstile_broadcast+0x30 > _mtx_unlock_sleep(c09f7780,0,0,0) at 0xc06776a7 =3D _mtx_unlock_sleep+0x3f > auditctl(c247bc00,cdb68d04) at 0xc07c1e1b =3D auditctl+0x14f > syscall(3b,3b,3b,8054200,7,...) at 0xc08a154b =3D syscall+0x2cf > Xint0x80_syscall() at 0xc088e94f =3D Xint0x80_syscall+0x1f > --- syscall (453, FreeBSD ELF32, auditctl), eip =3D 0x280cbcb7, esp =3D = =20 > 0xbfbfec1c, ebp =3D 0xbfbfec88 --- > db> >=20 > >Are you using quotas on the file system targeted by the audit =20 > >trail, or just on the system in general? >=20 > Just on the system, but I'd like to have them together. >=20 > >Is compiling quotas in sufficient to reproduce the problem, or must =20 > >quotas be enabled on at least one file system? >=20 > Compiling quotas in is sufficient. >=20 I'm wondering how many people are tripped over this feature of vn_open. Please, try the patch: Index: sys/security/audit/audit_syscalls.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/arch/ncvs/src/sys/security/audit/audit_syscalls.c,v retrieving revision 1.1.2.4 diff -u -r1.1.2.4 audit_syscalls.c --- sys/security/audit/audit_syscalls.c 16 Oct 2006 15:03:48 -0000 1.1.2.4 +++ sys/security/audit/audit_syscalls.c 14 Nov 2006 17:40:01 -0000 @@ -580,9 +580,9 @@ error =3D vn_open(&nd, &flags, 0, -1); if (error) return (error); - vfslocked =3D NDHASGIANT(&nd); - VOP_UNLOCK(nd.ni_vp, 0, td); vp =3D nd.ni_vp; + vfslocked =3D VFS_LOCK_GIANT(vp->v_mount); + VOP_UNLOCK(nd.ni_vp, 0, td); if (vp->v_type !=3D VREG) { vn_close(vp, AUDIT_CLOSE_FLAGS, td->td_ucred, td); VFS_UNLOCK_GIANT(vfslocked); --1LKvkjL3sHcu1TtY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWf+rC3+MBN1Mb4gRAnVjAJoDb0iLRH+NW155Vas7Rh8eISkfwQCdH2QE cToknSjg8/RvV6sAI+dCflQ= =jLn/ -----END PGP SIGNATURE----- --1LKvkjL3sHcu1TtY-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 18:03:32 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 788A316A40F for ; Tue, 14 Nov 2006 18:03:32 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC51E43D46 for ; Tue, 14 Nov 2006 18:03:30 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (kdqted@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAEI3OUE046982; Tue, 14 Nov 2006 19:03:29 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAEI3ODW046981; Tue, 14 Nov 2006 19:03:24 +0100 (CET) (envelope-from olli) Date: Tue, 14 Nov 2006 19:03:24 +0100 (CET) Message-Id: <200611141803.kAEI3ODW046981@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, pj@smo.de In-Reply-To: <4559FAD5.2010806@smo.de> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 14 Nov 2006 19:03:29 +0100 (CET) Cc: Subject: Re: Problems with man and less/more X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, pj@smo.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 18:03:32 -0000 Philipp Ost wrote: > I just stumbled across a oddity when I use the `man'-command piped > through `less' or `more'. > > What I do is the following: > 1. $ man $some_program > This works without problems. > 2. $ man $some_program | less or: $ man $some_program | more > This works without problems until I type `q' to return to the terminal. > Then the following message appears on the screen[tm] an I get my > shell-prompt: > > Error executing formatting or display command. > system command exited with status 36096 > Error executing formatting or display command. > system command exited with status 36096 > No manual entry for less > $ The man(1) command doesn't like it at all when its pager process gets a "broken pipe" signal. It isn't capable of handling that situation gracefully. You can reproduce the problem without any less(1) involved: $ export PAGER=cat $ man csh | head You will see the same error messages from man(1). > For some man-pages (it seems the category doesn't matter), the message > is two lines shorter: > > Error executing formatting or display command. > system command exited with status 36096 > No manual entry for X > $ It probably depends on the size of the manual page. For short pages, the second less(1) instance reaches EOF before you press "q". > There's no difference whether I use `less' or `more'. They're the same: 465840 -r-xr-xr-x 2 root wheel 109300 Nov 9 10:43 /usr/bin/less 465840 -r-xr-xr-x 2 root wheel 109300 Nov 9 10:43 /usr/bin/more And you can also use head(1), false(1), or "sed 1q", or any other command that will close its standard input prematurely (i.e. before it reads everything through EOF). > My system is 6.2-PRERELEASE with sources from November 12th: The problem is pretty old, I can even reproduce it on a FreeBSD 4.x machine. Normally there is no need to pipe man(1) output through less(1) (why would you want to do that?), so there's no real problem. Just set $PAGER appropriately. By the way, the default (if not set) is "more -s", which is the same as "less -s". Therefore, piping output from man(1) through less(1) doesn't really make sense. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "When your hammer is C++, everything begins to look like a thumb." -- Steve Haflich, in comp.lang.c++ From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 18:16:44 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F18ED16A40F for ; Tue, 14 Nov 2006 18:16:44 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2CE843D46 for ; Tue, 14 Nov 2006 18:16:44 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 7C1A01A3C19 for ; Tue, 14 Nov 2006 10:16:44 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5A88C51322; Tue, 14 Nov 2006 13:16:33 -0500 (EST) Date: Tue, 14 Nov 2006 13:16:33 -0500 From: Kris Kennaway To: stable@freebsd.org Message-ID: <20061114181633.GA88316@xor.obsecurity.org> References: <20061113084430.GE59604@dimma.mow.oilspace.com> <20061113184505.GA51659@xor.obsecurity.org> <20061114075020.GA1154@dimma.mow.oilspace.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <20061114075020.GA1154@dimma.mow.oilspace.com> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 18:16:45 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 14, 2006 at 10:50:21AM +0300, Dmitriy Kirhlarov wrote: > On Mon, Nov 13, 2006 at 01:45:05PM -0500, Kris Kennaway wrote: > > On Mon, Nov 13, 2006 at 11:44:31AM +0300, Dmitriy Kirhlarov wrote: > > > Hi, list. > > >=20 > > > One from my monitoring servers running with > > > FreeBSD 6.2-PRERELEASE #0: Fri Nov 10 11:03:10 UTC 2006 i386 > > >=20 > > > Under heavy load it panic several times per day. Backtrace accesable: > > > http://clh.higis.ru/~dimma/btfull.0=20 > > > Can somebody take a look? > > > I send Problem Report, but not get feed back now from gnats. >=20 > > Please provide your kernel config. >=20 > http://clh.higis.ru/~dimma/OILSPACE1DEB >=20 > I open PR for this problem -- kern/105464 Are you using unionfs? It's too broken to use, so you might as well take it out of your kernel config. Kris --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWggAWry0BWjoQKURAidnAKCBtq2Ar6OtiM4F7ydCjbDEjXXqFgCfS2bK W+bcwfwNw9CeH5kcUq/sPAM= =ZFfJ -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 18:51:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66C8316A40F for ; Tue, 14 Nov 2006 18:51:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DF9C43D49 for ; Tue, 14 Nov 2006 18:51:53 +0000 (GMT) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-67-174-220-97.hsd1.ca.comcast.net[67.174.220.97]) by comcast.net (rwcrmhc13) with ESMTP id <20061114185152m13004r1t5e>; Tue, 14 Nov 2006 18:51:52 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5DF6C1FA01D; Tue, 14 Nov 2006 10:51:52 -0800 (PST) Date: Tue, 14 Nov 2006 10:51:52 -0800 From: Jeremy Chadwick To: freebsd-stable@FreeBSD.ORG, pj@smo.de Message-ID: <20061114185152.GA43923@icarus.home.lan> Mail-Followup-To: freebsd-stable@FreeBSD.ORG, pj@smo.de References: <4559FAD5.2010806@smo.de> <200611141803.kAEI3ODW046981@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611141803.kAEI3ODW046981@lurza.secnetix.de> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: Problems with man and less/more X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 18:51:53 -0000 On Tue, Nov 14, 2006 at 07:03:24PM +0100, Oliver Fromme wrote: > Just set $PAGER appropriately. By the way, the default > (if not set) is "more -s", which is the same as "less -s". > Therefore, piping output from man(1) through less(1) > doesn't really make sense. Maybe this should be done by the default in /etc/profile and /etc/csh.cshrc for people who don't override it? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 18:53:56 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C024C16A492 for ; Tue, 14 Nov 2006 18:53:56 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D68B43D53 for ; Tue, 14 Nov 2006 18:53:56 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 4BF861A4D89 for ; Tue, 14 Nov 2006 10:53:56 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2A3E851341; Tue, 14 Nov 2006 13:53:45 -0500 (EST) Date: Tue, 14 Nov 2006 13:53:45 -0500 From: Kris Kennaway To: stable@freebsd.org Message-ID: <20061114185344.GA89030@xor.obsecurity.org> References: <20061113084430.GE59604@dimma.mow.oilspace.com> <20061113184505.GA51659@xor.obsecurity.org> <20061114075020.GA1154@dimma.mow.oilspace.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: <20061114075020.GA1154@dimma.mow.oilspace.com> User-Agent: Mutt/1.4.2.2i Cc: Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 18:53:56 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 14, 2006 at 10:50:21AM +0300, Dmitriy Kirhlarov wrote: > On Mon, Nov 13, 2006 at 01:45:05PM -0500, Kris Kennaway wrote: > > On Mon, Nov 13, 2006 at 11:44:31AM +0300, Dmitriy Kirhlarov wrote: > > > Hi, list. > > >=20 > > > One from my monitoring servers running with > > > FreeBSD 6.2-PRERELEASE #0: Fri Nov 10 11:03:10 UTC 2006 i386 > > >=20 > > > Under heavy load it panic several times per day. Backtrace accesable: > > > http://clh.higis.ru/~dimma/btfull.0=20 > > > Can somebody take a look? > > > I send Problem Report, but not get feed back now from gnats. >=20 > > Please provide your kernel config. >=20 > http://clh.higis.ru/~dimma/OILSPACE1DEB >=20 > I open PR for this problem -- kern/105464 =46rom alc@: --- I've never seen anything like this before. UMA is failing to allocate the zone structure. This is unrelated to the large-swap scenario that you ran into. Ask him to uncomment all of the UMA debugging #define's at the start of uma_core.c. Alan --- Kris --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWhC4Wry0BWjoQKURAqQUAKCWXe+Txp7zy//nnqwYEAdky7xlsACfYCoE 6tk23ckLrxtR77AdWFVqBIM= =XiWf -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 19:19:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9168E16A4C8; Tue, 14 Nov 2006 19:19:44 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62CFF43D5A; Tue, 14 Nov 2006 19:18:03 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 8B7461A3C1C; Tue, 14 Nov 2006 11:17:24 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 4C24051341; Tue, 14 Nov 2006 14:17:13 -0500 (EST) Date: Tue, 14 Nov 2006 14:17:13 -0500 From: Kris Kennaway To: Vlad Galu Message-ID: <20061114191713.GA89460@xor.obsecurity.org> References: <200610010015.k910F6Ba001594@cwsys.cwsent.com> <45475DEA.2030506@centtech.com> <20061031193139.GA27951@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Frequent VFS crashes with RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 19:19:44 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 14, 2006 at 05:10:23PM +0200, Vlad Galu wrote: > On 11/1/06, Vlad Galu wrote: > >On 10/31/06, Kris Kennaway wrote: > >> On Tue, Oct 31, 2006 at 04:34:59PM +0200, Vlad Galu wrote: > >> > >> > Yes, but for objective reasons I can't publish it :( > >> > The only > >> > debugging option that I didn't use was INVARIANTS. > >> > >> Which is coincidentally the most useful one ;-) > >> > >> Also turn on DEBUG_LOCKS and DEBUG_VFS_LOCKS then report the output of > >> 'show lockedvnods' at the time of crash, as well. >=20 > Upon Tor Egge's suggestion, I removed ZERO_COPY_SOCKETS from my > kernel and the machine has been running nicely ever since. Glad to hear it, depending on what Tor had to say you might want to file a PR about that. Kris --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWhY4Wry0BWjoQKURAn7YAJ41i0lHxAiQQ7tjGPWYKQLlpJxNCgCgvQ4B tJgPSleM5AciNuoseCttNYA= =dL+Q -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 19:36:21 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5566116A494; Tue, 14 Nov 2006 19:36:21 +0000 (UTC) (envelope-from steve@stevenwills.com) Received: from stevenwills.com (cpe-024-163-080-004.nc.res.rr.com [24.163.80.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E61743D69; Tue, 14 Nov 2006 19:36:12 +0000 (GMT) (envelope-from steve@stevenwills.com) Received: from [10.0.0.58] ([208.44.167.67]) (authenticated bits=0) by stevenwills.com (8.13.1/8.13.1) with ESMTP id kAEJa6rD014192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Nov 2006 14:36:07 -0500 (EST) (envelope-from steve@stevenwills.com) In-Reply-To: <20061114174059.GB29623@deviant.kiev.zoral.com.ua> References: <9ABCABF7-2D44-496D-84A2-4C3CA4527355@stevenwills.com> <20061114092953.R50450@fledge.watson.org> <20061114174059.GB29623@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Wills Date: Tue, 14 Nov 2006 14:36:08 -0500 To: Kostik Belousov X-Mailer: Apple Mail (2.752.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (stevenwills.com [24.163.80.4]); Tue, 14 Nov 2006 14:36:07 -0500 (EST) X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on tigger.example.com X-Virus-Scanned: ClamAV 0.88.4/2194/Tue Nov 14 12:26:01 2006 on tigger.example.com X-Virus-Status: Clean Cc: Robert Watson , freebsd-stable@freebsd.org Subject: Re: audit and quota don't get along X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 19:36:21 -0000 On Nov 14, 2006, at 12:41 PM, Kostik Belousov wrote: > I'm wondering how many people are tripped over this feature of > vn_open. > > Please, try the patch: That fixes it, thanks. Steve From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 19:50:16 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8790016A416 for ; Tue, 14 Nov 2006 19:50:16 +0000 (UTC) (envelope-from atanas@asd.aplus.net) Received: from pro20.abac.com (pro20.abac.com [66.226.64.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 562D443D98 for ; Tue, 14 Nov 2006 19:50:05 +0000 (GMT) (envelope-from atanas@asd.aplus.net) Received: from [216.55.129.232] ([216.55.129.232]) (authenticated bits=0) by pro20.abac.com (8.13.8/8.13.8) with ESMTP id kAEJnuHS070096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Nov 2006 11:49:57 -0800 (PST) (envelope-from atanas@asd.aplus.net) Message-ID: <455A1DEA.20304@asd.aplus.net> Date: Tue, 14 Nov 2006 11:50:02 -0800 From: Atanas User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary="------------090304060004050009080503" X-Spam-Score: 1.47 (SPF_SOFTFAIL) Subject: twa: Passthru request timed out! Resetting controller... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 19:50:16 -0000 This is a multi-part message in MIME format. --------------090304060004050009080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Has anyone experiencing this: twa0: ERROR: (0x05: 0x2018): Passthru request timed out!: request = 0xca839d20 twa0: INFO: (0x16: 0x1108): Resetting controller...: twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=0 ... twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=7 twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=1 twa0: INFO: (0x16: 0x1107): Controller reset done!: This happens on 6.2-PRERELEASE i386 (and on 6.1 since its release) on a number of machines with the following hardware configuration: - Tyan K8SE 2892, 2 AMD Opteron 270 CPUs, 4GB RAM - 3ware 9550SX-8LP, 8 500GB Seagate ST3500641AS SATA drives (configured as 8 SINGLE DISK units, aka JBOD) All hardware components, including the server chassis, are listed in the 3ware hardware compatibility lists. It doesn't seem to be a cabling or power issue. The controller and hard drives are already flashed to the latest firmware revisions. I tried turning off NCQ, but it didn't make any difference. I tried also switching the kernel from PAE to non-PAE (reducing the usable memory to 3GB), but it didn't help either. I have another machines with similar I/O configurations (3ware), but with Intel motherboards and running FreeBSD-5.5, and these run fine for about a year already. Now I'm thinking about swapping the drives between a working Intel and AMD based box, to see where controller timeouts will follow. The problem happens sporadically once in a month or so and is very hard to reproduce. Sometimes it takes several weeks until the next crash happens, sometimes it crashes again in just a few hours. When the thing happens, the kernel sometimes panics (most likely due to the inconsistent filesystem state caused by the controller reset), sometimes just hangs. It can be interrupted (I have a serial console), but the only usable thing after that seems to be "call cpu_reset()", followed by full (and sometimes painfully long) filesystem check. Here are the diffs against the default GENERIC and PAE kernel configurations: < cpu I486_CPU < ident GENERIC < options INET6 # IPv6 communications protocols < options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI > options QUOTA > options SMP # Symmetric MultiProcessor Kernel > options BREAK_TO_DEBUGGER > options DDB > options KDB > options KDB_UNATTENDED > options IPFIREWALL > options DUMMYNET I'm attaching the dmesg.boot following the latest crash. Regards, Atanas --------------090304060004050009080503 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="dmesg.boot" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.boot" Copyright (c) 1992-2006 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 6.2-PRERELEASE #0: Mon Nov 13 17:47:40 PST 2006 root@xyz:/var/obj/usr/src/sys/XYZ-PAE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Dual Core AMD Opteron(tm) Processor 270 (2009.27-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x3 Cores per package: 2 real memory = 5368709120 (5120 MB) avail memory = 4182241280 (3988 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 2.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 ata0: on atapci0 ata1: on atapci0 pcib1: at device 9.0 on pci0 pci1: on pcib1 pci1: at device 6.0 (no driver attached) fxp0: port 0x2400-0x243f mem 0xda101000-0xda101fff,0xda120000-0xda13ffff irq 16 at device 8.0 on pci1 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:e0:81:33:b5:f1 pcib2: at device 13.0 on pci0 pci2: on pcib2 pcib3: at device 14.0 on pci0 pci3: on pcib3 pcib4: port 0xcf8-0xcff on acpi0 pci24: on pcib4 pcib5: at device 10.0 on pci24 pci25: on pcib5 3ware device driver for 9000 series storage controllers, version: 3.60.02.012 twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem 0xde000000-0xdfffffff,0xdc300000-0xdc300fff irq 27 at device 3.0 on pci25 twa0: [FAST] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-8LP, 8 ports, Firmware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002 pci24: at device 10.1 (no driver attached) pcib6: at device 11.0 on pci24 pci26: on pcib6 bge0: mem 0xdc410000-0xdc41ffff,0xdc400000-0xdc40ffff irq 28 at device 9.0 on pci26 miibus1: on bge0 brgphy0: on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: Ethernet address: 00:e0:81:33:b6:f4 bge1: mem 0xdc430000-0xdc43ffff,0xdc420000-0xdc42ffff irq 29 at device 9.1 on pci26 miibus2: on bge1 brgphy1: on miibus2 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge1: Ethernet address: 00:e0:81:33:b6:f5 pci24: at device 11.1 (no driver attached) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 100.000MB/s transfers da0: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) da1 at twa0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 100.000MB/s transfers da1: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) da2 at twa0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 100.000MB/s transfers da2: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) da3 at twa0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 100.000MB/s transfers da3: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) da4 at twa0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-3 device da4: 100.000MB/s transfers da4: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) da5 at twa0 bus 0 target 5 lun 0 da5: Fixed Direct Access SCSI-3 device da5: 100.000MB/s transfers da5: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) da6 at twa0 bus 0 target 6 lun 0 da6: Fixed Direct Access SCSI-3 device da6: 100.000MB/s transfers da6: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) da7 at twa0 bus 0 target 7 lun 0 da7: Fixed Direct Access SCSI-3 device da7: 100.000MB/s transfers da7: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/da0s1a WARNING: / was not properly dismounted /: mount pending error: blocks 208 files 5 --------------090304060004050009080503-- From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 19:59:14 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CD7F16A4D2 for ; Tue, 14 Nov 2006 19:59:14 +0000 (UTC) (envelope-from aradford@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE5C643DF5 for ; Tue, 14 Nov 2006 19:56:28 +0000 (GMT) (envelope-from aradford@gmail.com) Received: by wr-out-0506.google.com with SMTP id i20so735119wra for ; Tue, 14 Nov 2006 11:56:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZhdZDVCxz1EL57U003YLojel2ZkmE6qjHs248PKWaxTrQVZBEKvjXmBrjnAUI0FvqMi6lC4S1qy9LCbK27rPl+S/TUOb2a5pnq6pfUkNo6DD614yWCCLpDmU9ABcdE8H7vFKLPO14qTW+fNaZedAf/UBAZ+RlCI5v4UOa03TdqA= Received: by 10.78.25.11 with SMTP id 11mr1329663huy.1163534185693; Tue, 14 Nov 2006 11:56:25 -0800 (PST) Received: by 10.78.154.13 with HTTP; Tue, 14 Nov 2006 11:56:25 -0800 (PST) Message-ID: Date: Tue, 14 Nov 2006 11:56:25 -0800 From: "adam radford" To: Atanas In-Reply-To: <455A1DEA.20304@asd.aplus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455A1DEA.20304@asd.aplus.net> Cc: freebsd-stable@freebsd.org Subject: Re: twa: Passthru request timed out! Resetting controller... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 19:59:14 -0000 Atanas, Are you running the latest 3ware firmware on that controller? -Adam On 11/14/06, Atanas wrote: > Has anyone experiencing this: > > twa0: ERROR: (0x05: 0x2018): Passthru request timed out!: request = > 0xca839d20 > twa0: INFO: (0x16: 0x1108): Resetting controller...: > > twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=0 > > ... > twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=7 > > twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=1 > > twa0: INFO: (0x16: 0x1107): Controller reset done!: > > > This happens on 6.2-PRERELEASE i386 (and on 6.1 since its release) on a > number of machines with the following hardware configuration: > > - Tyan K8SE 2892, 2 AMD Opteron 270 CPUs, 4GB RAM > - 3ware 9550SX-8LP, 8 500GB Seagate ST3500641AS SATA drives > (configured as 8 SINGLE DISK units, aka JBOD) > > All hardware components, including the server chassis, are listed in the > 3ware hardware compatibility lists. It doesn't seem to be a cabling or > power issue. The controller and hard drives are already flashed to the > latest firmware revisions. I tried turning off NCQ, but it didn't make > any difference. I tried also switching the kernel from PAE to non-PAE > (reducing the usable memory to 3GB), but it didn't help either. > > I have another machines with similar I/O configurations (3ware), but > with Intel motherboards and running FreeBSD-5.5, and these run fine for > about a year already. Now I'm thinking about swapping the drives between > a working Intel and AMD based box, to see where controller timeouts will > follow. > > The problem happens sporadically once in a month or so and is very hard > to reproduce. Sometimes it takes several weeks until the next crash > happens, sometimes it crashes again in just a few hours. > > When the thing happens, the kernel sometimes panics (most likely due to > the inconsistent filesystem state caused by the controller reset), > sometimes just hangs. It can be interrupted (I have a serial console), > but the only usable thing after that seems to be "call cpu_reset()", > followed by full (and sometimes painfully long) filesystem check. > > Here are the diffs against the default GENERIC and PAE kernel > configurations: > > < cpu I486_CPU > < ident GENERIC > < options INET6 # IPv6 communications protocols > < options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI > > > options QUOTA > > options SMP # Symmetric MultiProcessor Kernel > > options BREAK_TO_DEBUGGER > > options DDB > > options KDB > > options KDB_UNATTENDED > > > options IPFIREWALL > > options DUMMYNET > > I'm attaching the dmesg.boot following the latest crash. > > Regards, > Atanas > > > > Copyright (c) 1992-2006 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 6.2-PRERELEASE #0: Mon Nov 13 17:47:40 PST 2006 > root@xyz:/var/obj/usr/src/sys/XYZ-PAE > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Dual Core AMD Opteron(tm) Processor 270 (2009.27-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 > Features=0x178bfbff > Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x3 > Cores per package: 2 > real memory = 5368709120 (5120 MB) > avail memory = 4182241280 (3988 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-27 on motherboard > ioapic2 irqs 28-31 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > isab0: at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > pci0: at device 2.0 (no driver attached) > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pcib1: at device 9.0 on pci0 > pci1: on pcib1 > pci1: at device 6.0 (no driver attached) > fxp0: port 0x2400-0x243f mem 0xda101000-0xda101fff,0xda120000-0xda13ffff irq 16 at device 8.0 on pci1 > miibus0: on fxp0 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:e0:81:33:b5:f1 > pcib2: at device 13.0 on pci0 > pci2: on pcib2 > pcib3: at device 14.0 on pci0 > pci3: on pcib3 > pcib4: port 0xcf8-0xcff on acpi0 > pci24: on pcib4 > pcib5: at device 10.0 on pci24 > pci25: on pcib5 > 3ware device driver for 9000 series storage controllers, version: 3.60.02.012 > twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem 0xde000000-0xdfffffff,0xdc300000-0xdc300fff irq 27 at device 3.0 on pci25 > twa0: [FAST] > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-8LP, 8 ports, Firmware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002 > pci24: at device 10.1 (no driver attached) > pcib6: at device 11.0 on pci24 > pci26: on pcib6 > bge0: mem 0xdc410000-0xdc41ffff,0xdc400000-0xdc40ffff irq 28 at device 9.0 on pci26 > miibus1: on bge0 > brgphy0: on miibus1 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto > bge0: Ethernet address: 00:e0:81:33:b6:f4 > bge1: mem 0xdc430000-0xdc43ffff,0xdc420000-0xdc42ffff irq 29 at device 9.1 on pci26 > miibus2: on bge1 > brgphy1: on miibus2 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto > bge1: Ethernet address: 00:e0:81:33:b6:f5 > pci24: at device 11.1 (no driver attached) > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A, console > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff on isa0 > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled > da0 at twa0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 100.000MB/s transfers > da0: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da1 at twa0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 100.000MB/s transfers > da1: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da2 at twa0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI-3 device > da2: 100.000MB/s transfers > da2: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da3 at twa0 bus 0 target 3 lun 0 > da3: Fixed Direct Access SCSI-3 device > da3: 100.000MB/s transfers > da3: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da4 at twa0 bus 0 target 4 lun 0 > da4: Fixed Direct Access SCSI-3 device > da4: 100.000MB/s transfers > da4: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da5 at twa0 bus 0 target 5 lun 0 > da5: Fixed Direct Access SCSI-3 device > da5: 100.000MB/s transfers > da5: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da6 at twa0 bus 0 target 6 lun 0 > da6: Fixed Direct Access SCSI-3 device > da6: 100.000MB/s transfers > da6: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da7 at twa0 bus 0 target 7 lun 0 > da7: Fixed Direct Access SCSI-3 device > da7: 100.000MB/s transfers > da7: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #3 Launched! > Trying to mount root from ufs:/dev/da0s1a > WARNING: / was not properly dismounted > /: mount pending error: blocks 208 files 5 > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 20:00:27 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABDE816A4A0 for ; Tue, 14 Nov 2006 20:00:27 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92C3B43DEA for ; Tue, 14 Nov 2006 20:00:08 +0000 (GMT) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 53AD14204; Tue, 14 Nov 2006 11:59:53 -0800 (PST) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "satchel.alerce.com", Issuer "alerce.com" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id 0900E4203; Tue, 14 Nov 2006 11:59:52 -0800 (PST) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.4/8.13.4) with ESMTP id kAEK06m8070456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Nov 2006 12:00:06 -0800 (PST) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.4/8.13.4/Submit) id kAEK02vS070437; Tue, 14 Nov 2006 12:00:02 -0800 (PST) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17754.8258.37357.575054@satchel.alerce.com> Date: Tue, 14 Nov 2006 12:00:02 -0800 To: freebsd-stable@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP Subject: help identifying gmirror, ata, or motherboard problem (Tyan S2865G2NR) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 20:00:27 -0000 I'm having a problem with a machine that I support and would like some feedback. The system was built up from a barebones Transport PX22, which uses a Tyan S2865G2NR motherboard. It has two drives: ad4: 286188MB at ata2-master SATA300 ad6: 286188MB at ata3-master SATA300 A while back I noticed in the daily periodic report that gmirror had dropped ad4. We rebooted and got things going again and it ran smoothly for a month or so, then dropped it again. At that point we did a warranty replacement of ad4 and things have been running smoothly for a couple of months. A few days ago gmirror kicked ad6 out of the raid, which the following lines in dmesg: ad6: FAILURE - device detached subdisk6: detached ad6: detached GEOM_MIRROR: Device gm0s1: provider ad6s1 disconnected. We're adding an external device into the mirror and are planning to do a warranty swap on this drive too. The system is running, but feels sluggish. It might be interesting to note that the disk activity light is continuously lit. The system if running the stock 6.1 RELEASE. FreeBSD foo.com 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:15:57 UTC 2006 root@bloom.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP amd64 I'm trying to figure out if we've just gotten two lousy disks, or if there might be a driver or motherboard issue. Does any of this ring any bells? I'm suggesting that we upgrade to the tip of the stable tree, but the owner's not convinced. I can't tell if there's been anything relevant in the stable release that might address this (aside from all the other great stuff that's in there). Thanks for any input, g. From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 20:46:29 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EF1C16A4CA for ; Tue, 14 Nov 2006 20:46:29 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from bart.milos.co.za (bart.milos.co.za [196.38.18.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEABE44094 for ; Tue, 14 Nov 2006 20:39:28 +0000 (GMT) (envelope-from clay@milos.co.za) Received: (qmail 98017 invoked by uid 89); 14 Nov 2006 20:39:13 -0000 Received: from unknown (HELO claylaptop) (clay@milos.za.net@192.168.3.150) by bart.milos.co.za with SMTP; 14 Nov 2006 20:39:13 -0000 Message-ID: <010901c7082c$e9113230$9603a8c0@claylaptop> From: "Clayton Milos" To: References: <17754.8258.37357.575054@satchel.alerce.com> Date: Tue, 14 Nov 2006 22:38:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: freebsd-stable@freebsd.org Subject: Re: help identifying gmirror, ata, or motherboard problem (Tyan S2865G2NR) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 20:46:29 -0000 Some advice here from a guy that's been doing professional data recovery for years... Don't touch Maxtor. Ever. Luckily Fujitsu don't make ide drives any more. They were worse than Maxtor. If you have existing Maxtor dirves and can't change them make sure you keep them as cool as possible. I would recommend Western Digital or Seagate for IDE drives. Western Digital make RAID edition drives which are very fast and reliable which I personally favour for these kind of situations and they only cost a bit more. -Clay ----- Original Message ----- From: "George Hartzell" To: Sent: Tuesday, November 14, 2006 10:00 PM Subject: help identifying gmirror, ata,or motherboard problem (Tyan S2865G2NR) > > I'm having a problem with a machine that I support and would like some > feedback. > > The system was built up from a barebones Transport PX22, which uses a > Tyan S2865G2NR motherboard. > > It has two drives: > > ad4: 286188MB at ata2-master SATA300 > ad6: 286188MB at ata3-master SATA300 > > A while back I noticed in the daily periodic report that gmirror had > dropped ad4. We rebooted and got things going again and it ran > smoothly for a month or so, then dropped it again. > > At that point we did a warranty replacement of ad4 and things have > been running smoothly for a couple of months. > > A few days ago gmirror kicked ad6 out of the raid, which the following > lines in dmesg: > > ad6: FAILURE - device detached > subdisk6: detached > ad6: detached > GEOM_MIRROR: Device gm0s1: provider ad6s1 disconnected. > > We're adding an external device into the mirror and are planning to do > a warranty swap on this drive too. > > The system is running, but feels sluggish. It might be interesting to > note that the disk activity light is continuously lit. > > The system if running the stock 6.1 RELEASE. > > FreeBSD foo.com 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:15:57 > UTC 2006 root@bloom.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP amd64 > > I'm trying to figure out if we've just gotten two lousy disks, or if > there might be a driver or motherboard issue. > > Does any of this ring any bells? > > I'm suggesting that we upgrade to the tip of the stable tree, but the > owner's not convinced. I can't tell if there's been anything relevant > in the stable release that might address this (aside from all the > other great stuff that's in there). > > Thanks for any input, > > g. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 20:52:02 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D17BB16A49E for ; Tue, 14 Nov 2006 20:52:02 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CCB94403A for ; Tue, 14 Nov 2006 20:46:46 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gk5Ao-0002ky-7W for freebsd-stable@freebsd.org; Tue, 14 Nov 2006 21:46:26 +0100 Received: from r5h168.net.upc.cz ([86.49.7.168]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Nov 2006 21:46:26 +0100 Received: from gamato by r5h168.net.upc.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Nov 2006 21:46:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: martinko Date: Tue, 14 Nov 2006 21:46:06 +0100 Lines: 45 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: r5h168.net.upc.cz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.8) Gecko/20061111 SeaMonkey/1.0.6 In-Reply-To: Sender: news Subject: Re: adding an extra hard disk and adding space to /usr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 20:52:02 -0000 Aaron Burke wrote: > SNIP >>> (FreeBSD 4.x) : cd /usr; tar clpf - . | (cd /mnt; tar xvf -) >>> (FreeBSD 5.x+) : cd /usr; gtar clpf - . | (cd /mnt; gtar xvf -) >> iirc tar(1) has changed in 5.3. why do you use gtar please? is new tar >> missing something? > Well, technically no, but it requires more typing. > > gtar supports the same flags that were present on FreeBSD up till 4.x > (or as you say, perhaps as late as 5.3). However, the more typical tar > now has a completly undesired effect. The main difference is how the > 'l' flag is treated. > > excerpt from tar man page: > BUGS > POSIX and GNU violently disagree about the meaning of the -l option. > Because of the potential for disaster if someone expects one behavior > and > gets the other, the -l option is deliberately broken in this > implementa- > tion. > > another excerpt from the tar man page. (FreeBSD 5.4-Release): > -l If POSIXLY_CORRECT is specified in the environment, this is a > synonym for the --check-links option. Otherwise, an error will > be displayed. Users who desire behavior compatible with GNU > tar > should use the --one-file-system option instead. > > excerpt from gtar man page (FreeBSD 5.4-Release): > -l > --one-file-system Stay in local file system when creating an ar- > chive (do not cross mount points). > Well, good news everyone :) according to new GNU tar 1.16 announcement "-l" option has finally been fixed to comply with POSIX: "** Short option -l is now an alias of --check-links option, which complies with UNIX98. This ends the transition period started with version 1.14." Regards, M:) From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 20:52:43 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63CFE16A560 for ; Tue, 14 Nov 2006 20:52:43 +0000 (UTC) (envelope-from atanas@asd.aplus.net) Received: from pro20.abac.com (pro20.abac.com [66.226.64.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42DE743E6D for ; Tue, 14 Nov 2006 20:47:38 +0000 (GMT) (envelope-from atanas@asd.aplus.net) Received: from [216.55.129.232] ([216.55.129.232]) (authenticated bits=0) by pro20.abac.com (8.13.8/8.13.8) with ESMTP id kAEKlZGR086891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Nov 2006 12:47:35 -0800 (PST) (envelope-from atanas@asd.aplus.net) Message-ID: <455A2B6E.20705@asd.aplus.net> Date: Tue, 14 Nov 2006 12:47:42 -0800 From: Atanas User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: adam radford References: <455A1DEA.20304@asd.aplus.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.47 (SPF_SOFTFAIL) Cc: freebsd-stable@freebsd.org Subject: Re: twa: Passthru request timed out! Resetting controller... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 20:52:43 -0000 adam radford said the following on 11/14/06 11:56 AM: > > Are you running the latest 3ware firmware on that controller? > Yep. It's in dmesg.boot: twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-8LP, 8 ports, Firmware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002 That's the latest one released as 9.3.0.7 on the 3ware website. Yesterday flashed and rebooted them all, and this morning I got the next crash. Regards, Atanas > > On 11/14/06, Atanas wrote: >> Has anyone experiencing this: >> >> twa0: ERROR: (0x05: 0x2018): Passthru request timed out!: request = >> 0xca839d20 >> twa0: INFO: (0x16: 0x1108): Resetting controller...: >> >> twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=0 >> >> ... >> twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=7 >> >> twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=1 >> >> twa0: INFO: (0x16: 0x1107): Controller reset done!: >> >> >> This happens on 6.2-PRERELEASE i386 (and on 6.1 since its release) on a >> number of machines with the following hardware configuration: >> >> - Tyan K8SE 2892, 2 AMD Opteron 270 CPUs, 4GB RAM >> - 3ware 9550SX-8LP, 8 500GB Seagate ST3500641AS SATA drives >> (configured as 8 SINGLE DISK units, aka JBOD) >> >> All hardware components, including the server chassis, are listed in the >> 3ware hardware compatibility lists. It doesn't seem to be a cabling or >> power issue. The controller and hard drives are already flashed to the >> latest firmware revisions. I tried turning off NCQ, but it didn't make >> any difference. I tried also switching the kernel from PAE to non-PAE >> (reducing the usable memory to 3GB), but it didn't help either. >> >> I have another machines with similar I/O configurations (3ware), but >> with Intel motherboards and running FreeBSD-5.5, and these run fine for >> about a year already. Now I'm thinking about swapping the drives between >> a working Intel and AMD based box, to see where controller timeouts will >> follow. >> >> The problem happens sporadically once in a month or so and is very hard >> to reproduce. Sometimes it takes several weeks until the next crash >> happens, sometimes it crashes again in just a few hours. >> >> When the thing happens, the kernel sometimes panics (most likely due to >> the inconsistent filesystem state caused by the controller reset), >> sometimes just hangs. It can be interrupted (I have a serial console), >> but the only usable thing after that seems to be "call cpu_reset()", >> followed by full (and sometimes painfully long) filesystem check. >> >> Here are the diffs against the default GENERIC and PAE kernel >> configurations: >> >> < cpu I486_CPU >> < ident GENERIC >> < options INET6 # IPv6 communications protocols >> < options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI >> >> > options QUOTA >> > options SMP # Symmetric MultiProcessor Kernel >> > options BREAK_TO_DEBUGGER >> > options DDB >> > options KDB >> > options KDB_UNATTENDED >> >> > options IPFIREWALL >> > options DUMMYNET >> >> I'm attaching the dmesg.boot following the latest crash. >> >> Regards, >> Atanas >> >> >> >> Copyright (c) 1992-2006 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 6.2-PRERELEASE #0: Mon Nov 13 17:47:40 PST 2006 >> root@xyz:/var/obj/usr/src/sys/XYZ-PAE >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Dual Core AMD Opteron(tm) Processor 270 (2009.27-MHz 686-class CPU) >> Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 >> >> Features=0x178bfbff >> >> Features2=0x1 >> AMD Features=0xe2500800 >> AMD Features2=0x3 >> Cores per package: 2 >> real memory = 5368709120 (5120 MB) >> avail memory = 4182241280 (3988 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 2 >> cpu3 (AP): APIC ID: 3 >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 24-27 on motherboard >> ioapic2 irqs 28-31 on motherboard >> kbd1 at kbdmux0 >> acpi0: on motherboard >> acpi0: Power Button (fixed) >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 >> cpu0: on acpi0 >> cpu1: on acpi0 >> cpu2: on acpi0 >> cpu3: on acpi0 >> acpi_button0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pci0: at device 0.0 (no driver attached) >> isab0: at device 1.0 on pci0 >> isa0: on isab0 >> pci0: at device 1.1 (no driver attached) >> pci0: at device 2.0 (no driver attached) >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 >> ata0: on atapci0 >> ata1: on atapci0 >> pcib1: at device 9.0 on pci0 >> pci1: on pcib1 >> pci1: at device 6.0 (no driver attached) >> fxp0: port 0x2400-0x243f mem >> 0xda101000-0xda101fff,0xda120000-0xda13ffff irq 16 at device 8.0 on pci1 >> miibus0: on fxp0 >> inphy0: on miibus0 >> inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> fxp0: Ethernet address: 00:e0:81:33:b5:f1 >> pcib2: at device 13.0 on pci0 >> pci2: on pcib2 >> pcib3: at device 14.0 on pci0 >> pci3: on pcib3 >> pcib4: port 0xcf8-0xcff on acpi0 >> pci24: on pcib4 >> pcib5: at device 10.0 on pci24 >> pci25: on pcib5 >> 3ware device driver for 9000 series storage controllers, version: >> 3.60.02.012 >> twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem >> 0xde000000-0xdfffffff,0xdc300000-0xdc300fff irq 27 at device 3.0 on pci25 >> twa0: [FAST] >> twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-8LP, 8 >> ports, Firmware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002 >> pci24: at device 10.1 (no >> driver attached) >> pcib6: at device 11.0 on pci24 >> pci26: on pcib6 >> bge0: mem >> 0xdc410000-0xdc41ffff,0xdc400000-0xdc40ffff irq 28 at device 9.0 on pci26 >> miibus1: on bge0 >> brgphy0: on miibus1 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, >> 1000baseTX-FDX, auto >> bge0: Ethernet address: 00:e0:81:33:b6:f4 >> bge1: mem >> 0xdc430000-0xdc43ffff,0xdc420000-0xdc42ffff irq 29 at device 9.1 on pci26 >> miibus2: on bge1 >> brgphy1: on miibus2 >> brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, >> 1000baseTX-FDX, auto >> bge1: Ethernet address: 00:e0:81:33:b6:f5 >> pci24: at device 11.1 (no >> driver attached) >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 >> on acpi0 >> sio0: type 16550A, console >> fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on >> acpi0 >> fdc0: [FAST] >> fd0: <1440-KB 3.5" drive> on fdc0 drive 0 >> pmtimer0 on isa0 >> orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff on isa0 >> ppc0: parallel port not found. >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> sio1: configured irq 3 not in bitmap of probed irqs 0 >> sio1: port may not be enabled >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> Timecounters tick every 1.000 msec >> ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding >> disabled, default to deny, logging disabled >> da0 at twa0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-3 device >> da0: 100.000MB/s transfers >> da0: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) >> da1 at twa0 bus 0 target 1 lun 0 >> da1: Fixed Direct Access SCSI-3 device >> da1: 100.000MB/s transfers >> da1: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) >> da2 at twa0 bus 0 target 2 lun 0 >> da2: Fixed Direct Access SCSI-3 device >> da2: 100.000MB/s transfers >> da2: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) >> da3 at twa0 bus 0 target 3 lun 0 >> da3: Fixed Direct Access SCSI-3 device >> da3: 100.000MB/s transfers >> da3: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) >> da4 at twa0 bus 0 target 4 lun 0 >> da4: Fixed Direct Access SCSI-3 device >> da4: 100.000MB/s transfers >> da4: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) >> da5 at twa0 bus 0 target 5 lun 0 >> da5: Fixed Direct Access SCSI-3 device >> da5: 100.000MB/s transfers >> da5: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) >> da6 at twa0 bus 0 target 6 lun 0 >> da6: Fixed Direct Access SCSI-3 device >> da6: 100.000MB/s transfers >> da6: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) >> da7 at twa0 bus 0 target 7 lun 0 >> da7: Fixed Direct Access SCSI-3 device >> da7: 100.000MB/s transfers >> da7: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) >> SMP: AP CPU #1 Launched! >> SMP: AP CPU #2 Launched! >> SMP: AP CPU #3 Launched! >> Trying to mount root from ufs:/dev/da0s1a >> WARNING: / was not properly dismounted >> /: mount pending error: blocks 208 files 5 >> >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 20:53:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19A0A16A5CF for ; Tue, 14 Nov 2006 20:53:35 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from slimak.dkm.cz (slimak.dkm.cz [62.24.64.34]) by mx1.FreeBSD.org (Postfix) with SMTP id 97FE843E78 for ; Tue, 14 Nov 2006 20:50:53 +0000 (GMT) (envelope-from 000.fbsd@quip.cz) Received: (qmail 95625 invoked by uid 0); 14 Nov 2006 20:50:50 -0000 Received: from grimm.quip.cz (HELO ?192.168.1.2?) (213.220.192.218) by slimak.dkm.cz with SMTP; 14 Nov 2006 20:50:50 -0000 Message-ID: <455A2C21.9020304@quip.cz> Date: Tue, 14 Nov 2006 21:50:41 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: hartzell@alerce.com References: <17754.8258.37357.575054@satchel.alerce.com> In-Reply-To: <17754.8258.37357.575054@satchel.alerce.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: help identifying gmirror, ata, or motherboard problem (Tyan S2865G2NR) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 20:53:35 -0000 George Hartzell wrote: > I'm having a problem with a machine that I support and would like some > feedback. > > The system was built up from a barebones Transport PX22, which uses a > Tyan S2865G2NR motherboard. > > It has two drives: > > ad4: 286188MB at ata2-master SATA300 > ad6: 286188MB at ata3-master SATA300 > > A while back I noticed in the daily periodic report that gmirror had > dropped ad4. We rebooted and got things going again and it ran > smoothly for a month or so, then dropped it again. > > At that point we did a warranty replacement of ad4 and things have > been running smoothly for a couple of months. > > A few days ago gmirror kicked ad6 out of the raid, which the following > lines in dmesg: > > ad6: FAILURE - device detached > subdisk6: detached > ad6: detached > GEOM_MIRROR: Device gm0s1: provider ad6s1 disconnected. > > We're adding an external device into the mirror and are planning to do > a warranty swap on this drive too. > > The system is running, but feels sluggish. It might be interesting to > note that the disk activity light is continuously lit. > > The system if running the stock 6.1 RELEASE. > > FreeBSD foo.com 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:15:57 UTC 2006 root@bloom.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP amd64 > > I'm trying to figure out if we've just gotten two lousy disks, or if > there might be a driver or motherboard issue. > > Does any of this ring any bells? > > I'm suggesting that we upgrade to the tip of the stable tree, but the > owner's not convinced. I can't tell if there's been anything relevant > in the stable release that might address this (aside from all the > other great stuff that's in there). > > Thanks for any input, Hi, I had same problem few month ago and it was motherboard problem in my case. (the whole batch of ASUS barebones problem more precisely) Problem appeared with Seagate disks more often than with Hitec or Samsung, so my first thoughts was "it must be bad hard drive or batch of hard drives", but after many replacements and drives from other manufacturer I start to guess "it must be driver problem"... after next month of testing I found same problems on this batch of barebones with Linux and same barebones from different batch were running Linux for a long time... "say good bye Asus". I can't be 100% sure this is your case too, but I think so. Miroslav Lachman PS: you can check the drive status by smartctl (/usr/ports/sysutils/smartmontools) or by some utility from drive manufacturer before you do warranty return From owner-freebsd-stable@FreeBSD.ORG Tue Nov 14 22:30:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42C6B16A4C2 for ; Tue, 14 Nov 2006 22:30:25 +0000 (UTC) (envelope-from mark@dmglobal.net) Received: from ic.ucsb.edu (ic.ucsb.edu [128.111.151.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE9B243D5C for ; Tue, 14 Nov 2006 22:30:17 +0000 (GMT) (envelope-from mark@dmglobal.net) Received: from nat-cluster.ic.ucsb.edu ([128.111.151.1] helo=[10.1.1.182]) by ic.ucsb.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Gk5g4-000290-OX; Tue, 14 Nov 2006 13:18:45 -0800 Message-ID: <455A32B7.9080304@dmglobal.net> Date: Tue, 14 Nov 2006 13:18:47 -0800 From: Mark Dotson User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Atanas References: <455A1DEA.20304@asd.aplus.net> In-Reply-To: <455A1DEA.20304@asd.aplus.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: (ic.ucsb.edu) Sophos AV found no viruses in this message Cc: freebsd-stable@freebsd.org Subject: Re: twa: Passthru request timed out! Resetting controller... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 22:30:25 -0000 I've had continued problems with the 3ware series SATA cards and the Tyan boards. Specifically, I have a "Tyan S5360-1U" and both a 9500S-4LP and a 8506 series 3ware cards. In my case the first error is different, but the 'resetting' over and over is VERY familiar. This could be triggered by a simple file copy from one part of a container to another; degrading the unit and triggering the resetting crap. Note that the drives are fine, I tested that first thing. Sep 8 11:59:23 localhost kernel: 3w-9xxx: scsi0: WARNING: (0x06:0x002C): Unit #1: Command (0x2a) timed out, resetting card. Sep 8 11:59:41 localhost kernel: 3w-9xxx: scsi0: AEN: INFO (0x04:0x005E): Cache synchronized after power fail:unit=0. Sep 8 11:59:41 localhost kernel: 3w-9xxx: scsi0: AEN: INFO (0x04:0x005E): Cache synchronized after power fail:unit=1. I also found this problem to exist across platforms, not just FreeBSD. For example, the excerpt above is from a CentOS box. All tests were done with newest firmware for both card and mobo, and using the newest drivers provided by 3ware. Once I removed the card and drives from the Tyan system and stuck them in pretty much ANY other system, they worked fantastically. I don't have an answer for the "resetting problem" as of yet... 3ware and Tyan (And my system vendor "Appro") are still trying to find my specific problem and solve it. I believe they are currently doing the "replace everything" method of troubleshooting. -Mark Atanas wrote: > Has anyone experiencing this: > > twa0: ERROR: (0x05: 0x2018): Passthru request timed out!: request = > 0xca839d20 > twa0: INFO: (0x16: 0x1108): Resetting controller...: > twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=0 > ... > twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=7 > twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=1 > twa0: INFO: (0x16: 0x1107): Controller reset done!: > > This happens on 6.2-PRERELEASE i386 (and on 6.1 since its release) on a > number of machines with the following hardware configuration: > > - Tyan K8SE 2892, 2 AMD Opteron 270 CPUs, 4GB RAM > - 3ware 9550SX-8LP, 8 500GB Seagate ST3500641AS SATA drives > (configured as 8 SINGLE DISK units, aka JBOD) > > All hardware components, including the server chassis, are listed in the > 3ware hardware compatibility lists. It doesn't seem to be a cabling or > power issue. The controller and hard drives are already flashed to the > latest firmware revisions. I tried turning off NCQ, but it didn't make > any difference. I tried also switching the kernel from PAE to non-PAE > (reducing the usable memory to 3GB), but it didn't help either. > > I have another machines with similar I/O configurations (3ware), but > with Intel motherboards and running FreeBSD-5.5, and these run fine for > about a year already. Now I'm thinking about swapping the drives between > a working Intel and AMD based box, to see where controller timeouts will > follow. > > The problem happens sporadically once in a month or so and is very hard > to reproduce. Sometimes it takes several weeks until the next crash > happens, sometimes it crashes again in just a few hours. > > When the thing happens, the kernel sometimes panics (most likely due to > the inconsistent filesystem state caused by the controller reset), > sometimes just hangs. It can be interrupted (I have a serial console), > but the only usable thing after that seems to be "call cpu_reset()", > followed by full (and sometimes painfully long) filesystem check. > > Here are the diffs against the default GENERIC and PAE kernel > configurations: > > < cpu I486_CPU > < ident GENERIC > < options INET6 # IPv6 communications protocols > < options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI > > > options QUOTA > > options SMP # Symmetric MultiProcessor Kernel > > options BREAK_TO_DEBUGGER > > options DDB > > options KDB > > options KDB_UNATTENDED > > > options IPFIREWALL > > options DUMMYNET > > I'm attaching the dmesg.boot following the latest crash. > > Regards, > Atanas > > > ------------------------------------------------------------------------ > > Copyright (c) 1992-2006 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 6.2-PRERELEASE #0: Mon Nov 13 17:47:40 PST 2006 > root@xyz:/var/obj/usr/src/sys/XYZ-PAE > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Dual Core AMD Opteron(tm) Processor 270 (2009.27-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 > Features=0x178bfbff > Features2=0x1 > AMD Features=0xe2500800 > AMD Features2=0x3 > Cores per package: 2 > real memory = 5368709120 (5120 MB) > avail memory = 4182241280 (3988 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-27 on motherboard > ioapic2 irqs 28-31 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > isab0: at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > pci0: at device 2.0 (no driver attached) > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1400-0x140f at device 6.0 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pcib1: at device 9.0 on pci0 > pci1: on pcib1 > pci1: at device 6.0 (no driver attached) > fxp0: port 0x2400-0x243f mem 0xda101000-0xda101fff,0xda120000-0xda13ffff irq 16 at device 8.0 on pci1 > miibus0: on fxp0 > inphy0: on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:e0:81:33:b5:f1 > pcib2: at device 13.0 on pci0 > pci2: on pcib2 > pcib3: at device 14.0 on pci0 > pci3: on pcib3 > pcib4: port 0xcf8-0xcff on acpi0 > pci24: on pcib4 > pcib5: at device 10.0 on pci24 > pci25: on pcib5 > 3ware device driver for 9000 series storage controllers, version: 3.60.02.012 > twa0: <3ware 9000 series Storage Controller> port 0x3000-0x303f mem 0xde000000-0xdfffffff,0xdc300000-0xdc300fff irq 27 at device 3.0 on pci25 > twa0: [FAST] > twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-8LP, 8 ports, Firmware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002 > pci24: at device 10.1 (no driver attached) > pcib6: at device 11.0 on pci24 > pci26: on pcib6 > bge0: mem 0xdc410000-0xdc41ffff,0xdc400000-0xdc40ffff irq 28 at device 9.0 on pci26 > miibus1: on bge0 > brgphy0: on miibus1 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto > bge0: Ethernet address: 00:e0:81:33:b6:f4 > bge1: mem 0xdc430000-0xdc43ffff,0xdc420000-0xdc42ffff irq 29 at device 9.1 on pci26 > miibus2: on bge1 > brgphy1: on miibus2 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto > bge1: Ethernet address: 00:e0:81:33:b6:f5 > pci24: at device 11.1 (no driver attached) > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A, console > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff on isa0 > ppc0: parallel port not found. > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled > da0 at twa0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 100.000MB/s transfers > da0: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da1 at twa0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 100.000MB/s transfers > da1: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da2 at twa0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI-3 device > da2: 100.000MB/s transfers > da2: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da3 at twa0 bus 0 target 3 lun 0 > da3: Fixed Direct Access SCSI-3 device > da3: 100.000MB/s transfers > da3: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da4 at twa0 bus 0 target 4 lun 0 > da4: Fixed Direct Access SCSI-3 device > da4: 100.000MB/s transfers > da4: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da5 at twa0 bus 0 target 5 lun 0 > da5: Fixed Direct Access SCSI-3 device > da5: 100.000MB/s transfers > da5: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da6 at twa0 bus 0 target 6 lun 0 > da6: Fixed Direct Access SCSI-3 device > da6: 100.000MB/s transfers > da6: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > da7 at twa0 bus 0 target 7 lun 0 > da7: Fixed Direct Access SCSI-3 device > da7: 100.000MB/s transfers > da7: 476827MB (976541696 512 byte sectors: 255H 63S/T 60786C) > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #3 Launched! > Trying to mount root from ufs:/dev/da0s1a > WARNING: / was not properly dismounted > /: mount pending error: blocks 208 files 5 > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 00:52:52 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7534816A403 for ; Wed, 15 Nov 2006 00:52:52 +0000 (UTC) (envelope-from bsdhelp@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1EC543D53 for ; Wed, 15 Nov 2006 00:52:51 +0000 (GMT) (envelope-from bsdhelp@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so96955nfc for ; Tue, 14 Nov 2006 16:52:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=VnO44P9ayGFT+/vaakCueBEtaFfzWLtvLrhrzpj61KA4QMyvzRS3lvbgOIadgYBEaFQ4pWS1yIaeVLnvAMOyRYmC2wTcPa31NdeuvQ5PrUIHu1P7CUl5kA+bFHw65vum7LjLi2+MO4xd4wwMXIbZiHN/uXYAwAnSnZrLzT7tMNk= Received: by 10.82.142.9 with SMTP id p9mr220935bud.1163551970138; Tue, 14 Nov 2006 16:52:50 -0800 (PST) Received: by 10.82.166.15 with HTTP; Tue, 14 Nov 2006 16:52:50 -0800 (PST) Message-ID: <474548e50611141652k66d5cb1ejca87ca1d78266ba5@mail.gmail.com> Date: Tue, 14 Nov 2006 19:52:50 -0500 From: Joe To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: SSE support in 6.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 00:52:52 -0000 Trying to get steam working properly on 6.1. Cant seem to comfirm/enable the SSE support. Tried the CPU_ENABLE_SSE option, but its "unknown". How do I enable this into my kernel? uname -a = FreeBSD ### 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 ###:/usr/obj/usr/src/sys/SMP i386 -- Regards Joe -- Regards Joe From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 01:19:34 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C2F816A416 for ; Wed, 15 Nov 2006 01:19:34 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAFCB43D46 for ; Wed, 15 Nov 2006 01:19:33 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([85.236.96.60]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50003213422.msg for ; Wed, 15 Nov 2006 01:18:30 +0000 Message-ID: <014601c70853$f2f32fc0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Joe" , References: <474548e50611141652k66d5cb1ejca87ca1d78266ba5@mail.gmail.com> Date: Wed, 15 Nov 2006 01:18:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Processed: multiplay.co.uk, Wed, 15 Nov 2006 01:18:30 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 85.236.96.60 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org X-MDAV-Processed: multiplay.co.uk, Wed, 15 Nov 2006 01:18:31 +0000 Cc: Subject: Re: SSE support in 6.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 01:19:34 -0000 Joe wrote: > Trying to get steam working properly on 6.1. > > Cant seem to comfirm/enable the SSE support. Tried the CPU_ENABLE_SSE > option, but its "unknown". > > How do I enable this into my kernel? > > uname -a = FreeBSD ### 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 > 04:42:56 UTC 2006 ###:/usr/obj/usr/src/sys/SMP i386 Enabled by default on supported processors no need for special options anymore. 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 postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 01:42:11 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A42CC16A4A0 for ; Wed, 15 Nov 2006 01:42:11 +0000 (UTC) (envelope-from bsdhelp@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8434343D64 for ; Wed, 15 Nov 2006 01:42:05 +0000 (GMT) (envelope-from bsdhelp@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so108285nfc for ; Tue, 14 Nov 2006 17:42:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=d/UbLDHeJG7uAIGEBcY6SyfL4zhVXtZclK8XuWJ+48ehs3A8jzaq9g6x3M35WIbAE2vQe92ml9co/sQ02DTF96M6v+GKYxTf0K8RnJ2FWlc6QF4mH9GmUXXokkePoq4TIP89Q4C9DuxXTpVLVB3cCzzLyKwmJrpsCLjGko91w3A= Received: by 10.82.142.9 with SMTP id p9mr225743bud.1163554924018; Tue, 14 Nov 2006 17:42:04 -0800 (PST) Received: by 10.82.166.15 with HTTP; Tue, 14 Nov 2006 17:42:03 -0800 (PST) Message-ID: <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> Date: Tue, 14 Nov 2006 20:42:03 -0500 From: Joe To: "Steven Hartland" , freebsd-stable@freebsd.org In-Reply-To: <014601c70853$f2f32fc0$b3db87d4@multiplay.co.uk> MIME-Version: 1.0 References: <474548e50611141652k66d5cb1ejca87ca1d78266ba5@mail.gmail.com> <014601c70853$f2f32fc0$b3db87d4@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: SSE support in 6.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 01:42:11 -0000 is there some way to test to make sure its working properly. the guys from steam say that its not enabled and thats why my steam server wont start. so if i could prove that SSE is enabled and working i could send it to them. On 11/14/06, Steven Hartland wrote: > > Joe wrote: > > Trying to get steam working properly on 6.1. > > > > Cant seem to comfirm/enable the SSE support. Tried the CPU_ENABLE_SSE > > option, but its "unknown". > > > > How do I enable this into my kernel? > > > > uname -a = FreeBSD ### 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 > > 04:42:56 UTC 2006 ###:/usr/obj/usr/src/sys/SMP i386 > > Enabled by default on supported processors no need for special options > anymore. > > 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 postmaster@multiplay.co.uk. > > -- Regards Joe From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 01:57:01 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60BF116A403 for ; Wed, 15 Nov 2006 01:57:01 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25CED43D45 for ; Wed, 15 Nov 2006 01:57:01 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id EA2551A3C19; Tue, 14 Nov 2006 17:56:58 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A750551341; Tue, 14 Nov 2006 20:56:47 -0500 (EST) Date: Tue, 14 Nov 2006 20:56:47 -0500 From: Kris Kennaway To: Joe Message-ID: <20061115015647.GA95099@xor.obsecurity.org> References: <474548e50611141652k66d5cb1ejca87ca1d78266ba5@mail.gmail.com> <014601c70853$f2f32fc0$b3db87d4@multiplay.co.uk> <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, Steven Hartland Subject: Re: SSE support in 6.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 01:57:01 -0000 On Tue, Nov 14, 2006 at 08:42:03PM -0500, Joe wrote: > is there some way to test to make sure its working properly. the guys from > steam say that its not enabled and thats why my steam server wont start. so > if i could prove that SSE is enabled and working i could send it to them. Check whether your CPU really does support it, by reviewing the CPU features listed at boot (check dmesg or /var/log/messages) Kris From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 01:59:21 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B1CF16A4C9 for ; Wed, 15 Nov 2006 01:59:21 +0000 (UTC) (envelope-from sniimi@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FB3143D70 for ; Wed, 15 Nov 2006 01:59:19 +0000 (GMT) (envelope-from sniimi@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so31572wxc for ; Tue, 14 Nov 2006 17:59:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=BjuUm68pYTOFInrXbc0hNJZ+xvAujiapPpiWf8TP5kj3K1EFm6yBx+TRIspkzvpRt4LVL2Wzk+DJK3NKAHXEEc1VdY0YJ+nStQOt5vaQnHRENqwttOeancfJE/+6DuqtZTN6yk5m/ULgzb9bIuER4OcbnVF2Qr8zTQifFdN3fO0= Received: by 10.90.115.4 with SMTP id n4mr1850625agc.1163555958538; Tue, 14 Nov 2006 17:59:18 -0800 (PST) Received: by 10.90.95.7 with HTTP; Tue, 14 Nov 2006 17:59:18 -0800 (PST) Message-ID: <7a2b18c80611141759o8de57bgb22738fd556c4c4a@mail.gmail.com> Date: Wed, 15 Nov 2006 10:59:18 +0900 From: "NIIMI Satoshi" Sender: sniimi@gmail.com To: Joe In-Reply-To: <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <474548e50611141652k66d5cb1ejca87ca1d78266ba5@mail.gmail.com> <014601c70853$f2f32fc0$b3db87d4@multiplay.co.uk> <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> X-Google-Sender-Auth: b7287db419d0cb87 Cc: freebsd-stable@freebsd.org, Steven Hartland Subject: Re: SSE support in 6.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 01:59:21 -0000 2006/11/15, Joe : > is there some way to test to make sure its working properly. the guys from > steam say that its not enabled and thats why my steam server wont start. so > if i could prove that SSE is enabled and working i could send it to them. Try to check "hw.instruction_sse" sysctl MIB. | % sysctl hw.instruction_sse | hw.instruction_sse: 1 Thanks, -- NIIMI Satoshi From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 02:00:16 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4923616A40F for ; Wed, 15 Nov 2006 02:00:16 +0000 (UTC) (envelope-from bsdhelp@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93EC543D45 for ; Wed, 15 Nov 2006 02:00:15 +0000 (GMT) (envelope-from bsdhelp@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so112508nfc for ; Tue, 14 Nov 2006 18:00:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=R7EHydrVPiu0GssBwMGinhxLoTPmxCYMU00xLnanW6iaBKOjy2mpLkWXUsrr91Z6nIqwBO7pZJOYJ+lSR+0+vRh6l4rXJCE2vk3bXvWvDlEG4gR3T8cgUlElWPPvHLqfQclU9L8MWefz97VIXFBKzpktq9hXJj5/LmctqEe99pE= Received: by 10.82.175.2 with SMTP id x2mr80822bue.1163556013722; Tue, 14 Nov 2006 18:00:13 -0800 (PST) Received: by 10.82.166.15 with HTTP; Tue, 14 Nov 2006 18:00:13 -0800 (PST) Message-ID: <474548e50611141800s68a7feb6le69d236678c0d6b7@mail.gmail.com> Date: Tue, 14 Nov 2006 21:00:13 -0500 From: Joe To: freebsd-stable@freebsd.org In-Reply-To: <474548e50611141759n7d0845c1rb2ecf1b3964d7dc@mail.gmail.com> MIME-Version: 1.0 References: <474548e50611141652k66d5cb1ejca87ca1d78266ba5@mail.gmail.com> <014601c70853$f2f32fc0$b3db87d4@multiplay.co.uk> <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> <20061115015647.GA95099@xor.obsecurity.org> <474548e50611141759n7d0845c1rb2ecf1b3964d7dc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: SSE support in 6.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 02:00:16 -0000 ---------- Forwarded message ---------- From: Joe Date: Nov 14, 2006 8:59 PM Subject: Re: SSE support in 6.1? To: Kris Kennaway CPU: AMD Athlon(tm) processor (1000.04-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440800,MMX+,3DNow+,3DNow> looks like thats a negative On 11/14/06, Kris Kennaway < kris@obsecurity.org> wrote: > > On Tue, Nov 14, 2006 at 08:42:03PM -0500, Joe wrote: > > is there some way to test to make sure its working properly. the guys > from > > steam say that its not enabled and thats why my steam server wont start. > so > > if i could prove that SSE is enabled and working i could send it to > them. > > Check whether your CPU really does support it, by reviewing the CPU > features listed at boot (check dmesg or /var/log/messages) > > Kris > > > -- Regards Joe -- Regards Joe From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 02:11:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAEEF16A4D2 for ; Wed, 15 Nov 2006 02:11:56 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 864A543D67 for ; Wed, 15 Nov 2006 02:11:42 +0000 (GMT) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id kAF2BbLr000924; Wed, 15 Nov 2006 03:11:37 +0100 From: Pieter de Goeje To: Joe Date: Wed, 15 Nov 2006 03:11:37 +0100 User-Agent: KMail/1.9.4 References: <474548e50611141652k66d5cb1ejca87ca1d78266ba5@mail.gmail.com> <014601c70853$f2f32fc0$b3db87d4@multiplay.co.uk> <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> In-Reply-To: <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611150311.37139.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: SSE support in 6.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 02:11:57 -0000 On Wednesday 15 November 2006 02:42, Joe wrote: > is there some way to test to make sure its working properly. the guys from > steam say that its not enabled and thats why my steam server wont start. so > if i could prove that SSE is enabled and working i could send it to them. Im guessing you're referring to Half-Life, Source etc servers. I've successfully run them on FreeBSD in the past (and still do). Could you be more specific? Error message, type of server... Regards, Pieter de Goeje From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 04:10:17 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38E2D16A412; Wed, 15 Nov 2006 04:10:17 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id C00C843D45; Wed, 15 Nov 2006 04:10:16 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.220]) by hub.org (Postfix) with ESMTP id DEF1311A18D; Wed, 15 Nov 2006 00:10:15 -0400 (AST) Received: from hub.org ([200.46.204.220]) by localhost (mx1.hub.org [200.46.204.60]) (amavisd-new, port 10024) with ESMTP id 43192-08; Wed, 15 Nov 2006 00:10:15 -0400 (AST) Received: from ganymede.hub.org (blk-137-79-174.eastlink.ca [24.137.79.174]) by hub.org (Postfix) with ESMTP id 8726911A175; Wed, 15 Nov 2006 00:10:15 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id BA97F37B3D; Wed, 15 Nov 2006 00:10:14 -0400 (AST) Date: Wed, 15 Nov 2006 00:10:14 -0400 From: "Marc G. Fournier" To: Ruslan Ermilov , Olivier Mueller Message-ID: <9E6F0D394F37BCE038812891@ganymede.hub.org> In-Reply-To: <20061113223904.GB84153@rambler-co.ru> References: <1163442609.10865.59.camel@bigapple.omnis.ch> <20061113191454.GB66013@rambler-co.ru> <1163455070.14157.9.camel@bigapple.omnis.ch> <20061113223904.GB84153@rambler-co.ru> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-stable@freebsd.org Subject: Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 04:10:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, November 14, 2006 01:39:04 +0300 Ruslan Ermilov wrote: > On Mon, Nov 13, 2006 at 10:57:50PM +0100, Olivier Mueller wrote: >> On Mon, 2006-11-13 at 22:14 +0300, Ruslan Ermilov wrote: >> > > Btw, when will we see these new servers listed under: >> > > http://www.freebsd.org/platforms/amd64/motherboards.html ? >> > > >> > And you absolutely have no option of running FreeBSD/amd64 on >> > them? What a PITA! :-) >> >> Ehm well, I must admit I never tried that, for a simple (and silly?) >> reason: freebsd installation selects the i386 SMP kernel by default... >> > Because you're trying to install FreeBSD/i386 on it; download > and burn the FreeBSD/amd64 ISOs instead -- it will select an > amd64 SMP kernel then. I got indirectly burnt by this one myself (had a tech do a remote install, didn't think to tell him to download the amd64 version ... wasn't a big deal, we just re-installed, but ..) ... is there no way of having the installer detect that a system *is* amd64 capable and having it issue a warning? - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFWpMm4QvfyHIvDvMRApVgAJ0ae2Rilu46AgHsV2AXCAiJQfct1ACbBKXg HdQHsVtBAn0BECECMbanuGw= =iKLS -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 06:29:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C40CB16A47B; Wed, 15 Nov 2006 06:29:56 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id F038343D49; Wed, 15 Nov 2006 06:29:38 +0000 (GMT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with SMTP id RAA20325; Wed, 15 Nov 2006 17:29:12 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 15 Nov 2006 17:29:11 +1100 (EST) From: Ian Smith To: Jeremy Chadwick In-Reply-To: <20061114185152.GA43923@icarus.home.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pj@smo.de, freebsd-stable@freebsd.org Subject: Re: Problems with man and less/more X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 06:29:56 -0000 On Tue, 14 Nov 2006, Jeremy Chadwick wrote: > On Tue, Nov 14, 2006 at 07:03:24PM +0100, Oliver Fromme wrote: > > Just set $PAGER appropriately. By the way, the default > > (if not set) is "more -s", which is the same as "less -s". > > Therefore, piping output from man(1) through less(1) > > doesn't really make sense. > > Maybe this should be done by the default in /etc/profile and > /etc/csh.cshrc for people who don't override it? more and less don't behave quite the same though; I always set $PAGER to less explicitly in ~/.cshrc (albeit with some extra options) because as more, getting to the bottom of a file quits, where less requires 'q' to exit - handy if, say, running '!man something' from inside less .. Cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 10:07:03 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7557A16A40F for ; Wed, 15 Nov 2006 10:07:03 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 7572143D4C for ; Wed, 15 Nov 2006 10:06:43 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 15 Nov 2006 10:06:42 +0000 (GMT) Date: Wed, 15 Nov 2006 10:06:41 +0000 From: David Malone To: Joe Message-ID: <20061115100641.GA22391@walton.maths.tcd.ie> References: <474548e50611141652k66d5cb1ejca87ca1d78266ba5@mail.gmail.com> <014601c70853$f2f32fc0$b3db87d4@multiplay.co.uk> <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> <20061115015647.GA95099@xor.obsecurity.org> <474548e50611141759n7d0845c1rb2ecf1b3964d7dc@mail.gmail.com> <474548e50611141800s68a7feb6le69d236678c0d6b7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474548e50611141800s68a7feb6le69d236678c0d6b7@mail.gmail.com> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-stable@freebsd.org Subject: Re: Fwd: SSE support in 6.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 10:07:03 -0000 On Tue, Nov 14, 2006 at 09:00:13PM -0500, Joe wrote: > Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 > Features=0x183f9ff > AMD Features=0xc0440800,MMX+,3DNow+,3DNow> There is an option CPU_ATHLON_SSE_HACK which turns on SSE on Athlons which have SSE but where the BIOS has forgotten to turn it on. However, this Athlon looks too old - I think you need an Id of 0x660 or higher for this to work. David. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 10:14:22 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D2CB16A407 for ; Wed, 15 Nov 2006 10:14:22 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0582143D67 for ; Wed, 15 Nov 2006 10:14:20 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so231956nfc for ; Wed, 15 Nov 2006 02:14:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=R2/NFCZPOjKU/qOQNXRnTy4GgG/oagNEUpgwwsjR/7cgYNHxbhfPVnMB3+BYlI7NHY6NW1/ehmYlboydrNQrjUcUmERvDOSpt++O91cFfMrPJJ1wCd1l97IMmayY5ujOO4PH10nmxBYUx1K5DrGrzyYegWfiorD3zNyKFwPEQfc= Received: by 10.78.200.3 with SMTP id x3mr66257huf.1163585659362; Wed, 15 Nov 2006 02:14:19 -0800 (PST) Received: by 10.78.155.3 with HTTP; Wed, 15 Nov 2006 02:14:19 -0800 (PST) Message-ID: <7ad7ddd90611150214q1ff88220g5105ab513908eeb3@mail.gmail.com> Date: Wed, 15 Nov 2006 11:14:19 +0100 From: "Ulrich Spoerlein" To: stable@freebsd.org, kazakov@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: ntpd vs nss_ldap: Crashing in getaddrinfo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 10:14:22 -0000 Hi, I needed to test the ntpd from ports (net/ntp, net/ntp-devel, net/ntp-stable), but they always crashed with a SIGBUS error. Investigation lead to nss_ldap being the culprit. With nss_ldap installed and NO keyword "ldap" in /etc/nsswitch.conf, ntpd will run fine. If you either add "ldap" to passwd or group or both, ntpd will crash calling gethostaddr (even though LDAP is only used for passwd/group) /etc/nsswitch.conf: group: files ldap hosts: files dns networks: files passwd: files ldap shells: files root@build:/usr/ports/net/ntp-stable/work/ntp-4.2.2p4-RC4/ntpd# gdb ./ntpd 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"... (gdb) r -d Starting program: /usr/ports/net/ntp-stable/work/ntp-4.2.2p4-RC4/ntpd/ntpd -d ntpd 4.2.2p4-RC4@1.1585-o Wed Nov 15 09:56:13 UTC 2006 (1) addto_syslog: precision = 1.117 usec create_sockets(123) addto_syslog: no IPv6 interfaces found addto_syslog: ntp_io: estimated max descriptors: 10951, initial socket boundary: 20 bind() fd 20, family 2, port 123, addr 0.0.0.0, flags=9 Added addr 0.0.0.0 to list of addresses addto_syslog: Listening on interface wildcard, 0.0.0.0#123 Disabled bind() fd 21, family 2, port 123, addr 16.30.58.127, flags=25 Added addr 16.30.58.127 to list of addresses addto_syslog: Listening on interface xl0, 16.30.58.127#123 Enabled bind() fd 22, family 2, port 123, addr 127.0.0.1, flags=21 Added addr 127.0.0.1 to list of addresses addto_syslog: Listening on interface lo0, 127.0.0.1#123 Enabled init_io: maxactivefd 22 local_clock: time 0 base 0.000000 offset 0.000000 freq 0.000 state 0 Program received signal SIGBUS, Bus error. 0x280a98c8 in memset () from /libexec/ld-elf.so.1 (gdb) bt #0 0x280a98c8 in memset () from /libexec/ld-elf.so.1 #1 0x280c2100 in ?? () #2 0x2809f039 in map_object () from /libexec/ld-elf.so.1 #3 0x2809c115 in elf_hash () from /libexec/ld-elf.so.1 #4 0x2809c21c in elf_hash () from /libexec/ld-elf.so.1 #5 0x2809de8c in dlopen () from /libexec/ld-elf.so.1 #6 0x2828140c in _nsdbtaddsrc () from /lib/libc.so.6 #7 0x2827cb92 in ___toupper () from /lib/libc.so.6 #8 0x2827d1b4 in _nsyyparse () from /lib/libc.so.6 #9 0x2828179e in nsdispatch () from /lib/libc.so.6 #10 0x28271776 in getaddrinfo () from /lib/libc.so.6 #11 0x0804bfee in getnetnum (num=0xbfbfe537 "ntp0.XXXX.com", addr=0xbfbfe9d0, complain=0, a_type=t_UNK) at ntp_config.c:2222 #12 0x0804cb5f in getconfig (argc=2, argv=0xbfbfebcc) at ntp_config.c:652 #13 0x0805246e in ntpdmain (argc=2, argv=0xbfbfebcc) at ntpd.c:744 #14 0x080527bb in main (argc=2, argv=0xbfbfebcc) at ntpd.c:274 (gdb) f 11 #11 0x0804bfee in getnetnum (num=0xbfbfe537 "ntp0.XXXX.com", addr=0xbfbfe9d0, complain=0, a_type=t_UNK) at ntp_config.c:2222 2222 retval = getaddrinfo(num, "ntp", &hints, &ptr); (gdb) l 2217 hints.ai_socktype = SOCK_DGRAM; 2218 #ifdef DEBUG 2219 if (debug > 3) 2220 printf("getaddrinfo %s\n", num); 2221 #endif 2222 retval = getaddrinfo(num, "ntp", &hints, &ptr); 2223 if (retval != 0 || 2224 (ptr->ai_family == AF_INET6 && isc_net_probeipv6() != ISC_R_SUCCESS)) { 2225 if (complain) 2226 msyslog(LOG_ERR, (gdb) What's happening? Uli From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 10:37:35 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBD6416A412; Wed, 15 Nov 2006 10:37:35 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E05643D80; Wed, 15 Nov 2006 10:37:33 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (dqfmhm@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAFAbRW2088241; Wed, 15 Nov 2006 11:37:32 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAFAbQ6L088240; Wed, 15 Nov 2006 11:37:26 +0100 (CET) (envelope-from olli) Date: Wed, 15 Nov 2006 11:37:26 +0100 (CET) Message-Id: <200611151037.kAFAbQ6L088240@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, koitsu@FreeBSD.ORG, pj@smo.de, smithi@nimnet.asn.au In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 15 Nov 2006 11:37:32 +0100 (CET) Cc: Subject: Re: Problems with man and less/more X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, koitsu@FreeBSD.ORG, pj@smo.de, smithi@nimnet.asn.au List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 10:37:35 -0000 Ian Smith wrote: > Jeremy Chadwick wrote: > > Oliver Fromme wrote: > > > Just set $PAGER appropriately. By the way, the default > > > (if not set) is "more -s", which is the same as "less -s". > > > Therefore, piping output from man(1) through less(1) > > > doesn't really make sense. > > > > Maybe this should be done by the default in /etc/profile and > > /etc/csh.cshrc for people who don't override it? Those people will get the default behaviour already, so I don't think it's necessary to set $PAGER to anything. In fact, it might be confusing to do so. > more and less don't behave quite the same though; Right, less(1) enters a compatibility mode if called as "more". Sorry, I forgot about that because I have an alias more=less for ages. :-) > I always set $PAGER to > less explicitly in ~/.cshrc (albeit with some extra options) because as > more, getting to the bottom of a file quits, where less requires 'q' to > exit - handy if, say, running '!man something' from inside less .. Beside the alias more=less, I have the following environment variables set in my ~/.zshrc: LESSCHARSET=latin1 LESS=-Meiqa#8 PAGER=less Among other things, those options will make less(1) quit automatically when it hits the bottom of a file for the _second_ time in a row, which is very convenient, and it makes the prompt line more verbose (display file name, line numbers and percentage). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible." -- John William Chambless From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 10:57:45 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F372116A403 for ; Wed, 15 Nov 2006 10:57:44 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47DBA43D4C for ; Wed, 15 Nov 2006 10:57:44 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so94267uge for ; Wed, 15 Nov 2006 02:57:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ale+RDNO4REqYAIZHlo6xrQCtjjyGge9cDl/GR1mIXrdV7v7z/b45WGgj6FzFDLiBq1HW3Z8vsFMX0SJstsAE0U6Uye8PIXbXUb4DLjhp2SAkJAVQrA9CYad7z981F+jVTM37/MQ8LBNw3aJU3INWg6kRdbq5B7ASS8Dvf3PuTk= Received: by 10.78.166.7 with SMTP id o7mr264408hue.1163588262711; Wed, 15 Nov 2006 02:57:42 -0800 (PST) Received: by 10.78.155.3 with HTTP; Wed, 15 Nov 2006 02:57:42 -0800 (PST) Message-ID: <7ad7ddd90611150257w4e2a787dt3d644de2423bd4c9@mail.gmail.com> Date: Wed, 15 Nov 2006 11:57:42 +0100 From: "Ulrich Spoerlein" To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: dump(8): how many bytes written to tape? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 10:57:45 -0000 Hi, I'm trying to figure out how much bytes were written to a tape by dump(8). I'm using a blocksize of 64kB to maximize throughput to the tape drive. Initially, I thought I could just add up the number of "tape blocks" written by dump and multiply by 64kB. But it looks like dump is still reporting those values as 1kB blocks. Here's some sample output: DUMP: Date of this level 1 dump: Wed Nov 15 09:46:37 2006 DUMP: Date of last level 0 dump: the epoch DUMP: Cache 256 MB, blocksize = 65536 DUMP: DUMP: 30676 tape blocks on 1 volume DUMP: finished in 1 seconds, throughput 30676 KBytes/sec DUMP: Date of this level 1 dump: Wed Nov 15 10:25:38 2006 DUMP: Date of last level 0 dump: the epoch DUMP: DUMP: 4650864 tape blocks on 1 volume DUMP: finished in 132 seconds, throughput 35233 KBytes/sec DUMP: Date of this level 1 dump: Wed Nov 15 10:50:36 2006 DUMP: Date of last level 0 dump: the epoch DUMP: DUMP: 328548 tape blocks on 1 volume DUMP: finished in 14 seconds, throughput 23467 KBytes/sec DUMP: Date of this level 1 dump: Wed Nov 15 11:00:14 2006 DUMP: Date of last level 0 dump: the epoch DUMP: DUMP: 36925423 tape blocks on 1 volume DUMP: finished in 973 seconds, throughput 37950 KBytes/sec If I add the time*throughput, I get 41GB. If I add the number of tape blocks and assume a block size of 1kB, I get 41GB, too. So, how exactly is the '-b64' parameter to dump(8) affecting the block size on tape? Uli From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 11:45:15 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F315D16A40F for ; Wed, 15 Nov 2006 11:45:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FD0D43D67 for ; Wed, 15 Nov 2006 11:45:13 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (tytmli@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAFBj7qw091657; Wed, 15 Nov 2006 12:45:12 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAFBj7D0091656; Wed, 15 Nov 2006 12:45:07 +0100 (CET) (envelope-from olli) Date: Wed, 15 Nov 2006 12:45:07 +0100 (CET) Message-Id: <200611151145.kAFBj7D0091656@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, uspoerlein@gmail.com In-Reply-To: <7ad7ddd90611150257w4e2a787dt3d644de2423bd4c9@mail.gmail.com> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 15 Nov 2006 12:45:13 +0100 (CET) Cc: Subject: Re: dump(8): how many bytes written to tape? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, uspoerlein@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 11:45:15 -0000 Ulrich Spoerlein wrote: > I'm trying to figure out how much bytes were written to a tape by > dump(8). I'm using a blocksize of 64kB to maximize throughput to the > tape drive. Initially, I thought I could just add up the number of > "tape blocks" written by dump and multiply by 64kB. But it looks like > dump is still reporting those values as 1kB blocks. > [...] > So, how exactly is the '-b64' parameter to dump(8) affecting the block > size on tape? The -b option does _not_ change the blocksize of dump, which is hardcoded at 1024 bytes and cannot be changed. That means that the reported number of blocks is also always measured in units of 1024 bytes, no matter what your -b option says. Unfortunately the manual page is somewhat misleading. :-( Instead, the -b option changes the number of blocks per record, i.e. how many blocks are written at once per write operation. The default is 10 for standard tapes and 32 for high-density tapes (>= 6250 bpi). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "It combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript." -- Jamie Zawinski, when asked: "What's wrong with perl?" From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 12:52:48 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B876916A516; Wed, 15 Nov 2006 12:52:48 +0000 (UTC) (envelope-from TEvans@mintel.com) Received: from rocky.mintel.co.uk (rocky2.mintel.com [217.206.187.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDB9043DB8; Wed, 15 Nov 2006 12:51:50 +0000 (GMT) (envelope-from TEvans@mintel.com) Received: from notes03.mintel.co.uk (notes03.mintel.co.uk [10.0.11.9]) by rocky.mintel.co.uk (8.13.4/8.13.4) with SMTP id kAFCphhd065343; Wed, 15 Nov 2006 12:51:43 GMT (envelope-from TEvans@mintel.com) Received: by notes03.mintel.co.uk(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80257227.00468BD7 ; Wed, 15 Nov 2006 12:50:33 +0000 X-Lotus-FromDomain: MINTEL From: "Tom Evans" To: freebsd-stable@freebsd.org, koitsu@freebsd.org, pj@smo.de, smithi@nimnet.asn.au Message-ID: <80257227.00468BAD.00@notes03.mintel.co.uk> Date: Wed, 15 Nov 2006 12:51:31 +0000 Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Cc: owner-freebsd-stable@freebsd.org, pj@smo.de, koitsu@freebsd.org, freebsd-stable@freebsd.org, smithi@nimnet.asn.au Subject: Re: Problems with man and less/more X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 12:52:48 -0000 Not strictly on-topic, but I have become accustomed to reading my man pages in vim, beautifully colourised. This my alias/function for bash, rewrite according to taste: vman() { =A0 =A0 /usr/bin/man -w "$@" >/dev/null && /usr/bin/man "$@" | /usr/bin= /col -b | /usr/local/bin/vim -c 'set ft=3Dman nomod nolist noma' - } alias man=3D'vman' It is a bit wasteful, but it sure is purty. Cheers Tom = From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 13:04:10 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9155416A417 for ; Wed, 15 Nov 2006 13:04:10 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F9D043D62 for ; Wed, 15 Nov 2006 13:04:08 +0000 (GMT) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A5507.dip.t-dialin.net [84.154.85.7]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id kAFD45Rv061548; Wed, 15 Nov 2006 14:04:06 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id kAFD3x4f010015; Wed, 15 Nov 2006 14:03:59 +0100 (CET) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost [127.0.0.1]) by fire.jhs.private (8.13.6/8.13.6) with ESMTP id kAFD3x9A038653; Wed, 15 Nov 2006 14:03:59 +0100 (CET) (envelope-from jhs@fire.jhs.private) Message-Id: <200611151303.kAFD3x9A038653@fire.jhs.private> To: Oliver Fromme From: "Julian Stacey" Organization: http://berklix.com BSD Unix C Net Consultancy, Munich/Muenchen User-agent: EXMH http://beedub.com/exmh/ on FreeBSD http://freebsd.org X-URL: http://berklix.com X-Fallback: jhs@mail.brierdr.com, jhs@freebsd.org, jhs@berklix.net In-reply-to: Your message of "Tue, 14 Nov 2006 16:37:42 +0100." <200611141537.kAEFbgIT039373@lurza.secnetix.de> Date: Wed, 15 Nov 2006 14:03:59 +0100 Sender: jhs@flat.berklix.net Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Trouble: NFS via TCP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 13:04:10 -0000 Oliver Fromme wrote: > > Using a normal UDP mount I had eratic come & go problems with amd > > until I added to rc.conf > > nfs_server_flags="-u -t -n 10" > > Turns out I had too few. 10 fixed it. > > Thanks for the suggestion, but I don't think it applies > here. > > I'm using the default (-n 4), but this is the only mount > from localhost, so that should be sufficient. ^^^^^^^^^^^^^ Unless some other host mounts on to yours & occupies slots, maybe driven by a remote { amd or MS equivalent } (long shot, admitted). > Besides, > the same problem occurs when trying to mount from a NetApp > filer. MS ? I'm clueless :-) > Also, I don't have "erratic come & go problems", > but the mount(8) command simply hangs right from the start. Good, intermittents are harder to chase. I had a bad solder joint on a coax BNC once, intermittent, pings worked, some protocols broke, & had an electolytic die in a UTP hub power that similarly caused intermittents through low voltage. > I'm not using amd, if that matters (I don't think it does). Agreed. (Just mentioned it in case you were doing anything unusual, eg my hosts mount themselves occasionaly, to allow transparent host independence/ orthogonality of scripts). More a question if other host mounting yours. I recall X terminals can try unusual boot methods inc NFS, maybe other devices eg TCP printer spoolers to parallel converters too etc ? Maybe if you remove all but your 2 hosts on to a seperate net briefly for a test to see if some weird 3rd party problem ? (a bit like ripping spare cards out of a problematic PC). > Since I weren't able to track this problem down, I now tend > to think that it's a bug in the NIC (either broken hardware > or a bug in the bge(4) driver) that makes it break TCP NFS > packets somehow. I don't have any other explanation. I think you've already checked no ipfw in way either end (your old mail not to hand). Sometime my probs come down to eg: bad cmos battery on a cold standby gate I power up, timed masters off the spare gate, zaps internals, rdist of configs fails, named fails, NFS fails. All 'cos I turned a box on :-) Good luck. -- Julian Stacey. BSD Unix C Net Consultancy, Munich/Muenchen http://berklix.com Mail Ascii, not HTML. Ihr Rauch = mein allergischer Kopfschmerz. http://berklix.org/free-software From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 13:19:00 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8158C16A415 for ; Wed, 15 Nov 2006 13:19:00 +0000 (UTC) (envelope-from bsdhelp@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBE4D43D64 for ; Wed, 15 Nov 2006 13:18:59 +0000 (GMT) (envelope-from bsdhelp@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so276948nfc for ; Wed, 15 Nov 2006 05:18:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Vcx+Csal8gzSpXmykzWdHMoDV+7kOl0Dsd2XYLoYkd7qUQlRwF+J26TdTnfNpd9ch2/lOBZIK2W7Qpa4GACbz5WB+ztq4ZYX/jDgVfRKiefKUbiK/GEo2m/jW13CnscfMSQCW4RdbB04gX7rq7wq49ADRzTMehXwve/DhcPgEWY= Received: by 10.82.111.8 with SMTP id j8mr290214buc.1163596737798; Wed, 15 Nov 2006 05:18:57 -0800 (PST) Received: by 10.82.166.15 with HTTP; Wed, 15 Nov 2006 05:18:57 -0800 (PST) Message-ID: <474548e50611150518j7945c9f5g55b162c303f2e00d@mail.gmail.com> Date: Wed, 15 Nov 2006 08:18:57 -0500 From: Joe To: "David Malone" In-Reply-To: <20061115100641.GA22391@walton.maths.tcd.ie> MIME-Version: 1.0 References: <474548e50611141652k66d5cb1ejca87ca1d78266ba5@mail.gmail.com> <014601c70853$f2f32fc0$b3db87d4@multiplay.co.uk> <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> <20061115015647.GA95099@xor.obsecurity.org> <474548e50611141759n7d0845c1rb2ecf1b3964d7dc@mail.gmail.com> <474548e50611141800s68a7feb6le69d236678c0d6b7@mail.gmail.com> <20061115100641.GA22391@walton.maths.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Fwd: SSE support in 6.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 13:19:00 -0000 i'm currently attempting to emulate the appropriate cpu with qemu. i'll keep yall posted. On 11/15/06, David Malone wrote: > > On Tue, Nov 14, 2006 at 09:00:13PM -0500, Joe wrote: > > Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 > > > Features=0x183f9ff > > AMD Features=0xc0440800,MMX+,3DNow+,3DNow> > > There is an option CPU_ATHLON_SSE_HACK which turns on SSE on Athlons > which have SSE but where the BIOS has forgotten to turn it on. > However, this Athlon looks too old - I think you need an Id of 0x660 > or higher for this to work. > > David. > -- Regards Joe From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 13:32:03 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4C3116A412 for ; Wed, 15 Nov 2006 13:32:03 +0000 (UTC) (envelope-from pietro.cerutti@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2116A43D79 for ; Wed, 15 Nov 2006 13:32:00 +0000 (GMT) (envelope-from pietro.cerutti@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so124441uge for ; Wed, 15 Nov 2006 05:32:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Ckfaa4k6R0qzIb56Ko2PbnCvXFn/Raww8hJNFhew5YNJxNi4q/QCcYjPpIED+f/iU6WdIg/C0krzSNR7QAlQ4VdUa/mUy0z1MdKRHEyp6g5CufkRdGCCgJjzXNgab3scNM4Xygz/h705mSorYpd/7/s7IM6B/YiZzG8h/KIxHwc= Received: by 10.66.232.9 with SMTP id e9mr1723211ugh.1163597519513; Wed, 15 Nov 2006 05:31:59 -0800 (PST) Received: by 10.66.224.6 with HTTP; Wed, 15 Nov 2006 05:31:59 -0800 (PST) Message-ID: Date: Wed, 15 Nov 2006 14:31:59 +0100 From: "Pietro Cerutti" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: rc.subr modification: testing and feedback are welcome! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 13:32:03 -0000 Hello List, I did a patch to allow rc.conf DAEMON_enable values to be decided at startup. 1) set apache_start="ask" in rc.conf 2) at boot, you'll be prompted with "RC_ASK - Enable apache? [yes|no] " 3) the daemon is started depending on the decision 4) the decision is stored until the next boot, so that rc.shutdown can decide whether to call stop for a particular daemon or not See: http://www.freebsd.org/cgi/query-pr.cgi?pr=105568 for more information and to download the patch Thanx! -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 14:00:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5F0016A4E6 for ; Wed, 15 Nov 2006 14:00:53 +0000 (UTC) (envelope-from suhailc@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id E45C343DD5 for ; Wed, 15 Nov 2006 13:59:47 +0000 (GMT) (envelope-from suhailc@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so46733nzh for ; Wed, 15 Nov 2006 05:59:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=LwOJj/pyG5fJwx3steWBZR+lfNYBzry9igoc5sB/cLxly79JFyZnLhW3sqOf7uspSbpM7KvcpUdKK4Tdcg9OjGQ8DZZ6qiVtkZrKD4MqqoUexTQoh4hXaFf3w2wlkwp6OUPBHojlgmsaD1szS6MeiPcfimancoIOcSoBeSy/b9w= Received: by 10.35.50.1 with SMTP id c1mr3012964pyk.1163599178130; Wed, 15 Nov 2006 05:59:38 -0800 (PST) Received: by 10.35.121.6 with HTTP; Wed, 15 Nov 2006 05:59:38 -0800 (PST) Message-ID: Date: Wed, 15 Nov 2006 13:59:38 +0000 From: "Suhail Choudhury" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline Subject: Installing/Upgrading Ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 14:00:53 -0000 SGksCgpXaHkgdHJ5aW5nIHRvIGluc3RhbGwgcG9ydHMgdmlhICJzeXNpbnN0YWxsIC0+IGN1c3Rv bWlzZSAtPiBwb3J0cyIsCndoaWNoZXZlciBsb2NhdGlvbiBJIHRyeSwgSSBnZXQgdGhlIGZvbGxv d2luZyBtZXNzYWdlOgoKV2FybmluZzogIENhbid0IGZpbmQgdGhlIGA2LjEtUkVMRUFTRS1wMTAn IGRpc3RyaWJ1dGlvbiBvbiB0aGlzIIEgeCCBCiAgICAgICAgICCBIIEggSBGVFAgc2VydmVyLiAg WW91IG1heSBuZWVkIHRvIHZpc2l0IGEgZGlmZmVyZW50IHNlcnZlcgpmb3IgICAgICAggSB4IIEK ICAgICAgICAgIIEggSCBIHRoZSByZWxlYXNlIHlvdSBhcmUgdHJ5aW5nIHRvIGZldGNoIG9yIGdv IHRvIHRoZQpPcHRpb25zICAgICAgICCBIHgggQogICAgICAgICAggSCBIIEgbWVudSBhbmQgdG8g c2V0IHRoZSByZWxlYXNlIG5hbWUgdG8gZXhwbGljaXRseSBtYXRjaAp3aGF0J3MgICAgIIEgeCCB CiAgICAgICAgICCBIIEggSBhdmFpbGFibGUgb24gZnRwMS5mcmVlYnNkLm9yZyAob3Igc2V0IHRv ICJhbnkiKS4KICAgICAgICAggSB4IIEKICAgICAgICAgIIEggSCBCiAgICAgICAgIIEgeCCBCiAg ICAgICAgICCBIIEggSBXb3VsZCB5b3UgbGlrZSB0byBzZWxlY3QgYW5vdGhlciBGVFAgc2VydmVy PwoKSG93IGNhbiBJIGluc3RhbGwgdGhlIHBvcnRzIGRpcmVjdG9yeSBvbiA2LjEtUkVMRUFTRS1w MTA/Ci0tIAoKUmVnYXJkcywKU3VoYWlsLgo= From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 14:21:19 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 147B116A586 for ; Wed, 15 Nov 2006 14:21:19 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C7F943DF0 for ; Wed, 15 Nov 2006 14:12:42 +0000 (GMT) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id 63FFD5C57; Wed, 15 Nov 2006 09:21:51 -0500 (EST) Date: Wed, 15 Nov 2006 09:21:51 -0500 From: Wesley Shields To: Suhail Choudhury Message-ID: <20061115142151.GA62874@atarininja.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: Installing/Upgrading Ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 14:21:19 -0000 On Wed, Nov 15, 2006 at 01:59:38PM +0000, Suhail Choudhury wrote: > Hi, > > Why trying to install ports via "sysinstall -> customise -> ports", > whichever location I try, I get the following message: > > Warning: Can't find the `6.1-RELEASE-p10' distribution on this ? x ? > ? ? ? FTP server. You may need to visit a different server > for ? x ? > ? ? ? the release you are trying to fetch or go to the > Options ? x ? > ? ? ? menu and to set the release name to explicitly match > what's ? x ? > ? ? ? available on ftp1.freebsd.org (or set to "any"). > ? x ? > ? ? ? > ? x ? > ? ? ? Would you like to select another FTP server? > > How can I install the ports directory on 6.1-RELEASE-p10? > -- > > Regards, > Suhail. By using cvsup (use pkg_add(1) to install it), or portsnap which is in the base system. The entire process is well documented in the handbook. -- WXS From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 14:21:32 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 370B416A523 for ; Wed, 15 Nov 2006 14:21:32 +0000 (UTC) (envelope-from heli@mikestammer.com) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by mx1.FreeBSD.org (Postfix) with SMTP id D07BB43DE8 for ; Wed, 15 Nov 2006 14:12:28 +0000 (GMT) (envelope-from heli@mikestammer.com) Received: (qmail 22355 invoked from network); 15 Nov 2006 14:12:28 -0000 Received: from unknown (HELO mail.mikestammer.com) (mikestammer@sbcglobal.net@70.131.98.204 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 15 Nov 2006 14:12:27 -0000 X-YMail-OSG: JKEX15EVM1nWqgr4Ye1cgH8FdM.gkx4ByJR_dAKOJhsWDXBRYERhmmDMu9Wf7wtdiBOqX5JUNJiCZ.pXN5nPVMK5o35iFI8vrbE9QDyryoIHdpql5WTimg-- Received: from localhost (localhost [127.0.0.1]) by mail.mikestammer.com (Postfix) with ESMTP id BD6F81146A; Wed, 15 Nov 2006 08:12:26 -0600 (CST) X-Virus-Scanned: amavisd-new at mikestammer.com Received: from mail.mikestammer.com ([127.0.0.1]) by localhost (gondolin.middleearth.mikestammer.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+QJwPUG0GyQ; Wed, 15 Nov 2006 08:12:25 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eric) by mail.mikestammer.com (Postfix) with ESMTP id 2C8F811465; Wed, 15 Nov 2006 08:12:24 -0600 (CST) Message-ID: <455B2049.4050100@mikestammer.com> Date: Wed, 15 Nov 2006 08:12:25 -0600 From: Eric User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Suhail Choudhury References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Installing/Upgrading Ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 14:21:32 -0000 Suhail Choudhury wrote: > Hi, > > Why trying to install ports via "sysinstall -> customise -> ports", > whichever location I try, I get the following message: > > Warning: Can't find the `6.1-RELEASE-p10' distribution on this │ x │ > │ │ │ FTP server. You may need to visit a different server > for │ x │ > │ │ │ the release you are trying to fetch or go to the > Options │ x │ > │ │ │ menu and to set the release name to explicitly match > what's │ x │ > │ │ │ available on ftp1.freebsd.org (or set to "any"). > │ x │ > │ │ │ > │ x │ > │ │ │ Would you like to select another FTP server? > > How can I install the ports directory on 6.1-RELEASE-p10? > man portsnap From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 14:33:04 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58F7C16A4A7 for ; Wed, 15 Nov 2006 14:33:04 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from mailhost.graphdata.co.uk (mailhost.graphdata.co.uk [195.12.22.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id A827A43E0F for ; Wed, 15 Nov 2006 14:23:31 +0000 (GMT) (envelope-from dom@helenmarks.co.uk) Received: from localhost (localhost [127.0.0.1]) by mailhost.graphdata.co.uk (Postfix) with ESMTP id A09CA114032 for ; Wed, 15 Nov 2006 14:23:12 +0000 (GMT) X-Virus-Scanned: amavisd-new at graphdata.co.uk Received: from mailhost.graphdata.co.uk ([127.0.0.1]) by localhost (mailhost.graphdata.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioOj9j8Eq62u for ; Wed, 15 Nov 2006 14:23:06 +0000 (GMT) Received: from gdc083.internal.graphdata.co.uk (gdc083.internal.graphdata.co.uk [192.168.0.86]) by mailhost.graphdata.co.uk (Postfix) with SMTP id E9A0311402F for ; Wed, 15 Nov 2006 14:23:06 +0000 (GMT) Date: Wed, 15 Nov 2006 14:23:06 +0000 From: Dominic Marks To: freebsd-stable@freebsd.org Message-Id: <20061115142306.6a9de2ea.dom@helenmarks.co.uk> In-Reply-To: References: X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Installing/Upgrading Ports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 14:33:04 -0000 On Wed, 15 Nov 2006 13:59:38 +0000 "Suhail Choudhury" wrote: > Hi, > > Why trying to install ports via "sysinstall -> customise -> ports", > whichever location I try, I get the following message: > Most people avoid sysinstall where possible :-) > > How can I install the ports directory on 6.1-RELEASE-p10? > # cd /usr # fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz # tar xzf ports.tar.gz # rm ports.tar.gz You should then use csup to update this ports tree: # cp /usr/share/examples/cvsup/ports-supfile /your/place/ # csup -h cvsup.xx.freebsd.org /your/place/ports-supfile 1. Replace xx with your two letter country code. Of if you have no luck with your country, try a neighbour. 2. If you don't have csup installed then you can install it from ports first: # cd /usr/ports/net/csup && make install 3. Installing and learning portaudit and portupgrade (from ports) is also a good idea. > Regards, > Suhail. HTH, Dominic From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 14:46:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE17B16A403 for ; Wed, 15 Nov 2006 14:46:08 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 861E943D58 for ; Wed, 15 Nov 2006 14:46:08 +0000 (GMT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kAFEjbAD048029; Wed, 15 Nov 2006 09:45:37 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.6/8.13.3) with ESMTP id kAFEjb3v056334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Nov 2006 09:45:37 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200611151445.kAFEjb3v056334@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Nov 2006 09:45:37 -0500 To: Spartak Radchenko , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <45599A25.5080709@aif.ru> References: <455768F3.4000407@FreeBSD.org> <455786DB.4020807@mail.zedat.fu-berlin.de> <455858A3.9060701@aif.ru> <200611131447.kADElvjo044200@lava.sentex.ca> <45599A25.5080709@aif.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: Subject: Re: sio driver sucks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 14:46:09 -0000 At 05:27 AM 11/14/2006, Spartak Radchenko wrote: >>How do you switch it from sio to uart on RELENG_6 ? >> > >Build a new kernel with device uart, change sio to uart tn the >/boot/device.hints file. Maybe rebuilding a kernel is not needed, I >never checked it. Thanks, For me, sio on the motherboard generally has not been an issue. However, with serial PCI cards, I do see a lot of overflows and with a bit of cable plugging and unplugging, the box will live lock and need a reboot. http://lists.freebsd.org/pipermail/freebsd-current/2004-May/027453.html I noticed on current, if you compile both sio and uart in, sio will be used for the onboard devices, but uart for puc devices ---Mike From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 15:00:15 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 572FA16A407 for ; Wed, 15 Nov 2006 15:00:15 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5193C43D78 for ; Wed, 15 Nov 2006 15:00:04 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GkMEx-0000nQ-28 for freebsd-stable@freebsd.org; Wed, 15 Nov 2006 15:59:51 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Nov 2006 15:59:51 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Nov 2006 15:59:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 15 Nov 2006 15:59:32 +0100 Lines: 7 Message-ID: References: <474548e50611141652k66d5cb1ejca87ca1d78266ba5@mail.gmail.com> <014601c70853$f2f32fc0$b3db87d4@multiplay.co.uk> <474548e50611141742m394c5d2dx150c2cb667f0631e@mail.gmail.com> <20061115015647.GA95099@xor.obsecurity.org> <474548e50611141759n7d0845c1rb2ecf1b3964d7dc@mail.gmail.com> <474548e50611141800s68a7feb6le69d236678c0d6b7@mail.gmail.com> <20061115100641.GA22391@walton.maths.tcd.ie> <474548e50611150518j7945c9f5g55b162c303f2e00d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.4 (X11/20060625) In-Reply-To: <474548e50611150518j7945c9f5g55b162c303f2e00d@mail.gmail.com> Sender: news Subject: Re: Fwd: SSE support in 6.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 15:00:15 -0000 Joe wrote: > i'm currently attempting to emulate the appropriate cpu with qemu. i'll > keep > yall posted. You'll probably have a hard time accessing a server "inside" qemu, especially if it uses UDP. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 18:24:29 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59D7D16A403 for ; Wed, 15 Nov 2006 18:24:29 +0000 (UTC) (envelope-from dkirhlarov@oilspace.com) Received: from office.oilspace.com (ns2.oilspace.com [194.129.65.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FD7743D73 for ; Wed, 15 Nov 2006 18:24:27 +0000 (GMT) (envelope-from dkirhlarov@oilspace.com) Received: from dimma (proxy-mow.oilspace.com [81.222.156.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.oilspace.com (Postfix) with ESMTP id 6AD4B17A998 for ; Wed, 15 Nov 2006 18:24:25 +0000 (GMT) Received: from dimma (localhost [127.0.0.1]) by dimma (8.13.8/8.13.8) with ESMTP id kAFIOMM2001648 for ; Wed, 15 Nov 2006 21:24:22 +0300 (MSK) (envelope-from dkirhlarov@dimma) Received: (from dkirhlarov@localhost) by dimma (8.13.8/8.13.8/Submit) id kAFIOMdS001647 for freebsd-stable@freebsd.org; Wed, 15 Nov 2006 21:24:22 +0300 (MSK) (envelope-from dkirhlarov) Date: Wed, 15 Nov 2006 21:24:21 +0300 From: Dmitriy Kirhlarov To: freebsd-stable@freebsd.org Message-ID: <20061115182420.GA1132@dimma.mow.oilspace.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <20061113084430.GE59604@dimma.mow.oilspace.com> <20061113184505.GA51659@xor.obsecurity.org> <20061114075020.GA1154@dimma.mow.oilspace.com> <20061114185344.GA89030@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061114185344.GA89030@xor.obsecurity.org> X-Mailer: Mutt-ng devel (2005-03-13) based on Mutt 1.5.9 X-Operating-System: FreeBSD 6.2-PRERELEASE User-Agent: mutt-ng/devel-r804 (FreeBSD) Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 18:24:29 -0000 On Tue, Nov 14, 2006 at 01:53:45PM -0500, Kris Kennaway wrote: > From alc@: > > --- > I've never seen anything like this before. UMA is failing to allocate > the zone structure. This is unrelated to the large-swap scenario that > you ran into. Ask him to uncomment all of the UMA debugging #define's > at the start of uma_core.c. It was very painfull for me and I don't get result... #define UMA_DEBUG 1 #define UMA_DEBUG_ALLOC 1 #define UMA_DEBUG_ALLOC_1 1 in uma_core.c kill my machine. I get tons of crap to serial console. Server unaccessable over network too. I ask colocation support for manualy reboot server, for access to console and boot with old kernel. Now I update world and kernel to RELENG_6 11/15/2006 00:00:00 UTC Any other idea? PS. unionfs switch off now. UMA debug switch off too. WBR Dmitriy From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 18:25:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 544CE16A403 for ; Wed, 15 Nov 2006 18:25:45 +0000 (UTC) (envelope-from ingom-list@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id E432343D49 for ; Wed, 15 Nov 2006 18:25:44 +0000 (GMT) (envelope-from ingom-list@freenet.de) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.62) (envelope-from ) id 1GkPSB-0006iE-N4; Wed, 15 Nov 2006 19:25:43 +0100 Received: from p54b18a6e.dip0.t-ipconnect.de ([84.177.138.110]:1462 helo=medion-8800) by mx2.freenet.de with esmtpa (ID ingom-list@freenet.de) (port 25) (Exim 4.62 #12) id 1GkPSB-0000E7-7j; Wed, 15 Nov 2006 19:25:43 +0100 Date: Wed, 15 Nov 2006 19:25:42 +0100 To: "Pietro Cerutti" , freebsd-stable@freebsd.org From: Ingo Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.02 (Win32) Cc: Subject: Re: rc.subr modification: testing and feedback are welcome! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 18:25:45 -0000 Am 15.11.2006, 14:31 Uhr, schrieb Pietro Cerutti : > Hello List, > I did a patch to allow rc.conf DAEMON_enable values to be decided at > startup. > > 1) set apache_start="ask" in rc.conf > 2) at boot, you'll be prompted with "RC_ASK - Enable apache? [yes|no] " > 3) the daemon is started depending on the decision > 4) the decision is stored until the next boot, so that rc.shutdown can > decide whether to call stop for a particular daemon or not > > See: > http://www.freebsd.org/cgi/query-pr.cgi?pr=105568 > for more information and to download the patch > > > Thanx! > Hello, looks good (and works on my FBSD6.1), in general i like the idea but some more feature would be nice. There should be an tiemout so that the system boots even if I forget to choose (for example if I want to connect to the system by remote, and sshd isn´t startet yet). E.g. something like a global ASK_DELAY="sec" default set to 3sec or so, and adjustable by the variable. (and maybe adjustable for every demon individual) The DAEMON_enable variable should be set to ASK_DY to start after the default timeout and ASK_DN to not start after the timeout. It should also be possible to use the short form [y/n] while booting in addition to yes/no to start the deamon, and when I misstype, the variable should be set to "no" so that there is no errormessage from the rc system. greetings From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 19:26:50 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46C7E16A51C for ; Wed, 15 Nov 2006 19:26:50 +0000 (UTC) (envelope-from pietro.cerutti@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id E98FA43D9E for ; Wed, 15 Nov 2006 19:26:35 +0000 (GMT) (envelope-from pietro.cerutti@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so221932uge for ; Wed, 15 Nov 2006 11:26:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U2oCgMZ4Fxo8NvvY+Ti6RQPQnH0YrS7tjnSKAcvFmUQ8wT2SnVbQOX2t42UX9znZVlrqT6h0gc5ds4GM3d2v5XxheUkzG8ydSrgvRoRlzgQg9Ru1hXIbUCxYc4XI4XDSAXZP1OuZwbxL86+QVi+YhalQlyt1sE0XFjxNgnoxGwc= Received: by 10.67.22.14 with SMTP id z14mr3520611ugi.1163618793824; Wed, 15 Nov 2006 11:26:33 -0800 (PST) Received: by 10.66.224.6 with HTTP; Wed, 15 Nov 2006 11:26:33 -0800 (PST) Message-ID: Date: Wed, 15 Nov 2006 20:26:33 +0100 From: "Pietro Cerutti" To: Ingo , "FreeBSD Questions" , freebsd-stable@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: Subject: Re: rc.subr modification: testing and feedback are welcome! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 19:26:50 -0000 On 11/15/06, Ingo wrote: > > Hello, Hello, > There should be an tiemout so that the system boots even if I forget to > choose Yup, great idea. The new patch [attached] permits you to set: DAEMON_ask_timeout={0-9}[s|m|h] and DAEMON_ask_default=[yes|no] in rc.conf Default values have been put in rc.subr ("5s" and "yes") > > It should also be possible to use the short form [y/n] while booting in > addition to yes/no to start the deamon, This could be done, but at the moment I rely on the checkyesno subroutine in rc.subr, which only accepts [yes, true, on, 1] and [no, false, off, 0] in any combination of upper and lower case. > > greetings > Thanks for input, regards -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 19:27:33 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B2A016A4C8 for ; Wed, 15 Nov 2006 19:27:33 +0000 (UTC) (envelope-from pietro.cerutti@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88BC143D77 for ; Wed, 15 Nov 2006 19:27:26 +0000 (GMT) (envelope-from pietro.cerutti@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so222184uge for ; Wed, 15 Nov 2006 11:27:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=sAq6E6LkdNYJyTC07lVpdgW/QeGvw+Jndcd+zrv5A9wFtyGnMVcEyDNGiN+/HlqEllXUj6SJfqIi8kDuD4jQ8+m6w6mmZJ4RDdJZJ+0n9pvJ4072eRt/sxN+P6l3NBEmrDZy7huRmkONaGaU4WPEu4S8/5MlxnLTFgb7LOc9gno= Received: by 10.66.242.5 with SMTP id p5mr3513524ugh.1163618845219; Wed, 15 Nov 2006 11:27:25 -0800 (PST) Received: by 10.66.224.6 with HTTP; Wed, 15 Nov 2006 11:27:25 -0800 (PST) Message-ID: Date: Wed, 15 Nov 2006 20:27:25 +0100 From: "Pietro Cerutti" To: Ingo , "FreeBSD Questions" , freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_84035_12571137.1163618845044" Cc: Subject: Re: rc.subr modification: testing and feedback are welcome! [here's the patch] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 19:27:33 -0000 ------=_Part_84035_12571137.1163618845044 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Ouch... here's the patch ;-) On 11/15/06, Pietro Cerutti wrote: > On 11/15/06, Ingo wrote: > > > > Hello, > > Hello, > > > There should be an tiemout so that the system boots even if I forget to > > choose > > Yup, great idea. The new patch [attached] permits you to set: > > DAEMON_ask_timeout={0-9}[s|m|h] > and > DAEMON_ask_default=[yes|no] > > in rc.conf > > Default values have been put in rc.subr ("5s" and "yes") > > > > > It should also be possible to use the short form [y/n] while booting in > > addition to yes/no to start the deamon, > > This could be done, but at the moment I rely on the checkyesno > subroutine in rc.subr, which only accepts [yes, true, on, 1] and [no, > false, off, 0] in any combination of upper and lower case. > > > > > > greetings > > > > Thanks for input, regards > > > -- > Pietro Cerutti > ICQ: 117293691 > PGP: 0x9571F78E > > - ASCII Ribbon Campaign - > against HTML e-mail and > proprietary attachments > www.asciiribbon.org > -- Pietro Cerutti ICQ: 117293691 PGP: 0x9571F78E - ASCII Ribbon Campaign - against HTML e-mail and proprietary attachments www.asciiribbon.org ------=_Part_84035_12571137.1163618845044 Content-Type: application/octet-stream; name=rc.subr.diff Content-Transfer-Encoding: base64 X-Attachment-Id: f_euk4ljww Content-Disposition: attachment; filename="rc.subr.diff" LS0tIC9ldGMvcmMuc3Vici5vcmlnCVdlZCBOb3YgMTUgMTQ6MDM6NTkgMjAwNgorKysgL2V0Yy9y Yy5zdWJyCVdlZCBOb3YgMTUgMjA6MTA6MzIgMjAwNgpAQCAtNTYsNiArNTYsOCBAQAogSUQ9Ii91 c3IvYmluL2lkIgogSklEPWBwcyAtcCAkJCAtbyBqaWQ9YAogSURDTUQ9ImlmIFsgLXggJElEIF07 IHRoZW4gJElEIC11bjsgZmkiCitBU0tfVElNRU9VVD0iNXMiCitBU0tfREVGQVVMVD0iWUVTIgog CiBjYXNlICR7T1NUWVBFfSBpbgogRnJlZUJTRCkKQEAgLTEyMiw3ICsxMjQsOCBAQAogCiAjCiAj IGNoZWNreWVzbm8gdmFyCi0jCVRlc3QgJDEgdmFyaWFibGUsIGFuZCB3YXJuIGlmIG5vdCBzZXQg dG8gWUVTIG9yIE5PLgorIwlUZXN0ICQxIHZhcmlhYmxlLCBhbmQgd2FybiBpZiBub3Qgc2V0IHRv IFlFUywgTk8gb3IgQVNLLgorIwlJZiBpdCdzICJhc2siLCBsZXQgdGhlIHVzZXIgY2hvb3NlIGF0 IHJ1bnRpbWUgYmV0d2VlbiAieWVzIiBhbmQgIm5vIi4KICMJUmV0dXJuIDAgaWYgaXQncyAieWVz IiAoZXQgYWwpLCBub256ZXJvIG90aGVyd2lzZS4KICMKIGNoZWNreWVzbm8oKQpAQCAtMTQwLDcg KzE0Myw1MiBAQAogCVtObl1bT29dfFtGZl1bQWFdW0xsXVtTc11bRWVdfFtPb11bRmZdW0ZmXXww KQogCQlyZXR1cm4gMQogCQk7OwotCSopCisKKyAgICAgICMgImFzayIKKwlbQWFdW1NzXVtLa10p CisgICAgICAKKyAgICAgICMgYW5zd2VyIGFscmVhZHkgc3RvcmVkIGluIC5hc2sgZmlsZSwKKyAg ICAgICMgdGhpcyBzaG91bGQgYmUgdGhlIGNhc2Ugb24gc2h1dGRvd24KKyAgICAgIF9maWxlPSIv dmFyL3J1bi8kbmFtZS5hc2siCisgICAgICBpZiBbIC1mICRfZmlsZSBdOyB0aGVuCisgICAgICAg ICByZWFkIF9yZXNwb25zZSA8ICRfZmlsZQorICAgICAgICAgaWYgY2hlY2t5ZXNubyBfcmVzcG9u c2U7IHRoZW4KKyAgICAgICAgICAgIHJldHVybiAwCisgICAgICAgICBlbHNlCisgICAgICAgICAg ICByZXR1cm4gMQorICAgICAgICAgZmkKKyAgICAgIGZpCisgICAgICAjIHByb21wdCBhbmQgc2F2 ZSBjaG9pY2UgdG8gZmlsZSwKKyAgICAgICMgdGhpcyBzaG91bGQgYmUgdGhlIGNhc2Ugb24gc3Rh cnR1cAorCisgICAgICAjIFJlYWQgdGltZW91dCBhbmQgZGVmYXVsdCBhbnN3ZXIgZm9yIGRhZW1v bgorICAgICAgZXZhbCBfdGltZW91dD1cJCR7bmFtZX1fYXNrX3RpbWVvdXQKKyAgICAgIGV2YWwg X3Jlc3BvbnNlPVwkJHtuYW1lfV9hc2tfZGVmYXVsdAorCisgICAgICBpZiBbICEgJF90aW1lb3V0 IF07IHRoZW4KKyAgICAgICAgIF90aW1lb3V0PSRBU0tfVElNRU9VVAorICAgICAgZmkKKworICAg ICAgaWYgWyAhICRfcmVzcG9uc2UgXTsgdGhlbgorICAgICAgICAgX3Jlc3BvbnNlPSRBU0tfREVG QVVMVAorICAgICAgZmkKKworICAgICAgcmVhZCAtdCAkX3RpbWVvdXQgLXAgIlJDX0FTSyAtIEVu YWJsZSAkbmFtZT8gW3llc3xub10gIiBfZW5hYmxlCisgICAgICBpZiBbICQ/IC1lcSAxIF07IHRo ZW4KKyAgICAgICAgIF9lbmFibGU9JHtfcmVzcG9uc2V9CisgICAgICBmaQorICAgICAgaWYgY2hl Y2t5ZXNubyBfZW5hYmxlOyB0aGVuCisgICAgICAgICBfY2hvaWNlPSJ5ZXMiCisgICAgICAgICBf cmV0dXJuPTAKKyAgICAgIGVsc2UKKyAgICAgICAgIF9jaG9pY2U9Im5vIgorICAgICAgICAgX3Jl dHVybj0xCisgICAgICBmaQorICAgICAgZWNobyAiJF9jaG9pY2UiID4gJF9maWxlCisgICAgICBy ZXR1cm4gICRfcmV0dXJuOworICAgICAgOzsKKworICAgKikKIAkJd2FybiAiXCQkezF9IGlzIG5v dCBzZXQgcHJvcGVybHkgLSBzZWUgJHtyY3Zhcl9tYW5wYWdlfS4iCiAJCXJldHVybiAxCiAJCTs7 Cg== ------=_Part_84035_12571137.1163618845044-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 19:35:13 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62E1D16A494 for ; Wed, 15 Nov 2006 19:35:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 2344B43D9D for ; Wed, 15 Nov 2006 19:33:41 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 7156 invoked by uid 399); 15 Nov 2006 19:33:41 -0000 Received: from localhost (HELO lap) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 15 Nov 2006 19:33:41 -0000 Date: Wed, 15 Nov 2006 11:33:27 -0800 (PST) From: Doug Barton To: Pietro Cerutti In-Reply-To: Message-ID: <20061115113256.N1437@ync.qbhto.arg> References: Organization: http://www.FreeBSD.org/ X-OpenPGP-Key-ID: 0xD5B2F0FB X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, Ingo , FreeBSD Questions Subject: Re: rc.subr modification: testing and feedback are welcome! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 19:35:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You should probably consider discussing this on the freebsd-rc@ list as well. Doug - -- This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.0 (FreeBSD) iD8DBQFFW2uTyIakK9Wy8PsRAl9sAKD9CjyPJewi4EoZMvs7WQGlCNxT4gCeJ8GY gQSYCA80amd3kJCQ0S11gv0= =UVOj -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 20:10:29 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEB4016A52F for ; Wed, 15 Nov 2006 20:10:29 +0000 (UTC) (envelope-from vincent@xtra-net.org) Received: from ns1.xtra-net.be (ns1.xtra-net.be [195.162.200.90]) by mx1.FreeBSD.org (Postfix) with SMTP id BB0E443E09 for ; Wed, 15 Nov 2006 20:09:54 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 29029 invoked from network); 15 Nov 2006 20:09:53 -0000 Received: from unknown (HELO sbepfkaa.srv.xtra-net.be) (172.16.66.66) by 0 with SMTP; 15 Nov 2006 20:09:53 -0000 Received: (qmail 1969 invoked from network); 15 Nov 2006 20:09:22 -0000 Received: from wbedllfs.intranet.xtra-net.be (HELO wbemfkaa.net.xtra-net.be) (172.16.66.1) by 0 with SMTP; 15 Nov 2006 20:09:22 -0000 From: Vincent Blondel To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Wed, 15 Nov 2006 21:09:24 +0100 Message-Id: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 20:10:29 -0000 Hello all, -- System: FreeBSD-6.2-BETA3 | Tyan S2468GN -- I got a kernel crash on my web server this evening. I am now trying to debug the crash image generated on /var/crash/vmcore.0 but I am not comfortable with this procedure. As far as I can see it seems process httpd crashed but I do not know what I have to do to obtain precise info on this crash. I give you below a snapshot of I what I tried until now. So, could somebody help me debugging this crash ? Many thanks for your help. Regards Vincent. -- root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] # kgdb kernel.debug /var/crash/vmcore.0 [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: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 01 fault virtual address = 0x27675eda fault code = supervisor write, page not present instruction pointer = 0x20:0xc062a143 stack pointer = 0x28:0xe7063988 frame pointer = 0x28:0xe70639a4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 1213 (httpd) trap number = 12 panic: page fault cpuid = 0 Uptime: 4d0h17m19s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) list*0xc062a143 0xc062a143 is at /usr/src/sys/i386/i386/swtch.s:108. 103 /usr/src/sys/i386/i386/swtch.s: No such file or directory. in /usr/src/sys/i386/i386/swtch.s (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc04e3436 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc04e375d in panic (fmt=0xc064447a "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc062bd30 in trap_fatal (frame=0xe7063948, eva=661085914) at /usr/src/sys/i386/i386/trap.c:837 #4 0xc062b4e6 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -990658024, tf_esi = -992064896, tf_ebp = -419022428, tf_isp = -419022476, tf_ebx = -999450368, tf_edx = -419021423, tf_ecx = -992064896, tf_eax = -1068542761, tf_trapno = 12, tf_err = 2, tf_eip = -1067278013, tf_cs = 32, tf_eflags = 65666, tf_esp = -1068542761, tf_ss = -1068542761}) at /usr/src/sys/i386/i386/trap.c:270 #5 0xc061810a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc062a143 in cpu_switch () at /usr/src/sys/i386/i386/swtch.s:108 Previous frame inner to this frame (corrupt stack?) (kgdb) quit root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] # From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 20:16:10 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ADD316A40F for ; Wed, 15 Nov 2006 20:16:10 +0000 (UTC) (envelope-from om-lists-bsd@omx.ch) Received: from omega.omnis.ch (omega.omnis.ch [195.134.143.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 97B7E43D49 for ; Wed, 15 Nov 2006 20:16:09 +0000 (GMT) (envelope-from om-lists-bsd@omx.ch) Received: (qmail 11832 invoked from network); 15 Nov 2006 20:16:06 -0000 Received: from 195.134.148.35 ([195.134.148.35]) by omega.omnis.ch ([195.134.143.43]) with ESMTP via TCP; 15 Nov 2006 20:16:06 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <4685C92E-8B28-493A-BBFB-79A50F617970@omx.ch> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-stable@freebsd.org From: Olivier Mueller Date: Wed, 15 Nov 2006 21:16:07 +0100 X-Mailer: Apple Mail (2.752.2) Subject: linux locales to freebsd: symlink to make php setlocale() happy ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 20:16:10 -0000 Bonjour, While moving some more customers from a linux to a freebsd-based hosting, like some others I had a problem with php pages using setlocale(). According to 'locale -a', it looks like that for de_DE (german): Linux (suse): de_DE de_DE.utf8 de_DE@euro FreeBSD (6.1): de_DE.ISO8859-1 de_DE.ISO8859-15 de_DE.UTF-8 And in the customers code, the call which hadn't worked anymore is: setlocale (LC_ALL, 'de_DE@euro', 'de_DE', 'de', 'ge'). I could tell the customer to update his code and add "de_DE.ISO8859-1" to his setlocale() list, but he will ask me "why isn't it like before?" and on systems with hundreds of virtualhosts (and different customers), this can't really be done. So what would be the "cleanest" solution? Is there an options somewhere to add the "standard" de_DE-like label (xx_XX) to all languages? Or should I use symlinks like: [root@bsd /usr/share/locale]# ln -s de_DE.ISO8859-1 de_DE Regards, Olivier From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 20:37:52 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9ABB16A514 for ; Wed, 15 Nov 2006 20:37:52 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8594B43D83 for ; Wed, 15 Nov 2006 20:37:52 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 70E991A3C20 for ; Wed, 15 Nov 2006 12:37:52 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E93D351341; Wed, 15 Nov 2006 15:37:40 -0500 (EST) Date: Wed, 15 Nov 2006 15:37:40 -0500 From: Kris Kennaway To: freebsd-stable@freebsd.org Message-ID: <20061115203740.GA31455@xor.obsecurity.org> References: <20061113084430.GE59604@dimma.mow.oilspace.com> <20061113184505.GA51659@xor.obsecurity.org> <20061114075020.GA1154@dimma.mow.oilspace.com> <20061114185344.GA89030@xor.obsecurity.org> <20061115182420.GA1132@dimma.mow.oilspace.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <20061115182420.GA1132@dimma.mow.oilspace.com> User-Agent: Mutt/1.4.2.2i Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 20:37:52 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 15, 2006 at 09:24:21PM +0300, Dmitriy Kirhlarov wrote: > On Tue, Nov 14, 2006 at 01:53:45PM -0500, Kris Kennaway wrote: >=20 > > From alc@: > >=20 > > --- > > I've never seen anything like this before. UMA is failing to allocate > > the zone structure. This is unrelated to the large-swap scenario that > > you ran into. Ask him to uncomment all of the UMA debugging #define's > > at the start of uma_core.c. >=20 > It was very painfull for me and I don't get result... >=20 > #define UMA_DEBUG 1 > #define UMA_DEBUG_ALLOC 1 > #define UMA_DEBUG_ALLOC_1 1 >=20 > in uma_core.c kill my machine. > I get tons of crap to serial console. The "tons of crap" is what was necessary to proceed. Kris --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFW3qUWry0BWjoQKURAkPeAKCUoXI9GtKVnUUL849hkl3rHyOtUwCfRJnj /YvirRmlDA7i2m+U6qkx9eo= =IJ6T -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 21:43:15 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96EC516A403 for ; Wed, 15 Nov 2006 21:43:15 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8116F43D88 for ; Wed, 15 Nov 2006 21:43:12 +0000 (GMT) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 2F8684204 for ; Wed, 15 Nov 2006 13:42:56 -0800 (PST) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "satchel.alerce.com", Issuer "alerce.com" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id E65BE4203 for ; Wed, 15 Nov 2006 13:42:55 -0800 (PST) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.4/8.13.4) with ESMTP id kAFLhATA001592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 Nov 2006 13:43:10 -0800 (PST) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.4/8.13.4/Submit) id kAFLhAF4001587; Wed, 15 Nov 2006 13:43:10 -0800 (PST) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17755.35310.250336.672952@satchel.alerce.com> Date: Wed, 15 Nov 2006 13:43:10 -0800 To: freebsd-stable@freebsd.org In-Reply-To: <455A2C21.9020304@quip.cz> References: <17754.8258.37357.575054@satchel.alerce.com> <455A2C21.9020304@quip.cz> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: help identifying gmirror, ata, or motherboard problem (Tyan S2865G2NR) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 21:43:15 -0000 Miroslav Lachman writes: > George Hartzell wrote: > > > I'm having a problem with a machine that I support and would like some > > feedback. > > > > The system was built up from a barebones Transport PX22, which uses a > > Tyan S2865G2NR motherboard. > > > > It has two drives: > > > > ad4: 286188MB at ata2-master SATA300 > > ad6: 286188MB at ata3-master SATA300 Just to follow up on this, Maxtor asked if the board used an Nvidia controller (it does...) and then claimed that a newer rev. of their firmware for these drives would work better. They're shipping a replacement drive. We'll see.... Thanks for all the feedback. g. From owner-freebsd-stable@FreeBSD.ORG Wed Nov 15 22:14:49 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E8B916A51A for ; Wed, 15 Nov 2006 22:14:49 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [74.92.149.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 280D343D49 for ; Wed, 15 Nov 2006 22:14:28 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 0E33EB80F for ; Wed, 15 Nov 2006 17:14:19 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) To: FreeBSD Stable Message-Id: <36FBC1D2-9F33-4EA1-B93D-EB4C2B1253E8@khera.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-638064759; protocol="application/pkcs7-signature" From: Vivek Khera Date: Wed, 15 Nov 2006 17:14:18 -0500 X-Mailer: Apple Mail (2.752.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: adaptec utilities on amd64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 22:14:49 -0000 --Apple-Mail-2-638064759 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Does anyone have any hints on monitoring adaptec RAID's (particularly aac devices such as 2230SLP) on FreeBSD 6.2/amd64? I don't need to reconfigure anything, just know when and which drives have failed, if any. The latest card I got apparently has firmware too new for use with the FreeBSD native aaccli. Older versions of that card worked fine when freebsd4 compat was built into the kernel with FreeBSD 6.0, 6.1 and 6.2. I installed (with some $ARCH trickery) the linux-afaapps port, but it fails to run with this error: /compat/linux/usr/sbin/afacli: error while loading shared libraries: / usr/lib/libartsc.so.0: ELF file OS ABI invalid So then I tried the linux arcconf utility on the CD that came with the card. It reports "Controllers found: 0". Is there any other program to try? Has anyone hacked up a small program to do the necessary ioctl calls to the aac driver to probe the raid status and print out a degraded/optimal type output? something like what the kernel prints on boot would be sufficient. I'm very scared to put the server into production without a way to monitor the RAID status. --Apple-Mail-2-638064759-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 00:35:01 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F413C16A412 for ; Thu, 16 Nov 2006 00:35:00 +0000 (UTC) (envelope-from brucegb@realtime.net) Received: from ruth.realtime.net (mercury.realtime.net [205.238.132.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F4D643D46 for ; Thu, 16 Nov 2006 00:34:58 +0000 (GMT) (envelope-from brucegb@realtime.net) Received: from tigerfish2.my.domain (cpe-24-27-51-69.austin.res.rr.com [24.27.51.69]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 27180460-1817707 for ; Wed, 15 Nov 2006 18:34:57 -0600 Received: from tigerfish2.my.domain (localhost [127.0.0.1]) by tigerfish2.my.domain (8.13.8/8.13.8) with ESMTP id kAG0YveL047395 for ; Wed, 15 Nov 2006 18:34:57 -0600 (CST) (envelope-from brucegb@tigerfish2.my.domain) Received: (from brucegb@localhost) by tigerfish2.my.domain (8.13.8/8.13.8/Submit) id kAG0Yvde047394 for freebsd-stable@freebsd.org; Wed, 15 Nov 2006 18:34:57 -0600 (CST) (envelope-from brucegb) Date: Wed, 15 Nov 2006 18:34:57 -0600 From: Bruce Burden To: freebsd-stable@freebsd.org Message-ID: <20061116003422.GC942@tigerfish2.my.domain> References: <36FBC1D2-9F33-4EA1-B93D-EB4C2B1253E8@khera.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36FBC1D2-9F33-4EA1-B93D-EB4C2B1253E8@khera.org> User-Agent: Mutt/1.4.2.2i Subject: Re: adaptec utilities on amd64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 00:35:01 -0000 On Wed, Nov 15, 2006 at 05:14:18PM -0500, Vivek Khera wrote: > > Does anyone have any hints on monitoring adaptec RAID's (particularly > aac devices such as 2230SLP) on FreeBSD 6.2/amd64? I don't need to > reconfigure anything, just know when and which drives have failed, if > any. > I have a 2230SLP that I will be installing early next week on my AMD64 implementation. I am hoping that the aaccli program in ports will work. > > I installed (with some $ARCH trickery) the linux-afaapps port, but it > fails to run with this error: > > /compat/linux/usr/sbin/afacli: error while loading shared libraries: / > usr/lib/libartsc.so.0: ELF file OS ABI invalid > Did you brandelf the library? I tried working with the code from the CD, but ran into three problems: 1) I could not get additional .jar files recognised. (for the authenticateUser code) 2) The java code eventually goes into linux shared libraries, and (native) java seems rather reluctant to use linux libraries in the compat mode 3) Linux mode java should have worked based on the pathname supplied, but it did not. So, back to the aaccli program... > > So then I tried the linux arcconf utility on the CD that came with > the card. It reports "Controllers found: 0". > Yeah, me to. But, I figure that is because it runs into other problems first. Bruce -- ------------------------------------------------------------------------ "I like bad!" Bruce Burden Austin, TX. - Thuganlitha The Power and the Prophet Robert Don Hughes From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 00:49:39 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1DB616A416 for ; Thu, 16 Nov 2006 00:49:39 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EB0D43D5C for ; Thu, 16 Nov 2006 00:49:36 +0000 (GMT) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (failure[67.174.220.97]) by comcast.net (sccrmhc14) with ESMTP id <2006111600493601400mf0ese>; Thu, 16 Nov 2006 00:49:36 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AC1FC1FA01D; Wed, 15 Nov 2006 16:49:25 -0800 (PST) Date: Wed, 15 Nov 2006 16:49:25 -0800 From: Jeremy Chadwick To: George Hartzell Message-ID: <20061116004925.GA63607@icarus.home.lan> Mail-Followup-To: George Hartzell , freebsd-stable@freebsd.org References: <17754.8258.37357.575054@satchel.alerce.com> <455A2C21.9020304@quip.cz> <17755.35310.250336.672952@satchel.alerce.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17755.35310.250336.672952@satchel.alerce.com> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org Subject: Re: help identifying gmirror, ata, or motherboard problem (Tyan S2865G2NR) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 00:49:39 -0000 On Wed, Nov 15, 2006 at 01:43:10PM -0800, George Hartzell wrote: > Just to follow up on this, Maxtor asked if the board used an Nvidia > controller (it does...) and then claimed that a newer rev. of their > firmware for these drives would work better. > > They're shipping a replacement drive. We'll see.... > > Thanks for all the feedback. I can confirm this problem, and it's documented all over the web, from forums to blogs to Maxtor's own site. Maxtor won't admit to it being a "bug", instead stating it's a "compatibility issue" with nVidia chipsets. They will only replace a drive with this firmware if the customer calls and complains about the exact issue and knows of the nVidia compatibility problem. It also helps to refer to the support ID# (or whatever it's called) when calling them, otherwise they claim they have no knowledge of it. Maxtor would not send me a firmware, nor an updater application, for the drive. I got Maxtor to send me a replacement drive, and it did fix the problem. However, the NCQ feature of the drive is essentially disabled (not like it matters much; read StorageReview's review of NCQ/TCQ for details). This problem (amongst many others) have pretty much put me off of ever buying another Maxtor drive as long as I live, and have made me extra wary of nVidia's SB (southbridge) chipsets. I expect a drive manufacturer + ATA interface company to test their drives thoroughly on all mainstream vendors' southbridges. Test means weeks upon weeks of constant pounding, in RAID arrays and in single systems. This kind-of bug should've been caught immediately, and never made it to the consumer market. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 02:05:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABF9916A416 for ; Thu, 16 Nov 2006 02:05:45 +0000 (UTC) (envelope-from pokui@psg.com) Received: from mail.trueafrican.com (mail.trueafrican.com [212.88.98.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E5A743D46 for ; Thu, 16 Nov 2006 02:05:42 +0000 (GMT) (envelope-from pokui@psg.com) Received: from mail.trueafrican.com ([127.0.0.1]) by localhost (mail.trueafrican.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02083-09 for ; Thu, 16 Nov 2006 05:05:25 +0300 (EAT) Received: from andromeda.trueafrican.com (pokui.trueafrican.com [169.254.0.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.trueafrican.com (Postfix) with ESMTP id 3D65825F1C0 for ; Thu, 16 Nov 2006 05:05:20 +0300 (EAT) Received: from [127.0.0.1] (helo=localhost) by andromeda.trueafrican.com with esmtp (Exim 4.62) (envelope-from ) id 1GkWdv-0002LX-U1 for freebsd-stable@freebsd.org; Thu, 16 Nov 2006 05:06:20 +0300 From: Patrick Okui To: freebsd-stable@freebsd.org Date: Thu, 16 Nov 2006 05:06:16 +0300 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611160506.17630.pokui@psg.com> X-Virus-Scanned: by amavisd-new at trueafrican.com Subject: kernel build on RELENG_6 (as of 15:00 GMT on 16.November.2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 02:05:45 -0000 Fails with something along the lines of.. ...In function `ASR_failActiveCommands': /usr/src/sys/dev/asr/asr.c:840: error: `bcb' undeclared (first use in this function) /usr/src/sys/dev/asr/asr.c:840: error: (Each undeclared identifie .... changing bcb to ccb on that line fixes that... then later.. In file included from /usr/src/sys/kern/sched_4bsd.c:1390: /usr/src/sys/kern/kern_switch.c: In function `runq_choose': /usr/src/sys/kern/kern_switch.c:871: error: stray '\8' in program *** Error code 1 Replacing the ^H at the beginning of the file with a tab fixes that.. (funny enough, just deleting the charcter with 'x' in vi didn't work, I had to 'dd' the line and retype it out ... makes me wonder what editor was used to put that character there in the first place.) I'm guessing a committer has already caught this and fixed... but thought I'd post just in case someone hits the same bugs. -- patrick From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 02:07:37 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 105B116A40F for ; Thu, 16 Nov 2006 02:07:37 +0000 (UTC) (envelope-from atanas@asd.aplus.net) Received: from pro20.abac.com (pro20.abac.com [66.226.64.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C59D143D45 for ; Thu, 16 Nov 2006 02:07:36 +0000 (GMT) (envelope-from atanas@asd.aplus.net) Received: from [216.55.129.232] ([216.55.129.232]) (authenticated bits=0) by pro20.abac.com (8.13.8/8.13.8) with ESMTP id kAG27QlN077523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Nov 2006 18:07:27 -0800 (PST) (envelope-from atanas@asd.aplus.net) Message-ID: <455BC7F0.8080203@asd.aplus.net> Date: Wed, 15 Nov 2006 18:07:44 -0800 From: Atanas User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mark Dotson References: <455A1DEA.20304@asd.aplus.net> <455A32B7.9080304@dmglobal.net> In-Reply-To: <455A32B7.9080304@dmglobal.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.47 (SPF_SOFTFAIL) Cc: freebsd-stable@freebsd.org Subject: Re: twa: Passthru request timed out! Resetting controller... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 02:07:37 -0000 Mark Dotson said the following on 11/14/06 1:18 PM: > I've had continued problems with the 3ware series SATA cards and the > Tyan boards. Specifically, I have a "Tyan S5360-1U" and both a > 9500S-4LP and a 8506 series 3ware cards. > > In my case the first error is different, but the 'resetting' over and > over is VERY familiar. This could be triggered by a simple file copy > from one part of a container to another; degrading the unit and > triggering the resetting crap. Note that the drives are fine, I tested > that first thing. > > Sep 8 11:59:23 localhost kernel: 3w-9xxx: scsi0: WARNING: > (0x06:0x002C): Unit #1: Command (0x2a) timed out, resetting card. > Sep 8 11:59:41 localhost kernel: 3w-9xxx: scsi0: AEN: INFO (0x04:0x005E): > Cache synchronized after power fail:unit=0. > Sep 8 11:59:41 localhost kernel: 3w-9xxx: scsi0: AEN: INFO (0x04:0x005E): > Cache synchronized after power fail:unit=1. > > I also found this problem to exist across platforms, not just FreeBSD. > For example, the excerpt above is from a CentOS box. > > All tests were done with newest firmware for both card and mobo, and > using the newest drivers provided by 3ware. > > Once I removed the card and drives from the Tyan system and stuck them > in pretty much ANY other system, they worked fantastically. > > I don't have an answer for the "resetting problem" as of yet... 3ware > and Tyan (And my system vendor "Appro") are still trying to find my > specific problem and solve it. I believe they are currently doing the > "replace everything" method of troubleshooting. > Mark, thank you. It's good to know that the resetting problem exist on other platforms too. We already found out that replacing the entire box with identical one doesn't help, so unfortunately we'll have to start replacing components by using different brands or models. I wouldn't like to touch the I/O subsystem (these are already loaded production machines), so like you said, the safest bet would be to try another motherboard. However I don't see many Dual Opteron based boards suggested by the 3ware's compatibility list. The next one that comes in mind from that list is Supermicro H8DC8, but it looks more like a gamers dream (High-End PCI-e Graphics, SLI, etc. but no on-board VGA) than a server board. I'm quite surprised that the top Opteron based motherboard manufacturer listed in the 3ware web site motherboard compatibility docs: http://3ware.com/products/pdf/Motherboard_compatibility_list_9550SX_2006_06.pdf makes 2 out of 5 boards that are marked as compatible, but perform so bad with 3ware cards. I know what happens here in this mailing list when somebody looks for good SATA cards (Re: 3ware, 3ware, ...), I replied myself too. So are there any success stories with 3ware 9550SX (SATA II) and dual AMD Opteron server boards, or it's time to go back with Intel? Regards, Atanas > Atanas wrote: >> Has anyone experiencing this: >> >> twa0: ERROR: (0x05: 0x2018): Passthru request timed out!: request = >> 0xca839d20 >> twa0: INFO: (0x16: 0x1108): Resetting controller...: >> twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=0 >> ... >> twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=7 >> twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=1 >> twa0: INFO: (0x16: 0x1107): Controller reset done!: >> >> This happens on 6.2-PRERELEASE i386 (and on 6.1 since its release) on >> a number of machines with the following hardware configuration: >> >> - Tyan K8SE 2892, 2 AMD Opteron 270 CPUs, 4GB RAM >> - 3ware 9550SX-8LP, 8 500GB Seagate ST3500641AS SATA drives >> (configured as 8 SINGLE DISK units, aka JBOD) >> >> All hardware components, including the server chassis, are listed in >> the 3ware hardware compatibility lists. It doesn't seem to be a >> cabling or power issue. The controller and hard drives are already >> flashed to the latest firmware revisions. I tried turning off NCQ, but >> it didn't make any difference. I tried also switching the kernel from >> PAE to non-PAE (reducing the usable memory to 3GB), but it didn't help >> either. >> >> I have another machines with similar I/O configurations (3ware), but >> with Intel motherboards and running FreeBSD-5.5, and these run fine >> for about a year already. Now I'm thinking about swapping the drives >> between a working Intel and AMD based box, to see where controller >> timeouts will follow. >> >> The problem happens sporadically once in a month or so and is very >> hard to reproduce. Sometimes it takes several weeks until the next >> crash happens, sometimes it crashes again in just a few hours. >> >> When the thing happens, the kernel sometimes panics (most likely due >> to the inconsistent filesystem state caused by the controller reset), >> sometimes just hangs. It can be interrupted (I have a serial console), >> but the only usable thing after that seems to be "call cpu_reset()", >> followed by full (and sometimes painfully long) filesystem check. >> >> Here are the diffs against the default GENERIC and PAE kernel >> configurations: >> >> < cpu I486_CPU >> < ident GENERIC >> < options INET6 # IPv6 communications protocols >> < options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI >> >> > options QUOTA >> > options SMP # Symmetric MultiProcessor Kernel >> > options BREAK_TO_DEBUGGER >> > options DDB >> > options KDB >> > options KDB_UNATTENDED >> >> > options IPFIREWALL >> > options DUMMYNET >> >> I'm attaching the dmesg.boot following the latest crash. >> >> Regards, >> Atanas >> From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 02:22:24 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 087A716A40F for ; Thu, 16 Nov 2006 02:22:24 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2370043D46 for ; Thu, 16 Nov 2006 02:22:23 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 084701A3C1C; Wed, 15 Nov 2006 18:22:23 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 523FB51449; Wed, 15 Nov 2006 21:22:11 -0500 (EST) Date: Wed, 15 Nov 2006 21:22:11 -0500 From: Kris Kennaway To: Patrick Okui Message-ID: <20061116022211.GA36855@xor.obsecurity.org> References: <200611160506.17630.pokui@psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <200611160506.17630.pokui@psg.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: kernel build on RELENG_6 (as of 15:00 GMT on 16.November.2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 02:22:24 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 05:06:16AM +0300, Patrick Okui wrote: > Fails with something along the lines of.. >=20 > ...In function `ASR_failActiveCommands': > /usr/src/sys/dev/asr/asr.c:840: error: `bcb' undeclared (first use in thi= s=20 > function) > /usr/src/sys/dev/asr/asr.c:840: error: (Each undeclared identifie .... >=20 > changing bcb to ccb on that line fixes that... then later.. >=20 > In file included from /usr/src/sys/kern/sched_4bsd.c:1390: > /usr/src/sys/kern/kern_switch.c: In function `runq_choose': > /usr/src/sys/kern/kern_switch.c:871: error: stray '\8' in program > *** Error code 1 >=20 > Replacing the ^H at the beginning of the file with a tab fixes that.. (fu= nny=20 > enough, just deleting the charcter with 'x' in vi didn't work, I had to '= dd'=20 > the line and retype it out ... makes me wonder what editor was used to pu= t=20 > that character there in the first place.) >=20 > I'm guessing a committer has already caught this and fixed... but thought= I'd=20 > post just in case someone hits the same bugs. You have bad RAM. Kris --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD4DBQFFW8tSWry0BWjoQKURAiUHAJds8zHmE/CLzHwVcw4yrgf/WC8BAJ9dpuyE T8wb1sL9HWHrnxl+DeX2AA== =uUlL -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 02:33:58 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E9C816A412 for ; Thu, 16 Nov 2006 02:33:58 +0000 (UTC) (envelope-from pokui@psg.com) Received: from mail.trueafrican.com (mail.trueafrican.com [212.88.98.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DBE043D4C for ; Thu, 16 Nov 2006 02:33:56 +0000 (GMT) (envelope-from pokui@psg.com) Received: from mail.trueafrican.com ([127.0.0.1]) by localhost (mail.trueafrican.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06883-03 for ; Thu, 16 Nov 2006 05:33:49 +0300 (EAT) Received: from andromeda.trueafrican.com (pokui.trueafrican.com [169.254.0.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.trueafrican.com (Postfix) with ESMTP id C41AB25F1A3 for ; Thu, 16 Nov 2006 05:33:49 +0300 (EAT) Received: from [127.0.0.1] (helo=localhost) by andromeda.trueafrican.com with esmtp (Exim 4.62) (envelope-from ) id 1GkX5Q-0002Qu-SH; Thu, 16 Nov 2006 05:34:44 +0300 From: Patrick Okui To: Kris Kennaway Date: Thu, 16 Nov 2006 05:34:44 +0300 User-Agent: KMail/1.8 References: <200611160506.17630.pokui@psg.com> <20061116022211.GA36855@xor.obsecurity.org> In-Reply-To: <20061116022211.GA36855@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611160534.44263.pokui@psg.com> X-Virus-Scanned: by amavisd-new at trueafrican.com Cc: freebsd-stable@freebsd.org Subject: Re: kernel build on RELENG_6 (as of 15:00 GMT on 16.November.2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 02:33:58 -0000 On Thursday 16 November 2006 05:22, Kris Kennaway wrote: > On Thu, Nov 16, 2006 at 05:06:16AM +0300, Patrick Okui wrote: > > Fails with something along the lines of.. > > > > ...In function `ASR_failActiveCommands': > > /usr/src/sys/dev/asr/asr.c:840: error: `bcb' undeclared (first use in > > this function) > > /usr/src/sys/dev/asr/asr.c:840: error: (Each undeclared identifie .... > > > > changing bcb to ccb on that line fixes that... then later.. > > > > In file included from /usr/src/sys/kern/sched_4bsd.c:1390: > > /usr/src/sys/kern/kern_switch.c: In function `runq_choose': > > /usr/src/sys/kern/kern_switch.c:871: error: stray '\8' in program > > *** Error code 1 > > > > Replacing the ^H at the beginning of the file with a tab fixes that.. > > (funny enough, just deleting the charcter with 'x' in vi didn't work, I > > had to 'dd' the line and retype it out ... makes me wonder what editor > > was used to put that character there in the first place.) > > > > I'm guessing a committer has already caught this and fixed... but thought > > I'd post just in case someone hits the same bugs. > > You have bad RAM. Interesting... the bad RAM would cause cvsup to write a 'b' rather than a 'c' as well as insert that funky character? ** goes off to run memtest ** > > Kris -- patrick From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 02:38:28 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 096BD16A412 for ; Thu, 16 Nov 2006 02:38:28 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06F0543D69 for ; Thu, 16 Nov 2006 02:38:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id E28F81A3C19; Wed, 15 Nov 2006 18:38:23 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3EC6A51D0C; Wed, 15 Nov 2006 21:38:12 -0500 (EST) Date: Wed, 15 Nov 2006 21:38:12 -0500 From: Kris Kennaway To: Patrick Okui Message-ID: <20061116023812.GA37110@xor.obsecurity.org> References: <200611160506.17630.pokui@psg.com> <20061116022211.GA36855@xor.obsecurity.org> <200611160534.44263.pokui@psg.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <200611160534.44263.pokui@psg.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, Kris Kennaway Subject: Re: kernel build on RELENG_6 (as of 15:00 GMT on 16.November.2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 02:38:28 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 05:34:44AM +0300, Patrick Okui wrote: > On Thursday 16 November 2006 05:22, Kris Kennaway wrote: > > On Thu, Nov 16, 2006 at 05:06:16AM +0300, Patrick Okui wrote: > > > Fails with something along the lines of.. > > > > > > ...In function `ASR_failActiveCommands': > > > /usr/src/sys/dev/asr/asr.c:840: error: `bcb' undeclared (first use in > > > this function) > > > /usr/src/sys/dev/asr/asr.c:840: error: (Each undeclared identifie .... > > > > > > changing bcb to ccb on that line fixes that... then later.. > > > > > > In file included from /usr/src/sys/kern/sched_4bsd.c:1390: > > > /usr/src/sys/kern/kern_switch.c: In function `runq_choose': > > > /usr/src/sys/kern/kern_switch.c:871: error: stray '\8' in program > > > *** Error code 1 > > > > > > Replacing the ^H at the beginning of the file with a tab fixes that.. > > > (funny enough, just deleting the charcter with 'x' in vi didn't work,= I > > > had to 'dd' the line and retype it out ... makes me wonder what editor > > > was used to put that character there in the first place.) > > > > > > I'm guessing a committer has already caught this and fixed... but tho= ught > > > I'd post just in case someone hits the same bugs. > > > > You have bad RAM. >=20 > Interesting... the bad RAM would cause cvsup to write a 'b' rather than a= 'c'=20 > as well as insert that funky character?=20 Yep, they're both single bit flips. Kris --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFW88TWry0BWjoQKURAp8hAKDvAs0QB/Zw35J9dVHufigZVzKzMACgz5GY BNY1JU1+auo2cpZxd1vkgXc= =bxwb -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 02:47:48 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2456416A415 for ; Thu, 16 Nov 2006 02:47:48 +0000 (UTC) (envelope-from pokui@psg.com) Received: from mail.trueafrican.com (mail.trueafrican.com [212.88.98.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41E7843D53 for ; Thu, 16 Nov 2006 02:47:39 +0000 (GMT) (envelope-from pokui@psg.com) Received: from mail.trueafrican.com ([127.0.0.1]) by localhost (mail.trueafrican.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06472-07 for ; Thu, 16 Nov 2006 05:47:32 +0300 (EAT) Received: from andromeda.trueafrican.com (pokui.trueafrican.com [169.254.0.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.trueafrican.com (Postfix) with ESMTP id 21EB825F1A3 for ; Thu, 16 Nov 2006 05:47:32 +0300 (EAT) Received: from [127.0.0.1] (helo=localhost) by andromeda.trueafrican.com with esmtp (Exim 4.62) (envelope-from ) id 1GkXIl-0002Sw-Iy; Thu, 16 Nov 2006 05:48:31 +0300 From: Patrick Okui To: Kris Kennaway Date: Thu, 16 Nov 2006 05:48:30 +0300 User-Agent: KMail/1.8 References: <200611160506.17630.pokui@psg.com> <200611160534.44263.pokui@psg.com> <20061116023812.GA37110@xor.obsecurity.org> In-Reply-To: <20061116023812.GA37110@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611160548.30908.pokui@psg.com> X-Virus-Scanned: by amavisd-new at trueafrican.com Cc: freebsd-stable@freebsd.org Subject: Re: kernel build on RELENG_6 (as of 15:00 GMT on 16.November.2006) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 02:47:48 -0000 On Thursday 16 November 2006 05:38, Kris Kennaway wrote: > > Interesting... the bad RAM would cause cvsup to write a 'b' rather than a > > 'c' as well as insert that funky character? > > Yep, they're both single bit flips. I see. Well, thanks. Memtest should catch it (I hope) so I can complain to the providers of the dedicated server. cheers. Patrick. -- patrick From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 02:53:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC82916A403 for ; Thu, 16 Nov 2006 02:53:53 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70F7F43D46 for ; Thu, 16 Nov 2006 02:53:53 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.200] ([10.0.0.200]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kAG2rpVd014912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Nov 2006 18:53:53 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <455BD2BF.3050802@errno.com> Date: Wed, 15 Nov 2006 18:53:51 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Lamont Granquist References: <45578B48.1090704@errno.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ath0 issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 02:53:53 -0000 Lamont Granquist wrote: > > > On Sun, 12 Nov 2006, Sam Leffler wrote: >> If tx stops in ap mode you need to figure out whether the h/w tx q is >> stalled or something else "above" is blocking outbound traffic. The >> usual things to check are: >> >> 1. are there resources in the driver to send a packet (e.g. buffers on >> the queue); if the tx q is full then the OACTIVE bit will be marked on >> the interface and visible with ifconfig > > during one of the period where tx was blocking i got ifconfigs that > looked like: > > ath0: flags=8843 mtu 1500 > inet 192.168.70.1 netmask 0xffffff00 broadcast 192.168.70.255 > ether 00:09:5b:c8:78:9c > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c > authmode OPEN privacy OFF txpowmax 30 bmiss 7 protmode CTS burst > dtimperiod 1 bintval 100 > > ath0: flags=8843 mtu 1500 > inet 192.168.70.1 netmask 0xffffff00 broadcast 192.168.70.255 > ether 00:09:5b:c8:78:9c > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c > authmode OPEN privacy OFF txpowmax 30 bmiss 7 protmode CTS burst > dtimperiod 1 bintval 100 > >> 2. if packets are queued to the h/w and not going out then you need to >> identify whether a higher priority frame is blocking them; this is >> harder but can occur when something like a beacon frame fails to go out >> or if there is cabq traffic q'd up behind the beacon frame that doesn't >> make it out >> 3. if none of the above is blocking traffic then h/w may consider the >> media busy; this can happen if your ap is operating in a busy >> environment and things like protection are being used heavily, or if you >> have an overlapping BSS that is operating in 11b > > i'm not certain how to go about collecting that information, but this is > a very lightly used wireless network with only the freebsd box and the > windows machine participating and the traffic is limited to the ssh > sessions that i setup and the usual windoze and dhcp chatter... > >> Often problems such as this are most easily understood by sniffing >> traffic from another station and looking for traffic patterns coincident >> with the event on the ap. > > i've only got the two wireless points right now, so i can't get a third > machine up to sniff... > >> More useful information can be found in the >> statistics collected by the driver (use athstats). > > here's a before and after of athstats which brackets one of these events: > > warez# ./athstats > 2243 data frames received > 2925 data frames transmit > 50 tx frames with an alternate rate > 947 long on-chip tx retries > 115 tx failed 'cuz too many retries > 2M current transmit rate > 982 tx management frames > 6 tx frames discarded prior to association > 242 tx frames with no ack marked > 2828 tx frames with short preamble > 2439 rx failed 'cuz of bad CRC > 28137 rx failed 'cuz of PHY err > 19620 OFDM timing > 8517 CCK timing > 150622 beacons transmitted > 534 periodic calibrations > 16 rssi of last ack > 19 avg recv rssi > -96 rx noise floor > 1 cabq frames transmitted > 33 switched default/rx antenna > Antenna profile: > [1] tx 1862 rx 6345 > [2] tx 1927 rx 6371 > warez# ./athstats > 2252 data frames received > 2937 data frames transmit > 50 tx frames with an alternate rate > 947 long on-chip tx retries > 115 tx failed 'cuz too many retries > 2M current transmit rate > 982 tx management frames > 6 tx frames discarded prior to association > 242 tx frames with no ack marked > 2840 tx frames with short preamble > 2440 rx failed 'cuz of bad CRC > 28145 rx failed 'cuz of PHY err > 19623 OFDM timing > 8522 CCK timing > 150659 beacons transmitted > 535 periodic calibrations > 22 rssi of last ack > 22 avg recv rssi > -96 rx noise floor > 1 cabq frames transmitted > 33 switched default/rx antenna > Antenna profile: > [1] tx 1874 rx 6371 > [2] tx 1927 rx 6371 > > Snapshots are rarely useful; try running athstats 1 and correlate what you see with pauses. Another possible reason for deferred operation is something else in the system blocking the taskq threads; that's a bit trickier to diagnose. Sam From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 06:30:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 770B316A40F for ; Thu, 16 Nov 2006 06:30:45 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from bart.milos.co.za (bart.milos.co.za [196.38.18.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1842143D45 for ; Thu, 16 Nov 2006 06:30:42 +0000 (GMT) (envelope-from clay@milos.co.za) Received: (qmail 79661 invoked by uid 89); 16 Nov 2006 06:30:40 -0000 Received: from unknown (HELO claylaptop) (clay@milos.za.net@192.168.3.150) by bart.milos.co.za with SMTP; 16 Nov 2006 06:30:40 -0000 Message-ID: <01fe01c70948$aeecac70$9603a8c0@claylaptop> From: "Clayton Milos" To: "Atanas" , "Mark Dotson" References: <455A1DEA.20304@asd.aplus.net> <455A32B7.9080304@dmglobal.net> <455BC7F0.8080203@asd.aplus.net> Date: Thu, 16 Nov 2006 08:30:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: freebsd-stable@freebsd.org Subject: Re: twa: Passthru request timed out! Resetting controller... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 06:30:45 -0000 ----- Original Message ----- From: "Atanas" To: "Mark Dotson" Cc: Sent: Thursday, November 16, 2006 4:07 AM Subject: Re: twa: Passthru request timed out! Resetting controller... > Mark Dotson said the following on 11/14/06 1:18 PM: >> I've had continued problems with the 3ware series SATA cards and the Tyan >> boards. Specifically, I have a "Tyan S5360-1U" and both a 9500S-4LP and >> a 8506 series 3ware cards. >> >> In my case the first error is different, but the 'resetting' over and >> over is VERY familiar. This could be triggered by a simple file copy >> from one part of a container to another; degrading the unit and >> triggering the resetting crap. Note that the drives are fine, I tested >> that first thing. >> >> Sep 8 11:59:23 localhost kernel: 3w-9xxx: scsi0: WARNING: (0x06:0x002C): >> Unit #1: Command (0x2a) timed out, resetting card. >> Sep 8 11:59:41 localhost kernel: 3w-9xxx: scsi0: AEN: INFO >> (0x04:0x005E): >> Cache synchronized after power fail:unit=0. >> Sep 8 11:59:41 localhost kernel: 3w-9xxx: scsi0: AEN: INFO >> (0x04:0x005E): >> Cache synchronized after power fail:unit=1. >> >> I also found this problem to exist across platforms, not just FreeBSD. >> For example, the excerpt above is from a CentOS box. >> >> All tests were done with newest firmware for both card and mobo, and >> using the newest drivers provided by 3ware. >> >> Once I removed the card and drives from the Tyan system and stuck them in >> pretty much ANY other system, they worked fantastically. >> >> I don't have an answer for the "resetting problem" as of yet... 3ware and >> Tyan (And my system vendor "Appro") are still trying to find my specific >> problem and solve it. I believe they are currently doing the "replace >> everything" method of troubleshooting. >> > Mark, thank you. > > It's good to know that the resetting problem exist on other platforms too. > > We already found out that replacing the entire box with identical one > doesn't help, so unfortunately we'll have to start replacing components by > using different brands or models. > > I wouldn't like to touch the I/O subsystem (these are already loaded > production machines), so like you said, the safest bet would be to try > another motherboard. > > However I don't see many Dual Opteron based boards suggested by the > 3ware's compatibility list. The next one that comes in mind from that list > is Supermicro H8DC8, but it looks more like a gamers dream (High-End PCI-e > Graphics, SLI, etc. but no on-board VGA) than a server board. > > I'm quite surprised that the top Opteron based motherboard manufacturer > listed in the 3ware web site motherboard compatibility docs: > http://3ware.com/products/pdf/Motherboard_compatibility_list_9550SX_2006_06.pdf > makes 2 out of 5 boards that are marked as compatible, but perform so bad > with 3ware cards. > > I know what happens here in this mailing list when somebody looks for good > SATA cards (Re: 3ware, 3ware, ...), I replied myself too. > > So are there any success stories with 3ware 9550SX (SATA II) and dual AMD > Opteron server boards, or it's time to go back with Intel? > > Regards, > Atanas It's time to go with another SATA2 raid controller card. I have an Areca 8 port PCI-X cotroller card (www.areca.com.tw). Running it on a Tyan Thunder motherboard with dual AthlonMP and I've had no issues with it yet. I've got 8 drives on it in 2 volumes of 4 drives each. I'm getting what I consider to be good read/write speeds to the array. It also supports many things that 3ware did not at the time I bought it like online volume expansion. homer# dd if=/dev/zero of=test.file bs=65536 count=16384 16384+0 records in 16384+0 records out 1073741824 bytes transferred in 7.000588 secs (153378801 bytes/sec) -Clay > > >> Atanas wrote: >>> Has anyone experiencing this: >>> >>> twa0: ERROR: (0x05: 0x2018): Passthru request timed out!: request = >>> 0xca839d20 >>> twa0: INFO: (0x16: 0x1108): Resetting controller...: >>> twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=0 >>> ... >>> twa0: INFO: (0x04: 0x005E): Cache synchronization completed: unit=7 >>> twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=1 >>> twa0: INFO: (0x16: 0x1107): Controller reset done!: >>> >>> This happens on 6.2-PRERELEASE i386 (and on 6.1 since its release) on a >>> number of machines with the following hardware configuration: >>> >>> - Tyan K8SE 2892, 2 AMD Opteron 270 CPUs, 4GB RAM >>> - 3ware 9550SX-8LP, 8 500GB Seagate ST3500641AS SATA drives >>> (configured as 8 SINGLE DISK units, aka JBOD) >>> >>> All hardware components, including the server chassis, are listed in the >>> 3ware hardware compatibility lists. It doesn't seem to be a cabling or >>> power issue. The controller and hard drives are already flashed to the >>> latest firmware revisions. I tried turning off NCQ, but it didn't make >>> any difference. I tried also switching the kernel from PAE to non-PAE >>> (reducing the usable memory to 3GB), but it didn't help either. >>> >>> I have another machines with similar I/O configurations (3ware), but >>> with Intel motherboards and running FreeBSD-5.5, and these run fine for >>> about a year already. Now I'm thinking about swapping the drives between >>> a working Intel and AMD based box, to see where controller timeouts will >>> follow. >>> >>> The problem happens sporadically once in a month or so and is very hard >>> to reproduce. Sometimes it takes several weeks until the next crash >>> happens, sometimes it crashes again in just a few hours. >>> >>> When the thing happens, the kernel sometimes panics (most likely due to >>> the inconsistent filesystem state caused by the controller reset), >>> sometimes just hangs. It can be interrupted (I have a serial console), >>> but the only usable thing after that seems to be "call cpu_reset()", >>> followed by full (and sometimes painfully long) filesystem check. >>> >>> Here are the diffs against the default GENERIC and PAE kernel >>> configurations: >>> >>> < cpu I486_CPU >>> < ident GENERIC >>> < options INET6 # IPv6 communications protocols >>> < options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI >>> >>> > options QUOTA >>> > options SMP # Symmetric MultiProcessor Kernel >>> > options BREAK_TO_DEBUGGER >>> > options DDB >>> > options KDB >>> > options KDB_UNATTENDED >>> >>> > options IPFIREWALL >>> > options DUMMYNET >>> >>> I'm attaching the dmesg.boot following the latest crash. >>> >>> Regards, >>> Atanas >>> > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 08:23:59 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB3F216A416 for ; Thu, 16 Nov 2006 08:23:59 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx0.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E0243D86 for ; Thu, 16 Nov 2006 08:23:49 +0000 (GMT) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx0.rink.nu (Postfix) with ESMTP id 488A61704A for ; Thu, 16 Nov 2006 09:24:13 +0100 (CET) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx0.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIWK56blDQg5 for ; Thu, 16 Nov 2006 09:24:07 +0100 (CET) Received: by mx0.rink.nu (Postfix, from userid 1000) id 32D9817048; Thu, 16 Nov 2006 09:24:07 +0100 (CET) Date: Thu, 16 Nov 2006 09:24:07 +0100 From: Rink Springer To: stable@FreeBSD.org Message-ID: <20061116082407.GB33390@rink.nu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="WhfpMioaduB5tiZL" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: panic(): vinvalbuf: dirty bufs: perhaps a ffs_syncvnode bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 08:23:59 -0000 --WhfpMioaduB5tiZL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi people, At work, some storage is put on a SUN StorEdge 3510 FibreChannel array; the disks are divided into two volumes, which are mounted using isp(4) controllers. Two seperate machines each mount a single volume (this is, box1 mounts the first volume (/dev/da1), and box2 mounts the second volume (/dev/da2)). Both volumes are formatted using UFS2. Over the night, we reset the shelf in order to activate its new management IP address, causing the /dev/da[12] devices to be temporarily unavailable. This resulted in the following panic on the rather busy mailstorage server (the other server has minor load and was fine): --- (da0:isp0:0:1:0): lost device (da0:isp0:0:1:0): removing device entry (da1:isp0:0:2:0): lost device g_vfs_done():da1s1[WRITE(offset=3D292316823552, length=3D16384)]error =3D 6 g_vfs_done():da1s1[WRITE(offset=3D240287318016, length=3D16384)]error =3D 6 g_vfs_done():da1s1[READ(offset=3D12175362048, length=3D2048)]error =3D 6 g_vfs_done():da1s1[WRITE(offset=3D240287318016, length=3D16384)]error =3D 6 g_vfs_done():da1s1[READ(offset=3D18370689024, length=3D2048)]error =3D 6 g_vfs_done():da1s1[READ(offset=3D25829486592, length=3D512)]error =3D 6 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 78035 (lmtpd) g_vfs_done():da1s1[WRITE(offset=3D240287318016, length=3D1638(da1:isp0:0:2:0): Invalidating pack 4)]error =3D 6 g_vfs_done():da1s1[READ(offset=3D13768671232, length=3D6144)]error =3D 6 g_vfs_done():da1s1[READ(offset=3D102126977024, length=3D16384)]error =3D 6 g_vfs_done():da1s1[READ(offset=3D13768671232, length=3D6144)]error =3D 6 g_vfs_dpone():da1s1[READ(offset=3D102319669248, length=3D16384)]error =3D 6a nic: vinvalbuf: dirty bufs cpuid =3D 2 Uptime: 54d15h48m38s kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x56 fault code =3D supervisor read, page not present instruction pointer =3D 0x20:0xc0681303 stack pointer =3D 0x28:0xe8d973f0 frame pointer =3D 0x28:0xe8d973f8 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 78066 (lmtpd) trap number =3D 12 --- When looking at the source code of vinvalbuf(), which calls bufobj_invalbuf(), it seems that this panic is raised after a bufobj still contains dirty data after waiting for it to complete without error. The code can be found at /sys/kern/vfs_subr.c The sync routine called eventually translates to bufsync(), as in /sys/kern/vfs_bio.c, which calls the filesystem's sync routine. It seems as if the return status of vfs_bio_awrite() in ffs_syncvnode() is not checked; all the other parts are checked. I believe this could provoke this panic. As the machine is in production use, it was instantly rebooted by a collegue and thus I have no vmcore, backtrace or anything. I therefore hope the information provided here is adequate. Can someone with more FreeBSD-VFS knowledge please look at this? Thanks! --=20 Rink P.W. Springer - http://rink.nu "It's you isn't it? THE BASTARD OPERATOR FROM HELL!" "In the flesh, on the phone and in your account..." - BOFH #3 --WhfpMioaduB5tiZL Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIJawYJKoZIhvcNAQcCoIIJXDCCCVgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BuIwggObMIIDBKADAgECAhAiuN7bs9pg6t3I0n6G5OOTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjExMDgwOTI2 NTNaFw0wNzExMDgwOTI2NTNaMIHSMREwDwYDVQQEEwhTcHJpbmdlcjEaMBgGA1UEKhMRUmlu ayBQZXRlciBXeWNoZXIxIzAhBgNVBAMTGlJpbmsgUGV0ZXIgV3ljaGVyIFNwcmluZ2VyMRsw GQYJKoZIhvcNAQkBFgxtYWlsQHJpbmsubnUxHzAdBgkqhkiG9w0BCQEWEHJpbmtAZnJlZWJz ZC5vcmcxIDAeBgkqhkiG9w0BCQEWEXJpbmtAaWwuZm9udHlzLm5sMRwwGgYJKoZIhvcNAQkB Fg1yaW5rQHN0YWNrLm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxryGDfel YzzENX7wodkbVY1NALfaiPfNEG10YjD8ZWdK9zkN26Tc878Shbqapq0KYFD8TACGfEhKoMvo qbf0PHAS/gNYr81Arqa9FRPUfzvtDE/cMbhvI+p7ufBITyYnPJp9MUD72iT+DohRR2ISVi3i NAEgDuSbYYNxctnvXqU6O6EPy3mzoFPDoiOQwBfVtFrjxBbND9BUK2bjtUyGt4x8I/Vulzrt qLPTokva+b97DHRgbCA/aLLYIrU6QoqOFJ8GrAbro/FZLYh4m1oJk3FEHVQOKkk7xzIaFmmP QGJRL8m6nrIZFTrQ+X2wmzfLD55K/UiqbekOuMiWbY9EbwIDAQABo10wWzBLBgNVHREERDBC gQxtYWlsQHJpbmsubnWBEHJpbmtAZnJlZWJzZC5vcmeBEXJpbmtAaWwuZm9udHlzLm5sgQ1y aW5rQHN0YWNrLm5sMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAIfIcieRjePBA wjZqvOdGpyPcNDnK/ubeQSTV5Y4AHWxm1sXhQxB/XrQ3RVdz1qDnBRL1AjkEBAl8e9+am4s6 D6TaSlmJeNXn6ZPJTQecisz3M+AKiMckShM3oAeUi0ktn1yNYR+hz5aQN612XT5OZRYznJVZ kPf1DiA2RVVyz+MwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQG EwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNV BAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAw WhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBly YLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJo dHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNV HQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3 h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYICUTCCAk0CAQEwdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECECK43tuz2mDq3cjS fobk45MwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNjExMTYwODI0MDdaMCMGCSqGSIb3DQEJBDEWBBRewA9C3M92zy2bRIS43D7O D/28ijBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBH f1APZmbLSbY065tajDFmsa+KQsuhuHTrnB7hN30hAE7+MksX14re4clUN6C8M1idQAVuWUET KQdkW5ogy1Irk1yYoUuOZJBB42yyxMdfcuizuwgKtf8BFkQJfxYwoszyE0mFMydtHf3QrYRt cVyeYwhw/GAO/tmgojm/swM2geurS/j2EDVoEBojemLYy/9z8xKjtQGFnqLUwRarOoAVjO9p EZPv5SpEFW4A95BLTdniWnUdKS9Kw+SzesVpMfv2w1EQdp41lRLf96cNQGGtSVSN6but6bYh Ai2rDzZQ8r3t9KhnJqJiMU6hLiF05JsKA2S9PTaMNi1T3qr3EEkV --WhfpMioaduB5tiZL-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 09:00:23 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF85D16A40F for ; Thu, 16 Nov 2006 09:00:23 +0000 (UTC) (envelope-from dkirhlarov@oilspace.com) Received: from office.oilspace.com (office.oilspace.com [194.129.65.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id A42A643D6E for ; Thu, 16 Nov 2006 09:00:17 +0000 (GMT) (envelope-from dkirhlarov@oilspace.com) Received: from dimma (proxy-mow.oilspace.com [81.222.156.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.oilspace.com (Postfix) with ESMTP id 211B217A9D5 for ; Thu, 16 Nov 2006 09:00:16 +0000 (GMT) Received: from dimma (localhost [127.0.0.1]) by dimma (8.13.8/8.13.8) with ESMTP id kAG90F0M002510 for ; Thu, 16 Nov 2006 12:00:15 +0300 (MSK) (envelope-from dkirhlarov@dimma) Received: (from dkirhlarov@localhost) by dimma (8.13.8/8.13.8/Submit) id kAG90FRa002509 for freebsd-stable@freebsd.org; Thu, 16 Nov 2006 12:00:15 +0300 (MSK) (envelope-from dkirhlarov) Date: Thu, 16 Nov 2006 12:00:15 +0300 From: Dmitriy Kirhlarov To: freebsd-stable@freebsd.org Message-ID: <20061116090014.GB1132@dimma.mow.oilspace.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <20061113084430.GE59604@dimma.mow.oilspace.com> <20061113184505.GA51659@xor.obsecurity.org> <20061114075020.GA1154@dimma.mow.oilspace.com> <20061114185344.GA89030@xor.obsecurity.org> <20061115182420.GA1132@dimma.mow.oilspace.com> <20061115203740.GA31455@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061115203740.GA31455@xor.obsecurity.org> X-Mailer: Mutt-ng devel (2005-03-13) based on Mutt 1.5.9 X-Operating-System: FreeBSD 6.2-PRERELEASE User-Agent: mutt-ng/devel-r804 (FreeBSD) Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 09:00:23 -0000 On Wed, Nov 15, 2006 at 03:37:40PM -0500, Kris Kennaway wrote: > On Wed, Nov 15, 2006 at 09:24:21PM +0300, Dmitriy Kirhlarov wrote: > > On Tue, Nov 14, 2006 at 01:53:45PM -0500, Kris Kennaway wrote: > > > > > From alc@: > > > > > > --- > > > I've never seen anything like this before. UMA is failing to allocate > > > the zone structure. This is unrelated to the large-swap scenario that > > > you ran into. Ask him to uncomment all of the UMA debugging #define's > > > at the start of uma_core.c. > > > > It was very painfull for me and I don't get result... > > > > #define UMA_DEBUG 1 > > #define UMA_DEBUG_ALLOC 1 > > #define UMA_DEBUG_ALLOC_1 1 > > > > in uma_core.c kill my machine. > > I get tons of crap to serial console. > > The "tons of crap" is what was necessary to proceed. Not shure. I can't find way for collect output of UMA_DEBUG* with current console server and it can't be replaced before Jan. But I think UMA* is a wrong idea. You suppose bad hardware (I'm right?). Possible. But it can be detected only under heavy load -- when I enabling nagios on this server. When nagios disabled, machine work perfectly. With enabled UMA_DEBUG* options server not operable, no one service starting, we don't have this load and can't reproduce this behaviour. WBR Dmitriy From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 09:10:35 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62A2916A4B3 for ; Thu, 16 Nov 2006 09:10:35 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from arwen.teledomenet.gr (arwen.teledomenet.gr [213.142.128.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC03E43DEF for ; Thu, 16 Nov 2006 09:10:07 +0000 (GMT) (envelope-from nvass@teledomenet.gr) Received: from iris ([192.168.1.71]) by arwen.teledomenet.gr (8.12.10/8.12.10) with ESMTP id kAG9A3m1029649 for ; Thu, 16 Nov 2006 11:10:03 +0200 From: Nikos Vassiliadis To: stable@freebsd.org Date: Thu, 16 Nov 2006 11:09:02 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200611161109.02430.nvass@teledomenet.gr> Cc: Subject: trussing a non existing file causes misbehavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 09:10:35 -0000 Hello, In my 6.2-PRERELEASE(one month old approximately) truss gets stuck exiting when trying to truss a non existing file. I think the problem is not in truss itself. But I have not the skills to find it. So, will a build with updated sources help? Is there anybody else with the same problem? nik:0:~$ truss /nothing truss: execvp /nothing: No such file or directory load: 1.04 cmd: truss 70662 [exithold] 0.00u 0.00s 0% 700k Thanks in advance, Nikos From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 09:27:42 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76D5F16A412 for ; Thu, 16 Nov 2006 09:27:42 +0000 (UTC) (envelope-from perl@ipchains.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53AE443D68 for ; Thu, 16 Nov 2006 09:27:40 +0000 (GMT) (envelope-from perl@ipchains.ru) Received: from [80.68.244.38] (account odambaev@rbc.ru [80.68.244.38] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.10) with ESMTPA id 146440153; Thu, 16 Nov 2006 12:27:36 +0300 Message-ID: <455C2EC8.7030107@ipchains.ru> Date: Thu, 16 Nov 2006 12:26:32 +0300 From: Oleg Dambaev User-Agent: Thunderbird 1.5.0.5 (X11/20060831) MIME-Version: 1.0 To: Nikos Vassiliadis References: <200611161109.02430.nvass@teledomenet.gr> In-Reply-To: <200611161109.02430.nvass@teledomenet.gr> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: trussing a non existing file causes misbehavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 09:27:42 -0000 Nikos Vassiliadis wrote: > Hello, > > In my 6.2-PRERELEASE(one month old approximately) truss gets stuck exiting > when trying to truss a non existing file. I think the problem is not in truss itself. > But I have not the skills to find it. So, will a build with updated sources help? > Is there anybody else with the same problem? > > nik:0:~$ truss /nothing > truss: execvp /nothing: No such file or directory > load: 1.04 cmd: truss 70662 [exithold] 0.00u 0.00s 0% 700k > > Thanks in advance, Nikos > Never seen any dumbest thing. Re-read truss(1) man page and find out what truss must do. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 10:20:49 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7090316A407 for ; Thu, 16 Nov 2006 10:20:49 +0000 (UTC) (envelope-from ah@crypta.net) Received: from mail.crypta.net (mail.crypta.net [83.136.131.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C37D43D55 for ; Thu, 16 Nov 2006 10:20:48 +0000 (GMT) (envelope-from ah@crypta.net) Received: by mail.crypta.net (cryptobank/eProtect-smtpd, from userid 1001) id A90EFECD54B; Thu, 16 Nov 2006 11:20:47 +0100 (CET) Date: Thu, 16 Nov 2006 11:20:47 +0100 From: Andy Hilker To: freebsd-stable@freebsd.org Message-ID: <20061116102047.GA58134@mail.crypta.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-PGP-Key: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEC6E1071 Subject: misc/amanda-server: amfetchdump segmentation fault X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 10:20:49 -0000 Hi, Since 2.5.1p1,1 the amfetchdump utility does not work anymore: -- snap -- $ amfetchdump -a -c CONFIG HOST da0s1e 20061108 1 Scanning /home/amanda/hold... 1 tape(s) needed for restoration sh: segmentation fault (core dumped) amfetchdump -a -c CONFIG HOST da0s1e 20061108 1 -- snap -- With strings on the .core file I have found: Shared object "nss_dns.so.1" not found, required by "amfetchdump" This "nss_dns.so.1" seems to be related to FreeBSD specific patches which other ports needed in the past... (google result). But I am not sure if this is the reason for the segmentation fault. Is there anybody out where amfetchdump works in 2.5.1p1,1? Or any other idea? I can supply more information as needed. Regards, Andy From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 10:24:39 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BFAD16A403 for ; Thu, 16 Nov 2006 10:24:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F2DA43D58 for ; Thu, 16 Nov 2006 10:24:38 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id kAGAOaBO093724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Nov 2006 13:24:37 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id kAGAOaYj093723 for stable@freebsd.org; Thu, 16 Nov 2006 13:24:36 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 16 Nov 2006 13:24:36 +0300 From: Gleb Smirnoff To: stable@FreeBSD.org Message-ID: <20061116102436.GN32700@FreeBSD.org> References: <20061113084430.GE59604@dimma.mow.oilspace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20061113084430.GE59604@dimma.mow.oilspace.com> User-Agent: Mutt/1.5.6i Cc: Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 10:24:39 -0000 I wonder why UMA was suspected to be the problem. Dima gave me access to the core. Here are more details from the trace: Unread portion of the kernel message buffer: panic: thread 100147(nagios):1 holds process lock but isn't blocked on a lock #9 0xd060038e in panic (fmt=0xd08094d9 "thread %d(%s):%d holds %s but isn't blocked on a lock\n") at /usr/src/sys/kern/kern_shutdown.c:549 #10 0xd0629228 in propagate_priority (td=0xd745c900) at /usr/src/sys/kern/subr_turnstile.c:239 #11 0xd0629f32 in turnstile_wait (lock=0xd5dd5498, owner=0xd745c900) at /usr/src/sys/kern/subr_turnstile.c:643 #12 0xd05f4fc1 in _mtx_lock_sleep (m=0xd5dd5498, tid=3583683968, opts=0, file=0x12
, line=18) at /usr/src/sys/kern/kern_mutex.c:579 #13 0xd05f4992 in _mtx_lock_flags (m=0xd5dd5498, opts=0, file=0xd0806c3d "/usr/src/sys/kern/kern_thread.c", line=824) at /usr/src/sys/kern/kern_mutex.c:288 #14 0xd060d340 in thread_single (mode=0) at /usr/src/sys/kern/kern_thread.c:824 #15 0xd05e38b9 in fork1 (td=0xd59aad80, flags=20, pages=0, procp=0xf5cacccc) at /usr/src/sys/kern/kern_fork.c:274 #16 0xd05e3509 in fork (td=0xd59aad80, uap=0xf5cacd04) at /usr/src/sys/kern/kern_fork.c:98 #17 0xd07a6d10 in syscall (frame= {tf_fs = 134938683, tf_es = 59, tf_ds = -809566149, tf_edi = 134953856, tf_esi = 673312612, tf_ebp = -809526568, tf_isp = -171258524, tf_ebx = 672261300, tf_edx = 0, tf_ecx = 134963456, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 672684403, tf_cs = 51, tf_eflags = 642, tf_esp = -809526660, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 #18 0xd078f38f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 10 #10 0xd0629228 in propagate_priority (td=0xd745c900) at /usr/src/sys/kern/subr_turnstile.c:239 239 KASSERT(TD_ON_LOCK(td), ( (kgdb) list 234 #endif 235 236 /* 237 * If we aren't blocked on a lock, we should be. 238 */ 239 KASSERT(TD_ON_LOCK(td), ( 240 "thread %d(%s):%d holds %s but isn't blocked on a lock\n", 241 td->td_tid, td->td_proc->p_comm, td->td_state, 242 ts->ts_lockobj->lo_name)); 243 (kgdb) frame 14 #14 0xd060d340 in thread_single (mode=0) at /usr/src/sys/kern/kern_thread.c:824 824 PROC_LOCK(p); (kgdb) list 819 thread_stopped(p); 820 thread_suspend_one(td); 821 PROC_UNLOCK(p); 822 mi_switch(SW_VOL, NULL); 823 mtx_unlock_spin(&sched_lock); 824 PROC_LOCK(p); 825 mtx_lock_spin(&sched_lock); 826 if (mode == SINGLE_EXIT) 827 remaining = p->p_numthreads; 828 else if (mode == SINGLE_BOUNDARY) -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 10:55:16 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 813D116A4D1 for ; Thu, 16 Nov 2006 10:55:16 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1C3E43D6D for ; Thu, 16 Nov 2006 10:55:10 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so582565nfc for ; Thu, 16 Nov 2006 02:55:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=d9CsgFZU+sXHNQqxHv47turyvFmilUgNHCyYfUP+fZm5sDfkX7B1DJRGkw/XR41ApWAoXXn/mpD9oq0/GRaAtITrrLuglfGbUrf03tcjvbtiigWJUxK4pzxpHTc3S1dVYui52C1B0lyBfcozEAyWEttCWU2fKRMfm3+Ptg3l8oA= Received: by 10.78.81.20 with SMTP id e20mr424977hub.1163674509265; Thu, 16 Nov 2006 02:55:09 -0800 (PST) Received: by 10.78.155.3 with HTTP; Thu, 16 Nov 2006 02:55:08 -0800 (PST) Message-ID: <7ad7ddd90611160255m553a471cy41f6c911bdc2a1bf@mail.gmail.com> Date: Thu, 16 Nov 2006 11:55:09 +0100 From: "Ulrich Spoerlein" To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: systat -vm output showing negative total virtual memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 10:55:16 -0000 Hi all, this is on a two week old RELENG_6. The machine has 4GB RAM, SMP CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3012.12-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x641d> AMD Features=0x20100000 real memory = 3489071104 (3327 MB) avail memory = 3414265856 (3256 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 1198620 115040 1480676 289860 153004 count All 3330652 116920 -956751k 293960 pages vm.vmtotal has this to say System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 3 Disk Wait: 1 Page Wait: 1 Sleep: 40) Virtual Memory: (Total: 815944K, Active 355288K) Real Memory: (Total: 2558540K Active 150424K) Shared Virtual Memory: (Total: 11460K Active: 7856K) Shared Real Memory: (Total: 6916K Active: 5044K) Free Memory Pages: 890092K Uli From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 11:15:28 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F92A16A415 for ; Thu, 16 Nov 2006 11:15:28 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED80843D55 for ; Thu, 16 Nov 2006 11:15:27 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id kAGBFPk4093984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Nov 2006 14:15:26 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id kAGBFPZc093983 for stable@freebsd.org; Thu, 16 Nov 2006 14:15:25 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 16 Nov 2006 14:15:25 +0300 From: Gleb Smirnoff To: stable@FreeBSD.org Message-ID: <20061116111525.GO32700@FreeBSD.org> References: <20061113084430.GE59604@dimma.mow.oilspace.com> <20061116102436.GN32700@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20061116102436.GN32700@FreeBSD.org> User-Agent: Mutt/1.5.6i Cc: Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 11:15:28 -0000 On Thu, Nov 16, 2006 at 01:24:36PM +0300, Gleb Smirnoff wrote: T> I wonder why UMA was suspected to be the problem. Dima gave T> me access to the core. Here are more details from the trace: It looks like a race between two threads in one process. Look here: (kgdb) frame 12 #12 0xd05f4fc1 in _mtx_lock_sleep (m=0xd5dd5498, tid=3583683968, opts=0, file=0x12
, line=18) at /usr/src/sys/kern/kern_mutex.c:579 579 turnstile_wait(&m->mtx_object, mtx_owner(m)); (kgdb) p *m $10 = {mtx_object = {lo_class = 0xd084e224, lo_name = 0xd080508c "process lock", lo_type = 0xd080508c "process lock", lo_flags = 4390912, lo_list = { tqe_next = 0xd5dd56b0, tqe_prev = 0xd5dd5290}, lo_witness = 0xd088a100}, mtx_lock = 3611674882, mtx_recurse = 0} (kgdb) p ((struct thread *)tid) $15 = (struct thread *) 0xd59aad80 (kgdb) p ((struct thread *)(m->mtx_lock & ~(0x1 | 0x2))) $17 = (struct thread *) 0xd745c900 (kgdb) p ((struct thread *)(m->mtx_lock & ~(0x1 | 0x2)))->td_proc $18 = (struct proc *) 0xd5dd5430 (kgdb) p ((struct thread *)tid)->td_proc $19 = (struct proc *) 0xd5dd5430 So, we see that one thread blocks on the lock that is held by an other thread of the same process. Here they are: * 134 Thread 100198 (PID=47872: nagios) doadump () at pcpu.h:165 133 Thread 100147 (PID=47872: nagios) sched_switch (td=0xd745c900, newtd=0xd51f7a80, flags=2) at /usr/src/sys/kern/sched_4bsd.c:980 Let's look at the second one: (kgdb) thread 133 [Switching to thread 133 (Thread 100147)]#0 sched_switch (td=0xd745c900, newtd=0xd51f7a80, flags=2) at /usr/src/sys/kern/sched_4bsd.c:980 980 sched_lock.mtx_lock = (uintptr_t)td; (kgdb) bt #0 sched_switch (td=0xd745c900, newtd=0xd51f7a80, flags=2) at /usr/src/sys/kern/sched_4bsd.c:980 #1 0xd0607f46 in mi_switch (flags=2, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:420 #2 0xd0615ecf in maybe_preempt_in_ksegrp (td=0xd59aad80) at kern_switch.c:467 #3 0xd06160c8 in setrunqueue (td=0xd59aad80, flags=0) at kern_switch.c:585 #4 0xd06151e7 in sched_wakeup (td=0xd59aad80) at /usr/src/sys/kern/sched_4bsd.c:996 #5 0xd0608025 in setrunnable (td=0xd59aad80) at /usr/src/sys/kern/kern_synch.c:483 #6 0xd060d78e in thread_unsuspend_one (td=0xd59aad80) at /usr/src/sys/kern/kern_thread.c:972 #7 0xd060d584 in thread_suspend_check (return_instead=0) at /usr/src/sys/kern/kern_thread.c:935 #8 0xd0628a88 in userret (td=0xd745c900, frame=0xf5dd4d38, oticks=1) at /usr/src/sys/kern/subr_trap.c:116 #9 0xd07a6e16 in syscall (frame= {tf_fs = 134938683, tf_es = 59, tf_ds = -809566149, tf_edi = 134997504, tf_esi = 134998528, tf_ebp = -813707944, tf_isp = -170046108, tf_ebx = 672261300, tf_edx = 0, tf_ecx = 134969072, tf_eax = 1, tf_trapno = 0, tf_err = 2, tf_eip = 672832335, tf_cs = 51, tf_eflags = 646, tf_esp = -813707972, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:1034 #10 0xd078f38f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 11:16:21 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F4AB16A501 for ; Thu, 16 Nov 2006 11:16:21 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F44D43D5C for ; Thu, 16 Nov 2006 11:16:11 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so257932nzh for ; Thu, 16 Nov 2006 03:16:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZB9tr7h/E/UAOaoGq6B18V9PwjLOlHEHE/Fa7fi7yxYAUSawaFC7/cwPjX0FqcI9Yu8PeXbQ9eofks0oFTZNPgTRbIpxDqCrtDJ1CWwhisN+ztD9AJE7YPNMa5UGl24GYD0pD6WqAhnCIL0qwacpN8559NDrZq7KaFYJQY50Bas= Received: by 10.65.237.1 with SMTP id o1mr76168qbr.1163675771192; Thu, 16 Nov 2006 03:16:11 -0800 (PST) Received: by 10.64.204.15 with HTTP; Thu, 16 Nov 2006 03:16:11 -0800 (PST) Message-ID: <84dead720611160316p76116b3fw2672823246d7b39d@mail.gmail.com> Date: Thu, 16 Nov 2006 16:46:11 +0530 From: "Joseph Koshy" To: "Nikos Vassiliadis" In-Reply-To: <200611161109.02430.nvass@teledomenet.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200611161109.02430.nvass@teledomenet.gr> Cc: stable@freebsd.org Subject: Re: trussing a non existing file causes misbehavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 11:16:21 -0000 > Is there anybody else with the same problem? > > nik:0:~$ truss /nothing > truss: execvp /nothing: No such file or directory > load: 1.04 cmd: truss 70662 [exithold] 0.00u 0.00s 0% 700k Known problem. See bin/70803. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 12:14:24 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E8DC16A412 for ; Thu, 16 Nov 2006 12:14:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ABAE43D46 for ; Thu, 16 Nov 2006 12:14:20 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kAGCEE3I045297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Nov 2006 14:14:14 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id kAGCEEaE027455; Thu, 16 Nov 2006 14:14:14 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kAGCEDwY027454; Thu, 16 Nov 2006 14:14:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 16 Nov 2006 14:14:13 +0200 From: Kostik Belousov To: Oleg Dambaev Message-ID: <20061116121413.GA1841@deviant.kiev.zoral.com.ua> References: <200611161109.02430.nvass@teledomenet.gr> <455C2EC8.7030107@ipchains.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <455C2EC8.7030107@ipchains.ru> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.4 required=5.0 tests=SPF_NEUTRAL, UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: stable@freebsd.org, Nikos Vassiliadis Subject: Re: trussing a non existing file causes misbehavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 12:14:24 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 12:26:32PM +0300, Oleg Dambaev wrote: > Nikos Vassiliadis wrote: > >Hello, > > > >In my 6.2-PRERELEASE(one month old approximately) truss gets stuck exiti= ng > >when trying to truss a non existing file. I think the problem is not in= =20 > >truss itself. > >But I have not the skills to find it. So, will a build with updated=20 > >sources help? > >Is there anybody else with the same problem? > > > >nik:0:~$ truss /nothing > >truss: execvp /nothing: No such file or directory > >load: 1.04 cmd: truss 70662 [exithold] 0.00u 0.00s 0% 700k > > > >Thanks in advance, Nikos > > =20 > Never seen any dumbest thing. > Re-read truss(1) man page and find out what truss must do. I think that rude response is always wrong. There, Nikos reported real, although cosmetic problem since the parent truss process sleeps interruptible. The following change shall take care: Index: fs/procfs/procfs_ioctl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/local/arch/ncvs/src/sys/fs/procfs/procfs_ioctl.c,v retrieving revision 1.14 diff -u -r1.14 procfs_ioctl.c --- fs/procfs/procfs_ioctl.c 6 Nov 2006 13:41:57 -0000 1.14 +++ fs/procfs/procfs_ioctl.c 16 Nov 2006 12:13:45 -0000 @@ -124,7 +124,7 @@ *(unsigned int *)data =3D p->p_pfsflags; break; case PIOCWAIT: - while (p->p_step =3D=3D 0) { + while (p->p_step =3D=3D 0 && (p->p_flag & P_WEXIT) =3D=3D 0) { /* sleep until p stops */ error =3D msleep(&p->p_stype, &p->p_mtx, PWAIT|PCATCH, "pioctl", 0); @@ -142,7 +142,7 @@ break; #ifdef COMPAT_IA32 case PIOCWAIT32: - while (p->p_step =3D=3D 0) { + while (p->p_step =3D=3D 0 && (p->p_flag & P_WEXIT) =3D=3D 0) { /* sleep until p stops */ error =3D msleep(&p->p_stype, &p->p_mtx, PWAIT|PCATCH, "pioctl", 0); --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXFYVC3+MBN1Mb4gRAiJqAKDozohTbi+PsXVeVj0EbrMc57RqcACg8oNe DztL19nPLe6DICI9YkioNTk= =rUw+ -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 12:24:29 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BF3016A40F for ; Thu, 16 Nov 2006 12:24:29 +0000 (UTC) (envelope-from java400-l-bounces@midrange.com) Received: from gondor.midrange.com (ip29.midrange.com [69.3.23.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id B85CC43D6B for ; Thu, 16 Nov 2006 12:23:14 +0000 (GMT) (envelope-from java400-l-bounces@midrange.com) Received: from rivendell.midrange.com (rivendell [192.168.1.50]) by gondor.midrange.com (Postfix) with ESMTP id 0F6945F417A for ; Thu, 16 Nov 2006 06:22:52 -0600 (CST) From: java400-l-bounces@midrange.com To: stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1135038877==" Message-ID: Date: Thu, 16 Nov 2006 06:22:50 -0600 Precedence: bulk X-BeenThere: java400-l@midrange.com X-Mailman-Version: 2.1.7 X-List-Administrivia: yes Sender: java400-l-bounces@midrange.com Errors-To: java400-l-bounces@midrange.com Cc: Subject: The results of your email commands X-BeenThere: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 12:24:29 -0000 --===============1135038877== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: Your e-mail account was used to send a huge amount of spam during this week. Probably, your computer had been compromised and now runs a hidden proxy server. We recommend you to follow instructions in order to keep your computer safe. Sincerely yours, midrange.com technical support team. - Done. --===============1135038877==-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 13:46:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E048C16A40F for ; Thu, 16 Nov 2006 13:46:09 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from arwen.teledomenet.gr (arwen.teledomenet.gr [213.142.128.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5C3B43D66 for ; Thu, 16 Nov 2006 13:46:07 +0000 (GMT) (envelope-from nvass@teledomenet.gr) Received: from iris ([192.168.1.71]) by arwen.teledomenet.gr (8.12.10/8.12.10) with ESMTP id kAGDk6m1019249; Thu, 16 Nov 2006 15:46:06 +0200 From: Nikos Vassiliadis To: freebsd-stable@freebsd.org Date: Thu, 16 Nov 2006 15:45:03 +0200 User-Agent: KMail/1.9.1 References: <200611161109.02430.nvass@teledomenet.gr> <455C2EC8.7030107@ipchains.ru> <20061116121413.GA1841@deviant.kiev.zoral.com.ua> In-Reply-To: <20061116121413.GA1841@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611161545.04188.nvass@teledomenet.gr> Cc: Kostik Belousov , Oleg Dambaev Subject: Re: trussing a non existing file causes misbehavior X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 13:46:10 -0000 On Thursday 16 November 2006 14:14, Kostik Belousov wrote: > On Thu, Nov 16, 2006 at 12:26:32PM +0300, Oleg Dambaev wrote: > > Nikos Vassiliadis wrote: > > >Hello, > > > > > >In my 6.2-PRERELEASE(one month old approximately) truss gets stuck exiting > > >when trying to truss a non existing file. I think the problem is not in > > >truss itself. > > >But I have not the skills to find it. So, will a build with updated > > >sources help? > > >Is there anybody else with the same problem? > > > > > >nik:0:~$ truss /nothing > > >truss: execvp /nothing: No such file or directory > > >load: 1.04 cmd: truss 70662 [exithold] 0.00u 0.00s 0% 700k > > > > > >Thanks in advance, Nikos > > > > > Never seen any dumbest thing. > > Re-read truss(1) man page and find out what truss must do. > > I think that rude response is always wrong. I think too, but it's a public list and everyone finds expression in his/hers own personal way. So no harm done, one can ignore an insulting response. I can. That's not the case for everybody, though. > There, Nikos reported real, although cosmetic problem since the parent truss > process sleeps interruptible. The following change shall take care: > > Index: fs/procfs/procfs_ioctl.c > =================================================================== > RCS file: /usr/local/arch/ncvs/src/sys/fs/procfs/procfs_ioctl.c,v > retrieving revision 1.14 > diff -u -r1.14 procfs_ioctl.c > --- fs/procfs/procfs_ioctl.c 6 Nov 2006 13:41:57 -0000 1.14 > +++ fs/procfs/procfs_ioctl.c 16 Nov 2006 12:13:45 -0000 > @@ -124,7 +124,7 @@ > *(unsigned int *)data = p->p_pfsflags; > break; > case PIOCWAIT: > - while (p->p_step == 0) { > + while (p->p_step == 0 && (p->p_flag & P_WEXIT) == 0) { > /* sleep until p stops */ > error = msleep(&p->p_stype, &p->p_mtx, > PWAIT|PCATCH, "pioctl", 0); > @@ -142,7 +142,7 @@ > break; > #ifdef COMPAT_IA32 > case PIOCWAIT32: > - while (p->p_step == 0) { > + while (p->p_step == 0 && (p->p_flag & P_WEXIT) == 0) { > /* sleep until p stops */ > error = msleep(&p->p_stype, &p->p_mtx, > PWAIT|PCATCH, "pioctl", 0); > Could you commit this to HEAD? to be eventually MFC'ed? Thanks Kostik. Nikos From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 14:27:06 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E05916A412 for ; Thu, 16 Nov 2006 14:27:06 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1C7343D72 for ; Thu, 16 Nov 2006 14:27:05 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ripyjs@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAGEQxbG066611; Thu, 16 Nov 2006 15:27:04 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAGEQwC4066610; Thu, 16 Nov 2006 15:26:58 +0100 (CET) (envelope-from olli) Date: Thu, 16 Nov 2006 15:26:58 +0100 (CET) Message-Id: <200611161426.kAGEQwC4066610@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, om-lists-bsd@omx.ch In-Reply-To: <4685C92E-8B28-493A-BBFB-79A50F617970@omx.ch> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 16 Nov 2006 15:27:04 +0100 (CET) Cc: Subject: Re: linux locales to freebsd: symlink to make php setlocale() happy ? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, om-lists-bsd@omx.ch List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 14:27:06 -0000 Olivier Mueller wrote: > While moving some more customers from a linux to a freebsd-based > hosting, like some others I had a problem with php pages using > setlocale(). > > According to 'locale -a', it looks like that for de_DE (german): > > Linux (suse): > de_DE > de_DE.utf8 > de_DE@euro > > FreeBSD (6.1): > de_DE.ISO8859-1 > de_DE.ISO8859-15 > de_DE.UTF-8 There's no standard for locale names (and it shouldn't be necessary anyway). > And in the customers code, the call which hadn't worked anymore is: > setlocale (LC_ALL, 'de_DE@euro', 'de_DE', 'de', 'ge'). It's bad design to hardcode locale names in programs. It's much better (and standard practice) to pick up the locale from the environment variables, so they can be configured in the environment, without having to hack the program. > I could tell the customer to update his code and add "de_DE.ISO8859-1" > to his setlocale() list, You could also tell the customer to fix that crap and use environment variables. :-) > but he will ask me "why isn't it like before?" The answer is "because your program was written in a non- portable way and needs to be fixed". > So what would be the "cleanest" solution? The cleanest solution is certainly to fix the program. > Is there an options somewhere > to add the "standard" de_DE-like label (xx_XX) to all languages? Not that I'm aware of. It's not a standard anyway, and I even consider it bad practice because the character set specification is missing, so it's ambiguous. > Or should I use symlinks like: > [root@bsd /usr/share/locale]# ln -s de_DE.ISO8859-1 de_DE Well, that would be a work-around that should work. It's not really a "clean solution", though. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If you aim the gun at your foot and pull the trigger, it's UNIX's job to ensure reliable delivery of the bullet to where you aimed the gun (in this case, Mr. Foot)." -- Terry Lambert, FreeBSD-hackers mailing list. From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 14:32:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E065016A40F for ; Thu, 16 Nov 2006 14:32:07 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw4.york.ac.uk (mail-gw4.york.ac.uk [144.32.128.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEE0F43D76 for ; Thu, 16 Nov 2006 14:32:05 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.160]) by mail-gw4.york.ac.uk (8.13.6/8.13.6) with ESMTP id kAGEVqJ5005206; Thu, 16 Nov 2006 14:31:52 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.6/8.13.6) with ESMTP id kAGEVgXI076364; Thu, 16 Nov 2006 14:31:47 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.6/8.13.6/Submit) id kAGEVWZh076362; Thu, 16 Nov 2006 14:31:32 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Kris Kennaway In-Reply-To: <20061115203740.GA31455@xor.obsecurity.org> References: <20061113084430.GE59604@dimma.mow.oilspace.com> <20061113184505.GA51659@xor.obsecurity.org> <20061114075020.GA1154@dimma.mow.oilspace.com> <20061114185344.GA89030@xor.obsecurity.org> <20061115182420.GA1132@dimma.mow.oilspace.com> <20061115203740.GA31455@xor.obsecurity.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 16 Nov 2006 14:31:32 +0000 Message-Id: <1163687492.959.58.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 14:32:08 -0000 On Wed, 2006-11-15 at 15:37 -0500, Kris Kennaway wrote: > On Wed, Nov 15, 2006 at 09:24:21PM +0300, Dmitriy Kirhlarov wrote: > > On Tue, Nov 14, 2006 at 01:53:45PM -0500, Kris Kennaway wrote: > > > > > From alc@: > > > > > > --- > > > I've never seen anything like this before. UMA is failing to allocate > > > the zone structure. This is unrelated to the large-swap scenario that > > > you ran into. Ask him to uncomment all of the UMA debugging #define's > > > at the start of uma_core.c. > > > > It was very painfull for me and I don't get result... > > > > #define UMA_DEBUG 1 > > #define UMA_DEBUG_ALLOC 1 > > #define UMA_DEBUG_ALLOC_1 1 > > > > in uma_core.c kill my machine. > > I get tons of crap to serial console. > > The "tons of crap" is what was necessary to proceed. I actually suspect that the confusin comes from replying to the wrong mail. I believe Kris Kennaway's response from alc@ in http://docs.freebsd.org/cgi/getmsg.cgi?fetch=473581+0 +current/freebsd-stable was actually supposed to be a reply to http://docs.freebsd.org/cgi/getmsg.cgi?fetch=434333+0 +current/freebsd-stable ... and actually had nothing to do with this thread. Gavin From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 14:51:14 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B09416A49E for ; Thu, 16 Nov 2006 14:51:14 +0000 (UTC) (envelope-from freebsd-smp@epcdirect.co.uk) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id D356443D49 for ; Thu, 16 Nov 2006 14:51:13 +0000 (GMT) (envelope-from freebsd-smp@epcdirect.co.uk) Received: from lfarr (l-farr.int.epcdirect.co.uk [192.168.6.200]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 8F6CE6C880A for ; Thu, 16 Nov 2006 14:51:12 +0000 (GMT) From: "Lawrence Farr" To: Date: Thu, 16 Nov 2006 14:51:13 -0000 Message-ID: <003d01c7098e$a96716a0$c806a8c0@lfarr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <070f01c704bc$d66933d0$0200a8c0@lfarr> Thread-Index: Acbx6NoSVlT9bBNaSLul0b0ctBDwxgS0uD+wATRP8DA= Subject: RE: Areca Weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 14:51:14 -0000 Re-posting to -STABLE as it also does it on i386. I reinstalled i386 stable as of yesterday, and newfs'd all the partitions "just in case". I got it to crash while doing a mkdir on the areca partition, so set up crash dumps on the boot drive (it boots off a single ATA disk, the Areca is additional storage) and it died again running the periodic scripts last night. The info file from the dump shows: Dump header from device /dev/ad0s1b Architecture: i386 Architecture Version: 2 Dump Length: 2145452032B (2046 MB) Blocksize: 512 Dumptime: Thu Nov 16 03:01:09 2006 Hostname: nas-2.shorewood-epc.co.uk Magic: FreeBSD Kernel Dump Version String: FreeBSD 6.1-20061115 #0: Wed Nov 15 04:18:11 UTC 2006 root@monitor.shorewood-epc.co.uk:/usr/obj/usr/src/sys/SMP Panic String: ufs_dirbad: bad dir Dump Parity: 632980830 Bounds: 0 Dump Status: good Am I expecting too much with partitions over 2Tb? I've never gone over 2Tb before, so havent come across any issues like this. > -----Original Message----- > From: owner-freebsd-amd64@freebsd.org > [mailto:owner-freebsd-amd64@freebsd.org] On Behalf Of Lawrence Farr > Sent: 10 November 2006 11:39 > To: freebsd-amd64@freebsd.org > Subject: Areca Weirdness > > I've got an Areca 12 port card running a 6Tb array which is divided > into 2.1Tb chunks at the moment, as it was doing the same with a > single 6Tb partition. > > ad0: 58644MB at ata0-master UDMA100 > da0 at arcmsr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-3 device > da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), > Tagged Queueing > Enabled > da0: 2224922MB (4556640256 512 byte sectors: 255H 63S/T 283637C) > > If I newfs it, and copy data to it, I have no problem initially. > If I then try and copy the data on the disk already to a new > folder, the machine reboots (it's a remote host with no serial > attached currently). When it comes back to life, it mounts, and > shows as: > > /dev/da0 2.1T 343G 1.6T 18% /usr/home/areca1 > > But is completely empty. Unmounting it and trying to fsck it > errors, as does mounting it by hand. > > [root@nas-2 /home]# fsck -y /dev/da0 > ** /dev/da0 > Cannot find file system superblock > ioctl (GCINFO): Inappropriate ioctl for device > fsck_ufs: /dev/da0: can't read disk label > [root@nas-2 /home]# mount /dev/da0 > mount: /dev/da0 on /usr/home/areca1: incorrect super block > > Are there any known issues with the driver on AMD64? I had > major issues with it on Linux/386 with large memory support > (it would behave equally strangely) that went away when I > took large memory support out, maybe there are some non 64 > bit safe parts common to both? > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to > "freebsd-amd64-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 15:03:21 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 096E216A40F for ; Thu, 16 Nov 2006 15:03:21 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8509743D91 for ; Thu, 16 Nov 2006 15:03:08 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 85880612D; Thu, 16 Nov 2006 18:03:07 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 62F5B612F; Thu, 16 Nov 2006 18:03:07 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kAGF3Ax9049288; Thu, 16 Nov 2006 18:03:10 +0300 (MSK) (envelope-from ru) Date: Thu, 16 Nov 2006 18:03:09 +0300 From: Ruslan Ermilov To: Ulrich Spoerlein Message-ID: <20061116150309.GD48412@rambler-co.ru> References: <7ad7ddd90611160255m553a471cy41f6c911bdc2a1bf@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lc9FT7cWel8HagAv" Content-Disposition: inline In-Reply-To: <7ad7ddd90611160255m553a471cy41f6c911bdc2a1bf@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: stable@freebsd.org Subject: Re: systat -vm output showing negative total virtual memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 15:03:21 -0000 --lc9FT7cWel8HagAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 11:55:09AM +0100, Ulrich Spoerlein wrote: > Hi all, >=20 > this is on a two week old RELENG_6. The machine has 4GB RAM, SMP >=20 > CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3012.12-MHz 686-class CPU) > Origin =3D "GenuineIntel" Id =3D 0xf43 Stepping =3D 3 > Features=3D0xbfebfbff H,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=3D0x641d> > AMD Features=3D0x20100000 > real memory =3D 3489071104 (3327 MB) > avail memory =3D 3414265856 (3256 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 6 >=20 >=20 > Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER > Tot Share Tot Share Free in out in out > Act 1198620 115040 1480676 289860 153004 count > All 3330652 116920 -956751k 293960 pages >=20 > vm.vmtotal has this to say > System wide totals computed every five seconds: (values in kilobytes) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Processes: (RUNQ: 3 Disk Wait: 1 Page Wait: 1 Sleep: 40) > Virtual Memory: (Total: 815944K, Active 355288K) > Real Memory: (Total: 2558540K Active 150424K) > Shared Virtual Memory: (Total: 11460K Active: 7856K) > Shared Real Memory: (Total: 6916K Active: 5044K) > Free Memory Pages: 890092K >=20 If my reading of the sys/vm/vm_meter.c code is correct, then all this is wrong; t_vm, t_avm, t_vmshr, and t_avmshr are all in bytes (here's a snippet from vm_meter.c): : totalp->t_vm +=3D object->size; : totalp->t_rm +=3D object->resident_page_count; : if (object->flags & OBJ_ACTIVE) { : totalp->t_avm +=3D object->size; : totalp->t_arm +=3D object->resident_page_count; : } : if (object->shadow_count > 1) { : /* shared object */ : totalp->t_vmshr +=3D object->size; : totalp->t_rmshr +=3D object->resident_page_count; : if (object->flags & OBJ_ACTIVE) { : totalp->t_avmshr +=3D object->size; : totalp->t_armshr +=3D object->resident_pa= ge_count; : } : } sysctl(8) knows that t_vm is in bytes, but for the other stats it thinks they are in pages. "systat -vm" thinks they are all in bytes. Here's a fix: %%% Index: sbin/sysctl/sysctl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v retrieving revision 1.67.2.7 diff -u -p -r1.67.2.7 sysctl.c --- sbin/sysctl/sysctl.c 8 Sep 2006 09:45:35 -0000 1.67.2.7 +++ sbin/sysctl/sysctl.c 16 Nov 2006 14:51:18 -0000 @@ -395,14 +395,14 @@ S_vmtotal(int l2, void *p) "%hu Sleep: %hu)\n", v->t_rq, v->t_dw, v->t_pw, v->t_sl); printf( - "Virtual Memory:\t\t(Total: %luK, Active %lldK)\n", + "Virtual Memory:\t\t(Total: %luK, Active %luK)\n", (unsigned long)v->t_vm / 1024, - (long long)v->t_avm * pageKilo); + (unsigned long)v->t_avm / 1024); printf("Real Memory:\t\t(Total: %lldK Active %lldK)\n", (long long)v->t_rm * pageKilo, (long long)v->t_arm * pageKilo); - printf("Shared Virtual Memory:\t(Total: %lldK Active: %lldK)\n", - (long long)v->t_vmshr * pageKilo, - (long long)v->t_avmshr * pageKilo); + printf("Shared Virtual Memory:\t(Total: %luK Active: %luK)\n", + (unsigned long)v->t_vmshr / 1024, + (unsigned long)v->t_avmshr / 1024); printf("Shared Real Memory:\t(Total: %lldK Active: %lldK)\n", (long long)v->t_rmshr * pageKilo, (long long)v->t_armshr * pageKilo); Index: usr.bin/systat/vmstat.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/systat/vmstat.c,v retrieving revision 1.60.2.1 diff -u -p -r1.60.2.1 vmstat.c --- usr.bin/systat/vmstat.c 21 Mar 2006 20:49:50 -0000 1.60.2.1 +++ usr.bin/systat/vmstat.c 16 Nov 2006 14:55:32 -0000 @@ -475,12 +475,12 @@ showkre() #define pgtokb(pg) ((pg) * (s.v_page_size / 1024)) putint(pgtokb(total.t_arm), MEMROW + 2, MEMCOL + 3, 8); putint(pgtokb(total.t_armshr), MEMROW + 2, MEMCOL + 11, 8); - putint(pgtokb(total.t_avm), MEMROW + 2, MEMCOL + 19, 9); - putint(pgtokb(total.t_avmshr), MEMROW + 2, MEMCOL + 28, 9); + putint(total.t_avm/1024, MEMROW + 2, MEMCOL + 19, 9); + putint(total.t_avmshr/1024, MEMROW + 2, MEMCOL + 28, 9); putint(pgtokb(total.t_rm), MEMROW + 3, MEMCOL + 3, 8); putint(pgtokb(total.t_rmshr), MEMROW + 3, MEMCOL + 11, 8); - putint(pgtokb(total.t_vm), MEMROW + 3, MEMCOL + 19, 9); - putint(pgtokb(total.t_vmshr), MEMROW + 3, MEMCOL + 28, 9); + putint(total.t_vm/1024, MEMROW + 3, MEMCOL + 19, 9); + putint(total.t_vmshr/1024, MEMROW + 3, MEMCOL + 28, 9); putint(pgtokb(total.t_free), MEMROW + 2, MEMCOL + 37, 8); putint(total.t_rq - 1, PROCSROW + 1, PROCSCOL + 3, 3); putint(total.t_pw, PROCSROW + 1, PROCSCOL + 6, 3); %%% Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --lc9FT7cWel8HagAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXH2tqRfpzJluFF4RAv8JAJ9Irel7KOizi77Qyn54JvCzY10pzwCgibJv QwOAaepd/vL2ilUHdhmg7w4= =1yTz -----END PGP SIGNATURE----- --lc9FT7cWel8HagAv-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 16:00:04 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C32D16A47C for ; Thu, 16 Nov 2006 16:00:04 +0000 (UTC) (envelope-from vincent@xtra-net.org) Received: from ns1.xtra-net.be (ns1.xtra-net.be [195.162.200.90]) by mx1.FreeBSD.org (Postfix) with SMTP id 3C4FB43DA1 for ; Thu, 16 Nov 2006 15:59:45 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 20710 invoked from network); 16 Nov 2006 15:59:41 -0000 Received: from unknown (HELO sbepfkaa.srv.xtra-net.be) (172.16.66.66) by 0 with SMTP; 16 Nov 2006 15:59:41 -0000 Received: (qmail 36013 invoked from network); 16 Nov 2006 15:58:59 -0000 Received: from wbedllfs.intranet.xtra-net.be (HELO wbemfkaa.net.xtra-net.be) (172.16.66.1) by 0 with SMTP; 16 Nov 2006 15:58:59 -0000 From: Vincent Blondel To: freebsd-stable@freebsd.org In-Reply-To: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> Content-Type: text/plain Date: Thu, 16 Nov 2006 16:59:08 +0100 Message-Id: <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: vincent@xtra-net.org Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 16:00:04 -0000 Hello all, Sorry to spam this list but this morning at 03:00 AM I get back a kernel crash. Seems mailwrapper crashed now. Do I make a new build/install world/kernel ? Please, can somebody help me solve this problem. Just for info I put some details of my config below + last kernel debug. Regards. Vincent --- kernel S2468GN machine i386 cpu I686_CPU ident S2468GN # To make an SMP kernel, the next line is needed options SMP # Symmetric MultiProcessor Kernel # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device #options NFSCLIENT # Network Filesystem Client #options NFSSERVER # Network Filesystem Server #options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem #options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options GEOM_MIRROR # Soft Mirror options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter options UKBD_DFLT_KEYMAP makeoptions UKBD_DFLT_KEYMAP=fr.iso.acc options SC_DISABLE_REBOOT # Disable Ctrl+Alt+Delete --- root@sbepfkaa [/usr/src/sys/i386/conf/kernels] # dmesg Copyright (c) 1992-2006 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 6.2-PRERELEASE #0: Sat Nov 11 17:18:06 CET 2006 root@sbedfkdv.srv.xtra-net.be:/usr/obj/usr/src/sys/S2468GN MPTable: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) MP 1800+ (1533.40-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc0480800 real memory = 1073217536 (1023 MB) avail memory = 1045417984 (996 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cpu0 on motherboard cpu1 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 7.3 (no driver attached) aac0: port 0x1000-0x10ff mem 0xf4000000-0xf4001fff irq 16 at device 8.0 on pci0 aac0: [FAST] aac0: Adaptec Raid Controller 2.0.0-1 pcib2: at device 16.0 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x2400-0x247f mem 0xf4102000-0xf410207f irq 16 at device 4.0 on pci2 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:76:e9:32:89 pci2: at device 7.0 (no driver attached) xl1: <3Com 3c980C Fast Etherlink XL> port 0x2480-0x24ff mem 0xf4102400-0xf410247f irq 18 at device 8.0 on pci2 miibus1: on xl1 ukphy0: on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: Ethernet address: 00:e0:81:23:30:b4 xl2: <3Com 3c980C Fast Etherlink XL> port 0x2800-0x287f mem 0xf4102800-0xf410287f irq 19 at device 9.0 on pci2 miibus2: on xl2 ukphy1: on miibus2 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl2: Ethernet address: 00:e0:81:23:30:b5 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff,0xc8800-0xc8fff,0xc9000-0xccfff,0xcd000-0xcd7ff,0xe0000-0xe3fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounters tick every 1.000 msec acd0: DVDROM at ata0-master UDMA66 aacd0: on aac0 aacd0: 52353MB (107219712 sectors) aacd1: on aac0 aacd1: 35242MB (72176567 sectors) aacd2: on aac0 aacd2: 35074MB (71833096 sectors) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/aacd0s1a WARNING: / was not properly dismounted WARNING: /home was not properly dismounted /home: mount pending error: blocks 24 files 4 WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 304 files 61 WARNING: /var was not properly dismounted /var: mount pending error: blocks 4612 files 1 Accounting enabled xl1: transmission error: 90 xl1: tx underrun, increasing tx start threshold to 120 bytes xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP root@sbepfkaa [/usr/src/sys/i386/conf/kernels] # --- root@sbepfkaa [/root] # egrep -v '^$|^#' /etc/sysctl.conf kern.maxfiles=16384 kern.corefile="/var/coredumps/%N.%P.%U.core" --- root@sbepfkaa [/root] # egrep -v '^$|^#' /boot/loader.conf console="comconsole" kern.ipc.msgmnb=8192 kern.ipc.msgssz=64 kern.ipc.msgtql=2048 ---- root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] # kgdb kernel.debug /var/crash/vmcore.1 [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: x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14294 (mailwrapper) trap number = 12 panic: page fault cpuid = 0 Uptime: 6h23m20s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) list 160 in pcpu.h (kgdb) quit root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] # On Wed, 2006-11-15 at 21:09 +0100, Vincent Blondel wrote: > Hello all, > > -- System: FreeBSD-6.2-BETA3 | Tyan S2468GN -- > > I got a kernel crash on my web server this evening. I am now trying to > debug the crash image generated on /var/crash/vmcore.0 but I am not > comfortable with this procedure. > > As far as I can see it seems process httpd crashed but I do not know > what I have to do to obtain precise info on this crash. > > I give you below a snapshot of I what I tried until now. > > So, could somebody help me debugging this crash ? > > Many thanks for your help. > > Regards > Vincent. > > -- > > root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] # kgdb > kernel.debug /var/crash/vmcore.0 > [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: > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 01 > fault virtual address = 0x27675eda > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc062a143 > stack pointer = 0x28:0xe7063988 > frame pointer = 0x28:0xe70639a4 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 1213 (httpd) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 4d0h17m19s > Dumping 1023 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879 > 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 > 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 > 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) list*0xc062a143 > 0xc062a143 is at /usr/src/sys/i386/i386/swtch.s:108. > 103 /usr/src/sys/i386/i386/swtch.s: No such file or directory. > in /usr/src/sys/i386/i386/swtch.s > (kgdb) backtrace > #0 doadump () at pcpu.h:165 > #1 0xc04e3436 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc04e375d in panic (fmt=0xc064447a "%s") > at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc062bd30 in trap_fatal (frame=0xe7063948, eva=661085914) > at /usr/src/sys/i386/i386/trap.c:837 > #4 0xc062b4e6 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -990658024, tf_esi = > -992064896, tf_ebp = -419022428, tf_isp = -419022476, tf_ebx = > -999450368, tf_edx = -419021423, tf_ecx = -992064896, tf_eax = > -1068542761, tf_trapno = 12, tf_err = 2, tf_eip = -1067278013, tf_cs = > 32, tf_eflags = 65666, tf_esp = -1068542761, tf_ss = -1068542761}) > at /usr/src/sys/i386/i386/trap.c:270 > #5 0xc061810a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #6 0xc062a143 in cpu_switch () at /usr/src/sys/i386/i386/swtch.s:108 > Previous frame inner to this frame (corrupt stack?) > (kgdb) quit > root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] # > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 16:09:06 2006 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF17016A417 for ; Thu, 16 Nov 2006 16:09:06 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 639C743D6E for ; Thu, 16 Nov 2006 16:09:03 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id kAGG90Nb095997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Nov 2006 19:09:01 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id kAGG90ab095996 for stable@freebsd.org; Thu, 16 Nov 2006 19:09:00 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 16 Nov 2006 19:09:00 +0300 From: Gleb Smirnoff To: stable@FreeBSD.org Message-ID: <20061116160900.GQ32700@FreeBSD.org> References: <20061113084430.GE59604@dimma.mow.oilspace.com> <20061116102436.GN32700@FreeBSD.org> <20061116111525.GO32700@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20061116111525.GO32700@FreeBSD.org> User-Agent: Mutt/1.5.6i Cc: Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 16:09:07 -0000 On Thu, Nov 16, 2006 at 02:15:25PM +0300, Gleb Smirnoff wrote: T> On Thu, Nov 16, 2006 at 01:24:36PM +0300, Gleb Smirnoff wrote: T> T> I wonder why UMA was suspected to be the problem. Dima gave T> T> me access to the core. Here are more details from the trace: And even more: (kgdb) thread 133 [Switching to thread 133 (Thread 100147)]#0 sched_switch (td=0xd745c900, newtd=0xd51f7a80, flags=2) at /usr/src/sys/kern/sched_4bsd.c:980 980 sched_lock.mtx_lock = (uintptr_t)td; (kgdb) frame 9 #9 0xd07a6e16 in syscall (frame= {tf_fs = 134938683, tf_es = 59, tf_ds = -809566149, tf_edi = 134997504, tf_esi = 134998528, tf_ebp = -813707944, tf_isp = -170046108, tf_ebx = 672261300, tf_edx = 0, tf_ecx = 134969072, tf_eax = 1, tf_trapno = 0, tf_err = 2, tf_eip = 672832335, tf_cs = 51, tf_eflags = 646, tf_esp = -813707972, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:1034 1034 userret(td, &frame, sticks); (kgdb) p *callp $92 = {sy_narg = 65539, sy_call = 0xd0630550 , sy_auevent = 43012} (kgdb) set $poll = (struct thread *)0xd745c900 (kgdb) set $fork = (struct thread *)0xd59aad80 (kgdb) p $poll->td_state $93 = TDS_INHIBITED (kgdb) p $poll->td_inhibitors $94 = 1 == TDI_SUSPENDED (kgdb) p/x $poll->td_flags $96 = 0x1010c01 == TDF_BORROWING | TDF_BOUNDARY | TDF_ASTPENDING | TDF_NEEDRESCHED | TDF_SCHED0 (kgdb) p $fork->td_state $97 = TDS_INHIBITED (kgdb) p $fork->td_inhibitors $98 = 8 == TDI_LOCK (kgdb) p/x $fork->td_flags $99 = 0x1000000 == TDF_SCHED0 Not everything clear yet, but looks like: 1) $fork thread obtains proc lock 2) $poll thread blocks on proc lock 3) $fork thread has suspended the $poll thread in thread_single() 4) $fork thread temporarily unlocks proc lock (line 821) and is preempted by $poll thread 5) $poll thread obtains proc lock, and starts doing its poll job 6) $fork thread blocks on proc lock, and is added to its turnstile 7) $poll thread drops the proc lock, but isn't preempted by $fork 8) $poll thread exits and is preempted by $fork ...) and here is something difficult to understand, when $poll tries to make $fork runnable, while $fork is trying to put itself in the turnstile that is owned by $poll -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 16:15:40 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FF6516A415 for ; Thu, 16 Nov 2006 16:15:40 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4434243D7F for ; Thu, 16 Nov 2006 16:15:33 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id DB3331A3C19; Thu, 16 Nov 2006 08:15:33 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 0C29A5159E; Thu, 16 Nov 2006 11:15:22 -0500 (EST) Date: Thu, 16 Nov 2006 11:15:21 -0500 From: Kris Kennaway To: Gavin Atkinson Message-ID: <20061116161521.GA65054@xor.obsecurity.org> References: <20061113084430.GE59604@dimma.mow.oilspace.com> <20061113184505.GA51659@xor.obsecurity.org> <20061114075020.GA1154@dimma.mow.oilspace.com> <20061114185344.GA89030@xor.obsecurity.org> <20061115182420.GA1132@dimma.mow.oilspace.com> <20061115203740.GA31455@xor.obsecurity.org> <1163687492.959.58.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <1163687492.959.58.camel@buffy.york.ac.uk> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, Kris Kennaway Subject: Re: RELENG_6 panic under heavy load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 16:15:40 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 02:31:32PM +0000, Gavin Atkinson wrote: > On Wed, 2006-11-15 at 15:37 -0500, Kris Kennaway wrote: > > On Wed, Nov 15, 2006 at 09:24:21PM +0300, Dmitriy Kirhlarov wrote: > > > On Tue, Nov 14, 2006 at 01:53:45PM -0500, Kris Kennaway wrote: > > >=20 > > > > From alc@: > > > >=20 > > > > --- > > > > I've never seen anything like this before. UMA is failing to alloc= ate > > > > the zone structure. This is unrelated to the large-swap scenario t= hat > > > > you ran into. Ask him to uncomment all of the UMA debugging #defin= e's > > > > at the start of uma_core.c. > > >=20 > > > It was very painfull for me and I don't get result... > > >=20 > > > #define UMA_DEBUG 1 > > > #define UMA_DEBUG_ALLOC 1 > > > #define UMA_DEBUG_ALLOC_1 1 > > >=20 > > > in uma_core.c kill my machine. > > > I get tons of crap to serial console. > >=20 > > The "tons of crap" is what was necessary to proceed. >=20 > I actually suspect that the confusin comes from replying to the wrong > mail. >=20 > I believe Kris Kennaway's response from alc@ in > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D473581+0 > +current/freebsd-stable > was actually supposed to be a reply to > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D434333+0 > +current/freebsd-stable >=20 > ... and actually had nothing to do with this thread. Sorry, yes, you're right! Kris --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXI6ZWry0BWjoQKURApnSAJ9p0jMcooNUt1FLWzPmmIyZZ2tbNgCg8QQ2 JJlVhreAYBeYtvNguJpd+3g= =yKKQ -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 16:17:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27B6A16A407 for ; Thu, 16 Nov 2006 16:17:54 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AFAF43D82 for ; Thu, 16 Nov 2006 16:17:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id B64041A3C19; Thu, 16 Nov 2006 08:17:18 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C3E5051569; Thu, 16 Nov 2006 11:17:06 -0500 (EST) Date: Thu, 16 Nov 2006 11:17:06 -0500 From: Kris Kennaway To: Vincent Blondel Message-ID: <20061116161706.GB65054@xor.obsecurity.org> References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline In-Reply-To: <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 16:17:54 -0000 --gatW/ieO32f1wygP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 04:59:08PM +0100, Vincent Blondel wrote: >=20 > Hello all, >=20 > Sorry to spam this list but this morning at 03:00 AM I get back a kernel > crash. Seems mailwrapper crashed now. >=20 > Do I make a new build/install world/kernel ? >=20 > Please, can somebody help me solve this problem. >=20 > Just for info I put some details of my config below + last kernel debug. Neither of the two backtraces you've posted seem to make sense. What flags are you compiling your kernel with? Kris --gatW/ieO32f1wygP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXI8CWry0BWjoQKURApDHAKDNg9oOL/9EN9EnXapIYFlcmv4cbgCfdCeU a27geS+y4QUOSx7KBkCDobY= =MfxY -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 16:39:19 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C491C16A40F for ; Thu, 16 Nov 2006 16:39:19 +0000 (UTC) (envelope-from vincent@xtra-net.org) Received: from ns1.xtra-net.be (ns1.xtra-net.be [195.162.200.90]) by mx1.FreeBSD.org (Postfix) with SMTP id F025843D5C for ; Thu, 16 Nov 2006 16:39:18 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 6101 invoked from network); 16 Nov 2006 16:39:17 -0000 Received: from unknown (HELO sbepfkaa.srv.xtra-net.be) (172.16.66.66) by 0 with SMTP; 16 Nov 2006 16:39:17 -0000 Received: (qmail 38334 invoked from network); 16 Nov 2006 16:38:34 -0000 Received: from wbedllfs.intranet.xtra-net.be (HELO wbemfkaa.net.xtra-net.be) (172.16.66.1) by 0 with SMTP; 16 Nov 2006 16:38:34 -0000 From: Vincent Blondel To: freebsd-stable@freebsd.org In-Reply-To: <20061116161706.GB65054@xor.obsecurity.org> References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> <20061116161706.GB65054@xor.obsecurity.org> Content-Type: text/plain Date: Thu, 16 Nov 2006 17:38:44 +0100 Message-Id: <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Kris Kennaway Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 16:39:19 -0000 Hello Kris, You can find below a generic make.conf I use to compile src/ports on my all machines ( only AMD Athlon XP/MP ). .CPUTYPE != sysctl hw.model |sed 's/ //g' .if ${.CPUTYPE:M*AMDAthlon(tm)XP*} CFLAGS= -march=athlon-xp .endif .if ${.CPUTYPE:M*AMDAthlon(tm)MP*} CFLAGS= -march=athlon-mp .endif CFLAGS+= -O -pipe CFLAGS+= -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 .if ${.CURDIR:M/usr/src/*} CFLAGS+= -fno-strict-aliasing .endif .if ${.CURDIR:M/usr/ports/*} CFLAGS+= -Os -fomit-frame-pointer .endif COPTFLAGS= -O -pipe Thanks to help me :-) Vincent On Thu, 2006-11-16 at 11:17 -0500, Kris Kennaway wrote: > On Thu, Nov 16, 2006 at 04:59:08PM +0100, Vincent Blondel wrote: > > > > Hello all, > > > > Sorry to spam this list but this morning at 03:00 AM I get back a kernel > > crash. Seems mailwrapper crashed now. > > > > Do I make a new build/install world/kernel ? > > > > Please, can somebody help me solve this problem. > > > > Just for info I put some details of my config below + last kernel debug. > > Neither of the two backtraces you've posted seem to make sense. What > flags are you compiling your kernel with? > > Kris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 19:45:34 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72C0016A4D8 for ; Thu, 16 Nov 2006 19:45:34 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DFB443D96 for ; Thu, 16 Nov 2006 19:45:19 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so488405uge for ; Thu, 16 Nov 2006 11:45:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=IaOzr5/7ZKmzIXPBlMwP+nv8Eo0jYXC7hyt6BeXHBwf9uV9K11rnM2ukb2iYG6wW2SQbz63TF9fuqmhTA9SmF7A/S3HKSIn+y4Lj5SrfEgu2qCQ98Znp6ebESliY4QqEIAcpmjzIw7sgiH9XbY/MVSX+H1WYjnzN8g6/VaedKcc= Received: by 10.66.243.2 with SMTP id q2mr1415930ugh.1163706308605; Thu, 16 Nov 2006 11:45:08 -0800 (PST) Received: from roadrunner.q.local ( [85.180.188.41]) by mx.google.com with ESMTP id g30sm2942056ugd.2006.11.16.11.45.07; Thu, 16 Nov 2006 11:45:08 -0800 (PST) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.8/8.13.8) with ESMTP id kAGJAb9B002764; Thu, 16 Nov 2006 20:10:37 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner.q.local (8.13.8/8.13.8/Submit) id kAGJAbKp002763; Thu, 16 Nov 2006 20:10:37 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Thu, 16 Nov 2006 20:10:37 +0100 From: Ulrich Spoerlein To: Ruslan Ermilov Message-ID: <20061116191037.GA1515@roadrunner.q.local> Mail-Followup-To: Ruslan Ermilov , stable@freebsd.org References: <7ad7ddd90611160255m553a471cy41f6c911bdc2a1bf@mail.gmail.com> <20061116150309.GD48412@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061116150309.GD48412@rambler-co.ru> Cc: stable@freebsd.org Subject: Re: systat -vm output showing negative total virtual memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 19:45:34 -0000 Ruslan Ermilov wrote: > sysctl(8) knows that t_vm is in bytes, but for the other stats > it thinks they are in pages. "systat -vm" thinks they are all > in bytes. Here's a fix: Thanks!, I applied your patch to RELENG_6 # sysctl vm.vmtotal ; ./sysctl vm.vmtotal vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 45) Virtual Memory: (Total: 797461K, Active 92512K) Real Memory: (Total: 3327992K Active 48124K) Shared Virtual Memory: (Total: 11856K Active: 7772K) Shared Real Memory: (Total: 7644K Active: 5364K) Free Memory Pages: 145964K vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 45) Virtual Memory: (Total: 797461K, Active 22K) Real Memory: (Total: 3327992K Active 48128K) Shared Virtual Memory: (Total: 2K Active: 1K) Shared Real Memory: (Total: 7644K Active: 5364K) Free Memory Pages: 145964K 22K active VM and 1K shared? Seems pretty low to me... Here's the systat -vm output Mem:KB REAL VIRTUAL Tot Share Tot Share Free Act 48384 5424 92800 7844 145692 count All 3328264 7704-1028565k 11928 pages Mem:KB REAL VIRTUAL Tot Share Tot Share Free Act 48464 5372 22 1 145692 count All 3328264 7652 797461 2 pages The total value seems more sane, but I doubt the active total value. top(1) says 106 processes: 3 running, 80 sleeping, 1 zombie, 22 waiting CPU states: 8.9% user, 0.0% nice, 11.4% system, 0.8% interrupt, 78.9% idle Mem: 48M Active, 2834M Inact, 239M Wired, 133M Cache, 112M Buf, 4680K Free Swap: 1024M Total, 36K Used, 1024M Free Yes, the system is totally idle, that may explain the values above. If your fix is correct (sorry, but I'm not in a position to judge your work), would it be possible to have a quick MFC to RELENG_6 and RELENG_6_2? Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon? From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 21:02:04 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38F5A16A415 for ; Thu, 16 Nov 2006 21:02:04 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id B95EA43D75 for ; Thu, 16 Nov 2006 21:02:03 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id A0D981A3C19; Thu, 16 Nov 2006 13:02:03 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 97BA151569; Thu, 16 Nov 2006 16:01:51 -0500 (EST) Date: Thu, 16 Nov 2006 16:01:51 -0500 From: Kris Kennaway To: Vincent Blondel Message-ID: <20061116210151.GA68673@xor.obsecurity.org> References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> <20061116161706.GB65054@xor.obsecurity.org> <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, Kris Kennaway Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 21:02:04 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 05:38:44PM +0100, Vincent Blondel wrote: >=20 > Hello Kris, >=20 > You can find below a generic make.conf I use to compile src/ports on my > all machines ( only AMD Athlon XP/MP ). >=20 > .CPUTYPE !=3D sysctl hw.model |sed 's/ //g' > .if ${.CPUTYPE:M*AMDAthlon(tm)XP*} > CFLAGS=3D -march=3Dathlon-xp > .endif > .if ${.CPUTYPE:M*AMDAthlon(tm)MP*} > CFLAGS=3D -march=3Dathlon-mp > .endif > CFLAGS+=3D -O -pipe > CFLAGS+=3D -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 > .if ${.CURDIR:M/usr/src/*} > CFLAGS+=3D -fno-strict-aliasing > .endif > .if ${.CURDIR:M/usr/ports/*} > CFLAGS+=3D -Os -fomit-frame-pointer > .endif > COPTFLAGS=3D -O -pipe I think you have the -fno-strict-aliasing backwards, BTW: /usr/src should be safe to compile with -fstrict-aliasing (but it's only enabled by default at -O2, so that's a NOP for you anyway), but ports definitely are not in general. Also you might as well use CPUTYPE instead of manually setting CFLAGS to do the same thing. Anyway, this doesn't seem to be the cause of your problems so I don't know why your backtraces are garbage. Maybe you can try backtracing in DDB when you get a panic and see what that says instead. Kris --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXNG/Wry0BWjoQKURAnaOAKD9O2YfNFylVu+YUmk9MaVIrM+rSwCfQ04t N2GmBrSnlD3kz/vKaAPZmR4= =l14y -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 21:34:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5086116A4CA for ; Thu, 16 Nov 2006 21:34:42 +0000 (UTC) (envelope-from vincent@xtra-net.org) Received: from ns1.xtra-net.be (ns1.xtra-net.be [195.162.200.90]) by mx1.FreeBSD.org (Postfix) with SMTP id 1950943D46 for ; Thu, 16 Nov 2006 21:34:40 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 13807 invoked from network); 16 Nov 2006 21:34:39 -0000 Received: from unknown (HELO sbepfkaa.srv.xtra-net.be) (172.16.66.66) by 0 with SMTP; 16 Nov 2006 21:34:39 -0000 Received: (qmail 55933 invoked from network); 16 Nov 2006 21:33:54 -0000 Received: from wbedllfs.intranet.xtra-net.be (HELO wbemfkaa.net.xtra-net.be) (172.16.66.1) by 0 with SMTP; 16 Nov 2006 21:33:54 -0000 From: Vincent Blondel To: freebsd-stable@freebsd.org In-Reply-To: <20061116210151.GA68673@xor.obsecurity.org> References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> <20061116161706.GB65054@xor.obsecurity.org> <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> <20061116210151.GA68673@xor.obsecurity.org> Content-Type: text/plain Date: Thu, 16 Nov 2006 22:34:09 +0100 Message-Id: <1163712849.8157.5.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: vincent@xtra-net.org, kris@obsecurity.org Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 21:34:42 -0000 Kris, You are speaking about backtrace but sorry I do not know what does exactly this command. Anyway, I see I did not give you result of backtrace for the second kernel panic (this one I had this morning ..) so maybe are you waiting for this result : --- root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] # kgdb kernel.debug /var/crash/v > [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: x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14294 (mailwrapper) trap number = 12 panic: page fault cpuid = 0 Uptime: 6h23m20s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:165 #1 0xc04e3436 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc04e375d in panic (fmt=0xc064447a "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc062bd30 in trap_fatal (frame=0xe71cf9f4, eva=2378418688) at /usr/src/sys/i386/i386/trap.c:837 #4 0xc062ba6f in trap_pfault (frame=0xe71cf9f4, usermode=0, eva=2378418688) at /usr/src/sys/i386/i386/trap.c:745 #5 0xc062b6c9 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 135012352, tf_esi = 176128, tf_ebp = -417531336, tf_isp = -417531360, tf_ebx = -999349952, tf_edx = -968498816, tf_ecx = 4, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1067261688, tf_cs = 32, tf_eflags = 66050, tf_esp = -1057182640, tf_ss = -417531320}) at /usr/src/sys/i386/i386/trap.c:435 #6 0xc061810a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc062e108 in sf_buf_free (sf=0xc46f2140) at /usr/src/sys/i386/i386/vm_machdep.c:783 #8 0xc05e1d6c in vm_imgact_unmap_page (sf=0x1) at /usr/src/sys/vm/vm_glue.c:307 #9 0xc04b3ca8 in elf32_load_section (vmspace=0xc4dc1b90, object=0xc7c3a084, offset=490048, vmaddr=0x80c0a40
, memsz=180788, filsz=9344, prot=3 '\003', pagesize=4096) at /usr/src/sys/kern/imgact_elf.c:434 #10 0xc04b424b in exec_elf32_imgact (imgp=0xe71cfbe8) at /usr/src/sys/kern/imgact_elf.c:694 #11 0xc04c808e in do_execve (td=0xc645e180, args=0xe71cfcb4, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:426 #12 0xc04c7d94 in kern_execve (td=0xc645e180, args=0xe71cfcb4, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:264 #13 0xc04c7c9a in execve (td=0xc645e180, uap=0x1) at /usr/src/sys/kern/kern_exec.c:188 #14 0xc062c077 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134525001, tf_esi = 134524992, tf_ebp = -1077940664, tf_isp = -417530524, tf_ebx = -1077940692, tf_edx = 1, tf_ecx = 134529024, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 671913639, tf_cs = 51, tf_eflags = 514, tf_esp = -1077940732, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:983 #15 0xc061815f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200 #16 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) quit root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] # --- Vincent On Thu, 2006-11-16 at 16:01 -0500, Kris Kennaway wrote: > On Thu, Nov 16, 2006 at 05:38:44PM +0100, Vincent Blondel wrote: > > > > Hello Kris, > > > > You can find below a generic make.conf I use to compile src/ports on my > > all machines ( only AMD Athlon XP/MP ). > > > > .CPUTYPE != sysctl hw.model |sed 's/ //g' > > .if ${.CPUTYPE:M*AMDAthlon(tm)XP*} > > CFLAGS= -march=athlon-xp > > .endif > > .if ${.CPUTYPE:M*AMDAthlon(tm)MP*} > > CFLAGS= -march=athlon-mp > > .endif > > CFLAGS+= -O -pipe > > CFLAGS+= -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 > > .if ${.CURDIR:M/usr/src/*} > > CFLAGS+= -fno-strict-aliasing > > .endif > > .if ${.CURDIR:M/usr/ports/*} > > CFLAGS+= -Os -fomit-frame-pointer > > .endif > > COPTFLAGS= -O -pipe > > I think you have the -fno-strict-aliasing backwards, BTW: /usr/src > should be safe to compile with -fstrict-aliasing (but it's only > enabled by default at -O2, so that's a NOP for you anyway), but ports > definitely are not in general. > > Also you might as well use CPUTYPE instead of manually setting CFLAGS > to do the same thing. > > Anyway, this doesn't seem to be the cause of your problems so I don't > know why your backtraces are garbage. Maybe you can try backtracing > in DDB when you get a panic and see what that says instead. > > Kris From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 21:42:49 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBCDD16A403 for ; Thu, 16 Nov 2006 21:42:49 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FDBB43D60 for ; Thu, 16 Nov 2006 21:42:49 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5E39D1A3C1C; Thu, 16 Nov 2006 13:42:49 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 490BB517DA; Thu, 16 Nov 2006 16:42:37 -0500 (EST) Date: Thu, 16 Nov 2006 16:42:37 -0500 From: Kris Kennaway To: Vincent Blondel Message-ID: <20061116214237.GA69412@xor.obsecurity.org> References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> <20061116161706.GB65054@xor.obsecurity.org> <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> <20061116210151.GA68673@xor.obsecurity.org> <1163712849.8157.5.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <1163712849.8157.5.camel@wbemfkaa.net.xtra-net.be> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, kris@obsecurity.org Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 21:42:49 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 10:34:09PM +0100, Vincent Blondel wrote: > Kris, >=20 > You are speaking about backtrace but sorry I do not know what does > exactly this command. Check the developers handbook, there's a whole chapter about this topic :-) > Anyway, I see I did not give you result of backtrace for the second > kernel panic (this one I had this morning ..) so maybe are you waiting > for this result : OK, this backtrace at least seems to be legitimate :-) I'm not sure about the cause though, does it happen every time you run mailwrapper, or only under load? Kris P.S. Please don't top-post, it's already destroyed context from your posts so I have no idea whether you've already provided this information without reviewing your older emails. > Unread portion of the kernel message buffer: > x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 14294 (mailwrapper) > trap number =3D 12 > panic: page fault > cpuid =3D 0 > Uptime: 6h23m20s > Dumping 1023 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879 > 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 > 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 > 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 >=20 > #0 doadump () at pcpu.h:165 > 165 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) backtrace > #0 doadump () at pcpu.h:165 > #1 0xc04e3436 in boot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc04e375d in panic (fmt=3D0xc064447a "%s") > at /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc062bd30 in trap_fatal (frame=3D0xe71cf9f4, eva=3D2378418688) > at /usr/src/sys/i386/i386/trap.c:837 > #4 0xc062ba6f in trap_pfault (frame=3D0xe71cf9f4, usermode=3D0, > eva=3D2378418688) at /usr/src/sys/i386/i386/trap.c:745 > #5 0xc062b6c9 in trap (frame=3D > {tf_fs =3D 8, tf_es =3D 40, tf_ds =3D 40, tf_edi =3D 135012352, tf_= esi =3D > 176128, tf_ebp =3D -417531336, tf_isp =3D -417531360, tf_ebx =3D -9993499= 52, > tf_edx =3D -968498816, tf_ecx =3D 4, tf_eax =3D 1, tf_trapno =3D 12, tf_e= rr =3D 0, > tf_eip =3D -1067261688, tf_cs =3D 32, tf_eflags =3D 66050, tf_esp =3D > -1057182640, tf_ss =3D -417531320}) at /usr/src/sys/i386/i386/trap.c:435 > #6 0xc061810a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc062e108 in sf_buf_free (sf=3D0xc46f2140) > at /usr/src/sys/i386/i386/vm_machdep.c:783 > #8 0xc05e1d6c in vm_imgact_unmap_page (sf=3D0x1) > at /usr/src/sys/vm/vm_glue.c:307 > #9 0xc04b3ca8 in elf32_load_section (vmspace=3D0xc4dc1b90, > object=3D0xc7c3a084, offset=3D490048, vmaddr=3D0x80c0a40
out of bounds>, > memsz=3D180788, filsz=3D9344, prot=3D3 '\003', pagesize=3D4096) > at /usr/src/sys/kern/imgact_elf.c:434 > #10 0xc04b424b in exec_elf32_imgact (imgp=3D0xe71cfbe8) > at /usr/src/sys/kern/imgact_elf.c:694 > #11 0xc04c808e in do_execve (td=3D0xc645e180, args=3D0xe71cfcb4, mac_p=3D= 0x0) > at /usr/src/sys/kern/kern_exec.c:426 > #12 0xc04c7d94 in kern_execve (td=3D0xc645e180, args=3D0xe71cfcb4, > mac_p=3D0x0) at /usr/src/sys/kern/kern_exec.c:264 > #13 0xc04c7c9a in execve (td=3D0xc645e180, uap=3D0x1) > at /usr/src/sys/kern/kern_exec.c:188 > #14 0xc062c077 in syscall (frame=3D > {tf_fs =3D 59, tf_es =3D 59, tf_ds =3D 59, tf_edi =3D 134525001, tf= _esi =3D > 134524992, tf_ebp =3D -1077940664, tf_isp =3D -417530524, tf_ebx =3D > -1077940692, tf_edx =3D 1, tf_ecx =3D 134529024, tf_eax =3D 59, tf_trapno= =3D > 12, tf_err =3D 2, tf_eip =3D 671913639, tf_cs =3D 51, tf_eflags =3D 514, = tf_esp > =3D -1077940732, tf_ss =3D 59}) > at /usr/src/sys/i386/i386/trap.c:983 > #15 0xc061815f in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:200 > #16 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) quit > root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] # >=20 > --- >=20 > Vincent >=20 > On Thu, 2006-11-16 at 16:01 -0500, Kris Kennaway wrote: > > On Thu, Nov 16, 2006 at 05:38:44PM +0100, Vincent Blondel wrote: > > >=20 > > > Hello Kris, > > >=20 > > > You can find below a generic make.conf I use to compile src/ports on = my > > > all machines ( only AMD Athlon XP/MP ). > > >=20 > > > .CPUTYPE !=3D sysctl hw.model |sed 's/ //g' > > > .if ${.CPUTYPE:M*AMDAthlon(tm)XP*} > > > CFLAGS=3D -march=3Dathlon-xp > > > .endif > > > .if ${.CPUTYPE:M*AMDAthlon(tm)MP*} > > > CFLAGS=3D -march=3Dathlon-mp > > > .endif > > > CFLAGS+=3D -O -pipe > > > CFLAGS+=3D -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 > > > .if ${.CURDIR:M/usr/src/*} > > > CFLAGS+=3D -fno-strict-aliasing > > > .endif > > > .if ${.CURDIR:M/usr/ports/*} > > > CFLAGS+=3D -Os -fomit-frame-pointer > > > .endif > > > COPTFLAGS=3D -O -pipe > >=20 > > I think you have the -fno-strict-aliasing backwards, BTW: /usr/src > > should be safe to compile with -fstrict-aliasing (but it's only > > enabled by default at -O2, so that's a NOP for you anyway), but ports > > definitely are not in general. > >=20 > > Also you might as well use CPUTYPE instead of manually setting CFLAGS > > to do the same thing. > >=20 > > Anyway, this doesn't seem to be the cause of your problems so I don't > > know why your backtraces are garbage. Maybe you can try backtracing > > in DDB when you get a panic and see what that says instead. > >=20 > > Kris >=20 >=20 --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXNtMWry0BWjoQKURAlDiAJ4gIJkDnRyibuIxqQxaCP+u7VESnwCgmEdg HWiSPQApUNFWfhQXP8LDPH4= =TqOI -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 21:53:38 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F78C16A415 for ; Thu, 16 Nov 2006 21:53:38 +0000 (UTC) (envelope-from sherwin@sequeira.org.uk) Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C8743D49 for ; Thu, 16 Nov 2006 21:53:37 +0000 (GMT) (envelope-from sherwin@sequeira.org.uk) Received: from comet.sequestor.lan (81-86-227-131.dsl.pipex.com [81.86.227.131]) by galaxy.systems.pipex.net (Postfix) with ESMTP id B9157E000478 for ; Thu, 16 Nov 2006 21:53:35 +0000 (GMT) Received: by comet.sequestor.lan (Postfix, from userid 1000) id 012227DC; Thu, 16 Nov 2006 21:40:12 +0000 (GMT) From: Sherwin Sequeira To: FreeBSD List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Great Holm, Milton Keynes Date: Thu, 16 Nov 2006 21:40:12 +0000 Message-Id: <1163713212.19944.41.camel@comet.sequestor.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Subject: Please disregard - ISP change X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 21:53:38 -0000 Testing email server configuration. Ensuring that everything in postfix's relay table is required. Apologies for the noise -- S. Anthony Sequeira ++ Likewise, the national appetizer, brine-cured herring with raw onions, wins few friends, Germans excepted. -- Darwin Porter "Scandinavia On $50 A Day" ++ From owner-freebsd-stable@FreeBSD.ORG Thu Nov 16 22:39:38 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49FB916A49E for ; Thu, 16 Nov 2006 22:39:38 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id A01F443DCC for ; Thu, 16 Nov 2006 22:38:12 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 457595C64 for ; Fri, 17 Nov 2006 01:37:57 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 220CA5C0E for ; Fri, 17 Nov 2006 01:37:57 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kAGMc0Xb085879 for stable@freebsd.org; Fri, 17 Nov 2006 01:38:00 +0300 (MSK) (envelope-from ru) Date: Fri, 17 Nov 2006 01:38:00 +0300 From: Ruslan Ermilov To: stable@freebsd.org Message-ID: <20061116223800.GA85695@rambler-co.ru> References: <7ad7ddd90611160255m553a471cy41f6c911bdc2a1bf@mail.gmail.com> <20061116150309.GD48412@rambler-co.ru> <20061116191037.GA1515@roadrunner.q.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <20061116191037.GA1515@roadrunner.q.local> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Subject: Re: systat -vm output showing negative total virtual memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 22:39:38 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 16, 2006 at 08:10:37PM +0100, Ulrich Spoerlein wrote: > Ruslan Ermilov wrote: > > sysctl(8) knows that t_vm is in bytes, but for the other stats > > it thinks they are in pages. "systat -vm" thinks they are all > > in bytes. Here's a fix: >=20 > Thanks!, I applied your patch to RELENG_6 >=20 > 22K active VM and 1K shared? Seems pretty low to me... >=20 Actually, the values are also in pages. Below is a new patch to try. The total amount of virtual memory reported is still insane; I think some objects are included in the stats mistakenly, but I'm not yet sure. %%% Index: sbin/sysctl/sysctl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v retrieving revision 1.67.2.7 diff -u -p -r1.67.2.7 sysctl.c --- sbin/sysctl/sysctl.c 8 Sep 2006 09:45:35 -0000 1.67.2.7 +++ sbin/sysctl/sysctl.c 16 Nov 2006 22:23:35 -0000 @@ -395,8 +395,8 @@ S_vmtotal(int l2, void *p) "%hu Sleep: %hu)\n", v->t_rq, v->t_dw, v->t_pw, v->t_sl); printf( - "Virtual Memory:\t\t(Total: %luK, Active %lldK)\n", - (unsigned long)v->t_vm / 1024, + "Virtual Memory:\t\t(Total: %lldK, Active %lldK)\n", + (long long)v->t_vm * pageKilo, (long long)v->t_avm * pageKilo); printf("Real Memory:\t\t(Total: %lldK Active %lldK)\n", (long long)v->t_rm * pageKilo, (long long)v->t_arm * pageKilo); Index: usr.bin/systat/vmstat.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.bin/systat/vmstat.c,v retrieving revision 1.60.2.1 diff -u -p -r1.60.2.1 vmstat.c --- usr.bin/systat/vmstat.c 21 Mar 2006 20:49:50 -0000 1.60.2.1 +++ usr.bin/systat/vmstat.c 16 Nov 2006 22:35:34 -0000 @@ -58,6 +58,7 @@ static const char sccsid[] =3D "@(#)vmstat #include #include #include +#include #include #include #include @@ -135,7 +136,7 @@ static void copyinfo(struct Info *, stru static float cputime(int); static void dinfo(int, int, struct statinfo *, struct statinfo *); static void getinfo(struct Info *); -static void putint(int, int, int, int); +static void putint(intmax_t, int, int, int); static void putfloat(double, int, int, int, int, int); static void putlongdouble(long double, int, int, int, int, int); static int ucount(void); @@ -472,7 +473,7 @@ showkre() putfloat(avenrun[1], STATROW, STATCOL + 23, 6, 2, 0); putfloat(avenrun[2], STATROW, STATCOL + 29, 6, 2, 0); mvaddstr(STATROW, STATCOL + 53, buf); -#define pgtokb(pg) ((pg) * (s.v_page_size / 1024)) +#define pgtokb(pg) ((intmax_t)(unsigned)(pg) * (s.v_page_size / 1024)) putint(pgtokb(total.t_arm), MEMROW + 2, MEMCOL + 3, 8); putint(pgtokb(total.t_armshr), MEMROW + 2, MEMCOL + 11, 8); putint(pgtokb(total.t_avm), MEMROW + 2, MEMCOL + 19, 9); @@ -667,7 +668,8 @@ cputime(indx) =20 static void putint(n, l, lc, w) - int n, l, lc, w; + intmax_t n; + int l, lc, w; { char b[128]; =20 @@ -677,11 +679,11 @@ putint(n, l, lc, w) addch(' '); return; } - snprintf(b, sizeof(b), "%*d", w, n); + snprintf(b, sizeof(b), "%*jd", w, n); if ((int)strlen(b) > w) - snprintf(b, sizeof(b), "%*dk", w - 1, n / 1000); + snprintf(b, sizeof(b), "%*jdk", w - 1, n / 1000); if ((int)strlen(b) > w) - snprintf(b, sizeof(b), "%*dM", w - 1, n / 1000000); + snprintf(b, sizeof(b), "%*jdM", w - 1, n / 1000000); addstr(b); } =20 %%% Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXOhIqRfpzJluFF4RAtBHAJsFdI/ctD226z4CiOSs+4saEy5I7QCbBMqb V1Q2XU77i27P9y7IGGaLQiE= =jNC2 -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 00:39:55 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1B1C16A403 for ; Fri, 17 Nov 2006 00:39:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 5EC9743D49 for ; Fri, 17 Nov 2006 00:39:55 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 14747 invoked by uid 399); 17 Nov 2006 00:39:54 -0000 Received: from localhost (HELO ?192.168.0.7?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 17 Nov 2006 00:39:54 -0000 Message-ID: <455D04D8.60102@FreeBSD.org> Date: Thu, 16 Nov 2006 16:39:52 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061111) MIME-Version: 1.0 To: Sherwin Sequeira References: <1163713212.19944.41.camel@comet.sequestor.lan> In-Reply-To: <1163713212.19944.41.camel@comet.sequestor.lan> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD List Subject: Re: Please disregard - ISP change X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 00:39:56 -0000 Sherwin Sequeira wrote: > Testing email server configuration. > > Ensuring that everything in postfix's relay table is required. > > Apologies for the noise Please don't send these messages to the public lists. There is a freebsd-test list set up for this purpose. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 02:56:07 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19D2816A403 for ; Fri, 17 Nov 2006 02:56:07 +0000 (UTC) (envelope-from jon@seaholm.caamora.com.au) Received: from seaholm.caamora.com.au (seaholm.caamora.com.au [203.7.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F0C143D49 for ; Fri, 17 Nov 2006 02:56:02 +0000 (GMT) (envelope-from jon@seaholm.caamora.com.au) Received: (from jon@localhost) by seaholm.caamora.com.au (8.11.1/8.11.1) id kAH2tYJ29466; Fri, 17 Nov 2006 13:55:34 +1100 (EST) Message-ID: <20061117135534.03936@caamora.com.au> Date: Fri, 17 Nov 2006 13:55:34 +1100 From: jonathan michaels To: freebsd-stable@freebsd.org, eugen@www.svzserv.kemerovo.su References: <20061114084341.GA80973@svzserv.kemerovo.su> <200611141219.kAECJSni029154@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <200611141219.kAECJSni029154@lurza.secnetix.de>; from Oliver Fromme on Tue, Nov 14, 2006 at 01:19:28PM +0100 Organisation: Caamora, PO Box 144, Rosebery NSW 1445 Australia Cc: Subject: Re: Installing 6.2-BETA3 from floppies X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 02:56:07 -0000 On Tue, Nov 14, 2006 at 01:19:28PM +0100, Oliver Fromme wrote: > Eugene Grosbein wrote: > > Eugene Grosbein wrote: > > > I'm trying to install FreeBSD 6.x onto old Packard Bell machine, > > > it is Pentium-166 with 80Mb RAM and 10Gb HDD ("Orlando" motherboard). > > > [...] > > > However, timer does not 'tick' and there is always 10 seconds left. > > > I choose verbose mode, it starts to show its diagnostic output > > > but last line it shows is 'Calibrating clocks...' then it halts: > > > keyboard leds do not switch, there is no reaction on 'Ctrl-Alt-ESC'. > > > > Hmm, I was too quick... The kernel has spent lots of minutes > > 'sitting in this pose' but suddenly said that clock calibration > > has failed and it will use default frequency. > > Apparently the RTC on that mainboard is dead. Did you try > replacing its battery? It's usually a small lithium button > cell, or (on very old boards) a small battery package. > If that doesn't help, I guess the RTC chip itself is broken. on sone pentium pro motherboards manucactured in america, as opposed to those manufactured by american companies located in tiawan .. the 6 or so motherboards that i have seen worked with (clients machines/networks) they all had the cmose/realtime clocks batteries integrated into teh "rtc clock chip" it is some sort of mercury battery, motherboards with that style of rtc clock battery and or cmos battery have only one way to fix teh flat battery, that is to replace teh motherboard with one that has a "normal" battery for the rtc/cmos circuits. sorry for the typing, i'm tyyping blind (just about) at teh monebt. most kind regards jonathan -- ================================================================ powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system ==== === appropriate solution in an inappropriate world === ==== From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 07:05:34 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1365416A403 for ; Fri, 17 Nov 2006 07:05:34 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3119143D5F for ; Fri, 17 Nov 2006 07:05:32 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from localhost (unknown [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 1F27F5C36 for ; Fri, 17 Nov 2006 07:05:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikDf1f7V3KQC for ; Fri, 17 Nov 2006 07:05:29 +0000 (UTC) Received: from [62.84.172.67] (dsl172-67.as6911.net [62.84.172.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 012BD5C34 for ; Fri, 17 Nov 2006 07:05:28 +0000 (UTC) Message-ID: <455D5F38.4060208@joeholden.co.uk> Date: Fri, 17 Nov 2006 07:05:28 +0000 From: Joe Holden User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: (Seemingly) Spontaneous rebooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 07:05:34 -0000 Hi, i'm observing random reboots on a dedicated machine I have with 1&1. I have included as much information as I can think of, if there is anything else I can provide, please ask. dmesg: claire# dmesg Copyright (c) 1992-2006 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 6.2-PRERELEASE #1: Sun Nov 5 14:16:45 UTC 2006 root@claire.ber.rewt.org.uk:/usr/obj/usr/src/sys/claire Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2404.12-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebf9ff Features2=0x400 real memory = 1065353216 (1016 MB) avail memory = 1033650176 (985 MB) kbd1 at kbdmux0 cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 $PIR: No matching entry for 0.16.INTA $PIR: No matching entry for 0.16.INTB $PIR: No matching entry for 0.16.INTD $PIR: No matching entry for 0.18.INTA agp0: mem 0xea000000-0xea3fffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 16.3 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xdc00-0xdc0f at device 17.1 on pci0 ata0: on atapci0 ata1: on atapci0 vr0: port 0xe000-0xe0ff mem 0xea401000-0xea4010ff irq 15 at device 18.0 on pci0 miibus0: on vr0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:40:63:c3:72:02 orm0: at iomem 0xc0000-0xcbfff,0xcc000-0xcffff,0xd0000-0xd17ff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (memory) unknown: can't assign resources (port) Timecounter "TSC" frequency 2404116192 Hz quality 800 Timecounters tick every 1.000 msec ad0: 76319MB at ata0-master UDMA100 Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 556 files 20 WARNING: /var was not properly dismounted uhci0: port 0xd000-0xd01f irq 15 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd400-0xd41f irq 12 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xea400000-0xea4000ff irq 11 at device 16.3 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pciconf -lv: claire# pciconf -lv agp0@pci0:0:0: class=0x060000 card=0xa0031106 chip=0x31481106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8751 ProSavageDDR P4M266 System Controller' class = bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x00000080 chip=0xb0911106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'VT8633 Apollo Pro 266 CPU to AGP Controller' class = bridge subclass = PCI-PCI uhci0@pci0:16:0: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x80 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB uhci1@pci0:16:1: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x80 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82xxxxx UHCI USB 1.1 Controller (All VIA Chipsets)' class = serial bus subclass = USB ehci0@pci0:16:3: class=0x0c0320 card=0x31041106 chip=0x31041106 rev=0x82 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6202 USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB isab0@pci0:17:0: class=0x060100 card=0xa0031106 chip=0x31771106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8235 PCI to ISA Bridge' class = bridge subclass = PCI-ISA atapci0@pci0:17:1: class=0x01018a card=0xa0031106 chip=0x05711106 rev=0x06 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82xxxx EIDE Controller (All VIA Chipsets)' class = mass storage subclass = ATA vr0@pci0:18:0: class=0x020000 card=0x01061106 chip=0x30651106 rev=0x74 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6102 Rhine II PCI Fast Ethernet Controller' class = network subclass = ethernet none0@pci1:0:0: class=0x030000 card=0xa0031106 chip=0x8d045333 rev=0x00 hdr=0x00 vendor = 'S3 Graphics Co., Ltd.' device = '86C420 ProSavage DDR' class = display subclass = VGA uname -a: claire# uname -a FreeBSD claire.ber.rewt.org.uk 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Sun Nov 5 14:16:45 UTC 2006 root@claire.ber.rewt.org.uk:/usr/obj/usr/src/sys/claire i386 df -h: claire# df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad0s1a 496M 61M 395M 13% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s1e 496M 18K 456M 0% /tmp /dev/ad0s1f 70G 5.0G 59G 8% /usr /dev/ad0s1d 1.1G 102M 908M 10% /var devfs 1.0K 1.0K 0B 100% /var/named/dev As a side note: If anyone is wanting to know how to convert their evil 1&1 linux machine to FreeBSD, send me an email and i'll send you the info (I intend to write an article on this eventually) TIA, Joe From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 07:33:00 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E227F16A40F for ; Fri, 17 Nov 2006 07:33:00 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D1743D46 for ; Fri, 17 Nov 2006 07:32:59 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.8/8.13.8) with ESMTP id kAH7WvTX029072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Nov 2006 08:32:57 +0100 (CET) (envelope-from stb@lassitu.de) In-Reply-To: <455D5F38.4060208@joeholden.co.uk> References: <455D5F38.4060208@joeholden.co.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <232F7011-5BCC-4616-82CC-973D1CB41593@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Fri, 17 Nov 2006 08:32:56 +0100 To: Joe Holden X-Mailer: Apple Mail (2.752.2) Cc: freebsd-stable@freebsd.org Subject: Re: (Seemingly) Spontaneous rebooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 07:33:01 -0000 Am 17.11.2006 um 08:05 schrieb Joe Holden: > Hi, i'm observing random reboots on a dedicated machine I have with > 1&1. How do you know it's rebbots as opposed to crashes/panics? Enable crashdumps in rc.conf and see if you get a dump. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 07:38:11 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 923B616A49E for ; Fri, 17 Nov 2006 07:38:11 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2981343D55 for ; Fri, 17 Nov 2006 07:38:02 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from localhost (unknown [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 892AA5C36; Fri, 17 Nov 2006 07:38:01 +0000 (UTC) X-Virus-Scanned: amavisd-new at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+IUbIeErkXS; Fri, 17 Nov 2006 07:37:59 +0000 (UTC) Received: from [62.84.172.67] (dsl172-67.as6911.net [62.84.172.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by claire.ber.rewt.org.uk (Postfix) with ESMTP id CA7495C34; Fri, 17 Nov 2006 07:37:58 +0000 (UTC) Message-ID: <455D66D6.8080708@joeholden.co.uk> Date: Fri, 17 Nov 2006 07:37:58 +0000 From: Joe Holden User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Stefan Bethke References: <455D5F38.4060208@joeholden.co.uk> <232F7011-5BCC-4616-82CC-973D1CB41593@lassitu.de> In-Reply-To: <232F7011-5BCC-4616-82CC-973D1CB41593@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: (Seemingly) Spontaneous rebooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 07:38:11 -0000 Stefan Bethke wrote: > Am 17.11.2006 um 08:05 schrieb Joe Holden: > >> Hi, i'm observing random reboots on a dedicated machine I have with 1&1. > > How do you know it's rebbots as opposed to crashes/panics? Enable > crashdumps in rc.conf and see if you get a dump. > > > Stefan > > --Stefan Bethke Fon +49 170 346 0140 > > The reason why I said (seemingly) spontaneous reboots was because there is nothing in logs, it looks exactly like its just had the reset button hit. I've added to rc.conf, now i've just got to wait for it to crash, which isn't fun as it could be weeks, heh Ta, Joe From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 10:57:05 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 593B316A403 for ; Fri, 17 Nov 2006 10:57:05 +0000 (UTC) (envelope-from eti@erata.net) Received: from s1.net-solution.ro (s1.net-solution.ro [65.98.58.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFA1B43D6A for ; Fri, 17 Nov 2006 10:57:04 +0000 (GMT) (envelope-from eti@erata.net) Received: (qmail 23778 invoked from network); 17 Nov 2006 12:57:04 +0200 Received: from 223.126.77.82.static.cluj.rdsnet.ro (HELO toshiba) (82.77.126.223) by s1.net-solution.ro with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Nov 2006 12:57:04 +0200 From: Iulian M Organization: www.erata.net To: freebsd-stable@freebsd.org Date: Fri, 17 Nov 2006 12:56:50 +0200 User-Agent: KMail/1.9.4 References: <455CD0A9.7040403@free.fr> In-Reply-To: <455CD0A9.7040403@free.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1460869.XiWYE7d8MU"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200611171256.55982.eti@erata.net> Subject: Re: distcc problem (was: Firefox 2 and XFCE) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 10:57:05 -0000 --nextPart1460869.XiWYE7d8MU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 16 November 2006 22:57, VF wrote: > > cat /etc/make.conf > # added by use.perl 2006-10-14 03:14:45 > PERL_VER=3D5.8.8 > PERL_VERSION=3D5.8.8 > CC=3Ddistccc you redefine CC 2 lines below, and i guess its distcc not distccc > MAKE_ARGS=3D-j4 > CC=3D/usr/local/bin/distcc > > > setenv DISTCC_HOSTS=3Dlocalhost 192.168.4.11 > > and of course distcc well installed. > > When i start compilation in ports for exemple in /usr/ports distcc try > to reacch 192.168.4.11 but return an error : > > > #cat /var/log/messages | grep distcc > Nov 14 16:16:32 MOOMOO distccd[825]: (dcc_listen_by_addr) ERROR: bind of > :::3632 failed: Address already in use This means that the distccd (the daemon) its getting run and not distcc ( t= he=20 compiler wrapper), and the daemon is trying to bind to port 3632 witch is=20 already opened by another instance of distccd. =20 My guess is that someware you have something like CC=3Ddistccd witch causes= the=20 daemon to be run on every CC invocation. Hope it helps, PS: what has the subject has to do with distcc ? :) =2D-=20 Best Regards, Iulian Margarintescu (eti) http://www.erata.net eti@erata.net (spamassassin & pf & spamd all said it's OK to make it public ;-) ) Key ID: 0x03176E5CEDEFF7AB I prefer plain text email --nextPart1460869.XiWYE7d8MU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFXZV3AxduXO3v96sRAiL9AKCLypMoUo94W5hyQs5vHcL+i8wMmwCfdvWD ix2y8tWq/ag4WQKPyZcKXGU= =ew1r -----END PGP SIGNATURE----- --nextPart1460869.XiWYE7d8MU-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 11:10:39 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 637BD16A403 for ; Fri, 17 Nov 2006 11:10:39 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from bart.milos.co.za (bart.milos.co.za [196.38.18.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3598443D45 for ; Fri, 17 Nov 2006 11:10:35 +0000 (GMT) (envelope-from clay@milos.co.za) Received: (qmail 43000 invoked by uid 89); 17 Nov 2006 11:10:33 -0000 Received: from unknown (HELO claylaptop) (clay@milos.za.net@192.168.3.150) by bart.milos.co.za with SMTP; 17 Nov 2006 11:10:33 -0000 Message-ID: <019301c70a38$f7a43a50$9603a8c0@claylaptop> From: "Clayton Milos" To: "Lawrence Farr" , References: <003d01c7098e$a96716a0$c806a8c0@lfarr> Date: Fri, 17 Nov 2006 13:10:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: Subject: Re: Areca Weirdness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 11:10:39 -0000 ----- Original Message ----- From: "Lawrence Farr" To: Sent: Thursday, November 16, 2006 4:51 PM Subject: RE: Areca Weirdness > Re-posting to -STABLE as it also does it on i386. > > I reinstalled i386 stable as of yesterday, and newfs'd all the partitions > "just in case". I got it to crash while doing a mkdir on the areca > partition, so set up crash dumps on the boot drive (it boots off a single > ATA disk, the Areca is additional storage) and it died again running > the periodic scripts last night. The info file from the dump shows: > > Dump header from device /dev/ad0s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 2145452032B (2046 MB) > Blocksize: 512 > Dumptime: Thu Nov 16 03:01:09 2006 > Hostname: nas-2.shorewood-epc.co.uk > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 6.1-20061115 #0: Wed Nov 15 04:18:11 UTC 2006 > root@monitor.shorewood-epc.co.uk:/usr/obj/usr/src/sys/SMP > Panic String: ufs_dirbad: bad dir > Dump Parity: 632980830 > Bounds: 0 > Dump Status: good > > Am I expecting too much with partitions over 2Tb? I've never gone over > 2Tb before, so havent come across any issues like this. > >> -----Original Message----- >> From: owner-freebsd-amd64@freebsd.org >> [mailto:owner-freebsd-amd64@freebsd.org] On Behalf Of Lawrence Farr >> Sent: 10 November 2006 11:39 >> To: freebsd-amd64@freebsd.org >> Subject: Areca Weirdness >> >> I've got an Areca 12 port card running a 6Tb array which is divided >> into 2.1Tb chunks at the moment, as it was doing the same with a >> single 6Tb partition. >> >> ad0: 58644MB at ata0-master UDMA100 >> da0 at arcmsr0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-3 device >> da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), >> Tagged Queueing >> Enabled >> da0: 2224922MB (4556640256 512 byte sectors: 255H 63S/T 283637C) >> >> If I newfs it, and copy data to it, I have no problem initially. >> If I then try and copy the data on the disk already to a new >> folder, the machine reboots (it's a remote host with no serial >> attached currently). When it comes back to life, it mounts, and >> shows as: >> >> /dev/da0 2.1T 343G 1.6T 18% /usr/home/areca1 >> >> But is completely empty. Unmounting it and trying to fsck it >> errors, as does mounting it by hand. >> >> [root@nas-2 /home]# fsck -y /dev/da0 >> ** /dev/da0 >> Cannot find file system superblock >> ioctl (GCINFO): Inappropriate ioctl for device >> fsck_ufs: /dev/da0: can't read disk label >> [root@nas-2 /home]# mount /dev/da0 >> mount: /dev/da0 on /usr/home/areca1: incorrect super block >> >> Are there any known issues with the driver on AMD64? I had >> major issues with it on Linux/386 with large memory support >> (it would behave equally strangely) that went away when I >> took large memory support out, maybe there are some non 64 >> bit safe parts common to both? I have the Areca 8 port PCI-X card. 2 arrays of 1.25T each and no issues yet. I've been using it on 5.x for a year and now on 6.x it's perfect too. Have you updated the card to the latest firmware ? I've just done a test copy from the one volume to the other of 10 gigs. It ran at over 80M/s and tok under 2 minutes with no errors. Did you follow the instructions provided with the Areca card for creating volumes over 2TB ? There are some things you have to do so that the OS works correctly with it. -Clay From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 11:21:42 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0557316A417 for ; Fri, 17 Nov 2006 11:21:42 +0000 (UTC) (envelope-from freebsd-stable@epcdirect.co.uk) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9347343D45 for ; Fri, 17 Nov 2006 11:21:41 +0000 (GMT) (envelope-from freebsd-stable@epcdirect.co.uk) Received: from lfarr (l-farr.int.epcdirect.co.uk [192.168.6.200]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 6F7546C8817; Fri, 17 Nov 2006 11:21:40 +0000 (GMT) From: "Lawrence Farr" To: "'Clayton Milos'" , "'Lawrence Farr'" , Date: Fri, 17 Nov 2006 11:21:41 -0000 Message-ID: <01b801c70a3a$8e486ac0$c806a8c0@lfarr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <019301c70a38$f7a43a50$9603a8c0@claylaptop> Thread-Index: AccKOWZadFBczA/KQAS6uUA9fMOyJwAAJrtg Cc: Subject: RE: Areca Weirdness - UFS2 larger than 2Tb problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 11:21:42 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org > [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Clayton Milos > Sent: 17 November 2006 11:10 > To: Lawrence Farr; freebsd-stable@freebsd.org > Subject: Re: Areca Weirdness > > > ----- Original Message ----- > From: "Lawrence Farr" > To: > Sent: Thursday, November 16, 2006 4:51 PM > Subject: RE: Areca Weirdness > > > > Re-posting to -STABLE as it also does it on i386. > > > > I reinstalled i386 stable as of yesterday, and newfs'd all > the partitions > > "just in case". I got it to crash while doing a mkdir on the areca > > partition, so set up crash dumps on the boot drive (it > boots off a single > > ATA disk, the Areca is additional storage) and it died again running > > the periodic scripts last night. The info file from the dump shows: > > > > Dump header from device /dev/ad0s1b > > Architecture: i386 > > Architecture Version: 2 > > Dump Length: 2145452032B (2046 MB) > > Blocksize: 512 > > Dumptime: Thu Nov 16 03:01:09 2006 > > Hostname: nas-2.shorewood-epc.co.uk > > Magic: FreeBSD Kernel Dump > > Version String: FreeBSD 6.1-20061115 #0: Wed Nov 15 > 04:18:11 UTC 2006 > > root@monitor.shorewood-epc.co.uk:/usr/obj/usr/src/sys/SMP > > Panic String: ufs_dirbad: bad dir > > Dump Parity: 632980830 > > Bounds: 0 > > Dump Status: good > > > > Am I expecting too much with partitions over 2Tb? I've > never gone over > > 2Tb before, so havent come across any issues like this. > > > >> -----Original Message----- > >> From: owner-freebsd-amd64@freebsd.org > >> [mailto:owner-freebsd-amd64@freebsd.org] On Behalf Of Lawrence Farr > >> Sent: 10 November 2006 11:39 > >> To: freebsd-amd64@freebsd.org > >> Subject: Areca Weirdness > >> > >> I've got an Areca 12 port card running a 6Tb array which is divided > >> into 2.1Tb chunks at the moment, as it was doing the same with a > >> single 6Tb partition. > >> > >> ad0: 58644MB at ata0-master UDMA100 > >> da0 at arcmsr0 bus 0 target 0 lun 0 > >> da0: Fixed Direct Access SCSI-3 device > >> da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), > >> Tagged Queueing > >> Enabled > >> da0: 2224922MB (4556640256 512 byte sectors: 255H 63S/T 283637C) > >> > >> If I newfs it, and copy data to it, I have no problem initially. > >> If I then try and copy the data on the disk already to a new > >> folder, the machine reboots (it's a remote host with no serial > >> attached currently). When it comes back to life, it mounts, and > >> shows as: > >> > >> /dev/da0 2.1T 343G 1.6T 18% /usr/home/areca1 > >> > >> But is completely empty. Unmounting it and trying to fsck it > >> errors, as does mounting it by hand. > >> > >> [root@nas-2 /home]# fsck -y /dev/da0 > >> ** /dev/da0 > >> Cannot find file system superblock > >> ioctl (GCINFO): Inappropriate ioctl for device > >> fsck_ufs: /dev/da0: can't read disk label > >> [root@nas-2 /home]# mount /dev/da0 > >> mount: /dev/da0 on /usr/home/areca1: incorrect super block > >> > >> Are there any known issues with the driver on AMD64? I had > >> major issues with it on Linux/386 with large memory support > >> (it would behave equally strangely) that went away when I > >> took large memory support out, maybe there are some non 64 > >> bit safe parts common to both? > > I have the Areca 8 port PCI-X card. 2 arrays of 1.25T each > and no issues > yet. I've been using it on 5.x for a year and now on 6.x it's > perfect too. > Have you updated the card to the latest firmware ? > > I've just done a test copy from the one volume to the other > of 10 gigs. It > ran at over 80M/s and tok under 2 minutes with no errors. > > Did you follow the instructions provided with the Areca card > for creating > volumes over 2TB ? There are some things you have to do so > that the OS works > correctly with it. > > -Clay I'm not convinced it's an Areca problem anymore, as I've copied 300 or so Gb on now, but it will randomly corrupt the fs and reboot itself. Background fsck will not fix it, but a manual one does. I'm going to drop the partitions below 2Tb and try the test again to try and eliminate any hardware/driver issues. From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 11:25:11 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA4B16A5BE for ; Fri, 17 Nov 2006 11:25:11 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (www.unsane.co.uk [85.233.185.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id C49D243DA8 for ; Fri, 17 Nov 2006 11:25:06 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from [192.168.10.217] (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.13.7/8.13.3) with ESMTP id kAHBOvnv057656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Nov 2006 11:25:01 GMT (envelope-from jhary@unsane.co.uk) Message-ID: <455D9C01.3000905@unsane.co.uk> Date: Fri, 17 Nov 2006 11:24:49 +0000 From: Vince User-Agent: Thunderbird 1.5.0.7 (X11/20061017) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: gjournal on 6.x wont build X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 11:25:11 -0000 Hi all, I was intending on trying out gjournal on a new disk i've added in my desktop. I had a look to see what the most recent patch provided by Pawel and found http://people.freebsd.org/~pjd/patches/gjournal6_20061024.patch I created the directories as per Pawel's original post (http://lists.freebsd.org/pipermail/freebsd-fs/2006-June/001962.html) and the patch succeeded with no failed hunks, however adding options GEOM_JOURNAL options UFS_GJOURNAL to my kernel config then doing a make buildkernel KERNCONF=MYKERNELCONF errors out with /journal/g_journal.c /usr/src/sys/geom/journal/g_journal.c: In function `g_journal_do_switch': /usr/src/sys/geom/journal/g_journal.c:2872: error: structure has no member named `mnt_gjprovider' /usr/src/sys/geom/journal/g_journal.c:2885: error: structure has no member named `mnt_gjprovider' /usr/src/sys/geom/journal/g_journal.c:2890: error: structure has no member named `mnt_gjprovider' *** Error code 1 This is on a recent 6-stable system 6.2-PRERELEASE #1: Fri Nov 10 14:31:47 GMT 2006 any idea what ive done wrong ? Cheers, Vince From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 11:48:04 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8845916A403 for ; Fri, 17 Nov 2006 11:48:04 +0000 (UTC) (envelope-from dom@helenmarks.co.uk) Received: from mailhost.graphdata.co.uk (mailhost.graphdata.co.uk [195.12.22.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AFF443D46 for ; Fri, 17 Nov 2006 11:48:03 +0000 (GMT) (envelope-from dom@helenmarks.co.uk) Received: from localhost (localhost [127.0.0.1]) by mailhost.graphdata.co.uk (Postfix) with ESMTP id 7D66A114037; Fri, 17 Nov 2006 11:48:00 +0000 (GMT) X-Virus-Scanned: amavisd-new at graphdata.co.uk Received: from mailhost.graphdata.co.uk ([127.0.0.1]) by localhost (mailhost.graphdata.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZY6X43PDZ+z; Fri, 17 Nov 2006 11:47:55 +0000 (GMT) Received: from gdc083.internal.graphdata.co.uk (gdc083.internal.graphdata.co.uk [192.168.0.86]) by mailhost.graphdata.co.uk (Postfix) with SMTP id 2A36A11402F; Fri, 17 Nov 2006 11:47:55 +0000 (GMT) Date: Fri, 17 Nov 2006 11:47:54 +0000 From: Dominic Marks To: Joe Holden Message-Id: <20061117114754.dafdbc1a.dom@helenmarks.co.uk> In-Reply-To: <455D66D6.8080708@joeholden.co.uk> References: <455D5F38.4060208@joeholden.co.uk> <232F7011-5BCC-4616-82CC-973D1CB41593@lassitu.de> <455D66D6.8080708@joeholden.co.uk> X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: (Seemingly) Spontaneous rebooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 11:48:04 -0000 On Fri, 17 Nov 2006 07:37:58 +0000 Joe Holden wrote: > Stefan Bethke wrote: > > Am 17.11.2006 um 08:05 schrieb Joe Holden: > > > >> Hi, i'm observing random reboots on a dedicated machine I have with 1&1. > > > > How do you know it's rebbots as opposed to crashes/panics? Enable > > crashdumps in rc.conf and see if you get a dump. > > > > > > Stefan > > > > --Stefan Bethke Fon +49 170 346 0140 > > > > > The reason why I said (seemingly) spontaneous reboots was because there > is nothing in logs, it looks exactly like its just had the reset button hit. > > I've added to rc.conf, now i've just got to wait for it to crash, which > isn't fun as it could be weeks, heh See if you can get temperature readings from the hardware. Is the system busy? Dominic > Ta, > Joe > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 13:14:52 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B76E16A407 for ; Fri, 17 Nov 2006 13:14:52 +0000 (UTC) (envelope-from Philippe.Pegon@crc.u-strasbg.fr) Received: from mailhost.u-strasbg.fr (mailhost.u-strasbg.fr [130.79.200.154]) by mx1.FreeBSD.org (Postfix) with ESMTP id C550E43D53 for ; Fri, 17 Nov 2006 13:14:50 +0000 (GMT) (envelope-from Philippe.Pegon@crc.u-strasbg.fr) Received: from [IPv6:2001:660:2402:1001:20e:cff:fe60:e734] (apophis.u-strasbg.fr [IPv6:2001:660:2402:1001:20e:cff:fe60:e734]) by mailhost.u-strasbg.fr (8.13.8/jtpda-5.5pre1) with ESMTP id kAHDEhRx063467 ; Fri, 17 Nov 2006 14:14:43 +0100 (CET) Message-ID: <455DB601.8060306@crc.u-strasbg.fr> Date: Fri, 17 Nov 2006 14:15:45 +0100 From: Philippe Pegon User-Agent: Thunderbird 1.5.0.8 (X11/20061113) MIME-Version: 1.0 To: Vince References: <455D9C01.3000905@unsane.co.uk> In-Reply-To: <455D9C01.3000905@unsane.co.uk> Content-Type: multipart/mixed; boundary="------------090106030108050203020100" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::154]); Fri, 17 Nov 2006 14:14:43 +0100 (CET) X-Virus-Scanned: ClamAV 0.88.5/2201/Fri Nov 17 13:16:33 2006 on mr4.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,NO_RELAYS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on mr4.u-strasbg.fr Cc: freebsd-stable@freebsd.org Subject: Re: gjournal on 6.x wont build X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 13:14:52 -0000 This is a multi-part message in MIME format. --------------090106030108050203020100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Vince wrote: > Hi all, Hi, > I was intending on trying out gjournal on a new disk i've added in my > desktop. I had a look to see what the most recent patch provided by > Pawel and found > http://people.freebsd.org/~pjd/patches/gjournal6_20061024.patch > I created the directories as per Pawel's original post > (http://lists.freebsd.org/pipermail/freebsd-fs/2006-June/001962.html) > and the patch succeeded with no failed hunks, however adding > options GEOM_JOURNAL > options UFS_GJOURNAL > > to my kernel config > then doing a make buildkernel KERNCONF=MYKERNELCONF > > errors out with > /journal/g_journal.c > /usr/src/sys/geom/journal/g_journal.c: In function `g_journal_do_switch': > /usr/src/sys/geom/journal/g_journal.c:2872: error: structure has no > member named `mnt_gjprovider' > /usr/src/sys/geom/journal/g_journal.c:2885: error: structure has no > member named `mnt_gjprovider' > /usr/src/sys/geom/journal/g_journal.c:2890: error: structure has no > member named `mnt_gjprovider' > *** Error code 1 > > This is on a recent 6-stable system > 6.2-PRERELEASE #1: Fri Nov 10 14:31:47 GMT 2006 > any idea what ive done wrong ? the latest patch (gjournal6_20061024.patch) doesn't apply cleanly on fresh RELENG_6 due to the last commit on mount.h : http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/mount.h?only_with_tag=RELENG_6 I have slightly modified the patch so that it works (see attach) > Cheers, > Vince -- Philippe Pegon --------------090106030108050203020100 Content-Type: text/plain; name="gjournal6_20061030.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gjournal6_20061030.patch" --- etc/mtree/BSD.include.dist.orig +++ etc/mtree/BSD.include.dist @@ -102,6 +102,8 @@ .. gate .. + journal + .. label .. mirror --- include/Makefile.orig +++ include/Makefile @@ -42,8 +42,8 @@ fs/devfs fs/fdescfs fs/fifofs fs/msdosfs fs/ntfs fs/nullfs \ fs/nwfs fs/portalfs fs/procfs fs/smbfs fs/udf fs/umapfs \ fs/unionfs \ - geom/concat geom/eli geom/gate geom/label geom/mirror geom/nop \ - geom/raid3 geom/shsec geom/stripe \ + geom/concat geom/eli geom/gate geom/journal geom/label geom/mirror \ + geom/nop geom/raid3 geom/shsec geom/stripe \ isofs/cd9660 \ netatm/ipatm netatm/sigpvc netatm/spans netatm/uni \ netgraph/atm netgraph/netflow \ --- lib/libufs/Makefile.orig +++ lib/libufs/Makefile @@ -7,6 +7,7 @@ MAN= bread.3 cgread.3 libufs.3 sbread.3 ufs_disk_close.3 MLINKS+= bread.3 bwrite.3 MLINKS+= cgread.3 cgread1.3 +MLINKS+= cgread.3 cgwrite1.3 MLINKS+= sbread.3 sbwrite.3 MLINKS+= ufs_disk_close.3 ufs_disk_fillout.3 MLINKS+= ufs_disk_close.3 ufs_disk_fillout_blank.3 --- lib/libufs/cgread.3.orig +++ lib/libufs/cgread.3 @@ -4,6 +4,7 @@ .\" Manual page for libufs functions: .\" cgread(3) .\" cgread1(3) +.\" cgwrite1(3) .\" .\" This file is in the public domain. .\" @@ -13,8 +14,8 @@ .Dt CGREAD 3 .Os .Sh NAME -.Nm cgread , cgread1 -.Nd read cylinder groups of UFS disks +.Nm cgread , cgread1, cgwrite1 +.Nd read/write cylinder groups of UFS disks .Sh LIBRARY .Lb libufs .Sh SYNOPSIS @@ -28,6 +29,8 @@ .Fn cgread "struct uufsd *disk" .Ft int .Fn cgread1 "struct uufsd *disk" "int c" +.Ft int +.Fn cgwrite1 "struct uufsd *disk" "int c" .Sh DESCRIPTION The .Fn cgread @@ -60,6 +63,14 @@ field, and then incrementing the .Va d_ccg field. +.Pp +The +.Fn cgwrite1 +function stores cylinder group specified by +.Fa c +from +.Va d_cg +field of a userland UFS disk structure on disk. .Sh RETURN VALUES Both functions return 0 if there are no more cylinder groups to read, 1 if there are more cylinder groups, and \-1 on error. @@ -75,8 +86,16 @@ .Fn cgread1 has semantically identical failure conditions to those of .Fn cgread . +.Pp +The function +.Fn cgwrite1 +may fail and set +.Va errno +for any of the errors specified for the library function +.Xr bwrite 3 . .Sh SEE ALSO .Xr bread 3 , +.Xr bwrite 3 , .Xr libufs 3 .Sh HISTORY These functions first appeared as part of --- lib/libufs/cgroup.c.orig +++ lib/libufs/cgroup.c @@ -71,3 +71,17 @@ disk->d_lcg = c; return (1); } + +int +cgwrite1(struct uufsd *disk, int c) +{ + struct fs *fs; + + fs = &disk->d_fs; + if (bwrite(disk, fsbtodb(fs, cgtod(fs, c)), + disk->d_cgunion.d_buf, fs->fs_bsize) == -1) { + ERROR(disk, "unable to write cylinder group"); + return (-1); + } + return (0); +} --- lib/libufs/libufs.3.orig +++ lib/libufs/libufs.3 @@ -57,6 +57,7 @@ .Xr bwrite 3 , .Xr cgread 3 , .Xr cgread1 3 , +.Xr cgwrite1 3 , .Xr sbread 3 , .Xr sbwrite 3 , .Xr ufs_disk_close 3 , --- lib/libufs/libufs.h.orig +++ lib/libufs/libufs.h @@ -110,6 +110,7 @@ */ int cgread(struct uufsd *); int cgread1(struct uufsd *, int); +int cgwrite1(struct uufsd *, int); /* * inode.c --- sbin/dumpfs/dumpfs.c.orig +++ sbin/dumpfs/dumpfs.c @@ -168,8 +168,9 @@ (intmax_t)afs.fs_cstotal.cs_ndir, (intmax_t)afs.fs_cstotal.cs_nifree, (intmax_t)afs.fs_cstotal.cs_nffree); - printf("bpg\t%d\tfpg\t%d\tipg\t%d\n", - afs.fs_fpg / afs.fs_frag, afs.fs_fpg, afs.fs_ipg); + printf("bpg\t%d\tfpg\t%d\tipg\t%d\tunrefs\t%jd\n", + afs.fs_fpg / afs.fs_frag, afs.fs_fpg, afs.fs_ipg, + (intmax_t)afs.fs_unrefs); printf("nindir\t%d\tinopb\t%d\tmaxfilesize\t%ju\n", afs.fs_nindir, afs.fs_inopb, (uintmax_t)afs.fs_maxfilesize); @@ -228,10 +229,12 @@ printf("acls "); if (fsflags & FS_MULTILABEL) printf("multilabel "); + if (fsflags & FS_GJOURNAL) + printf("gjournal "); if (fsflags & FS_FLAGS_UPDATED) printf("fs_flags expanded "); fsflags &= ~(FS_UNCLEAN | FS_DOSOFTDEP | FS_NEEDSFSCK | FS_INDEXDIRS | - FS_ACLS | FS_MULTILABEL | FS_FLAGS_UPDATED); + FS_ACLS | FS_MULTILABEL | FS_GJOURNAL | FS_FLAGS_UPDATED); if (fsflags != 0) printf("unknown flags (%#x)", fsflags); putchar('\n'); @@ -282,8 +285,9 @@ cgtime = acg.cg_time; printf("magic\t%x\ttell\t%jx\ttime\t%s", acg.cg_magic, (intmax_t)cur, ctime(&cgtime)); - printf("cgx\t%d\tndblk\t%d\tniblk\t%d\tinitiblk %d\n", - acg.cg_cgx, acg.cg_ndblk, acg.cg_niblk, acg.cg_initediblk); + printf("cgx\t%d\tndblk\t%d\tniblk\t%d\tinitiblk %d\tunrefs %d\n", + acg.cg_cgx, acg.cg_ndblk, acg.cg_niblk, acg.cg_initediblk, + acg.cg_unrefs); break; case 1: cgtime = acg.cg_old_time; --- sbin/fsck_ffs/Makefile.orig +++ sbin/fsck_ffs/Makefile @@ -7,7 +7,9 @@ MAN= fsck_ffs.8 MLINKS= fsck_ffs.8 fsck_ufs.8 fsck_ffs.8 fsck_4.2bsd.8 SRCS= dir.c ea.c fsutil.c inode.c main.c pass1.c pass1b.c pass2.c pass3.c \ - pass4.c pass5.c setup.c utilities.c ffs_subr.c ffs_tables.c + pass4.c pass5.c setup.c utilities.c ffs_subr.c ffs_tables.c gjournal.c +DPADD= ${LIBUFS} +LDADD= -lufs WARNS?= 2 CFLAGS+= -I${.CURDIR} --- sbin/fsck_ffs/fsck.h.orig +++ sbin/fsck_ffs/fsck.h @@ -328,9 +328,9 @@ ino_t allocino(ino_t request, int type); void blkerror(ino_t ino, const char *type, ufs2_daddr_t blk); char *blockcheck(char *name); -int bread(int fd, char *buf, ufs2_daddr_t blk, long size); +int blread(int fd, char *buf, ufs2_daddr_t blk, long size); void bufinit(void); -void bwrite(int fd, char *buf, ufs2_daddr_t blk, long size); +void blwrite(int fd, char *buf, ufs2_daddr_t blk, long size); void cacheino(union dinode *dp, ino_t inumber); void catch(int); void catchquit(int); @@ -388,3 +388,4 @@ void sblock_init(void); void setinodebuf(ino_t); int setup(char *dev); +void gjournal_check(const char *filesys); --- sbin/fsck_ffs/fsutil.c.orig +++ sbin/fsck_ffs/fsutil.c @@ -221,7 +221,7 @@ if (bp->b_bno != dblk) { flush(fswritefd, bp); diskreads++; - bp->b_errs = bread(fsreadfd, bp->b_un.b_buf, dblk, size); + bp->b_errs = blread(fsreadfd, bp->b_un.b_buf, dblk, size); bp->b_bno = dblk; bp->b_size = size; } @@ -244,11 +244,11 @@ (bp->b_errs == bp->b_size / dev_bsize) ? "" : "PARTIALLY ", (long long)bp->b_bno); bp->b_errs = 0; - bwrite(fd, bp->b_un.b_buf, bp->b_bno, (long)bp->b_size); + blwrite(fd, bp->b_un.b_buf, bp->b_bno, (long)bp->b_size); if (bp != &sblk) return; for (i = 0, j = 0; i < sblock.fs_cssize; i += sblock.fs_bsize, j++) { - bwrite(fswritefd, (char *)sblock.fs_csp + i, + blwrite(fswritefd, (char *)sblock.fs_csp + i, fsbtodb(&sblock, sblock.fs_csaddr + j * sblock.fs_frag), sblock.fs_cssize - i < sblock.fs_bsize ? sblock.fs_cssize - i : sblock.fs_bsize); @@ -345,7 +345,7 @@ } int -bread(int fd, char *buf, ufs2_daddr_t blk, long size) +blread(int fd, char *buf, ufs2_daddr_t blk, long size) { char *cp; int i, errs; @@ -387,7 +387,7 @@ } void -bwrite(int fd, char *buf, ufs2_daddr_t blk, long size) +blwrite(int fd, char *buf, ufs2_daddr_t blk, long size) { int i; char *cp; --- /dev/null Tue Oct 24 16:33:50 2006 +++ sbin/fsck_ffs/gjournal.c Tue Oct 24 16:33:58 2006 @@ -0,0 +1,774 @@ +/*- + * Copyright (c) 2006 Pawel Jakub Dawidek + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * Copyright (c) 1982, 1986, 1989, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "fsck.h" + +struct cgchain { + union { + struct cg cgcu_cg; + char cgcu_buf[MAXBSIZE]; + } cgc_union; + int cgc_busy; + int cgc_dirty; + LIST_ENTRY(cgchain) cgc_next; +}; +#define cgc_cg cgc_union.cgcu_cg + +#define MAX_CACHED_CGS 1024 +static unsigned ncgs = 0; +static LIST_HEAD(, cgchain) cglist = LIST_HEAD_INITIALIZER(&cglist); + +static const char *devnam; +static struct uufsd *disk = NULL; +static struct fs *fs = NULL; +struct ufs2_dinode ufs2_zino; + +static void putcgs(void); + +/* + * Write current block of inodes. + */ +static int +putino(struct uufsd *disk, ino_t inode) +{ + caddr_t inoblock; + struct fs *fs; + ssize_t ret; + + fs = &disk->d_fs; + inoblock = disk->d_inoblock; + + assert(inoblock != NULL); + assert(inode >= disk->d_inomin && inode <= disk->d_inomax); + ret = bwrite(disk, fsbtodb(fs, ino_to_fsba(fs, inode)), inoblock, + fs->fs_bsize); + + return (ret == -1 ? -1 : 0); +} + +/* + * Return cylinder group from the cache or load it if it is not in the + * cache yet. + * Don't cache more than MAX_CACHED_CGS cylinder groups. + */ +static struct cgchain * +getcg(int cg) +{ + struct cgchain *cgc; + + assert(disk != NULL && fs != NULL); + LIST_FOREACH(cgc, &cglist, cgc_next) { + if (cgc->cgc_cg.cg_cgx == cg) { + //printf("%s: Found cg=%d\n", __func__, cg); + return (cgc); + } + } + /* + * Our cache is full? Let's clean it up. + */ + if (ncgs >= MAX_CACHED_CGS) { + //printf("%s: Flushing CGs.\n", __func__); + putcgs(); + } + cgc = malloc(sizeof(*cgc)); + if (cgc == NULL) { + /* + * Cannot allocate memory? + * Let's put all currently loaded and not busy cylinder groups + * on disk and try again. + */ + //printf("%s: No memory, flushing CGs.\n", __func__); + putcgs(); + cgc = malloc(sizeof(*cgc)); + if (cgc == NULL) + err(1, "malloc(%zu)", sizeof(*cgc)); + } + if (cgread1(disk, cg) == -1) + err(1, "cgread1(%d)", cg); + bcopy(&disk->d_cg, &cgc->cgc_cg, sizeof(cgc->cgc_union)); + cgc->cgc_busy = 0; + cgc->cgc_dirty = 0; + LIST_INSERT_HEAD(&cglist, cgc, cgc_next); + ncgs++; + //printf("%s: Read cg=%d\n", __func__, cg); + return (cgc); +} + +/* + * Mark cylinder group as dirty - it will be written back on putcgs(). + */ +static void +dirtycg(struct cgchain *cgc) +{ + + cgc->cgc_dirty = 1; +} + +/* + * Mark cylinder group as busy - it will not be freed on putcgs(). + */ +static void +busycg(struct cgchain *cgc) +{ + + cgc->cgc_busy = 1; +} + +/* + * Unmark the given cylinder group as busy. + */ +static void +unbusycg(struct cgchain *cgc) +{ + + cgc->cgc_busy = 0; +} + +/* + * Write back all dirty cylinder groups. + * Free all non-busy cylinder groups. + */ +static void +putcgs(void) +{ + struct cgchain *cgc, *cgc2; + + assert(disk != NULL && fs != NULL); + LIST_FOREACH_SAFE(cgc, &cglist, cgc_next, cgc2) { + if (cgc->cgc_busy) + continue; + LIST_REMOVE(cgc, cgc_next); + ncgs--; + if (cgc->cgc_dirty) { + bcopy(&cgc->cgc_cg, &disk->d_cg, + sizeof(cgc->cgc_union)); + if (cgwrite1(disk, cgc->cgc_cg.cg_cgx) == -1) + err(1, "cgwrite1(%d)", cgc->cgc_cg.cg_cgx); + //printf("%s: Wrote cg=%d\n", __func__, + // cgc->cgc_cg.cg_cgx); + } + free(cgc); + } +} + +#if 0 +/* + * Free all non-busy cylinder groups without storing the dirty ones. + */ +static void +cancelcgs(void) +{ + struct cgchain *cgc; + + assert(disk != NULL && fs != NULL); + while ((cgc = LIST_FIRST(&cglist)) != NULL) { + if (cgc->cgc_busy) + continue; + LIST_REMOVE(cgc, cgc_next); + //printf("%s: Canceled cg=%d\n", __func__, cgc->cgc_cg.cg_cgx); + free(cgc); + } +} +#endif + +/* + * Open the given provider, load statistics. + */ +static void +getdisk(void) +{ + int i; + + if (disk != NULL) + return; + disk = malloc(sizeof(*disk)); + if (disk == NULL) + err(1, "malloc(%zu)", sizeof(*disk)); + if (ufs_disk_fillout(disk, devnam) == -1) { + err(1, "ufs_disk_fillout(%s) failed: %s", devnam, + disk->d_error); + } + fs = &disk->d_fs; + fs->fs_csp = malloc((size_t)fs->fs_cssize); + if (fs->fs_csp == NULL) + err(1, "malloc(%zu)", (size_t)fs->fs_cssize); + bzero(fs->fs_csp, (size_t)fs->fs_cssize); + for (i = 0; i < fs->fs_cssize; i += fs->fs_bsize) { + if (bread(disk, fsbtodb(fs, fs->fs_csaddr + numfrags(fs, i)), + (void *)(((char *)fs->fs_csp) + i), + (size_t)(fs->fs_cssize - i < fs->fs_bsize ? fs->fs_cssize - i : fs->fs_bsize)) == -1) { + err(1, "bread: %s", disk->d_error); + } + } + if (fs->fs_contigsumsize > 0) { + fs->fs_maxcluster = malloc(fs->fs_ncg * sizeof(int32_t)); + if (fs->fs_maxcluster == NULL) + err(1, "malloc(%zu)", fs->fs_ncg * sizeof(int32_t)); + for (i = 0; i < fs->fs_ncg; i++) + fs->fs_maxcluster[i] = fs->fs_contigsumsize; + } +} + +/* + * Mark file system as clean, write the super-block back, close the disk. + */ +static void +closedisk(void) +{ + + free(fs->fs_csp); + if (fs->fs_contigsumsize > 0) { + free(fs->fs_maxcluster); + fs->fs_maxcluster = NULL; + } + fs->fs_clean = 1; + if (sbwrite(disk, 0) == -1) + err(1, "sbwrite(%s)", devnam); + if (ufs_disk_close(disk) == -1) + err(1, "ufs_disk_close(%s)", devnam); + free(disk); + disk = NULL; + fs = NULL; +} + +/* + * Write the statistics back, call closedisk(). + */ +static void +putdisk(void) +{ + int i; + + assert(disk != NULL && fs != NULL); + for (i = 0; i < fs->fs_cssize; i += fs->fs_bsize) { + if (bwrite(disk, fsbtodb(fs, fs->fs_csaddr + numfrags(fs, i)), + (void *)(((char *)fs->fs_csp) + i), + (size_t)(fs->fs_cssize - i < fs->fs_bsize ? fs->fs_cssize - i : fs->fs_bsize)) == -1) { + err(1, "bwrite: %s", disk->d_error); + } + } + closedisk(); +} + +#if 0 +/* + * Free memory, close the disk, but don't write anything back. + */ +static void +canceldisk(void) +{ + int i; + + assert(disk != NULL && fs != NULL); + free(fs->fs_csp); + if (fs->fs_contigsumsize > 0) + free(fs->fs_maxcluster); + if (ufs_disk_close(disk) == -1) + err(1, "ufs_disk_close(%s)", devnam); + free(disk); + disk = NULL; + fs = NULL; +} +#endif + +static int +isblock(unsigned char *cp, ufs1_daddr_t h) +{ + unsigned char mask; + + switch ((int)fs->fs_frag) { + case 8: + return (cp[h] == 0xff); + case 4: + mask = 0x0f << ((h & 0x1) << 2); + return ((cp[h >> 1] & mask) == mask); + case 2: + mask = 0x03 << ((h & 0x3) << 1); + return ((cp[h >> 2] & mask) == mask); + case 1: + mask = 0x01 << (h & 0x7); + return ((cp[h >> 3] & mask) == mask); + default: + assert(!"isblock: invalid number of fragments"); + } + return (0); +} + +/* + * put a block into the map + */ +static void +setblock(unsigned char *cp, ufs1_daddr_t h) +{ + + switch ((int)fs->fs_frag) { + case 8: + cp[h] = 0xff; + return; + case 4: + cp[h >> 1] |= (0x0f << ((h & 0x1) << 2)); + return; + case 2: + cp[h >> 2] |= (0x03 << ((h & 0x3) << 1)); + return; + case 1: + cp[h >> 3] |= (0x01 << (h & 0x7)); + return; + default: + assert(!"setblock: invalid number of fragments"); + } +} + +/* + * check if a block is free + */ +static int +isfreeblock(u_char *cp, ufs1_daddr_t h) +{ + + switch ((int)fs->fs_frag) { + case 8: + return (cp[h] == 0); + case 4: + return ((cp[h >> 1] & (0x0f << ((h & 0x1) << 2))) == 0); + case 2: + return ((cp[h >> 2] & (0x03 << ((h & 0x3) << 1))) == 0); + case 1: + return ((cp[h >> 3] & (0x01 << (h & 0x7))) == 0); + default: + assert(!"isfreeblock: invalid number of fragments"); + } + return (0); +} + +/* + * Update the frsum fields to reflect addition or deletion + * of some frags. + */ +void +fragacct(int fragmap, int32_t fraglist[], int cnt) +{ + int inblk; + int field, subfield; + int siz, pos; + + inblk = (int)(fragtbl[fs->fs_frag][fragmap]) << 1; + fragmap <<= 1; + for (siz = 1; siz < fs->fs_frag; siz++) { + if ((inblk & (1 << (siz + (fs->fs_frag % NBBY)))) == 0) + continue; + field = around[siz]; + subfield = inside[siz]; + for (pos = siz; pos <= fs->fs_frag; pos++) { + if ((fragmap & field) == subfield) { + fraglist[siz] += cnt; + pos += siz; + field <<= siz; + subfield <<= siz; + } + field <<= 1; + subfield <<= 1; + } + } +} + +static void +clusteracct(struct cg *cgp, ufs1_daddr_t blkno) +{ + int32_t *sump; + int32_t *lp; + u_char *freemapp, *mapp; + int i, start, end, forw, back, map, bit; + + if (fs->fs_contigsumsize <= 0) + return; + freemapp = cg_clustersfree(cgp); + sump = cg_clustersum(cgp); + /* + * Clear the actual block. + */ + setbit(freemapp, blkno); + /* + * Find the size of the cluster going forward. + */ + start = blkno + 1; + end = start + fs->fs_contigsumsize; + if (end >= cgp->cg_nclusterblks) + end = cgp->cg_nclusterblks; + mapp = &freemapp[start / NBBY]; + map = *mapp++; + bit = 1 << (start % NBBY); + for (i = start; i < end; i++) { + if ((map & bit) == 0) + break; + if ((i & (NBBY - 1)) != (NBBY - 1)) { + bit <<= 1; + } else { + map = *mapp++; + bit = 1; + } + } + forw = i - start; + /* + * Find the size of the cluster going backward. + */ + start = blkno - 1; + end = start - fs->fs_contigsumsize; + if (end < 0) + end = -1; + mapp = &freemapp[start / NBBY]; + map = *mapp--; + bit = 1 << (start % NBBY); + for (i = start; i > end; i--) { + if ((map & bit) == 0) + break; + if ((i & (NBBY - 1)) != 0) { + bit >>= 1; + } else { + map = *mapp--; + bit = 1 << (NBBY - 1); + } + } + back = start - i; + /* + * Account for old cluster and the possibly new forward and + * back clusters. + */ + i = back + forw + 1; + if (i > fs->fs_contigsumsize) + i = fs->fs_contigsumsize; + sump[i]++; + if (back > 0) + sump[back]--; + if (forw > 0) + sump[forw]--; + /* + * Update cluster summary information. + */ + lp = &sump[fs->fs_contigsumsize]; + for (i = fs->fs_contigsumsize; i > 0; i--) + if (*lp-- > 0) + break; + fs->fs_maxcluster[cgp->cg_cgx] = i; +} + +static void +blkfree(ufs2_daddr_t bno, long size) +{ + struct cgchain *cgc; + struct cg *cgp; + ufs1_daddr_t fragno, cgbno; + int i, cg, blk, frags, bbase; + u_int8_t *blksfree; + + cg = dtog(fs, bno); + cgc = getcg(cg); + dirtycg(cgc); + cgp = &cgc->cgc_cg; + cgbno = dtogd(fs, bno); + blksfree = cg_blksfree(cgp); + if (size == fs->fs_bsize) { + fragno = fragstoblks(fs, cgbno); + if (!isfreeblock(blksfree, fragno)) + assert(!"blkfree: freeing free block"); + setblock(blksfree, fragno); + clusteracct(cgp, fragno); + cgp->cg_cs.cs_nbfree++; + fs->fs_cstotal.cs_nbfree++; + fs->fs_cs(fs, cg).cs_nbfree++; + } else { + bbase = cgbno - fragnum(fs, cgbno); + /* + * decrement the counts associated with the old frags + */ + blk = blkmap(fs, blksfree, bbase); + fragacct(blk, cgp->cg_frsum, -1); + /* + * deallocate the fragment + */ + frags = numfrags(fs, size); + for (i = 0; i < frags; i++) { + if (isset(blksfree, cgbno + i)) + assert(!"blkfree: freeing free frag"); + setbit(blksfree, cgbno + i); + } + cgp->cg_cs.cs_nffree += i; + fs->fs_cstotal.cs_nffree += i; + fs->fs_cs(fs, cg).cs_nffree += i; + /* + * add back in counts associated with the new frags + */ + blk = blkmap(fs, blksfree, bbase); + fragacct(blk, cgp->cg_frsum, 1); + /* + * if a complete block has been reassembled, account for it + */ + fragno = fragstoblks(fs, bbase); + if (isblock(blksfree, fragno)) { + cgp->cg_cs.cs_nffree -= fs->fs_frag; + fs->fs_cstotal.cs_nffree -= fs->fs_frag; + fs->fs_cs(fs, cg).cs_nffree -= fs->fs_frag; + clusteracct(cgp, fragno); + cgp->cg_cs.cs_nbfree++; + fs->fs_cstotal.cs_nbfree++; + fs->fs_cs(fs, cg).cs_nbfree++; + } + } +} + +/* + * Recursively free all indirect blocks. + */ +static void +freeindir(ufs2_daddr_t blk, int level) +{ + char sblks[MAXBSIZE]; + ufs2_daddr_t *blks; + int i; + + if (bread(disk, fsbtodb(fs, blk), (void *)&sblks, (size_t)fs->fs_bsize) == -1) + err(1, "bread: %s", disk->d_error); + blks = (ufs2_daddr_t *)&sblks; + for (i = 0; i < howmany(fs->fs_bsize, sizeof(ufs2_daddr_t)); i++) { + if (blks[i] == 0) + break; + if (level == 0) + blkfree(blks[i], fs->fs_bsize); + else + freeindir(blks[i], level - 1); + } + blkfree(blk, fs->fs_bsize); +} + +#define dblksize(fs, dino, lbn) \ + ((dino)->di_size >= smalllblktosize(fs, (lbn) + 1) \ + ? (fs)->fs_bsize \ + : fragroundup(fs, blkoff(fs, (dino)->di_size))) + +/* + * Free all blocks associated with the given inode. + */ +static void +clear_inode(struct ufs2_dinode *dino) +{ + ufs2_daddr_t bn; + int extblocks, i, level; + off_t osize; + long bsize; + + extblocks = 0; + if (fs->fs_magic == FS_UFS2_MAGIC && dino->di_extsize > 0) + extblocks = btodb(fragroundup(fs, dino->di_extsize)); + /* deallocate external attributes blocks */ + if (extblocks > 0) { + osize = dino->di_extsize; + dino->di_blocks -= extblocks; + dino->di_extsize = 0; + for (i = 0; i < NXADDR; i++) { + if (dino->di_extb[i] == 0) + continue; + blkfree(dino->di_extb[i], sblksize(fs, osize, i)); + } + } +#define SINGLE 0 /* index of single indirect block */ +#define DOUBLE 1 /* index of double indirect block */ +#define TRIPLE 2 /* index of triple indirect block */ + /* deallocate indirect blocks */ + for (level = SINGLE; level <= TRIPLE; level++) { + if (dino->di_ib[level] == 0) + break; + freeindir(dino->di_ib[level], level); + } + /* deallocate direct blocks and fragments */ + for (i = 0; i < NDADDR; i++) { + bn = dino->di_db[i]; + if (bn == 0) + continue; + bsize = dblksize(fs, dino, i); + blkfree(bn, bsize); + } +} + +void +gjournal_check(const char *filesys) +{ + struct ufs2_dinode *dino; + struct cgchain *cgc; + struct cg *cgp; + uint8_t *inosused, *blksfree; + ino_t cino, ino; + int cg, mode; + + devnam = filesys; + getdisk(); + /* Are there any unreferenced inodes in this cylinder group? */ + if (fs->fs_unrefs == 0) { + //printf("No unreferenced inodes.\n"); + closedisk(); + return; + } + + for (cg = 0; cg < fs->fs_ncg; cg++) { + /* Show progress if requested. */ + if (got_siginfo) { + printf("%s: phase j: cyl group %d of %d (%d%%)\n", + cdevname, cg, fs->fs_ncg, cg * 100 / fs->fs_ncg); + got_siginfo = 0; + } + if (got_sigalarm) { + setproctitle("%s pj %d%%", cdevname, + cg * 100 / fs->fs_ncg); + got_sigalarm = 0; + } + cgc = getcg(cg); + cgp = &cgc->cgc_cg; + /* Are there any unreferenced inodes in this cylinder group? */ + if (cgp->cg_unrefs == 0) + continue; + //printf("Analizing cylinder group %d (count=%d)\n", cg, cgp->cg_unrefs); + /* + * We are going to modify this cylinder group, so we want it to + * be written back. + */ + dirtycg(cgc); + /* We don't want it to be freed in the meantime. */ + busycg(cgc); + inosused = cg_inosused(cgp); + blksfree = cg_blksfree(cgp); + /* + * Now go through the list of all inodes in this cylinder group + * to find unreferenced ones. + */ + for (cino = 0; cino < fs->fs_ipg; cino++) { + ino = fs->fs_ipg * cg + cino; + /* Unallocated? Skip it. */ + if (isclr(inosused, cino)) + continue; + if (getino(disk, (void **)&dino, ino, &mode) == -1) + err(1, "getino(cg=%d ino=%d)", cg, ino); + /* Not a regular file nor directory? Skip it. */ + if (!S_ISREG(dino->di_mode) && !S_ISDIR(dino->di_mode)) + continue; + /* Has reference(s)? Skip it. */ + if (dino->di_nlink > 0) + continue; + //printf("Clearing inode=%d (size=%jd)\n", ino, (intmax_t)dino->di_size); + /* Free inode's blocks. */ + clear_inode(dino); + /* Deallocate it. */ + clrbit(inosused, cino); + /* Update position of last used inode. */ + if (ino < cgp->cg_irotor) + cgp->cg_irotor = ino; + /* Update statistics. */ + cgp->cg_cs.cs_nifree++; + fs->fs_cs(fs, cg).cs_nifree++; + fs->fs_cstotal.cs_nifree++; + cgp->cg_unrefs--; + fs->fs_unrefs--; + /* If this is directory, update related statistics. */ + if (S_ISDIR(dino->di_mode)) { + cgp->cg_cs.cs_ndir--; + fs->fs_cs(fs, cg).cs_ndir--; + fs->fs_cstotal.cs_ndir--; + } + /* Zero-fill the inode. */ + *dino = ufs2_zino; + /* Write the inode back. */ + if (putino(disk, ino) == -1) + err(1, "putino(cg=%d ino=%d)", cg, ino); + if (cgp->cg_unrefs == 0) { + //printf("No more unreferenced inodes in cg=%d.\n", cg); + break; + } + } + /* + * We don't need this cylinder group anymore, so feel free to + * free it if needed. + */ + unbusycg(cgc); + /* + * If there are no more unreferenced inodes, there is no need to + * check other cylinder groups. + */ + if (fs->fs_unrefs == 0) { + //printf("No more unreferenced inodes (cg=%d/%d).\n", cg, + // fs->fs_ncg); + break; + } + } + /* Write back modified cylinder groups. */ + putcgs(); + /* Write back updated statistics and super-block. */ + putdisk(); +} --- sbin/fsck_ffs/inode.c.orig +++ sbin/fsck_ffs/inode.c @@ -329,10 +329,10 @@ lastinum += fullcnt; } /* - * If bread returns an error, it will already have zeroed + * If blread returns an error, it will already have zeroed * out the buffer, so we do not need to do so here. */ - (void)bread(fsreadfd, inodebuf, dblk, size); + (void)blread(fsreadfd, inodebuf, dblk, size); nextinop = inodebuf; } dp = (union dinode *)nextinop; --- sbin/fsck_ffs/main.c.orig +++ sbin/fsck_ffs/main.c @@ -237,6 +237,29 @@ exit(7); /* Filesystem clean, report it now */ exit(0); } + if (preen && skipclean) { + /* + * If file system is gjournaled, check it here. + */ + if ((fsreadfd = open(filesys, O_RDONLY)) < 0 || readsb(0) == 0) + exit(3); /* Cannot read superblock */ + close(fsreadfd); + if ((sblock.fs_flags & FS_GJOURNAL) != 0) { + //printf("GJournaled file system detected on %s.\n", + // filesys); + if (sblock.fs_clean == 1) { + pwarn("FILE SYSTEM CLEAN; SKIPPING CHECKS\n"); + exit(0); + } + if ((sblock.fs_flags & (FS_UNCLEAN | FS_NEEDSFSCK)) == 0) { + gjournal_check(filesys); + exit(0); + } else { + pfatal("UNEXPECTED INCONSISTENCY, %s\n", + "CANNOT RUN FAST FSCK\n"); + } + } + } /* * If we are to do a background check: * Get the mount point information of the file system @@ -437,7 +460,7 @@ * Write out the duplicate super blocks */ for (cylno = 0; cylno < sblock.fs_ncg; cylno++) - bwrite(fswritefd, (char *)&sblock, + blwrite(fswritefd, (char *)&sblock, fsbtodb(&sblock, cgsblock(&sblock, cylno)), SBLOCKSIZE); } --- sbin/fsck_ffs/pass5.c.orig +++ sbin/fsck_ffs/pass5.c @@ -164,6 +164,7 @@ pfatal("CG %d: BAD MAGIC NUMBER\n", c); newcg->cg_time = cg->cg_time; newcg->cg_old_time = cg->cg_old_time; + newcg->cg_unrefs = cg->cg_unrefs; newcg->cg_cgx = c; dbase = cgbase(fs, c); dmax = dbase + fs->fs_fpg; --- sbin/fsck_ffs/setup.c.orig +++ sbin/fsck_ffs/setup.c @@ -249,7 +249,7 @@ for (i = 0, j = 0; i < sblock.fs_cssize; i += sblock.fs_bsize, j++) { size = sblock.fs_cssize - i < sblock.fs_bsize ? sblock.fs_cssize - i : sblock.fs_bsize; - if (bread(fsreadfd, (char *)sblock.fs_csp + i, + if (blread(fsreadfd, (char *)sblock.fs_csp + i, fsbtodb(&sblock, sblock.fs_csaddr + j * sblock.fs_frag), size) != 0 && !asked) { pfatal("BAD SUMMARY INFORMATION"); @@ -322,7 +322,7 @@ if (bflag) { super = bflag; - if ((bread(fsreadfd, (char *)&sblock, super, (long)SBLOCKSIZE))) + if ((blread(fsreadfd, (char *)&sblock, super, (long)SBLOCKSIZE))) return (0); if (sblock.fs_magic == FS_BAD_MAGIC) { fprintf(stderr, BAD_MAGIC_MSG); @@ -337,7 +337,7 @@ } else { for (i = 0; sblock_try[i] != -1; i++) { super = sblock_try[i] / dev_bsize; - if ((bread(fsreadfd, (char *)&sblock, super, + if ((blread(fsreadfd, (char *)&sblock, super, (long)SBLOCKSIZE))) return (0); if (sblock.fs_magic == FS_BAD_MAGIC) { --- sbin/fsdb/fsdb.c.orig +++ sbin/fsdb/fsdb.c @@ -620,7 +620,7 @@ uint32_t idblk[MAXNINDIR]; int i; - bread(fsreadfd, (char *)idblk, fsbtodb(&sblock, blk), (int)sblock.fs_bsize); + blread(fsreadfd, (char *)idblk, fsbtodb(&sblock, blk), (int)sblock.fs_bsize); if (ind_level <= 0) { if (find_blks32(idblk, sblock.fs_bsize / sizeof(uint32_t), wantedblk)) return 1; @@ -662,7 +662,7 @@ uint64_t idblk[MAXNINDIR]; int i; - bread(fsreadfd, (char *)idblk, fsbtodb(&sblock, blk), (int)sblock.fs_bsize); + blread(fsreadfd, (char *)idblk, fsbtodb(&sblock, blk), (int)sblock.fs_bsize); if (ind_level <= 0) { if (find_blks64(idblk, sblock.fs_bsize / sizeof(uint64_t), wantedblk)) return 1; --- sbin/fsdb/fsdb.h.orig +++ sbin/fsdb/fsdb.h @@ -30,8 +30,7 @@ * $FreeBSD: src/sbin/fsdb/fsdb.h,v 1.10.14.1 2006/05/21 09:04:31 maxim Exp $ */ -extern int bread(int fd, char *buf, ufs2_daddr_t blk, long size); -extern void bwrite(int fd, char *buf, ufs2_daddr_t blk, long size); +extern int blread(int fd, char *buf, ufs2_daddr_t blk, long size); extern void rwerror(const char *mesg, ufs2_daddr_t blk); extern int reply(const char *question); --- sbin/geom/class/Makefile.orig +++ sbin/geom/class/Makefile @@ -4,6 +4,7 @@ .if !defined(NO_CRYPT) && !defined(NO_OPENSSL) SUBDIR+=eli .endif +SUBDIR+=journal SUBDIR+=label SUBDIR+=mirror SUBDIR+=nop --- /dev/null Tue Oct 24 16:33:50 2006 +++ sbin/geom/class/journal/Makefile Tue Oct 24 16:34:01 2006 @@ -0,0 +1,14 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../misc + +CLASS= journal +SRCS+= geom_journal_ufs.c + +DPADD= ${LIBMD} ${LIBUFS} +LDADD= -lmd -lufs + +NO_MAN= +CFLAGS+=-I${.CURDIR}/../../../../sys + +.include --- /dev/null Tue Oct 24 16:33:50 2006 +++ sbin/geom/class/journal/geom_journal.c Tue Oct 24 16:34:04 2006 @@ -0,0 +1,340 @@ +/*- + * Copyright (c) 2005-2006 Pawel Jakub Dawidek + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "geom_journal.h" + + +uint32_t lib_version = G_LIB_VERSION; +uint32_t version = G_JOURNAL_VERSION; + +static intmax_t default_jsize = -1; + +static void journal_main(struct gctl_req *req, unsigned flags); +static void journal_clear(struct gctl_req *req); +static void journal_dump(struct gctl_req *req); +static void journal_label(struct gctl_req *req); + +struct g_command class_commands[] = { + { "clear", G_FLAG_VERBOSE, journal_main, G_NULL_OPTS, + "[-v] prov ..." + }, + { "dump", 0, journal_main, G_NULL_OPTS, + "prov ..." + }, + { "label", G_FLAG_VERBOSE, journal_main, + { + { 'c', "checksum", NULL, G_TYPE_NONE }, + { 'f', "force", NULL, G_TYPE_NONE }, + { 'h', "hardcode", NULL, G_TYPE_NONE }, + { 's', "jsize", &default_jsize, G_TYPE_NUMBER }, + G_OPT_SENTINEL + }, + "[-cfhv] [-s jsize] dataprov [jprov]" + }, + { "stop", G_FLAG_VERBOSE, NULL, + { + { 'f', "force", NULL, G_TYPE_NONE }, + G_OPT_SENTINEL + }, + "[-fv] name ..." + }, + { "sync", G_FLAG_VERBOSE, NULL, G_NULL_OPTS, + "[-v]" + }, + G_CMD_SENTINEL +}; + +static int verbose = 0; + +static void +journal_main(struct gctl_req *req, unsigned flags) +{ + const char *name; + + if ((flags & G_FLAG_VERBOSE) != 0) + verbose = 1; + + name = gctl_get_ascii(req, "verb"); + if (name == NULL) { + gctl_error(req, "No '%s' argument.", "verb"); + return; + } + if (strcmp(name, "label") == 0) + journal_label(req); + else if (strcmp(name, "clear") == 0) + journal_clear(req); + else if (strcmp(name, "dump") == 0) + journal_dump(req); + else + gctl_error(req, "Unknown command: %s.", name); +} + +static int +g_journal_fs_exists(const char *prov) +{ + + if (g_journal_ufs_exists(prov)) + return (1); +#if 0 + if (g_journal_otherfs_exists(prov)) + return (1); +#endif + return (0); +} + +static int +g_journal_fs_using_last_sector(const char *prov) +{ + + if (g_journal_ufs_using_last_sector(prov)) + return (1); +#if 0 + if (g_journal_otherfs_using_last_sector(prov)) + return (1); +#endif + return (0); +} + +static void +journal_label(struct gctl_req *req) +{ + struct g_journal_metadata md; + const char *data, *journal, *str; + u_char sector[512]; + intmax_t jsize, msize, ssize; + int error, force, i, nargs, checksum, hardcode; + + nargs = gctl_get_int(req, "nargs"); + + strlcpy(md.md_magic, G_JOURNAL_MAGIC, sizeof(md.md_magic)); + md.md_version = G_JOURNAL_VERSION; + md.md_id = arc4random(); + md.md_joffset = 0; + md.md_jid = 0; + md.md_flags = GJ_FLAG_CLEAN; + checksum = gctl_get_int(req, "checksum"); + if (checksum) + md.md_flags |= GJ_FLAG_CHECKSUM; + force = gctl_get_int(req, "force"); + hardcode = gctl_get_int(req, "hardcode"); + + if (nargs != 1 && nargs != 2) { + gctl_error(req, "Invalid number of arguments."); + return; + } + + /* Verify the given providers. */ + for (i = 0; i < nargs; i++) { + str = gctl_get_ascii(req, "arg%d", i); + if (g_get_mediasize(str) == 0) { + gctl_error(req, "Invalid provider %s.", str); + return; + } + } + + data = gctl_get_ascii(req, "arg0"); + jsize = gctl_get_intmax(req, "jsize"); + journal = NULL; + switch (nargs) { + case 1: + if (!force && g_journal_fs_exists(data)) { + gctl_error(req, "File system exists on %s and this " + "operation is going to destroy it. Use -f if you " + "really want to do it.", data); + return; + } + journal = data; + if (jsize == -1) { + /* + * No journal size specified. 1GB should be safe + * default. + */ + jsize = 1073741824ULL; + } + msize = g_get_mediasize(data); + ssize = g_get_sectorsize(data); + if (jsize + ssize >= msize) { + gctl_error(req, "Provider too small for journalling. " + "You can try smaller jsize (default is %jd).", + jsize); + return; + } + md.md_jstart = msize - ssize - jsize; + md.md_jend = msize - ssize; + break; + case 2: + if (!force && g_journal_fs_using_last_sector(data)) { + gctl_error(req, "File system on %s is using the last " + "sector and this operation is going to overwrite " + "it. Use -f if you really want to do it.", data); + return; + } + journal = gctl_get_ascii(req, "arg1"); + if (jsize != -1) { + gctl_error(req, "jsize argument is valid only for " + "all-in-one configuration."); + return; + } + msize = g_get_mediasize(journal); + ssize = g_get_sectorsize(journal); + md.md_jstart = 0; + md.md_jend = msize - ssize; + break; + } + + if (g_get_sectorsize(data) != g_get_sectorsize(journal)) { + gctl_error(req, "Not equal sector sizes."); + return; + } + + /* + * Clear last sector first, to spoil all components if device exists. + */ + for (i = 0; i < nargs; i++) { + str = gctl_get_ascii(req, "arg%d", i); + error = g_metadata_clear(str, NULL); + if (error != 0) { + gctl_error(req, "Cannot clear metadata on %s: %s.", str, + strerror(error)); + return; + } + } + + /* + * Ok, store metadata. + */ + for (i = 0; i < nargs; i++) { + switch (i) { + case 0: + str = data; + md.md_type = GJ_TYPE_DATA; + if (nargs == 1) + md.md_type |= GJ_TYPE_JOURNAL; + break; + case 1: + str = journal; + md.md_type = GJ_TYPE_JOURNAL; + break; + } + md.md_provsize = g_get_mediasize(str); + assert(md.md_provsize != 0); + if (!hardcode) + bzero(md.md_provider, sizeof(md.md_provider)); + else { + if (strncmp(str, _PATH_DEV, strlen(_PATH_DEV)) == 0) + str += strlen(_PATH_DEV); + strlcpy(md.md_provider, str, sizeof(md.md_provider)); + } + journal_metadata_encode(&md, sector); + error = g_metadata_store(str, sector, sizeof(sector)); + if (error != 0) { + fprintf(stderr, "Cannot store metadata on %s: %s.\n", + str, strerror(error)); + gctl_error(req, "Not fully done."); + continue; + } + if (verbose) + printf("Metadata value stored on %s.\n", str); + } +} + +static void +journal_clear(struct gctl_req *req) +{ + const char *name; + int error, i, nargs; + + nargs = gctl_get_int(req, "nargs"); + if (nargs < 1) { + gctl_error(req, "Too few arguments."); + return; + } + + for (i = 0; i < nargs; i++) { + name = gctl_get_ascii(req, "arg%d", i); + error = g_metadata_clear(name, G_JOURNAL_MAGIC); + if (error != 0) { + fprintf(stderr, "Cannot clear metadata on %s: %s.\n", + name, strerror(error)); + gctl_error(req, "Not fully done."); + continue; + } + if (verbose) + printf("Metadata cleared on %s.\n", name); + } +} + +static void +journal_dump(struct gctl_req *req) +{ + struct g_journal_metadata md, tmpmd; + const char *name; + int error, i, nargs; + + nargs = gctl_get_int(req, "nargs"); + if (nargs < 1) { + gctl_error(req, "Too few arguments."); + return; + } + + for (i = 0; i < nargs; i++) { + name = gctl_get_ascii(req, "arg%d", i); + error = g_metadata_read(name, (u_char *)&tmpmd, sizeof(tmpmd), + G_JOURNAL_MAGIC); + if (error != 0) { + fprintf(stderr, "Cannot read metadata from %s: %s.\n", + name, strerror(error)); + gctl_error(req, "Not fully done."); + continue; + } + if (journal_metadata_decode((u_char *)&tmpmd, &md) != 0) { + fprintf(stderr, "MD5 hash mismatch for %s, skipping.\n", + name); + gctl_error(req, "Not fully done."); + continue; + } + printf("Metadata on %s:\n", name); + journal_metadata_dump(&md); + printf("\n"); + } +} --- /dev/null Tue Oct 24 16:33:50 2006 +++ sbin/geom/class/journal/geom_journal.h Tue Oct 24 16:34:07 2006 @@ -0,0 +1,33 @@ +/*- + * Copyright (c) 2006 Pawel Jakub Dawidek + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _GEOM_JOURNAL_H_ +#define _GEOM_JOURNAL_H_ +int g_journal_ufs_exists(const char *prov); +int g_journal_ufs_using_last_sector(const char *prov); +#endif /* !_GEOM_JOURNAL_H_ */ --- /dev/null Tue Oct 24 16:33:50 2006 +++ sbin/geom/class/journal/geom_journal_ufs.c Tue Oct 24 16:34:09 2006 @@ -0,0 +1,78 @@ +/*- + * Copyright (c) 2006 Pawel Jakub Dawidek + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD"); + +#include +#include +#include + +#include +#include + +#include +#include +#include +#include + +#include "geom_journal.h" + +static struct fs * +read_superblock(const char *prov) +{ + static struct uufsd disk; + struct fs *fs; + + if (ufs_disk_fillout(&disk, prov) == -1) + return (NULL); + fs = &disk.d_fs; + ufs_disk_close(&disk); + return (fs); +} + +int +g_journal_ufs_exists(const char *prov) +{ + + return (read_superblock(prov) != NULL); +} + +int +g_journal_ufs_using_last_sector(const char *prov) +{ + struct fs *fs; + off_t psize, fssize; + + fs = read_superblock(prov); + if (fs == NULL) + return (0); + /* Provider size in 512 bytes blocks. */ + psize = g_get_mediasize(prov) / DEV_BSIZE; + /* File system size in 512 bytes blocks. */ + fssize = fsbtodb(fs, dbtofsb(fs, psize)); + return (psize == fssize); +} --- sbin/growfs/debug.c.orig +++ sbin/growfs/debug.c @@ -281,6 +281,8 @@ */ fprintf(dbg_log, "maxbsize int32_t 0x%08x\n", sb->fs_maxbsize); + fprintf(dbg_log, "unrefs int64_t 0x%08x\n", + sb->fs_unrefs); fprintf(dbg_log, "sblockloc int64_t 0x%08x%08x\n", ((unsigned int *)&(sb->fs_sblockloc))[1], ((unsigned int *)&(sb->fs_sblockloc))[0]); @@ -399,6 +401,7 @@ cgr->cg_nclusterblks); fprintf(dbg_log, "niblk int32_t 0x%08x\n", cgr->cg_niblk); fprintf(dbg_log, "initediblk int32_t 0x%08x\n", cgr->cg_initediblk); + fprintf(dbg_log, "unrefs int32_t 0x%08x\n", cgr->cg_unrefs); fprintf(dbg_log, "time ufs_time_t %10u\n", (unsigned int)cgr->cg_initediblk); --- sbin/mount/mount.c.orig +++ sbin/mount/mount.c @@ -106,6 +106,7 @@ { MNT_SOFTDEP, "soft-updates" }, { MNT_MULTILABEL, "multilabel" }, { MNT_ACLS, "acls" }, + { MNT_GJOURNAL, "gjournal" }, { 0, NULL } }; @@ -773,6 +774,7 @@ if (flags & MNT_SUIDDIR) res = catopt(res, "suiddir"); if (flags & MNT_MULTILABEL) res = catopt(res, "multilabel"); if (flags & MNT_ACLS) res = catopt(res, "acls"); + if (flags & MNT_GJOURNAL) res = catopt(res, "gjournal"); return res; } --- sbin/newfs/mkfs.c.orig +++ sbin/newfs/mkfs.c @@ -135,6 +135,8 @@ sblock.fs_flags |= FS_DOSOFTDEP; if (Lflag) strlcpy(sblock.fs_volname, volumelabel, MAXVOLLEN); + if (Jflag) + sblock.fs_flags |= FS_GJOURNAL; if (lflag) sblock.fs_flags |= FS_MULTILABEL; /* --- sbin/newfs/newfs.8.orig +++ sbin/newfs/newfs.8 @@ -36,7 +36,7 @@ .Nd construct a new UFS1/UFS2 file system .Sh SYNOPSIS .Nm -.Op Fl NUln +.Op Fl JNUln .Op Fl L Ar volname .Op Fl O Ar filesystem-type .Op Fl S Ar sector-size @@ -77,6 +77,8 @@ .Pp The following options define the general layout policies: .Bl -tag -width indent +.It Fl J +Enable journaling on the new file system via gjournal. .It Fl L Ar volname Add a volume label to the new file system. .It Fl N --- sbin/newfs/newfs.c.orig +++ sbin/newfs/newfs.c @@ -117,6 +117,7 @@ int Rflag; /* regression test */ int Uflag; /* enable soft updates for file system */ int Eflag = 0; /* exit in middle of newfs for testing */ +int Jflag; /* enable gjournal for file system */ int lflag; /* enable multilabel for file system */ int nflag; /* do not create .snap directory */ quad_t fssize; /* file system size */ @@ -156,11 +157,14 @@ off_t mediasize; while ((ch = getopt(argc, argv, - "EL:NO:RS:T:Ua:b:c:d:e:f:g:h:i:lm:no:s:")) != -1) + "EJL:NO:RS:T:Ua:b:c:d:e:f:g:h:i:lm:no:s:")) != -1) switch (ch) { case 'E': Eflag++; break; + case 'J': + Jflag = 1; + break; case 'L': volumelabel = optarg; i = -1; --- sbin/newfs/newfs.h.orig +++ sbin/newfs/newfs.h @@ -49,6 +49,7 @@ extern int Rflag; /* regression test */ extern int Uflag; /* enable soft updates for file system */ extern int Eflag; /* exit as if error, for testing */ +extern int Jflag; /* enable gjournal for file system */ extern int lflag; /* enable multilabel MAC for file system */ extern int nflag; /* do not create .snap directory */ extern quad_t fssize; /* file system size */ --- sbin/tunefs/tunefs.8.orig +++ sbin/tunefs/tunefs.8 @@ -40,6 +40,7 @@ .Op Fl a Cm enable | disable .Op Fl e Ar maxbpg .Op Fl f Ar avgfilesize +.Op Fl J Cm enable | disable .Op Fl L Ar volname .Op Fl l Cm enable | disable .Op Fl m Ar minfree @@ -87,6 +88,8 @@ this parameter should be set higher. .It Fl f Ar avgfilesize Specify the expected average file size. +.It Fl J Cm enable | disable +Turn on/off GJournal flag. .It Fl L Ar volname Add/modify an optional file system volume label. .It Fl l Cm enable | disable --- sbin/tunefs/tunefs.c.orig +++ sbin/tunefs/tunefs.c @@ -76,11 +76,11 @@ int main(int argc, char *argv[]) { - char *avalue, *Lvalue, *lvalue, *nvalue; + char *avalue, *Jvalue, *Lvalue, *lvalue, *nvalue; const char *special, *on; const char *name; int active; - int Aflag, aflag, eflag, evalue, fflag, fvalue, Lflag, lflag; + int Aflag, aflag, eflag, evalue, fflag, fvalue, Jflag, Lflag, lflag; int mflag, mvalue, nflag, oflag, ovalue, pflag, sflag, svalue; int ch, found_arg, i; const char *chg[2]; @@ -89,13 +89,13 @@ if (argc < 3) usage(); - Aflag = aflag = eflag = fflag = Lflag = lflag = mflag = 0; + Aflag = aflag = eflag = fflag = Jflag = Lflag = lflag = mflag = 0; nflag = oflag = pflag = sflag = 0; - avalue = Lvalue = lvalue = nvalue = NULL; + avalue = Jvalue = Lvalue = lvalue = nvalue = NULL; evalue = fvalue = mvalue = ovalue = svalue = 0; active = 0; found_arg = 0; /* At least one arg is required. */ - while ((ch = getopt(argc, argv, "Aa:e:f:L:l:m:n:o:ps:")) != -1) + while ((ch = getopt(argc, argv, "Aa:e:f:J:L:l:m:n:o:ps:")) != -1) switch (ch) { case 'A': @@ -135,6 +135,19 @@ fflag = 1; break; + case 'J': + found_arg = 1; + name = "gjournaled file system"; + Jvalue = optarg; + if (strcmp(Jvalue, "enable") && + strcmp(Jvalue, "disable")) { + errx(10, "bad %s (options are %s)", + name, "`enable' or `disable'"); + } + Jflag = 1; + break; + + case 'L': found_arg = 1; name = "volume label"; @@ -282,6 +295,26 @@ sblock.fs_avgfilesize = fvalue; } } + if (Jflag) { + name = "gjournal"; + if (strcmp(Jvalue, "enable") == 0) { + if (sblock.fs_flags & FS_GJOURNAL) { + warnx("%s remains unchanged as enabled", name); + } else { + sblock.fs_flags |= FS_GJOURNAL; + warnx("%s set", name); + } + } else if (strcmp(Jvalue, "disable") == 0) { + if ((~sblock.fs_flags & FS_GJOURNAL) == + FS_GJOURNAL) { + warnx("%s remains unchanged as disabled", + name); + } else { + sblock.fs_flags &= ~FS_GJOURNAL; + warnx("%s cleared", name); + } + } + } if (lflag) { name = "multilabel"; if (strcmp(lvalue, "enable") == 0) { @@ -389,8 +422,8 @@ { fprintf(stderr, "%s\n%s\n%s\n%s\n", "usage: tunefs [-A] [-a enable | disable] [-e maxbpg] [-f avgfilesize]", -" [-L volname] [-l enable | disable] [-m minfree]", -" [-n enable | disable] [-o space | time] [-p]", +" [-J enable | disable ] [-L volname] [-l enable | disable]", +" [-m minfree] [-n enable | disable] [-o space | time] [-p]", " [-s avgfpdir] special | filesystem"); exit(2); } @@ -404,6 +437,8 @@ (sblock.fs_flags & FS_MULTILABEL)? "enabled" : "disabled"); warnx("soft updates: (-n) %s", (sblock.fs_flags & FS_DOSOFTDEP)? "enabled" : "disabled"); + warnx("gjournal: (-J) %s", + (sblock.fs_flags & FS_GJOURNAL)? "enabled" : "disabled"); warnx("maximum blocks per file in a cylinder group: (-e) %d", sblock.fs_maxbpg); warnx("average file size: (-f) %d", --- share/man/man5/fs.5.orig +++ share/man/man5/fs.5 @@ -153,7 +153,8 @@ u_int *fs_active; /* used by snapshots to track fs */ int32_t fs_old_cpc; /* cyl per cycle in postbl */ int32_t fs_maxbsize; /* maximum blocking factor permitted */ - int64_t fs_sparecon64[17]; /* old rotation block list head */ + int64_t fs_unrefs; /* number of unreferenced inodes */ + int64_t fs_sparecon64[16]; /* old rotation block list head */ int64_t fs_sblockloc; /* byte offset of standard superblock */ struct csum_total fs_cstotal; /* cylinder summary information */ ufs_time_t fs_time; /* last time written */ --- sys/cam/scsi/scsi_da.c.orig +++ sys/cam/scsi/scsi_da.c @@ -1163,6 +1163,8 @@ softc->disk->d_maxsize = DFLTPHYS; /* XXX: probably not arbitrary */ softc->disk->d_unit = periph->unit_number; softc->disk->d_flags = DISKFLAG_NEEDSGIANT; + if ((softc->quirks & DA_Q_NO_SYNC_CACHE) == 0) + softc->disk->d_flags |= DISKFLAG_CANFLUSHCACHE; disk_create(softc->disk, DISK_VERSION); /* @@ -1234,20 +1236,35 @@ } else { tag_code = MSG_SIMPLE_Q_TAG; } - scsi_read_write(&start_ccb->csio, - /*retries*/da_retry_count, - /*cbfcnp*/dadone, - /*tag_action*/tag_code, - /*read_op*/bp->bio_cmd == BIO_READ, - /*byte2*/0, - softc->minimum_cmd_size, - /*lba*/bp->bio_pblkno, - /*block_count*/bp->bio_bcount / - softc->params.secsize, - /*data_ptr*/ bp->bio_data, - /*dxfer_len*/ bp->bio_bcount, - /*sense_len*/SSD_FULL_SIZE, - /*timeout*/da_default_timeout*1000); + switch (bp->bio_cmd) { + case BIO_READ: + case BIO_WRITE: + scsi_read_write(&start_ccb->csio, + /*retries*/da_retry_count, + /*cbfcnp*/dadone, + /*tag_action*/tag_code, + /*read_op*/bp->bio_cmd == BIO_READ, + /*byte2*/0, + softc->minimum_cmd_size, + /*lba*/bp->bio_pblkno, + /*block_count*/bp->bio_bcount / + softc->params.secsize, + /*data_ptr*/ bp->bio_data, + /*dxfer_len*/ bp->bio_bcount, + /*sense_len*/SSD_FULL_SIZE, + /*timeout*/da_default_timeout*1000); + break; + case BIO_FLUSH: + scsi_synchronize_cache(&start_ccb->csio, + /*retries*/1, + /*cbfcnp*/dadone, + MSG_SIMPLE_Q_TAG, + /*begin_lba*/0,/* Cover the whole disk */ + /*lb_count*/0, + SSD_FULL_SIZE, + /*timeout*/da_default_timeout*1000); + break; + } start_ccb->ccb_h.ccb_state = DA_CCB_BUFFER_IO; /* --- sys/conf/NOTES.orig +++ sys/conf/NOTES @@ -135,6 +135,7 @@ options GEOM_FOX # Redundant path mitigation options GEOM_GATE # Userland services. options GEOM_GPT # GPT partitioning +options GEOM_JOURNAL # Journaling. options GEOM_LABEL # Providers labelization. options GEOM_MBR # DOS/MBR partitioning options GEOM_MIRROR # Disk mirroring. @@ -877,6 +878,9 @@ # directories at the expense of some memory. options UFS_DIRHASH +# Gjournal-based UFS journaling support. +options UFS_GJOURNAL + # Make space in the kernel for a root filesystem on a md device. # Define to the number of kilobytes to reserve for the filesystem. options MD_ROOT_SIZE=10 --- sys/conf/files.orig +++ sys/conf/files @@ -1125,6 +1125,8 @@ geom/geom_sunlabel_enc.c optional geom_sunlabel geom/geom_vfs.c standard geom/geom_vol_ffs.c optional geom_vol +geom/journal/g_journal.c optional geom_journal +geom/journal/g_journal_ufs.c optional geom_journal geom/label/g_label.c optional geom_label geom/label/g_label_ext2fs.c optional geom_label geom/label/g_label_iso9660.c optional geom_label @@ -1890,6 +1892,7 @@ ufs/ufs/ufs_bmap.c optional ffs ufs/ufs/ufs_dirhash.c optional ffs ufs/ufs/ufs_extattr.c optional ffs +ufs/ufs/ufs_gjournal.c optional ffs ufs/ufs/ufs_inode.c optional ffs ufs/ufs/ufs_lookup.c optional ffs ufs/ufs/ufs_quota.c optional ffs --- sys/conf/options.orig +++ sys/conf/options @@ -83,6 +83,7 @@ GEOM_FOX opt_geom.h GEOM_GATE opt_geom.h GEOM_GPT opt_geom.h +GEOM_JOURNAL opt_geom.h GEOM_LABEL opt_geom.h GEOM_MBR opt_geom.h GEOM_MIRROR opt_geom.h @@ -235,6 +236,9 @@ # Enable fast hash lookups for large directories on UFS-based filesystems. UFS_DIRHASH opt_ufs.h +# Enable gjournal-based UFS journal. +UFS_GJOURNAL opt_ufs.h + # The below sentence is not in English, and neither is this one. # We plan to remove the static dependences above, with a # _ROOT option to control if it usable as root. This list --- sys/dev/amr/amr.c.orig +++ sys/dev/amr/amr.c @@ -1287,7 +1287,7 @@ int driveno; int cmd; - ac = NULL; + *acp = NULL; error = 0; /* get a command */ @@ -1305,39 +1305,50 @@ ac->ac_bio = bio; ac->ac_data = bio->bio_data; ac->ac_length = bio->bio_bcount; - if (bio->bio_cmd == BIO_READ) { + cmd = 0; + switch (bio->bio_cmd) { + case BIO_READ: ac->ac_flags |= AMR_CMD_DATAIN; if (AMR_IS_SG64(sc)) { cmd = AMR_CMD_LREAD64; ac->ac_flags |= AMR_CMD_SG64; } else cmd = AMR_CMD_LREAD; - } else { + break; + case BIO_WRITE: ac->ac_flags |= AMR_CMD_DATAOUT; if (AMR_IS_SG64(sc)) { cmd = AMR_CMD_LWRITE64; ac->ac_flags |= AMR_CMD_SG64; } else cmd = AMR_CMD_LWRITE; + break; + case BIO_FLUSH: + ac->ac_flags |= AMR_CMD_PRIORITY | AMR_CMD_DATAOUT; + cmd = AMR_CMD_FLUSH; + break; } amrd = (struct amrd_softc *)bio->bio_disk->d_drv1; driveno = amrd->amrd_drive - sc->amr_drive; blkcount = (bio->bio_bcount + AMR_BLKSIZE - 1) / AMR_BLKSIZE; ac->ac_mailbox.mb_command = cmd; - ac->ac_mailbox.mb_blkcount = blkcount; - ac->ac_mailbox.mb_lba = bio->bio_pblkno; + if (bio->bio_cmd & (BIO_READ|BIO_WRITE)) { + ac->ac_mailbox.mb_blkcount = blkcount; + ac->ac_mailbox.mb_lba = bio->bio_pblkno; + if ((bio->bio_pblkno + blkcount) > sc->amr_drive[driveno].al_size) { + device_printf(sc->amr_dev, + "I/O beyond end of unit (%lld,%d > %lu)\n", + (long long)bio->bio_pblkno, blkcount, + (u_long)sc->amr_drive[driveno].al_size); + } + } ac->ac_mailbox.mb_drive = driveno; if (sc->amr_state & AMR_STATE_REMAP_LD) ac->ac_mailbox.mb_drive |= 0x80; /* we fill in the s/g related data when the command is mapped */ - if ((bio->bio_pblkno + blkcount) > sc->amr_drive[driveno].al_size) - device_printf(sc->amr_dev, "I/O beyond end of unit (%lld,%d > %lu)\n", - (long long)bio->bio_pblkno, blkcount, - (u_long)sc->amr_drive[driveno].al_size); - *acp = ac; return(error); } --- sys/dev/amr/amr_disk.c.orig +++ sys/dev/amr/amr_disk.c @@ -236,7 +236,7 @@ sc->amrd_disk->d_name = "amrd"; sc->amrd_disk->d_dump = (dumper_t *)amrd_dump; sc->amrd_disk->d_unit = sc->amrd_unit; - sc->amrd_disk->d_flags = 0; + sc->amrd_disk->d_flags = DISKFLAG_CANFLUSHCACHE; sc->amrd_disk->d_sectorsize = AMR_BLKSIZE; sc->amrd_disk->d_mediasize = (off_t)sc->amrd_drive->al_size * AMR_BLKSIZE; sc->amrd_disk->d_fwsectors = sc->amrd_drive->al_sectors; --- sys/dev/ata/ata-disk.c.orig +++ sys/dev/ata/ata-disk.c @@ -151,6 +151,8 @@ adp->disk->d_fwsectors = adp->sectors; adp->disk->d_fwheads = adp->heads; adp->disk->d_unit = device_get_unit(dev); + if (atadev->param.support.command2 & ATA_SUPPORT_FLUSHCACHE) + adp->disk->d_flags = DISKFLAG_CANFLUSHCACHE; disk_create(adp->disk, DISK_VERSION); device_add_child(dev, "subdisk", device_get_unit(dev)); bus_generic_attach(dev); @@ -260,6 +262,17 @@ else request->u.ata.command = ATA_WRITE; break; + case BIO_FLUSH: + request->u.ata.lba = 0; + request->u.ata.count = 0; + request->u.ata.feature = 0; + request->bytecount = 0; + request->transfersize = 0; + request->timeout = 1; + request->retries = 0; + request->flags = ATA_R_CONTROL; + request->u.ata.command = ATA_FLUSHCACHE; + break; default: device_printf(dev, "FAILURE - unknown BIO operation\n"); ata_free_request(request); --- sys/dev/ata/ata-raid.c.orig +++ sys/dev/ata/ata-raid.c @@ -146,6 +146,21 @@ rdp->disk->d_maxsize = 128 * DEV_BSIZE; rdp->disk->d_drv1 = rdp; rdp->disk->d_unit = rdp->lun; + /* we support flushing cache if all components support it */ + /* XXX: not all components can be connected at this point */ + rdp->disk->d_flags = DISKFLAG_CANFLUSHCACHE; + for (disk = 0; disk < rdp->total_disks; disk++) { + struct ata_device *atadev; + + if (rdp->disks[disk].dev == NULL) + continue; + if ((atadev = device_get_softc(rdp->disks[disk].dev)) == NULL) + continue; + if (atadev->param.support.command2 & ATA_SUPPORT_FLUSHCACHE) + continue; + rdp->disk->d_flags = 0; + break; + } disk_create(rdp->disk, DISK_VERSION); printf("ar%d: %juMB <%s %s%s> status: %s\n", rdp->lun, @@ -229,6 +244,39 @@ return error; } +static int +ata_raid_flush(struct bio *bp) +{ + struct ar_softc *rdp = bp->bio_disk->d_drv1; + struct ata_request *request; + device_t dev; + int disk, error; + + error = 0; + bp->bio_pflags = 0; + + for (disk = 0; disk < rdp->total_disks; disk++) { + if ((dev = rdp->disks[disk].dev) != NULL) + bp->bio_pflags++; + } + for (disk = 0; disk < rdp->total_disks; disk++) { + if ((dev = rdp->disks[disk].dev) == NULL) + continue; + if (!(request = ata_raid_init_request(rdp, bp))) + return ENOMEM; + request->dev = dev; + request->u.ata.command = ATA_FLUSHCACHE; + request->u.ata.lba = 0; + request->u.ata.count = 0; + request->u.ata.feature = 0; + request->timeout = 1; + request->retries = 0; + request->flags |= ATA_R_ORDERED | ATA_R_DIRECT; + ata_queue_request(request); + } + return 0; +} + static void ata_raid_strategy(struct bio *bp) { @@ -238,6 +286,15 @@ u_int64_t blkno, lba, blk = 0; int count, chunk, drv, par = 0, change = 0; + if (bp->bio_cmd == BIO_FLUSH) { + int error; + + error = ata_raid_flush(bp); + if (error != 0) + biofinish(bp, NULL, error); + return; + } + if (!(rdp->status & AR_S_READY) || (bp->bio_cmd != BIO_READ && bp->bio_cmd != BIO_WRITE)) { biofinish(bp, NULL, EIO); @@ -554,6 +611,15 @@ struct bio *bp = request->bio; int i, mirror, finished = 0; + if (bp->bio_cmd == BIO_FLUSH) { + if (bp->bio_error == 0) + bp->bio_error = request->result; + ata_free_request(request); + if (--bp->bio_pflags == 0) + biodone(bp); + return; + } + switch (rdp->type) { case AR_T_JBOD: case AR_T_SPAN: @@ -3957,6 +4023,9 @@ case BIO_WRITE: request->flags = ATA_R_WRITE; break; + case BIO_FLUSH: + request->flags = ATA_R_CONTROL; + break; } return request; } --- sys/geom/concat/g_concat.c.orig +++ sys/geom/concat/g_concat.c @@ -212,6 +212,42 @@ } static void +g_concat_flush(struct g_concat_softc *sc, struct bio *bp) +{ + struct bio_queue_head queue; + struct g_consumer *cp; + struct bio *cbp; + u_int no; + + bioq_init(&queue); + for (no = 0; no < sc->sc_ndisks; no++) { + cbp = g_clone_bio(bp); + if (cbp == NULL) { + for (cbp = bioq_first(&queue); cbp != NULL; + cbp = bioq_first(&queue)) { + bioq_remove(&queue, cbp); + g_destroy_bio(cbp); + } + if (bp->bio_error == 0) + bp->bio_error = ENOMEM; + g_io_deliver(bp, bp->bio_error); + return; + } + bioq_insert_tail(&queue, cbp); + cbp->bio_done = g_std_done; + cbp->bio_caller1 = sc->sc_disks[no].d_consumer; + cbp->bio_to = sc->sc_disks[no].d_consumer->provider; + } + for (cbp = bioq_first(&queue); cbp != NULL; cbp = bioq_first(&queue)) { + bioq_remove(&queue, cbp); + G_CONCAT_LOGREQ(cbp, "Sending request."); + cp = cbp->bio_caller1; + cbp->bio_caller1 = NULL; + g_io_request(cbp, cp); + } +} + +static void g_concat_start(struct bio *bp) { struct bio_queue_head queue; @@ -240,6 +276,9 @@ case BIO_WRITE: case BIO_DELETE: break; + case BIO_FLUSH: + g_concat_flush(sc, bp); + return; case BIO_GETATTR: /* To which provider it should be delivered? */ default: --- sys/geom/eli/g_eli.c.orig +++ sys/geom/eli/g_eli.c @@ -258,6 +258,7 @@ case BIO_READ: case BIO_WRITE: case BIO_GETATTR: + case BIO_FLUSH: break; case BIO_DELETE: /* @@ -298,6 +299,7 @@ wakeup(sc); break; case BIO_GETATTR: + case BIO_FLUSH: cbp->bio_done = g_std_done; cp = LIST_FIRST(&sc->sc_geom->consumer); cbp->bio_to = cp->provider; --- sys/geom/geom.h.orig +++ sys/geom/geom.h @@ -265,6 +265,7 @@ void g_destroy_bio(struct bio *); void g_io_deliver(struct bio *bp, int error); int g_io_getattr(const char *attr, struct g_consumer *cp, int *len, void *ptr); +int g_io_flush(struct g_consumer *cp); void g_io_request(struct bio *bp, struct g_consumer *cp); struct bio *g_new_bio(void); struct bio *g_alloc_bio(void); --- sys/geom/geom_disk.c.orig +++ sys/geom/geom_disk.c @@ -206,8 +206,10 @@ bp2->bio_inbed++; if (bp2->bio_children == bp2->bio_inbed) { bp2->bio_resid = bp2->bio_bcount - bp2->bio_completed; - if ((dp = bp2->bio_to->geom->softc)) + if ((bp2->bio_cmd & (BIO_READ|BIO_WRITE|BIO_DELETE)) && + (dp = bp2->bio_to->geom->softc)) { devstat_end_transaction_bio(dp->d_devstat, bp2); + } g_io_deliver(bp2, bp2->bio_error); } mtx_unlock(&g_disk_done_mtx); @@ -304,6 +306,24 @@ else error = ENOIOCTL; break; + case BIO_FLUSH: + g_trace(G_T_TOPOLOGY, "g_disk_flushcache(%s)", + bp->bio_to->name); + if (!(dp->d_flags & DISKFLAG_CANFLUSHCACHE)) { + g_io_deliver(bp, ENODEV); + return; + } + bp2 = g_clone_bio(bp); + if (bp2 == NULL) { + g_io_deliver(bp, ENOMEM); + return; + } + bp2->bio_done = g_disk_done; + bp2->bio_disk = dp; + g_disk_lock_giant(dp); + dp->d_strategy(bp2); + g_disk_unlock_giant(dp); + break; default: error = EOPNOTSUPP; break; --- sys/geom/geom_disk.h.orig +++ sys/geom/geom_disk.h @@ -91,6 +91,7 @@ #define DISKFLAG_NEEDSGIANT 0x1 #define DISKFLAG_OPEN 0x2 #define DISKFLAG_CANDELETE 0x4 +#define DISKFLAG_CANFLUSHCACHE 0x8 struct disk *disk_alloc(void); void disk_create(struct disk *disk, int version); --- sys/geom/geom_io.c.orig +++ sys/geom/geom_io.c @@ -199,6 +199,26 @@ return (error); } +int +g_io_flush(struct g_consumer *cp) +{ + struct bio *bp; + int error; + + g_trace(G_T_BIO, "bio_flush(%s)", cp->provider->name); + bp = g_alloc_bio(); + bp->bio_cmd = BIO_FLUSH; + bp->bio_done = NULL; + bp->bio_attribute = NULL; + bp->bio_offset = cp->provider->mediasize; + bp->bio_length = 0; + bp->bio_data = NULL; + g_io_request(bp, cp); + error = biowait(bp, "gflush"); + g_destroy_bio(bp); + return (error); +} + static int g_io_check(struct bio *bp) { @@ -217,6 +237,7 @@ break; case BIO_WRITE: case BIO_DELETE: + case BIO_FLUSH: if (cp->acw == 0) return (EPERM); break; @@ -259,10 +280,13 @@ KASSERT(cp != NULL, ("NULL cp in g_io_request")); KASSERT(bp != NULL, ("NULL bp in g_io_request")); - KASSERT(bp->bio_data != NULL, ("NULL bp->data in g_io_request")); pp = cp->provider; KASSERT(pp != NULL, ("consumer not attached in g_io_request")); + if (bp->bio_cmd & (BIO_READ|BIO_WRITE|BIO_DELETE|BIO_GETATTR)) { + KASSERT(bp->bio_data != NULL, + ("NULL bp->data in g_io_request")); + } if (bp->bio_cmd & (BIO_READ|BIO_WRITE|BIO_DELETE)) { KASSERT(bp->bio_offset % cp->provider->sectorsize == 0, ("wrong offset %jd for sectorsize %u", @@ -564,6 +588,10 @@ cmd = "GETATTR"; printf("%s[%s(attr=%s)]", pname, cmd, bp->bio_attribute); return; + case BIO_FLUSH: + cmd = "FLUSH"; + printf("%s[%s]", pname, cmd); + return; case BIO_READ: cmd = "READ"; case BIO_WRITE: --- sys/geom/geom_slice.c.orig +++ sys/geom/geom_slice.c @@ -260,6 +260,8 @@ gkd->length = gsp->slices[idx].length; /* now, pass it on downwards... */ } + /* FALLTHROUGH */ + case BIO_FLUSH: bp2 = g_clone_bio(bp); if (bp2 == NULL) { g_io_deliver(bp, ENOMEM); --- /dev/null Tue Oct 24 16:34:10 2006 +++ sys/geom/journal/g_journal.c Tue Oct 24 16:34:13 2006 @@ -0,0 +1,3024 @@ +/*- + * Copyright (c) 2005-2006 Pawel Jakub Dawidek + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#ifdef GJ_MEMDEBUG +#include +#include +#endif +#include +#include +#include + +#include + + +/* + * On-disk journal format: + * + * JH - Journal header + * RH - Record header + * + * %%%%%% ****** +------+ +------+ ****** +------+ %%%%%% + * % JH % * RH * | Data | | Data | ... * RH * | Data | ... % JH % ... + * %%%%%% ****** +------+ +------+ ****** +------+ %%%%%% + * + */ + +CTASSERT(sizeof(struct g_journal_header) <= 512); +CTASSERT(sizeof(struct g_journal_record_header) <= 512); + +static MALLOC_DEFINE(M_JOURNAL, "journal_data", "GEOM_JOURNAL Data"); +static struct mtx g_journal_cache_mtx; +MTX_SYSINIT(g_journal_cache, &g_journal_cache_mtx, "cache usage", MTX_DEF); + +const struct g_journal_desc *g_journal_filesystems[] = { + &g_journal_ufs, + NULL +}; + +SYSCTL_DECL(_kern_geom); + +int g_journal_debug = 0; +TUNABLE_INT("kern.geom.journal.debug", &g_journal_debug); +static u_int g_journal_switch_time = 10; +static u_int g_journal_force_switch = 70; +static u_int g_journal_parallel_flushes = 16; +static u_int g_journal_parallel_copies = 16; +static u_int g_journal_accept_immediately = 64; +static u_int g_journal_record_entries = GJ_RECORD_HEADER_NENTRIES; +static u_int g_journal_do_optimize = 1; + +SYSCTL_NODE(_kern_geom, OID_AUTO, journal, CTLFLAG_RW, 0, "GEOM_JOURNAL stuff"); +SYSCTL_INT(_kern_geom_journal, OID_AUTO, debug, CTLFLAG_RW, &g_journal_debug, 0, + "Debug level"); +SYSCTL_UINT(_kern_geom_journal, OID_AUTO, switch_time, CTLFLAG_RW, + &g_journal_switch_time, 0, "Switch journals every N seconds"); +SYSCTL_UINT(_kern_geom_journal, OID_AUTO, force_switch, CTLFLAG_RW, + &g_journal_force_switch, 0, "Force switch when journal is N%% full"); +SYSCTL_UINT(_kern_geom_journal, OID_AUTO, parallel_flushes, CTLFLAG_RW, + &g_journal_parallel_flushes, 0, + "Number of flush I/O requests send in parallel"); +SYSCTL_UINT(_kern_geom_journal, OID_AUTO, accept_immediately, CTLFLAG_RW, + &g_journal_accept_immediately, 0, + "Number of I/O requests accepted immediatelly"); +SYSCTL_UINT(_kern_geom_journal, OID_AUTO, parallel_copies, CTLFLAG_RW, + &g_journal_parallel_copies, 0, + "Number of copy I/O requests send in parallel"); +static int +g_journal_record_entries_sysctl(SYSCTL_HANDLER_ARGS) +{ + u_int entries; + int error; + + entries = g_journal_record_entries; + error = sysctl_handle_int(oidp, &entries, sizeof(entries), req); + if (error != 0 || req->newptr == NULL) + return (error); + if (entries < 1 || entries > GJ_RECORD_HEADER_NENTRIES) + return (EINVAL); + g_journal_record_entries = entries; + return (0); +} +SYSCTL_PROC(_kern_geom_journal, OID_AUTO, record_entries, + CTLTYPE_UINT | CTLFLAG_RW, NULL, 0, g_journal_record_entries_sysctl, "I", + "Maximum number of entires in one journal record"); +SYSCTL_UINT(_kern_geom_journal, OID_AUTO, optimize, CTLFLAG_RW, + &g_journal_do_optimize, 0, "Try to combine bios on flush and copy"); + +static u_int g_journal_cache_used = 0; +static u_int g_journal_cache_limit = 64 * 1024 * 1024; +TUNABLE_INT("kern.geom.journal.cache.limit", &g_journal_cache_limit); +static u_int g_journal_cache_divisor = 2; +TUNABLE_INT("kern.geom.journal.cache.divisor", &g_journal_cache_divisor); +static u_int g_journal_cache_switch = 90; +static u_int g_journal_cache_misses = 0; +static u_int g_journal_cache_alloc_failures = 0; +static u_int g_journal_cache_low = 0; + +SYSCTL_NODE(_kern_geom_journal, OID_AUTO, cache, CTLFLAG_RW, 0, + "GEOM_JOURNAL cache"); +SYSCTL_UINT(_kern_geom_journal_cache, OID_AUTO, used, CTLFLAG_RD, + &g_journal_cache_used, 0, "Number of allocated bytes"); +static int +g_journal_cache_limit_sysctl(SYSCTL_HANDLER_ARGS) +{ + u_int limit; + int error; + + limit = g_journal_cache_limit; + error = sysctl_handle_int(oidp, &limit, sizeof(limit), req); + if (error != 0 || req->newptr == NULL) + return (error); + g_journal_cache_limit = limit; + g_journal_cache_low = (limit / 100) * g_journal_cache_switch; + return (0); +} +SYSCTL_PROC(_kern_geom_journal_cache, OID_AUTO, limit, + CTLTYPE_UINT | CTLFLAG_RW, NULL, 0, g_journal_cache_limit_sysctl, "I", + "Maximum number of allocated bytes"); +SYSCTL_UINT(_kern_geom_journal_cache, OID_AUTO, divisor, CTLFLAG_RDTUN, + &g_journal_cache_divisor, 0, + "(kmem_size / kern.geom.journal.cache.divisor) == cache size"); +static int +g_journal_cache_switch_sysctl(SYSCTL_HANDLER_ARGS) +{ + u_int cswitch; + int error; + + cswitch = g_journal_cache_switch; + error = sysctl_handle_int(oidp, &cswitch, sizeof(cswitch), req); + if (error != 0 || req->newptr == NULL) + return (error); + if (cswitch < 0 || cswitch > 100) + return (EINVAL); + g_journal_cache_switch = cswitch; + g_journal_cache_low = (g_journal_cache_limit / 100) * cswitch; + return (0); +} +SYSCTL_PROC(_kern_geom_journal_cache, OID_AUTO, switch, + CTLTYPE_UINT | CTLFLAG_RW, NULL, 0, g_journal_cache_switch_sysctl, "I", + "Force switch when we hit this percent of cache use"); +SYSCTL_UINT(_kern_geom_journal_cache, OID_AUTO, misses, CTLFLAG_RW, + &g_journal_cache_misses, 0, "Number of cache misses"); +SYSCTL_UINT(_kern_geom_journal_cache, OID_AUTO, alloc_failures, CTLFLAG_RW, + &g_journal_cache_alloc_failures, 0, "Memory allocation failures"); + +static u_long g_journal_stats_bytes_skipped = 0; +static u_long g_journal_stats_combined_ios = 0; +static u_long g_journal_stats_switches = 0; +static u_long g_journal_stats_wait_for_copy = 0; +static u_long g_journal_stats_journal_full = 0; +static u_long g_journal_stats_low_mem = 0; + +SYSCTL_NODE(_kern_geom_journal, OID_AUTO, stats, CTLFLAG_RW, 0, + "GEOM_JOURNAL statistics"); +SYSCTL_ULONG(_kern_geom_journal_stats, OID_AUTO, skipped_bytes, CTLFLAG_RW, + &g_journal_stats_bytes_skipped, 0, "Number of skipped bytes"); +SYSCTL_ULONG(_kern_geom_journal_stats, OID_AUTO, combined_ios, CTLFLAG_RW, + &g_journal_stats_combined_ios, 0, "Number of combined I/O requests"); +SYSCTL_ULONG(_kern_geom_journal_stats, OID_AUTO, switches, CTLFLAG_RW, + &g_journal_stats_switches, 0, "Number of journal switches"); +SYSCTL_ULONG(_kern_geom_journal_stats, OID_AUTO, wait_for_copy, CTLFLAG_RW, + &g_journal_stats_wait_for_copy, 0, "Wait for journal copy on switch"); +SYSCTL_ULONG(_kern_geom_journal_stats, OID_AUTO, journal_full, CTLFLAG_RW, + &g_journal_stats_journal_full, 0, + "Number of times journal was almost full."); +SYSCTL_ULONG(_kern_geom_journal_stats, OID_AUTO, low_mem, CTLFLAG_RW, + &g_journal_stats_low_mem, 0, "Number of times low_mem hook was called."); + +static g_taste_t g_journal_taste; +static g_ctl_req_t g_journal_config; +static g_dumpconf_t g_journal_dumpconf; +static g_init_t g_journal_init; +static g_fini_t g_journal_fini; + +struct g_class g_journal_class = { + .name = G_JOURNAL_CLASS_NAME, + .version = G_VERSION, + .taste = g_journal_taste, + .ctlreq = g_journal_config, + .dumpconf = g_journal_dumpconf, + .init = g_journal_init, + .fini = g_journal_fini +}; + +static int g_journal_destroy(struct g_journal_softc *sc); +static void g_journal_metadata_update(struct g_journal_softc *sc); +static void g_journal_switch_wait(struct g_journal_softc *sc); + +#define GJ_SWITCHER_WORKING 0 +#define GJ_SWITCHER_DIE 1 +#define GJ_SWITCHER_DIED 2 +static int g_journal_switcher_state = GJ_SWITCHER_WORKING; +static int g_journal_switcher_wokenup = 0; +static int g_journal_sync_requested = 0; + +#ifdef GJ_MEMDEBUG +struct meminfo { + size_t mi_size; + struct stack mi_stack; +}; +#endif + +/* + * We use our own malloc/realloc/free funtions, so we can collect statistics + * and force journal switch when we're running out of cache. + */ +static void * +gj_malloc(size_t size, int flags) +{ + void *p; +#ifdef GJ_MEMDEBUG + struct meminfo *mi; +#endif + + mtx_lock(&g_journal_cache_mtx); + if (g_journal_cache_limit > 0 && !g_journal_switcher_wokenup && + g_journal_cache_used + size > g_journal_cache_low) { + GJ_DEBUG(1, "No cache, waking up the switcher."); + g_journal_switcher_wokenup = 1; + wakeup(&g_journal_switcher_state); + } + if ((flags & M_NOWAIT) && g_journal_cache_limit > 0 && + g_journal_cache_used + size > g_journal_cache_limit) { + mtx_unlock(&g_journal_cache_mtx); + g_journal_cache_alloc_failures++; + return (NULL); + } + g_journal_cache_used += size; + mtx_unlock(&g_journal_cache_mtx); + flags &= ~M_NOWAIT; +#ifndef GJ_MEMDEBUG + p = malloc(size, M_JOURNAL, flags | M_WAITOK); +#else + mi = malloc(sizeof(*mi) + size, M_JOURNAL, flags | M_WAITOK); + p = (u_char *)mi + sizeof(*mi); + mi->mi_size = size; + stack_save(&mi->mi_stack); +#endif + return (p); +} + +static void +gj_free(void *p, size_t size) +{ +#ifdef GJ_MEMDEBUG + struct meminfo *mi; +#endif + + KASSERT(p != NULL, ("p=NULL")); + KASSERT(size > 0, ("size=0")); + mtx_lock(&g_journal_cache_mtx); + KASSERT(g_journal_cache_used >= size, ("Freeing too much?")); + g_journal_cache_used -= size; + mtx_unlock(&g_journal_cache_mtx); +#ifdef GJ_MEMDEBUG + mi = p = (void *)((u_char *)p - sizeof(*mi)); + if (mi->mi_size != size) { + printf("GJOURNAL: Size mismatch! %zu != %zu\n", size, + mi->mi_size); + printf("GJOURNAL: Alloc backtrace:\n"); + stack_print(&mi->mi_stack); + printf("GJOURNAL: Free backtrace:\n"); + kdb_backtrace(); + } +#endif + free(p, M_JOURNAL); +} + +static void * +gj_realloc(void *p, size_t size, size_t oldsize) +{ + void *np; + +#ifndef GJ_MEMDEBUG + mtx_lock(&g_journal_cache_mtx); + g_journal_cache_used -= oldsize; + g_journal_cache_used += size; + mtx_unlock(&g_journal_cache_mtx); + np = realloc(p, size, M_JOURNAL, M_WAITOK); +#else + np = gj_malloc(size, M_WAITOK); + bcopy(p, np, MIN(oldsize, size)); + gj_free(p, oldsize); +#endif + return (np); +} + +static void +g_journal_check_overflow(struct g_journal_softc *sc) +{ + off_t length, used; + + if ((sc->sc_active.jj_offset < sc->sc_inactive.jj_offset && + sc->sc_journal_offset >= sc->sc_inactive.jj_offset) || + (sc->sc_active.jj_offset > sc->sc_inactive.jj_offset && + sc->sc_journal_offset >= sc->sc_inactive.jj_offset && + sc->sc_journal_offset < sc->sc_active.jj_offset)) { + panic("Journal overflow (joffset=%jd active=%jd inactive=%jd)", + (intmax_t)sc->sc_journal_offset, + (intmax_t)sc->sc_active.jj_offset, + (intmax_t)sc->sc_inactive.jj_offset); + } + if (sc->sc_active.jj_offset < sc->sc_inactive.jj_offset) { + length = sc->sc_inactive.jj_offset - sc->sc_active.jj_offset; + used = sc->sc_journal_offset - sc->sc_active.jj_offset; + } else { + length = sc->sc_jend - sc->sc_active.jj_offset; + length += sc->sc_inactive.jj_offset - sc->sc_jstart; + if (sc->sc_journal_offset >= sc->sc_active.jj_offset) + used = sc->sc_journal_offset - sc->sc_active.jj_offset; + else { + used = sc->sc_jend - sc->sc_active.jj_offset; + used += sc->sc_journal_offset - sc->sc_jstart; + } + } + /* Already woken up? */ + if (g_journal_switcher_wokenup) + return; + /* + * If the active journal takes more than g_journal_force_switch precent + * of free journal space, we force journal switch. + */ + KASSERT(length > 0, + ("length=%jd used=%jd active=%jd inactive=%jd joffset=%jd", + (intmax_t)length, (intmax_t)used, + (intmax_t)sc->sc_active.jj_offset, + (intmax_t)sc->sc_inactive.jj_offset, + (intmax_t)sc->sc_journal_offset)); + if ((used * 100) / length > g_journal_force_switch) { + g_journal_stats_journal_full++; + GJ_DEBUG(1, "Journal %s %jd%% full, forcing journal switch.", + sc->sc_name, (used * 100) / length); + mtx_lock(&g_journal_cache_mtx); + g_journal_switcher_wokenup = 1; + wakeup(&g_journal_switcher_state); + mtx_unlock(&g_journal_cache_mtx); + } +} + +static void +g_journal_orphan(struct g_consumer *cp) +{ + struct g_journal_softc *sc; + char name[256]; + int error; + + g_topology_assert(); + sc = cp->geom->softc; + GJ_DEBUG(0, "Lost provider %s (journal=%s).", cp->provider->name, + sc->sc_name); + strlcpy(name, sc->sc_name, sizeof(name)); + error = g_journal_destroy(sc); + if (error == 0) + GJ_DEBUG(0, "Journal %s destroyed.", name); + else { + GJ_DEBUG(0, "Cannot destroy journal %s (error=%d). " + "Destroy it manually after last close.", sc->sc_name, + error); + } +} + +static int +g_journal_access(struct g_provider *pp, int acr, int acw, int ace) +{ + struct g_journal_softc *sc; + int dcr, dcw, dce; + + g_topology_assert(); + GJ_DEBUG(2, "Access request for %s: r%dw%de%d.", pp->name, + acr, acw, ace); + + dcr = pp->acr + acr; + dcw = pp->acw + acw; + dce = pp->ace + ace; + + sc = pp->geom->softc; + if (sc == NULL || (sc->sc_flags & GJF_DEVICE_DESTROY)) { + if (acr <= 0 && acw <= 0 && ace <= 0) + return (0); + else + return (ENXIO); + } + if (pp->acw == 0 && dcw > 0) { + GJ_DEBUG(1, "Marking %s as dirty.", sc->sc_name); + sc->sc_flags &= ~GJF_DEVICE_CLEAN; + g_topology_unlock(); + g_journal_metadata_update(sc); + g_topology_lock(); + } /* else if (pp->acw == 0 && dcw > 0 && JEMPTY(sc)) { + GJ_DEBUG(1, "Marking %s as clean.", sc->sc_name); + sc->sc_flags |= GJF_DEVICE_CLEAN; + g_topology_unlock(); + g_journal_metadata_update(sc); + g_topology_lock(); + } */ + return (0); +} + +static void +g_journal_header_encode(struct g_journal_header *hdr, u_char *data) +{ + + bcopy(GJ_HEADER_MAGIC, data, sizeof(GJ_HEADER_MAGIC)); + data += sizeof(GJ_HEADER_MAGIC); + le32enc(data, hdr->jh_journal_id); + data += 4; + le32enc(data, hdr->jh_journal_next_id); +} + +static int +g_journal_header_decode(const u_char *data, struct g_journal_header *hdr) +{ + + bcopy(data, hdr->jh_magic, sizeof(hdr->jh_magic)); + data += sizeof(hdr->jh_magic); + if (bcmp(hdr->jh_magic, GJ_HEADER_MAGIC, sizeof(GJ_HEADER_MAGIC)) != 0) + return (EINVAL); + hdr->jh_journal_id = le32dec(data); + data += 4; + hdr->jh_journal_next_id = le32dec(data); + return (0); +} + +static void +g_journal_flush_cache(struct g_journal_softc *sc) +{ + struct bintime bt; + int error; + + if (sc->sc_bio_flush == 0) + return; + GJ_TIMER_START(1, &bt); + if (sc->sc_bio_flush & GJ_FLUSH_JOURNAL) { + error = g_io_flush(sc->sc_jconsumer); + GJ_DEBUG(error == 0 ? 2 : 0, "Flush cache of %s: error=%d.", + sc->sc_jconsumer->provider->name, error); + } + if (sc->sc_bio_flush & GJ_FLUSH_DATA) { + /* + * TODO: This could be called in parallel with the + * previous call. + */ + error = g_io_flush(sc->sc_dconsumer); + GJ_DEBUG(error == 0 ? 2 : 0, "Flush cache of %s: error=%d.", + sc->sc_dconsumer->provider->name, error); + } + GJ_TIMER_STOP(1, &bt, "Cache flush time"); +} + +static int +g_journal_write_header(struct g_journal_softc *sc) +{ + struct g_journal_header hdr; + struct g_consumer *cp; + u_char *buf; + int error; + + cp = sc->sc_jconsumer; + buf = gj_malloc(cp->provider->sectorsize, M_WAITOK); + + strlcpy(hdr.jh_magic, GJ_HEADER_MAGIC, sizeof(hdr.jh_magic)); + hdr.jh_journal_id = sc->sc_journal_id; + hdr.jh_journal_next_id = sc->sc_journal_next_id; + g_journal_header_encode(&hdr, buf); + error = g_write_data(cp, sc->sc_journal_offset, buf, + cp->provider->sectorsize); + /* if (error == 0) */ + sc->sc_journal_offset += cp->provider->sectorsize; + + gj_free(buf, cp->provider->sectorsize); + return (error); +} + +/* + * Every journal record has a header and data following it. + * Functions below are used to decode the header before storing it to + * little endian and to encode it after reading to system endianess. + */ +static void +g_journal_record_header_encode(struct g_journal_record_header *hdr, + u_char *data) +{ + struct g_journal_entry *ent; + u_int i; + + bcopy(GJ_RECORD_HEADER_MAGIC, data, sizeof(GJ_RECORD_HEADER_MAGIC)); + data += sizeof(GJ_RECORD_HEADER_MAGIC); + le32enc(data, hdr->jrh_journal_id); + data += 8; + le16enc(data, hdr->jrh_nentries); + data += 2; + bcopy(hdr->jrh_sum, data, sizeof(hdr->jrh_sum)); + data += 8; + for (i = 0; i < hdr->jrh_nentries; i++) { + ent = &hdr->jrh_entries[i]; + le64enc(data, ent->je_joffset); + data += 8; + le64enc(data, ent->je_offset); + data += 8; + le64enc(data, ent->je_length); + data += 8; + } +} + +static int +g_journal_record_header_decode(const u_char *data, + struct g_journal_record_header *hdr) +{ + struct g_journal_entry *ent; + u_int i; + + bcopy(data, hdr->jrh_magic, sizeof(hdr->jrh_magic)); + data += sizeof(hdr->jrh_magic); + if (strcmp(hdr->jrh_magic, GJ_RECORD_HEADER_MAGIC) != 0) + return (EINVAL); + hdr->jrh_journal_id = le32dec(data); + data += 8; + hdr->jrh_nentries = le16dec(data); + data += 2; + if (hdr->jrh_nentries > GJ_RECORD_HEADER_NENTRIES) + return (EINVAL); + bcopy(data, hdr->jrh_sum, sizeof(hdr->jrh_sum)); + data += 8; + for (i = 0; i < hdr->jrh_nentries; i++) { + ent = &hdr->jrh_entries[i]; + ent->je_joffset = le64dec(data); + data += 8; + ent->je_offset = le64dec(data); + data += 8; + ent->je_length = le64dec(data); + data += 8; + } + return (0); +} + +/* + * Function reads metadata from a provider (via the given consumer), decodes + * it to system endianess and verifies its correctness. + */ +static int +g_journal_metadata_read(struct g_consumer *cp, struct g_journal_metadata *md) +{ + struct g_provider *pp; + u_char *buf; + int error; + + g_topology_assert(); + + error = g_access(cp, 1, 0, 0); + if (error != 0) + return (error); + pp = cp->provider; + g_topology_unlock(); + /* Metadata is stored in last sector. */ + buf = g_read_data(cp, pp->mediasize - pp->sectorsize, pp->sectorsize, + &error); + g_topology_lock(); + g_access(cp, -1, 0, 0); + if (error != 0) { + GJ_DEBUG(1, "Cannot read metadata from %s (error=%d).", + cp->provider->name, error); + if (buf != NULL) + g_free(buf); + return (error); + } + + /* Decode metadata. */ + error = journal_metadata_decode(buf, md); + g_free(buf); + /* Is this is gjournal provider at all? */ + if (strcmp(md->md_magic, G_JOURNAL_MAGIC) != 0) + return (EINVAL); + /* + * Are we able to handle this version of metadata? + * We only maintain backward compatibility. + */ + if (md->md_version > G_JOURNAL_VERSION) { + GJ_DEBUG(0, + "Kernel module is too old to handle metadata from %s.", + cp->provider->name); + return (EINVAL); + } + /* Is checksum correct? */ + if (error != 0) { + GJ_DEBUG(0, "MD5 metadata hash mismatch for provider %s.", + cp->provider->name); + return (error); + } + return (0); +} + +/* + * Two functions below are responsible for updating metadata. + * Only metadata on the data provider is updated (we need to update + * information about active journal in there). + */ +static void +g_journal_metadata_done(struct bio *bp) +{ + + /* + * There is not much we can do on error except informing about it. + */ + if (bp->bio_error != 0) { + GJ_LOGREQ(0, bp, "Cannot update metadata (error=%d).", + bp->bio_error); + } else { + GJ_LOGREQ(2, bp, "Metadata updated."); + } + gj_free(bp->bio_data, bp->bio_length); + g_destroy_bio(bp); +} + +static void +g_journal_metadata_update(struct g_journal_softc *sc) +{ + struct g_journal_metadata md; + struct g_consumer *cp; + struct bio *bp; + u_char *sector; + + cp = sc->sc_dconsumer; + sector = gj_malloc(cp->provider->sectorsize, M_WAITOK); + strlcpy(md.md_magic, G_JOURNAL_MAGIC, sizeof(md.md_magic)); + md.md_version = G_JOURNAL_VERSION; + md.md_id = sc->sc_id; + md.md_type = sc->sc_orig_type; + md.md_jstart = sc->sc_jstart; + md.md_jend = sc->sc_jend; + md.md_joffset = sc->sc_inactive.jj_offset; + md.md_jid = sc->sc_journal_previous_id; + md.md_flags = 0; + if (sc->sc_flags & GJF_DEVICE_CLEAN) + md.md_flags |= GJ_FLAG_CLEAN; + + if (sc->sc_flags & GJF_DEVICE_HARDCODED) + strlcpy(md.md_provider, sc->sc_name, sizeof(md.md_provider)); + else + bzero(md.md_provider, sizeof(md.md_provider)); + md.md_provsize = cp->provider->mediasize; + journal_metadata_encode(&md, sector); + + /* + * Flush the cache, so we know all data are on disk. + * We write here informations like "journal is consistent", so we need + * to be sure it is. Without BIO_FLUSH here, we can end up in situation + * where metadata is stored on disk, but not all data. + */ + g_journal_flush_cache(sc); + + bp = g_alloc_bio(); + bp->bio_offset = cp->provider->mediasize - cp->provider->sectorsize; + bp->bio_length = cp->provider->sectorsize; + bp->bio_data = sector; + bp->bio_cmd = BIO_WRITE; + if (!(sc->sc_flags & GJF_DEVICE_DESTROY)) { + bp->bio_done = g_journal_metadata_done; + g_io_request(bp, cp); + } else { + bp->bio_done = NULL; + g_io_request(bp, cp); + biowait(bp, "gjmdu"); + g_journal_metadata_done(bp); + } + + /* + * Be sure metadata reached the disk. + */ + g_journal_flush_cache(sc); +} + +/* + * This is where the I/O request comes from the GEOM. + */ +static void +g_journal_start(struct bio *bp) +{ + struct g_journal_softc *sc; + + sc = bp->bio_to->geom->softc; + GJ_LOGREQ(3, bp, "Request received."); + + switch (bp->bio_cmd) { + case BIO_READ: + case BIO_WRITE: + mtx_lock(&sc->sc_mtx); + bioq_insert_tail(&sc->sc_regular_queue, bp); + wakeup(sc); + mtx_unlock(&sc->sc_mtx); + return; + case BIO_GETATTR: + if (strcmp(bp->bio_attribute, "GJOURNAL::provider") == 0) { + strlcpy(bp->bio_data, bp->bio_to->name, bp->bio_length); + bp->bio_completed = strlen(bp->bio_to->name) + 1; + g_io_deliver(bp, 0); + return; + } + /* FALLTHROUGH */ + case BIO_DELETE: + default: + g_io_deliver(bp, EOPNOTSUPP); + return; + } +} + +static void +g_journal_std_done(struct bio *bp) +{ + struct g_journal_softc *sc; + + sc = bp->bio_from->geom->softc; + mtx_lock(&sc->sc_mtx); + bioq_insert_tail(&sc->sc_back_queue, bp); + wakeup(sc); + mtx_unlock(&sc->sc_mtx); +} + +static struct bio * +g_journal_new_bio(off_t start, off_t end, off_t joffset, u_char *data, + int flags) +{ + struct bio *bp; + + bp = g_alloc_bio(); + bp->bio_offset = start; + bp->bio_joffset = joffset; + bp->bio_length = end - start; + bp->bio_cmd = BIO_WRITE; + bp->bio_done = g_journal_std_done; + if (data == NULL) + bp->bio_data = NULL; + else { + bp->bio_data = gj_malloc(bp->bio_length, flags); + if (bp->bio_data != NULL) + bcopy(data, bp->bio_data, bp->bio_length); + } + return (bp); +} + +#define g_journal_insert_bio(head, bp, flags) \ + g_journal_insert((head), (bp)->bio_offset, \ + (bp)->bio_offset + (bp)->bio_length, (bp)->bio_joffset, \ + (bp)->bio_data, flags) +/* + * The function below does a lot more than just inserting bio to the queue. + * It keeps the queue sorted by offset and ensures that there are no doubled + * data (it combines bios where ranges overlap). + * + * The function returns the number of bios inserted (as bio can be splitted). + */ +static int +g_journal_insert(struct bio **head, off_t nstart, off_t nend, off_t joffset, + u_char *data, int flags) +{ + struct bio *nbp, *cbp, *pbp; + off_t cstart, cend; + u_char *tmpdata; + int n; + + GJ_DEBUG(3, "INSERT(%p): (%jd, %jd, %jd)", *head, nstart, nend, + joffset); + n = 0; + pbp = NULL; + GJQ_FOREACH(*head, cbp) { + cstart = cbp->bio_offset; + cend = cbp->bio_offset + cbp->bio_length; + + if (nstart >= cend) { + /* + * +-------------+ + * | | + * | current | +-------------+ + * | bio | | | + * | | | new | + * +-------------+ | bio | + * | | + * +-------------+ + */ + GJ_DEBUG(3, "INSERT(%p): 1", *head); + } else if (nend <= cstart) { + /* + * +-------------+ + * | | + * +-------------+ | current | + * | | | bio | + * | new | | | + * | bio | +-------------+ + * | | + * +-------------+ + */ + nbp = g_journal_new_bio(nstart, nend, joffset, data, + flags); + if (pbp == NULL) + *head = nbp; + else + pbp->bio_next = nbp; + nbp->bio_next = cbp; + n++; + GJ_DEBUG(3, "INSERT(%p): 2 (nbp=%p pbp=%p)", *head, nbp, + pbp); + goto end; + } else if (nstart <= cstart && nend >= cend) { + /* + * +-------------+ +-------------+ + * | current bio | | current bio | + * +---+-------------+---+ +-------------+---+ + * | | | | | | | + * | | | | | | | + * | +-------------+ | +-------------+ | + * | new bio | | new bio | + * +---------------------+ +-----------------+ + * + * +-------------+ +-------------+ + * | current bio | | current bio | + * +---+-------------+ +-------------+ + * | | | | | + * | | | | | + * | +-------------+ +-------------+ + * | new bio | | new bio | + * +-----------------+ +-------------+ + */ + g_journal_stats_bytes_skipped += cbp->bio_length; + cbp->bio_offset = nstart; + cbp->bio_joffset = joffset; + cbp->bio_length = cend - nstart; + if (cbp->bio_data != NULL) { + gj_free(cbp->bio_data, cend - cstart); + cbp->bio_data = NULL; + } + if (data != NULL) { + cbp->bio_data = gj_malloc(cbp->bio_length, + flags); + if (cbp->bio_data != NULL) { + bcopy(data, cbp->bio_data, + cbp->bio_length); + } + data += cend - nstart; + } + joffset += cend - nstart; + nstart = cend; + GJ_DEBUG(3, "INSERT(%p): 3 (cbp=%p)", *head, cbp); + } else if (nstart > cstart && nend >= cend) { + /* + * +-----------------+ +-------------+ + * | current bio | | current bio | + * | +-------------+ | +---------+---+ + * | | | | | | | + * | | | | | | | + * +---+-------------+ +---+---------+ | + * | new bio | | new bio | + * +-------------+ +-------------+ + */ + g_journal_stats_bytes_skipped += cend - nstart; + nbp = g_journal_new_bio(nstart, cend, joffset, data, + flags); + nbp->bio_next = cbp->bio_next; + cbp->bio_next = nbp; + cbp->bio_length = nstart - cstart; + if (cbp->bio_data != NULL) { + cbp->bio_data = gj_realloc(cbp->bio_data, + cbp->bio_length, cend - cstart); + } + if (data != NULL) + data += cend - nstart; + joffset += cend - nstart; + nstart = cend; + n++; + GJ_DEBUG(3, "INSERT(%p): 4 (cbp=%p)", *head, cbp); + } else if (nstart > cstart && nend < cend) { + /* + * +---------------------+ + * | current bio | + * | +-------------+ | + * | | | | + * | | | | + * +---+-------------+---+ + * | new bio | + * +-------------+ + */ + g_journal_stats_bytes_skipped += nend - nstart; + nbp = g_journal_new_bio(nstart, nend, joffset, data, + flags); + nbp->bio_next = cbp->bio_next; + cbp->bio_next = nbp; + if (cbp->bio_data == NULL) + tmpdata = NULL; + else + tmpdata = cbp->bio_data + nend - cstart; + nbp = g_journal_new_bio(nend, cend, + cbp->bio_joffset + nend - cstart, tmpdata, flags); + nbp->bio_next = ((struct bio *)cbp->bio_next)->bio_next; + ((struct bio *)cbp->bio_next)->bio_next = nbp; + cbp->bio_length = nstart - cstart; + if (cbp->bio_data != NULL) { + cbp->bio_data = gj_realloc(cbp->bio_data, + cbp->bio_length, cend - cstart); + } + n += 2; + GJ_DEBUG(3, "INSERT(%p): 5 (cbp=%p)", *head, cbp); + goto end; + } else if (nstart <= cstart && nend < cend) { + /* + * +-----------------+ +-------------+ + * | current bio | | current bio | + * +-------------+ | +---+---------+ | + * | | | | | | | + * | | | | | | | + * +-------------+---+ | +---------+---+ + * | new bio | | new bio | + * +-------------+ +-------------+ + */ + g_journal_stats_bytes_skipped += nend - nstart; + nbp = g_journal_new_bio(nstart, nend, joffset, data, + flags); + if (pbp == NULL) + *head = nbp; + else + pbp->bio_next = nbp; + nbp->bio_next = cbp; + cbp->bio_offset = nend; + cbp->bio_length = cend - nend; + cbp->bio_joffset += nend - cstart; + tmpdata = cbp->bio_data; + if (tmpdata != NULL) { + cbp->bio_data = gj_malloc(cbp->bio_length, + flags); + if (cbp->bio_data != NULL) { + bcopy(tmpdata + nend - cstart, + cbp->bio_data, cbp->bio_length); + } + gj_free(tmpdata, cend - cstart); + } + n++; + GJ_DEBUG(3, "INSERT(%p): 6 (cbp=%p)", *head, cbp); + goto end; + } + if (nstart == nend) + goto end; + pbp = cbp; + } + nbp = g_journal_new_bio(nstart, nend, joffset, data, flags); + if (pbp == NULL) + *head = nbp; + else + pbp->bio_next = nbp; + nbp->bio_next = NULL; + n++; + GJ_DEBUG(3, "INSERT(%p): 8 (nbp=%p pbp=%p)", *head, nbp, pbp); +end: + if (g_journal_debug >= 3) { + GJQ_FOREACH(*head, cbp) { + GJ_DEBUG(3, "ELEMENT: %p (%jd, %jd, %jd, %p)", cbp, + (intmax_t)cbp->bio_offset, + (intmax_t)cbp->bio_length, + (intmax_t)cbp->bio_joffset, cbp->bio_data); + } + GJ_DEBUG(3, "INSERT(%p): DONE %d", *head, n); + } + return (n); +} + +/* + * The function combines neighbour bios trying to squeeze as much data as + * possible into one bio. + * + * The function returns the number of bios combined (negative value). + */ +static int +g_journal_optimize(struct bio *head) +{ + struct bio *cbp, *pbp; + int n; + + n = 0; + pbp = NULL; + GJQ_FOREACH(head, cbp) { + /* Skip bios which has to be read first. */ + if (cbp->bio_data == NULL) { + pbp = NULL; + continue; + } + /* There is no previous bio yet. */ + if (pbp == NULL) { + pbp = cbp; + continue; + } + /* Is this a neighbour bio? */ + if (pbp->bio_offset + pbp->bio_length != cbp->bio_offset) { + /* Be sure that bios queue is sorted. */ + KASSERT(pbp->bio_offset + pbp->bio_length < cbp->bio_offset, + ("poffset=%jd plength=%jd coffset=%jd", + (intmax_t)pbp->bio_offset, + (intmax_t)pbp->bio_length, + (intmax_t)cbp->bio_offset)); + pbp = cbp; + continue; + } + /* Be sure we don't end up with too big bio. */ + if (pbp->bio_length + cbp->bio_length > MAXPHYS) { + pbp = cbp; + continue; + } + /* Ok, we can join bios. */ + GJ_LOGREQ(4, pbp, "Join: "); + GJ_LOGREQ(4, cbp, "and: "); + pbp->bio_data = gj_realloc(pbp->bio_data, + pbp->bio_length + cbp->bio_length, pbp->bio_length); + bcopy(cbp->bio_data, pbp->bio_data + pbp->bio_length, + cbp->bio_length); + gj_free(cbp->bio_data, cbp->bio_length); + pbp->bio_length += cbp->bio_length; + pbp->bio_next = cbp->bio_next; + g_destroy_bio(cbp); + cbp = pbp; + g_journal_stats_combined_ios++; + n--; + GJ_LOGREQ(4, pbp, "Got: "); + } + return (n); +} + +/* + * TODO: Update comment. + * These are functions responsible for copying one portion of data from journal + * to the destination provider. + * The order goes like this: + * 1. Read the header, which contains informations about data blocks + * following it. + * 2. Read the data blocks from the journal. + * 3. Write the data blocks on the data provider. + * + * g_journal_copy_start() + * g_journal_copy_done() - got finished write request, logs potential errors. + */ + +/* + * When there is no data in cache, this function is used to read it. + */ +static void +g_journal_read_first(struct g_journal_softc *sc, struct bio *bp) +{ + struct bio *cbp; + + /* + * We were short in memory, so data was freed. + * In that case we need to read it back from journal. + */ + cbp = g_alloc_bio(); + cbp->bio_cflags = bp->bio_cflags; + cbp->bio_parent = bp; + cbp->bio_offset = bp->bio_joffset; + cbp->bio_length = bp->bio_length; + cbp->bio_data = gj_malloc(bp->bio_length, M_WAITOK); + cbp->bio_cmd = BIO_READ; + cbp->bio_done = g_journal_std_done; + GJ_LOGREQ(4, cbp, "READ FIRST"); + g_io_request(cbp, sc->sc_jconsumer); + g_journal_cache_misses++; +} + +static void +g_journal_copy_send(struct g_journal_softc *sc) +{ + struct bio *bioq, *bp, *lbp; + + bioq = lbp = NULL; + mtx_lock(&sc->sc_mtx); + for (; sc->sc_copy_in_progress < g_journal_parallel_copies;) { + bp = GJQ_FIRST(sc->sc_inactive.jj_queue); + if (bp == NULL) + break; + GJQ_REMOVE(sc->sc_inactive.jj_queue, bp); + sc->sc_copy_in_progress++; + GJQ_INSERT_AFTER(bioq, bp, lbp); + lbp = bp; + } + mtx_unlock(&sc->sc_mtx); + if (g_journal_do_optimize) + sc->sc_copy_in_progress += g_journal_optimize(bioq); + while ((bp = GJQ_FIRST(bioq)) != NULL) { + GJQ_REMOVE(bioq, bp); + GJQ_INSERT_HEAD(sc->sc_copy_queue, bp); + bp->bio_cflags = GJ_BIO_COPY; + if (bp->bio_data == NULL) + g_journal_read_first(sc, bp); + else { + bp->bio_joffset = 0; + GJ_LOGREQ(4, bp, "SEND"); + g_io_request(bp, sc->sc_dconsumer); + } + } +} + +static void +g_journal_copy_start(struct g_journal_softc *sc) +{ + + /* + * Remember in metadata that we're starting to copy journaled data + * to the data provider. + * In case of power failure, we will copy these data once again on boot. + */ + if (!sc->sc_journal_copying) { + sc->sc_journal_copying = 1; + GJ_DEBUG(1, "Starting copy of journal."); + g_journal_metadata_update(sc); + } + g_journal_copy_send(sc); +} + +/* + * Data block has been read from the journal provider. + */ +static int +g_journal_copy_read_done(struct bio *bp) +{ + struct g_journal_softc *sc; + struct g_consumer *cp; + struct bio *pbp; + + KASSERT(bp->bio_cflags == GJ_BIO_COPY, + ("Invalid bio (%d != %d).", bp->bio_cflags, GJ_BIO_COPY)); + + sc = bp->bio_from->geom->softc; + pbp = bp->bio_parent; + + if (bp->bio_error != 0) { + GJ_DEBUG(0, "Error while reading data from %s (error=%d).", + bp->bio_to->name, bp->bio_error); + /* + * We will not be able to deliver WRITE request as well. + */ + gj_free(bp->bio_data, bp->bio_length); + g_destroy_bio(pbp); + g_destroy_bio(bp); + sc->sc_copy_in_progress--; + return (1); + } + pbp->bio_data = bp->bio_data; + cp = sc->sc_dconsumer; + g_io_request(pbp, cp); + GJ_LOGREQ(4, bp, "READ DONE"); + g_destroy_bio(bp); + return (0); +} + +/* + * Data block has been written to the data provider. + */ +static void +g_journal_copy_write_done(struct bio *bp) +{ + struct g_journal_softc *sc; + + KASSERT(bp->bio_cflags == GJ_BIO_COPY, + ("Invalid bio (%d != %d).", bp->bio_cflags, GJ_BIO_COPY)); + + sc = bp->bio_from->geom->softc; + sc->sc_copy_in_progress--; + + if (bp->bio_error != 0) { + GJ_LOGREQ(0, bp, "[copy] Error while writting data (error=%d)", + bp->bio_error); + } + GJQ_REMOVE(sc->sc_copy_queue, bp); + gj_free(bp->bio_data, bp->bio_length); + GJ_LOGREQ(4, bp, "DONE"); + g_destroy_bio(bp); + + if (sc->sc_copy_in_progress == 0) { + /* + * This was the last write request for this journal. + */ + GJ_DEBUG(1, "Data has been copied."); + sc->sc_journal_copying = 0; + } +} + +static void g_journal_flush_done(struct bio *bp); + +/* + * Flush one record onto active journal provider. + */ +static void +g_journal_flush(struct g_journal_softc *sc) +{ + struct g_journal_record_header hdr; + struct g_journal_entry *ent; + struct g_provider *pp; + struct bio **bioq; + struct bio *bp, *fbp, *pbp; + off_t joffset, size; + u_char *data, hash[16]; + MD5_CTX ctx; + u_int i; + + if (sc->sc_current_count == 0) + return; + + size = 0; + pp = sc->sc_jprovider; + GJ_VALIDATE_OFFSET(sc->sc_journal_offset, sc); + joffset = sc->sc_journal_offset; + + GJ_DEBUG(2, "Storing %d journal entries on %s at %jd.", + sc->sc_current_count, pp->name, (intmax_t)joffset); + + /* + * Store 'journal id', so we know to which journal this record belongs. + */ + hdr.jrh_journal_id = sc->sc_journal_id; + /* Could be less than g_journal_record_entries if called due timeout. */ + hdr.jrh_nentries = MIN(sc->sc_current_count, g_journal_record_entries); + strlcpy(hdr.jrh_magic, GJ_RECORD_HEADER_MAGIC, sizeof(hdr.jrh_magic)); + + bioq = &sc->sc_active.jj_queue; + pbp = sc->sc_flush_queue; + + fbp = g_alloc_bio(); + fbp->bio_parent = NULL; + fbp->bio_cflags = GJ_BIO_JOURNAL; + fbp->bio_offset = -1; + fbp->bio_joffset = joffset; + fbp->bio_length = pp->sectorsize; + fbp->bio_cmd = BIO_WRITE; + fbp->bio_done = g_journal_std_done; + GJQ_INSERT_AFTER(sc->sc_flush_queue, fbp, pbp); + pbp = fbp; + fbp->bio_to = pp; + GJ_LOGREQ(4, fbp, "FLUSH_OUT"); + joffset += pp->sectorsize; + sc->sc_flush_count++; + if (sc->sc_flags & GJF_DEVICE_CHECKSUM) + MD5Init(&ctx); + + for (i = 0; i < hdr.jrh_nentries; i++) { + bp = sc->sc_current_queue; + KASSERT(bp != NULL, ("NULL bp")); + bp->bio_to = pp; + GJ_LOGREQ(4, bp, "FLUSHED"); + sc->sc_current_queue = bp->bio_next; + bp->bio_next = NULL; + sc->sc_current_count--; + + /* Add to the header. */ + ent = &hdr.jrh_entries[i]; + ent->je_offset = bp->bio_offset; + ent->je_joffset = joffset; + ent->je_length = bp->bio_length; + size += ent->je_length; + + data = bp->bio_data; + if (sc->sc_flags & GJF_DEVICE_CHECKSUM) + MD5Update(&ctx, data, ent->je_length); + bzero(bp, sizeof(*bp)); + bp->bio_cflags = GJ_BIO_JOURNAL; + bp->bio_offset = ent->je_offset; + bp->bio_joffset = ent->je_joffset; + bp->bio_length = ent->je_length; + bp->bio_data = data; + bp->bio_cmd = BIO_WRITE; + bp->bio_done = g_journal_std_done; + GJQ_INSERT_AFTER(sc->sc_flush_queue, bp, pbp); + pbp = bp; + bp->bio_to = pp; + GJ_LOGREQ(4, bp, "FLUSH_OUT"); + joffset += bp->bio_length; + sc->sc_flush_count++; + + /* + * Add request to the active sc_journal_queue queue. + * This is our cache. After journal switch we don't have to + * read the data from the inactive journal, because we keep + * it in memory. + */ + g_journal_insert(bioq, ent->je_offset, + ent->je_offset + ent->je_length, ent->je_joffset, data, + M_NOWAIT); + } + + /* + * After all requests, store valid header. + */ + data = gj_malloc(pp->sectorsize, M_WAITOK); + if (sc->sc_flags & GJF_DEVICE_CHECKSUM) { + MD5Final(hash, &ctx); + bcopy(hash, hdr.jrh_sum, sizeof(hdr.jrh_sum)); + } + g_journal_record_header_encode(&hdr, data); + fbp->bio_data = data; + + sc->sc_journal_offset = joffset; + + g_journal_check_overflow(sc); +} + +/* + * Flush request finished. + */ +static void +g_journal_flush_done(struct bio *bp) +{ + struct g_journal_softc *sc; + struct g_consumer *cp; + + KASSERT((bp->bio_cflags & GJ_BIO_MASK) == GJ_BIO_JOURNAL, + ("Invalid bio (%d != %d).", bp->bio_cflags, GJ_BIO_JOURNAL)); + + cp = bp->bio_from; + sc = cp->geom->softc; + sc->sc_flush_in_progress--; + + if (bp->bio_error != 0) { + GJ_LOGREQ(0, bp, "[flush] Error while writting data (error=%d)", + bp->bio_error); + } + gj_free(bp->bio_data, bp->bio_length); + GJ_LOGREQ(4, bp, "DONE"); + g_destroy_bio(bp); +} + +static void g_journal_release_delayed(struct g_journal_softc *sc); + +static void +g_journal_flush_send(struct g_journal_softc *sc) +{ + struct g_consumer *cp; + struct bio *bioq, *bp, *lbp; + + cp = sc->sc_jconsumer; + bioq = lbp = NULL; + while (sc->sc_flush_in_progress < g_journal_parallel_flushes) { + /* Send one flush requests to the active journal. */ + bp = GJQ_FIRST(sc->sc_flush_queue); + if (bp != NULL) { + GJQ_REMOVE(sc->sc_flush_queue, bp); + sc->sc_flush_count--; + bp->bio_offset = bp->bio_joffset; + bp->bio_joffset = 0; + sc->sc_flush_in_progress++; + GJQ_INSERT_AFTER(bioq, bp, lbp); + lbp = bp; + } + /* Try to release delayed requests. */ + g_journal_release_delayed(sc); + /* If there are no requests to flush, leave. */ + if (GJQ_FIRST(sc->sc_flush_queue) == NULL) + break; + } + if (g_journal_do_optimize) + sc->sc_flush_in_progress += g_journal_optimize(bioq); + while ((bp = GJQ_FIRST(bioq)) != NULL) { + GJQ_REMOVE(bioq, bp); + GJ_LOGREQ(3, bp, "Flush request send"); + g_io_request(bp, cp); + } +} + +static void +g_journal_add_current(struct g_journal_softc *sc, struct bio *bp) +{ + int n; + + GJ_LOGREQ(4, bp, "CURRENT %d", sc->sc_current_count); + n = g_journal_insert_bio(&sc->sc_current_queue, bp, M_WAITOK); + sc->sc_current_count += n; + n = g_journal_optimize(sc->sc_current_queue); + sc->sc_current_count += n; + /* + * For requests which are added to the current queue we deliver + * response immediately. + */ + bp->bio_completed = bp->bio_length; + g_io_deliver(bp, 0); + if (sc->sc_current_count >= g_journal_record_entries) { + /* + * Let's flush one record onto active journal provider. + */ + g_journal_flush(sc); + } +} + +static void +g_journal_release_delayed(struct g_journal_softc *sc) +{ + struct bio *bp; + + for (;;) { + /* The flush queue is full, exit. */ + if (sc->sc_flush_count >= g_journal_accept_immediately) + return; + bp = bioq_takefirst(&sc->sc_delayed_queue); + if (bp == NULL) + return; + sc->sc_delayed_count--; + g_journal_add_current(sc, bp); + } +} + +/* + * Add I/O request to the current queue. If we have enough requests for one + * journal record we flush them onto active journal provider. + */ +static void +g_journal_add_request(struct g_journal_softc *sc, struct bio *bp) +{ + + /* + * The flush queue is full, we need to delay the request. + */ + if (sc->sc_delayed_count > 0 || + sc->sc_flush_count >= g_journal_accept_immediately) { + GJ_LOGREQ(4, bp, "DELAYED"); + bioq_insert_tail(&sc->sc_delayed_queue, bp); + sc->sc_delayed_count++; + return; + } + + KASSERT(TAILQ_EMPTY(&sc->sc_delayed_queue.queue), + ("DELAYED queue not empty.")); + g_journal_add_current(sc, bp); +} + +static void g_journal_read_done(struct bio *bp); + +/* + * Try to find requested data in cache. + */ +static struct bio * +g_journal_read_find(struct bio *head, int sorted, struct bio *pbp, off_t ostart, + off_t oend) +{ + off_t cstart, cend; + struct bio *bp; + + GJQ_FOREACH(head, bp) { + if (bp->bio_offset == -1) + continue; + cstart = MAX(ostart, bp->bio_offset); + cend = MIN(oend, bp->bio_offset + bp->bio_length); + if (cend <= ostart) + continue; + else if (cstart >= oend) { + if (!sorted) + continue; + else { + bp = NULL; + break; + } + } + if (bp->bio_data == NULL) + break; + GJ_DEBUG(3, "READ(%p): (%jd, %jd) (bp=%p)", head, cstart, cend, + bp); + bcopy(bp->bio_data + cstart - bp->bio_offset, + pbp->bio_data + cstart - pbp->bio_offset, cend - cstart); + pbp->bio_completed += cend - cstart; + if (pbp->bio_completed == pbp->bio_length) { + /* + * Cool, the whole request was in cache, deliver happy + * message. + */ + g_io_deliver(pbp, 0); + return (pbp); + } + break; + } + return (bp); +} + +/* + * Try to find requested data in cache. + */ +static struct bio * +g_journal_read_queue_find(struct bio_queue *head, struct bio *pbp, off_t ostart, + off_t oend) +{ + off_t cstart, cend; + struct bio *bp; + + TAILQ_FOREACH(bp, head, bio_queue) { + cstart = MAX(ostart, bp->bio_offset); + cend = MIN(oend, bp->bio_offset + bp->bio_length); + if (cend <= ostart) + continue; + else if (cstart >= oend) + continue; + KASSERT(bp->bio_data != NULL, + ("%s: bio_data == NULL", __func__)); + GJ_DEBUG(3, "READ(%p): (%jd, %jd) (bp=%p)", head, cstart, cend, + bp); + bcopy(bp->bio_data + cstart - bp->bio_offset, + pbp->bio_data + cstart - pbp->bio_offset, cend - cstart); + pbp->bio_completed += cend - cstart; + if (pbp->bio_completed == pbp->bio_length) { + /* + * Cool, the whole request was in cache, deliver happy + * message. + */ + g_io_deliver(pbp, 0); + return (pbp); + } + break; + } + return (bp); +} + +/* + * This function is used for colecting data on read. + * The complexity is because parts of the data can be stored in four different + * places: + * - in delayed requests + * - in memory - the data not yet send to the active journal provider + * - in requests which are going to be sent to the active journal + * - in the active journal + * - in the inactive journal + * - in the data provider + */ +static void +g_journal_read(struct g_journal_softc *sc, struct bio *pbp, off_t ostart, + off_t oend) +{ + struct bio *bp, *nbp, *head; + off_t cstart, cend; + u_int i, sorted = 0; + + GJ_DEBUG(3, "READ: (%jd, %jd)", ostart, oend); + + cstart = cend = -1; + bp = NULL; + head = NULL; + for (i = 0; i <= 5; i++) { + switch (i) { + case 0: /* Delayed requests. */ + head = NULL; + sorted = 0; + break; + case 1: /* Not-yet-send data. */ + head = sc->sc_current_queue; + sorted = 1; + break; + case 2: /* In-flight to the active journal. */ + head = sc->sc_flush_queue; + sorted = 0; + break; + case 3: /* Active journal. */ + head = sc->sc_active.jj_queue; + sorted = 1; + break; + case 4: /* Inactive journal. */ + /* + * XXX: Here could be a race with g_journal_lowmem(). + */ + head = sc->sc_inactive.jj_queue; + sorted = 1; + break; + case 5: /* In-flight to the data provider. */ + head = sc->sc_copy_queue; + sorted = 0; + break; + default: + panic("gjournal %s: i=%d", __func__, i); + } + if (i == 0) + bp = g_journal_read_queue_find(&sc->sc_delayed_queue.queue, pbp, ostart, oend); + else + bp = g_journal_read_find(head, sorted, pbp, ostart, oend); + if (bp == pbp) { /* Got the whole request. */ + GJ_DEBUG(2, "Got the whole request from %u.", i); + return; + } else if (bp != NULL) { + cstart = MAX(ostart, bp->bio_offset); + cend = MIN(oend, bp->bio_offset + bp->bio_length); + GJ_DEBUG(2, "Got part of the request from %u (%jd-%jd).", + i, (intmax_t)cstart, (intmax_t)cend); + break; + } + } + if (bp != NULL) { + if (bp->bio_data == NULL) { + nbp = g_clone_bio(pbp); + nbp->bio_cflags = GJ_BIO_READ; + nbp->bio_data = + pbp->bio_data + cstart - pbp->bio_offset; + nbp->bio_offset = + bp->bio_joffset + cstart - bp->bio_offset; + nbp->bio_length = cend - cstart; + nbp->bio_done = g_journal_read_done; + g_io_request(nbp, sc->sc_jconsumer); + } + /* + * If we don't have the whole request yet, call g_journal_read() + * recursively. + */ + if (ostart < cstart) + g_journal_read(sc, pbp, ostart, cstart); + if (oend > cend) + g_journal_read(sc, pbp, cend, oend); + } else { + /* + * No data in memory, no data in journal. + * Its time for asking data provider. + */ + GJ_DEBUG(3, "READ(data): (%jd, %jd)", ostart, oend); + nbp = g_clone_bio(pbp); + nbp->bio_cflags = GJ_BIO_READ; + nbp->bio_data = pbp->bio_data + ostart - pbp->bio_offset; + nbp->bio_offset = ostart; + nbp->bio_length = oend - ostart; + nbp->bio_done = g_journal_read_done; + g_io_request(nbp, sc->sc_dconsumer); + /* We have the whole request, return here. */ + return; + } +} + +/* + * Function responsible for handling finished READ requests. + * Actually, g_std_done() could be used here, the only difference is that we + * log error. + */ +static void +g_journal_read_done(struct bio *bp) +{ + struct bio *pbp; + + KASSERT(bp->bio_cflags == GJ_BIO_READ, + ("Invalid bio (%d != %d).", bp->bio_cflags, GJ_BIO_READ)); + + pbp = bp->bio_parent; + pbp->bio_inbed++; + pbp->bio_completed += bp->bio_length; + + if (bp->bio_error != 0) { + if (pbp->bio_error == 0) + pbp->bio_error = bp->bio_error; + GJ_DEBUG(0, "Error while reading data from %s (error=%d).", + bp->bio_to->name, bp->bio_error); + } + g_destroy_bio(bp); + if (pbp->bio_children == pbp->bio_inbed && + pbp->bio_completed == pbp->bio_length) { + /* We're done. */ + g_io_deliver(pbp, 0); + } +} + +/* + * Deactive current journal and active next one. + */ +static void +g_journal_switch(struct g_journal_softc *sc) +{ + struct g_provider *pp; + + if (JEMPTY(sc)) { + GJ_DEBUG(3, "No need for %s switch.", sc->sc_name); + pp = LIST_FIRST(&sc->sc_geom->provider); + if (!(sc->sc_flags & GJF_DEVICE_CLEAN) && pp->acw == 0) { + sc->sc_flags |= GJF_DEVICE_CLEAN; + GJ_DEBUG(1, "Marking %s as clean.", sc->sc_name); + g_journal_metadata_update(sc); + } + } else { + GJ_DEBUG(3, "Switching journal %s.", sc->sc_geom->name); + + pp = sc->sc_jprovider; + + sc->sc_journal_previous_id = sc->sc_journal_id; + + sc->sc_journal_id = sc->sc_journal_next_id; + sc->sc_journal_next_id = arc4random(); + + GJ_VALIDATE_OFFSET(sc->sc_journal_offset, sc); + + g_journal_write_header(sc); + + sc->sc_inactive.jj_offset = sc->sc_active.jj_offset; + sc->sc_inactive.jj_queue = sc->sc_active.jj_queue; + + sc->sc_active.jj_offset = + sc->sc_journal_offset - pp->sectorsize; + sc->sc_active.jj_queue = NULL; + + /* + * Switch is done, start copying data from the (now) inactive + * journal to the data provider. + */ + g_journal_copy_start(sc); + } + mtx_lock(&sc->sc_mtx); + sc->sc_flags &= ~GJF_DEVICE_SWITCH; + mtx_unlock(&sc->sc_mtx); +} + +static void +g_journal_initialize(struct g_journal_softc *sc) +{ + + sc->sc_journal_id = arc4random(); + sc->sc_journal_next_id = arc4random(); + sc->sc_journal_previous_id = sc->sc_journal_id; + sc->sc_journal_offset = sc->sc_jstart; + sc->sc_inactive.jj_offset = sc->sc_jstart; + g_journal_write_header(sc); + sc->sc_active.jj_offset = sc->sc_jstart; +} + +static void +g_journal_mark_as_dirty(struct g_journal_softc *sc) +{ + const struct g_journal_desc *desc; + int i; + + GJ_DEBUG(1, "Marking file system %s as dirty.", sc->sc_name); + for (i = 0; (desc = g_journal_filesystems[i]) != NULL; i++) + desc->jd_dirty(sc->sc_dconsumer); +} + +/* + * Function read record header from the given journal. + * It is very simlar to g_read_data(9), but it doesn't allocate memory for bio + * and data on every call. + */ +static int +g_journal_sync_read(struct g_consumer *cp, struct bio *bp, off_t offset, + void *data) +{ + int error; + + bzero(bp, sizeof(*bp)); + bp->bio_cmd = BIO_READ; + bp->bio_done = NULL; + bp->bio_offset = offset; + bp->bio_length = cp->provider->sectorsize; + bp->bio_data = data; + g_io_request(bp, cp); + error = biowait(bp, "gjs_read"); + return (error); +} + +#if 0 +/* + * Function is called when we start the journal device and we detect that + * one of the journals was not fully copied. + * The purpose of this function is to read all records headers from journal + * and placed them in the inactive queue, so we can start journal + * synchronization process and the journal provider itself. + * Design decision was taken to not synchronize the whole journal here as it + * can take too much time. Reading headers only and delaying synchronization + * process until after journal provider is started should be the best choice. + */ +#endif + +static void +g_journal_sync(struct g_journal_softc *sc) +{ + struct g_journal_record_header rhdr; + struct g_journal_entry *ent; + struct g_journal_header jhdr; + struct g_consumer *cp; + struct bio *bp, *fbp, *tbp; + off_t joffset, offset; + u_char *buf, sum[16]; + uint64_t id; + MD5_CTX ctx; + int error, found, i; + + found = 0; + fbp = NULL; + cp = sc->sc_jconsumer; + bp = g_alloc_bio(); + buf = gj_malloc(cp->provider->sectorsize, M_WAITOK); + offset = joffset = sc->sc_inactive.jj_offset = sc->sc_journal_offset; + + GJ_DEBUG(2, "Looking for termination at %jd.", (intmax_t)joffset); + + /* + * Read and decode first journal header. + */ + error = g_journal_sync_read(cp, bp, offset, buf); + if (error != 0) { + GJ_DEBUG(0, "Error while reading journal header from %s.", + cp->provider->name); + goto end; + } + error = g_journal_header_decode(buf, &jhdr); + if (error != 0) { + GJ_DEBUG(0, "Cannot decode journal header from %s.", + cp->provider->name); + goto end; + } + id = sc->sc_journal_id; + if (jhdr.jh_journal_id != sc->sc_journal_id) { + GJ_DEBUG(1, "Journal ID mismatch at %jd (0x%08x != 0x%08x).", + (intmax_t)offset, (u_int)jhdr.jh_journal_id, (u_int)id); + goto end; + } + offset += cp->provider->sectorsize; + id = sc->sc_journal_next_id = jhdr.jh_journal_next_id; + + for (;;) { + /* + * If the biggest record won't fit, look for a record header or + * journal header from the begining. + */ + GJ_VALIDATE_OFFSET(offset, sc); + error = g_journal_sync_read(cp, bp, offset, buf); + if (error != 0) { + /* + * Not good. Having an error while reading header + * means, that we cannot read next headers and in + * consequence we cannot find termination. + */ + GJ_DEBUG(0, + "Error while reading record header from %s.", + cp->provider->name); + break; + } + + error = g_journal_record_header_decode(buf, &rhdr); + if (error != 0) { + GJ_DEBUG(2, "Not a record header at %jd (error=%d).", + (intmax_t)offset, error); + /* + * This is not a record header. + * If we are lucky, this is next journal header. + */ + error = g_journal_header_decode(buf, &jhdr); + if (error != 0) { + GJ_DEBUG(1, "Not a journal header at %jd (error=%d).", + (intmax_t)offset, error); + /* + * Nope, this is not journal header, which + * bascially means that journal is not + * terminated properly. + */ + error = ENOENT; + break; + } + /* + * Ok. This is header of _some_ journal. Now we need to + * verify if this is header of the _next_ journal. + */ + if (jhdr.jh_journal_id != id) { + GJ_DEBUG(1, "Journal ID mismatch at %jd " + "(0x%08x != 0x%08x).", (intmax_t)offset, + (u_int)jhdr.jh_journal_id, (u_int)id); + error = ENOENT; + break; + } + + /* Found termination. */ + found++; + GJ_DEBUG(1, "Found termination at %jd (id=0x%08x).", + (intmax_t)offset, (u_int)id); + sc->sc_active.jj_offset = offset; + sc->sc_journal_offset = + offset + cp->provider->sectorsize; + sc->sc_journal_id = id; + id = sc->sc_journal_next_id = jhdr.jh_journal_next_id; + + while ((tbp = fbp) != NULL) { + fbp = tbp->bio_next; + GJ_LOGREQ(3, tbp, "Adding request."); + g_journal_insert_bio(&sc->sc_inactive.jj_queue, + tbp, M_WAITOK); + } + + /* Skip journal's header. */ + offset += cp->provider->sectorsize; + continue; + } + + /* Skip record's header. */ + offset += cp->provider->sectorsize; + + /* + * Add information about every record entry to the inactive + * queue. + */ + if (sc->sc_flags & GJF_DEVICE_CHECKSUM) + MD5Init(&ctx); + for (i = 0; i < rhdr.jrh_nentries; i++) { + ent = &rhdr.jrh_entries[i]; + GJ_DEBUG(3, "Insert entry: %jd %jd.", + (intmax_t)ent->je_offset, (intmax_t)ent->je_length); + g_journal_insert(&fbp, ent->je_offset, + ent->je_offset + ent->je_length, ent->je_joffset, + NULL, M_WAITOK); + if (sc->sc_flags & GJF_DEVICE_CHECKSUM) { + u_char *buf2; + + /* + * TODO: Should use faster function (like + * g_journal_sync_read()). + */ + buf2 = g_read_data(cp, offset, ent->je_length, + NULL); + if (buf2 == NULL) + GJ_DEBUG(0, "Cannot read data at %jd.", + (intmax_t)offset); + else { + MD5Update(&ctx, buf2, ent->je_length); + g_free(buf2); + } + } + /* Skip entry's data. */ + offset += ent->je_length; + } + if (sc->sc_flags & GJF_DEVICE_CHECKSUM) { + MD5Final(sum, &ctx); + if (bcmp(sum, rhdr.jrh_sum, sizeof(rhdr.jrh_sum)) != 0) { + GJ_DEBUG(0, "MD5 hash mismatch at %jd!", + (intmax_t)offset); + } + } + } +end: + gj_free(bp->bio_data, cp->provider->sectorsize); + g_destroy_bio(bp); + + /* Remove bios from unterminated journal. */ + while ((tbp = fbp) != NULL) { + fbp = tbp->bio_next; + g_destroy_bio(tbp); + } + + if (found < 1 && joffset > 0) { + GJ_DEBUG(0, "Journal on %s is broken/corrupted. Initializing.", + sc->sc_name); + while ((tbp = sc->sc_inactive.jj_queue) != NULL) { + sc->sc_inactive.jj_queue = tbp->bio_next; + g_destroy_bio(tbp); + } + g_journal_initialize(sc); + g_journal_mark_as_dirty(sc); + } else { + GJ_DEBUG(0, "Journal %s consistent.", sc->sc_name); + g_journal_copy_start(sc); + } +} + +/* + * Wait for requests. + * If we have requests in the current queue, flush them after 3 seconds from the + * last flush. In this way we don't wait forever (or for journal switch) with + * storing not full records on journal. + */ +static void +g_journal_wait(struct g_journal_softc *sc, time_t last_write) +{ + int error, timeout; + + GJ_DEBUG(3, "%s: enter", __func__); + if (sc->sc_current_count == 0) { + if (g_journal_debug < 2) + msleep(sc, &sc->sc_mtx, PRIBIO | PDROP, "gj:work", 0); + else { + /* + * If we have debug turned on, show number of elements + * in various queues. + */ + for (;;) { + error = msleep(sc, &sc->sc_mtx, PRIBIO, + "gj:work", hz * 3); + if (error == 0) { + mtx_unlock(&sc->sc_mtx); + break; + } + GJ_DEBUG(3, "Report: current count=%d", + sc->sc_current_count); + GJ_DEBUG(3, "Report: flush count=%d", + sc->sc_flush_count); + GJ_DEBUG(3, "Report: flush in progress=%d", + sc->sc_flush_in_progress); + GJ_DEBUG(3, "Report: copy in progress=%d", + sc->sc_copy_in_progress); + GJ_DEBUG(3, "Report: delayed=%d", + sc->sc_delayed_count); + } + } + GJ_DEBUG(3, "%s: exit 1", __func__); + return; + } + + /* + * Flush even not full records every 3 seconds. + */ + timeout = (last_write + 3 - time_second) * hz; + if (timeout <= 0) { + mtx_unlock(&sc->sc_mtx); + g_journal_flush(sc); + g_journal_flush_send(sc); + GJ_DEBUG(3, "%s: exit 2", __func__); + return; + } + error = msleep(sc, &sc->sc_mtx, PRIBIO | PDROP, "gj:work", timeout); + if (error == EWOULDBLOCK) + g_journal_flush_send(sc); + GJ_DEBUG(3, "%s: exit 3", __func__); +} + +/* + * Worker thread. + */ +static void +g_journal_worker(void *arg) +{ + struct g_journal_softc *sc; + struct g_geom *gp; + struct g_provider *pp; + struct bio *bp; + time_t last_write; + int type; + + mtx_lock_spin(&sched_lock); + sched_prio(curthread, PRIBIO); + mtx_unlock_spin(&sched_lock); + + sc = arg; + + if (sc->sc_flags & GJF_DEVICE_CLEAN) { + GJ_DEBUG(0, "Journal %s clean.", sc->sc_name); + g_journal_initialize(sc); + } else { + g_journal_sync(sc); + } + /* + * Check if we can use BIO_FLUSH. + */ + sc->sc_bio_flush = 0; + if (g_io_flush(sc->sc_jconsumer) == 0) { + sc->sc_bio_flush |= GJ_FLUSH_JOURNAL; + GJ_DEBUG(1, "BIO_FLUSH supported by %s.", + sc->sc_jconsumer->provider->name); + } else { + GJ_DEBUG(0, "BIO_FLUSH not supported by %s.", + sc->sc_jconsumer->provider->name); + } + if (sc->sc_jconsumer != sc->sc_dconsumer) { + if (g_io_flush(sc->sc_dconsumer) == 0) { + sc->sc_bio_flush |= GJ_FLUSH_DATA; + GJ_DEBUG(1, "BIO_FLUSH supported by %s.", + sc->sc_dconsumer->provider->name); + } else { + GJ_DEBUG(0, "BIO_FLUSH not supported by %s.", + sc->sc_dconsumer->provider->name); + } + } + + gp = sc->sc_geom; + g_topology_lock(); + pp = g_new_providerf(gp, "%s.journal", sc->sc_name); + KASSERT(pp != NULL, ("Cannot create %s.journal.", sc->sc_name)); + pp->mediasize = sc->sc_mediasize; + /* + * There could be a problem when data provider and journal providers + * have different sectorsize, but such scenario is prevented on journal + * creation. + */ + pp->sectorsize = sc->sc_sectorsize; + g_error_provider(pp, 0); + g_topology_unlock(); + last_write = time_second; + + for (;;) { + /* Get first request from the queue. */ + mtx_lock(&sc->sc_mtx); + bp = bioq_first(&sc->sc_back_queue); + if (bp != NULL) + type = (bp->bio_cflags & GJ_BIO_MASK); + if (bp == NULL) { + bp = bioq_first(&sc->sc_regular_queue); + if (bp != NULL) + type = GJ_BIO_REGULAR; + } + if (bp == NULL) { +try_switch: + if ((sc->sc_flags & GJF_DEVICE_SWITCH) || + (sc->sc_flags & GJF_DEVICE_DESTROY)) { + if (sc->sc_current_count > 0) { + mtx_unlock(&sc->sc_mtx); + g_journal_flush(sc); + g_journal_flush_send(sc); + continue; + } + if (sc->sc_flush_in_progress > 0) + goto sleep; + if (sc->sc_copy_in_progress > 0) + goto sleep; + } + if (sc->sc_flags & GJF_DEVICE_SWITCH) { + mtx_unlock(&sc->sc_mtx); + g_journal_switch(sc); + wakeup(&sc->sc_journal_copying); + continue; + } + if (sc->sc_flags & GJF_DEVICE_DESTROY) { + GJ_DEBUG(1, "Shutting down worker " + "thread for %s.", gp->name); + sc->sc_worker = NULL; + wakeup(&sc->sc_worker); + mtx_unlock(&sc->sc_mtx); + kthread_exit(0); + } +sleep: + g_journal_wait(sc, last_write); + continue; + } + /* + * If we're in switch process, we need to delay all new + * write requests until its done. + */ + if ((sc->sc_flags & GJF_DEVICE_SWITCH) && + type == GJ_BIO_REGULAR && bp->bio_cmd == BIO_WRITE) { + GJ_LOGREQ(2, bp, "WRITE on SWITCH"); + goto try_switch; + } + if (type == GJ_BIO_REGULAR) + bioq_remove(&sc->sc_regular_queue, bp); + else + bioq_remove(&sc->sc_back_queue, bp); + mtx_unlock(&sc->sc_mtx); + switch (type) { + case GJ_BIO_REGULAR: + /* Regular request. */ + switch (bp->bio_cmd) { + case BIO_READ: + g_journal_read(sc, bp, bp->bio_offset, + bp->bio_offset + bp->bio_length); + break; + case BIO_WRITE: + last_write = time_second; + g_journal_add_request(sc, bp); + g_journal_flush_send(sc); + break; + default: + panic("Invalid bio_cmd (%d).", bp->bio_cmd); + } + break; + case GJ_BIO_COPY: + switch (bp->bio_cmd) { + case BIO_READ: + if (g_journal_copy_read_done(bp)) + g_journal_copy_send(sc); + break; + case BIO_WRITE: + g_journal_copy_write_done(bp); + g_journal_copy_send(sc); + break; + default: + panic("Invalid bio_cmd (%d).", bp->bio_cmd); + } + break; + case GJ_BIO_JOURNAL: + g_journal_flush_done(bp); + g_journal_flush_send(sc); + break; + case GJ_BIO_READ: + default: + panic("Invalid bio (%d).", type); + } + } +} + +static void +g_journal_destroy_event(void *arg, int flags __unused) +{ + struct g_journal_softc *sc; + + g_topology_assert(); + sc = arg; + g_journal_destroy(sc); +} + +static void +g_journal_timeout(void *arg) +{ + struct g_journal_softc *sc; + + sc = arg; + GJ_DEBUG(0, "Timeout. Journal %s cannot be completed.", + sc->sc_geom->name); + g_post_event(g_journal_destroy_event, sc, M_NOWAIT, NULL); +} + +static struct g_geom * +g_journal_create(struct g_class *mp, struct g_provider *pp, + const struct g_journal_metadata *md) +{ + struct g_journal_softc *sc; + struct g_geom *gp; + struct g_consumer *cp; + int error; + + g_topology_assert(); + /* + * There are two possibilities: + * 1. Data and both journals are on the same provider. + * 2. Data and journals are all on separated providers. + */ + /* Look for journal device with the same ID. */ + LIST_FOREACH(gp, &mp->geom, geom) { + sc = gp->softc; + if (sc == NULL) + continue; + if (sc->sc_id == md->md_id) + break; + } + if (gp == NULL) + sc = NULL; + else if (sc != NULL && (sc->sc_type & md->md_type) != 0) { + GJ_DEBUG(1, "Journal device %u already configured.", sc->sc_id); + return (NULL); + } + if (md->md_type == 0 || (md->md_type & ~GJ_TYPE_COMPLETE) != 0) { + GJ_DEBUG(0, "Invalid type on %s.", pp->name); + return (NULL); + } + if (md->md_type & GJ_TYPE_DATA) { + GJ_DEBUG(0, "Journal %u: %s contains data.", md->md_id, + pp->name); + } + if (md->md_type & GJ_TYPE_JOURNAL) { + GJ_DEBUG(0, "Journal %u: %s contains journal.", md->md_id, + pp->name); + } + + if (sc == NULL) { + /* Action geom. */ + sc = malloc(sizeof(*sc), M_JOURNAL, M_WAITOK | M_ZERO); + sc->sc_id = md->md_id; + sc->sc_type = 0; + sc->sc_flags = 0; + sc->sc_worker = NULL; + + gp = g_new_geomf(mp, "gjournal %u", sc->sc_id); + gp->start = g_journal_start; + gp->orphan = g_journal_orphan; + gp->access = g_journal_access; + gp->softc = sc; + sc->sc_geom = gp; + + mtx_init(&sc->sc_mtx, "gjournal", NULL, MTX_DEF); + + bioq_init(&sc->sc_back_queue); + bioq_init(&sc->sc_regular_queue); + bioq_init(&sc->sc_delayed_queue); + sc->sc_delayed_count = 0; + sc->sc_current_queue = NULL; + sc->sc_current_count = 0; + sc->sc_flush_queue = NULL; + sc->sc_flush_count = 0; + sc->sc_flush_in_progress = 0; + sc->sc_copy_queue = NULL; + sc->sc_copy_in_progress = 0; + sc->sc_inactive.jj_queue = NULL; + sc->sc_active.jj_queue = NULL; + + callout_init(&sc->sc_callout, CALLOUT_MPSAFE); + if (md->md_type != GJ_TYPE_COMPLETE) { + /* + * Journal and data are on separate providers. + * At this point we have only one of them. + * We setup a timeout in case the other part will not + * appear, so we won't wait forever. + */ + callout_reset(&sc->sc_callout, 5 * hz, + g_journal_timeout, sc); + } + } + + /* Remember type of the data provider. */ + if (md->md_type & GJ_TYPE_DATA) + sc->sc_orig_type = md->md_type; + sc->sc_type |= md->md_type; + cp = NULL; + + if (md->md_type & GJ_TYPE_DATA) { + if (md->md_flags & GJ_FLAG_CLEAN) + sc->sc_flags |= GJF_DEVICE_CLEAN; + if (md->md_flags & GJ_FLAG_CHECKSUM) + sc->sc_flags |= GJF_DEVICE_CHECKSUM; + cp = g_new_consumer(gp); + error = g_attach(cp, pp); + KASSERT(error == 0, ("Cannot attach to %s (error=%d).", + pp->name, error)); + error = g_access(cp, 1, 1, 1); + if (error != 0) { + GJ_DEBUG(0, "Cannot access %s (error=%d).", pp->name, + error); + g_journal_destroy(sc); + return (NULL); + } + sc->sc_dconsumer = cp; + sc->sc_mediasize = pp->mediasize - pp->sectorsize; + sc->sc_sectorsize = pp->sectorsize; + sc->sc_jstart = md->md_jstart; + sc->sc_jend = md->md_jend; + if (md->md_provider[0] != '\0') + sc->sc_flags |= GJF_DEVICE_HARDCODED; + sc->sc_journal_offset = md->md_joffset; + sc->sc_journal_id = md->md_jid; + sc->sc_journal_previous_id = md->md_jid; + } + if (md->md_type & GJ_TYPE_JOURNAL) { + if (cp == NULL) { + cp = g_new_consumer(gp); + error = g_attach(cp, pp); + KASSERT(error == 0, ("Cannot attach to %s (error=%d).", + pp->name, error)); + error = g_access(cp, 1, 1, 1); + if (error != 0) { + GJ_DEBUG(0, "Cannot access %s (error=%d).", + pp->name, error); + g_journal_destroy(sc); + return (NULL); + } + } else { + /* + * Journal is on the same provider as data, which means + * that data provider ends where journal starts. + */ + sc->sc_mediasize = md->md_jstart; + } + sc->sc_jconsumer = cp; + } + + if ((sc->sc_type & GJ_TYPE_COMPLETE) != GJ_TYPE_COMPLETE) { + /* Journal is not complete yet. */ + return (gp); + } else { + /* Journal complete, cancel timeout. */ + callout_drain(&sc->sc_callout); + } + + error = kthread_create(g_journal_worker, sc, &sc->sc_worker, 0, 0, + "g_journal %s", sc->sc_name); + if (error != 0) { + GJ_DEBUG(0, "Cannot create worker thread for %s.journal.", + sc->sc_name); + g_journal_destroy(sc); + return (NULL); + } + + return (gp); +} + +static void +g_journal_destroy_consumer(void *arg, int flags __unused) +{ + struct g_consumer *cp; + + g_topology_assert(); + cp = arg; + g_detach(cp); + g_destroy_consumer(cp); +} + +static int +g_journal_destroy(struct g_journal_softc *sc) +{ + struct g_geom *gp; + struct g_provider *pp; + struct g_consumer *cp; + + g_topology_assert(); + + if (sc == NULL) + return (ENXIO); + + gp = sc->sc_geom; + pp = LIST_FIRST(&gp->provider); + if (pp != NULL) { + if (pp->acr != 0 || pp->acw != 0 || pp->ace != 0) { + GJ_DEBUG(1, "Device %s is still open (r%dw%de%d).", + pp->name, pp->acr, pp->acw, pp->ace); + return (EBUSY); + } + g_error_provider(pp, ENXIO); + + g_journal_flush(sc); + g_journal_flush_send(sc); + g_journal_switch(sc); + } + + sc->sc_flags |= (GJF_DEVICE_DESTROY | GJF_DEVICE_CLEAN); + + g_topology_unlock(); + callout_drain(&sc->sc_callout); + mtx_lock(&sc->sc_mtx); + wakeup(sc); + while (sc->sc_worker != NULL) + msleep(&sc->sc_worker, &sc->sc_mtx, PRIBIO, "gj:destroy", 0); + mtx_unlock(&sc->sc_mtx); + + if (pp != NULL) { + GJ_DEBUG(1, "Marking %s as clean.", sc->sc_name); + g_journal_metadata_update(sc); + g_topology_lock(); + pp->flags |= G_PF_WITHER; + g_orphan_provider(pp, ENXIO); + } else { + g_topology_lock(); + } + mtx_destroy(&sc->sc_mtx); + + if (sc->sc_current_count != 0) { + GJ_DEBUG(0, "Warning! Number of current requests %d.", + sc->sc_current_count); + } + + LIST_FOREACH(cp, &gp->consumer, consumer) { + if (cp->acr + cp->acw + cp->ace > 0) + g_access(cp, -1, -1, -1); + /* + * We keep all consumers open for writting, so if I'll detach + * and destroy consumer here, I'll get providers for taste, so + * journal will be started again. + * Sending an event here, prevents this from happening. + */ + g_post_event(g_journal_destroy_consumer, cp, M_WAITOK, NULL); + } + gp->softc = NULL; + g_wither_geom(gp, ENXIO); + free(sc, M_JOURNAL); + return (0); +} + +static void +g_journal_taste_orphan(struct g_consumer *cp) +{ + + KASSERT(1 == 0, ("%s called while tasting %s.", __func__, + cp->provider->name)); +} + +static struct g_geom * +g_journal_taste(struct g_class *mp, struct g_provider *pp, int flags __unused) +{ + struct g_journal_metadata md; + struct g_consumer *cp; + struct g_geom *gp; + int error; + + g_topology_assert(); + g_trace(G_T_TOPOLOGY, "%s(%s, %s)", __func__, mp->name, pp->name); + GJ_DEBUG(2, "Tasting %s.", pp->name); + if (pp->geom->class == mp) + return (NULL); + + gp = g_new_geomf(mp, "journal:taste"); + /* This orphan function should be never called. */ + gp->orphan = g_journal_taste_orphan; + cp = g_new_consumer(gp); + g_attach(cp, pp); + error = g_journal_metadata_read(cp, &md); + g_detach(cp); + g_destroy_consumer(cp); + g_destroy_geom(gp); + if (error != 0) + return (NULL); + gp = NULL; + + if (md.md_provider[0] != '\0' && strcmp(md.md_provider, pp->name) != 0) + return (NULL); + if (md.md_provsize != 0 && md.md_provsize != pp->mediasize) + return (NULL); + if (g_journal_debug >= 2) + journal_metadata_dump(&md); + + gp = g_journal_create(mp, pp, &md); + return (gp); +} + +static struct g_journal_softc * +g_journal_find_device(struct g_class *mp, const char *name) +{ + struct g_journal_softc *sc; + struct g_geom *gp; + struct g_provider *pp; + + if (strncmp(name, "/dev/", 5) == 0) + name += 5; + LIST_FOREACH(gp, &mp->geom, geom) { + sc = gp->softc; + if (sc == NULL) + continue; + if (sc->sc_flags & GJF_DEVICE_DESTROY) + continue; + if ((sc->sc_type & GJ_TYPE_COMPLETE) != GJ_TYPE_COMPLETE) + continue; + pp = LIST_FIRST(&gp->provider); + if (strcmp(sc->sc_name, name) == 0) + return (sc); + if (pp != NULL && strcmp(pp->name, name) == 0) + return (sc); + } + return (NULL); +} + +static void +g_journal_ctl_destroy(struct gctl_req *req, struct g_class *mp) +{ + struct g_journal_softc *sc; + const char *name; + char param[16]; + int *nargs; + int error, i; + + g_topology_assert(); + + nargs = gctl_get_paraml(req, "nargs", sizeof(*nargs)); + if (nargs == NULL) { + gctl_error(req, "No '%s' argument.", "nargs"); + return; + } + if (*nargs <= 0) { + gctl_error(req, "Missing device(s)."); + return; + } + + for (i = 0; i < *nargs; i++) { + snprintf(param, sizeof(param), "arg%d", i); + name = gctl_get_asciiparam(req, param); + if (name == NULL) { + gctl_error(req, "No 'arg%d' argument.", i); + return; + } + sc = g_journal_find_device(mp, name); + if (sc == NULL) { + gctl_error(req, "No such device: %s.", name); + return; + } + error = g_journal_destroy(sc); + if (error != 0) { + gctl_error(req, "Cannot destroy device %s (error=%d).", + LIST_FIRST(&sc->sc_geom->provider)->name, error); + return; + } + } +} + +static void +g_journal_ctl_sync(struct gctl_req *req __unused, struct g_class *mp __unused) +{ + + g_topology_assert(); + g_topology_unlock(); + g_journal_sync_requested++; + wakeup(&g_journal_switcher_state); + while (g_journal_sync_requested > 0) + tsleep(&g_journal_sync_requested, PRIBIO, "j:sreq", hz / 2); + g_topology_lock(); +} + +static void +g_journal_config(struct gctl_req *req, struct g_class *mp, const char *verb) +{ + uint32_t *version; + + g_topology_assert(); + + version = gctl_get_paraml(req, "version", sizeof(*version)); + if (version == NULL) { + gctl_error(req, "No '%s' argument.", "version"); + return; + } + if (*version != G_JOURNAL_VERSION) { + gctl_error(req, "Userland and kernel parts are out of sync."); + return; + } + + if (strcmp(verb, "destroy") == 0 || strcmp(verb, "stop") == 0) { + g_journal_ctl_destroy(req, mp); + return; + } else if (strcmp(verb, "sync") == 0) { + g_journal_ctl_sync(req, mp); + return; + } + + gctl_error(req, "Unknown verb."); +} + +static void +g_journal_dumpconf(struct sbuf *sb, const char *indent, struct g_geom *gp, + struct g_consumer *cp, struct g_provider *pp) +{ + struct g_journal_softc *sc; + + g_topology_assert(); + + sc = gp->softc; + if (sc == NULL) + return; + if (pp != NULL) { + /* Nothing here. */ + } else if (cp != NULL) { + int first = 1; + + sbuf_printf(sb, "%s", indent); + if (cp == sc->sc_dconsumer) { + sbuf_printf(sb, "Data"); + first = 0; + } + if (cp == sc->sc_jconsumer) { + if (!first) + sbuf_printf(sb, ","); + sbuf_printf(sb, "Journal"); + } + sbuf_printf(sb, "\n"); + if (cp == sc->sc_jconsumer) { + sbuf_printf(sb, "%jd", + (intmax_t)sc->sc_jstart); + sbuf_printf(sb, "%jd", + (intmax_t)sc->sc_jend); + } + } else { + sbuf_printf(sb, "%s%u\n", indent, (u_int)sc->sc_id); + } +} + +static eventhandler_tag g_journal_event_shutdown = NULL; +static eventhandler_tag g_journal_event_lowmem = NULL; + +static void +g_journal_shutdown(void *arg, int howto __unused) +{ + struct g_class *mp; + struct g_geom *gp, *gp2; + + if (panicstr != NULL) + return; + mp = arg; + DROP_GIANT(); + g_topology_lock(); + LIST_FOREACH_SAFE(gp, &mp->geom, geom, gp2) { + if (gp->softc == NULL) + continue; + GJ_DEBUG(0, "Shutting down geom %s.", gp->name); + g_journal_destroy(gp->softc); + } + g_topology_unlock(); + PICKUP_GIANT(); +} + +/* + * Free cached requests from inactive queue in case of low memory. + * We free GJ_FREE_AT_ONCE elements at once. + */ +#define GJ_FREE_AT_ONCE 4 +static void +g_journal_lowmem(void *arg, int howto __unused) +{ + struct g_journal_softc *sc; + struct g_class *mp; + struct g_geom *gp; + struct bio *bp; + u_int nfree = GJ_FREE_AT_ONCE; + + g_journal_stats_low_mem++; + mp = arg; + DROP_GIANT(); + g_topology_lock(); + LIST_FOREACH(gp, &mp->geom, geom) { + sc = gp->softc; + if (sc == NULL || (sc->sc_flags & GJF_DEVICE_DESTROY)) + continue; + mtx_lock(&sc->sc_mtx); + for (bp = sc->sc_inactive.jj_queue; nfree > 0 && bp != NULL; + nfree--, bp = bp->bio_next) { + /* + * This is safe to free the bio_data, because: + * 1. If bio_data is NULL it will be read from the + * inactive journal. + * 2. If bp is sent down, it is first removed from the + * inactive queue, so it's impossible to free the + * data from under in-flight bio. + * On the other hand, freeing elements from the active + * queue, is not safe. + */ + if (bp->bio_data != NULL) { + GJ_DEBUG(2, "Freeing data from %s.", + sc->sc_name); + gj_free(bp->bio_data, bp->bio_length); + bp->bio_data = NULL; + } + } + mtx_unlock(&sc->sc_mtx); + if (nfree == 0) + break; + } + g_topology_unlock(); + PICKUP_GIANT(); +} + +static void g_journal_switcher(void *arg); + +static void +g_journal_init(struct g_class *mp) +{ + int error; + + /* Pick a conservative value if provided value sucks. */ + if (g_journal_cache_divisor <= 0 || + (vm_kmem_size / g_journal_cache_divisor == 0)) { + g_journal_cache_divisor = 5; + } + if (g_journal_cache_limit > 0) { + g_journal_cache_limit = vm_kmem_size / g_journal_cache_divisor; + g_journal_cache_low = + (g_journal_cache_limit / 100) * g_journal_cache_switch; + } + g_journal_event_shutdown = EVENTHANDLER_REGISTER(shutdown_post_sync, + g_journal_shutdown, mp, EVENTHANDLER_PRI_FIRST); + if (g_journal_event_shutdown == NULL) + GJ_DEBUG(0, "Warning! Cannot register shutdown event."); + g_journal_event_lowmem = EVENTHANDLER_REGISTER(vm_lowmem, + g_journal_lowmem, mp, EVENTHANDLER_PRI_FIRST); + if (g_journal_event_lowmem == NULL) + GJ_DEBUG(0, "Warning! Cannot register lowmem event."); + error = kthread_create(g_journal_switcher, mp, NULL, 0, 0, + "g_journal switcher"); + KASSERT(error == 0, ("Cannot create switcher thread.")); +} + +static void +g_journal_fini(struct g_class *mp) +{ + + if (g_journal_event_shutdown != NULL) { + EVENTHANDLER_DEREGISTER(shutdown_post_sync, + g_journal_event_shutdown); + } + if (g_journal_event_lowmem != NULL) + EVENTHANDLER_DEREGISTER(vm_lowmem, g_journal_event_lowmem); + g_journal_switcher_state = GJ_SWITCHER_DIE; + wakeup(&g_journal_switcher_state); + while (g_journal_switcher_state != GJ_SWITCHER_DIED) + tsleep(&g_journal_switcher_state, PRIBIO, "jfini:wait", hz / 5); + GJ_DEBUG(1, "Switcher died."); +} + +DECLARE_GEOM_CLASS(g_journal_class, g_journal); + +static const struct g_journal_desc * +g_journal_find_desc(const char *fstype) +{ + const struct g_journal_desc *desc; + int i; + + for (desc = g_journal_filesystems[i = 0]; desc != NULL; + desc = g_journal_filesystems[++i]) { + if (strcmp(desc->jd_fstype, fstype) == 0) + break; + } + return (desc); +} + +static void +g_journal_switch_wait(struct g_journal_softc *sc) +{ + struct bintime bt; + + mtx_assert(&sc->sc_mtx, MA_OWNED); + if (g_journal_debug >= 2) { + if (sc->sc_flush_in_progress > 0) { + GJ_DEBUG(2, "%d requests flushing.", + sc->sc_flush_in_progress); + } + if (sc->sc_copy_in_progress > 0) { + GJ_DEBUG(2, "%d requests copying.", + sc->sc_copy_in_progress); + } + if (sc->sc_flush_count > 0) { + GJ_DEBUG(2, "%d requests to flush.", + sc->sc_flush_count); + } + if (sc->sc_delayed_count > 0) { + GJ_DEBUG(2, "%d requests delayed.", + sc->sc_delayed_count); + } + } + g_journal_stats_switches++; + if (sc->sc_copy_in_progress > 0) + g_journal_stats_wait_for_copy++; + GJ_TIMER_START(1, &bt); + sc->sc_flags &= ~GJF_DEVICE_BEFORE_SWITCH; + sc->sc_flags |= GJF_DEVICE_SWITCH; + wakeup(sc); + while (sc->sc_flags & GJF_DEVICE_SWITCH) { + msleep(&sc->sc_journal_copying, &sc->sc_mtx, PRIBIO, + "gj:switch", 0); + } + GJ_TIMER_STOP(1, &bt, "Switch time of %s", sc->sc_name); +} + +static void +g_journal_do_switch(struct g_class *classp, struct thread *td) +{ + struct g_journal_softc *sc; + const struct g_journal_desc *desc; + struct g_geom *gp; + struct mount *mp; + struct bintime bt; + char *mountpoint; + int asyncflag, error, vfslocked; + + DROP_GIANT(); + g_topology_lock(); + LIST_FOREACH(gp, &classp->geom, geom) { + sc = gp->softc; + if (sc == NULL) + continue; + if (sc->sc_flags & GJF_DEVICE_DESTROY) + continue; + if ((sc->sc_type & GJ_TYPE_COMPLETE) != GJ_TYPE_COMPLETE) + continue; + mtx_lock(&sc->sc_mtx); + sc->sc_flags |= GJF_DEVICE_BEFORE_SWITCH; + mtx_unlock(&sc->sc_mtx); + } + g_topology_unlock(); + PICKUP_GIANT(); + + mtx_lock(&mountlist_mtx); + TAILQ_FOREACH(mp, &mountlist, mnt_list) { + if (mp->mnt_gjprovider == NULL) + continue; + if (mp->mnt_flag & MNT_RDONLY) + continue; + desc = g_journal_find_desc(mp->mnt_stat.f_fstypename); + if (desc == NULL) + continue; + if (vfs_busy(mp, LK_NOWAIT, &mountlist_mtx, td)) + continue; + /* mtx_unlock(&mountlist_mtx) was done inside vfs_busy() */ + + DROP_GIANT(); + g_topology_lock(); + sc = g_journal_find_device(classp, mp->mnt_gjprovider); + g_topology_unlock(); + PICKUP_GIANT(); + + if (sc == NULL) { + GJ_DEBUG(0, "Cannot find journal geom for %s.", + mp->mnt_gjprovider); + goto next; + } else if (JEMPTY(sc)) { + mtx_lock(&sc->sc_mtx); + sc->sc_flags &= ~GJF_DEVICE_BEFORE_SWITCH; + mtx_unlock(&sc->sc_mtx); + GJ_DEBUG(3, "No need for %s switch.", sc->sc_name); + goto next; + } + + mountpoint = mp->mnt_stat.f_mntonname; + + vfslocked = VFS_LOCK_GIANT(mp); + + error = vn_start_write(NULL, &mp, V_WAIT); + if (error != 0) { + VFS_UNLOCK_GIANT(vfslocked); + GJ_DEBUG(0, "vn_start_write(%s) failed (error=%d).", + mountpoint, error); + goto next; + } + asyncflag = mp->mnt_flag & MNT_ASYNC; + mp->mnt_flag &= ~MNT_ASYNC; + + GJ_TIMER_START(1, &bt); + vfs_msync(mp, MNT_NOWAIT); + GJ_TIMER_STOP(1, &bt, "Msync time of %s", mountpoint); + + GJ_TIMER_START(1, &bt); + error = VFS_SYNC(mp, MNT_NOWAIT, curthread); + if (error == 0) + GJ_TIMER_STOP(1, &bt, "Sync time of %s", mountpoint); + else { + GJ_DEBUG(0, "Cannot sync file system %s (error=%d).", + mountpoint, error); + } + mp->mnt_flag |= asyncflag; + + vn_finished_write(mp); + + if (error != 0) { + VFS_UNLOCK_GIANT(vfslocked); + goto next; + } + + GJ_TIMER_START(1, &bt); + error = vfs_write_suspend(mp); + VFS_UNLOCK_GIANT(vfslocked); + GJ_TIMER_STOP(1, &bt, "Suspend time of %s", mountpoint); + if (error != 0) { + GJ_DEBUG(0, "Cannot suspend file system %s (error=%d).", + mountpoint, error); + goto next; + } + + error = desc->jd_clean(mp); + if (error != 0) + goto next; + + mtx_lock(&sc->sc_mtx); + g_journal_switch_wait(sc); + mtx_unlock(&sc->sc_mtx); + + vfs_write_resume(mp); +next: + mtx_lock(&mountlist_mtx); + vfs_unbusy(mp, td); + } + mtx_unlock(&mountlist_mtx); + + sc = NULL; + for (;;) { + DROP_GIANT(); + g_topology_lock(); + LIST_FOREACH(gp, &g_journal_class.geom, geom) { + sc = gp->softc; + if (sc == NULL) + continue; + mtx_lock(&sc->sc_mtx); + if ((sc->sc_type & GJ_TYPE_COMPLETE) == GJ_TYPE_COMPLETE && + !(sc->sc_flags & GJF_DEVICE_DESTROY) && + (sc->sc_flags & GJF_DEVICE_BEFORE_SWITCH)) { + break; + } + mtx_unlock(&sc->sc_mtx); + sc = NULL; + } + g_topology_unlock(); + PICKUP_GIANT(); + if (sc == NULL) + break; + mtx_assert(&sc->sc_mtx, MA_OWNED); + g_journal_switch_wait(sc); + mtx_unlock(&sc->sc_mtx); + } +} + +/* + * TODO: Switcher thread should be started on first geom creation and killed on + * last geom destruction. + */ +static void +g_journal_switcher(void *arg) +{ + struct thread *td = curthread; + struct g_class *mp; + struct bintime bt; + int error; + + mp = arg; + for (;;) { + g_journal_switcher_wokenup = 0; + error = tsleep(&g_journal_switcher_state, PRIBIO, "jsw:wait", + g_journal_switch_time * hz); + if (g_journal_switcher_state == GJ_SWITCHER_DIE) { + g_journal_switcher_state = GJ_SWITCHER_DIED; + GJ_DEBUG(1, "Switcher exiting."); + wakeup(&g_journal_switcher_state); + kthread_exit(0); + } + if (error == 0 && g_journal_sync_requested == 0) { + GJ_DEBUG(1, "Out of cache, force switch (used=%u " + "limit=%u).", g_journal_cache_used, + g_journal_cache_limit); + } + GJ_TIMER_START(1, &bt); + g_journal_do_switch(mp, td); + GJ_TIMER_STOP(1, &bt, "Entire switch time"); + if (g_journal_sync_requested > 0) { + g_journal_sync_requested = 0; + wakeup(&g_journal_sync_requested); + } + } +} --- /dev/null Tue Oct 24 16:34:10 2006 +++ sys/geom/journal/g_journal.h Tue Oct 24 16:34:16 2006 @@ -0,0 +1,379 @@ +/*- + * Copyright (c) 2005-2006 Pawel Jakub Dawidek + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _G_JOURNAL_H_ +#define _G_JOURNAL_H_ + +#include +#include +#ifdef _KERNEL +#include +#endif + +#define G_JOURNAL_CLASS_NAME "JOURNAL" + +#define G_JOURNAL_MAGIC "GEOM::JOURNAL" +/* + * Version history: + * 0 - Initial version number. + */ +#define G_JOURNAL_VERSION 0 + +#ifdef _KERNEL +extern int g_journal_debug; + +#define GJ_DEBUG(lvl, ...) do { \ + if (g_journal_debug >= (lvl)) { \ + printf("GEOM_JOURNAL"); \ + if (g_journal_debug > 0) \ + printf("[%u]", lvl); \ + printf(": "); \ + printf(__VA_ARGS__); \ + printf("\n"); \ + } \ +} while (0) +#define GJ_LOGREQ(lvl, bp, ...) do { \ + if (g_journal_debug >= (lvl)) { \ + printf("GEOM_JOURNAL"); \ + if (g_journal_debug > 0) \ + printf("[%u]", lvl); \ + printf(": "); \ + printf(__VA_ARGS__); \ + printf(" "); \ + g_print_bio(bp); \ + printf("\n"); \ + } \ +} while (0) + +#define JEMPTY(sc) ((sc)->sc_journal_offset - \ + (sc)->sc_jprovider->sectorsize == \ + (sc)->sc_active.jj_offset && \ + (sc)->sc_current_count == 0) + +#define GJ_BIO_REGULAR 0x00 +#define GJ_BIO_READ 0x01 +#define GJ_BIO_JOURNAL 0x02 +#define GJ_BIO_COPY 0x03 +#define GJ_BIO_MASK 0x0f + +#if 0 +#define GJF_BIO_DONT_FREE 0x10 +#define GJF_BIO_MASK 0xf0 +#endif + +#define GJF_DEVICE_HARDCODED 0x0001 +#define GJF_DEVICE_DESTROY 0x0010 +#define GJF_DEVICE_SWITCH 0x0020 +#define GJF_DEVICE_BEFORE_SWITCH 0x0040 +#define GJF_DEVICE_CLEAN 0x0080 +#define GJF_DEVICE_CHECKSUM 0x0100 + +#define GJ_HARD_LIMIT 64 + +/* + * We keep pointers to journaled data in bio structure and because we + * need to store two off_t values (offset in data provider and offset in + * journal), we have to borrow bio_completed field for this. + */ +#define bio_joffset bio_completed +/* + * Use bio_caller1 field as a pointer in queue. + */ +#define bio_next bio_caller1 + +/* + * There are two such structures maintained inside each journaled device. + * One describes active part of the journal, were recent requests are stored. + * The second describes the last consistent part of the journal with requests + * that are copied to the destination provider. + */ +struct g_journal_journal { + struct bio *jj_queue; /* Cached journal entries. */ + off_t jj_offset; /* Journal's start offset. */ +}; + +struct g_journal_softc { + uint32_t sc_id; + uint8_t sc_type; + uint8_t sc_orig_type; + struct g_geom *sc_geom; + u_int sc_flags; + struct mtx sc_mtx; + off_t sc_mediasize; + u_int sc_sectorsize; +#define GJ_FLUSH_DATA 0x01 +#define GJ_FLUSH_JOURNAL 0x02 + u_int sc_bio_flush; + + uint32_t sc_journal_id; + uint32_t sc_journal_next_id; + int sc_journal_copying; + off_t sc_journal_offset; + off_t sc_journal_previous_id; + + struct bio_queue_head sc_back_queue; + struct bio_queue_head sc_regular_queue; + + struct bio_queue_head sc_delayed_queue; + int sc_delayed_count; + + struct bio *sc_current_queue; + int sc_current_count; + + struct bio *sc_flush_queue; + int sc_flush_count; + int sc_flush_in_progress; + + struct bio *sc_copy_queue; + int sc_copy_in_progress; + + struct g_consumer *sc_dconsumer; + struct g_consumer *sc_jconsumer; + + struct g_journal_journal sc_inactive; + struct g_journal_journal sc_active; + + off_t sc_jstart; /* Journal space start offset. */ + off_t sc_jend; /* Journal space end offset. */ + + struct callout sc_callout; + struct proc *sc_worker; +}; +#define sc_dprovider sc_dconsumer->provider +#define sc_jprovider sc_jconsumer->provider +#define sc_name sc_dprovider->name + +#define GJQ_INSERT_HEAD(head, bp) do { \ + (bp)->bio_next = (head); \ + (head) = (bp); \ +} while (0) +#define GJQ_INSERT_AFTER(head, bp, pbp) do { \ + if ((pbp) == NULL) \ + GJQ_INSERT_HEAD(head, bp); \ + else { \ + (bp)->bio_next = (pbp)->bio_next; \ + (pbp)->bio_next = (bp); \ + } \ +} while (0) +#define GJQ_FIRST(head) (head) +#define GJQ_REMOVE(head, bp) do { \ + struct bio *_bp; \ + \ + if ((head) == (bp)) { \ + (head) = (bp)->bio_next; \ + (bp)->bio_next = NULL; \ + break; \ + } \ + for (_bp = (head); _bp->bio_next != NULL; _bp = _bp->bio_next) {\ + if (_bp->bio_next == (bp)) \ + break; \ + } \ + KASSERT(_bp->bio_next != NULL, ("NULL bio_next")); \ + KASSERT(_bp->bio_next == (bp), ("bio_next != bp")); \ + _bp->bio_next = (bp)->bio_next; \ + (bp)->bio_next = NULL; \ +} while (0) +#define GJQ_FOREACH(head, bp) \ + for ((bp) = (head); (bp) != NULL; (bp) = (bp)->bio_next) + +#define GJ_HEADER_MAGIC "GJHDR" + +struct g_journal_header { + char jh_magic[sizeof(GJ_HEADER_MAGIC)]; + uint32_t jh_journal_id; + uint32_t jh_journal_next_id; +} __packed; + +struct g_journal_entry { + uint64_t je_joffset; + uint64_t je_offset; + uint64_t je_length; +} __packed; + +#define GJ_RECORD_HEADER_MAGIC "GJRHDR" +#define GJ_RECORD_HEADER_NENTRIES (20) +#define GJ_RECORD_MAX_SIZE(sc) \ + ((sc)->sc_jprovider->sectorsize + GJ_RECORD_HEADER_NENTRIES * MAXPHYS) +#define GJ_VALIDATE_OFFSET(offset, sc) do { \ + if ((offset) + GJ_RECORD_MAX_SIZE(sc) >= (sc)->sc_jend) { \ + (offset) = (sc)->sc_jstart; \ + GJ_DEBUG(2, "Starting from the begining (%s).", \ + (sc)->sc_name); \ + } \ +} while (0) + +struct g_journal_record_header { + char jrh_magic[sizeof(GJ_RECORD_HEADER_MAGIC)]; + uint32_t jrh_journal_id; + uint16_t jrh_nentries; + u_char jrh_sum[8]; + struct g_journal_entry jrh_entries[GJ_RECORD_HEADER_NENTRIES]; +} __packed; + +typedef int (g_journal_clean_t)(struct mount *mp); +typedef void (g_journal_dirty_t)(struct g_consumer *cp); + +struct g_journal_desc { + const char *jd_fstype; + g_journal_clean_t *jd_clean; + g_journal_dirty_t *jd_dirty; +}; + +/* Supported file systems. */ +extern const struct g_journal_desc g_journal_ufs; + +#define GJ_TIMER_START(lvl, bt) do { \ + if (g_journal_debug >= (lvl)) \ + binuptime(bt); \ +} while (0) +#define GJ_TIMER_STOP(lvl, bt, ...) do { \ + if (g_journal_debug >= (lvl)) { \ + struct bintime _bt2; \ + struct timeval _tv; \ + \ + binuptime(&_bt2); \ + bintime_sub(&_bt2, bt); \ + bintime2timeval(&_bt2, &_tv); \ + printf("GEOM_JOURNAL"); \ + if (g_journal_debug > 0) \ + printf("[%u]", lvl); \ + printf(": "); \ + printf(__VA_ARGS__); \ + printf(": %jd.%06jds\n", (intmax_t)_tv.tv_sec, \ + (intmax_t)_tv.tv_usec); \ + } \ +} while (0) +#endif /* _KERNEL */ + +#define GJ_TYPE_DATA 0x01 +#define GJ_TYPE_JOURNAL 0x02 +#define GJ_TYPE_COMPLETE (GJ_TYPE_DATA|GJ_TYPE_JOURNAL) + +#define GJ_FLAG_CLEAN 0x01 +#define GJ_FLAG_CHECKSUM 0x02 + +struct g_journal_metadata { + char md_magic[16]; /* Magic value. */ + uint32_t md_version; /* Version number. */ + uint32_t md_id; /* Journal unique ID. */ + uint8_t md_type; /* Provider type. */ + uint64_t md_jstart; /* Journal space start offset. */ + uint64_t md_jend; /* Journal space end offset. */ + uint64_t md_joffset; /* Last known consistent journal offset. */ + uint32_t md_jid; /* Last known consistent journal ID. */ + uint64_t md_flags; /* Journal flags. */ + char md_provider[16]; /* Hardcoded provider. */ + uint64_t md_provsize; /* Provider's size. */ + u_char md_hash[16]; /* MD5 hash. */ +}; +static __inline void +journal_metadata_encode(struct g_journal_metadata *md, u_char *data) +{ + MD5_CTX ctx; + + bcopy(md->md_magic, data, 16); + le32enc(data + 16, md->md_version); + le32enc(data + 20, md->md_id); + *(data + 24) = md->md_type; + le64enc(data + 25, md->md_jstart); + le64enc(data + 33, md->md_jend); + le64enc(data + 41, md->md_joffset); + le32enc(data + 49, md->md_jid); + le64enc(data + 53, md->md_flags); + bcopy(md->md_provider, data + 61, 16); + le64enc(data + 77, md->md_provsize); + MD5Init(&ctx); + MD5Update(&ctx, data, 85); + MD5Final(md->md_hash, &ctx); + bcopy(md->md_hash, data + 85, 16); +} +static __inline int +journal_metadata_decode_v0(const u_char *data, struct g_journal_metadata *md) +{ + MD5_CTX ctx; + + md->md_id = le32dec(data + 20); + md->md_type = *(data + 24); + md->md_jstart = le64dec(data + 25); + md->md_jend = le64dec(data + 33); + md->md_joffset = le64dec(data + 41); + md->md_jid = le32dec(data + 49); + md->md_flags = le64dec(data + 53); + bcopy(data + 61, md->md_provider, 16); + md->md_provsize = le64dec(data + 77); + MD5Init(&ctx); + MD5Update(&ctx, data, 85); + MD5Final(md->md_hash, &ctx); + if (bcmp(md->md_hash, data + 85, 16) != 0) + return (EINVAL); + return (0); +} +static __inline int +journal_metadata_decode(const u_char *data, struct g_journal_metadata *md) +{ + int error; + + bcopy(data, md->md_magic, 16); + md->md_version = le32dec(data + 16); + switch (md->md_version) { + case 0: + error = journal_metadata_decode_v0(data, md); + break; + default: + error = EINVAL; + break; + } + return (error); +} + +static __inline void +journal_metadata_dump(const struct g_journal_metadata *md) +{ + static const char hex[] = "0123456789abcdef"; + char hash[16 * 2 + 1]; + u_int i; + + printf(" magic: %s\n", md->md_magic); + printf(" version: %u\n", (u_int)md->md_version); + printf(" id: %u\n", (u_int)md->md_id); + printf(" type: %u\n", (u_int)md->md_type); + printf(" start: %ju\n", (uintmax_t)md->md_jstart); + printf(" end: %ju\n", (uintmax_t)md->md_jend); + printf(" joffset: %ju\n", (uintmax_t)md->md_joffset); + printf(" jid: %u\n", (u_int)md->md_jid); + printf(" flags: %u\n", (u_int)md->md_flags); + printf("hcprovider: %s\n", md->md_provider); + printf(" provsize: %ju\n", (uintmax_t)md->md_provsize); + bzero(hash, sizeof(hash)); + for (i = 0; i < 16; i++) { + hash[i * 2] = hex[md->md_hash[i] >> 4]; + hash[i * 2 + 1] = hex[md->md_hash[i] & 0x0f]; + } + printf(" MD5 hash: %s\n", hash); +} +#endif /* !_G_JOURNAL_H_ */ --- /dev/null Tue Oct 24 16:34:10 2006 +++ sys/geom/journal/g_journal_ufs.c Tue Oct 24 16:34:19 2006 @@ -0,0 +1,107 @@ +/*- + * Copyright (c) 2005-2006 Pawel Jakub Dawidek + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include +#include + +#include +#include + +static const int superblocks[] = SBLOCKSEARCH; + +static int +g_journal_ufs_clean(struct mount *mp) +{ + struct ufsmount *ump; + struct fs *fs; + int flags; + + ump = VFSTOUFS(mp); + fs = ump->um_fs; + + flags = fs->fs_flags; + fs->fs_flags &= ~(FS_UNCLEAN | FS_NEEDSFSCK); + ffs_sbupdate(ump, MNT_WAIT, 1); + fs->fs_flags = flags; + + return (0); +} + +static void +g_journal_ufs_dirty(struct g_consumer *cp) +{ + struct fs *fs; + int error, i, sb; + + if (SBLOCKSIZE % cp->provider->sectorsize != 0) + return; + for (i = 0; (sb = superblocks[i]) != -1; i++) { + if (sb % cp->provider->sectorsize != 0) + continue; + fs = g_read_data(cp, sb, SBLOCKSIZE, NULL); + if (fs == NULL) + continue; + if (fs->fs_magic != FS_UFS1_MAGIC && + fs->fs_magic != FS_UFS2_MAGIC) { + g_free(fs); + continue; + } + GJ_DEBUG(0, "clean=%d flags=0x%x", fs->fs_clean, fs->fs_flags); + fs->fs_clean = 0; + fs->fs_flags |= FS_NEEDSFSCK | FS_UNCLEAN; + error = g_write_data(cp, sb, fs, SBLOCKSIZE); + g_free(fs); + if (error != 0) { + GJ_DEBUG(0, "Cannot mark file system %s as dirty " + "(error=%d).", cp->provider->name, error); + } else { + GJ_DEBUG(0, "File system %s marked as dirty.", + cp->provider->name); + } + } +} + +const struct g_journal_desc g_journal_ufs = { + .jd_fstype = "ufs", + .jd_clean = g_journal_ufs_clean, + .jd_dirty = g_journal_ufs_dirty +}; + +MODULE_DEPEND(g_journal, ufs, 1, 1, 1); --- sys/geom/mirror/g_mirror.c.orig +++ sys/geom/mirror/g_mirror.c @@ -1042,6 +1042,48 @@ } static void +g_mirror_flush(struct g_mirror_softc *sc, struct bio *bp) +{ + struct bio_queue_head queue; + struct g_mirror_disk *disk; + struct g_consumer *cp; + struct bio *cbp; + + bioq_init(&queue); + LIST_FOREACH(disk, &sc->sc_disks, d_next) { + if (disk->d_state != G_MIRROR_DISK_STATE_ACTIVE) + continue; + cbp = g_clone_bio(bp); + if (cbp == NULL) { + for (cbp = bioq_first(&queue); cbp != NULL; + cbp = bioq_first(&queue)) { + bioq_remove(&queue, cbp); + g_destroy_bio(cbp); + } + if (bp->bio_error == 0) + bp->bio_error = ENOMEM; + g_io_deliver(bp, bp->bio_error); + return; + } + bioq_insert_tail(&queue, cbp); + cbp->bio_done = g_std_done; + cbp->bio_caller1 = disk; + cbp->bio_to = disk->d_consumer->provider; + } + for (cbp = bioq_first(&queue); cbp != NULL; cbp = bioq_first(&queue)) { + bioq_remove(&queue, cbp); + G_MIRROR_LOGREQ(3, cbp, "Sending request."); + disk = cbp->bio_caller1; + cbp->bio_caller1 = NULL; + cp = disk->d_consumer; + KASSERT(cp->acr >= 1 && cp->acw >= 1 && cp->ace >= 1, + ("Consumer %s not opened (r%dw%de%d).", cp->provider->name, + cp->acr, cp->acw, cp->ace)); + g_io_request(cbp, disk->d_consumer); + } +} + +static void g_mirror_start(struct bio *bp) { struct g_mirror_softc *sc; @@ -1061,6 +1103,9 @@ case BIO_WRITE: case BIO_DELETE: break; + case BIO_FLUSH: + g_mirror_flush(sc, bp); + return; case BIO_GETATTR: if (strcmp("GEOM::kerneldump", bp->bio_attribute) == 0) { g_mirror_kernel_dump(bp); --- sys/geom/raid3/g_raid3.c.orig +++ sys/geom/raid3/g_raid3.c @@ -25,7 +25,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/geom/raid3/g_raid3.c,v 1.40.2.16 2006/10/21 07:16:41 pjd Exp $"); +__FBSDID("$FreeBSD: src/sys/geom/raid3/g_raid3.c,v 1.40.2.15 2006/09/19 11:16:14 pjd Exp $"); #include #include @@ -1370,6 +1370,50 @@ } static void +g_raid3_flush(struct g_raid3_softc *sc, struct bio *bp) +{ + struct bio_queue_head queue; + struct g_raid3_disk *disk; + struct g_consumer *cp; + struct bio *cbp; + u_int i; + + bioq_init(&queue); + for (i = 0; i < sc->sc_ndisks; i++) { + disk = &sc->sc_disks[i]; + if (disk->d_state != G_RAID3_DISK_STATE_ACTIVE) + continue; + cbp = g_clone_bio(bp); + if (cbp == NULL) { + for (cbp = bioq_first(&queue); cbp != NULL; + cbp = bioq_first(&queue)) { + bioq_remove(&queue, cbp); + g_destroy_bio(cbp); + } + if (bp->bio_error == 0) + bp->bio_error = ENOMEM; + g_io_deliver(bp, bp->bio_error); + return; + } + bioq_insert_tail(&queue, cbp); + cbp->bio_done = g_std_done; + cbp->bio_caller1 = disk; + cbp->bio_to = disk->d_consumer->provider; + } + for (cbp = bioq_first(&queue); cbp != NULL; cbp = bioq_first(&queue)) { + bioq_remove(&queue, cbp); + G_RAID3_LOGREQ(3, cbp, "Sending request."); + disk = cbp->bio_caller1; + cbp->bio_caller1 = NULL; + cp = disk->d_consumer; + KASSERT(cp->acr >= 1 && cp->acw >= 1 && cp->ace >= 1, + ("Consumer %s not opened (r%dw%de%d).", cp->provider->name, + cp->acr, cp->acw, cp->ace)); + g_io_request(cbp, disk->d_consumer); + } +} + +static void g_raid3_start(struct bio *bp) { struct g_raid3_softc *sc; @@ -1390,6 +1434,9 @@ case BIO_WRITE: case BIO_DELETE: break; + case BIO_FLUSH: + g_raid3_flush(sc, bp); + return; case BIO_GETATTR: default: g_io_deliver(bp, EOPNOTSUPP); --- sys/geom/stripe/g_stripe.c.orig +++ sys/geom/stripe/g_stripe.c @@ -520,6 +520,42 @@ } static void +g_stripe_flush(struct g_stripe_softc *sc, struct bio *bp) +{ + struct bio_queue_head queue; + struct g_consumer *cp; + struct bio *cbp; + u_int no; + + bioq_init(&queue); + for (no = 0; no < sc->sc_ndisks; no++) { + cbp = g_clone_bio(bp); + if (cbp == NULL) { + for (cbp = bioq_first(&queue); cbp != NULL; + cbp = bioq_first(&queue)) { + bioq_remove(&queue, cbp); + g_destroy_bio(cbp); + } + if (bp->bio_error == 0) + bp->bio_error = ENOMEM; + g_io_deliver(bp, bp->bio_error); + return; + } + bioq_insert_tail(&queue, cbp); + cbp->bio_done = g_std_done; + cbp->bio_caller1 = sc->sc_disks[no]; + cbp->bio_to = sc->sc_disks[no]->provider; + } + for (cbp = bioq_first(&queue); cbp != NULL; cbp = bioq_first(&queue)) { + bioq_remove(&queue, cbp); + G_STRIPE_LOGREQ(cbp, "Sending request."); + cp = cbp->bio_caller1; + cbp->bio_caller1 = NULL; + g_io_request(cbp, cp); + } +} + +static void g_stripe_start(struct bio *bp) { off_t offset, start, length, nstripe; @@ -542,10 +578,10 @@ case BIO_READ: case BIO_WRITE: case BIO_DELETE: - /* - * Only those requests are supported. - */ break; + case BIO_FLUSH: + g_stripe_flush(sc, bp); + return; case BIO_GETATTR: /* To which provider it should be delivered? */ default: --- sys/kern/subr_disk.c.orig +++ sys/kern/subr_disk.c @@ -43,6 +43,7 @@ case BIO_WRITE: printf("cmd=write "); break; case BIO_DELETE: printf("cmd=delete "); break; case BIO_GETATTR: printf("cmd=getattr "); break; + case BIO_FLUSH: printf("cmd=flush "); break; default: printf("cmd=%x ", bp->bio_cmd); break; } sn = bp->bio_pblkno; --- sys/kern/vfs_subr.c.orig +++ sys/kern/vfs_subr.c @@ -2545,6 +2545,8 @@ strcat(buf, "|VV_TEXT"); if (vp->v_vflag & VV_SYSTEM) strcat(buf, "|VV_SYSTEM"); + if (vp->v_vflag & VV_DELETED) + strcat(buf, "|VV_DELETED"); if (vp->v_iflag & VI_DOOMED) strcat(buf, "|VI_DOOMED"); if (vp->v_iflag & VI_FREE) --- sys/modules/geom/Makefile.orig +++ sys/modules/geom/Makefile @@ -9,6 +9,7 @@ geom_fox \ geom_gate \ geom_gpt \ + geom_journal \ geom_label \ geom_mbr \ geom_mirror \ --- /dev/null Tue Oct 24 16:34:10 2006 +++ sys/modules/geom/geom_journal/Makefile Tue Oct 24 16:34:22 2006 @@ -0,0 +1,10 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../../geom/journal + +KMOD= geom_journal +SRCS= g_journal.c +SRCS+= g_journal_ufs.c +SRCS+= vnode_if.h + +.include --- sys/modules/ufs/Makefile.orig +++ sys/modules/ufs/Makefile @@ -6,7 +6,7 @@ SRCS= opt_ddb.h opt_directio.h opt_ffs.h opt_ffs_broken_fixme.h opt_mac.h \ opt_quota.h opt_suiddir.h opt_ufs.h \ vnode_if.h ufs_acl.c ufs_bmap.c ufs_dirhash.c ufs_extattr.c \ - ufs_inode.c ufs_lookup.c ufs_quota.c ufs_vfsops.c \ + ufs_gjournal.c ufs_inode.c ufs_lookup.c ufs_quota.c ufs_vfsops.c \ ufs_vnops.c ffs_alloc.c ffs_balloc.c ffs_inode.c ffs_snapshot.c \ ffs_softdep.c ffs_subr.c ffs_tables.c ffs_vfsops.c ffs_vnops.c --- sys/sys/bio.h.orig +++ sys/sys/bio.h @@ -88,6 +88,7 @@ #define BIO_WRITE 0x02 #define BIO_DELETE 0x04 #define BIO_GETATTR 0x08 +#define BIO_FLUSH 0x10 #define BIO_CMD0 0x20 /* Available for local hacks */ #define BIO_CMD1 0x40 /* Available for local hacks */ #define BIO_CMD2 0x80 /* Available for local hacks */ --- sys/sys/mount.h.orig +++ sys/sys/mount.h @@ -178,6 +178,7 @@ int mnt_secondary_accwrites;/* (i) secondary wr. starts */ int mnt_ref; /* (i) Reference count */ int mnt_gen; /* struct mount generation */ + char *mnt_gjprovider; /* gjournal provider name */ }; struct vnode *__mnt_vnode_next(struct vnode **mvp, struct mount *mp); @@ -224,7 +225,7 @@ #define MNT_SUIDDIR 0x00100000 /* special handling of SUID on dirs */ #define MNT_SOFTDEP 0x00200000 /* soft updates being done */ #define MNT_NOSYMFOLLOW 0x00400000 /* do not follow symlinks */ -#define MNT_JAILDEVFS 0x02000000 /* jail-friendly DEVFS behaviour */ +#define MNT_GJOURNAL 0x02000000 /* GEOM journal support enabled */ #define MNT_MULTILABEL 0x04000000 /* MAC support for individual objects */ #define MNT_ACLS 0x08000000 /* ACL support enabled */ #define MNT_NOATIME 0x10000000 /* disable update of file access time */ @@ -265,13 +266,13 @@ MNT_ROOTFS | MNT_NOATIME | MNT_NOCLUSTERR| \ MNT_NOCLUSTERW | MNT_SUIDDIR | MNT_SOFTDEP | \ MNT_IGNORE | MNT_EXPUBLIC | MNT_NOSYMFOLLOW | \ - MNT_JAILDEVFS | MNT_MULTILABEL | MNT_ACLS) + MNT_GJOURNAL | MNT_MULTILABEL | MNT_ACLS) /* Mask of flags that can be updated. */ #define MNT_UPDATEMASK (MNT_NOSUID | MNT_NOEXEC | \ MNT_SYNCHRONOUS | MNT_UNION | MNT_ASYNC | \ MNT_NOATIME | \ - MNT_NOSYMFOLLOW | MNT_IGNORE | MNT_JAILDEVFS | \ + MNT_NOSYMFOLLOW | MNT_IGNORE | \ MNT_NOCLUSTERR | MNT_NOCLUSTERW | MNT_SUIDDIR | \ MNT_ACLS | MNT_USER) --- sys/sys/vnode.h.orig +++ sys/sys/vnode.h @@ -253,6 +253,7 @@ #define VV_SYSTEM 0x0080 /* vnode being used by kernel */ #define VV_PROCDEP 0x0100 /* vnode is process dependent */ #define VV_NOKNOTE 0x0200 /* don't activate knotes on this vnode */ +#define VV_DELETED 0x0400 /* should be removed */ /* * Vnode attributes. A field value of VNOVAL represents a field whose value --- sys/ufs/ffs/ffs_extern.h.orig +++ sys/ufs/ffs/ffs_extern.h @@ -72,6 +72,7 @@ int ffs_reallocblks(struct vop_reallocblks_args *); int ffs_realloccg(struct inode *, ufs2_daddr_t, ufs2_daddr_t, ufs2_daddr_t, int, int, struct ucred *, struct buf **); +int ffs_sbupdate(struct ufsmount *, int, int); void ffs_setblock(struct fs *, u_char *, ufs1_daddr_t); int ffs_snapblkfree(struct fs *, struct vnode *, ufs2_daddr_t, long, ino_t); void ffs_snapremove(struct vnode *vp); --- sys/ufs/ffs/ffs_vfsops.c.orig +++ sys/ufs/ffs/ffs_vfsops.c @@ -53,6 +53,7 @@ #include #include +#include #include #include #include @@ -70,7 +71,6 @@ static uma_zone_t uma_inode, uma_ufs1, uma_ufs2; -static int ffs_sbupdate(struct ufsmount *, int, int); static int ffs_reload(struct mount *, struct thread *); static int ffs_mountfs(struct vnode *, struct mount *, struct thread *); static void ffs_oldfscompat_read(struct fs *, struct ufsmount *, @@ -661,6 +661,35 @@ fs->fs_pendingblocks = 0; fs->fs_pendinginodes = 0; } + if ((fs->fs_flags & FS_GJOURNAL) != 0) { +#ifdef UFS_GJOURNAL + /* + * Get journal provider name. + */ + size = 1024; + mp->mnt_gjprovider = malloc(size, M_UFSMNT, M_WAITOK); + if (g_io_getattr("GJOURNAL::provider", cp, &size, + mp->mnt_gjprovider) == 0) { + mp->mnt_gjprovider = realloc(mp->mnt_gjprovider, size, + M_UFSMNT, M_WAITOK); + MNT_ILOCK(mp); + mp->mnt_flag |= MNT_GJOURNAL; + MNT_IUNLOCK(mp); + } else { + printf( +"WARNING: %s: GJOURNAL flag on fs but no gjournal provider below\n", + mp->mnt_stat.f_mntonname); + free(mp->mnt_gjprovider, M_UFSMNT); + mp->mnt_gjprovider = NULL; + } +#else + printf( +"WARNING: %s: GJOURNAL flag on fs but no UFS_GJOURNAL support\n", + mp->mnt_stat.f_mntonname); +#endif + } else { + mp->mnt_gjprovider = NULL; + } ump = malloc(sizeof *ump, M_UFSMNT, M_WAITOK | M_ZERO); ump->um_cp = cp; ump->um_bo = &devvp->v_bufobj; @@ -828,6 +857,10 @@ } if (ump) { mtx_destroy(UFS_MTX(ump)); + if (mp->mnt_gjprovider != NULL) { + free(mp->mnt_gjprovider, M_UFSMNT); + mp->mnt_gjprovider = NULL; + } free(ump->um_fs, M_UFSMNT); free(ump, M_UFSMNT); mp->mnt_data = (qaddr_t)0; @@ -987,6 +1020,10 @@ PICKUP_GIANT(); vrele(ump->um_devvp); mtx_destroy(UFS_MTX(ump)); + if (mp->mnt_gjprovider != NULL) { + free(mp->mnt_gjprovider, M_UFSMNT); + mp->mnt_gjprovider = NULL; + } free(fs->fs_csp, M_UFSMNT); free(fs, M_UFSMNT); free(ump, M_UFSMNT); @@ -1471,7 +1508,7 @@ /* * Write a superblock and associated information back to disk. */ -static int +int ffs_sbupdate(mp, waitfor, suspended) struct ufsmount *mp; int waitfor; --- sys/ufs/ffs/fs.h.orig +++ sys/ufs/ffs/fs.h @@ -323,7 +323,8 @@ u_int *fs_active; /* (u) used by snapshots to track fs */ int32_t fs_old_cpc; /* cyl per cycle in postbl */ int32_t fs_maxbsize; /* maximum blocking factor permitted */ - int64_t fs_sparecon64[17]; /* old rotation block list head */ + int64_t fs_unrefs; /* number of unreferenced inodes */ + int64_t fs_sparecon64[16]; /* old rotation block list head */ int64_t fs_sblockloc; /* byte offset of standard superblock */ struct csum_total fs_cstotal; /* (u) cylinder summary information */ ufs_time_t fs_time; /* last time written */ @@ -406,6 +407,7 @@ #define FS_INDEXDIRS 0x08 /* kernel supports indexed directories */ #define FS_ACLS 0x10 /* file system has ACLs enabled */ #define FS_MULTILABEL 0x20 /* file system is MAC multi-label */ +#define FS_GJOURNAL 0x40 /* gjournaled file system */ #define FS_FLAGS_UPDATED 0x80 /* flags have been moved to new location */ /* @@ -475,7 +477,8 @@ int32_t cg_nclusterblks; /* number of clusters this cg */ int32_t cg_niblk; /* number of inode blocks this cg */ int32_t cg_initediblk; /* last initialized inode */ - int32_t cg_sparecon32[3]; /* reserved for future use */ + int32_t cg_unrefs; /* number of unreferenced inodes */ + int32_t cg_sparecon32[2]; /* reserved for future use */ ufs_time_t cg_time; /* time last written */ int64_t cg_sparecon64[3]; /* reserved for future use */ u_int8_t cg_space[1]; /* space for cylinder group maps */ --- /dev/null Tue Oct 24 16:34:10 2006 +++ sys/ufs/ufs/gjournal.h Tue Oct 24 16:34:25 2006 @@ -0,0 +1,37 @@ +/*- + * Copyright (c) 2005-2006 Pawel Jakub Dawidek + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef _UFS_UFS_GJOURNAL_H_ +#define _UFS_UFS_GJOURNAL_H_ + +/* + * GEOM journal function prototypes. + */ +void ufs_gjournal_orphan(struct vnode *fvp); +void ufs_gjournal_close(struct vnode *vp); +#endif /* !_UFS_UFS_GJOURNAL_H_ */ --- /dev/null Tue Oct 24 16:34:10 2006 +++ sys/ufs/ufs/ufs_gjournal.c Tue Oct 24 16:34:27 2006 @@ -0,0 +1,150 @@ +/*- + * Copyright (c) 2005-2006 Pawel Jakub Dawidek + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include "opt_ufs.h" + +#ifdef UFS_GJOURNAL + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include +#include + +/* + * Change the number of unreferenced inodes. + */ +static int +ufs_gjournal_modref(struct vnode *vp, int count) +{ + struct cg *cgp; + struct buf *bp; + ufs2_daddr_t cgbno; + int error, cg; + struct cdev *dev; + struct inode *ip; + struct ufsmount *ump; + struct fs *fs; + struct vnode *devvp; + ino_t ino; + + ip = VTOI(vp); + ump = ip->i_ump; + fs = ip->i_fs; + devvp = ip->i_devvp; + ino = ip->i_number; + + cg = ino_to_cg(fs, ino); + if (devvp->v_type != VCHR) { + /* devvp is a snapshot */ + dev = VTOI(devvp)->i_devvp->v_rdev; + cgbno = fragstoblks(fs, cgtod(fs, cg)); + } else { + /* devvp is a normal disk device */ + dev = devvp->v_rdev; + cgbno = fsbtodb(fs, cgtod(fs, cg)); + } + if ((u_int)ino >= fs->fs_ipg * fs->fs_ncg) + panic("ffs_freefile: range: dev = %s, ino = %lu, fs = %s", + devtoname(dev), (u_long)ino, fs->fs_fsmnt); + if ((error = bread(devvp, cgbno, (int)fs->fs_cgsize, NOCRED, &bp))) { + brelse(bp); + return (error); + } + cgp = (struct cg *)bp->b_data; + if (!cg_chkmagic(cgp)) { + brelse(bp); + return (0); + } + bp->b_xflags |= BX_BKGRDWRITE; + cgp->cg_unrefs += count; + UFS_LOCK(ump); + fs->fs_unrefs += count; + fs->fs_fmod = 1; + ACTIVECLEAR(fs, cg); + UFS_UNLOCK(ump); + bdwrite(bp); + return (0); +} + +void +ufs_gjournal_orphan(struct vnode *fvp) +{ + struct mount *mp; + struct inode *ip; + + mp = fvp->v_mount; + if (mp->mnt_gjprovider == NULL) + return; + VI_LOCK(fvp); + if (fvp->v_usecount < 2 || (fvp->v_vflag & VV_DELETED)) { + VI_UNLOCK(fvp); + return; + } + ip = VTOI(fvp); + if ((fvp->v_type == VDIR && ip->i_nlink > 2) || + (fvp->v_type != VDIR && ip->i_nlink > 1)) { + VI_UNLOCK(fvp); + return; + } + fvp->v_vflag |= VV_DELETED; + VI_UNLOCK(fvp); + + ufs_gjournal_modref(fvp, 1); +} + +void +ufs_gjournal_close(struct vnode *vp) +{ + struct mount *mp; + struct inode *ip; + + mp = vp->v_mount; + if (mp->mnt_gjprovider == NULL) + return; + if (!(vp->v_vflag & VV_DELETED)) + return; + ip = VTOI(vp); + if (ip->i_nlink > 0) + return; + ufs_gjournal_modref(vp, -1); +} + +#endif /* UFS_GJOURNAL */ --- sys/ufs/ufs/ufs_inode.c.orig +++ sys/ufs/ufs/ufs_inode.c @@ -57,6 +57,9 @@ #include #include #endif +#ifdef UFS_GJOURNAL +#include +#endif /* * Last reference to an inode. If necessary, write or delete it. @@ -83,6 +86,9 @@ */ if (ip->i_mode == 0) goto out; +#ifdef UFS_GJOURNAL + ufs_gjournal_close(vp); +#endif if ((ip->i_effnlink == 0 && DOINGSOFTDEP(vp)) || (ip->i_nlink <= 0 && (vp->v_mount->mnt_flag & MNT_RDONLY) == 0)) { --- sys/ufs/ufs/ufs_vnops.c.orig +++ sys/ufs/ufs/ufs_vnops.c @@ -81,6 +81,9 @@ #ifdef UFS_DIRHASH #include #endif +#ifdef UFS_GJOURNAL +#include +#endif #include @@ -777,6 +780,9 @@ error = EPERM; goto out; } +#ifdef UFS_GJOURNAL + ufs_gjournal_orphan(vp); +#endif error = ufs_dirremove(dvp, ip, ap->a_cnp->cn_flags, 0); if (ip->i_nlink <= 0) vp->v_vflag |= VV_NOSYNC; @@ -1683,6 +1689,9 @@ error = EINVAL; goto out; } +#ifdef UFS_GJOURNAL + ufs_gjournal_orphan(vp); +#endif /* * Delete reference to directory before purging * inode. If we crash in between, the directory --------------090106030108050203020100-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 13:35:49 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A64016A416 for ; Fri, 17 Nov 2006 13:35:49 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61CF943D5D for ; Fri, 17 Nov 2006 13:35:46 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from localhost (unknown [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 312BD5C1F; Fri, 17 Nov 2006 13:35:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lyIuRWv-aa7; Fri, 17 Nov 2006 13:35:42 +0000 (UTC) Received: from [62.84.172.67] (dsl172-67.as6911.net [62.84.172.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 385EB5C1D; Fri, 17 Nov 2006 13:35:42 +0000 (UTC) Message-ID: <455DBAAD.6080403@joeholden.co.uk> Date: Fri, 17 Nov 2006 13:35:41 +0000 From: Joe Holden User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Dominic Marks References: <455D5F38.4060208@joeholden.co.uk> <232F7011-5BCC-4616-82CC-973D1CB41593@lassitu.de> <455D66D6.8080708@joeholden.co.uk> <20061117114754.dafdbc1a.dom@helenmarks.co.uk> In-Reply-To: <20061117114754.dafdbc1a.dom@helenmarks.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: (Seemingly) Spontaneous rebooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joe@joeholden.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 13:35:49 -0000 Dominic Marks wrote: > See if you can get temperature readings from the hardware. Is > the system busy? > Hi Dominic, there is no sensors on said machine, it was up for 150 odd days running linux prior to the change. -- finger joe@joeholden.co.uk From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 13:37:05 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F15916A47B for ; Fri, 17 Nov 2006 13:37:05 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E00D43D5C for ; Fri, 17 Nov 2006 13:36:36 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so509258nzh for ; Fri, 17 Nov 2006 05:36:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fzFd+KhQWQpfJb24mZhGJzZEiQ+yhQxRuhRxlsCD0XWE8F57pxVpZxD0RcTAN6gLZBP51t2CkrziLUlq2wziiWDnkh0m122Vif2sC4eApqHrqarJyIDDeoExNXVVtOEUVtKaajtiCNaxUoLsd798cOUmXQhd6r5J6x6mCGpajrw= Received: by 10.65.180.7 with SMTP id h7mr2979267qbp.1163770587793; Fri, 17 Nov 2006 05:36:27 -0800 (PST) Received: by 10.64.204.15 with HTTP; Fri, 17 Nov 2006 05:36:27 -0800 (PST) Message-ID: <84dead720611170536y44477409j3ab56a6a6ab90277@mail.gmail.com> Date: Fri, 17 Nov 2006 19:06:27 +0530 From: "Joseph Koshy" To: "Joe Holden" In-Reply-To: <455D5F38.4060208@joeholden.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455D5F38.4060208@joeholden.co.uk> Cc: freebsd-stable@freebsd.org Subject: Re: (Seemingly) Spontaneous rebooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 13:37:05 -0000 jh> Hi, i'm observing random reboots on a dedicated machine I jh> have with 1&1. jh> I have included as much information as I can think of, if jh> there is anything else I can provide, please ask. Is the machine stable otherwise? Does it pass its builtin diagnostics? A good way to check for bad memory/insufficient cooling is to run a 'make -jN buildworld' repeatedly for 24+hrs, where you choose `N' according to the amount of CPU and RAM you have. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 13:40:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4D6E16A5B7 for ; Fri, 17 Nov 2006 13:40:53 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id E165B43DAF for ; Fri, 17 Nov 2006 13:40:29 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from localhost (unknown [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id EE5605C1F; Fri, 17 Nov 2006 13:40:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkLxuCxGDRbq; Fri, 17 Nov 2006 13:40:24 +0000 (UTC) Received: from [62.84.172.67] (dsl172-67.as6911.net [62.84.172.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 42BA25C1D; Fri, 17 Nov 2006 13:40:24 +0000 (UTC) Message-ID: <455DBBC7.9050807@joeholden.co.uk> Date: Fri, 17 Nov 2006 13:40:23 +0000 From: Joe Holden User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Joseph Koshy References: <455D5F38.4060208@joeholden.co.uk> <84dead720611170536y44477409j3ab56a6a6ab90277@mail.gmail.com> In-Reply-To: <84dead720611170536y44477409j3ab56a6a6ab90277@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: (Seemingly) Spontaneous rebooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joe@joeholden.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 13:40:54 -0000 Joseph Koshy wrote: > Is the machine stable otherwise? Does it pass its > builtin diagnostics? Hi Joseph, It has coped sufficiently during the extensive number of make/buildworlds and day to day use, nothing seems to trigger it, its fairly random. Ta, Joe -- finger joe@joeholden.co.uk From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 13:52:10 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED9ED16A415 for ; Fri, 17 Nov 2006 13:52:10 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A97543D49 for ; Fri, 17 Nov 2006 13:52:09 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.8/8.13.8) with ESMTP id kAHDq7xs048684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Nov 2006 14:52:08 +0100 (CET) (envelope-from stb@lassitu.de) In-Reply-To: <455DBAAD.6080403@joeholden.co.uk> References: <455D5F38.4060208@joeholden.co.uk> <232F7011-5BCC-4616-82CC-973D1CB41593@lassitu.de> <455D66D6.8080708@joeholden.co.uk> <20061117114754.dafdbc1a.dom@helenmarks.co.uk> <455DBAAD.6080403@joeholden.co.uk> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0BE259F4-95BC-4A44-983F-5F65921EFD14@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Fri, 17 Nov 2006 14:54:00 +0100 To: joe@joeholden.co.uk X-Mailer: Apple Mail (2.752.2) Cc: freebsd-stable@freebsd.org, Dominic Marks Subject: Re: (Seemingly) Spontaneous rebooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 13:52:11 -0000 Am 17.11.2006 um 14:35 schrieb Joe Holden: > Dominic Marks wrote: >> See if you can get temperature readings from the hardware. Is >> the system busy? > Hi Dominic, there is no sensors on said machine, it was up for 150 > odd days running linux prior to the change. If the system has ACPI, you might get some temperature information from the sysctl hw.acpi.thermal OIDs. If the hard disk is recent enough, it might have a temperature sensors as well, see sysutils/smartmontools. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 13:52:33 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36FC216A52B for ; Fri, 17 Nov 2006 13:52:33 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9018143D46 for ; Fri, 17 Nov 2006 13:52:32 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from localhost (unknown [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id AB2AD5C1F; Fri, 17 Nov 2006 13:52:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF9jKgkuucn5; Fri, 17 Nov 2006 13:52:29 +0000 (UTC) Received: from [62.84.172.67] (dsl172-67.as6911.net [62.84.172.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by claire.ber.rewt.org.uk (Postfix) with ESMTP id B1F435C1D; Fri, 17 Nov 2006 13:52:28 +0000 (UTC) Message-ID: <455DBE9C.7090909@joeholden.co.uk> Date: Fri, 17 Nov 2006 13:52:28 +0000 From: Joe Holden User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: joe@joeholden.co.uk References: <455D5F38.4060208@joeholden.co.uk> <84dead720611170536y44477409j3ab56a6a6ab90277@mail.gmail.com> <455DBBC7.9050807@joeholden.co.uk> In-Reply-To: <455DBBC7.9050807@joeholden.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Joseph Koshy Subject: Re: (Seemingly) Spontaneous rebooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joe@joeholden.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 13:52:33 -0000 Joe Holden wrote: > Joseph Koshy wrote: >> Is the machine stable otherwise? Does it pass its >> builtin diagnostics? > Hi Joseph, > It has coped sufficiently during the extensive number of > make/buildworlds and day to day use, nothing seems to trigger it, its > fairly random. > > Ta, > Joe Also, I cvsup'd and rebuilt world+kernel last night didn't have any issues during that, although that was hardly 24 hours -- finger joe@joeholden.co.uk From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 13:56:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89E0916A416 for ; Fri, 17 Nov 2006 13:56:09 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 366E543D64 for ; Fri, 17 Nov 2006 13:56:06 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from localhost (unknown [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 615E45C1D; Fri, 17 Nov 2006 13:56:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEupk2MHZBae; Fri, 17 Nov 2006 13:56:03 +0000 (UTC) Received: from [62.84.172.67] (dsl172-67.as6911.net [62.84.172.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 8856F5C20; Fri, 17 Nov 2006 13:56:02 +0000 (UTC) Message-ID: <455DBF71.8060203@joeholden.co.uk> Date: Fri, 17 Nov 2006 13:56:01 +0000 From: Joe Holden User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Stefan Bethke References: <455D5F38.4060208@joeholden.co.uk> <232F7011-5BCC-4616-82CC-973D1CB41593@lassitu.de> <455D66D6.8080708@joeholden.co.uk> <20061117114754.dafdbc1a.dom@helenmarks.co.uk> <455DBAAD.6080403@joeholden.co.uk> <0BE259F4-95BC-4A44-983F-5F65921EFD14@lassitu.de> In-Reply-To: <0BE259F4-95BC-4A44-983F-5F65921EFD14@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Dominic Marks Subject: Re: (Seemingly) Spontaneous rebooting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joe@joeholden.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 13:56:09 -0000 Stefan Bethke wrote: > > If the system has ACPI, you might get some temperature information from > the sysctl hw.acpi.thermal OIDs. > No acpi whatsoever, it is a very "stripped down" machine, looks like a blade or something. > If the hard disk is recent enough, it might have a temperature sensors > as well, see sysutils/smartmontools. > 17 degrees C apparently. Ta, Joe -- finger joe@joeholden.co.uk From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 14:22:58 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 264BB16A407 for ; Fri, 17 Nov 2006 14:22:58 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (www.unsane.co.uk [85.233.185.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F71943D7F for ; Fri, 17 Nov 2006 14:22:57 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from [192.168.10.217] (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.13.7/8.13.3) with ESMTP id kAHECohL061277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Nov 2006 14:12:52 GMT (envelope-from jhary@unsane.co.uk) Message-ID: <455DC35F.7080308@unsane.co.uk> Date: Fri, 17 Nov 2006 14:12:47 +0000 From: Vince User-Agent: Thunderbird 1.5.0.7 (X11/20061017) MIME-Version: 1.0 To: Philippe Pegon References: <455D9C01.3000905@unsane.co.uk> <455DB601.8060306@crc.u-strasbg.fr> In-Reply-To: <455DB601.8060306@crc.u-strasbg.fr> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: gjournal on 6.x wont build X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 14:22:58 -0000 Philippe Pegon wrote: > Vince wrote: >> Hi all, > > Hi, > >> I was intending on trying out gjournal on a new disk i've added in my >> desktop. I had a look to see what the most recent patch provided by >> Pawel and found >> http://people.freebsd.org/~pjd/patches/gjournal6_20061024.patch >> I created the directories as per Pawel's original post >> (http://lists.freebsd.org/pipermail/freebsd-fs/2006-June/001962.html) >> and the patch succeeded with no failed hunks, however adding >> options GEOM_JOURNAL >> options UFS_GJOURNAL >> >> to my kernel config >> then doing a make buildkernel KERNCONF=MYKERNELCONF >> >> errors out with >> /journal/g_journal.c >> /usr/src/sys/geom/journal/g_journal.c: In function `g_journal_do_switch': >> /usr/src/sys/geom/journal/g_journal.c:2872: error: structure has no >> member named `mnt_gjprovider' >> /usr/src/sys/geom/journal/g_journal.c:2885: error: structure has no >> member named `mnt_gjprovider' >> /usr/src/sys/geom/journal/g_journal.c:2890: error: structure has no >> member named `mnt_gjprovider' >> *** Error code 1 >> >> This is on a recent 6-stable system >> 6.2-PRERELEASE #1: Fri Nov 10 14:31:47 GMT 2006 >> any idea what ive done wrong ? > > the latest patch (gjournal6_20061024.patch) doesn't apply cleanly on > fresh RELENG_6 due to the last commit on mount.h : > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/mount.h?only_with_tag=RELENG_6 > > > I have slightly modified the patch so that it works (see attach) > That works a treat. Thanks for the prompt response and patch. i'll start playing with it when i get home. Vince > -- > Philippe Pegon > From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 14:51:10 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57B9516A547; Fri, 17 Nov 2006 14:51:10 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0226243D69; Fri, 17 Nov 2006 14:51:09 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [127.0.0.1] (localhost.cse.buffalo.edu [127.0.0.1]) by opus.cse.buffalo.edu (8.13.8/8.12.4) with ESMTP id kAHEp9bN082996; Fri, 17 Nov 2006 09:51:09 -0500 (EST) From: Ken Smith To: freebsd-stable@freebsd.org, freebsd-announce@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-OrenvrTUYveG0HC31leL" Organization: U. Buffalo CSE Department Date: Fri, 17 Nov 2006 09:51:09 -0500 Message-Id: <1163775069.82615.19.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Cc: Subject: FreeBSD 6.2-RC1 is now available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 14:51:10 -0000 --=-OrenvrTUYveG0HC31leL Content-Type: text/plain Content-Transfer-Encoding: quoted-printable We have now reached the Release Candidate stage of the FreeBSD 6.2 release cycle. A few significant problems had been discovered during the initial BETA testing and those issues should now be fixed. RC1 is the first of two planned Release Candidate builds. If no more significant problems are reported 6.2-RELEASE builds will be done after RC2. This is the first point packages have been included with the test builds and a few minor nits have been noticed already. In particular these are known problems which will be addressed before RC2: - sysinstall tries to install the wrong package for Linux emulation on i386 if you try to install it when prompted but the correct Linux emulation package (linux_base-fc4) is included on the distribution media - if you install gnome2 off the distribution media it will fail to find packages for gmime and gmime-sharp - RC1 distribution media does not include the documentation tree, RC2 will include a separate docs CD. The disc2 image will just contain packages We appreciate all the testing and feedback people have been providing, it has helped improve what will become 6.2-RELEASE. Your continued testing would be greatly appreciated. To get RC1 you can download the installation media from the FTP mirror sites as normal. For those of you who would like to update an existing system using cvs or cvsup use RELENG_6_2 as the branch tag when updating your source tree. Any problems can be reported by submitting a PR and/or sending email to the freebsd-stable@freebsd.org mailing list. MD5s and SHA256s for the ISOS: MD5 (6.2-RC1-alpha-bootonly.iso) =3D 8e39ee88c17884badc3fe189c6ed1795 MD5 (6.2-RC1-alpha-disc1.iso) =3D 25157cbebdb9820d37dd69131c559c1a MD5 (6.2-RC1-alpha-disc2.iso) =3D a482d215c05a24df55e5e263ef77918e MD5 (6.2-RC1-amd64-bootonly.iso) =3D 1185b38c1ea6fc93f3d1dffb0d40cba9 MD5 (6.2-RC1-amd64-disc1.iso) =3D ec29dae6926c1641a6cc7dd1a2047f84 MD5 (6.2-RC1-amd64-disc2.iso) =3D d9de53123d42a6464ae6d8a930024f80 MD5 (6.2-RC1-i386-bootonly.iso) =3D 2d0ca001f27e342aaffb265ca65fcde2 MD5 (6.2-RC1-i386-disc1.iso) =3D 29887fdc63ca47b60febe98a7246c451 MD5 (6.2-RC1-i386-disc2.iso) =3D bfc991723d29bb320db302b47871b1f9 MD5 (6.2-RC1-ia64-bootonly.iso) =3D cf6f1519b4dd4264fb2b873bc280a8f4 MD5 (6.2-RC1-ia64-disc1.iso) =3D 983e795f65882bfd93250ec074b33ca6 MD5 (6.2-RC1-ia64-disc2.iso) =3D 4699d6f27075144cbe2347271d47c89c MD5 (6.2-RC1-ia64-livefs.iso) =3D cdb6c5d853acaad1d8385d4c8302d061 MD5 (6.2-RC1-pc98-bootonly.iso) =3D 43df2d851438b5212faa81e456190ae5 MD5 (6.2-RC1-pc98-disc1.iso) =3D ba33bc96d1c416f16e123d43c88110da MD5 (6.2-RC1-sparc64-bootonly.iso) =3D dd29f3da4efb23d84fbb051db556b62e MD5 (6.2-RC1-sparc64-disc1.iso) =3D f4f4025cbb68cf332ccafb44a4973ce6 MD5 (6.2-RC1-sparc64-disc2.iso) =3D 8ce06a2a633141cc5a52f8d1f6059e22 SHA256 (6.2-RC1-amd64-bootonly.iso) =3D c3b0e1192f0756bf36438e4885d312cec03= da816e3cf3682334ac627eec59713 SHA256 (6.2-RC1-amd64-disc1.iso) =3D 1b83029274ca3aac1a9304abf2d9a97d1a6020= b01066385ed7378826ce00517c SHA256 (6.2-RC1-amd64-disc2.iso) =3D 0ec1a6562b92e917a77e0a536cc31c6a510ae7= 7fcd58369342a3cfa69d61aa45 SHA256 (6.2-RC1-i386-bootonly.iso) =3D fdabfbf8b60c21a37d0311f89cd72070c080= a7985cc7fd588a1365cbca6d24bf SHA256 (6.2-RC1-i386-disc1.iso) =3D 1609f2ddf3afd353f2451f36e9554b332a67ff1= 539e90d0d2023aee21b0ab513 SHA256 (6.2-RC1-i386-disc2.iso) =3D f49fd1ce0769199eeb840046817249d96c6c956= 31b5546586d46d6cb5d760640 SHA256 (6.2-RC1-ia64-bootonly.iso) =3D 51f410cfab7846fca7576e265dd1683f1494= f71560714c17fe7f9f0695389041 SHA256 (6.2-RC1-ia64-disc1.iso) =3D fc39dbe8e99766a7b071fa35f4efea6a65728d0= 5379ca29cbefec8431901b868 SHA256 (6.2-RC1-ia64-disc2.iso) =3D 3119d0d625a6abb218653c339976d9a6b84272d= 71f94573f06a26fa070ed97cc SHA256 (6.2-RC1-ia64-livefs.iso) =3D e6c8411c406c497c2bc5ad9577f2db159a3c8a= 39ef3123674faede9765c08107 SHA256 (6.2-RC1-pc98-bootonly.iso) =3D 66d30a5a3ca1b296cf9370a9116a1cce282d= 5f25d1843be36c21d731b4225bf6 SHA256 (6.2-RC1-pc98-disc1.iso) =3D 1a1ff42156d8e201feb54c6a1e36c3b07a682b2= 2fc7ba8a13fee0ebef2316c26 SHA256 (6.2-RC1-sparc64-bootonly.iso) =3D ef493ca3b5f053cfcc10f9f5f0d7e8517= 1681fe2f1aa67d314b63a8bc8d25983 SHA256 (6.2-RC1-sparc64-disc1.iso) =3D a2a3ac1191e7ce46efb12d1c4e51a0eed5a7= 2d130f7d48affa0f8fcfa1324c41 SHA256 (6.2-RC1-sparc64-disc2.iso) =3D 79103893f4059fca06bb20a09df157ff28c8= 14fa33f5db715c6b87a81eb0711b --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-OrenvrTUYveG0HC31leL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFXcxd/G14VSmup/YRAj51AJ9MJWUgurAFMDov+AQciz8HmUdXWQCeIuXA 28gVsS6K4iSX7Px+jGJHU6Y= =aG9F -----END PGP SIGNATURE----- --=-OrenvrTUYveG0HC31leL-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 15:40:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D3A216A4C8 for ; Fri, 17 Nov 2006 15:40:08 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3DA743D55 for ; Fri, 17 Nov 2006 15:40:07 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by ug-out-1314.google.com with SMTP id j3so814525ugf for ; Fri, 17 Nov 2006 07:40:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=umqedZfigIBRmFZv+vCAWGUfgqy+C1oCiCFf84NU+UGtpkB27z7NCAj7YH86B/twz4ZGg/ExNpKsI+CYarBUUoiUrC4Zy4PD2S+9/Q/fgjTFDpn7YblL8BTF2pU6Y1Dqb/vFa2MIl3x8abBrAJneeNf/w6l6+b0Am3e/XYUs5eM= Received: by 10.78.204.7 with SMTP id b7mr2021095hug.1163778006303; Fri, 17 Nov 2006 07:40:06 -0800 (PST) Received: by 10.78.97.15 with HTTP; Fri, 17 Nov 2006 07:40:06 -0800 (PST) Message-ID: Date: Fri, 17 Nov 2006 16:40:06 +0100 From: "Claus Guttesen" To: "FreeBSD Stable List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: hp c class blade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 15:40:08 -0000 Hi. I've installed FreeBSD 6.2 RC1 onto a BL460c blade. The installation itself went fine, but there is no network. The nic is on a broadcom 16 ports GB switch on the backside of the blade-chassis. I have booted in safe mode and without acpi, but still no nic unfortunately. regards Claus From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 15:45:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9623916A4F8 for ; Fri, 17 Nov 2006 15:45:25 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E2B43D5C for ; Fri, 17 Nov 2006 15:43:51 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so657538uge for ; Fri, 17 Nov 2006 07:43:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q1POl4N97eSbsGIXixi/wx95o/NPVB24NtUQcSXRnHaBAF4vybadc/e+XNW8GG+mYEveZ1rwBfvq7EYZlaZvrLolIpPmt1VPuZ6GfGmbjjYIf5dDsij4HN76zQOPF7XFqGk4ssmp9r0CwsxcY/HmKKfVDuQOLl1xvscGXOKfcRY= Received: by 10.78.138.6 with SMTP id l6mr1974442hud.1163778230778; Fri, 17 Nov 2006 07:43:50 -0800 (PST) Received: by 10.78.97.15 with HTTP; Fri, 17 Nov 2006 07:43:50 -0800 (PST) Message-ID: Date: Fri, 17 Nov 2006 16:43:50 +0100 From: "Claus Guttesen" To: "FreeBSD Stable List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Subject: Re: hp c class blade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 15:45:25 -0000 > I've installed FreeBSD 6.2 RC1 onto a BL460c blade. The installation > itself went fine, but there is no network. The nic is on a broadcom 16 > ports GB switch on the backside of the blade-chassis. Forgot to mention it was the amd64-port. Claus From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 15:54:06 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65B2416A415; Fri, 17 Nov 2006 15:54:06 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDA6843DA3; Fri, 17 Nov 2006 15:53:38 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 43FAC6133; Fri, 17 Nov 2006 18:53:36 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 09FD25EAD; Fri, 17 Nov 2006 18:53:36 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kAHFra0g006631; Fri, 17 Nov 2006 18:53:36 +0300 (MSK) (envelope-from ru) Date: Fri, 17 Nov 2006 18:53:35 +0300 From: Ruslan Ermilov To: stable@freebsd.org Message-ID: <20061117155335.GA2898@rambler-co.ru> References: <7ad7ddd90611160255m553a471cy41f6c911bdc2a1bf@mail.gmail.com> <20061116150309.GD48412@rambler-co.ru> <20061116191037.GA1515@roadrunner.q.local> <20061116223800.GA85695@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0ntfKIWw70PvrIHh" Content-Disposition: inline In-Reply-To: <20061116223800.GA85695@rambler-co.ru> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alan Cox Subject: Re: systat -vm output showing negative total virtual memory X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 15:54:06 -0000 --0ntfKIWw70PvrIHh Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 17, 2006 at 01:38:00AM +0300, Ruslan Ermilov wrote: > Actually, the values are also in pages. Below is a new patch > to try. The total amount of virtual memory reported is still > insane; I think some objects are included in the stats > mistakenly, but I'm not yet sure. >=20 Okay, the attached patch that includes a "fix" for vm_meter.c now prints the sane values for virtual memory. The huge contributions to vm total were from vnode objects representing mounted file systems (g_vfs_open()). Alan, could you please review this patch for me (the vm_meter.c portion at least) or suggest a better fix? On my amd64 system, I now get: : vm.vmtotal: : System wide totals computed every five seconds: (values in kilobytes) : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D : Processes: (RUNQ: 2 Disk Wait: 0 Page Wait: 0 Sleep: 35) : Virtual Memory: (Total: 4458372K, Active 95772K) : Real Memory: (Total: 93468K Active 71016K) : Shared Virtual Memory: (Total: 20504K Active: 18952K) : Shared Real Memory: (Total: 13956K Active: 13148K) : Free Memory Pages: 3024836K The patch is against RELENG_6 but should apply to HEAD too. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --+HP7ph2BbKc20aGI-- --0ntfKIWw70PvrIHh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXdr/qRfpzJluFF4RAtUkAJ4tksecolD8yRz/S6O4TkNS3HpcfwCdFnt4 Af1yChJVLGKOqUX+AWswENM= =JvoP -----END PGP SIGNATURE----- --0ntfKIWw70PvrIHh-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 16:14:10 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D47A016A412 for ; Fri, 17 Nov 2006 16:14:10 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94AE343D60 for ; Fri, 17 Nov 2006 16:14:01 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so539969nzh for ; Fri, 17 Nov 2006 08:14:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NPIeIf/hdq3oLCXL3ux9cHSZF/rwDz6DPkQbhAwMSb4K13TRvJd4lxHP3Xs9hb52yYeP0ypa1hRgxGAjZ7qnk8kBcpbbCkjQ3Nwg2Sr0GXaOtni4ioNNziJKc44YuRR9I/Ivh3pPRvElTyzIo4b5lc93HmRTLqKjgFAdUpv6USc= Received: by 10.65.219.16 with SMTP id w16mr2638167qbq.1163780041107; Fri, 17 Nov 2006 08:14:01 -0800 (PST) Received: by 10.65.220.18 with HTTP; Fri, 17 Nov 2006 08:14:00 -0800 (PST) Message-ID: <6eb82e0611170814w55814f96wcbf8be80f7a621fa@mail.gmail.com> Date: Sat, 18 Nov 2006 00:14:00 +0800 From: "Rong-en Fan" To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: ips(4) in toaster mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 16:14:11 -0000 Hi, After upgrading RELENG_6 from Jul 11 to Sep 30 on an i386 box, everytime I run tar to backup my system to a mounted nfs volume. After one hour of operation, it panics with sleeping thread. Upgrading to RELENG_6_2 does not help. Also, the console is complete hang, I can not break into DDB at all. The only thing is do power cycling. Also, the only harddisk on that host is the ips(4), so I can not obtain a kernel dump. I'm not sure if this is a hardware failure, at least, no led on the panel is shown red... OK, the only information on console is attached below. Any suggesstion are welcome. Thanks, Rong-En Fan == ips0: WARNING: command timeout. Adapter is in toaster mode, resetting to known s tate ips0: resetting adapter, this may take up to 5 minutes ips0: syncing config Sleeping thread (tid 100002, pid 14) owns a non-sleepable lock sched_switch(c5feec00,0,1,8577f833,d14d2103,...) at sched_switch+0x158 mi_switch(1,0) at mi_switch+0x1d5 sleepq_switch(c60c2604,e9f77b8c,c051acd3,4,1,...) at sleepq_switch+0x93 sleepq_wait(c60c2604,c60c25e0,c06e6957,1,1,...) at sleepq_wait+0x75 cv_wait(c60c2604,c60c25e0,a,e9f77c04,5,...) at cv_wait+0x151 _sema_wait(c60c25e0,0,0,c60c2400,c60c2400,...) at _sema_wait+0x64 ips_send_config_sync_cmd(c60f5000,e9f77c08,1,c60f5000,7,...) at ips_send_config_sync_cmd+0x78 ips_clear_adapter(c60c2400,c60b6e00,0,4,c60f5000,...) at ips_clear_adapter+0x60 ips_morpheus_reinit(c60c2400,1,c053abf7,c0740100,c5feec00,...) at ips_morpheus_reinit+0x2ac ips_timeout(c60c2400,c053a7f5,c5feec00,c5feea80,d69f60ed,...) at ips_timeout+0xf8 softclock(0,e9f77cd4,15dbe,c43ec589,c5feec00,...) at softclock+0x35d ithread_execute_handlers(c5fed430,c6042000,0,0,0,...) at ithread_execute_handlers+0x162 ithread_loop(c5fbc880,e9f77d38,0,0,0,...) at ithread_loop+0x64 fork_exit(c050b22a,c5fbc880,e9f77d38) at fork_exit+0x7b fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe9f77d6c, ebp = 0 --- panic: sleeping thread cpuid = 2 KDB: stack backtrace: kdb_backtrace(c0702303,2,c06ef01b,e9f98bf0,0,...) at kdb_backtrace+0x2f panic(c06ef01b,ffffffff,e,c051ac54,1,...) at panic+0x129 propagate_priority(c5fefd80,c5fefd80,0,0,0,...) at propagate_priority+0x69 turnstile_wait(c60c25a8,c5feec00,c610c000,c7d064a4,4,...) at turnstile_wait+0x32f _mtx_lock_sleep(c60c25a8,c5fefd80,0,0,0,...) at _mtx_lock_sleep+0xfd ipsd_strategy(c7d064a4,43,200,0,c04e31a1,...) at ipsd_strategy+0x70 g_disk_start(c7d1e4a4,c073bac8,24c,c06e8406,64,...) at g_disk_start+0x1b1 g_io_schedule_down(c5fefd80,4c,c5fefd80,c04e39c1,e9f98d04,...) at g_io_schedule_down+0x15f g_down_procbody(0,e9f98d38,0,0,0,...) at g_down_procbody+0xb3 fork_exit(c04e39c1,0,e9f98d38) at fork_exit+0x7b fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe9f98d6c, ebp = 0 --- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 16:15:45 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E37A16A407 for ; Fri, 17 Nov 2006 16:15:45 +0000 (UTC) (envelope-from vincent@xtra-net.org) Received: from ns1.xtra-net.be (ns1.xtra-net.be [195.162.200.90]) by mx1.FreeBSD.org (Postfix) with SMTP id B0E7843D67 for ; Fri, 17 Nov 2006 16:15:15 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 24219 invoked from network); 17 Nov 2006 16:15:14 -0000 Received: from unknown (HELO sbepfkaa.srv.xtra-net.be) (172.16.66.66) by 0 with SMTP; 17 Nov 2006 16:15:14 -0000 Received: (qmail 4686 invoked from network); 17 Nov 2006 16:14:16 -0000 Received: from wbedllfs.intranet.xtra-net.be (HELO wbemfkaa.net.xtra-net.be) (172.16.66.1) by 0 with SMTP; 17 Nov 2006 16:14:16 -0000 From: Vincent Blondel To: freebsd-stable@freebsd.org In-Reply-To: <20061116214237.GA69412@xor.obsecurity.org> References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> <20061116161706.GB65054@xor.obsecurity.org> <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> <20061116210151.GA68673@xor.obsecurity.org> <1163712849.8157.5.camel@wbemfkaa.net.xtra-net.be> <20061116214237.GA69412@xor.obsecurity.org> Content-Type: text/plain Date: Fri, 17 Nov 2006 17:14:40 +0100 Message-Id: <1163780080.2697.6.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: vincent@xtra-net.org, kris@obsecurity.org Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 16:15:45 -0000 On Thu, 2006-11-16 at 16:42 -0500, Kris Kennaway wrote: > On Thu, Nov 16, 2006 at 10:34:09PM +0100, Vincent Blondel wrote: > > Kris, > > > > You are speaking about backtrace but sorry I do not know what does > > exactly this command. > > Check the developers handbook, there's a whole chapter about this > topic :-) thanks :-) > > > Anyway, I see I did not give you result of backtrace for the second > > kernel panic (this one I had this morning ..) so maybe are you waiting > > for this result : > > OK, this backtrace at least seems to be legitimate :-) > > I'm not sure about the cause though, does it happen every time you run > mailwrapper, or only under load? sendmail_enable is defined to "NONE" so I can suppose I do not use mailwrapper. How can I know it > > Kris > > P.S. Please don't top-post, it's already destroyed context from your > posts so I have no idea whether you've already provided this > information without reviewing your older emails. > > > Unread portion of the kernel message buffer: > > x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 14294 (mailwrapper) > > trap number = 12 > > panic: page fault > > cpuid = 0 > > Uptime: 6h23m20s > > Dumping 1023 MB (2 chunks) > > chunk 0: 1MB (159 pages) ... ok > > chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879 > > 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 > > 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 > > 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 > > > > #0 doadump () at pcpu.h:165 > > 165 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) backtrace > > #0 doadump () at pcpu.h:165 > > #1 0xc04e3436 in boot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:409 > > #2 0xc04e375d in panic (fmt=0xc064447a "%s") > > at /usr/src/sys/kern/kern_shutdown.c:565 > > #3 0xc062bd30 in trap_fatal (frame=0xe71cf9f4, eva=2378418688) > > at /usr/src/sys/i386/i386/trap.c:837 > > #4 0xc062ba6f in trap_pfault (frame=0xe71cf9f4, usermode=0, > > eva=2378418688) at /usr/src/sys/i386/i386/trap.c:745 > > #5 0xc062b6c9 in trap (frame= > > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 135012352, tf_esi = > > 176128, tf_ebp = -417531336, tf_isp = -417531360, tf_ebx = -999349952, > > tf_edx = -968498816, tf_ecx = 4, tf_eax = 1, tf_trapno = 12, tf_err = 0, > > tf_eip = -1067261688, tf_cs = 32, tf_eflags = 66050, tf_esp = > > -1057182640, tf_ss = -417531320}) at /usr/src/sys/i386/i386/trap.c:435 > > #6 0xc061810a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > #7 0xc062e108 in sf_buf_free (sf=0xc46f2140) > > at /usr/src/sys/i386/i386/vm_machdep.c:783 > > #8 0xc05e1d6c in vm_imgact_unmap_page (sf=0x1) > > at /usr/src/sys/vm/vm_glue.c:307 > > #9 0xc04b3ca8 in elf32_load_section (vmspace=0xc4dc1b90, > > object=0xc7c3a084, offset=490048, vmaddr=0x80c0a40
> out of bounds>, > > memsz=180788, filsz=9344, prot=3 '\003', pagesize=4096) > > at /usr/src/sys/kern/imgact_elf.c:434 > > #10 0xc04b424b in exec_elf32_imgact (imgp=0xe71cfbe8) > > at /usr/src/sys/kern/imgact_elf.c:694 > > #11 0xc04c808e in do_execve (td=0xc645e180, args=0xe71cfcb4, mac_p=0x0) > > at /usr/src/sys/kern/kern_exec.c:426 > > #12 0xc04c7d94 in kern_execve (td=0xc645e180, args=0xe71cfcb4, > > mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:264 > > #13 0xc04c7c9a in execve (td=0xc645e180, uap=0x1) > > at /usr/src/sys/kern/kern_exec.c:188 > > #14 0xc062c077 in syscall (frame= > > {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134525001, tf_esi = > > 134524992, tf_ebp = -1077940664, tf_isp = -417530524, tf_ebx = > > -1077940692, tf_edx = 1, tf_ecx = 134529024, tf_eax = 59, tf_trapno = > > 12, tf_err = 2, tf_eip = 671913639, tf_cs = 51, tf_eflags = 514, tf_esp > > = -1077940732, tf_ss = 59}) > > at /usr/src/sys/i386/i386/trap.c:983 > > #15 0xc061815f in Xint0x80_syscall () > > at /usr/src/sys/i386/i386/exception.s:200 > > #16 0x00000033 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) quit > > root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] # > > > > --- > > > > Vincent > > > > On Thu, 2006-11-16 at 16:01 -0500, Kris Kennaway wrote: > > > On Thu, Nov 16, 2006 at 05:38:44PM +0100, Vincent Blondel wrote: > > > > > > > > Hello Kris, > > > > > > > > You can find below a generic make.conf I use to compile src/ports on my > > > > all machines ( only AMD Athlon XP/MP ). > > > > > > > > .CPUTYPE != sysctl hw.model |sed 's/ //g' > > > > .if ${.CPUTYPE:M*AMDAthlon(tm)XP*} > > > > CFLAGS= -march=athlon-xp > > > > .endif > > > > .if ${.CPUTYPE:M*AMDAthlon(tm)MP*} > > > > CFLAGS= -march=athlon-mp > > > > .endif > > > > CFLAGS+= -O -pipe > > > > CFLAGS+= -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 > > > > .if ${.CURDIR:M/usr/src/*} > > > > CFLAGS+= -fno-strict-aliasing > > > > .endif > > > > .if ${.CURDIR:M/usr/ports/*} > > > > CFLAGS+= -Os -fomit-frame-pointer > > > > .endif > > > > COPTFLAGS= -O -pipe > > > > > > I think you have the -fno-strict-aliasing backwards, BTW: /usr/src > > > should be safe to compile with -fstrict-aliasing (but it's only > > > enabled by default at -O2, so that's a NOP for you anyway), but ports > > > definitely are not in general. > > > > > > Also you might as well use CPUTYPE instead of manually setting CFLAGS > > > to do the same thing. > > > > > > Anyway, this doesn't seem to be the cause of your problems so I don't > > > know why your backtraces are garbage. Maybe you can try backtracing > > > in DDB when you get a panic and see what that says instead. > > > > > > Kris > > > > From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 16:33:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA3BA16A55C for ; Fri, 17 Nov 2006 16:33:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.152]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AAE043D5A for ; Fri, 17 Nov 2006 16:33:42 +0000 (GMT) (envelope-from jdc@koitsu.dyndns.org) Received: from icarus.home.lan (c-67-174-220-97.hsd1.ca.comcast.net[67.174.220.97]) by comcast.net (rwcrmhc12) with ESMTP id <20061117163330m1200kqor5e>; Fri, 17 Nov 2006 16:33:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 64D851FA01D; Fri, 17 Nov 2006 08:33:30 -0800 (PST) Date: Fri, 17 Nov 2006 08:33:30 -0800 From: Jeremy Chadwick To: Vincent Blondel Message-ID: <20061117163330.GA90885@icarus.home.lan> Mail-Followup-To: Vincent Blondel , freebsd-stable@freebsd.org, kris@obsecurity.org References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> <20061116161706.GB65054@xor.obsecurity.org> <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> <20061116210151.GA68673@xor.obsecurity.org> <1163712849.8157.5.camel@wbemfkaa.net.xtra-net.be> <20061116214237.GA69412@xor.obsecurity.org> <1163780080.2697.6.camel@wbemfkaa.net.xtra-net.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1163780080.2697.6.camel@wbemfkaa.net.xtra-net.be> X-PGP-Key: http://jdc.parodius.com/pubkey.asc User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-stable@freebsd.org, kris@obsecurity.org Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 16:33:44 -0000 On Fri, Nov 17, 2006 at 05:14:40PM +0100, Vincent Blondel wrote: > > OK, this backtrace at least seems to be legitimate :-) > > > > I'm not sure about the cause though, does it happen every time you run > > mailwrapper, or only under load? > > sendmail_enable is defined to "NONE" so I can suppose I do not use > mailwrapper. > > How can I know it You use mailwrapper whether or not sendmail_enable is set to NONE or any other value. mailwrapper is the framework used to make migrating to another MTA (postfix, exim, etc.) easier. It's what makes /etc/mail/mailer.conf work. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 16:36:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B28116A407 for ; Fri, 17 Nov 2006 16:36:09 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6611843D7D for ; Fri, 17 Nov 2006 16:36:00 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so544573nzh for ; Fri, 17 Nov 2006 08:36:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z52YnTvRCrlZ0H2FeE4+JJK5xT9dwXseO0sx0GsKzO4w56P5V9EWUkxBZ+rlCCRhhvx2MiIL8bvvyw9/KgM2PqbHF1NTQaKZsQgCnoinV4LEudbrGVawbfLnTzoHraVW+LWxVCSMulTcT57G+cHrGkWi/b7XHRbiRWeJpWOcp+g= Received: by 10.65.237.15 with SMTP id o15mr1367207qbr.1163781360247; Fri, 17 Nov 2006 08:36:00 -0800 (PST) Received: by 10.64.204.15 with HTTP; Fri, 17 Nov 2006 08:35:59 -0800 (PST) Message-ID: <84dead720611170835g42763643ia4de29781580e792@mail.gmail.com> Date: Fri, 17 Nov 2006 22:05:59 +0530 From: "Joseph Koshy" To: "Claus Guttesen" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: FreeBSD Stable List Subject: Re: hp c class blade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 16:36:09 -0000 cg> I've installed FreeBSD 6.2 RC1 onto a BL460c blade. The cg> installation itself went fine, but there is no network. cg> The nic is on a broadcom 16 ports GB switch on the cg> backside of the blade-chassis. Does the kernel detect any kind of network card in the system? What does "dmesg" say? If not, you'll need to check if the NIC in the system is supported. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 16:37:57 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BA1F16A519 for ; Fri, 17 Nov 2006 16:37:57 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3D7B43D46 for ; Fri, 17 Nov 2006 16:37:56 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so671374uge for ; Fri, 17 Nov 2006 08:37:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nBR1AqEp0VPI57crkXfL+ZWzHm3DlT6bKO/vuYL3t/0pB0MlR9V216N3nH3fGTYIr/ltKa2vx+j/VIhnWFbiyH/NpClyZRLiUVAPCoPt9Svh8foi9iaJniXvXr3HVLgcqsZsqvrrY+kKRFi1VqRDqPbVesXfqHW0k28HL/VnuY4= Received: by 10.78.201.15 with SMTP id y15mr2080748huf.1163781474841; Fri, 17 Nov 2006 08:37:54 -0800 (PST) Received: by 10.78.97.15 with HTTP; Fri, 17 Nov 2006 08:37:54 -0800 (PST) Message-ID: Date: Fri, 17 Nov 2006 17:37:54 +0100 From: "Claus Guttesen" To: "Craig Rodrigues" , "FreeBSD Stable List" In-Reply-To: <20061117154526.GA44026@crodrigues.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061117154526.GA44026@crodrigues.org> Cc: Subject: Re: Re: hp c class blade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 16:37:57 -0000 > Can you post the output of pciconf -l -v > and /var/run/dmesg.boot to the mailing list? I don't have physical access to the server atm. I'll get the information tomorrow. Claus From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 16:51:58 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2F0916A412 for ; Fri, 17 Nov 2006 16:51:58 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DF4943D5F for ; Fri, 17 Nov 2006 16:51:57 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (idqfmh@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kAHGpoQt039958; Fri, 17 Nov 2006 17:51:55 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kAHGpnd1039957; Fri, 17 Nov 2006 17:51:49 +0100 (CET) (envelope-from olli) Date: Fri, 17 Nov 2006 17:51:49 +0100 (CET) Message-Id: <200611171651.kAHGpnd1039957@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, kometen@gmail.com In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 17 Nov 2006 17:51:55 +0100 (CET) Cc: Subject: Re: hp c class blade X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, kometen@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 16:51:58 -0000 Claus Guttesen wrote: > I've installed FreeBSD 6.2 RC1 onto a BL460c blade. The installation > itself went fine, but there is no network. The nic is on a broadcom 16 > ports GB switch on the backside of the blade-chassis. > > I have booted in safe mode and without acpi, but still no nic unfortunately. What kind of NIC is it? Type "pcicinf -lv" and look for it. If you tell us the name, vendor ID and device ID (or even better, the whole section from pciconf output), someone might be able to tell you details about the support status of it in FreeBSD. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 17:34:26 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D252516A412 for ; Fri, 17 Nov 2006 17:34:26 +0000 (UTC) (envelope-from vincent@xtra-net.org) Received: from ns1.xtra-net.be (ns1.xtra-net.be [195.162.200.90]) by mx1.FreeBSD.org (Postfix) with SMTP id E04B343D69 for ; Fri, 17 Nov 2006 17:34:19 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 13698 invoked from network); 17 Nov 2006 17:34:16 -0000 Received: from unknown (HELO sbepfkaa.srv.xtra-net.be) (172.16.66.66) by 0 with SMTP; 17 Nov 2006 17:34:16 -0000 Received: (qmail 18990 invoked from network); 17 Nov 2006 17:33:17 -0000 Received: from wbedllfs.intranet.xtra-net.be (HELO wbemfkaa.net.xtra-net.be) (172.16.66.1) by 0 with SMTP; 17 Nov 2006 17:33:17 -0000 From: Vincent Blondel To: freebsd-stable@freebsd.org In-Reply-To: <20061117163330.GA90885@icarus.home.lan> References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> <20061116161706.GB65054@xor.obsecurity.org> <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> <20061116210151.GA68673@xor.obsecurity.org> <1163712849.8157.5.camel@wbemfkaa.net.xtra-net.be> <20061116214237.GA69412@xor.obsecurity.org> <1163780080.2697.6.camel@wbemfkaa.net.xtra-net.be> <20061117163330.GA90885@icarus.home.lan> Content-Type: text/plain Date: Fri, 17 Nov 2006 18:33:43 +0100 Message-Id: <1163784823.2697.14.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: koitsu@FreeBSD.org, vincent@xtra-net.org, kris@obsecurity.org Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 17:34:26 -0000 On Fri, 2006-11-17 at 08:33 -0800, Jeremy Chadwick wrote: > On Fri, Nov 17, 2006 at 05:14:40PM +0100, Vincent Blondel wrote: > > > OK, this backtrace at least seems to be legitimate :-) > > > > > > I'm not sure about the cause though, does it happen every time you run > > > mailwrapper, or only under load? > > > > sendmail_enable is defined to "NONE" so I can suppose I do not use > > mailwrapper. > > > > How can I know it > > You use mailwrapper whether or not sendmail_enable is set to NONE > or any other value. > > mailwrapper is the framework used to make migrating to another > MTA (postfix, exim, etc.) easier. It's what makes > /etc/mail/mailer.conf work. I know and /etc/mail/mailer.conf is defined like this on my machine to use qmail. sendmail /var/qmail/bin/sendmail send-mail /var/qmail/bin/sendmail mailq /var/qmail/bin/qmail-qread > From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 17:43:08 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABCDD16A407 for ; Fri, 17 Nov 2006 17:43:08 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EF0E43D58 for ; Fri, 17 Nov 2006 17:43:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAHHh0Dn027887; Fri, 17 Nov 2006 10:43:05 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <455DF4A2.2010805@samsco.org> Date: Fri, 17 Nov 2006 10:42:58 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Rong-en Fan References: <6eb82e0611170814w55814f96wcbf8be80f7a621fa@mail.gmail.com> In-Reply-To: <6eb82e0611170814w55814f96wcbf8be80f7a621fa@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: stable@freebsd.org Subject: Re: ips(4) in toaster mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 17:43:08 -0000 I'll look at this. Scott Rong-en Fan wrote: > Hi, > > After upgrading RELENG_6 from Jul 11 to Sep 30 on an i386 box, > everytime I run tar to backup my system to a mounted nfs volume. > After one hour of operation, it panics with sleeping thread. Upgrading > to RELENG_6_2 does not help. Also, the console is complete > hang, I can not break into DDB at all. The only thing is do power > cycling. > > Also, the only harddisk on that host is the ips(4), so I can not obtain > a kernel dump. I'm not sure if this is a hardware failure, at least, no > led on the panel is shown red... > > OK, the only information on console is attached below. Any suggesstion > are welcome. > > Thanks, > Rong-En Fan > > == > > ips0: WARNING: command timeout. Adapter is in toaster mode, resetting to > known s > tate > ips0: resetting adapter, this may take up to 5 minutes > ips0: syncing config > Sleeping thread (tid 100002, pid 14) owns a non-sleepable lock > sched_switch(c5feec00,0,1,8577f833,d14d2103,...) at sched_switch+0x158 > mi_switch(1,0) at mi_switch+0x1d5 > sleepq_switch(c60c2604,e9f77b8c,c051acd3,4,1,...) at sleepq_switch+0x93 > sleepq_wait(c60c2604,c60c25e0,c06e6957,1,1,...) at sleepq_wait+0x75 > cv_wait(c60c2604,c60c25e0,a,e9f77c04,5,...) at cv_wait+0x151 > _sema_wait(c60c25e0,0,0,c60c2400,c60c2400,...) at _sema_wait+0x64 > ips_send_config_sync_cmd(c60f5000,e9f77c08,1,c60f5000,7,...) at > ips_send_config_sync_cmd+0x78 > ips_clear_adapter(c60c2400,c60b6e00,0,4,c60f5000,...) at > ips_clear_adapter+0x60 > ips_morpheus_reinit(c60c2400,1,c053abf7,c0740100,c5feec00,...) at > ips_morpheus_reinit+0x2ac > ips_timeout(c60c2400,c053a7f5,c5feec00,c5feea80,d69f60ed,...) at > ips_timeout+0xf8 > softclock(0,e9f77cd4,15dbe,c43ec589,c5feec00,...) at softclock+0x35d > ithread_execute_handlers(c5fed430,c6042000,0,0,0,...) at > ithread_execute_handlers+0x162 > ithread_loop(c5fbc880,e9f77d38,0,0,0,...) at ithread_loop+0x64 > fork_exit(c050b22a,c5fbc880,e9f77d38) at fork_exit+0x7b > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe9f77d6c, ebp = 0 --- > panic: sleeping thread > cpuid = 2 > KDB: stack backtrace: > kdb_backtrace(c0702303,2,c06ef01b,e9f98bf0,0,...) at kdb_backtrace+0x2f > panic(c06ef01b,ffffffff,e,c051ac54,1,...) at panic+0x129 > propagate_priority(c5fefd80,c5fefd80,0,0,0,...) at propagate_priority+0x69 > turnstile_wait(c60c25a8,c5feec00,c610c000,c7d064a4,4,...) at > turnstile_wait+0x32f > _mtx_lock_sleep(c60c25a8,c5fefd80,0,0,0,...) at _mtx_lock_sleep+0xfd > ipsd_strategy(c7d064a4,43,200,0,c04e31a1,...) at ipsd_strategy+0x70 > g_disk_start(c7d1e4a4,c073bac8,24c,c06e8406,64,...) at g_disk_start+0x1b1 > g_io_schedule_down(c5fefd80,4c,c5fefd80,c04e39c1,e9f98d04,...) at > g_io_schedule_down+0x15f > g_down_procbody(0,e9f98d38,0,0,0,...) at g_down_procbody+0xb3 > fork_exit(c04e39c1,0,e9f98d38) at fork_exit+0x7b > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe9f98d6c, ebp = 0 --- > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 19:29:47 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55C5816A40F for ; Fri, 17 Nov 2006 19:29:47 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [74.92.149.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEC5943D4C for ; Fri, 17 Nov 2006 19:29:46 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id E0594B80F for ; Fri, 17 Nov 2006 14:29:45 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20061116003422.GC942@tigerfish2.my.domain> References: <36FBC1D2-9F33-4EA1-B93D-EB4C2B1253E8@khera.org> <20061116003422.GC942@tigerfish2.my.domain> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-800990119; protocol="application/pkcs7-signature" Message-Id: <35A2EF81-7D7B-4A8A-9101-5AEFEB3ED057@khera.org> From: Vivek Khera Date: Fri, 17 Nov 2006 14:29:43 -0500 To: FreeBSD Stable X-Mailer: Apple Mail (2.752.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: adaptec utilities on amd64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 19:29:47 -0000 --Apple-Mail-7-800990119 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 15, 2006, at 7:34 PM, Bruce Burden wrote: > I have a 2230SLP that I will be installing early next week > on my AMD64 implementation. I am hoping that the aaccli program > in ports will work. If it has the newer firmware, it will not work with aaccli. If you got the card after they switched to the "R" revision, you have the newer firmware. Some time long ago, someone posted a very short C program that probes the LSI controller and spits out this kind of output: [root@d03]# amrstat Drive 0: 34.18 GB, RAID1 optimal Drive 1: 102.54 GB, RAID1 optimal This is the kind of output I'd love to get from my adaptec controllers, too. This can be trivially scripted and hooked into a monitoring system like nagios. The aaccli tool is a curses based app (despite the "cli" in the name) and scripting it is damn near impossible. It doesn't even read commands from stdin! --Apple-Mail-7-800990119-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 19:59:49 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FC4916A501 for ; Fri, 17 Nov 2006 19:59:49 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF0D343D45 for ; Fri, 17 Nov 2006 19:59:48 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kAHJxgb4028997; Fri, 17 Nov 2006 12:59:47 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <455E14AC.7070906@samsco.org> Date: Fri, 17 Nov 2006 12:59:40 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Vivek Khera References: <36FBC1D2-9F33-4EA1-B93D-EB4C2B1253E8@khera.org> <20061116003422.GC942@tigerfish2.my.domain> <35A2EF81-7D7B-4A8A-9101-5AEFEB3ED057@khera.org> In-Reply-To: <35A2EF81-7D7B-4A8A-9101-5AEFEB3ED057@khera.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: FreeBSD Stable Subject: Re: adaptec utilities on amd64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 19:59:49 -0000 Vivek Khera wrote: > > On Nov 15, 2006, at 7:34 PM, Bruce Burden wrote: > >> I have a 2230SLP that I will be installing early next week >> on my AMD64 implementation. I am hoping that the aaccli program >> in ports will work. > > If it has the newer firmware, it will not work with aaccli. If you got > the card after they switched to the "R" revision, you have the newer > firmware. > > Some time long ago, someone posted a very short C program that probes > the LSI controller and spits out this kind of output: > > [root@d03]# amrstat > Drive 0: 34.18 GB, RAID1 > optimal > Drive 1: 102.54 GB, RAID1 > optimal > > This is the kind of output I'd love to get from my adaptec controllers, > too. This can be trivially scripted and hooked into a monitoring system > like nagios. > > The aaccli tool is a curses based app (despite the "cli" in the name) > and scripting it is damn near impossible. It doesn't even read commands > from stdin! > Yes, scripting it is possible, and it does have a non-interactive mode. Try the following: printf "open aac0\ncontroller details\nexit\n" | aaccli Scott From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 20:05:50 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B83116A403 for ; Fri, 17 Nov 2006 20:05:50 +0000 (UTC) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [74.92.149.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6123A43D53 for ; Fri, 17 Nov 2006 20:05:45 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 85675B80A for ; Fri, 17 Nov 2006 15:05:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <455E14AC.7070906@samsco.org> References: <36FBC1D2-9F33-4EA1-B93D-EB4C2B1253E8@khera.org> <20061116003422.GC942@tigerfish2.my.domain> <35A2EF81-7D7B-4A8A-9101-5AEFEB3ED057@khera.org> <455E14AC.7070906@samsco.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-14-803149982; protocol="application/pkcs7-signature" Message-Id: <812670C6-9003-49EC-83CC-F6356C20430B@khera.org> From: Vivek Khera Date: Fri, 17 Nov 2006 15:05:43 -0500 To: FreeBSD Stable X-Mailer: Apple Mail (2.752.2) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: adaptec utilities on amd64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 20:05:50 -0000 --Apple-Mail-14-803149982 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 17, 2006, at 2:59 PM, Scott Long wrote: > Yes, scripting it is possible, and it does have a non-interactive > mode. > Try the following: > > printf "open aac0\ncontroller details\nexit\n" | aaccli > I stand corrected. Not sure why it failed so miserably when last I tested it. The output when redirected to a file still contains the curses junk in it, but that can be filtered out... --Apple-Mail-14-803149982-- From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 20:18:57 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDC1516A40F for ; Fri, 17 Nov 2006 20:18:57 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 761DC43D4C for ; Fri, 17 Nov 2006 20:18:57 +0000 (GMT) (envelope-from tom@tomjudge.com) Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1GlAAn-0000gF-K1; Fri, 17 Nov 2006 20:18:53 +0000 Received: from [82.43.34.109] (helo=[192.168.0.2]) by asmtp-out1.blueyonder.co.uk with esmtp (Exim 4.52) id 1GlAAm-0002w9-TX; Fri, 17 Nov 2006 20:18:52 +0000 Message-ID: <455E1AA8.6030900@tomjudge.com> Date: Fri, 17 Nov 2006 20:25:12 +0000 From: Tom Judge User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: Scott Long References: <36FBC1D2-9F33-4EA1-B93D-EB4C2B1253E8@khera.org> <20061116003422.GC942@tigerfish2.my.domain> <35A2EF81-7D7B-4A8A-9101-5AEFEB3ED057@khera.org> <455E14AC.7070906@samsco.org> In-Reply-To: <455E14AC.7070906@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Vivek Khera , FreeBSD Stable Subject: Re: adaptec utilities on amd64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 20:18:57 -0000 Scott Long wrote: > Vivek Khera wrote: >> Some time long ago, someone posted a very short C program that probes >> the LSI controller and spits out this kind of output: >> >> [root@d03]# amrstat >> Drive 0: 34.18 GB, RAID1 >> optimal >> Drive 1: 102.54 GB, RAID1 >> optimal >> >> This is the kind of output I'd love to get from my adaptec >> controllers, too. This can be trivially scripted and hooked into a >> monitoring system like nagios. >> >> The aaccli tool is a curses based app (despite the "cli" in the name) >> and scripting it is damn near impossible. It doesn't even read >> commands from stdin! >> > > Yes, scripting it is possible, and it does have a non-interactive mode. > Try the following: > > printf "open aac0\ncontroller details\nexit\n" | aaccli > I have been trying to find a similar solution for aac controllers that will display the status of the volumes that the controller has configured (E.g. Optimal, Degraded, Failed etc...). So far the only way I have found to do it is to store the output of: printf "open aac0\ncontainer list\nexit\n" | aaccli For a known good status and then periodiacly check the output of the above command with the same status. Is there a better way to do this? Tom From owner-freebsd-stable@FreeBSD.ORG Fri Nov 17 20:55:54 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F04B16A4D8 for ; Fri, 17 Nov 2006 20:55:54 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9517A43D5A for ; Fri, 17 Nov 2006 20:55:53 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.6/8.13.8) id kAHKtqPB030007; Fri, 17 Nov 2006 14:55:52 -0600 (CST) (envelope-from dan) Date: Fri, 17 Nov 2006 14:55:52 -0600 From: Dan Nelson To: Vivek Khera Message-ID: <20061117205552.GB7333@dan.emsphone.com> References: <36FBC1D2-9F33-4EA1-B93D-EB4C2B1253E8@khera.org> <20061116003422.GC942@tigerfish2.my.domain> <35A2EF81-7D7B-4A8A-9101-5AEFEB3ED057@khera.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35A2EF81-7D7B-4A8A-9101-5AEFEB3ED057@khera.org> X-OS: FreeBSD 6.2-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.13 (2006-08-11) Cc: FreeBSD Stable Subject: Re: adaptec utilities on amd64? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 20:55:54 -0000 In the last episode (Nov 17), Vivek Khera said: > On Nov 15, 2006, at 7:34 PM, Bruce Burden wrote: > > I have a 2230SLP that I will be installing early next week on > > my AMD64 implementation. I am hoping that the aaccli program in > > ports will work. > > If it has the newer firmware, it will not work with aaccli. If you > got the card after they switched to the "R" revision, you have the > newer firmware. > > Some time long ago, someone posted a very short C program that probes > the LSI controller and spits out this kind of output: > > [root@d03]# amrstat > Drive 0: 34.18 GB, RAID1 optimal > Drive 1: 102.54 GB, RAID1 optimal > > This is the kind of output I'd love to get from my adaptec > controllers, too. This can be trivially scripted and hooked into a > monitoring system like nagios. > > The aaccli tool is a curses based app (despite the "cli" in the name) > and scripting it is damn near impossible. It doesn't even read > commands from stdin! It's non-interactive if you pass it a commandline, though. I have a Big Brother script that does this (amongst other things): # Gather Data CONTROLLERS=$($AACCLI controller list | awk '/PERC/ { print $1 }') OUT_AAC="Controller list: $CONTROLLERS " CMD_AAC="task list /all : controller details : container list /full : disk list /full : disk show smart /full : enclosure list /full : enclosure show status" for c in $CONTROLLERS ; do OUT_AAC=$OUT_AAC$($AACCLI open /readonly $c : $CMD_AAC) done It then processes the contents of $OUT_AAC to determine if the array's happy or not. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Sat Nov 18 07:51:57 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39ACC16A6B8 for ; Sat, 18 Nov 2006 07:51:57 +0000 (UTC) (envelope-from freebsd-smp@epcdirect.co.uk) Received: from gunfright.epcdirect.co.uk (gunfright.epcdirect.co.uk [195.10.242.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E8AC44225 for ; Sat, 18 Nov 2006 04:11:41 +0000 (GMT) (envelope-from freebsd-smp@epcdirect.co.uk) Received: from lfarr (lfarr.adsl.gemsoft.co.uk [195.10.239.114]) by gunfright.epcdirect.co.uk (Postfix) with ESMTP id 869496C8807 for ; Fri, 17 Nov 2006 21:45:05 +0000 (GMT) From: "Lawrence Farr" To: Date: Fri, 17 Nov 2006 21:45:06 -0000 Message-ID: <029d01c70a91$a56b3230$c806a8c0@lfarr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <01b801c70a3a$8e486ac0$c806a8c0@lfarr> Thread-Index: AccKOWZadFBczA/KQAS6uUA9fMOyJwAAJrtgABXYtzA= Subject: RE: Areca Weirdness - UFS2 larger than 2Tb problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 07:51:57 -0000 > > > > > > > Re-posting to -STABLE as it also does it on i386. > > > > > > I reinstalled i386 stable as of yesterday, and newfs'd all > > the partitions > > > "just in case". I got it to crash while doing a mkdir on the areca > > > partition, so set up crash dumps on the boot drive (it > > boots off a single > > > ATA disk, the Areca is additional storage) and it died > again running > > > the periodic scripts last night. The info file from the > dump shows: > > > > > > Dump header from device /dev/ad0s1b > > > Architecture: i386 > > > Architecture Version: 2 > > > Dump Length: 2145452032B (2046 MB) > > > Blocksize: 512 > > > Dumptime: Thu Nov 16 03:01:09 2006 > > > Hostname: nas-2.shorewood-epc.co.uk > > > Magic: FreeBSD Kernel Dump > > > Version String: FreeBSD 6.1-20061115 #0: Wed Nov 15 > > 04:18:11 UTC 2006 > > > root@monitor.shorewood-epc.co.uk:/usr/obj/usr/src/sys/SMP > > > Panic String: ufs_dirbad: bad dir > > > Dump Parity: 632980830 > > > Bounds: 0 > > > Dump Status: good > > > > > > Am I expecting too much with partitions over 2Tb? I've > > never gone over > > > 2Tb before, so havent come across any issues like this. > > > > > >> -----Original Message----- > > >> From: owner-freebsd-amd64@freebsd.org > > >> [mailto:owner-freebsd-amd64@freebsd.org] On Behalf Of > Lawrence Farr > > >> Sent: 10 November 2006 11:39 > > >> To: freebsd-amd64@freebsd.org > > >> Subject: Areca Weirdness > > >> > > >> I've got an Areca 12 port card running a 6Tb array which > is divided > > >> into 2.1Tb chunks at the moment, as it was doing the same with a > > >> single 6Tb partition. > > >> > > >> ad0: 58644MB at ata0-master UDMA100 > > >> da0 at arcmsr0 bus 0 target 0 lun 0 > > >> da0: Fixed Direct Access SCSI-3 device > > >> da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), > > >> Tagged Queueing > > >> Enabled > > >> da0: 2224922MB (4556640256 512 byte sectors: 255H 63S/T 283637C) > > >> > > >> If I newfs it, and copy data to it, I have no problem initially. > > >> If I then try and copy the data on the disk already to a new > > >> folder, the machine reboots (it's a remote host with no serial > > >> attached currently). When it comes back to life, it mounts, and > > >> shows as: > > >> > > >> /dev/da0 2.1T 343G 1.6T 18% /usr/home/areca1 > > >> > > >> But is completely empty. Unmounting it and trying to fsck it > > >> errors, as does mounting it by hand. > > >> > > >> [root@nas-2 /home]# fsck -y /dev/da0 > > >> ** /dev/da0 > > >> Cannot find file system superblock > > >> ioctl (GCINFO): Inappropriate ioctl for device > > >> fsck_ufs: /dev/da0: can't read disk label > > >> [root@nas-2 /home]# mount /dev/da0 > > >> mount: /dev/da0 on /usr/home/areca1: incorrect super block > > >> > > >> Are there any known issues with the driver on AMD64? I had > > >> major issues with it on Linux/386 with large memory support > > >> (it would behave equally strangely) that went away when I > > >> took large memory support out, maybe there are some non 64 > > >> bit safe parts common to both? > > > > I have the Areca 8 port PCI-X card. 2 arrays of 1.25T each > > and no issues > > yet. I've been using it on 5.x for a year and now on 6.x it's > > perfect too. > > Have you updated the card to the latest firmware ? > > > > I've just done a test copy from the one volume to the other > > of 10 gigs. It > > ran at over 80M/s and tok under 2 minutes with no errors. > > > > Did you follow the instructions provided with the Areca card > > for creating > > volumes over 2TB ? There are some things you have to do so > > that the OS works > > correctly with it. > > > > -Clay > > I'm not convinced it's an Areca problem anymore, as I've copied > 300 or so Gb on now, but it will randomly corrupt the fs and > reboot itself. Background fsck will not fix it, but a manual one > does. I'm going to drop the partitions below 2Tb and try the test > again to try and eliminate any hardware/driver issues. This has now paniced while idle, and with only a 1.8Tb fs mounted. Didn't get a core, but got this: Nov 17 19:43:39 nas-2 savecore: reboot after panic: ffs_valloc: dup alloc Nov 17 19:43:39 nas-2 savecore: no dump, not enough free space on device (661322 available, need 2095170) Nov 17 19:43:39 nas-2 savecore: unsaved dumps found but not saved Anyone got any ideas where to start looking? From owner-freebsd-stable@FreeBSD.ORG Sat Nov 18 08:42:09 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A841F16A407 for ; Sat, 18 Nov 2006 08:42:09 +0000 (UTC) (envelope-from f.fillon@lineaweb.fr) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3A5543D66 for ; Sat, 18 Nov 2006 08:42:03 +0000 (GMT) (envelope-from f.fillon@lineaweb.fr) Received: from lineawebp001 (maa78-1-82-228-2-240.fbx.proxad.net [82.228.2.240]) by smtp4-g19.free.fr (Postfix) with ESMTP id AC91988EB for ; Sat, 18 Nov 2006 09:42:04 +0100 (CET) From: =?iso-8859-1?Q?Fr=E9d=E9ric_Fillon?= To: Date: Sat, 18 Nov 2006 09:42:12 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AccK7XAhbifnSMmzSXmw0yzcOOYk1Q== Message-Id: <20061118084204.AC91988EB@smtp4-g19.free.fr> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem with download of 6.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 08:42:09 -0000 Hi, =20 I=92ve tried to download 6.2 RC1 version but it doesn=92t work. When I = try to click on one of the link, the result is =93unavailable page=94. =20 What should I do ? (I=92m trying with www.freebsd.org ). =20 Regards =20 Fr=E9d=E9ric Fillon From owner-freebsd-stable@FreeBSD.ORG Sat Nov 18 10:05:35 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D63D516A501 for ; Sat, 18 Nov 2006 10:05:35 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52DBE43DAE for ; Sat, 18 Nov 2006 10:05:03 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id kAIA4uos044957; Sat, 18 Nov 2006 11:04:58 +0100 (CET) (envelope-from mb@imp.ch) Date: Sat, 18 Nov 2006 11:04:56 +0100 (CET) From: Martin Blapp To: Scott Long In-Reply-To: <455DF4A2.2010805@samsco.org> Message-ID: <20061118110337.S13782@godot.imp.ch> References: <6eb82e0611170814w55814f96wcbf8be80f7a621fa@mail.gmail.com> <455DF4A2.2010805@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.58 on 157.161.9.65 Cc: stable@freebsd.org, Rong-en Fan Subject: Re: ips(4) in toaster mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 10:05:35 -0000 Hi, >> Also, the only harddisk on that host is the ips(4), so I can not obtain >> a kernel dump. I'm not sure if this is a hardware failure, at least, no >> led on the panel is shown red... Hmm ? We do kernel dumps on ips(4) and it works. dumpdev="/dev/ipsd0s1b" Martin From owner-freebsd-stable@FreeBSD.ORG Sat Nov 18 10:09:08 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89DD416A403 for ; Sat, 18 Nov 2006 10:09:08 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85D2B43D72 for ; Sat, 18 Nov 2006 10:08:57 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 702EC1A3C1E; Sat, 18 Nov 2006 02:08:59 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 571E851540; Sat, 18 Nov 2006 05:08:46 -0500 (EST) Date: Sat, 18 Nov 2006 05:08:45 -0500 From: Kris Kennaway To: Fr?d?ric Fillon Message-ID: <20061118100845.GA18274@xor.obsecurity.org> References: <20061118084204.AC91988EB@smtp4-g19.free.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <20061118084204.AC91988EB@smtp4-g19.free.fr> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: Problem with download of 6.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 10:09:08 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 18, 2006 at 09:42:12AM +0100, Fr?d?ric Fillon wrote: > Hi, >=20 > =20 >=20 > I?ve tried to download 6.2 RC1 version but it doesn?t work. When I try to > click on one of the link, the result is ?unavailable page?. >=20 > =20 >=20 > What should I do ? (I?m trying with www.freebsd.org > ). Try again now that the website is fully operational again after moving loca= tion ;-) Kris --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFXtutWry0BWjoQKURAmpLAKDij44fsLrz/RRI47oFavS2dsXeWgCfWAfp ufTC5S1MDRJb7M7aJlNZApc= =eyIi -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 18 12:34:45 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C61B916A407 for ; Sat, 18 Nov 2006 12:34:45 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6585443D49 for ; Sat, 18 Nov 2006 12:34:42 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so674864nzh for ; Sat, 18 Nov 2006 04:34:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EL/iTYBvCfGJG19AaFoTMq0mDrU/pCfwMyfXJq9Mz3QPljlCHysDmatxZk1AXRlZZjHoQ06McS78fPQQp0xtdpjli3OY/CrQc3xd6hkfUuQ5A2yqvrEyXcHYkaNdo0nRXJ+IFnOgOzbTfAf53wYtidIHx5EsajFWqGxrjPfYIdo= Received: by 10.65.250.11 with SMTP id c11mr4495276qbs.1163853284477; Sat, 18 Nov 2006 04:34:44 -0800 (PST) Received: by 10.65.220.18 with HTTP; Sat, 18 Nov 2006 04:34:44 -0800 (PST) Message-ID: <6eb82e0611180434u74902363pc79b2cb03ae5fbd4@mail.gmail.com> Date: Sat, 18 Nov 2006 20:34:44 +0800 From: "Rong-en Fan" To: "Martin Blapp" In-Reply-To: <20061118110337.S13782@godot.imp.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0611170814w55814f96wcbf8be80f7a621fa@mail.gmail.com> <455DF4A2.2010805@samsco.org> <20061118110337.S13782@godot.imp.ch> Cc: stable@freebsd.org Subject: Re: ips(4) in toaster mode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 12:34:45 -0000 On 11/18/06, Martin Blapp wrote: > > Hi, > > >> Also, the only harddisk on that host is the ips(4), so I can not obtain > >> a kernel dump. I'm not sure if this is a hardware failure, at least, no > >> led on the panel is shown red... > > Hmm ? We do kernel dumps on ips(4) and it works. > > dumpdev="/dev/ipsd0s1b" > > Martin ips(4) can do kernel dump, but in my case above, ips(4) is already command timeout mode... Regards, Rong-En Fan From owner-freebsd-stable@FreeBSD.ORG Sat Nov 18 18:19:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D82D16A407 for ; Sat, 18 Nov 2006 18:19:44 +0000 (UTC) (envelope-from vincent@xtra-net.org) Received: from ns1.xtra-net.be (ns1.xtra-net.be [195.162.200.90]) by mx1.FreeBSD.org (Postfix) with SMTP id CE89B43D70 for ; Sat, 18 Nov 2006 18:19:32 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 19104 invoked from network); 18 Nov 2006 18:19:35 -0000 Received: from unknown (HELO sbepfkaa.srv.xtra-net.be) (172.16.66.66) by 0 with SMTP; 18 Nov 2006 18:19:35 -0000 Received: (qmail 29374 invoked from network); 18 Nov 2006 18:18:53 -0000 Received: from wbedllfs.intranet.xtra-net.be (HELO wbemfkaa.net.xtra-net.be) (172.16.66.1) by 0 with SMTP; 18 Nov 2006 18:18:53 -0000 From: Vincent Blondel To: freebsd-stable@freebsd.org In-Reply-To: <20061117223140.GA13858@xor.obsecurity.org> References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> <20061116161706.GB65054@xor.obsecurity.org> <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> <20061116210151.GA68673@xor.obsecurity.org> <1163712849.8157.5.camel@wbemfkaa.net.xtra-net.be> <20061116214237.GA69412@xor.obsecurity.org> <1163780080.2697.6.camel@wbemfkaa.net.xtra-net.be> <20061117223140.GA13858@xor.obsecurity.org> Content-Type: text/plain Date: Sat, 18 Nov 2006 19:19:02 +0100 Message-Id: <1163873942.3315.12.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: vincent@xtra-net.org, kris@obsecurity.org Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 18:19:44 -0000 On Fri, 2006-11-17 at 17:31 -0500, Kris Kennaway wrote: > On Fri, Nov 17, 2006 at 05:14:40PM +0100, Vincent Blondel wrote: > > > > I'm not sure about the cause though, does it happen every time you run > > > mailwrapper, or only under load? > > > > sendmail_enable is defined to "NONE" so I can suppose I do not use > > mailwrapper. > > > > How can I know it > > You are clearly running it, because of: > > > > > Unread portion of the kernel message buffer: > > > > x0, limit 0xfffff, type 0x1b > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > > current process = 14294 (mailwrapper) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > If you don't know about mailwrapper running, that suggests you're not > using the system for email processing and it's the nightly admin > scripts which are sending mail automatically overnight. No I just forgot the existence of mailwrapper but as I said it in my last mail /etc/mail/mailer.conf points to /var/qmail/bin/sendmail on my machine because qmail is serving SMTP on my web server. Concerning nightly scripts, I receive them in my mailbox every day/week/month. > > I suspect that your mailwrapper executable may be corrupt. The kernel > is supposed to handle this, but you might have discovered a new and > better way to corrupt a binary to get it past the existing checks :-) Do not forget my original post concerned a kernel panic on process httpd so maybe problem does not come from mailwrapper ? > > Try to send an email to e.g. root on the system and see if it triggers > the crash. "echo Hello |mailx -s "Hello" root" works perfectly. > > If it does, then save a copy of the mailwrapper binary (i.e. don't > immediately "fix" it by reinstalling) and make it available so we can > see what is wrong with it. but I still get a new crash this morning at 09h20 AM and when I try to get kgdb running I get hundreds of lines with this ... kgdb: kvm_read: invalid address (0x0) ... > > Kris Vincent From owner-freebsd-stable@FreeBSD.ORG Sat Nov 18 18:33:35 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C51AD16A4FD for ; Sat, 18 Nov 2006 18:33:35 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from slimak.dkm.cz (slimak.dkm.cz [62.24.64.34]) by mx1.FreeBSD.org (Postfix) with SMTP id 28D5F43D5D for ; Sat, 18 Nov 2006 18:32:33 +0000 (GMT) (envelope-from 000.fbsd@quip.cz) Received: (qmail 91246 invoked by uid 0); 18 Nov 2006 18:32:36 -0000 Received: from grimm.quip.cz (HELO ?192.168.1.2?) (213.220.192.218) by slimak.dkm.cz with SMTP; 18 Nov 2006 18:32:35 -0000 Message-ID: <455F51BA.2090607@quip.cz> Date: Sat, 18 Nov 2006 19:32:26 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <15af975d0609212321r29fdd287p462ae0f2b7e404b4@mail.gmail.com> <15af975d0609220725s1206d7ebr53589adbc1b9c17@mail.gmail.com> <4513F5B0.9030300@goodforbusiness.co.uk> <200609261305.12224.jhb@freebsd.org> <451A3E33.8010805@goodforbusiness.co.uk> <45382F43.6020509@FreeBSD.org> In-Reply-To: <45382F43.6020509@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bruce M. Simpson" Subject: Re: bug on BTX X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 18:33:35 -0000 Hi all, Bruce M. Simpson wrote: > It would be a good thing to solve the real mode problem, as it would > enable FreeBSD to be booted from memory stick, USB CDROM, and within > QEMU without resorting to the current workarounds e.g. using GRUB or > skipping /boot/loader entirely to boot the kernel directly as I > currently do in QEMU virtualization. [...] > Indeed I recently ran into this myself. Certain 1U machines which I > acquired had problems booting from USB CDROM. I traced this back to the > USB BIOS trying to LGDT and causing a general protection fault in vm86 > mode. I worked around this by PXE booting them on a private VLAN with > most helpful assistance from dwhite@. [...] Is there any progress in fixing FreeBSD bootloader to be able to boot from USB devices? Any patches available which can I test? Or are there any possible workaround to make FreeBSD bootable from USB flashdrive in any machine? (I can boot from USB flashdrive and USB DVD-RW on my home PC and notebook, but can not boot HP DL140 and Sun Fire X2100 servers ;[) Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Sat Nov 18 19:47:25 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0162916A53F for ; Sat, 18 Nov 2006 19:47:25 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D14D43D46 for ; Sat, 18 Nov 2006 19:46:06 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 7F5FC1A3C1E; Sat, 18 Nov 2006 11:46:00 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A3A90513A1; Sat, 18 Nov 2006 14:45:47 -0500 (EST) Date: Sat, 18 Nov 2006 14:45:47 -0500 From: Kris Kennaway To: Vincent Blondel Message-ID: <20061118194547.GB40675@xor.obsecurity.org> References: <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> <20061116161706.GB65054@xor.obsecurity.org> <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> <20061116210151.GA68673@xor.obsecurity.org> <1163712849.8157.5.camel@wbemfkaa.net.xtra-net.be> <20061116214237.GA69412@xor.obsecurity.org> <1163780080.2697.6.camel@wbemfkaa.net.xtra-net.be> <20061117223140.GA13858@xor.obsecurity.org> <1163873942.3315.12.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: <1163873942.3315.12.camel@wbemfkaa.net.xtra-net.be> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org, kris@obsecurity.org Subject: Re: kernel crash ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 19:47:25 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 18, 2006 at 07:19:02PM +0100, Vincent Blondel wrote: > > If you don't know about mailwrapper running, that suggests you're not > > using the system for email processing and it's the nightly admin > > scripts which are sending mail automatically overnight. >=20 > No I just forgot the existence of mailwrapper but as I said it in my > last mail /etc/mail/mailer.conf points to /var/qmail/bin/sendmail on my > machine because qmail is serving SMTP on my web server. OK. > Concerning nightly scripts, I receive them in my mailbox every > day/week/month. >=20 > >=20 > > I suspect that your mailwrapper executable may be corrupt. The kernel > > is supposed to handle this, but you might have discovered a new and > > better way to corrupt a binary to get it past the existing checks :-) >=20 > Do not forget my original post concerned a kernel panic on process httpd > so maybe problem does not come from mailwrapper ? I did forget because it got trimmed somehow :-) > > If it does, then save a copy of the mailwrapper binary (i.e. don't > > immediately "fix" it by reinstalling) and make it available so we can > > see what is wrong with it. >=20 > but I still get a new crash this morning at 09h20 AM and when I try to > get kgdb running I get hundreds of lines with this ... >=20 > kgdb: kvm_read: invalid address (0x0) > ... This means you are running it against the wrong kernel. Kris --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFX2LrWry0BWjoQKURAh5XAKCHAo5gzwiEaAG/LpFjU8ExHEn95wCfQniS TPoo7sRuhQddOu6e9zRrXlw= =mZzI -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC-- From owner-freebsd-stable@FreeBSD.ORG Sat Nov 18 21:09:16 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 205E516A51C for ; Sat, 18 Nov 2006 21:09:16 +0000 (UTC) (envelope-from eti@erata.net) Received: from s1.net-solution.ro (s1.net-solution.ro [65.98.58.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1064843DA2 for ; Sat, 18 Nov 2006 21:08:45 +0000 (GMT) (envelope-from eti@erata.net) Received: (qmail 4162 invoked from network); 18 Nov 2006 23:08:51 +0200 Received: from 223.126.77.82.static.cluj.rdsnet.ro (HELO toshiba) (82.77.126.223) by s1.net-solution.ro with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Nov 2006 23:08:51 +0200 From: Iulian M Organization: www.erata.net To: eol1@yahoo.com Date: Sat, 18 Nov 2006 23:08:38 +0200 User-Agent: KMail/1.9.4 References: <20061118203919.44425.qmail@web51913.mail.yahoo.com> In-Reply-To: <20061118203919.44425.qmail@web51913.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611182308.40346.eti@erata.net> Cc: freebsd-stable@freebsd.org Subject: Re: GELI + sync issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 21:09:16 -0000 On Saturday 18 November 2006 22:39, Peter Thoenen wrote: > yep ... > > make buildworld > make buildkernel > make installkernel > make installworld I thought so ... now another question ... using GELI on new drive works ? If it does something is fishy with your partition ... corrupt metadata, disk failure ... if it does not work on a new drive (or partition) and you have a recent version of STABLE and you are sure it's not bad hardware causing surprises then the problem might be someware in the GELI implementation on your environment. -- Best Regards, Iulian Margarintescu http://www.erata.net eti@erata.net (spamassassin & pf & spamd all said it's OK to make it public ;-) ) Key ID: 0x03176E5CEDEFF7AB I prefer plain text email From owner-freebsd-stable@FreeBSD.ORG Sat Nov 18 21:26:16 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32C3516A407 for ; Sat, 18 Nov 2006 21:26:16 +0000 (UTC) (envelope-from lopisaur@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91A8943D6A for ; Sat, 18 Nov 2006 21:25:59 +0000 (GMT) (envelope-from lopisaur@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so1451315nfc for ; Sat, 18 Nov 2006 13:26:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=gNuql3r3YtEQ+fxaw6HgFJhWoWivWnfAXoFqVcYs6skygJ7Z5j6M9xCfqIPf5ZF0csMFd6JuM45no0RN/kPecZHRD6k3ly1JoqasxQ6I3akwngGp1Y34G5+VkXePHZ7af0ESZyo3lTbpWyJwQUiDHdM1QLe/jqEl7FY26+gogYY= Received: by 10.49.1.12 with SMTP id d12mr4233944nfi.1163885164021; Sat, 18 Nov 2006 13:26:04 -0800 (PST) Received: from ?192.168.1.33? ( [84.63.100.239]) by mx.google.com with ESMTP id x24sm16259859nfb.2006.11.18.13.26.02; Sat, 18 Nov 2006 13:26:03 -0800 (PST) From: Christian Lopez de Castilla Wagner To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Sat, 18 Nov 2006 22:26:08 +0100 Message-Id: <1163885169.6558.39.camel@resurrection> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Subject: Status of 3945ABG and others X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lopisaur@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 21:26:16 -0000 Hi guys, I don't know if any of you remember, I asked about some laptops a few months back. Anyway, I got a Toshiba Tecra A6, moved halfway across the planet and at the moment (especially since I can't afford to build myself a REAL machine right now) I really, really miss my FreeBSD. It's running that OS with the L-word right now, since FreeBSD wouldn give me sound nor network. I was wondering if there was any hope in sight for me? Sound is ALC861, wireless 3945ABG. I never got around to test the wired ethernet (Intel PRO/1000, should work, right?). I didn't even bother trying out X.org, because it should work (it's an i945GM). I really can't do without network and sound... 6.1 installs wonderfully, except for the stuff above. I don care about the fingerprint stuff, card reader, etc. -- Christian Lopez de Castilla Wagner lopisaur@gmail.com clopez@uni-koblenz.de (+49-173)1030695 PGP Keys: 98FC0D41 483EA9B6 (Old)