From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 00:42:15 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35FD816A421; Sun, 3 Feb 2008 00:42:15 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9D95A13C458; Sun, 3 Feb 2008 00:42:14 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id m1304qiD034827; Sun, 3 Feb 2008 03:04:52 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 3 Feb 2008 03:04:52 +0300 (MSK) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Message-ID: <20080203030205.T28725@woozle.rinet.ru> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Sun, 03 Feb 2008 03:04:52 +0300 (MSK) Cc: sos@FreeBSD.org Subject: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk 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, 03 Feb 2008 00:42:15 -0000 Dear colleagues, during rsycn from eSATA drive connected to Promise TX4 (ad12) to ZFS pool eSATA disk got disconnected. With the next access, system crashed: Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x3020e0b30 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff801cac9d stack pointer = 0x10:0xffffffffd79f7800 frame pointer = 0x10:0xffffffffd79f7840 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 898 (tcsh) trap number = 12 panic: page fault cpuid = 1 Uptime: 7h49m35s Physical memory: 4087 MB Dumping 677 MB: 662 646 630 614 598 582 566 550 534 518 502 486 470 454 438 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 #0 doadump () at pcpu.h:194 194 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:194 #1 0x0000000000000031 in ?? () #2 0xffffffff80219c30 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0xffffffff8021a04d in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0xffffffff80353284 in trap_fatal (frame=0xffffff000179c340, eva=18446742974222725120) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0xffffffff80353655 in trap_pfault (frame=0xffffffffd79f7750, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 #6 0xffffffff80353ffb in trap (frame=0xffffffffd79f7750) at /usr/src/sys/amd64/amd64/trap.c:410 #7 0xffffffff80339dbe in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #8 0xffffffff801cac9d in dev2udev (x=0xffffff0001779400) at /usr/src/sys/fs/devfs/devfs_vnops.c:1325 #9 0xffffffff80310ab8 in ufs_getattr (ap=Variable "ap" is not available. ) at /usr/src/sys/ufs/ufs/ufs_vnops.c:401 #10 0xffffffff8029dcf3 in vn_stat (vp=0xffffff004728b9b0, sb=0xffffffffd79f79f0, active_cred=Variable "active_cred" is not available. ) at vnode_if.h:286 #11 0xffffffff802953b1 in kern_stat (td=0xffffff000179c340, path=0x44b66a
, pathseg=Variable "pathseg" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2112 #12 0xffffffff80295507 in stat (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2093 #13 0xffffffff803538da in syscall (frame=0xffffffffd79f7c70) at /usr/src/sys/amd64/amd64/trap.c:852 #14 0xffffffff80339fcb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:290 #15 0x00000000809c235c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) I would be glad to provide additional info to investigate and hopefully fix the problem. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 01:01:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15FD616A417 for ; Sun, 3 Feb 2008 01:01:06 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id C189013C447 for ; Sun, 3 Feb 2008 01:01:05 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so468999anc.13 for ; Sat, 02 Feb 2008 17:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=OdMXD8+amQhAX3+p/pLFln55N50jAYJTrai7zLh9w/I=; b=EfIm731UdELu+Zets8OVLhbxOBsi7deMQlRzGAn4bCJBwUwrXZx1aThMM/0w4aI4LjMZYJg4tseYpiIKeyrZgjfE1vnE8wro0pP4h+MhJZeNFWjjTAICmjwlYj7NMf0/d8RsaKowzG4eAJgqzk/JrU9mZOMo0plMcE52hyvCt30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=i5F2ZWOmpqBjZcBWeegHS3POtcEm9j57by9U7IqGgS77+H7393xfldOaDfdNRSwLQldQzU21xZkJpcNOwlOZsDx1Cs2YX3jf5XHpVcdJtB+eiWY8yw39YHA1BezP2v7RIcf2h1vgTXdluhKVWRWTHI8++u1kzKlsQd1crRQUTeY= Received: by 10.100.216.3 with SMTP id o3mr11177927ang.95.1202000464739; Sat, 02 Feb 2008 17:01:04 -0800 (PST) Received: from ?10.0.3.231? ( [70.111.176.151]) by mx.google.com with ESMTPS id o61sm12728529hsc.10.2008.02.02.17.01.03 (version=SSLv3 cipher=RC4-MD5); Sat, 02 Feb 2008 17:01:04 -0800 (PST) From: "Alexandre \"Sunny\" Kovalenko" To: Danny Pansters In-Reply-To: <200802011526.23000.danny@ricin.com> References: <47A0B642.9060000@icyb.net.ua> <47A1C198.6090802@icyb.net.ua> <47A1E3D5.6040301@icyb.net.ua> <200802011526.23000.danny@ricin.com> Content-Type: text/plain; charset=utf-8 Date: Sat, 02 Feb 2008 20:00:58 -0500 Message-Id: <1202000458.894.9.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: kld regression 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, 03 Feb 2008 01:01:06 -0000 On Fri, 2008-02-01 at 15:26 +0100, Danny Pansters wrote: > On Thursday 31 January 2008 16:05:57 Andriy Gapon wrote: > > on 31/01/2008 14:39 Andriy Gapon said the following: > > > on 31/01/2008 13:07 John Baldwin said the following: > > >> On Wednesday 30 January 2008 12:39:14 pm Andriy Gapon wrote: > > >>> The problem is as follows: > > >>> 1. put udf_load="YES" in loader.conf > > >>> 2. you can mount and unmount udf filesystems > > >>> 3. you can kldunload udf if no udf filesystems are mounted > > >>> 4. now mount udf fs while udf.ko is unloaded > > >>> 5. udf is auto loaded and fs is mounted > > >>> 6. unmount fs > > >>> 7. try to kldunload udf > > >>> kldunload: can't unload file: Device busy > > >>> kernel message: kldunload: attempt to unload file that was loaded by > > >>> the kernel > > >>> > > >>> Yeah, it was loaded by kernel indeed, but WTF - what is the difference > > >>> from manual/loader.conf loading and why I can not manage my modules as > > >>> I wish? > > >> > > >> Hmm, the relevant code (vfs_init.c) hasn't changed in 6.x since 6.0. > > >> There were some changes in 7.0, but this should work in both branches. > > >> What is the previous release that this worked on? > > > > > > Maybe I was wrong when I called this regression, but this was very > > > surprising behavior for me. And in 5.X I did a lot of udf > > > debugging/experimenting and never encountered such a problem. Maybe I > > > always did kldload before mount, I can't tell now. > > > Anyway, this seems like an annoyance at the very least, pinning a kernel > > > module without any important reasons. > > > > Hmm, I found one difference with previous setups: in step 1 I also have > > udf_iconv_load="YES" and udf_iconv.ko module is what seems to prevent > > udf.ko from unloading in step 7. I can actually unload udf_iconv and > > then I am able again to unload udf. > > > > Still don't understand what is a big difference here. > > > > And if I had UDF_ICONV built into kernel then I wouldn't have this > > work-around. > > The way I understand it, there are two different things: > > 1. kldload will load "child" modules on demand, but kldunload does not attempt > to unload any other modules than the one you ask for. I don't think it's > material whether the kldload was done via the loader (before the kernel kmod > gets loaded, kernel is also a kmod), or after. It's also possible to have > modules who need to access the filesystem (other than /boot partition) when > kldloaded, and such modules can obviously not be loaded via the loader at > all. > > 2. There may be modules (such as bktr) that allocate memory in kernel space. > These can not be unloaded, because that memory may not be deallocated while > the kernel is up and running (the latter is my assumption). > > Anyhow, unless you're very tight on RAM, it hardly matters if you have some > kmods loaded but left unused. Kmods are small, typically 10-100 kB. I have two reasons for wanting to unload modules, neither have anything to do with the memory consumption: 1. hw.pci.do_power_nodriver setting allows me not to power up bits and pieces, resulting in longer battery life. I would really like to unload unneeded modules when I am taking laptop away from my desk where I have USB and Firewire peripherals and power supply. 2. usb.ko effectively prevents CPU from going into C3 state, which, again, negatively impacts battery life. For both of these reasons, I tend to reboot my laptop when I am planning on working away from my desk for prolonged time. > > If all your kmods are built into the kernel, you have the footprint of all of > them and you can't disable any at runtime. > > Feel free to correct me, anyone, if you think the above is not correct or > complete. > > Dan > _______________________________________________ > 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" -- Alexandre "Sunny" Kovalenko (Олександр Коваленко) From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 01:12:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5188216A41B; Sun, 3 Feb 2008 01:12:29 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtp4.poczta.interia.pl (smtp35.poczta.interia.pl [80.48.65.35]) by mx1.freebsd.org (Postfix) with ESMTP id 958D413C45D; Sun, 3 Feb 2008 01:12:28 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: by smtp4.poczta.interia.pl (INTERIA.PL, from userid 502) id 7CDFE41E140; Sun, 3 Feb 2008 01:44:59 +0100 (CET) Received: from f48.poczta.interia.pl (f48.poczta.interia.pl [10.217.2.48]) by smtp4.poczta.interia.pl (INTERIA.PL) with ESMTP id 0772C41D5A3; Sun, 3 Feb 2008 01:44:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by f48.poczta.interia.pl (Postfix) with ESMTP id 00EC7313C96; Sun, 3 Feb 2008 01:44:58 +0100 (CET) Date: 03 Feb 2008 01:44:58 +0100 From: vermaden To: freebsd-x11@freebsd.org, freebsd-drivers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=ISO-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE X-ORIGINATE-IP: 85.89.167.26 IMPORTANCE: Normal X-MSMAIL-PRIORITY: Normal X-PRIORITY: 3 X-Mailer: PSE3 Message-Id: <20080203004459.00EC7313C96@f48.poczta.interia.pl> X-EMID: 24b40acc Cc: Subject: Intel G965 / x3000 does not work 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, 03 Feb 2008 01:12:29 -0000 Hi, the subject tells it all, I cannot start x11 with intel drivers=0A=0AFr= eeBSD 7.0-RC1 (nothing changed, just installed from CD)=0A=0Athen I just ad= ded x11 by pkg_add -r xorg removed video-i810 driver=0Apackage and added vi= deo-intel driver also by pkg_add -r ...=0A=0Aall other configuration is bel= ow, along with errors=0A=0A=0A/var/log/Xorg.0.log --> http://pastebin.com/m= 2223621f=0A=0A%cat /etc/hosts=0A::1 localhost vermaden vermaden= .go.pl=0A128.0.0.1 localhost vermaden vermaden.go.pl=0A=0A%cat /etc/r= c.conf=0A=0Afont8x14=3D"iso02-8x14"=0Afont8x16=3D"iso02-8x16"=0Afont8x8=3D"= iso02-8x8"=0Akeymap=3D"pl_PL.ISO8859-2"=0Akeyrate=3D"fast"=0Alinux_enable= =3D"YES"=0Amoused_enable=3D"YES"=0A=0Aifconfig_re0=3D"DHCP"=0Asshd_enable= =3D"YES"=0Ahostname=3D"vermaden.go.pl"=0A=0A%kldstat=0AId Refs Address S= ize Name=0A 1 14 0xc0400000 926ed4 kernel=0A 2 1 0xc0d27000 6a1c= 4 acpi.ko=0A 3 1 0xc5698000 22000 linux.ko=0A34 1 0xc5de4000 13= 000 snd_hda.ko=0A35 1 0xc5eb0000 3f000 sound.ko=0A36 1 0xc72090= 00 6000 i915.ko=0A37 1 0xc720f000 f000 drm.ko=0A=0A%xinit=0A=0A= =0AX.Org X Server 1.4.0=0ARelease Date: 5 September 2007=0AX Protocol Versi= on 11, Revision 0=0ABuild Operating System: FreeBSD 7.0-RELEASE i386=0ACurr= ent Operating System: FreeBSD vermaden.go.pl 7.0-RC1 FreeBSD 7.0-RC1 #0: Mo= n=0A Dec 24 12:18:24 UTC 2007 root@logan.cse.buffalo.edu:/usr/obj/usr/s= rc/sys/GE=0ANERIC i386=0ABuild Date: 08 December 2007 03:38:37PM=0A=0A = Before reporting problems, check http://wiki.x.org=0A to make su= re that you have the latest version.=0AModule Loader present=0AMarkers: (--= ) probed, (**) from config file, (=3D=3D) default setting,=0A (++) f= rom command line, (!!) notice, (II) informational,=0A (WW) warning, = (EE) error, (NI) not implemented, (??) unknown.=0A(=3D=3D) Log file: "/var/= log/Xorg.0.log", Time: Sat Feb 2 19:22:57 2008=0A(=3D=3D) Using config fil= e: "/etc/X11/xorg.conf"=0A(II) Module "ddc" already built-in=0A(II) Module = "i2c" already built-in=0A(II) Module "ramdac" already built-in=0A(EE) GARTI= nit: Unable to open /dev/agpgart (No such file or directory)=0A(EE) intel(0= ): Failed to allocate framebuffer. Is your VideoRAM set too low?=0A(EE) int= el(0): Failed to allocate framebuffer. Is your VideoRAM set too low?=0A(EE)= intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low?=0A= (EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low= ?=0A(EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too= low?=0A(EE) intel(0): Couldn't allocate video memory=0A=0AFatal server err= or:=0AAddScreen/ScreenInit failed for driver 0=0A=0AXIO: fatal IO error 53= (Software caused connection abort) on X server ":0.0"=0A after 0 requ= ests (0 known processed) with 0 events remaining.=0A=0A%cat /etc/X11/xorg.c= onf=0ASection "ServerLayout"=0A Identifier "X.org Configured"=0A= Screen 0 "Screen0" 0 0=0A InputDevice "Mouse0" "Cor= ePointer"=0A InputDevice "Keyboard0" "CoreKeyboard"=0AEndSection= =0A=0ASection "Files"=0A RgbPath "/usr/local/share/X11/rgb"=0A = ModulePath "/usr/local/lib/xorg/modules"=0AEndSection=0A=0ASection= "Module"=0A Load "dbe"=0A Load "dri"=0A Load "extm= od"=0A Load "glx"=0AEndSection=0A=0ASection "InputDevice"=0A = Identifier "Keyboard0"=0A Driver "kbd"=0AEndSection=0A=0ASect= ion "InputDevice"=0A Identifier "Mouse0"=0A Driver "mou= se"=0A Option "Protocol" "auto"=0A Option "Device" = "/dev/sysmouse"=0A Option "ZAxisMapping" "4 5 6 7"=0AEndSection= =0A=0ASection "Monitor"=0A Identifier "Monitor0"=0A HorizSy= nc 30.0 - 110.0=0A VertRefresh 48.0 - 170.0=0A Option = "DPMS"=0AEndSection=0A=0ASection "Device"=0A Identifier "Card0"= =0A Driver "intel"=0AEndSection=0A=0ASection "Screen"=0A = Identifier "Screen0"=0A Device "Card0"=0A Monitor "Mo= nitor0"=0A DefaultDepth 24=0A SubSection "Display"=0A = Modes "1280x1240"=0A EndSubSection=0AEndSection=0A=0A=0AThanks i= n advance=0A=0ARegards=0Avermaden ---------------------------------------------------------------------- Zmus swojego faceta, zeby to przeczytal Kliknij >>> http://link.interia.pl/f1ceb From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 03:17:26 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EEC716A417 for ; Sun, 3 Feb 2008 03:17:26 +0000 (UTC) (envelope-from umarsani7@gmail.com) Received: from wombat.diezmil.com (wombat.diezmil.com [209.190.27.106]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4AA13C458 for ; Sun, 3 Feb 2008 03:17:26 +0000 (UTC) (envelope-from umarsani7@gmail.com) Received: from wombat.diezmil.com (wombat.diezmil.com [127.0.0.1]) by wombat.diezmil.com (8.13.8/8.13.8) with ESMTP id m133HPrA009881 for ; Sat, 2 Feb 2008 22:17:25 -0500 Date: Sat, 2 Feb 2008 22:17:25 -0500 Message-ID: <4948690.1202008645711.JavaMail.root@wombat.diezmil.com> From: umarsani7@gmail.com To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: PINJAMAN TANPA AGUNAN 8-125 JT..GRATIS..TANPA PROVISI/ADM 3%..dr HSBC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: umarsani7@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2008 03:17:26 -0000 DAPATKAN PINJAMAN TANPA AGUNAN DENGAN PERSYARATAN YANG MUDAH,PROSES YANG CEPAT, DAN FASILTAS BERUPA BEBAS PROVISI/ADM 3% UNTUK PINJAMAN 15.000.000 - 19.000.000 DENGAN TENOR/MASA PELUNASAN 24 BULAN DAN PINJAMAN >=20.000.000,- DENGAN TENOR 36 BULAN. PROSES VERIFIKASI HINGGA PENCAIRAN 5-7 HARI KERJA. dr HSBC DOCUMENT YANG DIBUTUHKAN : 1.FC KTP 2.FC.CREDIT CARD DAN BILLING 1 BULAN TERAKHIR 3.FC.NO REK.TABUNGAN(SEBAGAI TEMPAT TRANSFER BILA DI SETUJUI) 4.MATERAI Rp.6.000,- 1 BH. 5.FC.NPWP (untuk pinjaman diatas Rp.50 juta ) UTK KETERANGAN HUB: UMAR 0813-19288679 0859-21346503 or umarsani7@gmail.com PERHITUNGAN BUNGA/BULAN TENOR Jml.Pinjaman 12 bulan 24 bulan 36 bulan 8.000.000 - 14.999.999 2 %. 2 %. - 15.000.000 - 125.000.000 1.72% 1.80 %. 1.95 %. TABEL ANGSURAN PINJAMAN 1 TAHUN 2 TAHUN 3 TAHUN 8,000,000 826,667 493,333 - 9,000,000 930,000 555,000 - 10,000,000 1,033,334 616,666 - 10,500,000 1,085,000 647,500 - 11,000,000 1,136,667 678,333 - 12,000,000 1,240,001 740,000 - 13,000,000 1,343,334 801,666 - 14,000,000 1,446,667 863,333 - 15,000,000 1,508,000 895,000 709,167 16,000,000 1,608,533 954,667 756,445 17,000,000 1,709,067 1,014,333 803,723 18,000,000 1,809,600 1,074,000 851,000 19,000,000 1,910,133 1,133,667 898,278 20,000,000 2,010,667 1,193,333 945,556 21,000,000 2,111,200 1,253,000 992,834 22,000,000 2,211,733 1,312,667 1,040,112 23,000,000 2,312,267 1,372,333 1,087,389 24,000,000 2,412,800 1,432,000 1,134,667 25,000,000 2,513,333 1,491,667 1,181,945 26,000,000 2,613,867 1,551,333 1,229,223 27,000,000 2,714,400 1,611,000 1,276,501 28,000,000 2,814,933 1,670,667 1,323,778 29,000,000 2,915,467 1,730,333 1,371,056 30,000,000 3,016,000 1,790,000 1,418,334 31,000,000 3,116,533 1,849,667 1,465,612 32,000,000 3,217,067 1,909,333 1,512,890 33,000,000 3,317,600 1,969,000 1,560,167 34,000,000 3,418,133 2,028,667 1,607,445 35,000,000 3,518,667 2,088,333 1,654,723 36,000,000 3,619,200 2,148,000 1,702,001 37,000,000 3,719,733 2,207,667 1,749,279 38,000,000 3,820,267 2,267,333 1,796,556 39,000,000 3,920,800 2,327,000 1,843,834 40,000,000 4,021,333 2,386,667 1,891,112 41,000,000 4,121,867 2,446,333 1,938,390 42,000,000 4,222,400 2,506,000 1,985,668 43,000,000 4,322,933 2,565,667 2,032,945 44,000,000 4,423,467 2,625,333 2,080,223 45,000,000 4,524,000 2,685,000 2,127,501 46,000,000 4,624,533 2,744,667 2,174,779 47,000,000 4,725,067 2,804,333 2,222,057 48,000,000 4,825,600 2,864,000 2,269,334 49,000,000 4,926,133 2,923,667 2,316,612 50,000,000 5,026,667 2,983,333 2,363,890 55,000,000 5,529,333 3,281,667 2,600,279 60,000,000 6,032,000 3,580,000 2,836,668 65,000,000 6,534,667 3,878,333 3,073,057 70,000,000 7,037,333 4,176,667 3,309,446 75,000,000 7,540,000 4,475,000 3,545,835 80,000,000 8,042,667 4,773,333 3,782,224 85,000,000 8,545,333 5,071,667 4,018,613 90,000,000 9,048,000 5,370,000 4,255,002 95,000,000 9,550,667 5,668,333 4,491,391 100,000,000 10,053,333 5,966,667 4,727,780 105,000,000 10,556,000 6,265,000 4,964,169 110,000,000 11,058,667 6,563,333 5,200,558 115,000,000 11,561,333 6,861,667 5,436,947 120,000,000 12,064,000 7,160,000 5,673,336 125,000,000 12,566,667 7,458,333 5,909,725 -- This message was sent on behalf of umarsani7@gmail.com at openSubscriber.com http://www.opensubscriber.com/messages/freebsd-stable@freebsd.org/topic.html From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 03:18:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FC3816A41A for ; Sun, 3 Feb 2008 03:18:04 +0000 (UTC) (envelope-from umarsani7@gmail.com) Received: from wombat.diezmil.com (wombat.diezmil.com [209.190.27.106]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD3413C461 for ; Sun, 3 Feb 2008 03:18:03 +0000 (UTC) (envelope-from umarsani7@gmail.com) Received: from wombat.diezmil.com (wombat.diezmil.com [127.0.0.1]) by wombat.diezmil.com (8.13.8/8.13.8) with ESMTP id m133I3P0009887 for ; Sat, 2 Feb 2008 22:18:03 -0500 Date: Sat, 2 Feb 2008 22:18:03 -0500 Message-ID: <23342038.1202008683513.JavaMail.root@wombat.diezmil.com> From: umarsani7@gmail.com To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: PINJAMAN TANPA AGUNAN 8-125 JT..GRATIS..TANPA PROVISI/ADM 3%..dr HSBC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: umarsani7@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2008 03:18:04 -0000 DAPATKAN PINJAMAN TANPA AGUNAN DENGAN PERSYARATAN YANG MUDAH,PROSES YANG CEPAT, DAN FASILTAS BERUPA BEBAS PROVISI/ADM 3% UNTUK PINJAMAN 15.000.000 - 19.000.000 DENGAN TENOR/MASA PELUNASAN 24 BULAN DAN PINJAMAN >=20.000.000,- DENGAN TENOR 36 BULAN. PROSES VERIFIKASI HINGGA PENCAIRAN 5-7 HARI KERJA. dr HSBC DOCUMENT YANG DIBUTUHKAN : 1.FC KTP 2.FC.CREDIT CARD DAN BILLING 1 BULAN TERAKHIR 3.FC.NO REK.TABUNGAN(SEBAGAI TEMPAT TRANSFER BILA DI SETUJUI) 4.MATERAI Rp.6.000,- 1 BH. 5.FC.NPWP (untuk pinjaman diatas Rp.50 juta ) UTK KETERANGAN HUB: UMAR 0813-19288679 0859-21346503 or umarsani7@gmail.com PERHITUNGAN BUNGA/BULAN TENOR Jml.Pinjaman 12 bulan 24 bulan 36 bulan 8.000.000 - 14.999.999 2 %. 2 %. - 15.000.000 - 125.000.000 1.72% 1.80 %. 1.95 %. TABEL ANGSURAN PINJAMAN 1 TAHUN 2 TAHUN 3 TAHUN 8,000,000 826,667 493,333 - 9,000,000 930,000 555,000 - 10,000,000 1,033,334 616,666 - 10,500,000 1,085,000 647,500 - 11,000,000 1,136,667 678,333 - 12,000,000 1,240,001 740,000 - 13,000,000 1,343,334 801,666 - 14,000,000 1,446,667 863,333 - 15,000,000 1,508,000 895,000 709,167 16,000,000 1,608,533 954,667 756,445 17,000,000 1,709,067 1,014,333 803,723 18,000,000 1,809,600 1,074,000 851,000 19,000,000 1,910,133 1,133,667 898,278 20,000,000 2,010,667 1,193,333 945,556 21,000,000 2,111,200 1,253,000 992,834 22,000,000 2,211,733 1,312,667 1,040,112 23,000,000 2,312,267 1,372,333 1,087,389 24,000,000 2,412,800 1,432,000 1,134,667 25,000,000 2,513,333 1,491,667 1,181,945 26,000,000 2,613,867 1,551,333 1,229,223 27,000,000 2,714,400 1,611,000 1,276,501 28,000,000 2,814,933 1,670,667 1,323,778 29,000,000 2,915,467 1,730,333 1,371,056 30,000,000 3,016,000 1,790,000 1,418,334 31,000,000 3,116,533 1,849,667 1,465,612 32,000,000 3,217,067 1,909,333 1,512,890 33,000,000 3,317,600 1,969,000 1,560,167 34,000,000 3,418,133 2,028,667 1,607,445 35,000,000 3,518,667 2,088,333 1,654,723 36,000,000 3,619,200 2,148,000 1,702,001 37,000,000 3,719,733 2,207,667 1,749,279 38,000,000 3,820,267 2,267,333 1,796,556 39,000,000 3,920,800 2,327,000 1,843,834 40,000,000 4,021,333 2,386,667 1,891,112 41,000,000 4,121,867 2,446,333 1,938,390 42,000,000 4,222,400 2,506,000 1,985,668 43,000,000 4,322,933 2,565,667 2,032,945 44,000,000 4,423,467 2,625,333 2,080,223 45,000,000 4,524,000 2,685,000 2,127,501 46,000,000 4,624,533 2,744,667 2,174,779 47,000,000 4,725,067 2,804,333 2,222,057 48,000,000 4,825,600 2,864,000 2,269,334 49,000,000 4,926,133 2,923,667 2,316,612 50,000,000 5,026,667 2,983,333 2,363,890 55,000,000 5,529,333 3,281,667 2,600,279 60,000,000 6,032,000 3,580,000 2,836,668 65,000,000 6,534,667 3,878,333 3,073,057 70,000,000 7,037,333 4,176,667 3,309,446 75,000,000 7,540,000 4,475,000 3,545,835 80,000,000 8,042,667 4,773,333 3,782,224 85,000,000 8,545,333 5,071,667 4,018,613 90,000,000 9,048,000 5,370,000 4,255,002 95,000,000 9,550,667 5,668,333 4,491,391 100,000,000 10,053,333 5,966,667 4,727,780 105,000,000 10,556,000 6,265,000 4,964,169 110,000,000 11,058,667 6,563,333 5,200,558 115,000,000 11,561,333 6,861,667 5,436,947 120,000,000 12,064,000 7,160,000 5,673,336 125,000,000 12,566,667 7,458,333 5,909,725 -- This message was sent on behalf of umarsani7@gmail.com at openSubscriber.com http://www.opensubscriber.com/messages/freebsd-stable@freebsd.org/topic.html From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 06:55:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29D5816A418 for ; Sun, 3 Feb 2008 06:55:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id B430413C4E3 for ; Sun, 3 Feb 2008 06:55:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JLYkp-000Ftw-Hl; Sun, 03 Feb 2008 08:55:04 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m136shB6089834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2008 08:54:43 +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.14.2/8.14.2) with ESMTP id m136t2JC054012; Sun, 3 Feb 2008 08:55:02 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m136t2QD054011; Sun, 3 Feb 2008 08:55:02 +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: Sun, 3 Feb 2008 08:55:02 +0200 From: Kostik Belousov To: Dmitry Morozovsky Message-ID: <20080203065502.GH57756@deviant.kiev.zoral.com.ua> References: <20080203030205.T28725@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Yf2LLZzcMaLfAG8/" Content-Disposition: inline In-Reply-To: <20080203030205.T28725@woozle.rinet.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Scanner-Signature: a89dff86c47152c77ba722073511b1ec X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2160 [Feb 02 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-stable@freebsd.org, sos@freebsd.org Subject: Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk 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, 03 Feb 2008 06:55:06 -0000 --Yf2LLZzcMaLfAG8/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 03, 2008 at 03:04:52AM +0300, Dmitry Morozovsky wrote: > Dear colleagues, >=20 > during rsycn from eSATA drive connected to Promise TX4 (ad12) to ZFS pool= =20 > eSATA disk got disconnected. With the next access, system crashed: >=20 > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 1; apic id =3D 01 > fault virtual address =3D 0x3020e0b30 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x8:0xffffffff801cac9d > stack pointer =3D 0x10:0xffffffffd79f7800 > frame pointer =3D 0x10:0xffffffffd79f7840 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 898 (tcsh) > trap number =3D 12 > panic: page fault > cpuid =3D 1 > Uptime: 7h49m35s > Physical memory: 4087 MB > Dumping 677 MB: 662 646 630 614 598 582 566 550 534 518 502 486 470 454 4= 38 422=20 > 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 1= 18 102=20 > 86 70 54 38 22 6 >=20 > #0 doadump () at pcpu.h:194 > 194 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:194 > #1 0x0000000000000031 in ?? () > #2 0xffffffff80219c30 in boot (howto=3D260) at=20 > /usr/src/sys/kern/kern_shutdown.c:409 > #3 0xffffffff8021a04d in panic (fmt=3D0x104
) at=20 > /usr/src/sys/kern/kern_shutdown.c:563 > #4 0xffffffff80353284 in trap_fatal (frame=3D0xffffff000179c340,=20 > eva=3D18446742974222725120) at /usr/src/sys/amd64/amd64/trap.c:724 > #5 0xffffffff80353655 in trap_pfault (frame=3D0xffffffffd79f7750, usermo= de=3D0) at=20 > /usr/src/sys/amd64/amd64/trap.c:641 > #6 0xffffffff80353ffb in trap (frame=3D0xffffffffd79f7750) at=20 > /usr/src/sys/amd64/amd64/trap.c:410 > #7 0xffffffff80339dbe in calltrap () at=20 > /usr/src/sys/amd64/amd64/exception.S:169 > #8 0xffffffff801cac9d in dev2udev (x=3D0xffffff0001779400) at=20 > /usr/src/sys/fs/devfs/devfs_vnops.c:1325 > #9 0xffffffff80310ab8 in ufs_getattr (ap=3DVariable "ap" is not availabl= e. > ) at /usr/src/sys/ufs/ufs/ufs_vnops.c:401 > #10 0xffffffff8029dcf3 in vn_stat (vp=3D0xffffff004728b9b0,=20 > sb=3D0xffffffffd79f79f0, active_cred=3DVariable "active_cred" is not avai= lable. > ) at vnode_if.h:286 > #11 0xffffffff802953b1 in kern_stat (td=3D0xffffff000179c340, path=3D0x44= b66a=20 >
, pathseg=3DVariable "pathseg" is not ava= ilable. > ) at /usr/src/sys/kern/vfs_syscalls.c:2112 > #12 0xffffffff80295507 in stat (td=3DVariable "td" is not available. > ) at /usr/src/sys/kern/vfs_syscalls.c:2093 > #13 0xffffffff803538da in syscall (frame=3D0xffffffffd79f7c70) at=20 > /usr/src/sys/amd64/amd64/trap.c:852 > #14 0xffffffff80339fcb in Xfast_syscall () at=20 > /usr/src/sys/amd64/amd64/exception.S:290 > #15 0x00000000809c235c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb)=20 >=20 > I would be glad to provide additional info to investigate and hopefully f= ix the=20 > problem. >=20 > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ Di you have the UFS volume mounted from the eSATA drive ? If yes, then the panic is the natural consequence of the device disappearing from under the UFS. If not, and fault address 0x3020e0b30 looks suspicious, it could mean some kernel memory corruption. Anyway, it would be interesting to look at the vnode vp content from the frame #10, and to lookup the mount point together with a device it comes from. --Yf2LLZzcMaLfAG8/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkelZUUACgkQC3+MBN1Mb4ggWACdFvWsIwluyq7HLp1bUXGuQBJ2 tKMAnAlK1tuLjRrCurm2idxe4ZMP+Yvf =JA2T -----END PGP SIGNATURE----- --Yf2LLZzcMaLfAG8/-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 07:44:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B7FF16A421 for ; Sun, 3 Feb 2008 07:44: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 B2B1113C46E for ; Sun, 3 Feb 2008 07:44:10 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from scoo-longs-computer.local (74-92-209-37-Colorado.hfc.comcastbusiness.net [74.92.209.37] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m137i2KE044753 for ; Sun, 3 Feb 2008 00:44:07 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <47A570C1.2070708@samsco.org> Date: Sun, 03 Feb 2008 00:44:01 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: FreeBSD Stable References: <200802030728.m137SdOY042122@repoman.freebsd.org> In-Reply-To: <200802030728.m137SdOY042122@repoman.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.5 required=5.4 tests=MANY_EXCLAMATIONS, PLING_PLING autolearn=no version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Subject: HEADS UP!!! rr232x driver has been removed!!! [Re: cvs commit: src/sys/dev/rr232x...] 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, 03 Feb 2008 07:44:11 -0000 HEADS UP!!! The rr232x driver has been removed at the request of Highpoint. The reason is that is has been superseded by the hptrr driver and is no longer supported by Highpoint. If you use this driver, you must update your kernel config and/or module loading config to point to the hptrr driver instead. Please direct any questions or concerns about this to me. The driver will also be removed from the upcoming 7.0 release. Scott Long wrote: > scottl 2008-02-03 07:28:39 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_7) > sys/i386/conf GENERIC NOTES > sys/amd64/conf GENERIC NOTES > sys/conf files.amd64 files.i386 > Removed files: (Branch: RELENG_7) > sys/dev/rr232x LICENSE README amd64-elf.rr232x_lib.o.uu > array.h him.h himfuncs.h hptintf.h > i386-elf.rr232x_lib.o.uu ldm.h list.h > os_bsd.c os_bsd.h osm.h osm_bsd.c > rr232x_config.c rr232x_config.h > sys/modules/rr232x Makefile > Log: > Remove the rr232x driver. It has been superseced by the hptrr driver. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 09:05:52 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A79316A41A; Sun, 3 Feb 2008 09:05:52 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id BB6DF13C455; Sun, 3 Feb 2008 09:05:51 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id m1395iaB068520; Sun, 3 Feb 2008 12:05:44 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 3 Feb 2008 12:05:44 +0300 (MSK) From: Dmitry Morozovsky To: Kostik Belousov In-Reply-To: <20080203065502.GH57756@deviant.kiev.zoral.com.ua> Message-ID: <20080203120136.B28725@woozle.rinet.ru> References: <20080203030205.T28725@woozle.rinet.ru> <20080203065502.GH57756@deviant.kiev.zoral.com.ua> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Sun, 03 Feb 2008 12:05:44 +0300 (MSK) Cc: freebsd-stable@freebsd.org, sos@freebsd.org Subject: Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk 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, 03 Feb 2008 09:05:52 -0000 On Sun, 3 Feb 2008, Kostik Belousov wrote: KB> Di you have the UFS volume mounted from the eSATA drive ? If yes, then the KB> panic is the natural consequence of the device disappearing from under the KB> UFS. If not, and fault address 0x3020e0b30 looks suspicious, it could mean KB> some kernel memory corruption. yes, there is (were) UFS2 on eSATA. KB> Anyway, it would be interesting to look at the vnode vp content from the KB> frame #10, and to lookup the mount point together with a device it comes KB> from. (kgdb) fr 10 #10 0xffffffff8029dcf3 in vn_stat (vp=0xffffff004728b9b0, sb=0xffffffffd79f79f0, active_cred=Variable "active_cred" is not available. ) at vnode_if.h:286 286 vnode_if.h: No such file or directory. in vnode_if.h (kgdb) p vp $1 = (struct vnode *) 0xffffff004728b9b0 (kgdb) p *vp $2 = {v_type = VDIR, v_tag = 0xffffffff8039319c "ufs", v_op = 0xffffffff804e98e0, v_data = 0xffffff003fab0480, v_mount = 0xffffff00050dc650, v_nmntvnodes = { tqe_next = 0xffffff004728bba0, tqe_prev = 0xffffff004728f218}, v_un = {vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0, le_prev = 0xffffffff808c10e0}, v_hash = 215211, v_cache_src = {lh_first = 0xffffff003f4d5000}, v_cache_dst = {tqh_first = 0xffffff0026fcca90, tqh_last = 0xffffff0026fccab0}, v_dd = 0xffffff00470a49b0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lk_object = {lo_name = 0xffffffff8039319c "ufs", lo_type = 0xffffffff8039319c "ufs", lo_flags = 70844416, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, lk_interlock = 0xffffffff80514730, lk_flags = 262208, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 1, lk_prio = 80, lk_timo = 51, lk_lockholder = 0xffffff000179c340, lk_newlock = 0x0}, v_interlock = {lock_object = { lo_name = 0xffffffff8039e4da "vnode interlock", lo_type = 0xffffffff8039e4da "vnode interlock", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, v_vnlock = 0xffffff004728ba48, v_holdcnt = 3, v_usecount = 2, v_iflag = 0, v_vflag = 0, v_writecount = 0, v_freelist = {tqe_next = 0x0, tqe_prev = 0xffffff004728b900}, v_bufobj = {bo_mtx = 0xffffff004728ba98, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff004728bb08}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd = {tqh_first = 0x0, tqh_last = 0xffffff004728bb28}, bv_root = 0x0, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0, bo_ops = 0xffffffff804dd3e0, bo_bsize = 65536, bo_object = 0xffffff0047994680, bo_synclist = {le_next = 0x0, le_prev = 0x0}, bo_private = 0xffffff004728b9b0, __bo_vnode = 0xffffff004728b9b0}, v_pollinfo = 0x0, v_label = 0x0} I think tere are at least two problems here: - panic when non-essential UFS mounted partition disappears - particular disappearing eSATA drive from eSATA channel of TX4. Relevant error messages are Feb 2 19:29:18 hamster kernel: ata7: reiniting channel .. Feb 2 19:29:18 hamster kernel: ata7: SATA connect time=0ms Feb 2 19:29:18 hamster kernel: ata7: reset tp1 mask=01 ostat0=d0 ostat1=00 Feb 2 19:29:18 hamster kernel: ata7: stat0=0xd0 err=0x00 lsb=0x36 msb=0x72 Feb 2 19:29:26 hamster last message repeated 87 times Feb 2 19:29:27 hamster kernel: Feb 2 19:29:27 hamster kernel: ata7: stat0=0xd0 err=0x00 lsb=0x36 msb=0x72 Feb 2 19:29:49 hamster last message repeated 221 times Feb 2 19:29:49 hamster kernel: ata7: reset tp2 stat0=d0 stat1=00 devices=0x0 Feb 2 19:29:49 hamster kernel: ad14: FAILURE - device detached Feb 2 19:29:49 hamster kernel: ad1g4_:v fdse_tdaocnhee(d): Feb 2 19:29:49 hamster kernel: ad14a[aRtEaA7D:( orfefisneitt= d1o2n4e0 9.1.43 Feb 2 19:29:49 hamster kernel: 2960, length=131072)]error = 6 Feb 2 19:29:49 hamster kernel: g_vfs_done():ad14a[READ(offset=124091564032, length=131072)]error = 6 Feb 2 19:29:49 hamster kernel: g_vfs_done():ad14a[READ(offset=124091695104, length=131072)]error = 6 ... and zillion of g_vfs_gone after. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 09:48:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A34516A41B for ; Sun, 3 Feb 2008 09:48:04 +0000 (UTC) (envelope-from toomany@toomany.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 1BC9613C442 for ; Sun, 3 Feb 2008 09:48:04 +0000 (UTC) (envelope-from toomany@toomany.net) Received: by wa-out-1112.google.com with SMTP id k17so1748196waf.3 for ; Sun, 03 Feb 2008 01:48:03 -0800 (PST) Received: by 10.115.79.1 with SMTP id g1mr40246wal.43.1202032083689; Sun, 03 Feb 2008 01:48:03 -0800 (PST) Received: by 10.114.53.10 with HTTP; Sun, 3 Feb 2008 01:48:03 -0800 (PST) Message-ID: Date: Sun, 3 Feb 2008 10:48:03 +0100 From: "TooMany Secrets" To: freebsd-stable MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Cc: freebsd-current@freebsd.org Subject: Broadcom Netlink BCM5906M 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, 03 Feb 2008 09:48:04 -0000 SGkhCgpUaGVyZSBpcyBhbnkgcGxhbiBmb3IgdGhlIGV0aGVybmV0IGRyaXZlciBCcm9hZGNvbSBC Q001OTA2TT8KSSBoYXZlIGEgbmV3IGxhcHRvcCAoRGVsbCBWb3N0cm8gMTQwMCkgd2l0aCB0aGlz IGV0aGVybmV0LCBidXQgZG9lc24ndAp3b3JrIHdpdGggYmdlIG9yIGFueSAiYiplIiBkcml2ZXIg Oi0oCgpUaGFuayB5b3UgdmVyeSBtdWNoIGFuZCBwbGVhc2UsIGV4Y3VzZSBtZSB0aGUgY3Jvc3Mt cG9zdGluZy4KCi0tIApIYXZlIGEgbmljZSBkYXkgIDstKQpUb29NYW55U2VjcmV0cwoKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PQpEaWpvIENvbmZ1Y2lvOgoiRXjDrWdldGUgbXVjaG8gYSB0 aSBtaXNtbyB5IGVzcGVyYSBwb2NvIGRlIGxvcyBkZW3DoXMuIEFzw60gdGUgYWhvcnJhcsOhcwpk aXNndXN0b3MuIgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09Cg== From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 10:10:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AE1C16A420 for ; Sun, 3 Feb 2008 10:10:14 +0000 (UTC) (envelope-from darranc@deejc.net) Received: from smtp-out-57.livemail.co.uk (smtp-out-60.livemail.co.uk [213.171.216.60]) by mx1.freebsd.org (Postfix) with ESMTP id 29FC713C46B for ; Sun, 3 Feb 2008 10:10:13 +0000 (UTC) (envelope-from darranc@deejc.net) Received: from Postfix filter 42a77884ce2a0a03efc6bb50a6dcdb20 (smtp-out-57.livemail.co.uk [127.0.0.1]) by smtp-out-57.livemail.co.uk (Postfix) with SMTP id DCAEF207848 for ; Sun, 3 Feb 2008 10:10:10 +0000 (GMT) Received: from Vostro (unknown [91.104.121.82]) by smtp-out-57.livemail.co.uk (Postfix) with ESMTP id EB47A20783F; Sun, 3 Feb 2008 10:10:07 +0000 (GMT) From: "Darran" To: "'TooMany Secrets'" , "'freebsd-stable'" References: Date: Sun, 3 Feb 2008 10:10:06 -0000 Message-ID: <002301c8664c$f3c5bff0$6501a8c0@Vostro> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Content-Type: multipart/signed; micalg=MD5; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_001F_01C8664C.F24847B0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AchmSf/HpvH3ZWoKTuOwyJYiMYfhQQAAs4nw X-Original-To: freebsd-stable@freebsd.org Cc: freebsd-current@freebsd.org Subject: RE: Broadcom Netlink BCM5906M 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, 03 Feb 2008 10:10:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C8664C.F24847B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a dell vostro 1000 and I had the nic working under 6.2 using NDIS = but I have have not been able to get my NIC working under 6.3 or 7 using any windows drivers and ndis. Darran http://www.deejc.net -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of TooMany Secrets Sent: 03 February 2008 09:48 To: freebsd-stable Cc: freebsd-current@freebsd.org Subject: Broadcom Netlink BCM5906M Hi! There is any plan for the ethernet driver Broadcom BCM5906M? I have a new laptop (Dell Vostro 1400) with this ethernet, but doesn't work with bge or any "b*e" driver :-( Thank you very much and please, excuse me the cross-posting. --=20 Have a nice day ;-) TooManySecrets =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Dijo Confucio: "Ex=EDgete mucho a ti mismo y espera poco de los dem=E1s. As=ED te = ahorrar=E1s disgustos." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D ------=_NextPart_000_001F_01C8664C.F24847B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEHAQAAoIII0DCC AlgwggHBoAMCAQICEC4N3+8bOWbjM8NONNhNsVAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMxOTEyNDEzNloXDTA4MDMxODEy NDEzNlowQzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEgMB4GCSqGSIb3DQEJARYR ZGFycmFuY0BkZWVqYy5uZXQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANmDFEcbptwbmawN K6+7QngGHBeiU4gOuYU3D3X1Zucv3hI2qMpcqPuYO6HUOsVGFxqeS8fx0qa3wvlx9zjEotOBcKHu pZxku9JNiofhhtBi4y0iaC2V+j1GqDxkz0W+s32f7dAT1X1zv2Jt04XkL+OWW7V2sZhbBeQ9jXzX JK1hAgMBAAGjLjAsMBwGA1UdEQQVMBOBEWRhcnJhbmNAZGVlamMubmV0MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEFBQADgYEAawNjU0urh2u6syrZEzC0qU/nuiPHMd/2rVLWj0a9QRL89hgMNM/b R4iePEH3+8jBH+uBStMAm0FvzWzJj2Kiak3JV5GnZ/7J31EWXiGQcheAp7rFi9ud4vKh2bZPcI6r eN9k7dvSvmyix4cFWDx/p7gZvXdhxjxK7SMncHHA4BUwggMtMIIClqADAgECAgEAMA0GCSqGSIb3 DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlD YXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0 aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAx MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYG A1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59 LQ2PexLfhSV1KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmU hl6t6sBeduvZFKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMw ETAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+N YFhhrCa7UjVcCM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd 5Jr9E/Sm2Xyx+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAvcwggLzAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAuDd/vGzlm4zPDTjTYTbFQMAwGCCqGSIb3 DQIFBQCgggHUMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDIw MzEwMTAwNFowHwYJKoZIhvcNAQkEMRIEEIF0rgLDd/MBmzTIhxJ6EMowZwYJKoZIhvcNAQkPMVow WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwCgYIKoZIhvcNAgUwBwYFKw4DAhowgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAuDd/vGzlm4zPDTjTYTbFQMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAhAuDd/vGzlm4zPDTjTYTbFQMA0GCSqGSIb3DQEBAQUABIGArgvgQFLjTkDWaWi/KBYznhX0 5HoJ9t2+T7CNOb9GcOHDhOjXEbhTF9cFpJl4sjw7zWky89hPGI+NxNLb5M9W9YCz7ndDTyg43td5 ZYOpR2AufISBm2BPtxGmDGpKhYgXQB41mcxZ1TF5xDM5uGYJ1z5TGIa5ILhnZX3pQdaaWpUAAAAA AAA= ------=_NextPart_000_001F_01C8664C.F24847B0-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 10:36:44 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2DD216A419; Sun, 3 Feb 2008 10:36:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id A826513C468; Sun, 3 Feb 2008 10:36:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m13Aah5x006066; Sun, 3 Feb 2008 05:36:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.2/8.14.1) with ESMTP id m13AahUc032928; Sun, 3 Feb 2008 05:36:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 843C11B5078; Sun, 3 Feb 2008 05:36:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080203103643.843C11B5078@freebsd-stable.sentex.ca> Date: Sun, 3 Feb 2008 05:36:43 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2008 10:36:44 -0000 TB --- 2008-02-03 08:49:47 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-03 08:49:47 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2008-02-03 08:49:47 - cleaning the object tree TB --- 2008-02-03 08:50:15 - cvsupping the source tree TB --- 2008-02-03 08:50:15 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2008-02-03 08:50:22 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-03 08:50:22 - cd /src TB --- 2008-02-03 08:50:22 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 3 08:50:23 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Feb 3 10:18:11 UTC 2008 TB --- 2008-02-03 10:18:11 - generating LINT kernel config TB --- 2008-02-03 10:18:11 - cd /src/sys/amd64/conf TB --- 2008-02-03 10:18:11 - /usr/bin/make -B LINT TB --- 2008-02-03 10:18:11 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-03 10:18:11 - cd /src TB --- 2008-02-03 10:18:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 3 10:18:11 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rp/../../dev/rp/rp.c cc -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/amd64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/amd64/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rp/../../dev/rp/rp_pci.c ld -d -warn-common -r -d -o rp.ko rp.o rp_pci.o :> export_syms awk -f /src/sys/modules/rp/../../conf/kmod_syms.awk rp.ko export_syms | xargs -J% objcopy % rp.ko objcopy --strip-debug rp.ko ===> rr232x (all) make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-03 10:36:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-03 10:36:43 - ERROR: failed to build lint kernel TB --- 2008-02-03 10:36:43 - tinderbox aborted TB --- 5427.78 user 562.95 system 6415.42 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 11:04:36 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AAB816A417; Sun, 3 Feb 2008 11:04:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id EBB3F13C44B; Sun, 3 Feb 2008 11:04:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m13B4Z2o063045; Sun, 3 Feb 2008 06:04:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.2/8.14.1) with ESMTP id m13B4ZoK050613; Sun, 3 Feb 2008 06:04:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 16E341B5078; Sun, 3 Feb 2008 06:04:35 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080203110435.16E341B5078@freebsd-stable.sentex.ca> Date: Sun, 3 Feb 2008 06:04:35 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2008 11:04:36 -0000 TB --- 2008-02-03 09:40:09 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-03 09:40:09 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2008-02-03 09:40:09 - cleaning the object tree TB --- 2008-02-03 09:40:31 - cvsupping the source tree TB --- 2008-02-03 09:40:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2008-02-03 09:40:37 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-03 09:40:37 - cd /src TB --- 2008-02-03 09:40:37 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 3 09:40:38 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Feb 3 10:42:58 UTC 2008 TB --- 2008-02-03 10:42:58 - generating LINT kernel config TB --- 2008-02-03 10:42:58 - cd /src/sys/i386/conf TB --- 2008-02-03 10:42:58 - /usr/bin/make -B LINT TB --- 2008-02-03 10:42:59 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-03 10:42:59 - cd /src TB --- 2008-02-03 10:42:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Feb 3 10:42:59 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rp/../../dev/rp/rp_pci.c ld -d -warn-common -r -d -o rp.kld rp.o rp_pci.o :> export_syms awk -f /src/sys/modules/rp/../../conf/kmod_syms.awk rp.kld export_syms | xargs -J% objcopy % rp.kld ld -Bshareable -d -warn-common -o rp.ko rp.kld objcopy --strip-debug rp.ko ===> rr232x (all) make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-03 11:04:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-03 11:04:34 - ERROR: failed to build lint kernel TB --- 2008-02-03 11:04:34 - tinderbox aborted TB --- 4358.50 user 411.61 system 5065.52 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 11:06:20 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AC2516A420; Sun, 3 Feb 2008 11:06:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB8813C442; Sun, 3 Feb 2008 11:06:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JLcfx-0008q6-VC; Sun, 03 Feb 2008 13:06:18 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m13B5whU095188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Feb 2008 13:05:58 +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.14.2/8.14.2) with ESMTP id m13B6H07058758; Sun, 3 Feb 2008 13:06:17 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m13B6Gb3058757; Sun, 3 Feb 2008 13:06:16 +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: Sun, 3 Feb 2008 13:06:16 +0200 From: Kostik Belousov To: Dmitry Morozovsky Message-ID: <20080203110616.GJ57756@deviant.kiev.zoral.com.ua> References: <20080203030205.T28725@woozle.rinet.ru> <20080203065502.GH57756@deviant.kiev.zoral.com.ua> <20080203120136.B28725@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uSiDmGZtMrYHxQQN" Content-Disposition: inline In-Reply-To: <20080203120136.B28725@woozle.rinet.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Scanner-Signature: e97279b2caa82cd912acb3683499d123 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2160 [Feb 02 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-stable@freebsd.org, sos@freebsd.org Subject: Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk 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, 03 Feb 2008 11:06:20 -0000 --uSiDmGZtMrYHxQQN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 03, 2008 at 12:05:44PM +0300, Dmitry Morozovsky wrote: > On Sun, 3 Feb 2008, Kostik Belousov wrote: >=20 > KB> Di you have the UFS volume mounted from the eSATA drive ? If yes, the= n the > KB> panic is the natural consequence of the device disappearing from unde= r the > KB> UFS. If not, and fault address 0x3020e0b30 looks suspicious, it could= mean > KB> some kernel memory corruption. >=20 > yes, there is (were) UFS2 on eSATA. >=20 > KB> Anyway, it would be interesting to look at the vnode vp content fro= m the > KB> frame #10, and to lookup the mount point together with a device it = comes > KB> from. >=20 > (kgdb) fr 10 > #10 0xffffffff8029dcf3 in vn_stat (vp=3D0xffffff004728b9b0,=20 > sb=3D0xffffffffd79f79f0, active_cred=3DVariable "active_cred" is not avai= lable. > ) at vnode_if.h:286 > 286 vnode_if.h: No such file or directory. > in vnode_if.h > (kgdb) p vp > $1 =3D (struct vnode *) 0xffffff004728b9b0 > (kgdb) p *vp > $2 =3D {v_type =3D VDIR, v_tag =3D 0xffffffff8039319c "ufs", v_op =3D=20 > 0xffffffff804e98e0, v_data =3D 0xffffff003fab0480, v_mount =3D 0xffffff00= 050dc650,=20 The *v_mount and *(struct ufs_mount *)(v_mount->mnt_data) content shall be enough to confirm that vnode comes from the lost partition. > v_nmntvnodes =3D { > tqe_next =3D 0xffffff004728bba0, tqe_prev =3D 0xffffff004728f218}, v_= un =3D=20 > {vu_mount =3D 0x0, vu_socket =3D 0x0, vu_cdev =3D 0x0, vu_fifoinfo =3D 0x= 0}, v_hashlist=20 > =3D {le_next =3D 0x0,=20 > le_prev =3D 0xffffffff808c10e0}, v_hash =3D 215211, v_cache_src =3D {= lh_first =3D=20 > 0xffffff003f4d5000}, v_cache_dst =3D {tqh_first =3D 0xffffff0026fcca90, t= qh_last =3D=20 > 0xffffff0026fccab0},=20 > v_dd =3D 0xffffff00470a49b0, v_cstart =3D 0, v_lasta =3D 0, v_lastw =3D= 0, v_clen =3D=20 > 0, v_lock =3D {lk_object =3D {lo_name =3D 0xffffffff8039319c "ufs", lo_ty= pe =3D=20 > 0xffffffff8039319c "ufs",=20 > lo_flags =3D 70844416, lo_witness_data =3D {lod_list =3D {stqe_next= =3D 0x0},=20 > lod_witness =3D 0x0}}, lk_interlock =3D 0xffffffff80514730, lk_flags =3D = 262208,=20 > lk_sharecount =3D 0,=20 > lk_waitcount =3D 0, lk_exclusivecount =3D 1, lk_prio =3D 80, lk_timo = =3D 51,=20 > lk_lockholder =3D 0xffffff000179c340, lk_newlock =3D 0x0}, v_interlock = =3D=20 > {lock_object =3D { > lo_name =3D 0xffffffff8039e4da "vnode interlock", lo_type =3D=20 > 0xffffffff8039e4da "vnode interlock", lo_flags =3D 16973824, lo_witness_d= ata =3D=20 > {lod_list =3D {stqe_next =3D 0x0},=20 > lod_witness =3D 0x0}}, mtx_lock =3D 4, mtx_recurse =3D 0}, v_vnlo= ck =3D=20 > 0xffffff004728ba48, v_holdcnt =3D 3, v_usecount =3D 2, v_iflag =3D 0, v_v= flag =3D 0,=20 > v_writecount =3D 0,=20 > v_freelist =3D {tqe_next =3D 0x0, tqe_prev =3D 0xffffff004728b900}, v_b= ufobj =3D=20 > {bo_mtx =3D 0xffffff004728ba98, bo_clean =3D {bv_hd =3D {tqh_first =3D 0x= 0, tqh_last =3D=20 > 0xffffff004728bb08},=20 > bv_root =3D 0x0, bv_cnt =3D 0}, bo_dirty =3D {bv_hd =3D {tqh_first = =3D 0x0,=20 > tqh_last =3D 0xffffff004728bb28}, bv_root =3D 0x0, bv_cnt =3D 0}, bo_numo= utput =3D 0,=20 > bo_flag =3D 0,=20 > bo_ops =3D 0xffffffff804dd3e0, bo_bsize =3D 65536, bo_object =3D=20 > 0xffffff0047994680, bo_synclist =3D {le_next =3D 0x0, le_prev =3D 0x0}, b= o_private =3D=20 > 0xffffff004728b9b0,=20 > __bo_vnode =3D 0xffffff004728b9b0}, v_pollinfo =3D 0x0, v_label =3D 0= x0} >=20 >=20 > I think tere are at least two problems here: > - panic when non-essential UFS mounted partition disappears Unfortunately, FreeBSD has no concept of the unessential mount; I wish the mount option onerror=3Dnopanic too :). > - particular disappearing eSATA drive from eSATA channel of TX4. Relevant= error=20 > messages are This looks more like the hardware problem, and it only induced the known kernel deficiency. >=20 > Feb 2 19:29:18 hamster kernel: ata7: reiniting channel .. > Feb 2 19:29:18 hamster kernel: ata7: SATA connect time=3D0ms > Feb 2 19:29:18 hamster kernel: ata7: reset tp1 mask=3D01 ost= at0=3Dd0=20 > ostat1=3D00 > Feb 2 19:29:18 hamster kernel: ata7: stat0=3D0xd0 err=3D0x00= lsb=3D0x36=20 > msb=3D0x72 > Feb 2 19:29:26 hamster last message repeated 87 times > Feb 2 19:29:27 hamster kernel:=20 > Feb 2 19:29:27 hamster kernel: ata7: stat0=3D0xd0 err=3D0x00= lsb=3D0x36=20 > msb=3D0x72 > Feb 2 19:29:49 hamster last message repeated 221 times > Feb 2 19:29:49 hamster kernel: ata7: reset tp2 stat0=3Dd0 st= at1=3D00=20 > devices=3D0x0 > Feb 2 19:29:49 hamster kernel: ad14: FAILURE - device detach= ed > Feb 2 19:29:49 hamster kernel: ad1g4_:v fdse_tdaocnhee(d): > Feb 2 19:29:49 hamster kernel: ad14a[aRtEaA7D:( orfefisneitt= =3D=20 > d1o2n4e0 9.1.43 > Feb 2 19:29:49 hamster kernel: 2960, length=3D131072)]error = =3D 6 > Feb 2 19:29:49 hamster kernel:=20 > g_vfs_done():ad14a[READ(offset=3D124091564032, length=3D131072)]error =3D= 6 > Feb 2 19:29:49 hamster kernel:=20 > g_vfs_done():ad14a[READ(offset=3D124091695104, length=3D131072)]error =3D= 6 >=20 > ... and zillion of g_vfs_gone after. >=20 > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ --uSiDmGZtMrYHxQQN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkeloCgACgkQC3+MBN1Mb4iBqwCeJlkEFSY02Zzf02t0mZHcZBet vr8AmQGzal5N7choXcqvgGV1Ookatwbn =7nI0 -----END PGP SIGNATURE----- --uSiDmGZtMrYHxQQN-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 14:18:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F58916A478; Sun, 3 Feb 2008 14:18:24 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id E774713C44B; Sun, 3 Feb 2008 14:18:23 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.1/8.14.1) with ESMTP id m13EIMiZ013502; Sun, 3 Feb 2008 17:18:22 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Sun, 3 Feb 2008 17:18:22 +0300 (MSK) From: Dmitry Morozovsky To: Kostik Belousov In-Reply-To: <20080203110616.GJ57756@deviant.kiev.zoral.com.ua> Message-ID: <20080203171200.E33439@woozle.rinet.ru> References: <20080203030205.T28725@woozle.rinet.ru> <20080203065502.GH57756@deviant.kiev.zoral.com.ua> <20080203120136.B28725@woozle.rinet.ru> <20080203110616.GJ57756@deviant.kiev.zoral.com.ua> X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (woozle.rinet.ru [0.0.0.0]); Sun, 03 Feb 2008 17:18:22 +0300 (MSK) Cc: freebsd-stable@freebsd.org, sos@freebsd.org Subject: Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk 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, 03 Feb 2008 14:18:24 -0000 On Sun, 3 Feb 2008, Kostik Belousov wrote: KB> > (kgdb) p *vp KB> > $2 = {v_type = VDIR, v_tag = 0xffffffff8039319c "ufs", v_op = KB> > 0xffffffff804e98e0, v_data = 0xffffff003fab0480, v_mount = 0xffffff00050dc650, KB> The *v_mount and *(struct ufs_mount *)(v_mount->mnt_data) content shall KB> be enough to confirm that vnode comes from the lost partition. sure: ... f_mntfromname = "/dev/ad14a", f_mntonname = "/media/esata", but I was sure it was from there. KB> > I think tere are at least two problems here: KB> > - panic when non-essential UFS mounted partition disappears KB> Unfortunately, FreeBSD has no concept of the unessential mount; I wish KB> the mount option onerror=nopanic too :). What disturbs me even more - mount was read-only. I can understand the "panic when some unwritten data may be lost" approach, but on read-only... KB> > - particular disappearing eSATA drive from eSATA channel of TX4. Relevant error KB> > messages are KB> This looks more like the hardware problem, and it only induced the known KB> kernel deficiency. That's why I put Soeren on CC list ;) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 16:17:51 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E9C16A417 for ; Sun, 3 Feb 2008 16:17:51 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF7D13C46A for ; Sun, 3 Feb 2008 16:17:51 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1378548uge.37 for ; Sun, 03 Feb 2008 08:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=PE+GVqe0wzKy7cVtw4OX9QbTZrTIkDSC5tcEhk1usyw=; b=AjAxBh1bkXKOMksanCiA02sPPH/G7ixdIgdmnBVbHkybOKhqKsoWNUjTHE5qwRn73MZ3UVNkVKuBrKnb1scvoyQcBbMQk5Rlvlcmyw3RMCsK81dpYPpQkEVDYrG5YMGrMExbbFsQ2NjfmiRvFZNz7iLkv/yNWcqJ2X7Hr1gdAOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nDSW7abEx4Mc5DxZY+XePJG7uhSRU9OzK3fRWXcTQXbdwwJMbuV1N8pS1uZx0XDQIj57lLwtGhmnhC0Fj6lCAqu7pBo/jk0VZcheatJ3ZsrWlFkChFphr7GU7w+WhobcC7CuemafdHY++876sMfhuVi92qiQPolfSPNtW8+7wPI= Received: by 10.67.19.9 with SMTP id w9mr935683ugi.86.1202053900270; Sun, 03 Feb 2008 07:51:40 -0800 (PST) Received: by 10.66.219.18 with HTTP; Sun, 3 Feb 2008 07:51:40 -0800 (PST) Message-ID: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> Date: Sun, 3 Feb 2008 15:51:40 +0000 From: Chris To: "FreeBSD Stable" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: gjournal panic 7.0-RC1 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, 03 Feb 2008 16:17:51 -0000 I had originally enabled gjournal and seemed to have no problems but I was seeing errors in messages regarding dma write failures and after some research concluded I had setup gjournal incorrectly. I setup the gjournal again properly with soft updates disabled and doing a fresh newfs, mount showed it as enabled and I had the .journal mounted. Started copying files to it from another partition as I wanted to set that up on gjournal also and the copying I felt would be a good stress test to see if the errors stop, the errors were gone and I felt great but as it was about 80 gig of data to copy I went away to do something else for a bit. Came back to see box had rebooted itself from a journal related panic. panic: Journal overflow (joffset=499054080000 active=499691355136 inactive=4990$ cpuid = 0 7.0-RC1 Fair to say this is not as stable as ufs + soft updates then? googling did show other occurances of problem or is there a patch/workaround for the issue? disks are both 500 gig each. Chris From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 20:36:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FCA516A419 for ; Sun, 3 Feb 2008 20:36:13 +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 5F66E13C43E for ; Sun, 3 Feb 2008 20:36:13 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JLlZM-0001lY-Vv for freebsd-stable@freebsd.org; Sun, 03 Feb 2008 20:36:04 +0000 Received: from 78-1-113-112.adsl.net.t-com.hr ([78.1.113.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Feb 2008 20:36:04 +0000 Received: from ivoras by 78-1-113-112.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Feb 2008 20:36:04 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Sun, 03 Feb 2008 21:35:44 +0100 Lines: 37 Message-ID: References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF99D3E63CA4244AE122F6DA3" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-113-112.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: gjournal panic 7.0-RC1 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, 03 Feb 2008 20:36:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF99D3E63CA4244AE122F6DA3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Chris wrote: > Came back to see box had rebooted itself from a journal related panic. >=20 > panic: Journal overflow (joffset=3D499054080000 active=3D499691355136 i= nactive=3D4990$ > cpuid =3D 0 AFAIK this means that the journal is too small for your machine - try=20 doubling it until there are no more panics. If so, this is the same class of errors as ZFS (some would call it=20 "tuning errors"), only this time the space reserved for the on-disk=20 journal is too small, and the fast drives fill it up before data can be=20 transfered from the journal to the data area. --------------enigF99D3E63CA4244AE122F6DA3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHpiWgldnAQVacBcgRAoGLAJ0bCDFD1zS9RX+9hNK1LlOZATZJTgCfeYCi BdhMyn2jj7/ZSoxluY81LYg= =nVnl -----END PGP SIGNATURE----- --------------enigF99D3E63CA4244AE122F6DA3-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 20:58:26 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EED1F16A419; Sun, 3 Feb 2008 20:58:26 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (in-addr.broker.freenet6.net [IPv6:2001:5c0:8fff:fffe::214d]) by mx1.freebsd.org (Postfix) with ESMTP id 9E90613C458; Sun, 3 Feb 2008 20:58:26 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1JLluz-000Mjd-CY; Sun, 03 Feb 2008 15:58:25 -0500 Date: Sun, 3 Feb 2008 15:58:25 -0500 From: Gary Palmer To: Ivan Voras Message-ID: <20080203205825.GA62536@in-addr.com> References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-stable@freebsd.org Subject: Re: gjournal panic 7.0-RC1 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, 03 Feb 2008 20:58:27 -0000 On Sun, Feb 03, 2008 at 09:35:44PM +0100, Ivan Voras wrote: > Chris wrote: > > >Came back to see box had rebooted itself from a journal related panic. > > > >panic: Journal overflow (joffset=499054080000 active=499691355136 > >inactive=4990$ > >cpuid = 0 > > AFAIK this means that the journal is too small for your machine - try > doubling it until there are no more panics. > > If so, this is the same class of errors as ZFS (some would call it > "tuning errors"), only this time the space reserved for the on-disk > journal is too small, and the fast drives fill it up before data can be > transfered from the journal to the data area. Is there something stopping gjournal from temporarily blocking writes to the journal to allow it to flush the journaled data to the provider? Thanks, Gary From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 20:58:45 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76DCF16A498 for ; Sun, 3 Feb 2008 20:58:45 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 4A50613C448 for ; Sun, 3 Feb 2008 20:58:45 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost.egr.msu.edu [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 876672EB9EF; Sun, 3 Feb 2008 15:58:44 -0500 (EST) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1O777AdvJPSx; Sun, 3 Feb 2008 15:58:44 -0500 (EST) Received: from [10.0.0.211] (c-208-53-102-126.chrlmi.cablespeed.com [208.53.102.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTP id 41ED32EB9EB; Sun, 3 Feb 2008 15:58:44 -0500 (EST) Message-ID: <47A62B00.1060403@egr.msu.edu> Date: Sun, 03 Feb 2008 15:58:40 -0500 From: Adam McDougall User-Agent: Thunderbird 2.0.0.9 (X11/20080203) MIME-Version: 1.0 To: Ivan Voras References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: gjournal panic 7.0-RC1 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, 03 Feb 2008 20:58:45 -0000 Ivan Voras wrote: > Chris wrote: > >> Came back to see box had rebooted itself from a journal related panic. >> >> panic: Journal overflow (joffset=499054080000 active=499691355136 >> inactive=4990$ >> cpuid = 0 > > AFAIK this means that the journal is too small for your machine - try > doubling it until there are no more panics. > > If so, this is the same class of errors as ZFS (some would call it > "tuning errors"), only this time the space reserved for the on-disk > journal is too small, and the fast drives fill it up before data can > be transfered from the journal to the data area. > I did some experimentation with gjournal a few weeks ago to determine how I might partition a new server, as well as how large to make my journals and where. I did find that for the computers I have tested so far, a 1 gig (default size) journal seems to be sufficient, but half of that or less is asking for trouble and I could not find any workarounds to reduce the chances of panic when I was already stuck with a too-small journal I created a while ago. I also found the -s parameter is vague in that it does not say what units it accepts (appears to be bytes) and I *could not* get it to make a journal inside a data partition any bigger than somewhere around 1.7 gigs. Some values of -s seemed to wrap around to a smaller number, while other values gave errors about being too small (when they weren't) or invalid size. The only way I could force a journal size 2G or larger was to make a separate partition for journal. On the server I was setting up, I decided to make my (journaled) data partitions da0s1d,e,f and the journals da0s2d,e,f. I'm just getting this out there to the list because I don't have time to debug it further. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 21:18:51 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C45516A473 for ; Sun, 3 Feb 2008 21:18:51 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 780A013C457 for ; Sun, 3 Feb 2008 21:18:50 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1425865uge.37 for ; Sun, 03 Feb 2008 13:18:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/NuumPZ1L7C0Hl2/7w5WCL7Atz6DkGg9RR70+SxMXHw=; b=WWjyjfzRQ1s3EQEoNb3GpYmlOfgWl+kEOz9DEw+fCBydbcUaltFuaamaG5gZE3V62vOn3oWRl9B6M2NhOF0Mhs/Ah5JbnpeWUrEVMhY7V0Ir3V4zWh3SCDlku9Wnz/m7BuCcj7bADaONJOXiqqswY+iAF+1GZ7Kcc1ovzVsAPW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NCXYcBYte7a3dDYrImRU9RYXgbm/RRCDl/fUs0NXaJdPJyzpUjm+LuWrldbuziePVO1wbaibb+OYTMBDWvDHY26U7Mn1O0O8tY78+pPQSPyEH2HGvK6i0zBXh8VQ7kfbREI9QhfYNUtzPRBvuT1ofEXpM1o+frNzxhDGIv7gtWg= Received: by 10.66.217.20 with SMTP id p20mr1133216ugg.51.1202073529404; Sun, 03 Feb 2008 13:18:49 -0800 (PST) Received: by 10.66.219.18 with HTTP; Sun, 3 Feb 2008 13:18:49 -0800 (PST) Message-ID: <3aaaa3a0802031318y2e3fd33en8071c82172ab9ecf@mail.gmail.com> Date: Sun, 3 Feb 2008 21:18:49 +0000 From: Chris To: "Adam McDougall" In-Reply-To: <47A62B00.1060403@egr.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> <47A62B00.1060403@egr.msu.edu> Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: gjournal panic 7.0-RC1 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, 03 Feb 2008 21:18:51 -0000 > I did some experimentation with gjournal a few weeks ago to determine > how I might partition > a new server, as well as how large to make my journals and where. I did > find that for the computers > I have tested so far, a 1 gig (default size) journal seems to be > sufficient, but half of that or less is > asking for trouble and I could not find any workarounds to reduce the > chances of panic when I > was already stuck with a too-small journal I created a while ago. I > also found the -s parameter > is vague in that it does not say what units it accepts (appears to be > bytes) and I *could not* get it > to make a journal inside a data partition any bigger than somewhere > around 1.7 gigs. Some values > of -s seemed to wrap around to a smaller number, while other values gave > errors about being too small > (when they weren't) or invalid size. The only way I could force a > journal size 2G or larger was > to make a separate partition for journal. On the server I was setting > up, I decided to make my > (journaled) data partitions da0s1d,e,f and the journals da0s2d,e,f. > > I'm just getting this out there to the list because I don't have time to > debug it further. thanks for this info I have spent some 8 hours on this today and it seems the documentation for this is somewhat lacking all information required, the server is handling large 50meg files, I have an identical server that hasnt beetouched by gjournal and even after I had setup gjournal properly so no more errors I then found the write speeds were pretty poor, with hd load very high in vmstat. My initial impressions of gjournal is complicated to setup, unstable and slow write speeds however I have not given up yet and may play with it a little more tommorow. The errors that were appearing are these. ad4: FAILURE - WRITE_DMA48 status=51 error=10 LBA=662870719 This is not hd failure but occurs when the gjournal was enabled on the initial newfs but has no actual journal location. I stopped these errors after the proper configuration but of course had that single panic. If the only advantage of journaling is to avoid slow fsck's then I may decide I can live without it, the real attraction to me was been able to use the much glamorised async which is what made me so shocked when write speeds were low. Chris From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 21:23:32 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 145ED16A41A for ; Sun, 3 Feb 2008 21:23:32 +0000 (UTC) (envelope-from chrcoluk@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 A049313C468 for ; Sun, 3 Feb 2008 21:23:31 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1426596uge.37 for ; Sun, 03 Feb 2008 13:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=nDgUE5bzdrRE9M8Idasu1InBo2YepftPKejLXQI/vPI=; b=LZDOC6A4UFuZPNt9nd1kRtYBYQzH8iwr7J/X6wF8warwD1+S35BwxMEmtvzU6UMXmzxk80/Wp/iPX89loRxHN+J6ql7IiQeilSpFxLQh75uRAhxY4V2iSQXyupcgWNIqJ/hJJQ55X4dERYe/4IhJTU4gmQb2s6ioy2TUPAnlBOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ICuGWBxBMkKDgzLLMNhuq6Gd4QNkXzu+k55PQi5OSQVo3L39azMt2JM6eMYLhVWo8uRRcBhgOmo4lCs1DkEk2C7sIxkIGuEIgoX59MU9A1RE9vfufnOO74LJ9S+Z/bbBZD32FMyeZuFemLQbOUaRTUvhE15392eJa/crOqKX1ew= Received: by 10.67.115.10 with SMTP id s10mr1103508ugm.89.1202073810484; Sun, 03 Feb 2008 13:23:30 -0800 (PST) Received: by 10.66.219.18 with HTTP; Sun, 3 Feb 2008 13:23:30 -0800 (PST) Message-ID: <3aaaa3a0802031323obec30f0ubf23dfd01557d287@mail.gmail.com> Date: Sun, 3 Feb 2008 21:23:30 +0000 From: Chris To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: gjournal panic 7.0-RC1 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, 03 Feb 2008 21:23:32 -0000 > AFAIK this means that the journal is too small for your machine - try > doubling it until there are no more panics. > > If so, this is the same class of errors as ZFS (some would call it > "tuning errors"), only this time the space reserved for the on-disk > journal is too small, and the fast drives fill it up before data can be > transfered from the journal to the data area. > > > To double it is to do another newfs and start from scratch again or can I somehow increase the size without losing the data on the drive? Does a larger journal incease write speeds as I am finding them very poor around 60% of a sync + soft updates drive. Chris From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 21:23:58 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC86F16A418 for ; Sun, 3 Feb 2008 21:23:58 +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 4AABF13C4EE for ; Sun, 3 Feb 2008 21:23:58 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JLmJb-0003ok-H9 for freebsd-stable@freebsd.org; Sun, 03 Feb 2008 21:23:51 +0000 Received: from 78-1-113-112.adsl.net.t-com.hr ([78.1.113.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Feb 2008 21:23:51 +0000 Received: from ivoras by 78-1-113-112.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Feb 2008 21:23:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Sun, 03 Feb 2008 22:23:44 +0100 Lines: 42 Message-ID: References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> <20080203205825.GA62536@in-addr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig71AF302F2031436C49562DDF" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-113-112.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <20080203205825.GA62536@in-addr.com> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: gjournal panic 7.0-RC1 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, 03 Feb 2008 21:23:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig71AF302F2031436C49562DDF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Gary Palmer wrote: > On Sun, Feb 03, 2008 at 09:35:44PM +0100, Ivan Voras wrote: >> If so, this is the same class of errors as ZFS (some would call it=20 >> "tuning errors"), only this time the space reserved for the on-disk=20 >> journal is too small, and the fast drives fill it up before data can b= e=20 >> transfered from the journal to the data area. >=20 > Is there something stopping gjournal from temporarily blocking writes > to the journal to allow it to flush the journaled data to the provider?= I've done something like that in the past, but I don't know if Pawel's=20 gjournal has this implemented. I feel that a good solution could be to somehow pause the file system at = the VFS layer not to generate requests that would result in IO writes -=20 this could (in theory...) help with ZFS. --------------enig71AF302F2031436C49562DDF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHpjDgldnAQVacBcgRAnpuAKCBp41nE55TNHPQ1TNK47+eiWKbkACg6aKf +nGW6jqRPWsxEF+usvN2vnc= =kM2d -----END PGP SIGNATURE----- --------------enig71AF302F2031436C49562DDF-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 21:45:55 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A09616A419 for ; Sun, 3 Feb 2008 21:45:55 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [64.46.156.146]) by mx1.freebsd.org (Postfix) with ESMTP id 4D07213C46B for ; Sun, 3 Feb 2008 21:45:55 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTP id B15476107; Sun, 3 Feb 2008 16:45:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1202075154; bh=GxNssaZauT1gfg fsff681XymDxHrW150NeFC3vEPpvo=; h=DomainKey-Signature:Message-ID: Date:From:User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:OpenPGP:Content-Type: Content-Transfer-Encoding; b=S5PtxOxwZ4P8WRk+cNVlFteoCsEymwECv1YSv Jtii3QJtqa6jCAfxXrcGvphhL6u+5ZBJX3sKqgzyRHsaKZi7VkRXT1agew/seJPeqgv CtjZb6ygUVKLhxYtlv7Pawgw DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=F7zU29QA7YEiKGinZEILQstugb3GUjbF8JI4j8XabpuMpGW80p1OwcHDYiE/bEXO/ 1OrlNDR2y+nBgRAtOihfz0ArAbTw5bUfJ16PzetlGMbqejTh9HRk2lzel83gKXB Message-ID: <47A63610.4070608@protected-networks.net> Date: Sun, 03 Feb 2008 16:45:52 -0500 From: Michael Butler User-Agent: Thunderbird 2.0.0.9 (X11/20080124) MIME-Version: 1.0 To: Chris References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> <47A62B00.1060403@egr.msu.edu> <3aaaa3a0802031318y2e3fd33en8071c82172ab9ecf@mail.gmail.com> In-Reply-To: <3aaaa3a0802031318y2e3fd33en8071c82172ab9ecf@mail.gmail.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam McDougall , freebsd-stable@freebsd.org, Ivan Voras Subject: Re: gjournal panic 7.0-RC1 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, 03 Feb 2008 21:45:55 -0000 Chris wrote: > If the only advantage of journaling is to avoid slow fsck's then I may > decide I can live without it, the real attraction to me was been able > to use the much glamorised async which is what made me so shocked when > write speeds were low. If I understood this thread correctly, the impression of poor performance is based on a configuration where both the journal and the data are on the same physical drive. Intuitively, this will likely penalize any transaction on the volume, read or write, since you're asking the drive to not only accumulate a queue of information to the journal in one region of the disk but also to flush that data in "idle time" to a region in the data space on that same disk at a significant seek-length away. I would think that journaling on one drive and storing the resultant data-set on another would improve performance enormously (reduced seek-lengths) and more so if they were 1) high-rpm drives (less rotational latency) and 2) on different buses (no bus/controller contention), Michael From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 22:38:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB21016A41B for ; Sun, 3 Feb 2008 22:38:30 +0000 (UTC) (envelope-from chrcoluk@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 3883A13C469 for ; Sun, 3 Feb 2008 22:38:30 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1440954uge.37 for ; Sun, 03 Feb 2008 14:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=aIcCt/KgMQelirhwEbkceAeN1/LO5Y3rbxDG3sgwPI4=; b=Fg8JiF7nK20g9GJpNP1m9ouY/8Ft6mTgc5PQDyEZZ9/r+AVSXHr0giGqRAuDbVU3nY9b3wt+SPgKys2e5cM24QOhrDMx5SUHsHqfGNQxWSLPEgn7EcBeJSajnDfZ+MX7gqfG9Nmd6vdo85P8dTGi6HZkHCJi/nTm661mkuQWN70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pbTlx1qQv0TjkyUqHgZW+1QEWjkHjC+8IxR+A4RB/x1PNQUv60iGrIdEjs6BkSLbwVUBQCyrY1Qxb13ljHvHxBCocFsGCjo8PuXKW9LKFu7/WbS1GFc4f6iosZ4Rk3qYc0AhIEcvnBHUjCgAcd/c3fzi1H7MSFN3OZDBKV+EeJ4= Received: by 10.67.15.15 with SMTP id s15mr1387657ugi.27.1202078308507; Sun, 03 Feb 2008 14:38:28 -0800 (PST) Received: by 10.66.219.18 with HTTP; Sun, 3 Feb 2008 14:38:28 -0800 (PST) Message-ID: <3aaaa3a0802031438u112fe5damc48adc286f308252@mail.gmail.com> Date: Sun, 3 Feb 2008 22:38:28 +0000 From: Chris To: "Michael Butler" In-Reply-To: <47A63610.4070608@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> <47A62B00.1060403@egr.msu.edu> <3aaaa3a0802031318y2e3fd33en8071c82172ab9ecf@mail.gmail.com> <47A63610.4070608@protected-networks.net> Cc: Adam McDougall , freebsd-stable@freebsd.org, Ivan Voras Subject: Re: gjournal panic 7.0-RC1 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, 03 Feb 2008 22:38:30 -0000 > If I understood this thread correctly, the impression of poor > performance is based on a configuration where both the journal and the > data are on the same physical drive. Intuitively, this will likely > penalize any transaction on the volume, read or write, since you're > asking the drive to not only accumulate a queue of information to the > journal in one region of the disk but also to flush that data in "idle > time" to a region in the data space on that same disk at a significant > seek-length away. > > I would think that journaling on one drive and storing the resultant > data-set on another would improve performance enormously (reduced > seek-lengths) and more so if they were 1) high-rpm drives (less > rotational latency) and 2) on different buses (no bus/controller > contention), > > Michael > Yes I have suspected this, there is 2 physical drives in the machine so this would be possible, if its possible to swap the journals round so they journaling for each other I will give it a go tommorow. They both sata 300 drives. Chris From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 23:38:08 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 531DC16A41B for ; Sun, 3 Feb 2008 23:38:08 +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 7F89F13C442 for ; Sun, 3 Feb 2008 23:38:06 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JLoPP-0001gF-3R for freebsd-stable@freebsd.org; Sun, 03 Feb 2008 23:37:59 +0000 Received: from 78-1-113-112.adsl.net.t-com.hr ([78.1.113.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Feb 2008 23:37:59 +0000 Received: from ivoras by 78-1-113-112.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Feb 2008 23:37:59 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 04 Feb 2008 00:37:43 +0100 Lines: 73 Message-ID: References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> <47A62B00.1060403@egr.msu.edu> <3aaaa3a0802031318y2e3fd33en8071c82172ab9ecf@mail.gmail.com> <47A63610.4070608@protected-networks.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigABE262E7FCBEA5D933381A10" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-113-112.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <47A63610.4070608@protected-networks.net> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: gjournal panic 7.0-RC1 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, 03 Feb 2008 23:38:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigABE262E7FCBEA5D933381A10 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Michael Butler wrote: > I would think that journaling on one drive and storing the resultant=20 > data-set on another would improve performance enormously (reduced=20 > seek-lengths) and more so if they were 1) high-rpm drives (less=20 > rotational latency) and 2) on different buses (no bus/controller=20 > contention), There are (very near) limits to what you can do with such a setup: the=20 drive that holds the external journal needs to be much faster than the=20 data drive, since it will become the main bottleneck in IO. It has to be = faster mostly in sequential IO, seeks are only present when transferring = journal data to the main drives while under simultaneous write IO from=20 the file system. Ideally, the journal drive would have to deliver at=20 least twice as sequential IO as the main drive to maximize the potential = performance. Thus, using a conveniently small medium as an USB flash=20 drive is not very useful (the high seek rate will remain unused and=20 sequential performance is generally lower than regular drives) I've done some benchmarking. The setup is: three 7.5k RPM drives, two in = RAID0, one for the journal. Here's a summary of the results: UFS+SU: bonnie++: writes: 102 MB/s, rewrites: 47 MB/s, reads: 103 MB/s postmark: 110 trans/s UFS+GJ: bonnie++: writes: 35 MB/s, rewrites: 22 MB/s, reads: 99 MB/s postmark: 123 trans/s UFS+GJ-detached: bonnie++: writes: 46 MB/s, rewrites: 36 MB/s, reads: 100 MB/s postmark: 263 trans/s Postmark is configured to have a bias for writing a lot of small files,=20 and benefits a lot from the detached journal. Margins of errors are=20 around +/- 3 MB/s for bonnie++ and around 15 trans/s for postmark. For comparison, here are the results for Linux 2.6.23, regular ext3: bonnie++: writes: 105 MB/s, rewrites: 52 MB/s, reads: 128 MB/s postmark: 173 trans/s --------------enigABE262E7FCBEA5D933381A10 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHplBNldnAQVacBcgRAuMyAJ0ce6nqja0lrkrGRAInm8Xn74fZVQCgsl5h +N3qni0MsBUnACGru8blBno= =RTXJ -----END PGP SIGNATURE----- --------------enigABE262E7FCBEA5D933381A10-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 3 23:45:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C93DF16A418 for ; Sun, 3 Feb 2008 23:45:04 +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 4D57413C468 for ; Sun, 3 Feb 2008 23:45:04 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JLoWE-0001vK-7l for freebsd-stable@freebsd.org; Sun, 03 Feb 2008 23:45:02 +0000 Received: from 78-1-113-112.adsl.net.t-com.hr ([78.1.113.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Feb 2008 23:45:02 +0000 Received: from ivoras by 78-1-113-112.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Feb 2008 23:45:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 04 Feb 2008 00:40:28 +0100 Lines: 47 Message-ID: References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> <3aaaa3a0802031323obec30f0ubf23dfd01557d287@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0E678FF0F26DAA55DC9F80D5" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-113-112.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <3aaaa3a0802031323obec30f0ubf23dfd01557d287@mail.gmail.com> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: gjournal panic 7.0-RC1 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, 03 Feb 2008 23:45:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0E678FF0F26DAA55DC9F80D5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Chris wrote: >> AFAIK this means that the journal is too small for your machine - try >> doubling it until there are no more panics. >> >> If so, this is the same class of errors as ZFS (some would call it >> "tuning errors"), only this time the space reserved for the on-disk >> journal is too small, and the fast drives fill it up before data can b= e >> transfered from the journal to the data area. >> >> >> >=20 > To double it is to do another newfs and start from scratch again or > can I somehow increase the size without losing the data on the drive? If you use an external journal, you can re-create the journal keep the=20 data, if you use an "inline" journal on the same drive as the file=20 system (the default configuration), you need to re-create both the=20 journal and the file system (newfs). > Does a larger journal incease write speeds as I am finding them very > poor around 60% of a sync + soft updates drive. No. An external journal could help you to increase the performance. --------------enig0E678FF0F26DAA55DC9F80D5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHplDsldnAQVacBcgRAiVBAKDjGkq4G+F1QHyeAFuW0+Ky/459gQCdFDks OvTBenUnNw2OvzHEM0+hXX0= =wm6d -----END PGP SIGNATURE----- --------------enig0E678FF0F26DAA55DC9F80D5-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 03:52:53 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6670916A419 for ; Mon, 4 Feb 2008 03:52:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.freebsd.org (Postfix) with ESMTP id 0B64013C50C for ; Mon, 4 Feb 2008 03:52:52 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1640921wxd.7 for ; Sun, 03 Feb 2008 19:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=n5qQ5DHzfnqZvDf6QdKZMeFdImnqDIJz/VtaUI7HPQo=; b=SbBlyo/6U1UwHeIcx9UT8Xk6ZVdNxxPwoSjIkUjNEu/6qYx3yJYEoIyBxxdT37U7xhTZJ+QJTJbibW85s0BSJLTs7+B1dsHW3CqF4QRH3FsJHdXD2EwN54fKmjoFR7dh4kCIItL/AWRJj3OeesbICmLXG2ir9+vRyGeJlq2W8gk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=xOBglg+gy23r1+B3SEngE6OKTTUPiVNmkYC7aG8i1YMN1qLMea7/0UC0hJTdmrkdxaJ2gUhnr9fSL4dYt5Lj1UtxyKod3r3JczmCWgG5hGBSgOTbJhmGhX3GUOjO3QoU0Dp9846XesXB+dytMtTeWbbbcwGbTLc3ZyvmochiR7M= Received: by 10.150.189.9 with SMTP id m9mr2727960ybf.142.1202097172399; Sun, 03 Feb 2008 19:52:52 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 5sm12124264wrh.27.2008.02.03.19.52.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Feb 2008 19:52:50 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m143qiLd028721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 12:52:45 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m143qgI6028720; Mon, 4 Feb 2008 12:52:42 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 4 Feb 2008 12:52:42 +0900 From: Pyun YongHyeon To: Andriy Gapon Message-ID: <20080204035242.GA28554@cdnetworks.co.kr> References: <47A3041D.5050402@icyb.net.ua> <20080201123603.GA14050@cdnetworks.co.kr> <47A321BB.1060708@icyb.net.ua> <47A32501.7080703@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <47A32501.7080703@icyb.net.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org, yongari@freebsd.org Subject: Re: 6.3 nfe: strange behavior after hand X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 03:52:53 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 01, 2008 at 03:56:17PM +0200, Andriy Gapon wrote: > on 01/02/2008 15:42 Andriy Gapon said the following: > > on 01/02/2008 14:36 Pyun YongHyeon said the following: > >> After applying attached patch and let me know the output of > >> "devid : xxx, revid : xxx, pwr = xxx". It would be even better > >> if you can show me the above message for working/non-working case. > >> > >> > > > > Applied the patch with correction to actually print rev instead of dev > > for the second time :-) > > This is in working case: > > devid : 269, revid : a3, pwr = 00000003 > > A clarification: I just applied the patch, recompiled and re-loaded the > module. There was no reboot/poweroff/reset in between. > > > Will wait for the non-working situation. > > > Revert previous patch and try attached patch again and let me know how it goes. -- Regards, Pyun YongHyeon --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nfe.diff2" --- sys/dev/nfe/if_nfe.c.orig 2008-02-02 04:36:24.000000000 +0900 +++ sys/dev/nfe/if_nfe.c 2008-02-04 12:47:11.000000000 +0900 @@ -763,12 +763,6 @@ if ((sc->nfe_flags & NFE_PWR_MGMT) == 0) return; - NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_RESET | NFE_RXTX_BIT2); - NFE_WRITE(sc, NFE_MAC_RESET, NFE_MAC_RESET_MAGIC); - DELAY(100); - NFE_WRITE(sc, NFE_MAC_RESET, 0); - DELAY(100); - NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_BIT2); pwr = NFE_READ(sc, NFE_PWR2_CTL); pwr &= ~NFE_PWR2_WAKEUP_MASK; if (sc->nfe_revid >= 0xa3 && @@ -776,6 +770,12 @@ sc->nfe_devid == PCI_PRODUCT_NVIDIA_NFORCE430_LAN2)) pwr |= NFE_PWR2_REVA3; NFE_WRITE(sc, NFE_PWR2_CTL, pwr); + NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_RESET | NFE_RXTX_BIT2); + NFE_WRITE(sc, NFE_MAC_RESET, NFE_MAC_RESET_MAGIC); + DELAY(100); + NFE_WRITE(sc, NFE_MAC_RESET, 0); + DELAY(100); + NFE_WRITE(sc, NFE_RXTX_CTL, NFE_RXTX_BIT2); } --7AUc2qLy4jB3hD7Z-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 05:31:19 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8DF216A417 for ; Mon, 4 Feb 2008 05:31:19 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 90E9F13C46B for ; Mon, 4 Feb 2008 05:31:19 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1JLtLC-000JiF-7N for freebsd-stable@freebsd.org; Mon, 04 Feb 2008 12:53:58 +0800 Message-ID: <47A69A66.2080109@micom.mng.net> Date: Mon, 04 Feb 2008 12:53:58 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.9 (X11/20071225) MIME-Version: 1.0 To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: /dev/cuad0: Device busy 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, 04 Feb 2008 05:31:19 -0000 Hi, I'm trying to use serial port but the system says device busy. daemon# cu -l /dev/cuad0 -s 9600 /dev/cuad0: Device busy link down daemon# uname -an FreeBSD daemon.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #0: Mon Jan 14 16:49:57 ULAT 2008 tsgan@daemon.micom.mng.net:/usr/obj/usr/src/sys/GDAEMON i386 It seems like no other program is using serial port. How to check whether something is using serial port? Any idea? thanks, Ganbold -- If you think the problem is bad now, just wait until we've solved it. -- Arthur Kasspe From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 05:37:49 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B83C16A419 for ; Mon, 4 Feb 2008 05:37:49 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 04F3113C43E for ; Mon, 4 Feb 2008 05:37:48 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m145bjFO018304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 16:07:46 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Mon, 4 Feb 2008 16:07:32 +1030 User-Agent: KMail/1.9.7 References: <47A69A66.2080109@micom.mng.net> In-Reply-To: <47A69A66.2080109@micom.mng.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3391462.Us6umr4DTO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200802041607.34493.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Ganbold Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 05:37:49 -0000 --nextPart3391462.Us6umr4DTO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 4 Feb 2008, Ganbold wrote: > I'm trying to use serial port but the system says device busy. > > daemon# cu -l /dev/cuad0 -s 9600 > /dev/cuad0: Device busy > link down What does fstat /dev/cuad0 say? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3391462.Us6umr4DTO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHpqSe5ZPcIHs/zowRAvwzAJ4zMiylhJ4g7gvXQfMNGR/tkF2JaQCcCjE7 Anv2347SE1uOwcHQDupTZgs= =14j3 -----END PGP SIGNATURE----- --nextPart3391462.Us6umr4DTO-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 06:25:39 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57FB716A418 for ; Mon, 4 Feb 2008 06:25:39 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA3F13C442 for ; Mon, 4 Feb 2008 06:25:38 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1JLult-000KIh-Gb; Mon, 04 Feb 2008 14:25:37 +0800 Message-ID: <47A6AFE1.7060305@micom.mng.net> Date: Mon, 04 Feb 2008 14:25:37 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.9 (X11/20071225) MIME-Version: 1.0 To: Daniel O'Connor References: <47A69A66.2080109@micom.mng.net> <200802041607.34493.doconnor@gsoft.com.au> In-Reply-To: <200802041607.34493.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 06:25:39 -0000 Daniel O'Connor wrote: > On Mon, 4 Feb 2008, Ganbold wrote: > >> I'm trying to use serial port but the system says device busy. >> >> daemon# cu -l /dev/cuad0 -s 9600 >> /dev/cuad0: Device busy >> link down >> > > What does fstat /dev/cuad0 say? > > It says: daemon# fstat /dev/cuad0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME daemon# Ganbold -- We'll have solar energy when the power companies develop a sunbeam meter. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 06:30:23 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31C0516A418 for ; Mon, 4 Feb 2008 06:30:23 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 201F013C4DB for ; Mon, 4 Feb 2008 06:30:23 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 0F43E1CC038; Sun, 3 Feb 2008 22:30:23 -0800 (PST) Date: Sun, 3 Feb 2008 22:30:23 -0800 From: Jeremy Chadwick To: Ganbold Message-ID: <20080204063023.GA91789@eos.sc1.parodius.com> References: <47A69A66.2080109@micom.mng.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A69A66.2080109@micom.mng.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Stable Mailing List Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 06:30:23 -0000 On Mon, Feb 04, 2008 at 12:53:58PM +0800, Ganbold wrote: > Hi, > > I'm trying to use serial port but the system says device busy. > > daemon# cu -l /dev/cuad0 -s 9600 > /dev/cuad0: Device busy > link down Does the same happen if you do `cu -l ttyd0 -s 9600`? > How to check whether something is using serial port? > Any idea? fstat should help here. -- | 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 Feb 4 06:37:34 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F0316A419 for ; Mon, 4 Feb 2008 06:37:34 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 173B213C448 for ; Mon, 4 Feb 2008 06:37:33 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1JLuxP-000KPq-OR; Mon, 04 Feb 2008 14:37:32 +0800 Message-ID: <47A6B2AB.2060308@micom.mng.net> Date: Mon, 04 Feb 2008 14:37:31 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.9 (X11/20071225) MIME-Version: 1.0 To: Jeremy Chadwick References: <47A69A66.2080109@micom.mng.net> <20080204063023.GA91789@eos.sc1.parodius.com> In-Reply-To: <20080204063023.GA91789@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Mailing List Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 06:37:34 -0000 Jeremy Chadwick wrote: > On Mon, Feb 04, 2008 at 12:53:58PM +0800, Ganbold wrote: > >> Hi, >> >> I'm trying to use serial port but the system says device busy. >> >> daemon# cu -l /dev/cuad0 -s 9600 >> /dev/cuad0: Device busy >> link down >> > > Does the same happen if you do `cu -l ttyd0 -s 9600`? > It works and fstat shows: daemon# fstat /dev/cuad0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME daemon# fstat /dev/ttyd0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root cu 5574 3 /dev 41 crw------- ttyd0 rw /dev/ttyd0 root cu 5573 3 /dev 41 crw------- ttyd0 rw /dev/ttyd0 daemon# Is it expected behaviour? thanks, Ganbold > >> How to check whether something is using serial port? >> Any idea? >> > > fstat should help here. > > -- Success is in the minds of Fools. -- William Wrenshaw, 1578 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 06:51:22 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E20C316A419 for ; Mon, 4 Feb 2008 06:51:22 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id CED5913C458 for ; Mon, 4 Feb 2008 06:51:22 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 931111CC033; Sun, 3 Feb 2008 22:51:22 -0800 (PST) Date: Sun, 3 Feb 2008 22:51:22 -0800 From: Jeremy Chadwick To: Ganbold Message-ID: <20080204065122.GA92674@eos.sc1.parodius.com> References: <47A69A66.2080109@micom.mng.net> <20080204063023.GA91789@eos.sc1.parodius.com> <47A6B2AB.2060308@micom.mng.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A6B2AB.2060308@micom.mng.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Stable Mailing List Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 06:51:23 -0000 On Mon, Feb 04, 2008 at 02:37:31PM +0800, Ganbold wrote: > Jeremy Chadwick wrote: >> On Mon, Feb 04, 2008 at 12:53:58PM +0800, Ganbold wrote: >> >>> Hi, >>> >>> I'm trying to use serial port but the system says device busy. >>> >>> daemon# cu -l /dev/cuad0 -s 9600 >>> /dev/cuad0: Device busy >>> link down >>> >> >> Does the same happen if you do `cu -l ttyd0 -s 9600`? >> > > It works and fstat shows: > > daemon# fstat /dev/cuad0 > USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME > daemon# fstat /dev/ttyd0 > USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME > root cu 5574 3 /dev 41 crw------- ttyd0 rw > /dev/ttyd0 > root cu 5573 3 /dev 41 crw------- ttyd0 rw > /dev/ttyd0 > daemon# > > Is it expected behaviour? As far as I know, yes. On all of our machines which utilise getty(8) on ttyd0 (as listed in /etc/ttys): $ grep ttyd0 /etc/ttys ttyd0 "/usr/libexec/getty std.115200" xterm on secure $ fstat /dev/ttyd0 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root getty 37376 0 /dev 36 crw------- ttyd0 rw /dev/ttyd0 root getty 37376 1 /dev 36 crw------- ttyd0 rw /dev/ttyd0 root getty 37376 2 /dev 36 crw------- ttyd0 rw /dev/ttyd0 Additionally, see Section 23.2.5 of the below document: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serial.html Personally, I never understood the concept of "dial-in" and "call-out" devices on FreeBSD. I ran BBS software for years on both Apple II hardware and PC hardware; there was no distinction between such devices. A serial port is a serial port. Chances are I'm not understanding why there's a distinction, but there doesn't appear to be any explanation of why there's a distinction within manpages or the handbook... -- | 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 Feb 4 07:08:36 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDD7916A417 for ; Mon, 4 Feb 2008 07:08:36 +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 4748413C465 for ; Mon, 4 Feb 2008 07:08:35 +0000 (UTC) (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 m1478WYm000724; Mon, 4 Feb 2008 14:08:32 +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 m1478Wvq000723; Mon, 4 Feb 2008 14:08:32 +0700 (KRAT) (envelope-from eugen) Date: Mon, 4 Feb 2008 14:08:32 +0700 From: Eugene Grosbein To: Jeremy Chadwick Message-ID: <20080204070832.GA97372@svzserv.kemerovo.su> References: <47A69A66.2080109@micom.mng.net> <20080204063023.GA91789@eos.sc1.parodius.com> <47A6B2AB.2060308@micom.mng.net> <20080204065122.GA92674@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080204065122.GA92674@eos.sc1.parodius.com> User-Agent: Mutt/1.4.2.3i Cc: Ganbold , FreeBSD Stable Mailing List Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 07:08:37 -0000 > Personally, I never understood the concept of "dial-in" and "call-out" > devices on FreeBSD. I ran BBS software for years on both Apple II > hardware and PC hardware; there was no distinction between such devices. > A serial port is a serial port. Chances are I'm not understanding why > there's a distinction, but there doesn't appear to be any explanation of > why there's a distinction within manpages or the handbook... The distinction exists to allow an application to wait on the "dial-in" port for incoming calls and another application to make outgoing call mean time using the same port as "call-out" while the port is idle. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 09:21:56 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7B2F16A46C for ; Mon, 4 Feb 2008 09:21:56 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 3D29813C469 for ; Mon, 4 Feb 2008 09:21:55 +0000 (UTC) (envelope-from grafan@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2069934fgg.35 for ; Mon, 04 Feb 2008 01:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=Qiic39Qc5mrLSXu8BBehVVe7dTTyiOEBpB99t6mlNho=; b=UVktXXD5vAmQdQ41leGoqYbxNT0XNN+E8yNCFZJG0COSdlz8bkbz1x+0hfnpHRRFoKhcq3o5z4YSpxS7jlmrJP0j+Ot3evwtRNOpWNxxBS39uGI/kOO1zBLaMTMvabeXQ0NRs/ISFm4Vrh+thpCJzOXh7+ZeFynPx7znxnpT2K4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=j8cjcsUElJikM37uPGHexhhYmXerSA+ed3hthfuZzVWQ90cDxm+CpxCQPkge16DlgBFmRT8GakQ1a2dFjDTW/kUH1HrIvIK28fxum2bp8aZEemXY/ZYShhMRyxnmjEfFL2CEHm4CHu7moHFuj2YxjnCgvlEbQMCyBmmd408ni3I= Received: by 10.82.181.7 with SMTP id d7mr12634351buf.8.1202115421836; Mon, 04 Feb 2008 00:57:01 -0800 (PST) Received: by 10.82.115.11 with HTTP; Mon, 4 Feb 2008 00:57:01 -0800 (PST) Message-ID: <6eb82e0802040057l19b5ff72g76884e0973ef1024@mail.gmail.com> Date: Mon, 4 Feb 2008 16:57:01 +0800 From: "Rong-en Fan" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Cc: wens@csie.org Subject: 6.3 panic (seems hptmv 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, 04 Feb 2008 09:21:57 -0000 V2UgaGF2ZSBhIGJveCBydW5uaW5nIDYuMi1SRUxFQVNFIHNtb290aGx5LCBvbmNlIHdlIGJvb3QK d2l0aCA2LjMtUkVMRUFTRS4gSXQgcGFuaWNzIGluIGhwdG12MCwgSSBoYXZlIGtlcm5lbCBkdW1w IGF2YWlsYWJsZS4KQW55IGlkZWFzPwoKUmVnYXJkcywKUm9uZy1FbiBGYW4KCkZhdGFsIHRyYXAg MTI6IHBhZ2UgZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUKZmF1bHQgdmlydHVhbCBhZGRyZXNz CT0gMHhmZmZmZmZmYjU0NDRlZmM1CmZhdWx0IGNvZGUJCT0gc3VwZXJ2aXNvciByZWFkIGRhdGEs IHBhZ2Ugbm90IHByZXNlbnQKaW5zdHJ1Y3Rpb24gcG9pbnRlcgk9IDB4ODoweGZmZmZmZmZmODAz MmFjNjYKc3RhY2sgcG9pbnRlcgkgICAgICAgID0gMHgxMDoweGZmZmZmZmZmYTUzMzRiOTAKZnJh bWUgcG9pbnRlcgkgICAgICAgID0gMHgxMDoweDAKY29kZSBzZWdtZW50CQk9IGJhc2UgMHgwLCBs aW1pdCAweGZmZmZmLCB0eXBlIDB4MWIKCQkJPSBEUEwgMCwgcHJlcyAxLCBsb25nIDEsIGRlZjMy IDAsIGdyYW4gMQpwcm9jZXNzb3IgZWZsYWdzCT0gaW50ZXJydXB0IGVuYWJsZWQsIHJlc3VtZSwg SU9QTCA9IDAKY3VycmVudCBwcm9jZXNzCQk9IDIyIChpcnExOTogaHB0bXYwKQp0cmFwIG51bWJl cgkJPSAxMgpwYW5pYzogcGFnZSBmYXVsdApVcHRpbWU6IDJtNDZzCkR1bXBpbmcgMTAyMyBNQiAo MiBjaHVua3MpCiAgY2h1bmsgMDogMU1CICgxNTkgcGFnZXMpIC4uLiBvawogIGNodW5rIDE6IDEw MjNNQiAoMjYxODA4IHBhZ2VzKSAxMDA3IDk5MSA5NzUgOTU5IDk0MyA5MjcgOTExIDg5NSA4NzkK ODYzIDg0NyA4MzEgODE1IDc5OSA3ODMgNzY3IDc1MSA3MzUgNzE5IDcwMyA2ODcgNjcxIDY1NSA2 MzkgNjIzIDYwNwo1OTEgNTc1IDU1OSA1NDMgNTI3IDUxMSA0OTUgNDc5IDQ2MyA0NDcgNDMxIDQx NSAzOTkgMzgzIDM2NyAzNTEgMzM1CjMxOSAzMDMgMjg3IDI3MSAyNTUgMjM5IDIyMyAyMDcgMTkx IDE3NSAxNTkgMTQzIDEyNyAxMTEgOTUgNzkgNjMgNDcgMzEKMTUKCiMwICBkb2FkdW1wICgpIGF0 IHBjcHUuaDoxNzIKMTcyCQlfX2FzbSBfX3ZvbGF0aWxlKCJtb3ZxICUlZ3M6MCwlMCIgOiAiPXIi ICh0ZCkpOwooa2dkYikgYnQgZnVsbAojMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MTcyCk5vIGxv Y2Fscy4KIzEgIDB4MDAwMDAwMDAwMDAwMDAwNCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuCiMyICAweGZmZmZmZmZmODAyMWEwODMgaW4gYm9vdCAoaG93dG89MjYwKQog ICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjQwOQoJZmlyc3RfYnVmX3By aW50ZiA9IDEKIzMgIDB4ZmZmZmZmZmY4MDIxYTY4NiBpbiBwYW5pYyAoZm10PTB4ZmZmZmZmMDAz ZGJhMjk4MCAiwrA2wrk9IikKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24u Yzo1NjUKCWJvb3RvcHQgPSAyNjAKCW5ld3BhbmljID0gMAoJYXAgPSB7e2dwX29mZnNldCA9IDE2 LCBmcF9vZmZzZXQgPSA0OCwKICAgIG92ZXJmbG93X2FyZ19hcmVhID0gMHhmZmZmZmZmZmE1MzM0 YTAwLAogICAgcmVnX3NhdmVfYXJlYSA9IDB4ZmZmZmZmZmZhNTMzNDkzMH19CglidWYgPSAicGFn ZSBmYXVsdCIsICdcMCcgPHJlcGVhdHMgMjQ1IHRpbWVzPgojNCAgMHhmZmZmZmZmZjgwMzQ5ZTQx IGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4ZmZmZmZmMDAzZGJhMjk4MCwKICAgIGV2YT0xODQ0Njc0 Mjk3NTIzMzQ3MjE3NikgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAuYzo2NjkKCWNv ZGUgPSAxMgoJc3MgPSAxMgoJdHlwZSA9IDEyCgllc3AgPSAwCglzb2Z0c2VnID0ge3NzZF9iYXNl ID0gMCwgc3NkX2xpbWl0ID0gMTA0ODU3NSwgc3NkX3R5cGUgPSAyNywKICBzc2RfZHBsID0gMCwg c3NkX3AgPSAxLCBzc2RfbG9uZyA9IDEsIHNzZF9kZWYzMiA9IDAsIHNzZF9ncmFuID0gMX0KCW1z ZyA9IDB4MAojNSAgMHhmZmZmZmZmZjgwMzRhMWIyIGluIHRyYXBfcGZhdWx0IChmcmFtZT0weGZm ZmZmZmZmYTUzMzRhZTAsIHVzZXJtb2RlPTApCiAgICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1k NjQvdHJhcC5jOjU4MAoJdmEgPSAxODQ0Njc0NDA1MzY0ODUxNTA3MgoJdm0gPSAoc3RydWN0IHZt c3BhY2UgKikgMHgwCgltYXAgPSAweDEKCXJ2ID0gMQoJZnR5cGUgPSAxICdcMDAxJwoJcCA9IChz dHJ1Y3QgcHJvYyAqKSAweDAKCWV2YSA9IDE4NDQ2NzQ0MDUzNjQ4NTE5MTA5CiM2ICAweGZmZmZm ZmZmODAzNGE0NjMgaW4gdHJhcCAoZnJhbWU9CiAgICAgIHt0Zl9yZGkgPSAtMjE0NDE0OTE5NSwg dGZfcnNpID0gLTIxNDIxNjQwMjQsIHRmX3JkeCA9IDAsIHRmX3JjeAo9IDMxNzUxNjIwODIsIHRm X3I4ID0gMTUzNiwgdGZfcjkgPSA5NywgdGZfcmF4ID0gLTIwMDYxMDMyNjE5LCB0Zl9yYngKPSAt MjE0NDE0OTE5NSwgdGZfcmJwID0gMCwgdGZfcjEwID0gLTIxNDIyODA5MzYsIHRmX3IxMSA9IC0y MDU0MjU5MTY4LAp0Zl9yMTIgPSA0LCB0Zl9yMTMgPSAwLCB0Zl9yMTQgPSAtMTA5OTUwMzQ0Mjgx NiwgdGZfcjE1ID0KLTEwOTg0NzYwMTcyODAsIHRmX3RyYXBubyA9IDEyLCB0Zl9hZGRyID0gLTIw MDYxMDMyNTA3LCB0Zl9mbGFncyA9Ci0xMDk4NDc2MDc5NDQwLCB0Zl9lcnIgPSAwLCB0Zl9yaXAg PSAtMjE0NDE2MjcxNCwgdGZfY3MgPSA4LCB0Zl9yZmxhZ3MKPSA2NjE4MywgdGZfcnNwID0gLTE1 MjMzNjQ5NjAsIHRmX3NzID0gMTZ9KQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3Ry YXAuYzozNTMKCXAgPSAoc3RydWN0IHByb2MgKikgMHhmZmZmZmYwMDNkYjkzNmIwCglzdGlja3Mg PSA0Mjk0OTY3Mjk1Cgl0eXBlID0gMwoJaSA9IDAKCXVjb2RlID0gMAoJY29kZSA9IDAKIzcgIDB4 ZmZmZmZmZmY4MDMzNGRiYiBpbiBjYWxsdHJhcCAoKQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0 L2FtZDY0L2V4Y2VwdGlvbi5TOjE2OApObyBsb2NhbHMuCiM4ICAweGZmZmZmZmZmODAzMmFjNjYg aW4gQ2hlY2tQZW5kaW5nQ2FsbCAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM5 ICAweGZmZmZmZmZmODAzNTY4MWMgaW4gaHB0X2ludHIgKGFyZz0weGZmZmZmZmZmODAzMmRmMjUp CiAgICBhdCAvdXNyL3NyYy9zeXMvZGV2L2hwdG12L2VudHJ5LmM6MjAzOQoJX3ZidXNfcCA9IDB4 ZmZmZmZmZmY4MDMyZTEzNQoJb2xkc3BsID0gMAojMTAgMHhmZmZmZmZmZjgwMjAwMzM1IGluIGl0 aHJlYWRfbG9vcCAoYXJnPTB4ZmZmZmZmMDAwMDdjZTQ4MCkKICAgIGF0IC91c3Ivc3JjL3N5cy9r ZXJuL2tlcm5faW50ci5jOjY4MgoJaWUgPSAoc3RydWN0IGludHJfZXZlbnQgKikgMHhmZmZmZmYw MDAwMDA5ODAwCiMxMSAweGZmZmZmZmZmODAxZmVkODMgaW4gZm9ya19leGl0ICgKICAgIGNhbGxv dXQ9MHhmZmZmZmZmZjgwMjAwMWYwIDxpdGhyZWFkX2xvb3A+LCBhcmc9MHhmZmZmZmYwMDAwN2Nl NDgwLAogICAgZnJhbWU9MHhmZmZmZmZmZmE1MzM0YzUwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX2ZvcmsuYzo3ODgKCXAgPSAoc3RydWN0IHByb2MgKikgMHhmZmZmZmYwMDNkYjkzNmIwCiMx MiAweGZmZmZmZmZmODAzMzUxN2UgaW4gZm9ya190cmFtcG9saW5lICgpCiAgICBhdCAvdXNyL3Ny Yy9zeXMvYW1kNjQvYW1kNjQvZXhjZXB0aW9uLlM6NDExCk5vIGxvY2Fscy4KIzEzIDB4MDAwMDAw MDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxNCAw eDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxl LgojMTUgMHgwMDAwMDAwMDAwMDAwMDAxIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2 YWlsYWJsZS4KIzE2IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUg aW5mbyBhdmFpbGFibGUuCiMxNyAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9s IHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTggMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE5IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyMCAweDAwMDAwMDAwMDAwMDAw MDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjEgMHgwMDAwMDAw MDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIyIDB4 MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUu CiMyMyAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojMjQgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBp bmZvIGF2YWlsYWJsZS4KIzI1IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wg dGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNiAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjcgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI4IDB4MDAwMDAwMDAwMDAwMDAw MCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyOSAweDAwMDAwMDAw MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzAgMHgw MDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzMxIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFp bGFibGUuCiMzMiAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGlu Zm8gYXZhaWxhYmxlLgojMzMgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0 YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM0IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzYgMHgwMDAwMDAwMDAwMDAwMDAw IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM3IDB4MDAwMDAwMDAw MDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzOCAweDAw MDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoj MzkgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWls YWJsZS4KIzQwIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuCiM0MSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRh YmxlIGluZm8gYXZhaWxhYmxlLgojNDIgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQzIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0NCAweDAwMDAwMDAwMDAwMDAwMDAg aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDUgMHgwMDAwMDAwMDAw NmJkMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQ2IDB4ZmZm ZmZmMDAzZGJhMjk4MCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0 NyAweGZmZmZmZjAwMDA3Y2U0ODAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxh YmxlLgojNDggMHgwMDAwMDAwMDAwMDAwMDAxIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZv IGF2YWlsYWJsZS4KIzQ5IDB4ZmZmZmZmMDAzZGI5MzZiMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFi bGUgaW5mbyBhdmFpbGFibGUuCiM1MCAweGZmZmZmZjAwM2RiYmMyNjAgaW4gPz8gKCkKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNTEgMHhmZmZmZmZmZmE1MzM0YjU4IGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzUyIDB4ZmZmZmZmMDAzZGJhMjk4MCBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM1MyAweGZmZmZmZmZmODAy MmZhMDYgaW4gc2NoZWRfc3dpdGNoICh0ZD0weGZmZmZmZjAwMDA3Y2U0ODAsIG5ld3RkPTB4MCwK ICAgIGZsYWdzPTApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkXzRic2QuYzo5NzMKCWtnID0g KHN0cnVjdCBrc2VncnAgKikgMHhmZmZmZmZmYjU0NDRlZjU1CglwID0gKHN0cnVjdCBwcm9jICop IDB4ZmZmZmZmZmY4MDIwMDFmMAojNTQgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzU1IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM1NiAweDAwMDAwMDAwMDAwMDAwMDAg aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNTcgMHgwMDAwMDAwMDAw MDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzU4IDB4MDAw MDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM1 OSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxh YmxlLgojNjAgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZv IGF2YWlsYWJsZS4KIzYxIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFi bGUgaW5mbyBhdmFpbGFibGUuCiM2MiAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNjMgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzY0IDB4MDAwMDAwMDAwMDAwMDAwMCBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM2NSAweDAwMDAwMDAwMDAw MDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNjYgMHgwMDAw MDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzY3 IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi bGUuCiM2OCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8g YXZhaWxhYmxlLgojNjkgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJs ZSBpbmZvIGF2YWlsYWJsZS4KIzcwIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1i b2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM3MSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNzIgMHgwMDAwMDAwMDAwMDAwMDAwIGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzczIDB4MDAwMDAwMDAwMDAw MDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM3NCAweDAwMDAw MDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNzUg MHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJs ZS4KIzc2IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBh dmFpbGFibGUuCiM3NyAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxl IGluZm8gYXZhaWxhYmxlLgojNzggMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJv bCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzc5IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM4MCAweDAwMDAwMDAwMDAwMDAwMDAgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojODEgMHgwMDAwMDAwMDAwMDAw MDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzgyIDB4MDAwMDAw MDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM4MyAw eDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxl LgojODQgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2 YWlsYWJsZS4KIzg1IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUg aW5mbyBhdmFpbGFibGUuCiM4NiAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9s IHRhYmxlIGluZm8gYXZhaWxhYmxlLgojODcgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzg4IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM4OSAweDAwMDAwMDAwMDAwMDAw MDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojOTAgMHgwMDAwMDAw MDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzkxIDB4 MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUu CiM5MiAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojOTMgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBp bmZvIGF2YWlsYWJsZS4KIzk0IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wg dGFibGUgaW5mbyBhdmFpbGFibGUuCiM5NSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojOTYgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzk3IDB4MDAwMDAwMDAwMDAwMDAw MCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM5OCAweDAwMDAwMDAw MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojOTkgMHgw MDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzEwMCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojMTAxIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUg aW5mbyBhdmFpbGFibGUuCiMxMDIgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJv bCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzEwMyAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTA0IDB4MDAwMDAwMDAwMDAwMDAwMCBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxMDUgMHgwMDAwMDAwMDAw MDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzEwNiAweDAw MDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoj MTA3IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFp bGFibGUuCiMxMDggMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBp bmZvIGF2YWlsYWJsZS4KIzEwOSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9s IHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTEwIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxMTEgMHgwMDAwMDAwMDAwMDAwMDAwIGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzExMiAweDAwMDAwMDAwMDAw MDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTEzIDB4MDAw MDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMx MTQgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWls YWJsZS4KIzExNSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGlu Zm8gYXZhaWxhYmxlLgojMTE2IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wg dGFibGUgaW5mbyBhdmFpbGFibGUuCiMxMTcgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzExOCAweDAwMDAwMDAwMDAwMDAwMDAgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTE5IDB4MDAwMDAwMDAwMDAw MDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxMjAgMHgwMDAw MDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzEy MSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxh YmxlLgojMTIyIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuCiMxMjMgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0 YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzEyNCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTI1IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCihrZ2RiKSBxdWl0Cg== From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 12:04:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81A3716A477; Mon, 4 Feb 2008 12:04:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id 3A31213C501; Mon, 4 Feb 2008 12:04:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m14C4lTO074894; Mon, 4 Feb 2008 23:04:48 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802041204.m14C4lTO074894@drugs.dv.isc.org> To: Eugene Grosbein From: Mark Andrews In-reply-to: Your message of "Mon, 04 Feb 2008 14:08:32 +0700." <20080204070832.GA97372@svzserv.kemerovo.su> Date: Mon, 04 Feb 2008 23:04:47 +1100 Sender: marka@isc.org Cc: Jeremy Chadwick , FreeBSD Stable Mailing List , Ganbold Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 12:04:50 -0000 > > Personally, I never understood the concept of "dial-in" and "call-out" > > devices on FreeBSD. I ran BBS software for years on both Apple II > > hardware and PC hardware; there was no distinction between such devices. > > A serial port is a serial port. Chances are I'm not understanding why > > there's a distinction, but there doesn't appear to be any explanation of > > why there's a distinction within manpages or the handbook... > > The distinction exists to allow an application to wait on the "dial-in" > port for incoming calls and another application to make outgoing call > mean time using the same port as "call-out" while the port is idle. And once there is a incoming call block out going calls until the incoming call completes. > > Eugene Grosbein > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 13:10:20 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DCAC16A46B for ; Mon, 4 Feb 2008 13:10:20 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4938C13C461 for ; Mon, 4 Feb 2008 13:10:20 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 432171CC033; Mon, 4 Feb 2008 05:10:20 -0800 (PST) Date: Mon, 4 Feb 2008 05:10:20 -0800 From: Jeremy Chadwick To: Eugene Grosbein Message-ID: <20080204131020.GA5830@eos.sc1.parodius.com> References: <47A69A66.2080109@micom.mng.net> <20080204063023.GA91789@eos.sc1.parodius.com> <47A6B2AB.2060308@micom.mng.net> <20080204065122.GA92674@eos.sc1.parodius.com> <20080204070832.GA97372@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080204070832.GA97372@svzserv.kemerovo.su> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Ganbold , FreeBSD Stable Mailing List Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 13:10:20 -0000 On Mon, Feb 04, 2008 at 02:08:32PM +0700, Eugene Grosbein wrote: > > Personally, I never understood the concept of "dial-in" and "call-out" > > devices on FreeBSD. I ran BBS software for years on both Apple II > > hardware and PC hardware; there was no distinction between such devices. > > A serial port is a serial port. Chances are I'm not understanding why > > there's a distinction, but there doesn't appear to be any explanation of > > why there's a distinction within manpages or the handbook... > > The distinction exists to allow an application to wait on the "dial-in" > port for incoming calls and another application to make outgoing call > mean time using the same port as "call-out" while the port is idle. This is intruiging to me, because now I'm left wondering how that actually works behind the scenes! :-) What happens when program X has /dev/ttyd0 open (for incoming calls), receives a call, and then during which program Y attempts to open /dev/cuad0? Does program Y indefinitely block/wait somewhere within the kernel until program X releases the fd? If so, then I'm left wondering why Ganbold's cu -l cuad0 attempt returned an immediate EBUSY, rather than blocking indefinitely. Also, the above mechanism must be fairly old, because I imagine it would be more effective to utilise kqueue/kevent to inform said programs of when the serial port is available for use. -- | 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 Feb 4 13:18:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68BA616A4F5 for ; Mon, 4 Feb 2008 13:18:10 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id F002013C505 for ; Mon, 4 Feb 2008 13:18:09 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: by py-out-1112.google.com with SMTP id u52so3272010pyb.10 for ; Mon, 04 Feb 2008 05:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=WVgOsEUjNTIRdK4ajQBoGt56osU15TpGgHyhCRs1Sd4=; b=ZRFAIFgWM6JZ4mBBCBKRQphr/jXTwl64IFelmP2Uni9Pg3Us6Kr5mkkNNazU669HHPFEQzcilZm2XhuGUyOnIRDGg9C81LhqM/NNqsEjWJ/s9N1/crM4yW9Ng7InS1COQLMIkkjaaVib2AjlV6MpQgNBJpe4JlJpSf1+vs1STPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=nxL+FBFwgeuLhR/W526dbK5V95bg3N9vNYertMzVqgi3ExPyAi12rfRuYhwiYsIGWkred+OSaTTkBOIwhBeXN7+XTGntBB/qH0eduhXwzb2DUq/w2WllTICNNEPM61OOXIxd4QzWSPgPDIap9W6pYt36/3ADbxzUYX4+0abZ0B8= Received: by 10.140.169.6 with SMTP id r6mr4686149rve.210.1202129432469; Mon, 04 Feb 2008 04:50:32 -0800 (PST) Received: by 10.140.203.6 with HTTP; Mon, 4 Feb 2008 04:50:32 -0800 (PST) Message-ID: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> Date: Mon, 4 Feb 2008 12:50:32 +0000 From: "Primeroz lists" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 13:18:10 -0000 SGkgYWxsLAoKd2UgYXJlIGV4cGVyaWVuY2luZyByZXBlYXRlZCBjcmFzaCBvbiBhIERlbGwgUG93 ZXJFZGdlIDI5NTAgKHJldiAxIG9yIDIpLgoKRkJTRCByZWxlYXNlIGlzIDYuMi1SRUxFQVNFLXA1 ICwgQU1ENjQuIDJ4WGVvbiBRdWFkQ29yZSBhbmQgOEcgb2YgUmFtLgoKTXlTUUwgVmVyc2lvbiBp cyA1LjAuNDEgd2l0aCBmb2xsb3dpbmcgY29uZmlndXJhdGlvbiBzZXR0aW5nczoKCnNldC12YXJp YWJsZSAgICA9IGtleV9idWZmZXI9NzY4TQpzZXQtdmFyaWFibGUgICAgPSB0YWJsZV9jYWNoZT04 MDAKc2V0LXZhcmlhYmxlICAgID0gc29ydF9idWZmZXI9MjRNCnNldC12YXJpYWJsZSAgICA9IG15 aXNhbV9zb3J0X2J1ZmZlcl9zaXplPTI1Nk0Kc2V0LXZhcmlhYmxlICAgID0gcmVjb3JkX2J1ZmZl cj0xNk0Kc2V0LXZhcmlhYmxlICAgID0gbWF4X2FsbG93ZWRfcGFja2V0PTEwTQpzZXQtdmFyaWFi bGUgICAgPSB0aHJlYWRfc3RhY2s9MTI4SwpzZXQtdmFyaWFibGUgICAgPSBqb2luX2J1ZmZlcj01 MTJNCnNldC12YXJpYWJsZSAgICA9IG1heF9oZWFwX3RhYmxlX3NpemU9MjU2TQpzZXQtdmFyaWFi bGUgICAgPSBtYXhfY29ubmVjdGlvbnM9MzAwCnNldC12YXJpYWJsZSAgICA9IHRtcF90YWJsZV9z aXplPTM4NE0Kc2V0LXZhcmlhYmxlICAgID0gcXVlcnlfY2FjaGVfc2l6ZT00MDI2NTMxODQKc2V0 LXZhcmlhYmxlICAgID0gcXVlcnlfY2FjaGVfbGltaXQ9MTM0MjE3NzI4CnNldC12YXJpYWJsZSAg ICA9IHJlYWRfcm5kX2J1ZmZlcl9zaXplPTEwTQpzZXQtdmFyaWFibGUgICAgPSBmdF9taW5fd29y ZF9sZW49MQpwaWQtZmlsZSAgICAgICAgPSAvdmFyL2RiL215c3FsZC5waWQKdG1wZGlyICAgICAg ICAgID0gL3Zhci90bXAKZnRfc3RvcHdvcmRfZmlsZSA9ICcnCnNldC12YXJpYWJsZSAgICA9IHRo cmVhZF9jYWNoZV9zaXplPTgwCnNldC12YXJpYWJsZSAgICA9IG15aXNhbV9zdGF0c19tZXRob2Q9 bnVsbHNfZXF1YWwKCgpUaGUgc3lzdGVtIGlzIGNyYXNoaW5nIHJlcGVhdGVkbHkgYW5kIGZyb20g dGhlIGdyYXBocyB3ZSBjb2xsZWN0IG9uIHRoZSBib3gKaSBjYW4gc2VlIHRoYXQgZXZlcnkgdGlt ZSBiZWZvcmUgdGhlIGNyYXNoIHdlIGhhdmUgYW4gaW50ZW5zaXZlIHVzYWdlIG9mCipJbm5vREIq IHJlbGF0ZWQgcmVzb3VyY2VzLCBpIGNvbGxlY3RlZCBzZXZlcmFsIHZtY29yZSBkdW1wIGFuZCBh dHRhY2hlZCBpcwp3aGF0IGkndmUgYmVlbiBhYmxlIHRvIGV4dHJhY3QuCgpJJ20gbm90IHN1cmUg aG93IG11Y2ggdGhlICpJbm5vREIqIHVzYWdlIGlzIHJlbGF0ZWQgdG8gdGhlIGNyYXNoLCBidHcg aSdtCnF1aXRlIHN1cmUgdGhhdCBpdCBpcyB0cmlnZ2VyaW5nIHRoZSBjcmFzaC4KCkkndmUgbG9v a2VkIG9uIHRoZSB2YXJpb3VzIENWUyBhbmQgcmVsZWFzZXMgdG8gc2VlIGlmIGFueXRoaW5nIHJl bGF0ZWQgdG8gbXkKY3Jhc2ggaGFzIGJlZW4gdXBkYXRlZCBpbiB0aGUgbGFzdCBwZXJpb2QgYnV0 IGkgZGlkIG5vdCBmaW5kIGFueXRoaW5nCnNwZWNpZmljYWxseSByZWxhdGVkIHNvIGknbSB3b25k ZXJpbmcgaWYgYW55Ym9keSBlbHNlIGhhZCBleHBlcmllbmNlIG9mIHRoaXMKa2luZCBvZiBwcm9i bGVtcyBiZWZvcmUgcHJvY2VkaW5nIHRvIGEgYmxpbmQgdXBncmFkZSBvciBhbnkgb3RoZXIgYmxp bmQKc29sdXRpb24uCgoKPiAkIHN1ZG8gIGtnZGIgL3Vzci9vYmovdXNyL3NyYy9zeXMvUEUyOTUw L2tlcm5lbC5kZWJ1ZyB2bWNvcmUuMgpQYXNzd29yZDoKW0dEQiB3aWxsIG5vdCBiZSBhYmxlIHRv IGRlYnVnIHVzZXItbW9kZSB0aHJlYWRzOiAvdXNyL2xpYi9saWJ0aHJlYWRfZGIuc286ClVuZGVm aW5lZCBzeW1ib2wgInBzX3BnbG9iYWxfbG9va3VwIl0KR05VIGdkYiA2LjEuMSBbRnJlZUJTRF0K Q29weXJpZ2h0IDIwMDQgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCkdEQiBpcyBmcmVl IHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5k IHlvdSBhcmUKd2VsY29tZSB0byBjaGFuZ2UgaXQgYW5kL29yIGRpc3RyaWJ1dGUgY29waWVzIG9m IGl0IHVuZGVyIGNlcnRhaW4KY29uZGl0aW9ucy4KVHlwZSAic2hvdyBjb3B5aW5nIiB0byBzZWUg dGhlIGNvbmRpdGlvbnMuClRoZXJlIGlzIGFic29sdXRlbHkgbm8gd2FycmFudHkgZm9yIEdEQi4g IFR5cGUgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxzLgpUaGlzIEdEQiB3YXMgY29uZmlndXJl ZCBhcyAiYW1kNjQtbWFyY2VsLWZyZWVic2QiLgoKVW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5l bCBtZXNzYWdlIGJ1ZmZlcjoKCgpGYXRhbCB0cmFwIDEyOiBwYWdlIGZhdWx0IHdoaWxlIGluIGtl cm5lbCBtb2RlCmNwdWlkID0gNTsgYXBpYyBpZCA9IDA1CmZhdWx0IHZpcnR1YWwgYWRkcmVzcyAg ID0gMHgxMDAxNjY4ODdhZApmYXVsdCBjb2RlICAgICAgICAgICAgICA9IHN1cGVydmlzb3IgcmVh ZCwgcGFnZSBub3QgcHJlc2VudAppbnN0cnVjdGlvbiBwb2ludGVyICAgICA9IDB4ODoweGZmZmZm ZmZmODAzZmEyOTAKc3RhY2sgcG9pbnRlciAgICAgICAgICAgPSAweDEwOjB4ZmZmZmZmZmZiYTBh OTk4MApmcmFtZSBwb2ludGVyICAgICAgICAgICA9IDB4MTA6MHgyCmNvZGUgc2VnbWVudCAgICAg ICAgICAgID0gYmFzZSAweDAsIGxpbWl0IDB4ZmZmZmYsIHR5cGUgMHgxYgogICAgICAgICAgICAg ICAgICAgICAgICA9IERQTCAwLCBwcmVzIDEsIGxvbmcgMSwgZGVmMzIgMCwgZ3JhbiAxCnByb2Nl c3NvciBlZmxhZ3MgICAgICAgID0gaW50ZXJydXB0IGVuYWJsZWQsIHJlc3VtZSwgSU9QTCA9IDAK Y3VycmVudCBwcm9jZXNzICAgICAgICAgPSAxMDM4IChteXNxbGQpCnRyYXAgbnVtYmVyICAgICAg ICAgICAgID0gMTIKcGFuaWM6IHBhZ2UgZmF1bHQKY3B1aWQgPSA1ClVwdGltZTogMWQ0aDM3bTU0 cwpEdW1waW5nIDgxOTEgTUIgKDMgY2h1bmtzKQogIGNodW5rIDA6IDFNQiAoMTU2IHBhZ2VzKSAu Li4gb2sKICBjaHVuayAxOiAzMzI3TUIgKDg1MTYyNCBwYWdlcykgMzMxMSAzMjk1IDMyNzkgMzI2 MyAzMjQ3IDMyMzEgMzIxNSAzMTk5CjMxODMgMzE2NyAzMTUxIDMxMzUgMzExOSAzMTAzIDMwODcg MzA3MSAzMDU1IDMwMzkgMzAyMyAzMDA3IDI5OTEgMjk3NSAyOTU5CjI5NDMgMjkyNyAyOTExIDI4 OTUgMjg3OSAyODYzIDI4NDcgMjgzMSAyODE1IDI3OTkgMjc4MyAyNzY3IDI3NTEgMjczNSAyNzE5 CjI3MDMgMjY4NyAyNjcxIDI2NTUgMjYzOSAyNjIzIDI2MDcgMjU5MSAyNTc1IDI1NTkgMjU0MyAy NTI3IDI1MTEgMjQ5NSAyNDc5CjI0NjMgMjQ0NyAyNDMxIDI0MTUgMjM5OSAyMzgzIDIzNjcgMjM1 MSAyMzM1IDIzMTkgMjMwMyAyMjg3IDIyNzEgMjI1NSAyMjM5CjIyMjMgMjIwNyAyMTkxIDIxNzUg MjE1OSAyMTQzIDIxMjcgMjExMSAyMDk1IDIwNzkgMjA2MyAyMDQ3IDIwMzEgMjAxNSAxOTk5CjE5 ODMgMTk2NyAxOTUxIDE5MzUgMTkxOSAxOTAzIDE4ODcgMTg3MSAxODU1IDE4MzkgMTgyMyAxODA3 IDE3OTEgMTc3NSAxNzU5CjE3NDMgMTcyNyAxNzExIDE2OTUgMTY3OSAxNjYzIDE2NDcgMTYzMSAx NjE1IDE1OTkgMTU4MyAxNTY3IDE1NTEgMTUzNSAxNTE5CjE1MDMgMTQ4NyAxNDcxIDE0NTUgMTQz OSAxNDIzIDE0MDcgMTM5MSAxMzc1IDEzNTkgMTM0MyAxMzI3IDEzMTEgMTI5NSAxMjc5CjEyNjMg MTI0NyAxMjMxIDEyMTUgMTE5OSAxMTgzIDExNjcgMTE1MSAxMTM1IDExMTkgMTEwMyAxMDg3IDEw NzEgMTA1NSAxMDM5CjEwMjMgMTAwNyA5OTEgOTc1IDk1OSA5NDMgOTI3IDkxMSA4OTUgODc5IDg2 MyA4NDcgODMxIDgxNSA3OTkgNzgzIDc2NyA3NTEKNzM1IDcxOSA3MDMgNjg3IDY3MSA2NTUgNjM5 IDYyMyA2MDcgNTkxIDU3NSA1NTkgNTQzIDUyNyA1MTEgNDk1IDQ3OSA0NjMgNDQ3CjQzMSA0MTUg Mzk5IDM4MyAzNjcgMzUxIDMzNSAzMTkgMzAzIDI4NyAyNzEgMjU1IDIzOSAyMjMgMjA3IDE5MSAx NzUgMTU5IDE0MwoxMjcgMTExIDk1IDc5IDYzIDQ3IDMxIDE1IC4uLiBvawogIGNodW5rIDI6IDQ4 NjRNQiAoMTI0NTE4NCBwYWdlcykgNDg0OSA0ODMzIDQ4MTcgNDgwMSA0Nzg1IDQ3NjkgNDc1MyA0 NzM3CjQ3MjEgNDcwNSA0Njg5IDQ2NzMgNDY1NyA0NjQxIDQ2MjUgNDYwOSA0NTkzIDQ1NzcgNDU2 MSA0NTQ1IDQ1MjkgNDUxMyA0NDk3CjQ0ODEgNDQ2NSA0NDQ5IDQ0MzMgNDQxNyA0NDAxIDQzODUg NDM2OSA0MzUzIDQzMzcgNDMyMSA0MzA1IDQyODkgNDI3MyA0MjU3CjQyNDEgNDIyNSA0MjA5IDQx OTMgNDE3NyA0MTYxIDQxNDUgNDEyOSA0MTEzIDQwOTcgNDA4MSA0MDY1IDQwNDkgNDAzMyA0MDE3 CjQwMDEgMzk4NSAzOTY5IDM5NTMgMzkzNyAzOTIxIDM5MDUgMzg4OSAzODczIDM4NTcgMzg0MSAz ODI1IDM4MDkgMzc5MyAzNzc3CjM3NjEgMzc0NSAzNzI5IDM3MTMgMzY5NyAzNjgxIDM2NjUgMzY0 OSAzNjMzIDM2MTcgMzYwMSAzNTg1IDM1NjkgMzU1MyAzNTM3CjM1MjEgMzUwNSAzNDg5IDM0NzMg MzQ1NyAzNDQxIDM0MjUgMzQwOSAzMzkzIDMzNzcgMzM2MSAzMzQ1IDMzMjkgMzMxMyAzMjk3CjMy ODEgMzI2NSAzMjQ5IDMyMzMgMzIxNyAzMjAxIDMxODUgMzE2OSAzMTUzIDMxMzcgMzEyMSAzMTA1 IDMwODkgMzA3MyAzMDU3CjMwNDEgMzAyNSAzMDA5IDI5OTMgMjk3NyAyOTYxIDI5NDUgMjkyOSAy OTEzIDI4OTcgMjg4MSAyODY1IDI4NDkgMjgzMyAyODE3CjI4MDEgMjc4NSAyNzY5IDI3NTMgMjcz NyAyNzIxIDI3MDUgMjY4OSAyNjczIDI2NTcgMjY0MSAyNjI1IDI2MDkgMjU5MyAyNTc3CjI1NjEg MjU0NSAyNTI5IDI1MTMgMjQ5NyAyNDgxIDI0NjUgMjQ0OSAyNDMzIDI0MTcgMjQwMSAyMzg1IDIz NjkgMjM1MyAyMzM3CjIzMjEgMjMwNSAyMjg5IDIyNzMgMjI1NyAyMjQxIDIyMjUgMjIwOSAyMTkz IDIxNzcgMjE2MSAyMTQ1IDIxMjkgMjExMyAyMDk3CjIwODEgMjA2NSAyMDQ5IDIwMzMgMjAxNyAy MDAxIDE5ODUgMTk2OSAxOTUzIDE5MzcgMTkyMSAxOTA1IDE4ODkgMTg3MyAxODU3CjE4NDEgMTgy NSAxODA5IDE3OTMgMTc3NyAxNzYxIDE3NDUgMTcyOSAxNzEzIDE2OTcgMTY4MSAxNjY1IDE2NDkg MTYzMyAxNjE3CjE2MDEgMTU4NSAxNTY5IDE1NTMgMTUzNyAxNTIxIDE1MDUgMTQ4OSAxNDczIDE0 NTcgMTQ0MSAxNDI1IDE0MDkgMTM5MyAxMzc3CjEzNjEgMTM0NSAxMzI5IDEzMTMgMTI5NyAxMjgx IDEyNjUgMTI0OSAxMjMzIDEyMTcgMTIwMSAxMTg1IDExNjkgMTE1MyAxMTM3CjExMjEgMTEwNSAx MDg5IDEwNzMgMTA1NyAxMDQxIDEwMjUgMTAwOSA5OTMgOTc3IDk2MSA5NDUgOTI5IDkxMyA4OTcg ODgxIDg2NQo4NDkgODMzIDgxNyA4MDEgNzg1IDc2OSA3NTMgNzM3IDcyMSA3MDUgNjg5IDY3MyA2 NTcgNjQxIDYyNSA2MDkgNTkzIDU3NyA1NjEKNTQ1IDUyOSA1MTMgNDk3IDQ4MSA0NjUgNDQ5IDQz MyA0MTcgNDAxIDM4NSAzNjkgMzUzIDMzNyAzMjEgMzA1IDI4OSAyNzMgMjU3CjI0MSAyMjUgMjA5 IDE5MyAxNzcgMTYxIDE0NSAxMjkgMTEzIDk3IDgxIDY1IDQ5IDMzIDE3IDEKCiMwICBkb2FkdW1w ICgpIGF0IHBjcHUuaDoxNzIKMTcyICAgICBwY3B1Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv cnkuCiAgICAgICAgaW4gcGNwdS5oCihrZ2RiKSBidAojMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6 MTcyCiMxICAweDAwMDAwMDAwMDAwMDAwMDQgaW4gPz8gKCkKIzIgIDB4ZmZmZmZmZmY4MDJhN2Q2 NyBpbiBib290IChob3d0bz0yNjApIGF0Ci91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24u Yzo0MDkKIzMgIDB4ZmZmZmZmZmY4MDJhODQwMSBpbiBwYW5pYyAoZm10PTB4ZmZmZmZmMDAzNmY5 YzcyMAoi77+9XDIwNkPvv71cMDAx77+977+977+977+977+9JVxcXDAwMe+/ve+/ve+/vVwyMDBp 77+977+9IikKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo1NjUKIzQg IDB4ZmZmZmZmZmY4MDQyNWY3ZiBpbiB0cmFwX2ZhdGFsIChmcmFtZT0weGZmZmZmZjAwMzZmOWM3 MjAsCmV2YT0xODQ0Njc0Mjk4MTYxNzg3ODcwNCkKICAgIGF0IC91c3Ivc3JjL3N5cy9hbWQ2NC9h bWQ2NC90cmFwLmM6NjYwCiM1ICAweGZmZmZmZmZmODA0MjYyOWYgaW4gdHJhcF9wZmF1bHQgKGZy YW1lPTB4ZmZmZmZmZmZiYTBhOThkMCwgdXNlcm1vZGU9MCkKYXQgL3Vzci9zcmMvc3lzL2FtZDY0 L2FtZDY0L3RyYXAuYzo1NzMKIzYgIDB4ZmZmZmZmZmY4MDQyNjU1MyBpbiB0cmFwIChmcmFtZT0K ICAgICAge3RmX3JkaSA9IDEwOTk4ODc1NzY2NzIsIHRmX3JzaSA9IDAsIHRmX3JkeCA9IDAsIHRm X3JjeCA9IC0xMTczNzEwMzEyLAp0Zl9yOCA9IC0xMDkzNTY0MjYxOTkyLCB0Zl9yOSA9IC0xMTcz NzEwMzA0LCB0Zl9yYXggPSAtMTE3MzcxMDI5MywgdGZfcmJ4ID0KLTEwOTM1NjQyNjIwMDAsIHRm X3JicCA9IDIsIHRmX3IxMCA9IC0xMDk4NTg5Mjg4NjcyLCB0Zl9yMTEgPSA0MzU4MzY1NTgsCnRm X3IxMiA9IDEwOTk4ODc1NzY2NzIsIHRmX3IxMyA9IC0xMDkzNTY0MjYyMDAwLCB0Zl9yMTQgPSA0 MzU4MzU1MjAsIHRmX3IxNQo9IC0xMTczNzEwMzEyLCB0Zl90cmFwbm8gPSAxMiwgdGZfYWRkciA9 IDEwOTk4ODc1NzcwMDUsIHRmX2ZsYWdzID0KLTIxNDQ2MDcwMTgsIHRmX2VyciA9IDAsIHRmX3Jp cCA9IC0yMTQzMzEzMjY0LCB0Zl9jcyA9IDgsIHRmX3JmbGFncyA9IDY2MTE4LAp0Zl9yc3AgPSAt MTE3MzcxMDQ0MCwgdGZfc3MgPSAxNn0pCiAgICBhdCAvdXNyL3NyYy9zeXMvYW1kNjQvYW1kNjQv dHJhcC5jOjM1MgojNyAgMHhmZmZmZmZmZjgwNDExNzNiIGluIGNhbGx0cmFwICgpIGF0Ci91c3Iv c3JjL3N5cy9hbWQ2NC9hbWQ2NC9leGNlcHRpb24uUzoxNjgKIzggIDB4ZmZmZmZmZmY4MDNmYTI5 MCBpbiBfdm1fbWFwX3VubG9jayAoKSBhdCAvdXNyL3NyYy9zeXMvdm0vdm1fbWFwLmM6NDQzCiM5 ICAweGZmZmZmZmZmODAzZmRlY2MgaW4gdm1fbWFwX2xvb2t1cCAodmFyX21hcD0weGZmZmZmZmZm YmEwYTlhMTAsCnZhZGRyPTQzNTgzNTUyMCwgZmF1bHRfdHlwZWE9MiAnXDAwMicsCiAgICBvdXRf ZW50cnk9MHhmZmZmZmZmZmJhMGE5YTE4LCBvYmplY3Q9MHhmZmZmZmYwMTYyN2Q5OTk4LApwaW5k ZXg9MHhmZmZmZmZmZmJhMGE5YTIwLCBvdXRfcHJvdD0weGZmZmZmZmZmYmEwYTlhMmIgIiIsCiAg ICB3aXJlZD0weGZmZmZmZmZmYmEwYTlhMmMpIGF0IC91c3Ivc3JjL3N5cy92bS92bV9tYXAuYzoz MDc0CiMxMCAweGZmZmZmZmZmODAyYjg0NWUgaW4gdW10eF9rZXlfZ2V0ICh0ZD0weGZmZmZmZjAw MzZmOWM3MjAsCnVtdHg9MHgxOWZhNTI4MCwga2V5PTB4ZmZmZmZmMDE2MjdkOTk5MCkKICAgIGF0 IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjMxMgojMTEgMHhmZmZmZmZmZjgwMmI4NTc4 IGluIF9kb19sb2NrICh0ZD0weGZmZmZmZjAwMzZmOWM3MjAsIHVtdHg9MHgxOWZhNTI4MCwKaWQ9 MTAwNTgyLCB0aW1vPTApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX3VtdHguYzozNjIK IzEyIDB4ZmZmZmZmZmY4MDJiOTllOSBpbiBfdW10eF9vcCAodGQ9MHhmZmZmZmYwMDM2ZjljNzIw LCB1YXA9MHgxODhlNikgYXQKL3Vzci9zcmMvc3lzL2tlcm4va2Vybl91bXR4LmM6NTQ1CiMxMyAw eGZmZmZmZmZmODA0MjZkZDEgaW4gc3lzY2FsbCAoZnJhbWU9CiAgICAgIHt0Zl9yZGkgPSA0MzU4 MzU1MjAsIHRmX3JzaSA9IDAsIHRmX3JkeCA9IDEwMDU4MiwgdGZfcmN4ID0gMCwgdGZfcjggPQow LCB0Zl9yOSA9IDE0MDczNzQ1MjA1MzA2MCwgdGZfcmF4ID0gNDU0LCB0Zl9yYnggPSAxMDA1ODIs IHRmX3JicCA9CjQzNTgzNTUyMCwgdGZfcjEwID0gMSwgdGZfcjExID0gNTgyLCB0Zl9yMTIgPSA5 OTgyMTI4LCB0Zl9yMTMgPSAxMDI0LCB0Zl9yMTQKPSAwLCB0Zl9yMTUgPSAwLCB0Zl90cmFwbm8g PSAxMiwgdGZfYWRkciA9IDEzODc0NjY3NTIsIHRmX2ZsYWdzID0gMCwgdGZfZXJyCj0gMiwgdGZf cmlwID0gMzQzNzgyMDY3ODAsIHRmX2NzID0gNDMsIHRmX3JmbGFncyA9IDU4MiwgdGZfcnNwID0K MTQwNzM3NDUyMDUyODA4LCB0Zl9zcyA9IDM1fSkgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0 L3RyYXAuYzo3OTIKIzE0IDB4ZmZmZmZmZmY4MDQxMThkOCBpbiBYZmFzdF9zeXNjYWxsICgpIGF0 Ci91c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC9leGNlcHRpb24uUzoyNzAKIzE1IDB4MDAwMDAwMDgw MTE5Y2UzYyBpbiA/PyAoKQpQcmV2aW91cyBmcmFtZSBpbm5lciB0byB0aGlzIGZyYW1lIChjb3Jy dXB0IHN0YWNrPykKKGtnZGIpCgooa2dkYikgdXAgNgojNiAgMHhmZmZmZmZmZjgwNDI2NTUzIGlu IHRyYXAgKGZyYW1lPQogICAgICB7dGZfcmRpID0gMTA5OTg4NzU3NjY3MiwgdGZfcnNpID0gMCwg dGZfcmR4ID0gMCwgdGZfcmN4ID0gLTExNzM3MTAzMTIsCnRmX3I4ID0gLTEwOTM1NjQyNjE5OTIs IHRmX3I5ID0gLTExNzM3MTAzMDQsIHRmX3JheCA9IC0xMTczNzEwMjkzLCB0Zl9yYnggPQotMTA5 MzU2NDI2MjAwMCwgdGZfcmJwID0gMiwgdGZfcjEwID0gLTEwOTg1ODkyODg2NzIsIHRmX3IxMSA9 IDQzNTgzNjU1OCwKdGZfcjEyID0gMTA5OTg4NzU3NjY3MiwgdGZfcjEzID0gLTEwOTM1NjQyNjIw MDAsIHRmX3IxNCA9IDQzNTgzNTUyMCwgdGZfcjE1Cj0gLTExNzM3MTAzMTIsIHRmX3RyYXBubyA9 IDEyLCB0Zl9hZGRyID0gMTA5OTg4NzU3NzAwNSwgdGZfZmxhZ3MgPQotMjE0NDYwNzAxOCwgdGZf ZXJyID0gMCwgdGZfcmlwID0gLTIxNDMzMTMyNjQsIHRmX2NzID0gOCwgdGZfcmZsYWdzID0gNjYx MTgsCnRmX3JzcCA9IC0xMTczNzEwNDQwLCB0Zl9zcyA9IDE2fSkKICAgIGF0IC91c3Ivc3JjL3N5 cy9hbWQ2NC9hbWQ2NC90cmFwLmM6MzUyCjM1MiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KHZvaWQpIHRyYXBfcGZhdWx0KCZmcmFtZSwgRkFMU0UpOwoKKGtnZGIpIHVwCiM3ICAweGZmZmZm ZmZmODA0MTE3M2IgaW4gY2FsbHRyYXAgKCkgYXQKL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4 Y2VwdGlvbi5TOjE2OAoxNjggICAgICAgICAgICAgY2FsbCAgICB0cmFwCkN1cnJlbnQgbGFuZ3Vh Z2U6ICBhdXRvOyBjdXJyZW50bHkgYXNtCihrZ2RiKSB1cAojOCAgMHhmZmZmZmZmZjgwM2ZhMjkw IGluIF92bV9tYXBfdW5sb2NrICgpIGF0IC91c3Ivc3JjL3N5cy92bS92bV9tYXAuYzo0NDMKNDQz ICAgICAgICAgICAgICAgICAgICAgX3N4X3h1bmxvY2soJm1hcC0+bG9jaywgZmlsZSwgbGluZSk7 CkN1cnJlbnQgbGFuZ3VhZ2U6ICBhdXRvOyBjdXJyZW50bHkgYwooa2dkYikgdXAKIzkgIDB4ZmZm ZmZmZmY4MDNmZGVjYyBpbiB2bV9tYXBfbG9va3VwICh2YXJfbWFwPTB4ZmZmZmZmZmZiYTBhOWEx MCwKdmFkZHI9NDM1ODM1NTIwLCBmYXVsdF90eXBlYT0yICdcMDAyJywKICAgIG91dF9lbnRyeT0w eGZmZmZmZmZmYmEwYTlhMTgsIG9iamVjdD0weGZmZmZmZjAxNjI3ZDk5OTgsCnBpbmRleD0weGZm ZmZmZmZmYmEwYTlhMjAsIG91dF9wcm90PTB4ZmZmZmZmZmZiYTBhOWEyYiAiIiwKICAgIHdpcmVk PTB4ZmZmZmZmZmZiYTBhOWEyYykgYXQgL3Vzci9zcmMvc3lzL3ZtL3ZtX21hcC5jOjMwNzQKMzA3 NCAgICAgICAgICAgIHZtX21hcF9sb2NrX3JlYWQobWFwKTsKKGtnZGIpIGxpc3QKMzA2OSAgICBS ZXRyeUxvb2t1cDo7CjMwNzAgICAgICAgICAgICAvKgozMDcxICAgICAgICAgICAgICogTG9va3Vw IHRoZSBmYXVsdGluZyBhZGRyZXNzLgozMDcyICAgICAgICAgICAgICovCjMwNzMKMzA3NCAgICAg ICAgICAgIHZtX21hcF9sb2NrX3JlYWQobWFwKTsKMzA3NSAgICAjZGVmaW5lIFJFVFVSTih3aHkp IFwKMzA3NiAgICAgICAgICAgICAgICAgICAgeyBcCjMwNzcgICAgICAgICAgICAgICAgICAgIHZt X21hcF91bmxvY2tfcmVhZChtYXApOyBcCjMwNzggICAgICAgICAgICAgICAgICAgIHJldHVybiAo d2h5KTsgXAooa2dkYikgcCBtYXAKJDEgPSAweDEwMDE2Njg4NjYwCihrZ2RiKSBkb3duCiM4ICAw eGZmZmZmZmZmODAzZmEyOTAgaW4gX3ZtX21hcF91bmxvY2sgKCkgYXQgL3Vzci9zcmMvc3lzL3Zt L3ZtX21hcC5jOjQ0Mwo0NDMgICAgICAgICAgICAgICAgICAgICBfc3hfeHVubG9jaygmbWFwLT5s b2NrLCBmaWxlLCBsaW5lKTsKKGtnZGIpIGxpc3QKNDM4ICAgICB7CjQzOQo0NDAgICAgICAgICAg ICAgaWYgKG1hcC0+c3lzdGVtX21hcCkKNDQxICAgICAgICAgICAgICAgICAgICAgX210eF91bmxv Y2tfZmxhZ3MoJm1hcC0+c3lzdGVtX210eCwgMCwgZmlsZSwgbGluZSk7CjQ0MiAgICAgICAgICAg ICBlbHNlCjQ0MyAgICAgICAgICAgICAgICAgICAgIF9zeF94dW5sb2NrKCZtYXAtPmxvY2ssIGZp bGUsIGxpbmUpOwo0NDQgICAgIH0KNDQ1CjQ0NiAgICAgdm9pZAo0NDcgICAgIF92bV9tYXBfbG9j a19yZWFkKHZtX21hcF90IG1hcCwgY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUpCgoKVGhhbmtz LApGcmFuY2VzY28gQ2lvY2NoZXR0aQo= From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 13:38:32 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BB3E16A418 for ; Mon, 4 Feb 2008 13:38:32 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3B29013C458 for ; Mon, 4 Feb 2008 13:38:32 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 245931CC031; Mon, 4 Feb 2008 05:38:32 -0800 (PST) Date: Mon, 4 Feb 2008 05:38:32 -0800 From: Jeremy Chadwick To: Primeroz lists Message-ID: <20080204133832.GA6950@eos.sc1.parodius.com> References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 13:38:32 -0000 On Mon, Feb 04, 2008 at 12:50:32PM +0000, Primeroz lists wrote: > we are experiencing repeated crash on a Dell PowerEdge 2950 (rev 1 or 2). > > FBSD release is 6.2-RELEASE-p5 , AMD64. 2xXeon QuadCore and 8G of Ram. > MySQL Version is 5.0.41 with following configuration settings: > {snip} There's additional information needed to help with this: 1) Contents of /boot/loader.conf 2) What scheduler you're using in your kernel configuration 3) Your kernel configuration in its entirity, if possible :-) 4) What options you compiled/built mysql50-server with Chances are your problem is related to process size limits. The most important part is how you've tuned /boot/loader.conf -- I'm betting you haven't. In my experience, mysqld will either segfault or in some cases cause the entire box to panic when kern.maxdsiz, kern.dfldsiz, and kern.maxssiz are not adjusted in loader.conf. This is taken from loader.conf on our production SQL server running RELENG_6, i386, with 2GB RAM: # Increase maximum allocatable memory on a process to 1536MB. # We don't choose 2GB (our amount of RAM) since that would # exhaust all memory, and result in a kernel panic. Maximum # stack size is still set to 128MB. # # dfldsiz = Initial data size limit (bytes) # maxdsiz = Maximum data size limit (bytes) # dflssiz = Initial stack size limit (bytes) # maxssiz = Maximum stack size limit (bytes) # kern.maxdsiz="1536M" kern.dfldsiz="1536M" kern.maxssiz="128M" Some other comments: > set-variable = key_buffer=768M > set-variable = table_cache=800 > set-variable = sort_buffer=24M > set-variable = myisam_sort_buffer_size=256M > set-variable = record_buffer=16M > set-variable = max_allowed_packet=10M > set-variable = thread_stack=128K > set-variable = join_buffer=512M > set-variable = max_heap_table_size=256M > set-variable = max_connections=300 > set-variable = tmp_table_size=384M > set-variable = query_cache_size=402653184 > set-variable = query_cache_limit=134217728 > set-variable = read_rnd_buffer_size=10M > set-variable = ft_min_word_len=1 > pid-file = /var/db/mysqld.pid > tmpdir = /var/tmp > ft_stopword_file = '' > set-variable = thread_cache_size=80 > set-variable = myisam_stats_method=nulls_equal These tunings seem fairly "random", in that they almost look like someone just picked arbitrary values rather than reading how they all work together and how exactly they impact the system. This is a very common (and bad) habit people have when "tuning" mysql; they just fiddle around. For comparison, using the same box of ours mentioned above: set-variable = tmp_table_size=64M set-variable = max_allowed_packet=32M set-variable = table_cache=256 set-variable = key_buffer_size=64M set-variable = join_buffer_size=8M set-variable = sort_buffer_size=8M set-variable = read_buffer_size=8M set-variable = query_cache_size=64M set-variable = query_cache_limit=32M set-variable = innodb_buffer_pool_size=512M set-variable = innodb_additional_mem_pool_size=20M set-variable = innodb_log_file_size=128M set-variable = innodb_log_buffer_size=8M Also, please remove pid-file from your my.cnf -- it serves zero purpose, and if placed in a location which isn't where rc.d/mysql expects it to be, could lead to problems when shutting down/starting up the server. The rc.d/mysql script takes care of this for you, so don't override it. Finally, I will take a moment to urge you to upgrade that box to RELENG_7. SCHED_ULE was re-written and specifically tested with mysqld in mind, and are quite impressive. The fact you're using a pair of quad core CPUs would be reason enough to upgrade. RELENG_6 will soon be on its way out the door, so it's an inevitable upgrade anyways. -- | 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 Feb 4 13:51:46 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A875616A417 for ; Mon, 4 Feb 2008 13:51:46 +0000 (UTC) (envelope-from andrew@rinet.ru) Received: from mail.tsscom.ru (mail.tsscom.ru [195.10.205.29]) by mx1.freebsd.org (Postfix) with ESMTP id 30BC513C461 for ; Mon, 4 Feb 2008 13:51:45 +0000 (UTC) (envelope-from andrew@rinet.ru) Received: from [195.10.205.145] (HELO [10.10.80.29]) by mail.tsscom.ru (CommuniGate Pro SMTP 5.1.8) with ESMTP id 159730 for stable@freebsd.org; Mon, 04 Feb 2008 15:51:41 +0300 From: Andrew Kolchoogin To: stable@freebsd.org In-Reply-To: <200802041204.m14C4lTO074894@drugs.dv.isc.org> References: <200802041204.m14C4lTO074894@drugs.dv.isc.org> Content-Type: text/plain Organization: Cronyx Plus LLC Date: Mon, 04 Feb 2008 15:51:30 +0300 Message-Id: <1202129490.2261.15.camel@akela> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 13:51:46 -0000 > > > Personally, I never understood the concept of "dial-in" and "call-out" > > > devices on FreeBSD. I ran BBS software for years on both Apple II > > > hardware and PC hardware; there was no distinction between such devices. > > > A serial port is a serial port. Chances are I'm not understanding why > > > there's a distinction, but there doesn't appear to be any explanation of > > > why there's a distinction within manpages or the handbook... > > The distinction exists to allow an application to wait on the "dial-in" > > port for incoming calls and another application to make outgoing call > > mean time using the same port as "call-out" while the port is idle. > And once there is a incoming call block out going calls until > the incoming call completes. And for now one must forget existance of such devices and use /dev/ttyd* for both incoming and outgoing calls. Long history is the following: terminal devices under UNIX have changed its semantics quite a long time ago. Historically, there are a pair of devices, one was for dial-in, and another -- for dial-out. This absurd was created because of absence of non-blocking open()'s -- O_NONBLOCK simply doesn't work for open()'s of devices. As such, historical getty implementation opens port in blocking mode and blocks until carrier is detected on terminal line. Kernel doesn't allow multiple simultaneous opens of /dev/tty* in blocking mode to prevent multiple applications from accessing serial port simultaneously -- as such, if we want to make outgoing call, we ought to have 'some another' device physically attached to the same serial port, so, /dev/cua* exist. For now, there are virtually no software that relates on this behaviour -- POSIX tty locking semantics mandate us to check lock files in well-known system-wide directory -- /var/spool/lock in FreeBSD. Kernel allows opens of /dev/tty* in non-blocking mode many times, as such, no special 'dial-out' device needs to make outgoing call. It is clear that _all_ applications communicating with serial port use one semantics -- historical UNIX or POSIX. One can not use system /usr/libexec/getty with POSIX-compatible software because it opens /dev/tty* in blocking mode. Use comms/mgetty+sendfax mgetty instead -- to be precise, mgetty also can be used with UNIX tty semantics (see description of configuration keyword "blocking"), but just don't do it. ;) -- Andrew Kolchoogin. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 13:56:44 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9C8D16A41B; Mon, 4 Feb 2008 13:56:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id 9C52A13C447; Mon, 4 Feb 2008 13:56:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id m14Dug8n075519; Tue, 5 Feb 2008 00:56:42 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200802041356.m14Dug8n075519@drugs.dv.isc.org> To: Jeremy Chadwick From: Mark Andrews In-reply-to: Your message of "Mon, 04 Feb 2008 05:10:20 -0800." <20080204131020.GA5830@eos.sc1.parodius.com> Date: Tue, 05 Feb 2008 00:56:42 +1100 Sender: marka@isc.org Cc: FreeBSD Stable Mailing List , Ganbold , Eugene Grosbein Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 13:56:45 -0000 > On Mon, Feb 04, 2008 at 02:08:32PM +0700, Eugene Grosbein wrote: > > > Personally, I never understood the concept of "dial-in" and "call-out" > > > devices on FreeBSD. I ran BBS software for years on both Apple II > > > hardware and PC hardware; there was no distinction between such devices. > > > A serial port is a serial port. Chances are I'm not understanding why > > > there's a distinction, but there doesn't appear to be any explanation of > > > why there's a distinction within manpages or the handbook... > > > > The distinction exists to allow an application to wait on the "dial-in" > > port for incoming calls and another application to make outgoing call > > mean time using the same port as "call-out" while the port is idle. > > This is intruiging to me, because now I'm left wondering how that > actually works behind the scenes! :-) > > What happens when program X has /dev/ttyd0 open (for incoming calls), > receives a call, and then during which program Y attempts to open > /dev/cuad0? Does program Y indefinitely block/wait somewhere within the > kernel until program X releases the fd? open blocks until CD is asserted when /dev/cuad0 is not open. > If so, then I'm left wondering why Ganbold's cu -l cuad0 attempt > returned an immediate EBUSY, rather than blocking indefinitely. EBUSY indicates that the open on /dev/ttyd0 completed. > Also, the above mechanism must be fairly old, because I imagine it would > be more effective to utilise kqueue/kevent to inform said programs of > when the serial port is available for use. Only about 20 years old. > -- > | 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 | > > _______________________________________________ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 14:19:07 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFB1516A418 for ; Mon, 4 Feb 2008 14:19:07 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.249]) by mx1.freebsd.org (Postfix) with ESMTP id 449F413C44B for ; Mon, 4 Feb 2008 14:19:07 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: by hs-out-2122.google.com with SMTP id h53so2259599hsh.11 for ; Mon, 04 Feb 2008 06:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=14lR/WJiTCGvG4UQpLIZKu7IiO3oBCNbrJQrp1Bm+E0=; b=YqshfsWZ8RnW/586WN++y4ysZP2SHsuQCETgTf1fnQeFlAAd6iU8XsvqwXAZ88uDCSXYAAUPPOQub9oxRA+Gp4Y7ij6amDo1b3QwPwTv1U5YCjnn/csX6zsUnpVsNBpuF251CxHulXhR1t/utOvLKBPrjdFbUep3VAk82TK9emo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=epU6SsGvFldtc8Tb5Rh45yOyrcoPBjfTbk4Gdg4UfIFUHEyuAfDSXXe3O/kcJ9yVxrjJ2/X0VcnHbpMCDICMaMWJunVlX7EcHe94Lf6JvKhaJqGL2TXZkROhZmNeH/EHczATjTrybkl8iVfLfvonwsTuS/j0hRMknLEb7PLb8eE= Received: by 10.141.198.9 with SMTP id a9mr4741352rvq.280.1202134745596; Mon, 04 Feb 2008 06:19:05 -0800 (PST) Received: by 10.140.203.6 with HTTP; Mon, 4 Feb 2008 06:19:05 -0800 (PST) Message-ID: <55b8c6fe0802040619m8728e68kbe408ee4a94e591a@mail.gmail.com> Date: Mon, 4 Feb 2008 14:19:05 +0000 From: "Primeroz lists" To: "Jeremy Chadwick" In-Reply-To: <20080204133832.GA6950@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_33088_30899750.1202134745559" References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <20080204133832.GA6950@eos.sc1.parodius.com> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 14:19:07 -0000 ------=_Part_33088_30899750.1202134745559 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > > > > There's additional information needed to help with this: > > 1) Contents of /boot/loader.conf empty > > 2) What scheduler you're using in your kernel configuration We using the 4bsd Scheduler (ULE is commented out in kernel conf) > 3) Your kernel configuration in its entirity, if possible :-) attached > > 4) What options you compiled/built mysql50-server with As from Tinderbox log: configure: running /bin/sh './configure' --prefix=/usr/local '--localstatedir=/var/db/mysql' '--without-debug' '--without-readline' '--without-libedit' '--without-bench' '--without-extra-tools' '--with-libwrap' '--with-mysqlfs' '--with-low-memory' '--with-comment=FreeBSD port: mysql-server-5.0.41' '--enable-thread-safe-client' '--with-named-thread-libs=-pthread' '--prefix=/usr/local' '--build=amd64-portbld-freebsd6.2' 'CC=cc' 'CFLAGS=-O2 -fno-strict-aliasing -pipe ' 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe -felide-constructors -fno-rtti -fno-exceptions' 'CXX=c++' 'build_alias=amd64-portbld-freebsd6.2' CFLAGS=' -DDBUG_OFF -O2 -fno-strict-aliasing -pipe ' CXXFLAGS=' -DDBUG_OFF -O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe -felide-constructors -fno-rtti -fno-exceptions -fno-implicit-templates -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=1000000' --cache-file=/dev/null --srcdir=. This is taken from loader.conf on our production SQL server running > RELENG_6, i386, with 2GB RAM: > > > # Increase maximum allocatable memory on a process to 1536MB. > # We don't choose 2GB (our amount of RAM) since that would > # exhaust all memory, and result in a kernel panic. Maximum > # stack size is still set to 128MB. > # > # dfldsiz = Initial data size limit (bytes) > # maxdsiz = Maximum data size limit (bytes) > # dflssiz = Initial stack size limit (bytes) > # maxssiz = Maximum stack size limit (bytes) > # > kern.maxdsiz="1536M" > kern.dfldsiz="1536M" > kern.maxssiz="128M" > I did not setup anything in the /boot/loader.conf so i guess i'm using default values for all of those settings, > Some other comments: > > > Finally, I will take a moment to urge you to upgrade that box to > RELENG_7. SCHED_ULE was re-written and specifically tested with mysqld > in mind, and are quite impressive. The fact you're using a pair of quad > core CPUs would be reason enough to upgrade. RELENG_6 will soon be on > its way out the door, so it's an inevitable upgrade anyways. > Yes, configuration need fixing especially about InnoDB that is not configured/tuned at all. The one that take my attention more then others options is: set-variable = innodb_buffer_pool_size=512M I'm sure i need to increase that value, i'm using the default that surely is not giving me the expected resaults ... but i wonder if that can lead to such a crash and not just a performance problem as i read on some sources on internet about mysql optimization. We are thinking about an OS Upgrade but what i would really like is to understand what in mysql is triggering this crash before upgrading to new OS/Mysql and maybe mask the problem for long time. thanks for your help. Francesco Ciocchetti ------=_Part_33088_30899750.1202134745559 Content-Type: application/octet-stream; name=PE2950 Content-Transfer-Encoding: base64 X-Attachment-Id: f_fc93vgit0 Content-Disposition: attachment; filename=PE2950 IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2FtZDY0CiMKIyBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIGZpbGUsIHBsZWFzZSBy ZWFkIHRoZSBoYW5kYm9vayBzZWN0aW9uIG9uCiMgS2VybmVsIENvbmZpZ3VyYXRpb24gRmlsZXM6 CiMKIyAgICBodHRwOi8vd3d3LkZyZWVCU0Qub3JnL2RvYy9lbl9VUy5JU084ODU5LTEvYm9va3Mv aGFuZGJvb2sva2VybmVsY29uZmlnLWNvbmZpZy5odG1sCiMKIyBUaGUgaGFuZGJvb2sgaXMgYWxz byBhdmFpbGFibGUgbG9jYWxseSBpbiAvdXNyL3NoYXJlL2RvYy9oYW5kYm9vawojIGlmIHlvdSd2 ZSBpbnN0YWxsZWQgdGhlIGRvYyBkaXN0cmlidXRpb24sIG90aGVyd2lzZSBhbHdheXMgc2VlIHRo ZQojIEZyZWVCU0QgV29ybGQgV2lkZSBXZWIgc2VydmVyIChodHRwOi8vd3d3LkZyZWVCU0Qub3Jn LykgZm9yIHRoZQojIGxhdGVzdCBpbmZvcm1hdGlvbi4KIwojIEFuIGV4aGF1c3RpdmUgbGlzdCBv ZiBvcHRpb25zIGFuZCBtb3JlIGRldGFpbGVkIGV4cGxhbmF0aW9ucyBvZiB0aGUKIyBkZXZpY2Ug bGluZXMgaXMgYWxzbyBwcmVzZW50IGluIHRoZSAuLi8uLi9jb25mL05PVEVTIGFuZCBOT1RFUyBm aWxlcy4KIyBJZiB5b3UgYXJlIGluIGRvdWJ0IGFzIHRvIHRoZSBwdXJwb3NlIG9yIG5lY2Vzc2l0 eSBvZiBhIGxpbmUsIGNoZWNrIGZpcnN0CiMgaW4gTk9URVMuCiMKIyAkRnJlZUJTRDogc3JjL3N5 cy9hbWQ2NC9jb25mL0dFTkVSSUMsdiAxLjQzOS4yLjcgMjAwNS8xMC8yOCAxOToyMToyNyBqaGIg RXhwICQKCm1hY2hpbmUJCWFtZDY0CmNwdQkJSEFNTUVSCmlkZW50CQlQRTI5NTAKCiMgVG8gc3Rh dGljYWxseSBjb21waWxlIGluIGRldmljZSB3aXJpbmcgaW5zdGVhZCBvZiAvYm9vdC9kZXZpY2Uu aGludHMKI2hpbnRzCQkiR0VORVJJQy5oaW50cyIJCSMgRGVmYXVsdCBwbGFjZXMgdG8gbG9vayBm b3IgZGV2aWNlcy4KCm1ha2VvcHRpb25zCURFQlVHPS1nCQkjIEJ1aWxkIGtlcm5lbCB3aXRoIGdk YigxKSBkZWJ1ZyBzeW1ib2xzCgojb3B0aW9ucyAJU0NIRURfVUxFCQkjIFVMRSBzY2hlZHVsZXIK b3B0aW9ucyAJU0NIRURfNEJTRAkJIyA0QlNEIHNjaGVkdWxlcgpvcHRpb25zIAlQUkVFTVBUSU9O CQkjIEVuYWJsZSBrZXJuZWwgdGhyZWFkIHByZWVtcHRpb24Kb3B0aW9ucyAJSU5FVAkJCSMgSW50 ZXJORVR3b3JraW5nCiNvcHRpb25zIAlJTkVUNgkJCSMgSVB2NiBjb21tdW5pY2F0aW9ucyBwcm90 b2NvbHMKb3B0aW9ucyAJRkZTCQkJIyBCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJ U09GVFVQREFURVMJCSMgRW5hYmxlIEZGUyBzb2Z0IHVwZGF0ZXMgc3VwcG9ydApvcHRpb25zIAlV RlNfQUNMCQkJIyBTdXBwb3J0IGZvciBhY2Nlc3MgY29udHJvbCBsaXN0cwpvcHRpb25zIAlVRlNf RElSSEFTSAkJIyBJbXByb3ZlIHBlcmZvcm1hbmNlIG9uIGJpZyBkaXJlY3RvcmllcwpvcHRpb25z IAlNRF9ST09UCQkJIyBNRCBpcyBhIHBvdGVudGlhbCByb290IGRldmljZQpvcHRpb25zIAlORlND TElFTlQJCSMgTmV0d29yayBGaWxlc3lzdGVtIENsaWVudApvcHRpb25zIAlORlNTRVJWRVIJCSMg TmV0d29yayBGaWxlc3lzdGVtIFNlcnZlcgpvcHRpb25zIAlORlNfUk9PVAkJIyBORlMgdXNhYmxl IGFzIC8sIHJlcXVpcmVzIE5GU0NMSUVOVApvcHRpb25zIAlOVEZTCQkJIyBOVCBGaWxlIFN5c3Rl bQpvcHRpb25zIAlNU0RPU0ZTCQkJIyBNU0RPUyBGaWxlc3lzdGVtCm9wdGlvbnMgCUNEOTY2MAkJ CSMgSVNPIDk2NjAgRmlsZXN5c3RlbQpvcHRpb25zIAlQUk9DRlMJCQkjIFByb2Nlc3MgZmlsZXN5 c3RlbSAocmVxdWlyZXMgUFNFVURPRlMpCm9wdGlvbnMgCVBTRVVET0ZTCQkjIFBzZXVkby1maWxl c3lzdGVtIGZyYW1ld29yawpvcHRpb25zIAlHRU9NX0dQVAkJIyBHVUlEIFBhcnRpdGlvbiBUYWJs ZXMuCm9wdGlvbnMgICAgIEdFT01fTEFCRUwKb3B0aW9ucyAJQ09NUEFUXzQzCQkjIE5lZWRlZCBi eSBDT01QQVRfTElOVVgzMgpvcHRpb25zIAlDT01QQVRfSUEzMgkJIyBDb21wYXRpYmxlIHdpdGgg aTM4NiBiaW5hcmllcwpvcHRpb25zIAlDT01QQVRfRlJFRUJTRDQJCSMgQ29tcGF0aWJsZSB3aXRo IEZyZWVCU0Q0Cm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNENQkJIyBDb21wYXRpYmxlIHdpdGggRnJl ZUJTRDUKb3B0aW9ucyAJQ09NUEFUX0xJTlVYMzIJCSMgQ29tcGF0aWJsZSB3aXRoIGkzODYgbGlu dXggYmluYXJpZXMgCm9wdGlvbnMgCVNDU0lfREVMQVk9NTAwMAkJIyBEZWxheSAoaW4gbXMpIGJl Zm9yZSBwcm9iaW5nIFNDU0kKb3B0aW9ucyAJS1RSQUNFCQkJIyBrdHJhY2UoMSkgc3VwcG9ydApv cHRpb25zIAlTWVNWU0hNCQkJIyBTWVNWLXN0eWxlIHNoYXJlZCBtZW1vcnkKb3B0aW9ucyAJU1lT Vk1TRwkJCSMgU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpvcHRpb25zIAlTWVNWU0VNCQkJIyBT WVNWLXN0eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5H ICMgUE9TSVggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMKb3B0aW9ucyAJS0JEX0lOU1RB TExfQ0RFVgkjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXYKb3B0aW9ucyAJQUhDX1JFR19Q UkVUVFlfUFJJTlQJIyBQcmludCByZWdpc3RlciBiaXRmaWVsZHMgaW4gZGVidWcKCQkJCQkjIG91 dHB1dC4gIEFkZHMgfjEyOGsgdG8gZHJpdmVyLgpvcHRpb25zIAlBSERfUkVHX1BSRVRUWV9QUklO VAkjIFByaW50IHJlZ2lzdGVyIGJpdGZpZWxkcyBpbiBkZWJ1ZwoJCQkJCSMgb3V0cHV0LiAgQWRk cyB+MjE1ayB0byBkcml2ZXIuCm9wdGlvbnMgCUFEQVBUSVZFX0dJQU5UCQkjIEdpYW50IG11dGV4 IGlzIGFkYXB0aXZlLgpvcHRpb25zICAgICBTTVAKCgojb3B0aW9ucyAgICAgSU5WQVJJQU5UUyAK I29wdGlvbnMgICAgIElOVkFSSUFOVF9TVVBQT1JUCgojb3B0aW9ucyAgICAgS0RCCiNvcHRpb25z ICAgICBEREIKI29wdGlvbnMgICAgIEtEQl9VTkFUVEVOREVECiNvcHRpb25zICAgICBCUkVBS19U T19ERUJVR0dFUgoKCiMgV29ya2Fyb3VuZHMgZm9yIHNvbWUga25vd24tdG8tYmUtYnJva2VuIGNo aXBzZXRzIChuVmlkaWEgbkZvcmNlMy1Qcm8xNTApCmRldmljZQkJYXRwaWMJCQkjIDgyNTlBIGNv bXBhdGFiaWxpdHkKCiMgTGludXggMzItYml0IEFCSSBzdXBwb3J0Cm9wdGlvbnMgCUxJTlBST0NG UwkJIyBDYW5ub3QgYmUgYSBtb2R1bGUgeWV0LgoKIyBCdXMgc3VwcG9ydC4KZGV2aWNlCQlhY3Bp CmRldmljZQkJcGNpCgojIEZsb3BweSBkcml2ZXMKZGV2aWNlCQlmZGMKCiMgQVRBIGFuZCBBVEFQ SSBkZXZpY2VzCmRldmljZQkJYXRhCmRldmljZQkJYXRhZGlzawkJIyBBVEEgZGlzayBkcml2ZXMK ZGV2aWNlCQlhdGFwaWNkCQkjIEFUQVBJIENEUk9NIGRyaXZlcwpkZXZpY2UJCWF0YXBpZmQJCSMg QVRBUEkgZmxvcHB5IGRyaXZlcwpvcHRpb25zIAlBVEFfU1RBVElDX0lECSMgU3RhdGljIGRldmlj ZSBudW1iZXJpbmcKCiMgU0NTSSBDb250cm9sbGVycwpkZXZpY2UJCW1wdAkJIyBMU0ktTG9naWMg TVBULUZ1c2lvbgoKIyBTQ1NJIHBlcmlwaGVyYWxzCmRldmljZQkJc2NidXMJCSMgU0NTSSBidXMg KHJlcXVpcmVkIGZvciBTQ1NJKQpkZXZpY2UJCWNoCQkjIFNDU0kgbWVkaWEgY2hhbmdlcnMKZGV2 aWNlCQlkYQkJIyBEaXJlY3QgQWNjZXNzIChkaXNrcykKZGV2aWNlCQlzYQkJIyBTZXF1ZW50aWFs IEFjY2VzcyAodGFwZSBldGMpCmRldmljZQkJY2QJCSMgQ0QKZGV2aWNlCQlwYXNzCQkjIFBhc3N0 aHJvdWdoIGRldmljZSAoZGlyZWN0IFNDU0kgYWNjZXNzKQpkZXZpY2UJCXNlcwkJIyBTQ1NJIEVu dmlyb25tZW50YWwgU2VydmljZXMgKGFuZCBTQUYtVEUpCgojIFJBSUQgY29udHJvbGxlcnMKZGV2 aWNlICAgICAgbWZpCgojIGF0a2JkYzAgY29udHJvbHMgYm90aCB0aGUga2V5Ym9hcmQgYW5kIHRo ZSBQUy8yIG1vdXNlCmRldmljZQkJYXRrYmRjCQkjIEFUIGtleWJvYXJkIGNvbnRyb2xsZXIKZGV2 aWNlCQlhdGtiZAkJIyBBVCBrZXlib2FyZApkZXZpY2UJCXBzbQkJIyBQUy8yIG1vdXNlCmRldmlj ZSAgICAgIGtiZG11eAoKZGV2aWNlCQl2Z2EJCSMgVkdBIHZpZGVvIGNhcmQgZHJpdmVyCgpkZXZp Y2UJCXNwbGFzaAkJIyBTcGxhc2ggc2NyZWVuIGFuZCBzY3JlZW4gc2F2ZXIgc3VwcG9ydAoKIyBz eXNjb25zIGlzIHRoZSBkZWZhdWx0IGNvbnNvbGUgZHJpdmVyLCByZXNlbWJsaW5nIGFuIFNDTyBj b25zb2xlCmRldmljZQkJc2MKCmRldmljZQkJYWdwCQkjIHN1cHBvcnQgc2V2ZXJhbCBBR1AgY2hp cHNldHMKCgpkZXZpY2UJCXNpbwkJIyA4MjUwLCAxNls0NV01MCBiYXNlZCBzZXJpYWwgcG9ydHMK CgpkZXZpY2UJCW1paWJ1cwkJIyBNSUkgYnVzIHN1cHBvcnQKZGV2aWNlICAgICAgYmNlCgpkZXZp Y2UJCWxvb3AJCSMgTmV0d29yayBsb29wYmFjawpkZXZpY2UJCXJhbmRvbQkJIyBFbnRyb3B5IGRl dmljZQpkZXZpY2UJCWV0aGVyCQkjIEV0aGVybmV0IHN1cHBvcnQKZGV2aWNlCQl0dW4JCSMgUGFj a2V0IHR1bm5lbC4KZGV2aWNlCQlwdHkJCSMgUHNldWRvLXR0eXMgKHRlbG5ldCBldGMpCmRldmlj ZQkJbWQJCSMgTWVtb3J5ICJkaXNrcyIKZGV2aWNlCQlnaWYJCSMgSVB2NiBhbmQgSVB2NCB0dW5u ZWxpbmcKI2RldmljZQkJZmFpdGgJCSMgSVB2Ni10by1JUHY0IHJlbGF5aW5nICh0cmFuc2xhdGlv bikKCmRldmljZQkJYnBmCQkjIEJlcmtlbGV5IHBhY2tldCBmaWx0ZXIKCmRldmljZQkJdWhjaQkJ IyBVSENJIFBDSS0+VVNCIGludGVyZmFjZQpkZXZpY2UJCW9oY2kJCSMgT0hDSSBQQ0ktPlVTQiBp bnRlcmZhY2UKZGV2aWNlCQllaGNpCQkjIEVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlIChVU0IgMi4w KQpkZXZpY2UJCXVzYgkJIyBVU0IgQnVzIChyZXF1aXJlZCkKZGV2aWNlCQl1Z2VuCQkjIEdlbmVy aWMKZGV2aWNlCQl1aGlkCQkjICJIdW1hbiBJbnRlcmZhY2UgRGV2aWNlcyIKZGV2aWNlCQl1a2Jk CQkjIEtleWJvYXJkCmRldmljZQkJdW1zCQkjIE1vdXNlCgpkZXZpY2UgICAgICAgICAgY2FycApk ZXZpY2UgICAgICBwZgpkZXZpY2UgICAgICBwZmxvZwpkZXZpY2UgICAgICBwZnN5bmMKCm9wdGlv bnMgRkFTVF9JUFNFQwpkZXZpY2UgY3J5cHRvCgoKZGV2aWNlICAgICAgICAgIGNhcnAKZGV2aWNl ICAgICAgcGYKZGV2aWNlICAgICAgcGZsb2cKZGV2aWNlICAgICAgcGZzeW5jCgpvcHRpb25zICAg ICAgICAgQUxUUQpvcHRpb25zICAgICAgICAgQUxUUV9DQlEgICAgICAgICMgQ2xhc3MgQmFzZXMg UXVldWluZyAoQ0JRKQpvcHRpb25zICAgICAgICAgQUxUUV9SRUQgICAgICAgICMgUmFuZG9tIEVh cmx5IERldGVjdGlvbiAoUkVEKQpvcHRpb25zICAgICAgICAgQUxUUV9SSU8gICAgICAgICMgUkVE IEluL091dApvcHRpb25zICAgICAgICAgQUxUUV9IRlNDICAgICAgICMgSGllcmFyY2hpY2FsIFBh Y2tldCBTY2hlZHVsZXIgKEhGU0MpCm9wdGlvbnMgICAgICAgICBBTFRRX1BSSVEgICAgICAgIyBQ cmlvcml0eSBRdWV1aW5nIChQUklRKQpvcHRpb25zICAgICAgICAgQUxUUV9OT1BDQyAgICAgICMg UmVxdWlyZWQgZm9yIFNNUCBidWlsZAoK ------=_Part_33088_30899750.1202134745559-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 14:42:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 896DE16A421; Mon, 4 Feb 2008 14:42:10 +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 D506A13C44B; Mon, 4 Feb 2008 14:42:09 +0000 (UTC) (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 m14Eg6EI040853; Mon, 4 Feb 2008 21:42:07 +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 m14Eg6bb040852; Mon, 4 Feb 2008 21:42:06 +0700 (KRAT) (envelope-from eugen) Date: Mon, 4 Feb 2008 21:42:06 +0700 From: Eugene Grosbein To: Jeremy Chadwick Message-ID: <20080204144206.GA40367@svzserv.kemerovo.su> References: <47A69A66.2080109@micom.mng.net> <20080204063023.GA91789@eos.sc1.parodius.com> <47A6B2AB.2060308@micom.mng.net> <20080204065122.GA92674@eos.sc1.parodius.com> <20080204070832.GA97372@svzserv.kemerovo.su> <20080204131020.GA5830@eos.sc1.parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080204131020.GA5830@eos.sc1.parodius.com> User-Agent: Mutt/1.4.2.3i Cc: Ganbold , FreeBSD Stable Mailing List Subject: Re: /dev/cuad0: Device busy 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, 04 Feb 2008 14:42:10 -0000 On Mon, Feb 04, 2008 at 05:10:20AM -0800, Jeremy Chadwick wrote: > Also, the above mechanism must be fairly old, because I imagine it would > be more effective to utilise kqueue/kevent to inform said programs of > when the serial port is available for use. The kqueue/kevent had appeared only in 4.x version of FreeBSD and serial ports were used long time before. Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 14:50:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CC1516A418 for ; Mon, 4 Feb 2008 14:50:10 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id DCE4C13C45B for ; Mon, 4 Feb 2008 14:50:09 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so1647764rvb.43 for ; Mon, 04 Feb 2008 06:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=j1DwV4wOWroBH9Rwr/w7mmiSVXezkavJtCGhh0bKNU0=; b=Ehsiv2+p0BxnzUAjsmWYLilbk+eLTQWOnIN0Rk5fm9v1DjRMVUQ0++qzdwwjwTlriA2UvQAiZud+d0uxSayrNUu9Hf7xF/dhqYmPAiUGFyO1WKRwHLgA73qLxcnJJCRJOBlRRb8CoAql9v2j97bRH2jYBVV1+BxmJb1FFxZYHBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jWUtvy8qLPJhCiAEjzrJG2poeO3wEFDvTwn16WvjS0q40N9PQ0/LWejd9B4U7flnDYNHWZJCNRRwR+bbpNFUzC6fi9FoAeAuaidZVoDsvKd39p3IioIZfGLjIdNGlwm8KCQPy+YVEjtV7E3oZxv7sQBxNNGjX+HKqXKdo+IMdM0= Received: by 10.140.170.12 with SMTP id s12mr4776283rve.101.1202136609560; Mon, 04 Feb 2008 06:50:09 -0800 (PST) Received: by 10.140.203.6 with HTTP; Mon, 4 Feb 2008 06:50:09 -0800 (PST) Message-ID: <55b8c6fe0802040650m3eefd1cfp79133334ed2df269@mail.gmail.com> Date: Mon, 4 Feb 2008 14:50:09 +0000 From: "Primeroz lists" To: "Jeremy Chadwick" In-Reply-To: <55b8c6fe0802040619m8728e68kbe408ee4a94e591a@mail.gmail.com> MIME-Version: 1.0 References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <20080204133832.GA6950@eos.sc1.parodius.com> <55b8c6fe0802040619m8728e68kbe408ee4a94e591a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 14:50:10 -0000 Just wanted to point out that anyway our crash is a Kernel panic crash and not a Mysqld crash. Platform is AMD64 so , i'm don't think it can be a problem of process size : > $ sudo -u mysql limits Resource limits (current): cputime infinity secs filesize infinity kB datasize 33554432 kB stacksize 524288 kB coredumpsize infinity kB memoryuse infinity kB memorylocked infinity kB maxprocesses 5547 openfiles 11095 sbsize infinity bytes vmemoryuse infinity kB > $ sysctl -a | fgrep kvm vm.kvm_free: 1159720960 vm.kvm_size: 2147479552 thx From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 15:04:19 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79FDC16A420 for ; Mon, 4 Feb 2008 15:04:19 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6425013C447 for ; Mon, 4 Feb 2008 15:04:19 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 33AA01CC038; Mon, 4 Feb 2008 07:04:19 -0800 (PST) Date: Mon, 4 Feb 2008 07:04:19 -0800 From: Jeremy Chadwick To: Primeroz lists Message-ID: <20080204150419.GA11397@eos.sc1.parodius.com> References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <20080204133832.GA6950@eos.sc1.parodius.com> <55b8c6fe0802040619m8728e68kbe408ee4a94e591a@mail.gmail.com> <55b8c6fe0802040650m3eefd1cfp79133334ed2df269@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55b8c6fe0802040650m3eefd1cfp79133334ed2df269@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 15:04:19 -0000 On Mon, Feb 04, 2008 at 02:50:09PM +0000, Primeroz lists wrote: > Just wanted to point out that anyway our crash is a Kernel panic crash and > not a Mysqld crash. But the process that's inducing the panic *every time* is mysqld; this you've already confirmed. To me this means that mysqld is responsible for tickling some sort of condition that causes a panic; it could be the fault of mysqld or it could be the fault of FreeBSD. > Platform is AMD64 so , i'm don't think it can be a problem of process size : > > > $ sudo -u mysql limits > Resource limits (current): > cputime infinity secs > filesize infinity kB > datasize 33554432 kB ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is interesting, since your machine only has 8GB of RAM. I am not familiar with the amd64 platform, so it's possible that kern.maxdsiz and kern.dfldsiz get set to something completely different than what I'm used to seeing on i386. -- | 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 Feb 4 15:28:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 907D916A418 for ; Mon, 4 Feb 2008 15:28:03 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7131B13C43E for ; Mon, 4 Feb 2008 15:28:03 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 698AC1CC033; Mon, 4 Feb 2008 07:28:03 -0800 (PST) Date: Mon, 4 Feb 2008 07:28:03 -0800 From: Jeremy Chadwick To: Primeroz lists Message-ID: <20080204152803.GB11397@eos.sc1.parodius.com> References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <20080204133832.GA6950@eos.sc1.parodius.com> <55b8c6fe0802040619m8728e68kbe408ee4a94e591a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55b8c6fe0802040619m8728e68kbe408ee4a94e591a@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 15:28:03 -0000 On Mon, Feb 04, 2008 at 02:19:05PM +0000, Primeroz lists wrote: > We using the 4bsd Scheduler (ULE is commented out in kernel conf) That's good, as it confirms you're not hitting ULE bugs. > > 3) Your kernel configuration in its entirity, if possible :-) > > attached I don't see anything in your kernel configuration that could cause this sort of situation. I think your kernel config is fine. > > 4) What options you compiled/built mysql50-server with > > As from Tinderbox log: > > configure: running /bin/sh './configure' --prefix=/usr/local > '--localstatedir=/var/db/mysql' '--without-debug' '--without-readline' > '--without-libedit' '--without-bench' '--without-extra-tools' > '--with-libwrap' '--with-mysqlfs' '--with-low-memory' > '--with-comment=FreeBSD port: mysql-server-5.0.41' > '--enable-thread-safe-client' '--with-named-thread-libs=-pthread' > '--prefix=/usr/local' '--build=amd64-portbld-freebsd6.2' 'CC=cc' > 'CFLAGS=-O2 -fno-strict-aliasing -pipe ' 'CXXFLAGS=-O2 > -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe > -felide-constructors -fno-rtti -fno-exceptions' 'CXX=c++' > 'build_alias=amd64-portbld-freebsd6.2' CFLAGS=' -DDBUG_OFF -O2 > -fno-strict-aliasing -pipe ' CXXFLAGS=' -DDBUG_OFF -O2 > -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe > -felide-constructors -fno-rtti -fno-exceptions -fno-implicit-templates > -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=1000000' > --cache-file=/dev/null --srcdir=. Okay, so no custom make variables for the port; this is the same as what we use on our box. You're also using pthreads, which should be fine (we use it as well, and not LinuxThreads). We use mysql-server-5.0.45 (fairly old, since newest is 5.0.51a); yours is a bit older. I'll have to look at the ChangeLog between 5.0.41 and 5.0.51a to see if there's any relevant changes which might give hints to what's causing it. I don't see any changes relevant between 5.0.41 and 5.0.45, 5.0.51, nor 5.0.51a which could cause what you're seeing. > I did not setup anything in the /boot/loader.conf so i guess i'm using > default values for all of those settings, See my other mail; amd64 might be doing something different with those values (calculating them in a more appropriate manner?). > Yes, configuration need fixing especially about InnoDB that is not > configured/tuned at all. > The one that take my attention more then others options is: > > set-variable = innodb_buffer_pool_size=512M > > I'm sure i need to increase that value, i'm using the default that surely is > not giving me the expected resaults ... but i wonder if that can lead to > such a crash and not just a performance problem as i read on some sources on > internet about mysql optimization. It's very possible. A lot of the tuning variables in mysqld have added side-effects in FreeBSD from what I've seen -- that is to say, if the FreeBSD box isn't configured with things like a large default data size (confirmed by limits(1)), crashes can happen. In our case it was usually mysqld segfaulting with absolutely no details as to why, but in other cases we'd seen kernel panics. Ultimately once we tuned loader.conf all of these went away, and we've had nothing but stability. > We are thinking about an OS Upgrade but what i would really like is to > understand what in mysql is triggering this crash before upgrading to new > OS/Mysql and maybe mask the problem for long time. Understood, but you need to keep in mind that if this is a FreeBSD bug which has already been fixed, the fix itself may only exist in RELENG_7 and may not be backported. I'm getting ahead of myself saying that, but it is something to keep in mind. A few more questions: 1) Shortly before the kernel panics, do you get any odd messages in /var/log/messages or on the console itself? (dmesg -a could help here). I'm left wondering if maybe the problem is something else, like a disk issue or other oddity and is manifesting itself in an odd way. 2) Are you remapping any libraries using /etc/libmap.conf, such as transparently remapping pthread to kse? 3) How big are all the InnoDB tables? If you're not sure, how big do the ibdata* and ib_logfile* files grow to? -- | 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 Feb 4 15:47:22 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9806216A418 for ; Mon, 4 Feb 2008 15:47:22 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-04.prod.mesa1.secureserver.net [64.202.165.17]) by mx1.freebsd.org (Postfix) with SMTP id 67ABD13C468 for ; Mon, 4 Feb 2008 15:47:22 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 14495 invoked from network); 4 Feb 2008 15:20:40 -0000 Received: from unknown (24.144.77.185) by smtpout09-04.prod.mesa1.secureserver.net (64.202.165.17) with ESMTP; 04 Feb 2008 15:20:40 -0000 Message-ID: <47A72CDE.20101@seclark.us> Date: Mon, 04 Feb 2008 10:18:54 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: debugging 6.1 crash X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 15:47:22 -0000 Hello List, I am trying to debug a 6.1 panic. When I run kgdb kernel.debug /var/crash/vmcore.7 all I get is: kgdb: kvm_read: invalid address (0x24) kgdb: kvm_read: invalid address (0x24) kgdb: kvm_read: invalid address (0x24) kgdb: kvm_read: invalid address (0x24) kgdb: kvm_read: invalid address (0x24) kgdb: kvm_read: invalid address (0x24) kgdb: kvm_read: invalid address (0x24) ... the info file shows: Dump header from device /dev/ad0s1b Architecture: i386 Architecture Version: 2 Dump Length: 116981760B (111 MB) Blocksize: 512 Dumptime: Mon Feb 4 04:13:09 2008 Hostname: G301482.netws.com Magic: FreeBSD Kernel Dump Version String: FreeBSD 6.1-STABLE #25: Wed Nov 14 10:30:01 EST 2007 root@J301002.nwv01.com:/mnt/src/sys/i386/compile/WOLFPAC6SMP Panic String: page fault Dump Parity: 1156397610 Bounds: 7 Dump Status: good Does my kernel.debug have to match exactly the crash file kernel. I have made the following change to my kernel that the kernel.debug is based on. --- route.h.orig Tue Apr 4 22:07:23 2006 +++ route.h Mon Dec 17 13:11:44 2007 @@ -289,6 +289,7 @@ #define RT_LOCK_INIT(_rt) \ mtx_init(&(_rt)->rt_mtx, "rtentry", NULL, MTX_DEF | MTX_DUPOK) #define RT_LOCK(_rt) mtx_lock(&(_rt)->rt_mtx) +#define RT_TRYLOCK(_rt) mtx_trylock(&(_rt)->rt_mtx) #define RT_UNLOCK(_rt) mtx_unlock(&(_rt)->rt_mtx) #define RT_LOCK_DESTROY(_rt) mtx_destroy(&(_rt)->rt_mtx) #define RT_LOCK_ASSERT(_rt) mtx_assert(&(_rt)->rt_mtx, MA_OWNED) --- route.c.orig Tue Oct 30 19:07:54 2007 +++ route.c Mon Dec 17 15:13:20 2007 @@ -996,6 +996,7 @@ struct radix_node_head *rnh = rt_tables[dst->sa_family]; int dlen = SA_SIZE(dst), glen = SA_SIZE(gate); +again: RT_LOCK_ASSERT(rt); /* @@ -1029,7 +1030,15 @@ RT_REMREF(rt); return (EADDRINUSE); /* failure */ } - RT_LOCK(rt); + /* + * Try to reacquire the lock on rt, and if it fails, + * clean state and restart from scratch. + */ + if (!RT_TRYLOCK(rt)) { + RTFREE_LOCKED(gwrt); + RT_LOCK(rt); + goto again; + } /* * If there is already a gwroute, then drop it. If we * are asked to replace route with itself, then do Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 16:05:45 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9974316A46E for ; Mon, 4 Feb 2008 16:05:45 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1FFF813C4E5 for ; Mon, 4 Feb 2008 16:05:44 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so1659601rvb.43 for ; Mon, 04 Feb 2008 08:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=KOEOYuGhD6cMP6Rn9T+wxIPSQqgg3eCLINb5UR3A+lQ=; b=DqlqlD6h9l8i+cVBBYvCWIW6GXAyysKnm4pkwCT534ZgxJD8F6oCD1TFnCdKMqWOBS0BehrQdK77r7HTZk7cgVs70vLxFbnnqVZF+RL6N2RoFX9wQ3jU0b3/QFLWr/xIktSJHcxV2ljZzSq0+QdUb/FG3gUcfwNaopEKk4sebG8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QMCPkvv9FL8BHdyjbl31UxSlBA1sLvkYAWgdySle8jp6PCcIujW7wm8hmzHZm3MBqMF0elzubSSm+amX6MLigrQhfYq8iNSbT3Nw3nrZZqsYYkOo+lbkM7aWkmstl77T0+QPKFtaESUf3y4z6PrtHnlr5rwLhstYR8Y+SQkD8mw= Received: by 10.141.99.4 with SMTP id b4mr2627452rvm.275.1202141144468; Mon, 04 Feb 2008 08:05:44 -0800 (PST) Received: by 10.140.203.6 with HTTP; Mon, 4 Feb 2008 08:05:44 -0800 (PST) Message-ID: <55b8c6fe0802040805o5c075e54m42145fec4a1fd4c1@mail.gmail.com> Date: Mon, 4 Feb 2008 16:05:44 +0000 From: "Primeroz lists" To: "Jeremy Chadwick" In-Reply-To: <20080204152803.GB11397@eos.sc1.parodius.com> MIME-Version: 1.0 References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <20080204133832.GA6950@eos.sc1.parodius.com> <55b8c6fe0802040619m8728e68kbe408ee4a94e591a@mail.gmail.com> <20080204152803.GB11397@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 16:05:45 -0000 > > We use mysql-server-5.0.45 (fairly old, since newest is 5.0.51a); yours > is a bit older. I'll have to look at the ChangeLog between 5.0.41 and > 5.0.51a to see if there's any relevant changes which might give hints to > what's causing it. > > I don't see any changes relevant between 5.0.41 and 5.0.45, 5.0.51, > nor 5.0.51a which could cause what you're seeing. Yes, i looked at that changes but nothing really seemed to relate to my issue that's why i did not proceeded with a mysql straight upgrade. > > > > I did not setup anything in the /boot/loader.conf so i guess i'm using > > default values for all of those settings, > > See my other mail; amd64 might be doing something different with those > values (calculating them in a more appropriate manner?). I'm looking into that right now , especially about having a maxdsiz bigger then actual RAM+Swap ... > A few more questions: > > 1) Shortly before the kernel panics, do you get any odd messages in > /var/log/messages or on the console itself? (dmesg -a could help here). > I'm left wondering if maybe the problem is something else, like a disk > issue or other oddity and is manifesting itself in an odd way. Not at all ... very wierd indeed. I see totally nothing bad in all sort of information i can find before the crash. Everything is fine and then at some point i see the messages from kernel booting again. > > 2) Are you remapping any libraries using /etc/libmap.conf, such as > transparently remapping pthread to kse? > No, i'm remapping libpthread -> libthr but we run the same mapping on a bunch of other mysql server without issues > > 3) How big are all the InnoDB tables? If you're not sure, how big do > the ibdata* and ib_logfile* files grow to? > Quite big actually, -rw-rw---- 1 mysql mysql 5.0M Feb 4 15:58 ib_logfile0 -rw-rw---- 1 mysql mysql 5.0M Feb 4 15:58 ib_logfile1 -rw-rw---- 1 mysql mysql 4.2G Feb 4 15:58 ibdata1 ... ... thanks FC From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 16:09:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3EBE16A41B; Mon, 4 Feb 2008 16:09:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4EDAD13C47E; Mon, 4 Feb 2008 16:09:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3676843F21C; Mon, 4 Feb 2008 18:09:20 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMoGIBdWLF3D; Mon, 4 Feb 2008 18:09:20 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id CAFC643F21B; Mon, 4 Feb 2008 18:09:19 +0200 (EET) Message-ID: <47A738AE.5070900@icyb.net.ua> Date: Mon, 04 Feb 2008 18:09:18 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 References: <4799D78F.6000405@icyb.net.ua> <47A097FA.3090303@icyb.net.ua> <20080130164508.GC6257@suse.cz> <47A2E7E5.1040307@icyb.net.ua> <20080201093806.GA4632@suse.cz> In-Reply-To: <20080201093806.GA4632@suse.cz> Content-Type: multipart/mixed; boundary="------------060302010604060102000307" Cc: freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: ps/2 mouse 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, 04 Feb 2008 16:09:21 -0000 This is a multi-part message in MIME format. --------------060302010604060102000307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit on 01/02/2008 11:38 Vojtech Pavlik said the following: > On Fri, Feb 01, 2008 at 11:35:33AM +0200, Andriy Gapon wrote: >> I compared FreeBSD and Linux sources more thoroughly and found the >> following: >> http://lxr.linux.no/linux+v2.6.24/drivers/input/mouse/psmouse-base.c#L464 >> static int im_explorer_detect(struct psmouse *psmouse, int set_properties) >> { >> struct ps2dev *ps2dev = &psmouse->ps2dev; >> unsigned char param[2]; >> >> intellimouse_detect(psmouse, 0); >> >> I.e., first thing the explorer probe does is massaging a mouse with >> IntelliMouse magic commands. >> >> I did the same in FreeBSD psm.c, i.e., added a call to >> enable_msintelli() at the very start of enable_msexplorer(). And voil - >> everything is perfect, correct ID is returned, probing succeeds, the >> mouse works great. >> >> I think that this change is quite safe to make in FreeBSD, because with >> Linux user-base we can be 99% percent sure that this change won't break >> anything. > > It is even correct: A mouse isn't required to be able to jump straight > into the Explorer mode, it is supposed to always go through the > IntelliMouse mode. Any takers to test this change with your current PS/2 mouse (either working or non-working) ? Any takers to commit this change ? :-) Will this issue get more traction if I file a PR? -- Andriy Gapon --------------060302010604060102000307 Content-Type: text/x-patch; name="psm.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="psm.c.patch" --- psm.c.orig 2008-02-04 18:07:34.000000000 +0200 +++ psm.c 2008-02-04 18:08:14.000000000 +0200 @@ -3109,6 +3109,8 @@ enable_msexplorer(struct psm_softc *sc) int id; int i; + enable_msintelli(sc); + /* the special sequence to enable the extra buttons and the roller. */ for (i = 0; i < sizeof(rate1)/sizeof(rate1[0]); ++i) { if (set_mouse_sampling_rate(kbdc, rate1[i]) != rate1[i]) --------------060302010604060102000307-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 16:19:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 140A616A41A for ; Mon, 4 Feb 2008 16:19:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0E613C45B for ; Mon, 4 Feb 2008 16:19:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JM42Y-0004Rc-10 for freebsd-stable@freebsd.org; Mon, 04 Feb 2008 18:19:27 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id m14GJ1MY041683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 18:19: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.14.2/8.14.2) with ESMTP id m14GJKDq028441; Mon, 4 Feb 2008 18:19:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m14GJK32028440; Mon, 4 Feb 2008 18:19:20 +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: Mon, 4 Feb 2008 18:19:20 +0200 From: Kostik Belousov To: Primeroz lists Message-ID: <20080204161920.GN57756@deviant.kiev.zoral.com.ua> References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZOzza+p1BO565g7i" Content-Disposition: inline In-Reply-To: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Scanner-Signature: 7efc2c4198efd9af05add900528fdda3 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2165 [Feb 04 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {TO: local part of email appears in body} X-SpamTest-Method: none X-SpamTest-Rate: 9 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 16:19:29 -0000 --ZOzza+p1BO565g7i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 04, 2008 at 12:50:32PM +0000, Primeroz lists wrote: > Hi all, >=20 > we are experiencing repeated crash on a Dell PowerEdge 2950 (rev 1 or 2). >=20 > FBSD release is 6.2-RELEASE-p5 , AMD64. 2xXeon QuadCore and 8G of Ram. >=20 > MySQL Version is 5.0.41 with following configuration settings: >=20 > set-variable =3D key_buffer=3D768M > set-variable =3D table_cache=3D800 > set-variable =3D sort_buffer=3D24M > set-variable =3D myisam_sort_buffer_size=3D256M > set-variable =3D record_buffer=3D16M > set-variable =3D max_allowed_packet=3D10M > set-variable =3D thread_stack=3D128K > set-variable =3D join_buffer=3D512M > set-variable =3D max_heap_table_size=3D256M > set-variable =3D max_connections=3D300 > set-variable =3D tmp_table_size=3D384M > set-variable =3D query_cache_size=3D402653184 > set-variable =3D query_cache_limit=3D134217728 > set-variable =3D read_rnd_buffer_size=3D10M > set-variable =3D ft_min_word_len=3D1 > pid-file =3D /var/db/mysqld.pid > tmpdir =3D /var/tmp > ft_stopword_file =3D '' > set-variable =3D thread_cache_size=3D80 > set-variable =3D myisam_stats_method=3Dnulls_equal >=20 >=20 > The system is crashing repeatedly and from the graphs we collect on the b= ox > i can see that every time before the crash we have an intensive usage of > *InnoDB* related resources, i collected several vmcore dump and attached = is > what i've been able to extract. >=20 > I'm not sure how much the *InnoDB* usage is related to the crash, btw i'm > quite sure that it is triggering the crash. >=20 > I've looked on the various CVS and releases to see if anything related to= my > crash has been updated in the last period but i did not find anything > specifically related so i'm wondering if anybody else had experience of t= his > kind of problems before proceding to a blind upgrade or any other blind > solution. >=20 >=20 > > $ sudo kgdb /usr/obj/usr/src/sys/PE2950/kernel.debug vmcore.2 > Password: > [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.s= o: > 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 detail= s. > This GDB was configured as "amd64-marcel-freebsd". >=20 > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 5; apic id =3D 05 > fault virtual address =3D 0x100166887ad > fault code =3D supervisor read, page not present > instruction pointer =3D 0x8:0xffffffff803fa290 > stack pointer =3D 0x10:0xffffffffba0a9980 > frame pointer =3D 0x10:0x2 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 1038 (mysqld) > trap number =3D 12 > panic: page fault > cpuid =3D 5 > Uptime: 1d4h37m54s > Dumping 8191 MB (3 chunks) > chunk 0: 1MB (156 pages) ... ok > chunk 1: 3327MB (851624 pages) 3311 3295 3279 3263 3247 3231 3215 3199 > 3183 3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 2959 > 2943 2927 2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 > 2703 2687 2671 2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 > 2463 2447 2431 2415 2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 > 2223 2207 2191 2175 2159 2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 > 1983 1967 1951 1935 1919 1903 1887 1871 1855 1839 1823 1807 1791 1775 1759 > 1743 1727 1711 1695 1679 1663 1647 1631 1615 1599 1583 1567 1551 1535 1519 > 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 > 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 > 1023 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 4= 47 > 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 1= 43 > 127 111 95 79 63 47 31 15 ... ok > chunk 2: 4864MB (1245184 pages) 4849 4833 4817 4801 4785 4769 4753 4737 > 4721 4705 4689 4673 4657 4641 4625 4609 4593 4577 4561 4545 4529 4513 4497 > 4481 4465 4449 4433 4417 4401 4385 4369 4353 4337 4321 4305 4289 4273 4257 > 4241 4225 4209 4193 4177 4161 4145 4129 4113 4097 4081 4065 4049 4033 4017 > 4001 3985 3969 3953 3937 3921 3905 3889 3873 3857 3841 3825 3809 3793 3777 > 3761 3745 3729 3713 3697 3681 3665 3649 3633 3617 3601 3585 3569 3553 3537 > 3521 3505 3489 3473 3457 3441 3425 3409 3393 3377 3361 3345 3329 3313 3297 > 3281 3265 3249 3233 3217 3201 3185 3169 3153 3137 3121 3105 3089 3073 3057 > 3041 3025 3009 2993 2977 2961 2945 2929 2913 2897 2881 2865 2849 2833 2817 > 2801 2785 2769 2753 2737 2721 2705 2689 2673 2657 2641 2625 2609 2593 2577 > 2561 2545 2529 2513 2497 2481 2465 2449 2433 2417 2401 2385 2369 2353 2337 > 2321 2305 2289 2273 2257 2241 2225 2209 2193 2177 2161 2145 2129 2113 2097 > 2081 2065 2049 2033 2017 2001 1985 1969 1953 1937 1921 1905 1889 1873 1857 > 1841 1825 1809 1793 1777 1761 1745 1729 1713 1697 1681 1665 1649 1633 1617 > 1601 1585 1569 1553 1537 1521 1505 1489 1473 1457 1441 1425 1409 1393 1377 > 1361 1345 1329 1313 1297 1281 1265 1249 1233 1217 1201 1185 1169 1153 1137 > 1121 1105 1089 1073 1057 1041 1025 1009 993 977 961 945 929 913 897 881 8= 65 > 849 833 817 801 785 769 753 737 721 705 689 673 657 641 625 609 593 577 5= 61 > 545 529 513 497 481 465 449 433 417 401 385 369 353 337 321 305 289 273 2= 57 > 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 1 >=20 > #0 doadump () at pcpu.h:172 > 172 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:172 > #1 0x0000000000000004 in ?? () > #2 0xffffffff802a7d67 in boot (howto=3D260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #3 0xffffffff802a8401 in panic (fmt=3D0xffffff0036f9c720 > "???\206C???\001???????????????%\\\001?????????\200i??????") > at /usr/src/sys/kern/kern_shutdown.c:565 > #4 0xffffffff80425f7f in trap_fatal (frame=3D0xffffff0036f9c720, > eva=3D18446742981617878704) > at /usr/src/sys/amd64/amd64/trap.c:660 > #5 0xffffffff8042629f in trap_pfault (frame=3D0xffffffffba0a98d0, usermo= de=3D0) > at /usr/src/sys/amd64/amd64/trap.c:573 > #6 0xffffffff80426553 in trap (frame=3D > {tf_rdi =3D 1099887576672, tf_rsi =3D 0, tf_rdx =3D 0, tf_rcx =3D -= 1173710312, > tf_r8 =3D -1093564261992, tf_r9 =3D -1173710304, tf_rax =3D -1173710293, = tf_rbx =3D > -1093564262000, tf_rbp =3D 2, tf_r10 =3D -1098589288672, tf_r11 =3D 43583= 6558, > tf_r12 =3D 1099887576672, tf_r13 =3D -1093564262000, tf_r14 =3D 435835520= , tf_r15 > =3D -1173710312, tf_trapno =3D 12, tf_addr =3D 1099887577005, tf_flags =3D > -2144607018, tf_err =3D 0, tf_rip =3D -2143313264, tf_cs =3D 8, tf_rflags= =3D 66118, > tf_rsp =3D -1173710440, tf_ss =3D 16}) > at /usr/src/sys/amd64/amd64/trap.c:352 > #7 0xffffffff8041173b in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:168 > #8 0xffffffff803fa290 in _vm_map_unlock () at /usr/src/sys/vm/vm_map.c:4= 43 > #9 0xffffffff803fdecc in vm_map_lookup (var_map=3D0xffffffffba0a9a10, > vaddr=3D435835520, fault_typea=3D2 '\002', > out_entry=3D0xffffffffba0a9a18, object=3D0xffffff01627d9998, > pindex=3D0xffffffffba0a9a20, out_prot=3D0xffffffffba0a9a2b "", > wired=3D0xffffffffba0a9a2c) at /usr/src/sys/vm/vm_map.c:3074 The vm_map.c does not contain a call to the vm_map_unlock() at the line 3074. Please, rebuild you kernel from scratch. In case this does not help, I ask you to show the backtrace from the ddb. Also, to speed up the conversation, could you, please, for each + from the ddb output, do the list *(+) in the kgdb ? > #10 0xffffffff802b845e in umtx_key_get (td=3D0xffffff0036f9c720, > umtx=3D0x19fa5280, key=3D0xffffff01627d9990) > at /usr/src/sys/kern/kern_umtx.c:312 > #11 0xffffffff802b8578 in _do_lock (td=3D0xffffff0036f9c720, umtx=3D0x19f= a5280, > id=3D100582, timo=3D0) > at /usr/src/sys/kern/kern_umtx.c:362 > #12 0xffffffff802b99e9 in _umtx_op (td=3D0xffffff0036f9c720, uap=3D0x188e= 6) at > /usr/src/sys/kern/kern_umtx.c:545 > #13 0xffffffff80426dd1 in syscall (frame=3D > {tf_rdi =3D 435835520, tf_rsi =3D 0, tf_rdx =3D 100582, tf_rcx =3D = 0, tf_r8 =3D > 0, tf_r9 =3D 140737452053060, tf_rax =3D 454, tf_rbx =3D 100582, tf_rbp = =3D > 435835520, tf_r10 =3D 1, tf_r11 =3D 582, tf_r12 =3D 9982128, tf_r13 =3D 1= 024, tf_r14 > =3D 0, tf_r15 =3D 0, tf_trapno =3D 12, tf_addr =3D 1387466752, tf_flags = =3D 0, tf_err > =3D 2, tf_rip =3D 34378206780, tf_cs =3D 43, tf_rflags =3D 582, tf_rsp =3D > 140737452052808, tf_ss =3D 35}) at /usr/src/sys/amd64/amd64/trap.c:792 > #14 0xffffffff804118d8 in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:270 > #15 0x000000080119ce3c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) >=20 > (kgdb) up 6 > #6 0xffffffff80426553 in trap (frame=3D > {tf_rdi =3D 1099887576672, tf_rsi =3D 0, tf_rdx =3D 0, tf_rcx =3D -= 1173710312, > tf_r8 =3D -1093564261992, tf_r9 =3D -1173710304, tf_rax =3D -1173710293, = tf_rbx =3D > -1093564262000, tf_rbp =3D 2, tf_r10 =3D -1098589288672, tf_r11 =3D 43583= 6558, > tf_r12 =3D 1099887576672, tf_r13 =3D -1093564262000, tf_r14 =3D 435835520= , tf_r15 > =3D -1173710312, tf_trapno =3D 12, tf_addr =3D 1099887577005, tf_flags =3D > -2144607018, tf_err =3D 0, tf_rip =3D -2143313264, tf_cs =3D 8, tf_rflags= =3D 66118, > tf_rsp =3D -1173710440, tf_ss =3D 16}) > at /usr/src/sys/amd64/amd64/trap.c:352 > 352 (void) trap_pfault(&frame, FALSE); >=20 > (kgdb) up > #7 0xffffffff8041173b in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:168 > 168 call trap > Current language: auto; currently asm > (kgdb) up > #8 0xffffffff803fa290 in _vm_map_unlock () at /usr/src/sys/vm/vm_map.c:4= 43 > 443 _sx_xunlock(&map->lock, file, line); > Current language: auto; currently c > (kgdb) up > #9 0xffffffff803fdecc in vm_map_lookup (var_map=3D0xffffffffba0a9a10, > vaddr=3D435835520, fault_typea=3D2 '\002', > out_entry=3D0xffffffffba0a9a18, object=3D0xffffff01627d9998, > pindex=3D0xffffffffba0a9a20, out_prot=3D0xffffffffba0a9a2b "", > wired=3D0xffffffffba0a9a2c) at /usr/src/sys/vm/vm_map.c:3074 > 3074 vm_map_lock_read(map); > (kgdb) list > 3069 RetryLookup:; > 3070 /* > 3071 * Lookup the faulting address. > 3072 */ > 3073 > 3074 vm_map_lock_read(map); > 3075 #define RETURN(why) \ > 3076 { \ > 3077 vm_map_unlock_read(map); \ > 3078 return (why); \ > (kgdb) p map > $1 =3D 0x10016688660 > (kgdb) down > #8 0xffffffff803fa290 in _vm_map_unlock () at /usr/src/sys/vm/vm_map.c:4= 43 > 443 _sx_xunlock(&map->lock, file, line); > (kgdb) list > 438 { > 439 > 440 if (map->system_map) > 441 _mtx_unlock_flags(&map->system_mtx, 0, file, line= ); > 442 else > 443 _sx_xunlock(&map->lock, file, line); > 444 } > 445 > 446 void > 447 _vm_map_lock_read(vm_map_t map, const char *file, int line) >=20 >=20 > Thanks, > Francesco Ciocchetti > _______________________________________________ > 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" --ZOzza+p1BO565g7i Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkenOwcACgkQC3+MBN1Mb4iQAwCeKSO9l/L7HOdVkJp8SLzL7xf0 KNMAnAns0NUrA1UVKxuLND9mhPkBEfPN =rYMJ -----END PGP SIGNATURE----- --ZOzza+p1BO565g7i-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 16:35:16 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1289C16A476 for ; Mon, 4 Feb 2008 16:35:16 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id A5E3013C45B for ; Mon, 4 Feb 2008 16:35:15 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: by wx-out-0506.google.com with SMTP id i29so1819235wxd.7 for ; Mon, 04 Feb 2008 08:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=0J1FmFNQdUKNoUDEC3cI9dRJTZGU3oARf3f5G/pJ0Z4=; b=T7mnxwaFCbLeWY1txycU8QMMPt4rG/bKqHW7p8IHd+e2OBrEgD5FCvEIUwDZQ1r8b71KsaIbEQTNRQ0L9olzmmA8kBSlwoD7rULDZuowCcMy7XQJjqpl+v+/swnNCDbNJDiFjMbLSIvFjz1HnDzPlnv9Kd3+pjEu9xInedSbpPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=BrO67Wfix0TT6Dm7ukPLyp1kuX26QDnEN01ZpK1uU0Bbmf8O9aKUV48PSZwazS5l/kTuarRCyYbOp5oGfemWxMa5DGAAKXXuJMO6rAbOVv6qxUSoKA8pJ9fbZwBi7Z+lcB5UXusZeG5q0G7iQCWbEn6QN88pSQgnkb/ALnAdcEc= Received: by 10.141.179.5 with SMTP id g5mr4877921rvp.18.1202142913852; Mon, 04 Feb 2008 08:35:13 -0800 (PST) Received: by 10.140.203.6 with HTTP; Mon, 4 Feb 2008 08:35:13 -0800 (PST) Message-ID: <55b8c6fe0802040835y1c269f2do1a5f8430ce495f68@mail.gmail.com> Date: Mon, 4 Feb 2008 16:35:13 +0000 From: "Primeroz lists" To: "Kostik Belousov" In-Reply-To: <20080204161920.GN57756@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <20080204161920.GN57756@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 16:35:16 -0000 > > The vm_map.c does not contain a call to the vm_map_unlock() at the > line 3074. > Mine does ... is Revision *1.366.2.3 *on Freebsd CVS for vm_map.c , CVS TAG RELENG_6_2 Please, rebuild you kernel from scratch. In case this does not help, > I ask you to show the backtrace from the ddb. Also, to speed up the > conversation, could you, please, for each + from the > ddb output, do the list *(+) in the kgdb ? > > Working on this thanks FC From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 16:40:01 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6AE716A41A for ; Mon, 4 Feb 2008 16:40:01 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by mx1.freebsd.org (Postfix) with SMTP id 718E313C461 for ; Mon, 4 Feb 2008 16:40:01 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 7766 invoked from network); 4 Feb 2008 16:39:59 -0000 Received: from unknown (24.144.77.185) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 04 Feb 2008 16:39:56 -0000 Message-ID: <47A73F6E.8070309@seclark.us> Date: Mon, 04 Feb 2008 11:38:06 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <47A72CDE.20101@seclark.us> In-Reply-To: <47A72CDE.20101@seclark.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: debugging 6.1 crash X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 16:40:01 -0000 Stephen Clark wrote: > Hello List, > > I am trying to debug a 6.1 panic. When I run kgdb kernel.debug > /var/crash/vmcore.7 all I get is: > > kgdb: kvm_read: invalid address (0x24) > kgdb: kvm_read: invalid address (0x24) > kgdb: kvm_read: invalid address (0x24) > kgdb: kvm_read: invalid address (0x24) > kgdb: kvm_read: invalid address (0x24) > kgdb: kvm_read: invalid address (0x24) > kgdb: kvm_read: invalid address (0x24) > ... > > the info file shows: > Dump header from device /dev/ad0s1b > Architecture: i386 > Architecture Version: 2 > Dump Length: 116981760B (111 MB) > Blocksize: 512 > Dumptime: Mon Feb 4 04:13:09 2008 > Hostname: G301482.netws.com > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 6.1-STABLE #25: Wed Nov 14 10:30:01 EST 2007 > root@J301002.nwv01.com:/mnt/src/sys/i386/compile/WOLFPAC6SMP > Panic String: page fault > Dump Parity: 1156397610 > Bounds: 7 > Dump Status: good > > > Does my kernel.debug have to match exactly the crash file kernel. I > have made the following change > to my kernel that the kernel.debug is based on. > --- route.h.orig Tue Apr 4 22:07:23 2006 > +++ route.h Mon Dec 17 13:11:44 2007 > @@ -289,6 +289,7 @@ > #define RT_LOCK_INIT(_rt) \ > mtx_init(&(_rt)->rt_mtx, "rtentry", NULL, MTX_DEF | MTX_DUPOK) > #define RT_LOCK(_rt) mtx_lock(&(_rt)->rt_mtx) > +#define RT_TRYLOCK(_rt) mtx_trylock(&(_rt)->rt_mtx) > #define RT_UNLOCK(_rt) mtx_unlock(&(_rt)->rt_mtx) > #define RT_LOCK_DESTROY(_rt) mtx_destroy(&(_rt)->rt_mtx) > #define RT_LOCK_ASSERT(_rt) mtx_assert(&(_rt)->rt_mtx, > MA_OWNED) > --- route.c.orig Tue Oct 30 19:07:54 2007 > +++ route.c Mon Dec 17 15:13:20 2007 > @@ -996,6 +996,7 @@ > struct radix_node_head *rnh = rt_tables[dst->sa_family]; > int dlen = SA_SIZE(dst), glen = SA_SIZE(gate); > > +again: > RT_LOCK_ASSERT(rt); > > /* > @@ -1029,7 +1030,15 @@ > RT_REMREF(rt); > return (EADDRINUSE); /* failure */ > } > - RT_LOCK(rt); > + /* > + * Try to reacquire the lock on rt, and if it fails, > + * clean state and restart from scratch. > + */ > + if (!RT_TRYLOCK(rt)) { > + RTFREE_LOCKED(gwrt); > + RT_LOCK(rt); > + goto again; > + } > /* > * If there is already a gwroute, then drop it. If we > * are asked to replace route with itself, then do > > Thanks, > Steve > Well I recompiled the kernel without the above changes and I am now kgdb comes up. It looks like the panic instruction pointer is in a loadable kernel module. Is there some way to have kgdb look at the kernel module? Below is what i get now: 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: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0b4536c stack pointer = 0x28:0xc7516a30 frame pointer = 0x28:0xc7516a48 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 = 13 (swi1: net) trap number = 12 panic: page fault cpuid = 0 Uptime: 8h31m18s Dumping 111 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 111MB (28400 pages) 95 79 63 47 31 15 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc06492b2 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 #2 0xc06495d9 in panic (fmt=0xc0910386 "%s") at ../../../kern/kern_shutdown.c:565 #3 0xc082d99c in trap_fatal (frame=0xc75169f0, eva=4) at ../../../i386/i386/trap.c:837 #4 0xc082d6db in trap_pfault (frame=0xc75169f0, usermode=0, eva=4) at ../../../i386/i386/trap.c:745 #5 0xc082d335 in trap (frame= {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -950965440, tf_esi = -1026657792, tf_ebp = -950965688, tf_isp = -950965732, tf_ebx = -1045086208, tf_edx = -1047438316, tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1061923988, tf_cs = 32, tf_eflags = 590406, tf_esp = -929974260, tf_ss = 0}) at ../../../i386/i386/trap.c:435 #6 0xc08198fa in calltrap () at ../../../i386/i386/exception.s:139 #7 0xc0b4536c in ?? () Cannot access memory at address 0xc891b80c (kgdb) list *0xc0b4536c No source file for address 0xc0b4536c. (kgdb) looking at the loadable kernel modules on the system I get: sudo kldstat Id Refs Address Size Name 1 13 0xc0400000 72862c kernel 2 1 0xc0b29000 2340 accf_http.ko 3 1 0xc0b2c000 3b180 ipf.ko 4 1 0xc0b68000 5c2f8 acpi.ko 5 1 0xc1dcc000 3000 ng_iface.ko 6 1 0xc1dcf000 6000 ng_ppp.ko 7 1 0xc1dd6000 4000 ng_bpf.ko 8 1 0xc1ddd000 4000 ng_vjc.ko Which makes think the panic instruction pointer is in ipf.ko? This is ipf 4.1.26 compiled out of the kernel tree. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 17:21:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAB1316A4C9 for ; Mon, 4 Feb 2008 17:21:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 9B7C713C4E9 for ; Mon, 4 Feb 2008 17:21:03 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m14HL1bZ001521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2008 04:21:01 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m14HL0Qv001412; Tue, 5 Feb 2008 04:21:00 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m14HL0bY001408; Tue, 5 Feb 2008 04:21:00 +1100 (EST) (envelope-from peter) Date: Tue, 5 Feb 2008 04:21:00 +1100 From: Peter Jeremy To: Jeremy Chadwick Message-ID: <20080204172100.GB1124@server.vk2pj.dyndns.org> References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <20080204133832.GA6950@eos.sc1.parodius.com> <55b8c6fe0802040619m8728e68kbe408ee4a94e591a@mail.gmail.com> <55b8c6fe0802040650m3eefd1cfp79133334ed2df269@mail.gmail.com> <20080204150419.GA11397@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <20080204150419.GA11397@eos.sc1.parodius.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 17:21:05 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 04, 2008 at 07:04:19AM -0800, Jeremy Chadwick wrote: >But the process that's inducing the panic *every time* is mysqld; this >you've already confirmed. To me this means that mysqld is responsible >for tickling some sort of condition that causes a panic; it could be the >fault of mysqld or it could be the fault of FreeBSD. By definition, if a userland process causes a kernel panic, it's the fault of the kernel. >> > $ sudo -u mysql limits >> Resource limits (current): >> cputime infinity secs >> filesize infinity kB >> datasize 33554432 kB These are defaults and so are unlikely to be causing problems. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHp0l8/opHv/APuIcRAlZBAKCgSb4V1OORbGmaYW2KhvT4BgwVUwCfeHzZ p0tC1hD0gklomasxYFrBYqw= =d6AN -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 17:46:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 111AC16A418 for ; Mon, 4 Feb 2008 17:46:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id 9924013C448 for ; Mon, 4 Feb 2008 17:46:28 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m14HkPoB002607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2008 04:46:26 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m14HkPhR001602; Tue, 5 Feb 2008 04:46:25 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m14HkPEr001601; Tue, 5 Feb 2008 04:46:25 +1100 (EST) (envelope-from peter) Date: Tue, 5 Feb 2008 04:46:25 +1100 From: Peter Jeremy To: Primeroz lists Message-ID: <20080204174625.GC1124@server.vk2pj.dyndns.org> References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <20080204161920.GN57756@deviant.kiev.zoral.com.ua> <55b8c6fe0802040835y1c269f2do1a5f8430ce495f68@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline In-Reply-To: <55b8c6fe0802040835y1c269f2do1a5f8430ce495f68@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 04 Feb 2008 17:46:29 -0000 --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 04, 2008 at 04:35:13PM +0000, Primeroz lists wrote: >> >> The vm_map.c does not contain a call to the vm_map_unlock() at the >> line 3074. >> > >Mine does ... is Revision *1.366.2.3 *on Freebsd CVS for vm_map.c , CVS TAG >RELENG_6_2 Not according to either the kgdb output you included or http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/vm/vm_map.c?annotate=3D1.366.= 2.3 both of which show a call to vm_map_lock_read() at line 3074. I can't find anywhere that vm_map_lookup() calls vm_map_unlock() - it always calls vm_map_unlock_read(). --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHp09x/opHv/APuIcRAspoAJ4+eVS+APzJ05P2iKH8N9enHpm71QCfRExg 3OnvMvzl3WKQa77EvJwfNf0= =ikRy -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 18:07:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 137C416A468; Mon, 4 Feb 2008 18:07:29 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.freebsd.org (Postfix) with ESMTP id B487413C4EB; Mon, 4 Feb 2008 18:07:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from desktop.home.serebryakov.spb.ru (unknown [89.163.10.141]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTP id E893813DF84; Mon, 4 Feb 2008 20:50:40 +0300 (MSK) Date: Mon, 4 Feb 2008 20:49:03 +0300 From: Lev Serebryakov X-Mailer: The Bat! (v3.99.3) Professional Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1188949738.20080204204903@serebryakov.spb.ru> To: Ivan Voras In-Reply-To: References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re[2]: gjournal panic 7.0-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 18:07:29 -0000 Hello, Ivan. You wrote 3 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2008 =D0=B3., 23:35:= 44: > If so, this is the same class of errors as ZFS (some would call it > "tuning errors") Why this is ever possible on "stable" (I know, that "stable" doesn't meand really "stable" these days, but at least it is not -CURRENT, whcih can be experimental) release of server operating system?! I was courious (and upset) when read about ZFS panics, and now I'm just courious and dissapointed. My humble opinion is, that release system (and I'm almost sure, that this panic and ZFS panics will not be fixed whwn 7.0 becomes RELEASE instead of RC1) CAN NOT PANIC on healthy hardware. AT ALL. NEVER. Ok, every programmer (me too) makes mistakes. Software contains bugs. Ok. But bugs are bugs. They MUST be fixed. And now we have special "tuning errors" which (correct me, if I wrong, and I want to be wrong here!) will not be fixed. They will be hidden under tuning guides and recomendations, and signs "Beware! Dragons are here!" Hey, are FreeBSD experimental system or production one?! Ok, ZFS (gjournal, whatever) need more resources (memory, journal space, whatever) and system is mis-tuned and can not provide this resource (in case of ZFS and 32bit systems it seems, that ADDRESS SPACE is such resource). I understand, that provide GOOD service in such conditions is not possible/valuable (especially in ZFS/32bit case). But now system doesn't provide ANY service, it PANIC! Which can disturb other services on this system, which can continue work even without limited resource (for example, NAT can work even if HTTP proxy is failed due to problems with gjournalled/ZFS cache). Ok, subsystem can not work efficiently. Degrade service. Swith to "one 512 byte sector per second" speed mode. Disable all caches, doesn't try to work with all features. Complain 10 times/second on console (and dmesg buffer). Ok. But PANIC?! NO-NO-NO!!! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 23:00:44 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D51B16A51A for ; Mon, 4 Feb 2008 23:00:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 37A4213C45D for ; Mon, 4 Feb 2008 23:00:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 230850012-1834499 for multiple; Mon, 04 Feb 2008 18:00:44 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m14N0STb072283; Mon, 4 Feb 2008 18:00:39 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-stable@freebsd.org, Stephen.Clark@seclark.us Date: Mon, 4 Feb 2008 14:59:51 -0500 User-Agent: KMail/1.9.7 References: <47A72CDE.20101@seclark.us> <47A73F6E.8070309@seclark.us> In-Reply-To: <47A73F6E.8070309@seclark.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802041459.51872.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 04 Feb 2008 18:00:39 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5686/Mon Feb 4 16:13:58 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: debugging 6.1 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: Mon, 04 Feb 2008 23:00:44 -0000 On Monday 04 February 2008 11:38:06 am Stephen Clark wrote: > Stephen Clark wrote: > > Hello List, > > > > I am trying to debug a 6.1 panic. When I run kgdb kernel.debug > > /var/crash/vmcore.7 all I get is: > > > > kgdb: kvm_read: invalid address (0x24) > > kgdb: kvm_read: invalid address (0x24) > > kgdb: kvm_read: invalid address (0x24) > > kgdb: kvm_read: invalid address (0x24) > > kgdb: kvm_read: invalid address (0x24) > > kgdb: kvm_read: invalid address (0x24) > > kgdb: kvm_read: invalid address (0x24) > > ... > > > > the info file shows: > > Dump header from device /dev/ad0s1b > > Architecture: i386 > > Architecture Version: 2 > > Dump Length: 116981760B (111 MB) > > Blocksize: 512 > > Dumptime: Mon Feb 4 04:13:09 2008 > > Hostname: G301482.netws.com > > Magic: FreeBSD Kernel Dump > > Version String: FreeBSD 6.1-STABLE #25: Wed Nov 14 10:30:01 EST 2007 > > root@J301002.nwv01.com:/mnt/src/sys/i386/compile/WOLFPAC6SMP > > Panic String: page fault > > Dump Parity: 1156397610 > > Bounds: 7 > > Dump Status: good > > > > > > Does my kernel.debug have to match exactly the crash file kernel. I > > have made the following change > > to my kernel that the kernel.debug is based on. > > --- route.h.orig Tue Apr 4 22:07:23 2006 > > +++ route.h Mon Dec 17 13:11:44 2007 > > @@ -289,6 +289,7 @@ > > #define RT_LOCK_INIT(_rt) \ > > mtx_init(&(_rt)->rt_mtx, "rtentry", NULL, MTX_DEF | MTX_DUPOK) > > #define RT_LOCK(_rt) mtx_lock(&(_rt)->rt_mtx) > > +#define RT_TRYLOCK(_rt) mtx_trylock(&(_rt)->rt_mtx) > > #define RT_UNLOCK(_rt) mtx_unlock(&(_rt)->rt_mtx) > > #define RT_LOCK_DESTROY(_rt) mtx_destroy(&(_rt)->rt_mtx) > > #define RT_LOCK_ASSERT(_rt) mtx_assert(&(_rt)->rt_mtx, > > MA_OWNED) > > --- route.c.orig Tue Oct 30 19:07:54 2007 > > +++ route.c Mon Dec 17 15:13:20 2007 > > @@ -996,6 +996,7 @@ > > struct radix_node_head *rnh = rt_tables[dst->sa_family]; > > int dlen = SA_SIZE(dst), glen = SA_SIZE(gate); > > > > +again: > > RT_LOCK_ASSERT(rt); > > > > /* > > @@ -1029,7 +1030,15 @@ > > RT_REMREF(rt); > > return (EADDRINUSE); /* failure */ > > } > > - RT_LOCK(rt); > > + /* > > + * Try to reacquire the lock on rt, and if it fails, > > + * clean state and restart from scratch. > > + */ > > + if (!RT_TRYLOCK(rt)) { > > + RTFREE_LOCKED(gwrt); > > + RT_LOCK(rt); > > + goto again; > > + } > > /* > > * If there is already a gwroute, then drop it. If we > > * are asked to replace route with itself, then do > > > > Thanks, > > Steve > > > Well I recompiled the kernel without the above changes and I am now kgdb > comes up. It looks like > the panic instruction pointer is in a loadable kernel module. Is there > some way to have kgdb look at the kernel > module? > Below is what i get now: > 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: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x4 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0b4536c > stack pointer = 0x28:0xc7516a30 > frame pointer = 0x28:0xc7516a48 > 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 = 13 (swi1: net) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 8h31m18s > Dumping 111 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 111MB (28400 pages) 95 79 63 47 31 15 > > #0 doadump () at pcpu.h:165 > 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc06492b2 in boot (howto=260) at ../../../kern/kern_shutdown.c:409 > #2 0xc06495d9 in panic (fmt=0xc0910386 "%s") at > ../../../kern/kern_shutdown.c:565 > #3 0xc082d99c in trap_fatal (frame=0xc75169f0, eva=4) at > ../../../i386/i386/trap.c:837 > #4 0xc082d6db in trap_pfault (frame=0xc75169f0, usermode=0, eva=4) > at ../../../i386/i386/trap.c:745 > #5 0xc082d335 in trap (frame= > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -950965440, tf_esi = > -1026657792, tf_ebp = -950965688, tf_isp = -950965732, tf_ebx = > -1045086208, tf_edx = -1047438316, tf_ecx = 0, tf_eax = 0, tf_trapno = > 12, tf_err = 0, tf_eip = -1061923988, tf_cs = 32, tf_eflags = 590406, > tf_esp = -929974260, tf_ss = 0}) at ../../../i386/i386/trap.c:435 > #6 0xc08198fa in calltrap () at ../../../i386/i386/exception.s:139 > #7 0xc0b4536c in ?? () > Cannot access memory at address 0xc891b80c > (kgdb) list *0xc0b4536c > No source file for address 0xc0b4536c. > (kgdb) > > looking at the loadable kernel modules on the system I get: > sudo kldstat > Id Refs Address Size Name > 1 13 0xc0400000 72862c kernel > 2 1 0xc0b29000 2340 accf_http.ko > 3 1 0xc0b2c000 3b180 ipf.ko > 4 1 0xc0b68000 5c2f8 acpi.ko > 5 1 0xc1dcc000 3000 ng_iface.ko > 6 1 0xc1dcf000 6000 ng_ppp.ko > 7 1 0xc1dd6000 4000 ng_bpf.ko > 8 1 0xc1ddd000 4000 ng_vjc.ko > > Which makes think the panic instruction pointer is in ipf.ko? > This is ipf 4.1.26 compiled out of the kernel tree. > > Steve You can use asf(8) with the -c option to build a .asf file you can source into kgdb to load symbols for the kernel modules to give you a decent backtrace. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 23:17:43 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53B0616A421; Mon, 4 Feb 2008 23:17:43 +0000 (UTC) (envelope-from jarrod@netleader.com.au) Received: from wallace.netleader.com.au (wallace.netleader.com.au [203.122.246.247]) by mx1.freebsd.org (Postfix) with ESMTP id B392D13C457; Mon, 4 Feb 2008 23:17:42 +0000 (UTC) (envelope-from jarrod@netleader.com.au) Received: from gromit.local (gromit.local [192.168.0.3]) by wallace.netleader.com.au (8.14.2/8.14.2) with ESMTP id m14NHaUw064957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Feb 2008 09:47:39 +1030 (CST) (envelope-from jarrod@netleader.com.au) Message-Id: From: Jarrod Sayers To: "Marc G. Fournier" In-Reply-To: <738861275EBE2BF6D27F547B@ganymede.hub.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 5 Feb 2008 09:47:36 +1030 References: <59DD6CCE263ECD75A7283A7B@ganymede.hub.org> <477A72B8.8010307@protected-networks.net> <477BAD2B.8070603@tomjudge.com> <1DB78354-EBA2-43D0-A2D6-EFDA4950135B@netleader.com.au> <477C1629.1030604@tomjudge.com> <20080103104129.T36551@wallace.netleader.com.au> <738861275EBE2BF6D27F547B@ganymede.hub.org> X-Mailer: Apple Mail (2.915) Cc: Tom Judge , freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Nagios + 6.3-RELEASE == Hung Process 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, 04 Feb 2008 23:17:43 -0000 On 03/01/2008, at 11:56 AM, Marc G. Fournier wrote: > As noted in my original report, this isn't a nagios issue per se ... > my first > experience with this issue was with Azureus/java ... so its a > 'threading issue > in general' ... A patch to force the package to link against libthr() has been committed [1] and should be available once mirrors update as net-mgmt/ nagios 2.10_1. This has been tested since this conversation stated in the net-mgmt/nagios-devel port [2] without any negative feedback being received. Bundled in the update is the inclusion of libltdl as requested by Tom Judge. I'd be interested to know how people go with the updated port. Thanks for your patience. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=120150 [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=119246 Jarrod. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 23:27:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A1AC16A41B for ; Mon, 4 Feb 2008 23:27:50 +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 4BFBB13C455 for ; Mon, 4 Feb 2008 23:27:49 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m14NRnQR049482; Mon, 4 Feb 2008 18:27:49 -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.8/8.13.3) with ESMTP id m14NRmmt017027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2008 18:27:49 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200802042327.m14NRmmt017027@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 Feb 2008 18:30:00 -0500 To: Jarrod Sayers From: Mike Tancsa In-Reply-To: References: <59DD6CCE263ECD75A7283A7B@ganymede.hub.org> <477A72B8.8010307@protected-networks.net> <477BAD2B.8070603@tomjudge.com> <1DB78354-EBA2-43D0-A2D6-EFDA4950135B@netleader.com.au> <477C1629.1030604@tomjudge.com> <20080103104129.T36551@wallace.netleader.com.au> <738861275EBE2BF6D27F547B@ganymede.hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Tom Judge , freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Nagios + 6.3-RELEASE == Hung Process 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, 04 Feb 2008 23:27:50 -0000 At 06:17 PM 2/4/2008, Jarrod Sayers wrote: >On 03/01/2008, at 11:56 AM, Marc G. Fournier wrote: >>As noted in my original report, this isn't a nagios issue per se ... >>my first >>experience with this issue was with Azureus/java ... so its a >>'threading issue >>in general' ... > >A patch to force the package to link against libthr() has been >committed [1] and should be available once mirrors update as >net-mgmt/ nagios 2.10_1. This has been tested since this >conversation stated in >the net-mgmt/nagios-devel port [2] without any negative feedback being We have been using nagios linked against libthr via libmap.conf since the end of November and its been working great since then. Prior to that, we would see 100% CPU usage a couple of times a week on various nagios procs. Hasnt happened since. ---Mike From owner-freebsd-stable@FreeBSD.ORG Mon Feb 4 23:29:56 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDF4516A41A for ; Mon, 4 Feb 2008 23:29:56 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 6DEB813C465 for ; Mon, 4 Feb 2008 23:29:56 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so123913uge.37 for ; Mon, 04 Feb 2008 15:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=TlbSz0IV+xoWBp2ouDq2ya7ZpBhyRcFsiYXLIWt9Pr4=; b=ax6m95g/KQ5Rk8y1Pf8HtfJfINFg6sKNmlxthPB5yr8JgA+3O/xLTZYi7u/n9gm9iuBtly6IvxCKTsKAc2nuixL6yrUeaew+Sl/m1sMNrJrgO39fquMa0DNs1TwjMwjoi5OKD78yQPzSeUywKWZyckMv4IGwtj0SZbNOU0Ia59Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kVBmX6yObpMXSdFlmYPsk/qHlm5FfFrRU4Qv0D0I7GEin5Sn7OfigxeZcdjN+t89uNaOzQ7oJf4Is/UlKmqQ+BddaTpu95qoDpzZCC/iBW+hXHXiVwnWY40qBHD8v+/JGoJQapp0rla814Phmb/ePnFtUNQyzTxY8at5QGXxqEI= Received: by 10.66.224.19 with SMTP id w19mr570123ugg.34.1202167794806; Mon, 04 Feb 2008 15:29:54 -0800 (PST) Received: by 10.66.219.18 with HTTP; Mon, 4 Feb 2008 15:29:54 -0800 (PST) Message-ID: <3aaaa3a0802041529u3b2659a6q6e9f7dc67468300d@mail.gmail.com> Date: Mon, 4 Feb 2008 23:29:54 +0000 From: Chris To: lev@freebsd.org In-Reply-To: <1188949738.20080204204903@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aaaa3a0802030751w69ce59a9oeb869e3d87d92616@mail.gmail.com> <1188949738.20080204204903@serebryakov.spb.ru> Cc: freebsd-stable@freebsd.org, Ivan Voras Subject: Re: Re[2]: gjournal panic 7.0-RC1 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, 04 Feb 2008 23:29:57 -0000 > Ok, subsystem can not work efficiently. Degrade service. Swith to > "one 512 byte sector per second" speed mode. Disable all caches, doesn't > try to work with all features. Complain 10 times/second on console (and > dmesg buffer). Ok. But PANIC?! NO-NO-NO!!! > Yes given the fact I had a panic and the work involved in configuring it properly I decided to newfs the drives again to ufs + soft updates something that is faster and just works, googling shows there seems to be very few people using gjournal so is still a bit immature for stable status in my view. Chris From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 03:06:58 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60D7B16A41B for ; Tue, 5 Feb 2008 03:06:58 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 2723F13C45B for ; Tue, 5 Feb 2008 03:06:58 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from localhost (localhost [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 3DAD0341E7; Tue, 5 Feb 2008 03:06:56 +0000 (GMT) Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXkr3Sr-tHe1; Tue, 5 Feb 2008 03:06:55 +0000 (GMT) Received: from [192.168.255.6] (unknown [192.168.255.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id EFD89340E8; Tue, 5 Feb 2008 03:06:54 +0000 (GMT) Message-ID: <47A7D2CD.7020505@tomjudge.com> Date: Tue, 05 Feb 2008 03:06:53 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Primeroz lists References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> In-Reply-To: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 05 Feb 2008 03:06:58 -0000 Primeroz lists wrote: > Hi all, > > we are experiencing repeated crash on a Dell PowerEdge 2950 (rev 1 or 2). > > FBSD release is 6.2-RELEASE-p5 , AMD64. 2xXeon QuadCore and 8G of Ram. > > > >> $ sudo kgdb /usr/obj/usr/src/sys/PE2950/kernel.debug vmcore.2 This back trace will be useless, I rebuilt the kernels on the build servers the week before last, not all systems got the updates. You will need to 'make installkernel' and crash the box again to get a usable vmcore... Pointy hat to me sorry, should have told you this before. Tom From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 03:32:00 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31A0A16A468 for ; Tue, 5 Feb 2008 03:32:00 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id DF30213C442 for ; Tue, 5 Feb 2008 03:31:59 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1JMEXM-0002xe-DI for freebsd-stable@freebsd.org; Tue, 05 Feb 2008 11:31:57 +0800 Message-ID: <47A7D8AC.7030104@micom.mng.net> Date: Tue, 05 Feb 2008 11:31:56 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.9 (X11/20071225) MIME-Version: 1.0 To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: fusefs-ntfs makes fatal trap/page fault in FreeBSD-7.0 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, 05 Feb 2008 03:32:00 -0000 Hi, I'm having trouble mounting external NTFS hard drive using fusefs-ntfs port on Dell Latitude D620. devil# uname -an FreeBSD devil.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #3: Tue Feb 5 10:29:24 ULAT 2008 tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 devil# pkg_info | grep fuse fusefs-kmod-0.3.9.p1_3 Kernel module for fuse fusefs-libs-2.7.2 FUSE allows filesystem implementation in userspace fusefs-ntfs-1.1120 Mount NTFS partitions (read/write) and disk images devil# kldload /usr/local/modules/fuse.ko devil# kldstat Id Refs Address Size Name 1 23 0xc0400000 6df8b4 kernel 2 1 0xc0ae0000 14324 snd_hda.ko 3 2 0xc0af5000 52a08 sound.ko 4 2 0xc0b48000 10ebc drm.ko 5 1 0xc0b59000 7184 i915.ko 6 1 0xc0b61000 6b314 acpi.ko 7 2 0xc4005000 c000 ipfw.ko 8 1 0xc4035000 4000 ipdivert.ko 9 1 0xc406d000 22000 linux.ko 11 3 0xc43dd000 3000 ucom.ko 12 1 0xc43e0000 3000 uftdi.ko 13 1 0xc43e5000 4000 uplcom.ko 14 1 0xc59aa000 e000 fuse.ko When I try to mount it, on serial console I see: ... umass0: on uhub4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-4 device da0: 40.000MB/s transfers da0: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 1 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): ABORTED COMMAND asc:0,0 (da0:umass-sim0:0:0:0): No additional sense information (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 1 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): ABORTED COMMAND asc:0,0 (da0:umass-sim0:0:0:0): No additional sense information (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) GEOM_LABEL: Label for provider da0s1 is ntfs/FreeAgent Drive. GEOM_LABEL: Label ntfs/FreeAgent Drive removed. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x746e756f fault code = supervisor read, page not present instruction pointer = 0x20:0xc06d8f36 stack pointer = 0x28:0xe63d09b0 frame pointer = 0x28:0xe63d09b4 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 = 19197 (mount_fusefs) [thread pid 19197 tid 100099 ] Stopped at strcmp+0x26: movzbl 0(%ecx),%eax db> bt Tracing pid 19197 tid 100099 td 0xc4312210 strcmp(c59b644f,746e756f,c3e43934,2d,e63d0a8c,...) at strcmp+0x26 vfs_getopt(c09bb6c0,c59b644f,0,0,c4312210,...) at vfs_getopt+0x35 fuse_mount(c3e438b8,c4312210,c08d0185,3e9,0,...) at fuse_mount+0x70 vfs_donmount(48217080,c,e63d0c70,c48e4000,bfbfebb4,...) at vfs_donmount+0x13ad nmount(c4312210,e63d0cfc,c,e63d0d38,c095e6d0,...) at nmount+0xb2 syscall(e63d0d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x480ccb4b, esp = 0xbfbfe64c, ebp = 0xbfbfebc8 --- db> trace Tracing pid 19197 tid 100099 td 0xc4312210 strcmp(c59b644f,746e756f,c3e43934,2d,e63d0a8c,...) at strcmp+0x26 vfs_getopt(c09bb6c0,c59b644f,0,0,c4312210,...) at vfs_getopt+0x35 fuse_mount(c3e438b8,c4312210,c08d0185,3e9,0,...) at fuse_mount+0x70 vfs_donmount(48217080,c,e63d0c70,c48e4000,bfbfebb4,...) at vfs_donmount+0x13ad nmount(c4312210,e63d0cfc,c,e63d0d38,c095e6d0,...) at nmount+0xb2 syscall(e63d0d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x480ccb4b, esp = 0xbfbfe64c, ebp = 0xbfbfebc8 --- db> Any idea how to solve this problem? thanks, Ganbold -- Real computer scientists don't program in assembler. They don't write in anything less portable than a number two pencil. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 04:08:23 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7440316A418 for ; Tue, 5 Feb 2008 04:08:23 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 2B61913C43E for ; Tue, 5 Feb 2008 04:08:22 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1JMF6a-0003Ft-50; Tue, 05 Feb 2008 12:08:20 +0800 Message-ID: <47A7E133.8030802@micom.mng.net> Date: Tue, 05 Feb 2008 12:08:19 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.9 (X11/20071225) MIME-Version: 1.0 To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sam@FreeBSD.org Subject: panic: resource_list_release: resource entry is not busy in FreeBSD-7.0 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, 05 Feb 2008 04:08:23 -0000 Hi, I'm having trouble using Orinoco Silver a/b/g combo pcmcia card on Dell Latitude D620. It happens in following order: 1. First I reboot FreeBSD-7.0 laptop with Orinoco combo card plugged in. 2. Then when I try to unplug the card it panics. However after rebooting (without plugged in card) when I try to plug in and unplug the card everything is fine, no crash. System I have: devil# uname -an FreeBSD devil.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #3: Tue Feb 5 10:29:24 ULAT 2008 tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 When panics, on the serial console it shows: ... ath0: mem 0x88000000-0x8800ffff irq 18 at device 0.0 on cardbus0 ath0: [ITHREAD] ath0: using obsoleted if_watchdog interface ath0: Ethernet address: 00:20:a6:4f:bf:7d ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 ... Tue Feb 5 11:52:45 ULAT 2008 ... panic: resource_list_release: resource entry is not busy cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c08c8051,e40bebb8,c064f78f,c08ec063,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ec063,0,c08c7b57,e40bebc4,0,...) at kdb_backtrace+0x29 panic(c08c7b57,3,10,0,c3c6ce40,...) at panic+0x10f resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at resource_list_release+0xc2 bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at bus_generic_rl_release_resource+0x77 bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at bus_release_resource+0x67 ath_pci_detach(c3c92e00,c3b41050,c095ba2c,970,4,...) at ath_pci_detach+0xb2 device_detach(c3c92e00,e40becac,e40becb0,c09aacf0,0,...) at device_detach+0x8c cardbus_detach_card(c3c46100,c3b9c8b4,c091b07c,1df,c09ad260,...) at cardbus_detach_card+0xcd cbb_event_thread(c3bb1000,e40bed38,c08c1ad7,305,c3c40ab0,...) at cbb_event_thread+0x15a fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- KDB: enter: panic [thread pid 36 tid 100035 ] Stopped at kdb_enter+0x32: leave db> bt Tracing pid 36 tid 100035 td 0xc3c2a210 kdb_enter(c08c5554,0,c08c7b57,e40bebc4,0,...) at kdb_enter+0x32 panic(c08c7b57,3,10,0,c3c6ce40,...) at panic+0x124 resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at resource_list_release+0xc2 bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at bus_generic_rl_release_resource+0x77 bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at bus_release_resource+0x67 ath_pci_detach(c3c92e00,c3b41050,c095ba2c,970,4,...) at ath_pci_detach+0xb2 device_detach(c3c92e00,e40becac,e40becb0,c09aacf0,0,...) at device_detach+0x8c cardbus_detach_card(c3c46100,c3b9c8b4,c091b07c,1df,c09ad260,...) at cardbus_detach_card+0xcd cbb_event_thread(c3bb1000,e40bed38,c08c1ad7,305,c3c40ab0,...) at cbb_event_thread+0x15a fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- db> tr Tracing pid 36 tid 100035 td 0xc3c2a210 kdb_enter(c08c5554,0,c08c7b57,e40bebc4,0,...) at kdb_enter+0x32 panic(c08c7b57,3,10,0,c3c6ce40,...) at panic+0x124 resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at resource_list_release+0xc2 bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at bus_generic_rl_release_resource+0x77 bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at bus_release_resource+0x67 ath_pci_detach(c3c92e00,c3b41050,c095ba2c,970,4,...) at ath_pci_detach+0xb2 device_detach(c3c92e00,e40becac,e40becb0,c09aacf0,0,...) at device_detach+0x8c cardbus_detach_card(c3c46100,c3b9c8b4,c091b07c,1df,c09ad260,...) at cardbus_detach_card+0xcd cbb_event_thread(c3bb1000,e40bed38,c08c1ad7,305,c3c40ab0,...) at cbb_event_thread+0x15a fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- db> Any idea how to solve this problem? thanks, Ganbold -- We have only two things to worry about: That things will never get back to normal, and that they already have. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 04:30:56 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1E5916A420 for ; Tue, 5 Feb 2008 04:30:56 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from mindcrime.bit0.com (bit0.com [207.246.88.211]) by mx1.freebsd.org (Postfix) with ESMTP id 79F0013C442 for ; Tue, 5 Feb 2008 04:30:56 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from localhost (localhost [127.0.0.1]) by mindcrime.bit0.com (Postfix) with ESMTP id 37B311E33AE for ; Mon, 4 Feb 2008 23:30:55 -0500 (EST) X-Virus-Scanned: amavisd-new at bit0.com Received: from mindcrime.bit0.com ([127.0.0.1]) by localhost (mindcrime.int.bit0.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihfVP6fyG5fd for ; Mon, 4 Feb 2008 23:30:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mindcrime.bit0.com (Postfix) with ESMTP for ; Mon, 4 Feb 2008 23:30:52 -0500 (EST) Date: Mon, 4 Feb 2008 23:30:52 -0500 (EST) From: Mike Andrews X-X-Sender: mandrews@mindcrime.int.bit0.com To: freebsd-stable@freebsd.org Message-ID: <20080204230945.J49853@mindcrime.int.bit0.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: mount -p and NFS 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: Tue, 05 Feb 2008 04:30:56 -0000 Is there anything like "mount -p" that will print the current NFS options in use? TCP vs UDP, v2 vs v3, read/write sizes etc. It doesn't have to be in fstab format; I just need to be able to see what the flags are for an active mount. This would be useful in tracking down an irritating NFS problem I've been experiencing with diskless systems in every 6.x release and 7.0-RC1, namely libc.so.6 appears to be truncated or corrupt to the client at somewhat random times... I think it may be related to mount options, hence the question. Mike Andrews * mandrews@bit0.com * http://www.bit0.com It's not news, it's Fark.com. Carpe cavy! From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 06:57:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 167FE16A418 for ; Tue, 5 Feb 2008 06:57:05 +0000 (UTC) (envelope-from zbeeble@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 C53A313C4E8 for ; Tue, 5 Feb 2008 06:57:04 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so3642963pyb.10 for ; Mon, 04 Feb 2008 22:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=ojuZvuxHorHH5RZr+eQTrxbPWgY5ewo/I9PqBlFNWHA=; b=VXSt6AzrMnuB0WcS6ekhiJyGmC8zj6/0wOCbEISbnA4UdlnPHbyLywjEnOo54JwlI0zyn6ptTFoxgbMPXel7f869dSUDi4Yz0pxr4lvoTCKbIlixlcttO+hN6+ZzfLloHgos/p8aVkuNU0dIYM+/GdiPS3IrQsvGkdaSgDxACN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lWjOk7qsXUxov1Ns9grhaVaUUVC8JD25JrnnxTkvk+d09AiZACWHn0gYbw4qo2qEigfigDVLbPbxy4gg6W0WnpxUJFmgAO/4aaJTb6MUefiHpnP+h1J918CJNkMsZ7IkW4urfCTYvRJLKwRE5Wny8I6GDiXHJCBU6N/MqnJCfIE= Received: by 10.64.196.9 with SMTP id t9mr14763286qbf.78.1202192967747; Mon, 04 Feb 2008 22:29:27 -0800 (PST) Received: by 10.64.148.4 with HTTP; Mon, 4 Feb 2008 22:29:27 -0800 (PST) Message-ID: <5f67a8c40802042229y5f407e3bo55f32e95c7997848@mail.gmail.com> Date: Tue, 5 Feb 2008 01:29:27 -0500 From: "Zaphod Beeblebrox" To: Ganbold In-Reply-To: <47A7D8AC.7030104@micom.mng.net> MIME-Version: 1.0 References: <47A7D8AC.7030104@micom.mng.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Stable Mailing List Subject: Re: fusefs-ntfs makes fatal trap/page fault in FreeBSD-7.0 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, 05 Feb 2008 06:57:05 -0000 On Feb 4, 2008 10:31 PM, Ganbold wrote: > I'm having trouble mounting external NTFS hard drive using fusefs-ntfs > port on Dell Latitude D620. > I havn't seen this specific problem, but on my Dell XPS 1730 (core-2-duo-extreme) The NTFS-3g mounts doen't seem to shutdown properly. That is: many of the writes are uncommitted and the filesystem needs a check and often information is lost ... unless I unmount the filesystems before shutdown. UFS and ZFS partitions seem to shutdown just fine. I've never had a problem with FAT-32 partitions, either, but the ntfs-3g is problematic somehow. According to the rc.d scrpt for fuse, it should be unmounting all the partitions before shutdown --- and I think that script even runs (when I shutdown from a non-X environment, I see it's output). But several times, shutting down from X (so I don't see the output of shutdown scripts), I've ended up with corrupt ntfs partitions. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 07:16:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19B8E16A46C for ; Tue, 5 Feb 2008 07:16:02 +0000 (UTC) (envelope-from marko.kobal@arctur.si) Received: from cygnus.arctur.si (cygnus.arctur.si [193.77.181.76]) by mx1.freebsd.org (Postfix) with ESMTP id D0CDD13C4CC for ; Tue, 5 Feb 2008 07:16:01 +0000 (UTC) (envelope-from marko.kobal@arctur.si) Received: from localhost (localhost [127.0.0.1]) by cygnus.arctur.si (Postfix) with ESMTP id ACC56CB683C for ; Tue, 5 Feb 2008 07:51:46 +0100 (CET) Received: from cygnus.arctur.si ([127.0.0.1]) by localhost (cygnus.arctur.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45706-03 for ; Tue, 5 Feb 2008 07:51:46 +0100 (CET) Received: from [192.168.1.10] (neonka.arctur.si [193.77.124.79]) by cygnus.arctur.si (Postfix) with ESMTP id 3C5E4CB6838 for ; Tue, 5 Feb 2008 07:51:46 +0100 (CET) Message-ID: <47A80784.9080103@arctur.si> Date: Tue, 05 Feb 2008 07:51:48 +0100 From: Marko Kobal User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at arctur.si Subject: freeBSD 6.3 and LSI Logic 1030 = only 3.3MB/s 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, 05 Feb 2008 07:16:02 -0000 Hi, I've upgraded one of my boxes from 6.2 to freeBSD 6.3. I have on-board LSI Logic 1030 SCSI Ultra4 Adapter, on it I have attached two IBM Ultra-320 SCSI 36GB disks. The machine is IBM xServer 225. See the dmesg output: .. mpt0: port 0xb000-0xb0ff mem 0xf5010000-0xf501ffff,0xf5000000-0xf500ffff irq 32 at device 3.0 on pci4 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.14.0 mpt0: Capabilities: ( RAID-1 SAFTE ) mpt0: 1 Active Volume (1 Max) mpt0: 2 Hidden Drive Members (6 Max) .. da1 at mpt0 bus 0 target 4 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 3.300MB/s transfers, Tagged Queueing Enabled da1: 34702MB (71071560 512 byte sectors: 255H 63S/T 4424C) .. It is showing that logical device da1 has only 3.3MB/s transfer rate!? Before the upgrade it was showing the correct 320MB/s. After a few quick disk test I can confirm that it is running sloooow: # dd if=/dev/da1 of=/dev/null bs=16384 count=1000 1000+0 records in 1000+0 records out 16384000 bytes transferred in 4.393638 secs (3729028 bytes/sec) # dd if=/dev/da1 of=/dev/null bs=16384 count=1000 1000+0 records in 1000+0 records out 16384000 bytes transferred in 6.619820 secs (2474992 bytes/sec) Is there something wrong with the mpt driver in 6.3? And also, is there any utility to access LSI Logic 1030 BIOS under freeBSD? Thanks for help! -- Kind regards, Marko Kobal. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 08:43:19 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CD2E16A46C for ; Tue, 5 Feb 2008 08:43:19 +0000 (UTC) (envelope-from elizabeth.zamora@sosoutreach.org) Received: from koln-4db42aa6.pool.einsundeins.de (koln-4db42aa6.pool.einsundeins.de [77.180.42.166]) by mx1.freebsd.org (Postfix) with SMTP id 7562F13C468 for ; Tue, 5 Feb 2008 08:43:18 +0000 (UTC) (envelope-from elizabeth.zamora@sosoutreach.org) Received: from [106.182.168.171] (helo=qpi) by koln-4db42aa6.pool.einsundeins.de with smtp (Exim 4.62 (FreeBSD)) id 1JMJOP-0006hN-Rn; Tue, 5 Feb 2008 09:42:32 +0100 Message-ID: <002601c867d2$c8c42530$aba8b66a@qpi> From: To: Date: Tue, 5 Feb 2008 09:40:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Why I Love You 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, 05 Feb 2008 08:43:19 -0000 A Token of My Love http://194.117.238.111/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 09:46:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0884916A41A for ; Tue, 5 Feb 2008 09:46:13 +0000 (UTC) (envelope-from marko.kobal@arctur.si) Received: from cygnus.arctur.si (cygnus.arctur.si [193.77.181.76]) by mx1.freebsd.org (Postfix) with ESMTP id C085713C447 for ; Tue, 5 Feb 2008 09:46:12 +0000 (UTC) (envelope-from marko.kobal@arctur.si) Received: from localhost (localhost [127.0.0.1]) by cygnus.arctur.si (Postfix) with ESMTP id B5B64CB683C for ; Tue, 5 Feb 2008 10:46:11 +0100 (CET) Received: from cygnus.arctur.si ([127.0.0.1]) by localhost (cygnus.arctur.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67234-02 for ; Tue, 5 Feb 2008 10:46:11 +0100 (CET) Received: from [192.168.1.10] (neonka.arctur.si [193.77.124.79]) by cygnus.arctur.si (Postfix) with ESMTP id 5A224CB6838 for ; Tue, 5 Feb 2008 10:46:11 +0100 (CET) Message-ID: <47A83065.9040906@arctur.si> Date: Tue, 05 Feb 2008 10:46:13 +0100 From: Marko Kobal User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at arctur.si Subject: downgrade freebsd 6.3 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: Tue, 05 Feb 2008 09:46:13 -0000 Hi, I'm having some issues after upgrading from 6.2 to 6.3 (with the mpt driver). I have upgraded both world and kernel and have already done installkernel and installworld and rebooted several times. Now I wish to downgrade to 6.2; I did "*default tag=RELENG_6_2" in CVSUP file and "make update", but then when I try to run: /usr/src# make buildkernel I get: -------------------------------------------------------------- >>> stage 3.1: making dependencies -------------------------------------------------------------- cd /usr/obj/usr/src/sys/CORVUS; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=pentium4 GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/obj/usr/src/make.i386/make KERNEL=kernel depend -DNO_MODULES_OBJ make: don't know how to make /usr/src/sys/sys/_sx.h. Stop *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Does this mean I can not downgrade back to 6.2!? Kind regards, Marko. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 09:49:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91F5116A478 for ; Tue, 5 Feb 2008 09:49: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 D172013C448 for ; Tue, 5 Feb 2008 09:49:30 +0000 (UTC) (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 m159nOAX062539; Tue, 5 Feb 2008 16:49:24 +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 m159nOC4062538; Tue, 5 Feb 2008 16:49:24 +0700 (KRAT) (envelope-from eugen) Date: Tue, 5 Feb 2008 16:49:24 +0700 From: Eugene Grosbein To: Marko Kobal Message-ID: <20080205094924.GA62440@svzserv.kemerovo.su> References: <47A83065.9040906@arctur.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A83065.9040906@arctur.si> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: downgrade freebsd 6.3 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: Tue, 05 Feb 2008 09:49:31 -0000 On Tue, Feb 05, 2008 at 10:46:13AM +0100, Marko Kobal wrote: > Does this mean I can not downgrade back to 6.2!? First try to "rm -rf /usr/obj". From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 12:57:08 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D4A716A417 for ; Tue, 5 Feb 2008 12:57:08 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by mx1.freebsd.org (Postfix) with SMTP id 2870213C478 for ; Tue, 5 Feb 2008 12:57:08 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 1306 invoked from network); 5 Feb 2008 12:57:07 -0000 Received: from unknown (24.144.77.185) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 05 Feb 2008 12:57:07 -0000 Message-ID: <47A85CB4.20202@seclark.us> Date: Tue, 05 Feb 2008 07:55:16 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: kgdb kernel crash with module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2008 12:57:08 -0000 Hello List, Is there some way to debug a crash dump with kgdb when the crash is in a module? Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 13:49:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 515F616A419 for ; Tue, 5 Feb 2008 13:49:06 +0000 (UTC) (envelope-from matt@gsicomp.on.ca) Received: from daisy2.compar.com (mail1.compar.com [216.208.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8198713C45D for ; Tue, 5 Feb 2008 13:49:04 +0000 (UTC) (envelope-from matt@gsicomp.on.ca) Received: from localhost (localhost.compar.com [127.0.0.1]) by daisy2.compar.com (Postfix) with ESMTP id E998813C47F for ; Tue, 5 Feb 2008 08:30:33 -0500 (EST) X-Virus-Scanned: amavisd-new at compar.com Received: from unknown by localhost (amavisd-new, unix socket) id yW-v7--72S0c for ; Tue, 5 Feb 2008 08:30:26 -0500 (EST) Received: from hermes (CPE00062566c7bb-CM001ac3584898.cpe.net.cable.rogers.com [99.236.43.116]) by daisy2.compar.com (Postfix) with SMTP id E504513C47B for ; Tue, 5 Feb 2008 08:30:25 -0500 (EST) Message-ID: <004901c867fb$44b08350$1200a8c0@hermes> From: "Matt Emmerton" To: Date: Tue, 5 Feb 2008 08:30:26 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0046_01C867D1.5B90A110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: ATA/boot problems with 6.2-release and 7-prerelease 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, 05 Feb 2008 13:49:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C867D1.5B90A110 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit I have a 6.1-release machine that I wanted to upgrade, so I decided I would upgrade to 6.2-rel, and then to 7-pre. When I upgraded to 6.2-rel, it fails at mountroot, claiming that it can't find ad0s1a to boot from. (Entering ? to list all available boot devices only lists acd0 and ad2*, which are secondary master/slave. It doesn't list anything on ad0 or ad1 which are primary master/slave.) The same thing happens on 7-pre. All installations are using GENERIC kernel. Booting from CD and going into fixit mode works fine - I can see all filesystems on all disks. I've tried swapping primary/secondary as well as swapping cables, but the problem persists. I've attached the dmesg from 6.1. Both 6.2 and 7-pre have the following text in the dmesg numerous times for ata0. ata0: reiniting channel .. ata0: reset tp1 mask=0x ostat0=58 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=50 devices=0x3 I see this a couple of times for ata1 as well, but the stat1 line is different and we end up detecting ad2/acd0 which are on ata1. Any ideas? -- Matt Emmerton ------=_NextPart_000_0046_01C867D1.5B90A110 Content-Type: application/octet-stream; name="dmesg.61generic" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.61generic" Copyright (c) 1992-2006 The FreeBSD Project.=0A= Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994=0A= The Regents of the University of California. All rights reserved.=0A= FreeBSD 6.1-RELEASE #0: Sun May 7 04:32:43 UTC 2006=0A= root@opus.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC=0A= Preloaded elf kernel "/boot/kernel.61GENERIC/kernel" at 0xc0afe000.=0A= Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0afe18c.=0A= link_elf: symbol rman_is_region_manager undefined=0A= KLD file acpi.ko - could not finalize loading=0A= Calibrating clock(s) ... i8254 clock: 1193325 Hz=0A= CLK_USE_I8254_CALIBRATION not specified - using default frequency=0A= Timecounter "i8254" frequency 1193182 Hz quality 0=0A= Calibrating TSC clock ... TSC clock: 1699952540 Hz=0A= CPU: Intel(R) Celeron(R) CPU 1.70GHz (1699.95-MHz 686-class CPU)=0A= Origin =3D "GenuineIntel" Id =3D 0xf13 Stepping =3D 3=0A= = Features=3D0x3febfbff=0A= real memory =3D 234815488 (223 MB)=0A= Physical memory chunk(s):=0A= 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages)=0A= 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages)=0A= 0x0000000000c25000 - 0x000000000dbc7fff, 217722880 bytes (53155 pages)=0A= avail memory =3D 220291072 (210 MB)=0A= MP Configuration Table version 1.4 found at 0xc00f1400=0A= APIC: Using the MPTable enumerator.=0A= MPTable: =0A= bios32: Found BIOS32 Service Directory header at 0xc00fae80=0A= bios32: Entry =3D 0xfb2f0 (c00fb2f0) Rev =3D 0 Len =3D 1=0A= pcibios: PCI BIOS entry at 0xf0000+0xb340=0A= pnpbios: Found PnP BIOS data at 0xc00fbd70=0A= pnpbios: Entry =3D f0000:bda0 Rev =3D 1.0=0A= Other BIOS signatures found:=0A= ioapic0: Changing APIC ID to 2=0A= ioapic0: Assuming intbase of 0=0A= ioapic0: Routing external 8259A's -> intpin 0=0A= ioapic0: intpin 0 -> ExtINT (edge, high)=0A= ioapic0: intpin 1 -> ISA IRQ 1 (edge, high)=0A= ioapic0: intpin 2 -> ISA IRQ 2 (edge, high)=0A= ioapic0: intpin 3 -> ISA IRQ 3 (edge, high)=0A= ioapic0: intpin 4 -> ISA IRQ 4 (edge, high)=0A= ioapic0: intpin 5 -> ISA IRQ 5 (edge, high)=0A= ioapic0: intpin 6 -> ISA IRQ 6 (edge, high)=0A= ioapic0: intpin 7 -> ISA IRQ 7 (edge, high)=0A= ioapic0: intpin 8 -> ISA IRQ 8 (edge, high)=0A= ioapic0: intpin 9 -> ISA IRQ 9 (edge, high)=0A= ioapic0: intpin 10 -> ISA IRQ 10 (edge, high)=0A= ioapic0: intpin 11 -> ISA IRQ 11 (edge, high)=0A= ioapic0: intpin 12 -> ISA IRQ 12 (edge, high)=0A= ioapic0: intpin 13 -> ISA IRQ 13 (edge, high)=0A= ioapic0: intpin 14 -> ISA IRQ 14 (edge, high)=0A= ioapic0: intpin 15 -> ISA IRQ 15 (edge, high)=0A= ioapic0: intpin 16 -> PCI IRQ 16 (level, low)=0A= ioapic0: intpin 17 -> PCI IRQ 17 (level, low)=0A= ioapic0: intpin 18 -> PCI IRQ 18 (level, low)=0A= ioapic0: intpin 19 -> PCI IRQ 19 (level, low)=0A= ioapic0: intpin 20 -> PCI IRQ 20 (level, low)=0A= ioapic0: intpin 21 -> PCI IRQ 21 (level, low)=0A= ioapic0: intpin 22 -> PCI IRQ 22 (level, low)=0A= ioapic0: intpin 23 -> PCI IRQ 23 (level, low)=0A= ioapic0: intpin 20 bus PCI=0A= ioapic0: intpin 20 trigger: level=0A= ioapic0: intpin 20 polarity: low=0A= ioapic0: intpin 21 bus PCI=0A= ioapic0: intpin 21 trigger: level=0A= ioapic0: intpin 21 polarity: low=0A= ioapic0: intpin 22 bus PCI=0A= ioapic0: intpin 22 trigger: level=0A= ioapic0: intpin 22 polarity: low=0A= ioapic0: intpin 23 bus PCI=0A= ioapic0: intpin 23 trigger: level=0A= ioapic0: intpin 23 polarity: low=0A= ioapic0: intpin 18 bus PCI=0A= ioapic0: intpin 18 trigger: level=0A= ioapic0: intpin 18 polarity: low=0A= ioapic0: intpin 16 bus PCI=0A= ioapic0: intpin 16 trigger: level=0A= ioapic0: intpin 16 polarity: low=0A= ioapic0: intpin 19 bus PCI=0A= ioapic0: intpin 19 trigger: level=0A= ioapic0: intpin 19 polarity: low=0A= ioapic0: intpin 1 bus ISA=0A= ioapic0: intpin 1 trigger: edge=0A= ioapic0: intpin 1 polarity: high=0A= ioapic0: intpin 2 bus ISA=0A= ioapic0: Routing IRQ 0 -> intpin 2=0A= ioapic0: intpin 2 trigger: edge=0A= ioapic0: intpin 2 polarity: high=0A= ioapic0: intpin 3 bus ISA=0A= ioapic0: intpin 3 trigger: edge=0A= ioapic0: intpin 3 polarity: high=0A= ioapic0: intpin 4 bus ISA=0A= ioapic0: intpin 4 trigger: edge=0A= ioapic0: intpin 4 polarity: high=0A= ioapic0: intpin 6 bus ISA=0A= ioapic0: intpin 6 trigger: edge=0A= ioapic0: intpin 6 polarity: high=0A= ioapic0: intpin 7 bus ISA=0A= ioapic0: intpin 7 trigger: edge=0A= ioapic0: intpin 7 polarity: high=0A= ioapic0: intpin 8 bus ISA=0A= ioapic0: intpin 8 trigger: edge=0A= ioapic0: intpin 8 polarity: high=0A= ioapic0: intpin 12 bus ISA=0A= ioapic0: intpin 12 trigger: edge=0A= ioapic0: intpin 12 polarity: high=0A= ioapic0: intpin 13 bus ISA=0A= ioapic0: intpin 13 trigger: edge=0A= ioapic0: intpin 13 polarity: high=0A= ioapic0: intpin 14 bus ISA=0A= ioapic0: intpin 14 trigger: edge=0A= ioapic0: intpin 14 polarity: high=0A= ioapic0: intpin 15 bus ISA=0A= ioapic0: intpin 15 trigger: edge=0A= ioapic0: intpin 15 polarity: high=0A= ioapic0: Routing SMI -> intpin 23=0A= lapic: Routing ExtINT -> LINT0=0A= lapic: Routing NMI -> LINT1=0A= ioapic0 irqs 0-23 on motherboard=0A= cpu0 BSP:=0A= ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff=0A= lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff=0A= timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000=0A= wlan: <802.11 Link Layer>=0A= null: =0A= random: =0A= nfslock: pseudo-device=0A= io: =0A= kbd: new array size 4=0A= kbd1 at kbdmux0=0A= mem: =0A= Pentium Pro MTRR support enabled=0A= rr232x: RocketRAID 232x controller driver v1.02 (May 7 2006 04:32:33)=0A= npx0: INT 16 interface=0A= cpu0 on motherboard=0A= pci_open(1): mode 1 addr port (0x0cf8) is 0x80000070=0A= pci_open(1a): mode1res=3D0x80000000 (0x80000000)=0A= pci_cfgcheck: device 0 [class=3D060000] [hdr=3D80] is there = (id=3D06511039)=0A= pcibios: BIOS version 2.10=0A= Found $PIR table, 6 entries at 0xc00fde70=0A= PCI-Only Interrupts: 5 9 10 11=0A= Location Bus Device Pin Link IRQs=0A= slot 1 0 11 A 0x03 3 4 5 6 7 9 10 11 14 15=0A= slot 1 0 11 B 0x04 3 4 5 6 7 9 10 11 14 15=0A= slot 1 0 11 C 0x01 3 4 5 6 7 9 10 11 14 15=0A= slot 1 0 11 D 0x02 3 4 5 6 7 9 10 11 14 15=0A= slot 2 0 9 A 0x02 3 4 5 6 7 9 10 11 14 15=0A= slot 2 0 9 B 0x03 3 4 5 6 7 9 10 11 14 15=0A= slot 2 0 9 C 0x04 3 4 5 6 7 9 10 11 14 15=0A= slot 2 0 9 D 0x01 3 4 5 6 7 9 10 11 14 15=0A= slot 3 0 13 A 0x04 3 4 5 6 7 9 10 11 14 15=0A= slot 3 0 13 B 0x01 3 4 5 6 7 9 10 11 14 15=0A= slot 3 0 13 C 0x02 3 4 5 6 7 9 10 11 14 15=0A= slot 3 0 13 D 0x03 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 1 A 0x01 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 1 B 0x02 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 1 C 0x03 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 1 D 0x04 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 2 A 0x01 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 2 B 0x02 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 2 C 0x03 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 2 D 0x04 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 3 A 0x05 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 3 B 0x06 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 3 C 0x07 3 4 5 6 7 9 10 11 14 15=0A= embedded 0 3 D 0x08 3 4 5 6 7 9 10 11 14 15=0A= pcib0: pcibus 0 on motherboard=0A= pci0: on pcib0=0A= pci0: physical bus=3D0=0A= found-> vendor=3D0x1039, dev=3D0x0651, revid=3D0x01=0A= bus=3D0, slot=3D0, func=3D0=0A= class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1=0A= cmdreg=3D0x0007, statreg=3D0x2210, cachelnsz=3D0 (dwords)=0A= lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)=0A= map[10]: type 1, range 32, base e8000000, size 26, enabled=0A= found-> vendor=3D0x1039, dev=3D0x0001, revid=3D0x00=0A= bus=3D0, slot=3D1, func=3D0=0A= class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0=0A= cmdreg=3D0x0107, statreg=3D0x0000, cachelnsz=3D0 (dwords)=0A= lattimer=3D0x40 (1920 ns), mingnt=3D0x0e (3500 ns), maxlat=3D0x00 (0 ns)=0A= found-> vendor=3D0x1039, dev=3D0x0008, revid=3D0x04=0A= bus=3D0, slot=3D2, func=3D0=0A= class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1=0A= cmdreg=3D0x000f, statreg=3D0x0200, cachelnsz=3D0 (dwords)=0A= lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)=0A= found-> vendor=3D0x1039, dev=3D0x5513, revid=3D0x00=0A= bus=3D0, slot=3D2, func=3D5=0A= class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0=0A= cmdreg=3D0x0005, statreg=3D0x0210, cachelnsz=3D0 (dwords)=0A= lattimer=3D0x80 (3840 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)=0A= intpin=3Da, irq=3D14=0A= powerspec 2 supports D0 D1 D3 current D0=0A= map[20]: type 4, range 32, base 00004000, size 4, enabled=0A= pcib0: unable to route slot 2 INTA=0A= found-> vendor=3D0x1039, dev=3D0x7012, revid=3D0xa0=0A= bus=3D0, slot=3D2, func=3D7=0A= class=3D04-01-00, hdrtype=3D0x00, mfdev=3D0=0A= cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords)=0A= lattimer=3D0x20 (960 ns), mingnt=3D0x34 (13000 ns), maxlat=3D0x0b (2750 = ns)=0A= intpin=3Dc, irq=3D5=0A= powerspec 2 supports D0 D1 D2 D3 current D0=0A= map[10]: type 4, range 32, base 0000d800, size 8, enabled=0A= map[14]: type 4, range 32, base 0000dc00, size 7, enabled=0A= pcib0: slot 2 INTC routed to irq 18=0A= found-> vendor=3D0x1039, dev=3D0x7001, revid=3D0x0f=0A= bus=3D0, slot=3D3, func=3D0=0A= class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1=0A= cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D8 (dwords)=0A= lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x50 (20000 ns)=0A= intpin=3Da, irq=3D5=0A= map[10]: type 1, range 32, base ec124000, size 12, enabled=0A= pcib0: slot 3 INTA routed to irq 20=0A= found-> vendor=3D0x1039, dev=3D0x7001, revid=3D0x0f=0A= bus=3D0, slot=3D3, func=3D1=0A= class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0=0A= cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D8 (dwords)=0A= lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x50 (20000 ns)=0A= intpin=3Db, irq=3D10=0A= map[10]: type 1, range 32, base ec120000, size 12, enabled=0A= pcib0: slot 3 INTB routed to irq 21=0A= found-> vendor=3D0x1039, dev=3D0x7001, revid=3D0x0f=0A= bus=3D0, slot=3D3, func=3D2=0A= class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0=0A= cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D8 (dwords)=0A= lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x50 (20000 ns)=0A= intpin=3Dc, irq=3D11=0A= map[10]: type 1, range 32, base ec121000, size 12, enabled=0A= pcib0: slot 3 INTC routed to irq 22=0A= found-> vendor=3D0x1039, dev=3D0x7002, revid=3D0x00=0A= bus=3D0, slot=3D3, func=3D3=0A= class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0=0A= cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D8 (dwords)=0A= lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x50 (20000 ns)=0A= intpin=3Dd, irq=3D9=0A= powerspec 2 supports D0 D3 current D0=0A= map[10]: type 1, range 32, base ec122000, size 12, enabled=0A= pcib0: slot 3 INTD routed to irq 258=0A= found-> vendor=3D0x1039, dev=3D0x0900, revid=3D0x91=0A= bus=3D0, slot=3D4, func=3D0=0A= class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0=0A= cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords)=0A= lattimer=3D0x20 (960 ns), mingnt=3D0x34 (13000 ns), maxlat=3D0x0b (2750 = ns)=0A= intpin=3Da, irq=3D11=0A= powerspec 2 supports D0 D1 D2 D3 current D0=0A= map[10]: type 4, range 32, base 0000e000, size 8, enabled=0A= map[14]: type 1, range 32, base ec123000, size 12, enabled=0A= pcib0: slot 4 INTA routed to irq 19=0A= agp0: mem 0xe8000000-0xebffffff at device = 0.0 on pci0=0A= agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe8000000=0A= agp0: allocating GATT for aperture of size 64M=0A= pcib1: at device 1.0 on pci0=0A= pcib1: secondary bus 1=0A= pcib1: subordinate bus 1=0A= pcib1: I/O decode 0xc000-0xcfff=0A= pcib1: memory decode 0xec000000-0xec0fffff=0A= pcib1: prefetched decode 0xe0000000-0xe7ffffff=0A= pci1: on pcib1=0A= pci1: physical bus=3D1=0A= found-> vendor=3D0x1039, dev=3D0x6325, revid=3D0x00=0A= bus=3D1, slot=3D0, func=3D0=0A= class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0=0A= cmdreg=3D0x0003, statreg=3D0x02b0, cachelnsz=3D0 (dwords)=0A= lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns)=0A= intpin=3Da, irq=3D10=0A= powerspec 2 supports D0 D1 D2 D3 current D0=0A= map[10]: type 3, range 32, base e0000000, size 27, enabled=0A= pcib1: (null) requested memory range 0xe0000000-0xe7ffffff: good=0A= map[14]: type 1, range 32, base ec000000, size 17, enabled=0A= pcib1: (null) requested memory range 0xec000000-0xec01ffff: good=0A= map[18]: type 4, range 32, base 0000c000, size 7, enabled=0A= pcib1: (null) requested I/O range 0xc000-0xc07f: in range=0A= pcib1: slot 0 INTA routed to irq 16=0A= pci1: at device 0.0 (no driver attached)=0A= isab0: at device 2.0 on pci0=0A= isa0: on isab0=0A= atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x4000-0x400f irq 14 at device 2.5 = on pci0=0A= atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x4000=0A= ata0: on atapci0=0A= atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0=0A= atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6=0A= ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50=0A= ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00=0A= ata0: stat1=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00=0A= ata0: reset tp2 stat0=3D50 stat1=3D50 devices=3D0x3=0A= ioapic0: routing intpin 14 (ISA IRQ 14) to vector 48=0A= ata0: [MPSAFE]=0A= ata1: on atapci0=0A= atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170=0A= atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376=0A= ata1: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00=0A= ata1: stat0=3D0x80 err=3D0x80 lsb=3D0x80 msb=3D0x80=0A= ata1: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00=0A= ata1: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb=0A= ata1: reset tp2 stat0=3D50 stat1=3D00 = devices=3D0x9=0A= ioapic0: routing intpin 15 (ISA IRQ 15) to vector 49=0A= ata1: [MPSAFE]=0A= pci0: at device 2.7 (no driver attached)=0A= ohci0: mem 0xec124000-0xec124fff irq 20 at = device 3.0 on pci0=0A= ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xec124000=0A= ioapic0: routing intpin 20 (PCI IRQ 20) to vector 50=0A= ohci0: [GIANT-LOCKED]=0A= usb0: OHCI version 1.0, legacy support=0A= usb0: on ohci0=0A= usb0: USB revision 1.0=0A= uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1=0A= uhub0: 2 ports with 2 removable, self powered=0A= ohci1: mem 0xec120000-0xec120fff irq 21 at = device 3.1 on pci0=0A= ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xec120000=0A= ioapic0: routing intpin 21 (PCI IRQ 21) to vector 51=0A= ohci1: [GIANT-LOCKED]=0A= usb1: OHCI version 1.0, legacy support=0A= usb1: on ohci1=0A= usb1: USB revision 1.0=0A= uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1=0A= uhub1: 2 ports with 2 removable, self powered=0A= ohci2: mem 0xec121000-0xec121fff irq 22 at = device 3.2 on pci0=0A= ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xec121000=0A= ioapic0: routing intpin 22 (PCI IRQ 22) to vector 52=0A= ohci2: [GIANT-LOCKED]=0A= usb2: OHCI version 1.0, legacy support=0A= usb2: on ohci2=0A= usb2: USB revision 1.0=0A= uhub2: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1=0A= uhub2: 2 ports with 2 removable, self powered=0A= ehci0: mem 0xec122000-0xec122fff irq = 258 at device 3.3 on pci0=0A= ehci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xec122000=0A= ehci0: Could not allocate irq=0A= device_attach: ehci0 attach returned 6=0A= sis0: port 0xe000-0xe0ff mem = 0xec123000-0xec123fff irq 19 at device 4.0 on pci0=0A= sis0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe000=0A= miibus0: on sis0=0A= rlphy0: on miibus0=0A= rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto=0A= sis0: bpf attached=0A= sis0: Ethernet address: 00:01:80:34:65:56=0A= ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53=0A= sis0: [MPSAFE]=0A= ex_isa_identify()=0A= ata: ata0 already exists; skipping it=0A= ata: ata1 already exists; skipping it=0A= pnp_identify: Trying Read_Port at 203=0A= pnp_identify: Trying Read_Port at 243=0A= pnp_identify: Trying Read_Port at 283=0A= pnp_identify: Trying Read_Port at 2c3=0A= pnp_identify: Trying Read_Port at 303=0A= pnp_identify: Trying Read_Port at 343=0A= pnp_identify: Trying Read_Port at 383=0A= pnp_identify: Trying Read_Port at 3c3=0A= PNP Identify complete=0A= unknown: status reg test failed ff=0A= unknown: status reg test failed ff=0A= unknown: status reg test failed ff=0A= unknown: status reg test failed ff=0A= unknown: status reg test failed ff=0A= unknown: status reg test failed ff=0A= pnpbios: 15 devices, largest 102 bytes=0A= PNP0200: adding dma mask 0x10=0A= PNP0200: adding io range 0-0xf, size=3D0x10, align=3D0=0A= PNP0200: adding io range 0x81-0x83, size=3D0x3, align=3D0=0A= PNP0200: adding io range 0x87-0x87, size=3D0x1, align=3D0=0A= PNP0200: adding io range 0x89-0x8b, size=3D0x3, align=3D0=0A= PNP0200: adding io range 0x8f-0x91, size=3D0x3, align=3D0=0A= PNP0200: adding io range 0xc0-0xdf, size=3D0x20, align=3D0=0A= pnpbios: handle 1 device ID PNP0200 (0002d041)=0A= PNP0100: adding irq mask 0x1=0A= PNP0100: adding io range 0x40-0x43, size=3D0x4, align=3D0=0A= pnpbios: handle 2 device ID PNP0100 (0001d041)=0A= PNP0b00: adding irq mask 0x100=0A= PNP0b00: adding io range 0x70-0x71, size=3D0x2, align=3D0=0A= pnpbios: handle 3 device ID PNP0b00 (000bd041)=0A= PNP0303: adding irq mask 0x2=0A= PNP0303: adding io range 0x60-0x60, size=3D0x1, align=3D0=0A= PNP0303: adding io range 0x64-0x64, size=3D0x1, align=3D0=0A= pnpbios: handle 4 device ID PNP0303 (0303d041)=0A= PNP0800: adding io range 0x61-0x61, size=3D0x1, align=3D0=0A= pnpbios: handle 5 device ID PNP0800 (0008d041)=0A= PNP0c04: adding irq mask 0x2000=0A= PNP0c04: adding io range 0xf0-0xff, size=3D0x10, align=3D0=0A= pnpbios: handle 6 device ID PNP0c04 (040cd041)=0A= PNP0c01: adding fixed memory32 range 0-0x9ffff, size=3D0xa0000=0A= PNP0c01: adding fixed memory32 range 0x20000000-0x203fffff, = size=3D0x400000=0A= PNP0c01: adding fixed memory32 range 0xffee0000-0xffefffff, = size=3D0x20000=0A= PNP0c01: adding fixed memory32 range 0xfffe0000-0xffffffff, = size=3D0x20000=0A= PNP0c01: adding fixed memory32 range 0xfec00000-0xfec0ffff, = size=3D0x10000=0A= PNP0c01: adding fixed memory32 range 0xfee00000-0xfee0ffff, = size=3D0x10000=0A= PNP0c01: adding fixed memory32 range 0x100000-0xffffff, size=3D0xf00000=0A= pnpbios: handle 7 device ID PNP0c01 (010cd041)=0A= PNP0c02: adding fixed memory32 range 0xf0000-0xf3fff, size=3D0x4000=0A= PNP0c02: adding fixed memory32 range 0xf4000-0xf7fff, size=3D0x4000=0A= PNP0c02: adding fixed memory32 range 0xf8000-0xfbfff, size=3D0x4000=0A= PNP0c02: adding fixed memory32 range 0xfc000-0xfffff, size=3D0x4000=0A= pnpbios: handle 8 device ID PNP0c02 (020cd041)=0A= PNP0a03: adding io range 0x290-0x29f, size=3D0x10, align=3D0=0A= PNP0a03: adding io range 0x4d0-0x4d1, size=3D0x2, align=3D0=0A= PNP0a03: adding io range 0xcf8-0xcff, size=3D0x8, align=3D0=0A= pnpbios: handle 9 device ID PNP0a03 (030ad041)=0A= PNP0c02: adding io range 0x1000-0x107f, size=3D0x80, align=3D0=0A= PNP0c02: adding io range 0x10c0-0x10df, size=3D0x20, align=3D0=0A= pnpbios: handle 11 device ID PNP0c02 (020cd041)=0A= PNP0501: adding irq mask 0x10=0A= PNP0501: adding io range 0x3f8-0x3ff, size=3D0x8, align=3D0=0A= pnpbios: handle 12 device ID PNP0501 (0105d041)=0A= PNP0700: adding dma mask 0x4=0A= PNP0700: adding io range 0x3f0-0x3f5, size=3D0x6, align=3D0=0A= PNP0700: adding io range 0x3f7-0x3f7, size=3D0x1, align=3D0=0A= PNP0700: adding irq mask 0x40=0A= pnpbios: handle 13 device ID PNP0700 (0007d041)=0A= PNP0401: adding dma mask 0x8=0A= PNP0401: adding irq mask 0x80=0A= PNP0401: adding io range 0x378-0x37f, size=3D0x8, align=3D0=0A= PNP0401: adding io range 0x778-0x77f, size=3D0x8, align=3D0=0A= pnpbios: handle 15 device ID PNP0401 (0104d041)=0A= PNP0501: adding irq mask 0x8=0A= PNP0501: adding io range 0x2f8-0x2ff, size=3D0x8, align=3D0=0A= pnpbios: handle 16 device ID PNP0501 (0105d041)=0A= ahc_isa_probe 13: ioport 0xdc00 alloc failed=0A= sc: sc0 already exists; skipping it=0A= vga: vga0 already exists; skipping it=0A= isa_probe_children: disabling PnP devices=0A= isa_probe_children: probing non-PnP devices=0A= pmtimer0 on isa0=0A= orm0: at iomem 0xc0000-0xc7fff on isa0=0A= adv0: not probed (disabled)=0A= aha0: not probed (disabled)=0A= aic0: not probed (disabled)=0A= atkbdc0: at port 0x60,0x64 on isa0=0A= atkbd0: irq 1 on atkbdc0=0A= atkbd: the current kbd controller command byte 0047=0A= atkbd: keyboard ID 0x41ab (2)=0A= kbd0 at atkbd0=0A= kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000=0A= ioapic0: routing intpin 1 (ISA IRQ 1) to vector 54=0A= atkbd0: [GIANT-LOCKED]=0A= psm0: current command byte:0047=0A= psm0: strange result for test aux port (1).=0A= psm0: failed to reset the aux device.=0A= bt0: not probed (disabled)=0A= cs0: not probed (disabled)=0A= ed0: not probed (disabled)=0A= fdc0: ic_type 90 part_id 80=0A= fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 = on isa0=0A= fdc0: ic_type 90 part_id 80=0A= ioapic0: routing intpin 6 (ISA IRQ 6) to vector 55=0A= fdc0: [MPSAFE]=0A= fdc0: [FAST]=0A= fe0: not probed (disabled)=0A= ie0: not probed (disabled)=0A= lnc0: not probed (disabled)=0A= ppc0: parallel port found at 0x378=0A= ppc0: using extended I/O port range=0A= ppc0: ECP SPP SPP=0A= ppc0: at port 0x378-0x37f irq 7 on isa0=0A= ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode=0A= ppc0: FIFO with 16/16/16 bytes threshold=0A= ppbus0: on ppc0=0A= plip0: on ppbus0=0A= plip0: bpf attached=0A= lpt0: on ppbus0=0A= lpt0: Interrupt-driven port=0A= ppi0: on ppbus0=0A= ioapic0: routing intpin 7 (ISA IRQ 7) to vector 56=0A= sc0: at flags 0x100 on isa0=0A= sc0: VGA <16 virtual consoles, flags=3D0x300>=0A= sc0: fb0, kbd1, terminal emulator: sc (syscons terminal)=0A= sio0: irq maps: 0x81 0x91 0x81 0x81=0A= sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0=0A= sio0: type 16550A=0A= ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57=0A= sio1: irq maps: 0x81 0x89 0x81 0x81=0A= sio1 at port 0x2f8-0x2ff irq 3 on isa0=0A= sio1: type 16550A=0A= ioapic0: routing intpin 3 (ISA IRQ 3) to vector 58=0A= sio2: not probed (disabled)=0A= sio3: not probed (disabled)=0A= sn0: not probed (disabled)=0A= vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0=0A= vt0: not probed (disabled)=0A= isa_probe_children: probing PnP devices=0A= unknown: can't assign resources (port)=0A= unknown: at port 0x60 on isa0=0A= unknown: failed to probe at port 0x61 on isa0=0A= unknown: can't assign resources (memory)=0A= unknown: at iomem = 0-0x9ffff,0x20000000-0x203fffff,0xffee0000-0xffefffff on isa0=0A= unknown: can't assign resources (port)=0A= unknown: at port 0x3f8-0x3ff on isa0=0A= unknown: can't assign resources (port)=0A= unknown: at port 0x3f0-0x3f5 on isa0=0A= unknown: can't assign resources (port)=0A= unknown: at port 0x378-0x37f on isa0=0A= unknown: can't assign resources (port)=0A= unknown: at port 0x2f8-0x2ff on isa0=0A= Device configuration finished.=0A= procfs registered=0A= lapic: Divisor 2, Frequency 49998542 hz=0A= Timecounter "TSC" frequency 1699952540 Hz quality 800=0A= Timecounters tick every 1.000 msec=0A= lo0: bpf attached=0A= rr232x: no controller detected.=0A= fdc0: output ready timeout=0A= fdc0: output ready timeout=0A= fdc0: output ready timeout=0A= fdc0: output ready timeout=0A= fdc0: output ready timeout=0A= fdc0: output ready timeout=0A= fdc0: output ready timeout=0A= ata0-slave: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA100 cable=3D40 wire=0A= ata0-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA33 cable=3D40 wire=0A= ad0: setting PIO4 on 5513 chip=0A= ad0: setting UDMA33 on 5513 chip=0A= ad0: 6187MB at ata0-master UDMA33=0A= ad0: 12672450 sectors [13410C/15H/63S] 16 sectors/interrupt 1 depth queue=0A= GEOM: new disk ad0=0A= ad0: Silicon Integrated Systems check1 failed=0A= ad0: Adaptec check1 failed=0A= ad0: LSI (v3) check1 failed=0A= ad0: LSI (v2) check1 failed=0A= ad0: FreeBSD check1 failed=0A= ad1: setting PIO4 on 5513 chip=0A= ad1: setting UDMA100 on 5513 chip=0A= ad1: 19092MB at ata0-slave UDMA100=0A= ad1: 39102336 sectors [38792C/16H/63S] 16 sectors/interrupt 1 depth queue=0A= ad1: Silicon Integrated Systems check1 failed=0A= ad1: Adaptec check1 failed=0A= ad1: LSI (v3) check1 failed=0A= ad1: LSI (v2) check1 failed=0A= ad1: FreeBSD check1 failed=0A= ata1-slave: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA33 cable=3D40 wire=0A= ata1-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA100 cable=3D80 wire=0A= ad2: setting PIO4 on 5513 chip=0A= ad2: setting UDMA100 on 5513 chip=0A= ad2: 38166MB at ata1-master UDMA100=0A= ad2: 78165360 sectors [77545C/16H/63S] 16 sectors/interrupt 1 depth queue=0A= ad2: Silicon Integrated Systems check1 failed=0A= ad2: Adaptec check1 failed=0A= ad2: LSI (v3) check1 failed=0A= ad2: LSI (v2) check1 failed=0A= ad2: FreeBSD check1 failed=0A= acd0: setting PIO4 on 5513 chip=0A= acd0: setting UDMA33 on 5513 chip=0A= GEOM: new disk ad1=0A= GEOM: new disk ad2=0A= acd0: DVDROM drive at ata1 as slave=0A= acd0: read 8958KB/s (8958KB/s), 256KB buffer, UDMA33=0A= acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet=0A= acd0: Writes:=0A= acd0: Audio: play, 256 volume levels=0A= acd0: Mechanism: ejectable tray, unlocked=0A= acd0: Medium: no/blank disc=0A= ATA PseudoRAID loaded=0A= Trying to mount root from ufs:/dev/ad0s1a=0A= start_init: trying /sbin/init=0A= fdc0: output ready timeout=0A= fdc0: input ready timeout=0A= fdc0: input ready timeout=0A= fdc0: output ready timeout=0A= fdc0: input ready timeout=0A= fdc0: input ready timeout=0A= fdc0: output ready timeout=0A= fdc0: input ready timeout=0A= fdc0: input ready timeout=0A= fdc0: output ready timeout=0A= fdc0: input ready timeout=0A= fdc0: input ready timeout=0A= link_elf: symbol _vn_lock undefined=0A= ------=_NextPart_000_0046_01C867D1.5B90A110-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 15:14:23 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8823716A418 for ; Tue, 5 Feb 2008 15:14:23 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: from smtpout04-02.prod.mesa1.secureserver.net (smtpout04-01.prod.mesa1.secureserver.net [64.202.165.196]) by mx1.freebsd.org (Postfix) with SMTP id 31E9413C43E for ; Tue, 5 Feb 2008 15:14:22 +0000 (UTC) (envelope-from Stephen.Clark@seclark.us) Received: (qmail 31393 invoked from network); 5 Feb 2008 15:14:21 -0000 Received: from unknown (24.144.77.185) by smtpout04-04.prod.mesa1.secureserver.net (64.202.165.199) with ESMTP; 05 Feb 2008 15:14:21 -0000 Message-ID: <47A87CDE.4060801@seclark.us> Date: Tue, 05 Feb 2008 10:12:30 -0500 From: Stephen Clark User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <47A85CB4.20202@seclark.us> In-Reply-To: <47A85CB4.20202@seclark.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: kgdb kernel crash with module X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stephen.Clark@seclark.us List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2008 15:14:23 -0000 Stephen Clark wrote: > Hello List, > > Is there some way to debug a crash dump with kgdb when the crash is in > a module? > > Steve > My bad found it in the manual - I obviously did not read far enough. sorry for the noise. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 19:42:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B35D316A418 for ; Tue, 5 Feb 2008 19:42:06 +0000 (UTC) (envelope-from tom@samplonius.org) Received: from ly.sdf.com (ly.sdf.com [216.113.193.83]) by mx1.freebsd.org (Postfix) with ESMTP id 66F3B13C4D1 for ; Tue, 5 Feb 2008 19:42:06 +0000 (UTC) (envelope-from tom@samplonius.org) Received: from localhost (localhost [127.0.0.1]) by ly.sdf.com (Postfix) with ESMTP id 678EC37C002; Tue, 5 Feb 2008 11:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.044 X-Spam-Level: X-Spam-Status: No, score=-4.044 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.355, BAYES_00=-2.599] Received: from ly.sdf.com ([127.0.0.1]) by localhost (ly.sdf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4acmma4xsC1A; Tue, 5 Feb 2008 11:37:58 -0800 (PST) Received: from ly.sdf.com (ly.sdf.com [216.113.193.83]) by ly.sdf.com (Postfix) with ESMTP id 0721937C001; Tue, 5 Feb 2008 11:37:58 -0800 (PST) Date: Tue, 5 Feb 2008 11:37:57 -0800 (PST) From: Tom Samplonius To: Primeroz lists Message-ID: <28875927.5811202240277979.JavaMail.root@ly.sdf.com> In-Reply-To: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.251.80.98] Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 05 Feb 2008 19:42:06 -0000 ----- "Primeroz lists" wrote: > Hi all, > > we are experiencing repeated crash on a Dell PowerEdge 2950 (rev 1 or > 2). > > FBSD release is 6.2-RELEASE-p5 , AMD64. 2xXeon QuadCore and 8G of Ram. > > MySQL Version is 5.0.41 with following configuration settings: > > set-variable = key_buffer=768M > set-variable = table_cache=800 > set-variable = sort_buffer=24M > set-variable = myisam_sort_buffer_size=256M > set-variable = record_buffer=16M > set-variable = max_allowed_packet=10M > set-variable = thread_stack=128K > set-variable = join_buffer=512M > set-variable = max_heap_table_size=256M > set-variable = max_connections=300 > set-variable = tmp_table_size=384M > set-variable = query_cache_size=402653184 > set-variable = query_cache_limit=134217728 > set-variable = read_rnd_buffer_size=10M > set-variable = ft_min_word_len=1 > pid-file = /var/db/mysqld.pid > tmpdir = /var/tmp > ft_stopword_file = '' > set-variable = thread_cache_size=80 > set-variable = myisam_stats_method=nulls_equal Also, myslq is not really well tuned. The query cache is a kludge. It is helpful, if you have stupid application that issues the same query over and over again, even though the database has not changed. If you don't have this problem, it just adds overhead. And quite a lot, if it is big. Generally, the query cache should be 20 to 100M at most, if not disabled. If you have a smart web application (anything using memcached), the query cache should just be turned off. It will actually be faster. You should give us much storage as possible to the database engine, for it cache actual data, not query results. It is weird that you are apparently are heavily using Innodb, but you have just set various myiasam values? Here is something useful: http://www.joyeur.com/2007/09/25/quick-wins-with-mysql Tom From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 19:58:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8061416A46D for ; Tue, 5 Feb 2008 19:58:31 +0000 (UTC) (envelope-from christian.baer@uni-dortmund.de) Received: from dd17730.kasserver.com (dd17730.kasserver.com [85.13.138.103]) by mx1.freebsd.org (Postfix) with ESMTP id 10EEF13C457 for ; Tue, 5 Feb 2008 19:58:31 +0000 (UTC) (envelope-from christian.baer@uni-dortmund.de) Received: from nermal.rz1.convenimus.net (sub87-230-112-155.he-dsl.de [87.230.112.155]) by dd17730.kasserver.com (Postfix) with ESMTP id F202D18080BC1 for ; Tue, 5 Feb 2008 20:29:20 +0100 (CET) Received: from sunny.rz1.convenimus.net (sunny.rz1.convenimus.net [192.168.100.5]) by nermal.rz1.convenimus.net (Postfix) with ESMTP id 22D2415213 for ; Tue, 5 Feb 2008 20:29:08 +0100 (CET) Received: by sunny.rz1.convenimus.net (Postfix, from userid 1001) id 8156F33C23; Tue, 5 Feb 2008 20:28:02 +0100 (CET) Date: Tue, 5 Feb 2008 20:28:02 +0100 From: Christian Baer To: freebsd-stable@freebsd.org Message-ID: <20080205192802.GA22163@sunny.rz1.convenimus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (FreeBSD/6.3-STABLE (sparc64)) Subject: Did something change with DHCP? 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, 05 Feb 2008 19:58:31 -0000 Greetings, people! I had a strange effect today when I updated to the latest -STABLE (sources from about 17:00 UTC yesterday, not sure about the time though). After rebooting for the last time (installworld and mergemaster went before that), the machine had a new IP. The old one was 192.168.100.9 the new one had a 76 instead of the 9. I have dnsmasq running on another computer as a DHCP-server. I used static DHCP, which means the ether address of each computer is in the configuration file of dnsmasq and should give each machine the same IP-address each time. That works fine for alle my machines exept this one where I have just updates. The 76 is part of the dynamic range I put in there in case I ever connect a computer from a friend or a laptop or anything else that isn't always in my network. If I try to get a new IP-address with dhclient fxp0, I always get 76. dnsmasq puts this into /var/log/messages (twice): Feb 5 16:09:43 nermal dnsmasq[138]: not giving name jon.rz1.convenimus.net to the DHCP lease of 192.168.100.76 because the name exists in /etc/hosts with address 192.168.100.9 I also get this message if any other computer requests an IP-address. Mind you, exactly this message, not a message regarding the other computer. I did notice some changes in the defaults of rc.config. After looking at the file more closely, I still can't find anything that would be of relevance. This is a piece of /etc/defaults/rc.conf: dhclient_program="/sbin/dhclient" dhclient_flags="" #dhclient_flags_fxp0="" background_dhclient="NO" #background_dhclient_fxp0="YES" synchronous_dhclient="YES" I did not comment out those two lines, that was done by mergemaster. And I don't see anything in those settings that would suggest this happenning. There is nothing concerning the dhclient in rc.conf and /etc/dhclient.conf contains not entries, therefore leaving the defaults. What changed with this update? Regards Chris From owner-freebsd-stable@FreeBSD.ORG Tue Feb 5 20:08:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70FD516A41A for ; Tue, 5 Feb 2008 20:08:09 +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 2EFE413C4D1 for ; Tue, 5 Feb 2008 20:08:08 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.2/8.14.2) id m15JSVjM096245; Tue, 5 Feb 2008 13:28:31 -0600 (CST) (envelope-from dan) Date: Tue, 5 Feb 2008 13:28:31 -0600 From: Dan Nelson To: Mike Andrews Message-ID: <20080205192830.GB17472@dan.emsphone.com> References: <20080204230945.J49853@mindcrime.int.bit0.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20080204230945.J49853@mindcrime.int.bit0.com> X-OS: FreeBSD 7.0-PRERELEASE User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: mount -p and NFS 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: Tue, 05 Feb 2008 20:08:09 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In the last episode (Feb 04), Mike Andrews said: > Is there anything like "mount -p" that will print the current NFS > options in use? TCP vs UDP, v2 vs v3, read/write sizes etc. It > doesn't have to be in fstab format; I just need to be able to see > what the flags are for an active mount. > > This would be useful in tracking down an irritating NFS problem I've > been experiencing with diskless systems in every 6.x release and > 7.0-RC1, namely libc.so.6 appears to be truncated or corrupt to the > client at somewhat random times... I think it may be related to > mount options, hence the question. Theoretically, any filesystem that uses nmount(2) should have its options recored in an easy-to-extract format, since one of the arguments to nmount is an array of options. I patched my kernel and /sbin/mount binary to do this (borrowing the f_charspare field in struct statfs), and it mostly works. The stuff below in <> brackets are from the options array. You can see that cd9660 was mounted with the option "ssector=0": (root@dan) /root># mount local/root on / (zfs, NFS exported, local, ) devfs on /dev (devfs, local, <>) /dev/ufs/boot on /.boot (ufs, local, soft-updates, ) procfs on /proc (procfs, local, ) /dev/md0 on /tmp (ufs, NFS exported, local, <>) /dev/cd0 on /cdrom (cd9660, NFS exported, local, read-only, ) Unfortunately, mount_nfs simply calls nmount with a single "nfs_args" option whose value is the same binary "struct nfs_args" it used to call mount(2) with :( The fix would be to make nfs_vfsops.c and mount_nfs.c use the options array instead of a custom struct, but nfs_vfsops.c:nfs_decode_args scares me off every time I look at it. -- Dan Nelson dnelson@allantgroup.com --2oS5YaxWCcQjTEyO Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mountopts.diff" Index: sys/kern/vfs_mount.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_mount.c,v retrieving revision 1.265.2.2 diff -u -p -r1.265.2.2 vfs_mount.c --- sys/kern/vfs_mount.c 17 Jan 2008 04:24:53 -0000 1.265.2.2 +++ sys/kern/vfs_mount.c 18 Jan 2008 23:13:48 -0000 @@ -1020,6 +1020,40 @@ vfs_domount( if (mp->mnt_opt != NULL) vfs_freeopts(mp->mnt_opt); mp->mnt_opt = mp->mnt_optnew; + + /* Collapse the mount options into a readable string */ + mp->mnt_stat.f_charspare[0]=0; + if (mp->mnt_opt) { + struct vfsopt *opt; + struct sbuf *sb; + + sb = sbuf_new(NULL, mp->mnt_stat.f_charspare, + sizeof(mp->mnt_stat.f_charspare), + SBUF_FIXEDLEN); + TAILQ_FOREACH(opt, mp->mnt_opt, link) { + /* + * Skip options that are temporary, stored + * elsewhere in struct statfs, or are structs + */ + if (strcmp(opt->name,"errmsg") == 0 || + strcmp(opt->name,"from") == 0 || + strcmp(opt->name,"fspath") == 0 || + strcmp(opt->name,"fstype") == 0 || + strcmp(opt->name,"nfs_args") == 0 || + strcmp(opt->name,"update") == 0 ) + continue; + if (sbuf_len(sb)) + sbuf_cat(sb, ","); + sbuf_cat(sb, opt->name); + if (opt->len) { + sbuf_cat(sb, "="); + sbuf_cat(sb, opt->value); + } + } + sbuf_finish(sb); + sbuf_delete(sb); + } + (void)VFS_STATFS(mp, &mp->mnt_stat, td); } /* Index: sbin/mount/mount.c =================================================================== RCS file: /home/ncvs/src/sbin/mount/mount.c,v retrieving revision 1.96 diff -u -p -r1.96 mount.c --- sbin/mount/mount.c 25 Jun 2007 05:06:54 -0000 1.96 +++ sbin/mount/mount.c 2 Oct 2007 21:20:18 -0000 @@ -596,6 +596,7 @@ prmount(struct statfs *sfp) (void)printf(", %s", o->o_name); flags &= ~o->o_opt; } + printf(", <%s>",sfp->f_charspare); /* * Inform when file system is mounted by an unprivileged user * or privileged non-root user. --2oS5YaxWCcQjTEyO-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 01:43:55 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2B5216A418 for ; Wed, 6 Feb 2008 01:43:55 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id 3E46813C447 for ; Wed, 6 Feb 2008 01:43:55 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1JMZKM-0009vp-2t for freebsd-stable@freebsd.org; Wed, 06 Feb 2008 09:43:54 +0800 Message-ID: <47A910D9.5030508@micom.mng.net> Date: Wed, 06 Feb 2008 09:43:53 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.9 (X11/20071225) MIME-Version: 1.0 To: FreeBSD Stable Mailing List References: <47A7D8AC.7030104@micom.mng.net> In-Reply-To: <47A7D8AC.7030104@micom.mng.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: fusefs-ntfs makes fatal trap/page fault in FreeBSD-7.0 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, 06 Feb 2008 01:43:55 -0000 More information: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x746e756f fault code = supervisor read, page not present instruction pointer = 0x20:0xc06d8f46 stack pointer = 0x28:0xe64189b0 frame pointer = 0x28:0xe64189b4 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 = 843 (mount_fusefs) panic: from debugger cpuid = 0 KDB: stack backtrace: Uptime: 1m34s Physical memory: 1006 MB Dumping 56 MB: 41 25 9 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xc064f4fe in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc064f7bb in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0465d47 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:433 #4 0xc0466735 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #5 0xc0467ea5 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:222 #6 0xc0676b06 in kdb_trap (type=12, code=0, tf=0xe6418970) at /usr/src/sys/kern/subr_kdb.c:502 #7 0xc085528f in trap_fatal (frame=0xe6418970, eva=1953396079) at /usr/src/sys/i386/i386/trap.c:890 #8 0xc08554b0 in trap_pfault (frame=0xe6418970, usermode=0, eva=1953396079) at /usr/src/sys/i386/i386/trap.c:812 #9 0xc0855e52 in trap (frame=0xe6418970) at /usr/src/sys/i386/i386/trap.c:490 #10 0xc083c36b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #11 0xc06d8f46 in strcmp (s1=0xc432044f "fspath", s2=0x746e756f
) at /usr/src/sys/libkern/strcmp.c:45 #12 0xc06c0865 in vfs_getopt (opts=0xc09bb700, name=0xc432044f "fspath", buf=0x0, len=0x0) at /usr/src/sys/kern/vfs_mount.c:1869 #13 0xc4319380 in ?? () #14 0xc09bb700 in w_data () #15 0xc432044f in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0xc43df210 in ?? () #19 0xc43df210 in ?? () #20 0xc09b1db0 in w_lock_list_free () #21 0xc43df210 in ?? () #22 0xe6418a00 in ?? () #23 0x00000246 in ?? () #24 0xc09b1db0 in w_lock_list_free () #25 0xe6418a1c in ?? () #26 0xc064279d in _mtx_unlock_spin_flags (m=0xc3e5707c, opts=-1002573296, file=0xc08d01ce "/usr/src/sys/kern/vfs_mount.c", line=1001) at /usr/src/sys/kern/kern_mutex.c:246 #27 0xc06c34ad in vfs_donmount (td=0xc43df210, fsflags=0, fsoptions=0xc439c900) at /usr/src/sys/kern/vfs_mount.c:1007 #28 0xc06c47a2 in nmount (td=0xc43df210, uap=0xe6418cfc) at /usr/src/sys/kern/vfs_mount.c:416 #29 0xc0855783 in syscall (frame=0xe6418d38) at /usr/src/sys/i386/i386/trap.c:1035 #30 0xc083c3d0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #31 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Ganbold wrote: > Hi, > > I'm having trouble mounting external NTFS hard drive using fusefs-ntfs > port on Dell Latitude D620. > > devil# uname -an > FreeBSD devil.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #3: > Tue Feb 5 10:29:24 ULAT 2008 > tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 > > devil# pkg_info | grep fuse > fusefs-kmod-0.3.9.p1_3 Kernel module for fuse > fusefs-libs-2.7.2 FUSE allows filesystem implementation in userspace > fusefs-ntfs-1.1120 Mount NTFS partitions (read/write) and disk images > devil# kldload /usr/local/modules/fuse.ko > devil# kldstat > Id Refs Address Size Name > 1 23 0xc0400000 6df8b4 kernel > 2 1 0xc0ae0000 14324 snd_hda.ko > 3 2 0xc0af5000 52a08 sound.ko > 4 2 0xc0b48000 10ebc drm.ko > 5 1 0xc0b59000 7184 i915.ko > 6 1 0xc0b61000 6b314 acpi.ko > 7 2 0xc4005000 c000 ipfw.ko > 8 1 0xc4035000 4000 ipdivert.ko > 9 1 0xc406d000 22000 linux.ko > 11 3 0xc43dd000 3000 ucom.ko > 12 1 0xc43e0000 3000 uftdi.ko > 13 1 0xc43e5000 4000 uplcom.ko > 14 1 0xc59aa000 e000 fuse.ko > > > When I try to mount it, on serial console I see: > .. > umass0: on uhub4 > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-4 device > da0: 40.000MB/s transfers > da0: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 1 0 > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > (da0:umass-sim0:0:0:0): ABORTED COMMAND asc:0,0 > (da0:umass-sim0:0:0:0): No additional sense information > (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 0 0 3f 0 0 1 0 > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > (da0:umass-sim0:0:0:0): ABORTED COMMAND asc:0,0 > (da0:umass-sim0:0:0:0): No additional sense information > (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > GEOM_LABEL: Label for provider da0s1 is ntfs/FreeAgent Drive. > GEOM_LABEL: Label ntfs/FreeAgent Drive removed. > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x746e756f > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06d8f36 > stack pointer = 0x28:0xe63d09b0 > frame pointer = 0x28:0xe63d09b4 > 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 = 19197 (mount_fusefs) > [thread pid 19197 tid 100099 ] > Stopped at strcmp+0x26: movzbl 0(%ecx),%eax > db> bt > Tracing pid 19197 tid 100099 td 0xc4312210 > strcmp(c59b644f,746e756f,c3e43934,2d,e63d0a8c,...) at strcmp+0x26 > vfs_getopt(c09bb6c0,c59b644f,0,0,c4312210,...) at vfs_getopt+0x35 > fuse_mount(c3e438b8,c4312210,c08d0185,3e9,0,...) at fuse_mount+0x70 > vfs_donmount(48217080,c,e63d0c70,c48e4000,bfbfebb4,...) at > vfs_donmount+0x13ad > nmount(c4312210,e63d0cfc,c,e63d0d38,c095e6d0,...) at nmount+0xb2 > syscall(e63d0d38) at syscall+0x2b3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x480ccb4b, esp = > 0xbfbfe64c, ebp = 0xbfbfebc8 --- > db> trace > Tracing pid 19197 tid 100099 td 0xc4312210 > strcmp(c59b644f,746e756f,c3e43934,2d,e63d0a8c,...) at strcmp+0x26 > vfs_getopt(c09bb6c0,c59b644f,0,0,c4312210,...) at vfs_getopt+0x35 > fuse_mount(c3e438b8,c4312210,c08d0185,3e9,0,...) at fuse_mount+0x70 > vfs_donmount(48217080,c,e63d0c70,c48e4000,bfbfebb4,...) at > vfs_donmount+0x13ad > nmount(c4312210,e63d0cfc,c,e63d0d38,c095e6d0,...) at nmount+0xb2 > syscall(e63d0d38) at syscall+0x2b3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x480ccb4b, esp = > 0xbfbfe64c, ebp = 0xbfbfebc8 --- > db> > > Any idea how to solve this problem? > > thanks, > > Ganbold > -- "You boys lookin' for trouble?" "Sure. Whaddya got?" -- Marlon Brando, "The Wild Ones" From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 02:02:15 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19E8516A417 for ; Wed, 6 Feb 2008 02:02:15 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.freebsd.org (Postfix) with ESMTP id D40BA13C457 for ; Wed, 6 Feb 2008 02:02:14 +0000 (UTC) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=daemon.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.67 (FreeBSD)) (envelope-from ) id 1JMZc5-000A5k-2m for freebsd-stable@freebsd.org; Wed, 06 Feb 2008 10:02:13 +0800 Message-ID: <47A91524.9070401@micom.mng.net> Date: Wed, 06 Feb 2008 10:02:12 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.9 (X11/20071225) MIME-Version: 1.0 To: FreeBSD Stable Mailing List References: <47A7E133.8030802@micom.mng.net> In-Reply-To: <47A7E133.8030802@micom.mng.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: panic: resource_list_release: resource entry is not busy in FreeBSD-7.0 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, 06 Feb 2008 02:02:15 -0000 More information: Unread portion of the kernel message buffer: panic: resource_list_release: resource entry is not busy cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c08c8071,e40bebb8,c064f78f,c08ec0ac,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ec0ac,0,c08c7b77,e40bebc4,0,...) at kdb_backtrace+0x29 panic(c08c7b77,3,10,0,c3c6ce40,...) at panic+0x10f resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at resource_list_release+0xc2 bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at bus_generic_rl_release_resource+0x77 bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at bus_release_resource+0x67 ath_pci_detach(c3c92e00,c3b41050,c095ba6c,970,4,...) at ath_pci_detach+0xb2 device_detach(c3c92e00,e40becac,e40becb0,c09aad30,0,...) at device_detach+0x8c cardbus_detach_card(c3c46100,c3b9c8b4,c091b0bc,1df,c09ad2a0,...) at cardbus_detach_card+0xcd cbb_event_thread(c3bb1000,e40bed38,c08c1af7,305,c3c40ab0,...) at cbb_event_thread+0x15a fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 24s Physical memory: 1006 MB Dumping 55 MB: 40 24 8 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xc064f4fe in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc064f7bb in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0465d47 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:433 #4 0xc0466735 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #5 0xc0467ea5 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 #6 0xc0676b06 in kdb_trap (type=3, code=0, tf=0xe40beb44) at /usr/src/sys/kern/subr_kdb.c:502 #7 0xc0855fcf in trap (frame=0xe40beb44) at /usr/src/sys/i386/i386/trap.c:648 #8 0xc083c36b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #9 0xc0676c82 in kdb_enter (msg=0xc08c5574 "panic") at cpufunc.h:60 #10 0xc064f7a4 in panic (fmt=0xc08c7b77 "resource_list_release: resource entry is not busy") at /usr/src/sys/kern/kern_shutdown.c:547 #11 0xc06733b2 in resource_list_release (rl=0xc3c96204, bus=0xc3c46100, child=0xc3c92e00, type=3, rid=16, res=0xc3c6ce00) at /usr/src/sys/kern/subr_bus.c:2768 #12 0xc06734a7 in bus_generic_rl_release_resource (dev=0xc3c46100, child=0xc3c92e00, type=3, rid=16, r=0xc3c6ce00) at /usr/src/sys/kern/subr_bus.c:3319 #13 0xc0673057 in bus_release_resource (dev=0xc3c92e00, type=3, rid=16, r=0xc3c6ce00) at bus_if.h:347 #14 0xc04aad92 in ath_pci_detach (dev=0xc3c92e00) at /usr/src/sys/dev/ath/if_ath_pci.c:223 #15 0xc067166c in device_detach (dev=0xc3c92e00) at device_if.h:212 #16 0xc04c3cdd in cardbus_detach_card (cbdev=0xc3c46100) at /usr/src/sys/dev/cardbus/cardbus.c:236 #17 0xc0556dba in cbb_event_thread (arg=0xc3bb1000) at card_if.h:95 #18 0xc06302e8 in fork_exit (callout=0xc0556c60 , arg=0xc3bb1000, frame=0xe40bed38) at /usr/src/sys/kern/kern_fork.c:781 #19 0xc083c3e0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 (kgdb) Ganbold wrote: > Hi, > > I'm having trouble using Orinoco Silver a/b/g combo pcmcia card on > Dell Latitude D620. > > It happens in following order: > 1. First I reboot FreeBSD-7.0 laptop with Orinoco combo card plugged in. > 2. Then when I try to unplug the card it panics. > > However after rebooting (without plugged in card) > when I try to plug in and unplug the card everything is fine, no crash. > > System I have: > > devil# uname -an > FreeBSD devil.micom.mng.net 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #3: > Tue Feb 5 10:29:24 ULAT 2008 > tsgan@devil.micom.mng.net:/usr/obj/usr/src/sys/DEVIL i386 > > When panics, on the serial console it shows: > > .. > ath0: mem 0x88000000-0x8800ffff irq 18 at device 0.0 on > cardbus0 > ath0: [ITHREAD] > ath0: using obsoleted if_watchdog interface > ath0: Ethernet address: 00:20:a6:4f:bf:7d > ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 > .. > Tue Feb 5 11:52:45 ULAT 2008 > .. > panic: resource_list_release: resource entry is not busy > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c08c8051,e40bebb8,c064f78f,c08ec063,0,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08ec063,0,c08c7b57,e40bebc4,0,...) at kdb_backtrace+0x29 > panic(c08c7b57,3,10,0,c3c6ce40,...) at panic+0x10f > resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at > resource_list_release+0xc2 > bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at > bus_generic_rl_release_resource+0x77 > bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at > bus_release_resource+0x67 > ath_pci_detach(c3c92e00,c3b41050,c095ba2c,970,4,...) at > ath_pci_detach+0xb2 > device_detach(c3c92e00,e40becac,e40becb0,c09aacf0,0,...) at > device_detach+0x8c > cardbus_detach_card(c3c46100,c3b9c8b4,c091b07c,1df,c09ad260,...) at > cardbus_detach_card+0xcd > cbb_event_thread(c3bb1000,e40bed38,c08c1ad7,305,c3c40ab0,...) at > cbb_event_thread+0x15a > fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- > KDB: enter: panic > [thread pid 36 tid 100035 ] > Stopped at kdb_enter+0x32: leave > db> bt > Tracing pid 36 tid 100035 td 0xc3c2a210 > kdb_enter(c08c5554,0,c08c7b57,e40bebc4,0,...) at kdb_enter+0x32 > panic(c08c7b57,3,10,0,c3c6ce40,...) at panic+0x124 > resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at > resource_list_release+0xc2 > bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at > bus_generic_rl_release_resource+0x77 > bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at > bus_release_resource+0x67 > ath_pci_detach(c3c92e00,c3b41050,c095ba2c,970,4,...) at > ath_pci_detach+0xb2 > device_detach(c3c92e00,e40becac,e40becb0,c09aacf0,0,...) at > device_detach+0x8c > cardbus_detach_card(c3c46100,c3b9c8b4,c091b07c,1df,c09ad260,...) at > cardbus_detach_card+0xcd > cbb_event_thread(c3bb1000,e40bed38,c08c1ad7,305,c3c40ab0,...) at > cbb_event_thread+0x15a > fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- > db> tr > Tracing pid 36 tid 100035 td 0xc3c2a210 > kdb_enter(c08c5554,0,c08c7b57,e40bebc4,0,...) at kdb_enter+0x32 > panic(c08c7b57,3,10,0,c3c6ce40,...) at panic+0x124 > resource_list_release(c3c96204,c3c46100,c3c92e00,3,10,...) at > resource_list_release+0xc2 > bus_generic_rl_release_resource(c3c46100,c3c92e00,3,10,c3c6ce00) at > bus_generic_rl_release_resource+0x77 > bus_release_resource(c3c92e00,3,10,c3c6ce00,c3c92e00,...) at > bus_release_resource+0x67 > ath_pci_detach(c3c92e00,c3b41050,c095ba2c,970,4,...) at > ath_pci_detach+0xb2 > device_detach(c3c92e00,e40becac,e40becb0,c09aacf0,0,...) at > device_detach+0x8c > cardbus_detach_card(c3c46100,c3b9c8b4,c091b07c,1df,c09ad260,...) at > cardbus_detach_card+0xcd > cbb_event_thread(c3bb1000,e40bed38,c08c1ad7,305,c3c40ab0,...) at > cbb_event_thread+0x15a > fork_exit(c0556c60,c3bb1000,e40bed38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe40bed70, ebp = 0 --- > db> > > Any idea how to solve this problem? > > thanks, > > Ganbold > -- Hollerith, v: What thou doest when thy phone is on the fritzeth. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 06:38:11 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E3216A41A; Wed, 6 Feb 2008 06:38:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8B1DD13C45D; Wed, 6 Feb 2008 06:38:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m166cAfu037473; Wed, 6 Feb 2008 01:38:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.2/8.14.1) with ESMTP id m166cABg088272; Wed, 6 Feb 2008 01:38:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id A064D1B5078; Wed, 6 Feb 2008 01:38:10 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080206063810.A064D1B5078@freebsd-stable.sentex.ca> Date: Wed, 6 Feb 2008 01:38:10 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [releng_7 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 06:38:11 -0000 TB --- 2008-02-06 04:56:45 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-06 04:56:45 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2008-02-06 04:56:45 - cleaning the object tree TB --- 2008-02-06 04:57:08 - cvsupping the source tree TB --- 2008-02-06 04:57:08 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2008-02-06 04:57:17 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-06 04:57:17 - cd /src TB --- 2008-02-06 04:57:17 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 6 04:57:18 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Feb 6 06:25:19 UTC 2008 TB --- 2008-02-06 06:25:20 - generating LINT kernel config TB --- 2008-02-06 06:25:20 - cd /src/sys/amd64/conf TB --- 2008-02-06 06:25:20 - /usr/bin/make -B LINT TB --- 2008-02-06 06:25:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-06 06:25:20 - cd /src TB --- 2008-02-06 06:25:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 6 06:25:20 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue vers.c linking kernel hptrr_os_bsd.o(.data+0x0): multiple definition of `hpt_dbg_level' entry.o(.bss+0x0): first defined here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-06 06:38:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-06 06:38:10 - ERROR: failed to build lint kernel TB --- 2008-02-06 06:38:10 - tinderbox aborted TB --- 5119.45 user 545.54 system 6084.73 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 07:04:36 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4218C16A4A5; Wed, 6 Feb 2008 07:04:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 127A213C458; Wed, 6 Feb 2008 07:04:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m1674ZaI038209; Wed, 6 Feb 2008 02:04:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.2/8.14.1) with ESMTP id m1674ZNK039388; Wed, 6 Feb 2008 02:04:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id D209F1B5078; Wed, 6 Feb 2008 02:04:34 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080206070434.D209F1B5078@freebsd-stable.sentex.ca> Date: Wed, 6 Feb 2008 02:04:34 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [releng_7 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 07:04:36 -0000 TB --- 2008-02-06 05:47:15 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-06 05:47:15 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2008-02-06 05:47:15 - cleaning the object tree TB --- 2008-02-06 05:47:41 - cvsupping the source tree TB --- 2008-02-06 05:47:42 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2008-02-06 05:47:53 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-06 05:47:53 - cd /src TB --- 2008-02-06 05:47:53 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 6 05:47:54 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 6 06:50:00 UTC 2008 TB --- 2008-02-06 06:50:00 - generating LINT kernel config TB --- 2008-02-06 06:50:00 - cd /src/sys/i386/conf TB --- 2008-02-06 06:50:00 - /usr/bin/make -B LINT TB --- 2008-02-06 06:50:01 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-06 06:50:01 - cd /src TB --- 2008-02-06 06:50:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 6 06:50:01 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue vers.c linking kernel hptrr_os_bsd.o(.data+0x0): multiple definition of `hpt_dbg_level' entry.o(.bss+0x0): first defined here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-06 07:04:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-06 07:04:34 - ERROR: failed to build lint kernel TB --- 2008-02-06 07:04:34 - tinderbox aborted TB --- 3977.81 user 388.74 system 4639.51 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 09:31:08 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3189916A41A for ; Wed, 6 Feb 2008 09:31:08 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.185]) by mx1.freebsd.org (Postfix) with ESMTP id 0618A13C45A for ; Wed, 6 Feb 2008 09:31:07 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so2086937rvb.43 for ; Wed, 06 Feb 2008 01:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=2pUIsVoUvMoa0wlfSmxlyYXKpNt4MfwMTD8GA/oTbgw=; b=TiSYlDAYkhROd9zalSLM94Qw3W71YwqkSqQXImcsyu0sueqiIv8ZgIR4Oqy8xiYWlqKGtNp314Pf19QXU9ncz8Bm4UjaxMur1niwXEZW3P+i6p1znccU0NAKaHraiCtGIPLz59AKbctgenDm9tPMIMnpv43dfCcnIkB0i+iGnUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=KJvNcO8Iv8/5uYPKlA/JUSqxDNVB5wT+nr4Gccy/R8Pxj8+wxRL8gaqThVXSxtpwD/M1M2CxFGm2C8LUeOqFV6t+FInUNNtDl4/nvdvsSz+kas9FqqseJ9GbWv4BksqcbaOPyTjxJfOkiEojiBu2lFfiQ5/KRqgiiUiYWRL51ik= Received: by 10.141.141.3 with SMTP id t3mr392720rvn.213.1202290267590; Wed, 06 Feb 2008 01:31:07 -0800 (PST) Received: by 10.140.203.6 with HTTP; Wed, 6 Feb 2008 01:31:07 -0800 (PST) Message-ID: <55b8c6fe0802060131y6e0e27d8j4e7db10381c6bfab@mail.gmail.com> Date: Wed, 6 Feb 2008 09:31:07 +0000 From: "Primeroz lists" To: "Tom Samplonius" In-Reply-To: <28875927.5811202240277979.JavaMail.root@ly.sdf.com> MIME-Version: 1.0 References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <28875927.5811202240277979.JavaMail.root@ly.sdf.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 06 Feb 2008 09:31:08 -0000 Yes i agree with everything. Definetly mysql need to be tuned for InnoDB and in general . As stated in the previous post my a collegue of mine i had to install a new kernel to have a consistent crash coredump. Anyway still in my mind is that even if not tuned mysql should not cause my kernel to panic, i could expect a mysql crash or very very poor performance ... but the kernel panic leave me confused. I will post on this thread my coredump as soon as the server crash again (and it will) ... surely i will tune mysql then and see if and how much this helps. thanks On Feb 5, 2008 7:37 PM, Tom Samplonius wrote: > > ----- "Primeroz lists" wrote: > > Hi all, > > > > we are experiencing repeated crash on a Dell PowerEdge 2950 (rev 1 or > > 2). > > > > FBSD release is 6.2-RELEASE-p5 , AMD64. 2xXeon QuadCore and 8G of Ram. > > > > MySQL Version is 5.0.41 with following configuration settings: > > > > set-variable = key_buffer=768M > > set-variable = table_cache=800 > > set-variable = sort_buffer=24M > > set-variable = myisam_sort_buffer_size=256M > > set-variable = record_buffer=16M > > set-variable = max_allowed_packet=10M > > set-variable = thread_stack=128K > > set-variable = join_buffer=512M > > set-variable = max_heap_table_size=256M > > set-variable = max_connections=300 > > set-variable = tmp_table_size=384M > > set-variable = query_cache_size=402653184 > > set-variable = query_cache_limit=134217728 > > set-variable = read_rnd_buffer_size=10M > > set-variable = ft_min_word_len=1 > > pid-file = /var/db/mysqld.pid > > tmpdir = /var/tmp > > ft_stopword_file = '' > > set-variable = thread_cache_size=80 > > set-variable = myisam_stats_method=nulls_equal > > Also, myslq is not really well tuned. > > The query cache is a kludge. It is helpful, if you have stupid > application that issues the same query over and over again, even though the > database has not changed. If you don't have this problem, it just adds > overhead. And quite a lot, if it is big. Generally, the query cache should > be 20 to 100M at most, if not disabled. If you have a smart web application > (anything using memcached), the query cache should just be turned off. It > will actually be faster. > > You should give us much storage as possible to the database engine, for > it cache actual data, not query results. It is weird that you are > apparently are heavily using Innodb, but you have just set various myiasam > values? > > Here is something useful: > > http://www.joyeur.com/2007/09/25/quick-wins-with-mysql > > > Tom > > > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 10:30:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 363AC16A417 for ; Wed, 6 Feb 2008 10:30:06 +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 E2C6E13C447 for ; Wed, 6 Feb 2008 10:30:05 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JMhXW-0004Gg-TP for freebsd-stable@freebsd.org; Wed, 06 Feb 2008 10:30:02 +0000 Received: from sub87-230-112-155.he-dsl.de ([87.230.112.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Feb 2008 10:30:02 +0000 Received: from christian.baer by sub87-230-112-155.he-dsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Feb 2008 10:30:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Christian Baer Date: Wed, 6 Feb 2008 00:31:36 +0100 (CET) Organization: Convenimus Projekt Lines: 9 Message-ID: References: <20080205192802.GA22163@sunny.rz1.convenimus.net> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sub87-230-112-155.he-dsl.de User-Agent: slrn/0.9.8.1 (FreeBSD/6.3-STABLE (sparc64)) Sender: news Subject: Re: Did something change with DHCP? 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, 06 Feb 2008 10:30:06 -0000 On Tue, 5 Feb 2008 20:28:02 +0100 Christian Baer wrote: Greetings, people! Never mind about this thing. Problem was solved. I must have had a mental blackout today. Resetting the dhcp-leases did the trick. Regards Chris From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 10:47:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A09C416A418 for ; Wed, 6 Feb 2008 10:47:18 +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 251B813C459 for ; Wed, 6 Feb 2008 10:47:17 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JMhoC-00059J-3R for freebsd-stable@freebsd.org; Wed, 06 Feb 2008 10:47:16 +0000 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, 06 Feb 2008 10:47:16 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Feb 2008 10:47:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 06 Feb 2008 11:48:22 +0100 Lines: 74 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF0DA95586B0D03E7F532A293" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20071022) X-Enigmail-Version: 0.95.0 Sender: news Subject: finstall alpha3 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, 06 Feb 2008 10:47:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF0DA95586B0D03E7F532A293 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, As some of you may already know, I'm working on a graphical installer for FreeBSD 7, which was started as a Google SoC 2007 project but still continues. Usually I'd announce a new build on blogs.freebsdish.org but it's currently down and anyway maybe it's time for a wider exposure. The latest build can be found at http://ivoras.sharanet.org/stuff/freebsd7-finstall-alpha3.iso.bz2 with MD5 fingerprint of 4a11b172ed1c3030f530028a56f88ece. This is a i386 build as I don't have an amd64 development machine. Caveat! This is to be considered alpha-quality software. In particular, it still can't do any of the following things: - install on an already partitioned drive (so it's practically only usable for experimentation in VMWare and similar tools) - configure any of the more advanced features like RAID, X11 and sound - configure system locale & similar features On the other hand, here's what it *can* do currently: - it's a "live" CD environment, completely like an already installed FreeBSD system, only running from a read-only media (e.g. it's usable as a "FixIt" system) - it installs both the base system (7.0-RC1) and a pre-selected set of packages which includes X.Org 7.3, XFce desktop 4.4, Firefox and Thunderb= ird - supports UFS, UFS+gjournal, ZFS and Ext2 (only UFS has been well tested= ). - configure simple services like ssh, ntpdate, bsdstats For those who tried earlier versions, the major changes are: - several subtle bugs are fixed - implemented ZFS support with proper tuning in loader.conf - added bsdstats package in the default set I'd like to hear impressions and suggestions of potential users. Some of the obvious features (like install on a already partitioned drive) will be done in time for, or slightly after, 7.0 gets released (a rudimentary support for remote installs will also be present), some features (RAID) will almost certainly get done later. Anything other will require time and probably sponsorship. I'm also interested in possible contributions to the project. In particular, it needs many UI strings to be filled in (many of the text labels and help texts are only placeholders). Interested people should know how to use Subversion. The project is hosted on SourceForge at http://sourceforge.net/projects/finstall - Perforce was avoided to allow access to people without FreeBSD developer accounts. I'd like to thank Google for the SoC project funding, Murray Stokely who was the mentor during the SoC and many other people who have helped. --------------enigF0DA95586B0D03E7F532A293 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHqZB2ldnAQVacBcgRAuq7AKCTtMXpJtrlSMoWFoNJ/LK+DqREwwCgmg+X j+TzBoJAcox2PlrjJulJsOM= =w1XP -----END PGP SIGNATURE----- --------------enigF0DA95586B0D03E7F532A293-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 11:20:58 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 528CA16A41A for ; Wed, 6 Feb 2008 11:20:58 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id C091913C469 for ; Wed, 6 Feb 2008 11:20:57 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A5E27.dip.t-dialin.net [84.154.94.39]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id m16BKtmG021531; Wed, 6 Feb 2008 11:20:56 GMT (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m16BMwrn042793; Wed, 6 Feb 2008 12:22:59 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m16BMrBv079324; Wed, 6 Feb 2008 12:22:58 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200802061122.m16BMrBv079324@fire.js.berklix.net> To: Ivan Voras In-reply-to: References: Comments: In-reply-to Ivan Voras message dated "Wed, 06 Feb 2008 11:48:22 +0100." Date: Wed, 06 Feb 2008 12:22:53 +0100 From: "Julian H. Stacey" Cc: freebsd-stable@freebsd.org Subject: Re: finstall alpha3 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, 06 Feb 2008 11:20:58 -0000 Ivan Voras wrote: > As some of you may already know, I'm working on a graphical installer > for FreeBSD 7, which was started as a Google SoC 2007 project but still > continues. 10+ years back when Jordan did first pre= X, 24x80 graphical installer, soon afer he'd finished a blind chap posted ~So how do I install ?~ Answer then: ~Get a friend do it for you, or abandon FreeBSD & use NetBSD~ NetBSD still have Ascii installer, so more attractive to some. Idea for another SOC project : An automated tool that could descramble all the glitz of [arbitrary ?] graphics tools back to something sensible / Ascii, a bit like what OCR does for printed paper. No doubt a bew grraphical installer might be nice (if X is reliable which it often is Not, & don't rely on VESA either on old hardware), but just so's we don't forget blind too, amazingly they use computers (with expensive interfaces). Also visually impaired do too, the later simply with simple text xterms with Monster fonts, rather than graphics I presume. -- Julian Stacey. BSD Unix Linux Net Consultant, Munich. http://berklix.com From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 11:44:12 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCA6B16A418 for ; Wed, 6 Feb 2008 11:44:12 +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 578C513C442 for ; Wed, 6 Feb 2008 11:44:11 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JMihA-0007q6-Fw for freebsd-stable@freebsd.org; Wed, 06 Feb 2008 11:44:04 +0000 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, 06 Feb 2008 11:44:04 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Feb 2008 11:44:04 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 06 Feb 2008 12:45:09 +0100 Lines: 47 Message-ID: References: <200802061122.m16BMrBv079324@fire.js.berklix.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE5575292F7931118516FA4FE" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20071022) In-Reply-To: <200802061122.m16BMrBv079324@fire.js.berklix.net> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: finstall alpha3 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, 06 Feb 2008 11:44:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5575292F7931118516FA4FE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Julian H. Stacey wrote: > Ivan Voras wrote: >> As some of you may already know, I'm working on a graphical installer >> for FreeBSD 7, which was started as a Google SoC 2007 project but stil= l >> continues.=20 >=20 > 10+ years back when Jordan did first pre=3D X, 24x80 graphical installe= r, > soon afer he'd finished a blind chap posted ~So how do I install ?~ > Answer then: ~Get a friend do it for you, or abandon FreeBSD & use NetB= SD~ Good advice, in a BOFH kind of way :) The "installer" is actually separated into a front-end (GUI) and the back-end, with the idea that both be interchangeable. In the long term, someone may write a text-based front-end, if it is needed. The actual usability of finstall will come with the more advanced features, like configuring GEOM RAID, etc. Even now it can set up UFS+gjournal or ZFS file systems for users who want it. It will not replace sysinstall immediately, but it might, given time. I hope to preach about it on BSDCan :) --------------enigE5575292F7931118516FA4FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHqZ3FldnAQVacBcgRAvkXAKC0m4ZFRvYyoMUd+ZzAahKBofXOkQCcCsgP DWFcrfCgWrnT4RwNNQbdhU4= =zm8T -----END PGP SIGNATURE----- --------------enigE5575292F7931118516FA4FE-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 12:08:31 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E261F16A417; Wed, 6 Feb 2008 12:08:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9FD13C448; Wed, 6 Feb 2008 12:08:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.2/8.14.2) with ESMTP id m16C8UHq049673; Wed, 6 Feb 2008 07:08:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp1.sentex.ca (8.14.2/8.14.1) with ESMTP id m16C8UNg044626; Wed, 6 Feb 2008 07:08:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 97E431B5078; Wed, 6 Feb 2008 07:08:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080206120830.97E431B5078@freebsd-stable.sentex.ca> Date: Wed, 6 Feb 2008 07:08:30 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [releng_7_0 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 12:08:32 -0000 TB --- 2008-02-06 10:50:01 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-06 10:50:01 - starting RELENG_7_0 tinderbox run for i386/i386 TB --- 2008-02-06 10:50:01 - cleaning the object tree TB --- 2008-02-06 10:50:30 - cvsupping the source tree TB --- 2008-02-06 10:50:30 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7_0/i386/i386/supfile TB --- 2008-02-06 10:50:40 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-06 10:50:40 - cd /src TB --- 2008-02-06 10:50:40 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 6 10:50:41 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 6 11:53:41 UTC 2008 TB --- 2008-02-06 11:53:41 - generating LINT kernel config TB --- 2008-02-06 11:53:41 - cd /src/sys/i386/conf TB --- 2008-02-06 11:53:41 - /usr/bin/make -B LINT TB --- 2008-02-06 11:53:42 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-06 11:53:42 - cd /src TB --- 2008-02-06 11:53:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 6 11:53:42 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue vers.c linking kernel hptrr_os_bsd.o(.data+0x0): multiple definition of `hpt_dbg_level' entry.o(.bss+0x0): first defined here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-06 12:08:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-06 12:08:30 - ERROR: failed to build lint kernel TB --- 2008-02-06 12:08:30 - tinderbox aborted TB --- 3976.78 user 392.48 system 4709.47 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7_0-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 12:31:08 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C189B16A417; Wed, 6 Feb 2008 12:31:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6975413C4D5; Wed, 6 Feb 2008 12:31:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.14.2/8.14.2) with ESMTP id m16CV79K081484; Wed, 6 Feb 2008 07:31:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [64.7.128.103]) by smtp2.sentex.ca (8.14.2/8.14.1) with ESMTP id m16CV7df084457; Wed, 6 Feb 2008 07:31:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-stable.sentex.ca (Postfix, from userid 666) id 155D31B5078; Wed, 6 Feb 2008 07:31:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20080206123107.155D31B5078@freebsd-stable.sentex.ca> Date: Wed, 6 Feb 2008 07:31:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.92, clamav-milter version 0.92 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [releng_7_0 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 12:31:09 -0000 TB --- 2008-02-06 10:50:01 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-06 10:50:01 - starting RELENG_7_0 tinderbox run for amd64/amd64 TB --- 2008-02-06 10:50:01 - cleaning the object tree TB --- 2008-02-06 10:50:34 - cvsupping the source tree TB --- 2008-02-06 10:50:34 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7_0/amd64/amd64/supfile TB --- 2008-02-06 10:50:42 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-06 10:50:42 - cd /src TB --- 2008-02-06 10:50:42 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 6 10:50:43 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Feb 6 12:18:04 UTC 2008 TB --- 2008-02-06 12:18:04 - generating LINT kernel config TB --- 2008-02-06 12:18:04 - cd /src/sys/amd64/conf TB --- 2008-02-06 12:18:04 - /usr/bin/make -B LINT TB --- 2008-02-06 12:18:04 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-02-06 12:18:04 - cd /src TB --- 2008-02-06 12:18:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 6 12:18:04 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue vers.c linking kernel hptrr_os_bsd.o(.data+0x0): multiple definition of `hpt_dbg_level' entry.o(.bss+0x0): first defined here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-06 12:31:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-06 12:31:07 - ERROR: failed to build lint kernel TB --- 2008-02-06 12:31:07 - tinderbox aborted TB --- 5117.09 user 551.29 system 6066.05 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7_0-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 14:26:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D5ED16A417 for ; Wed, 6 Feb 2008 14:26:02 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (unknown [IPv6:2001:41d0:1:2ad2::1]) by mx1.freebsd.org (Postfix) with ESMTP id EFE6E13C4F5 for ; Wed, 6 Feb 2008 14:26:01 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:1:2ad2::fffe:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTP id DF14D1BAC2E for ; Wed, 6 Feb 2008 15:26:00 +0100 (CET) Received: from morzine.restart.bel (morzine6.restart.bel [IPv6:2001:41d0:1:2ad2::1:2]) (authenticated bits=0) by restart.be (8.14.2/8.14.2) with ESMTP id m16EPvCF086201 for ; Wed, 6 Feb 2008 15:25:57 +0100 (CET) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1202307960; bh=PKg9QvVFFPZ6xxaAA1O7WkdOXw2VIwxMVwVnM5Y btFg=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-Scanned-By; b=HTQDKfBQ8CI 7xab4RjWJWDwRIfeSlRclmoGBwZHB+RV2BnizDOdRbjFQg8nx+ZIh/9VS+J2PHHu9dl xr0Yd1GA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=uAuuZm5mVyq8AIu1eKg3decpsct+JIqGMCXLVSiyQRxmhXx007+5Js8L/plwOJOiE VEL64ylFf1+EoR8+aAeTg== Message-ID: <47A9C375.8020805@restart.be> Date: Wed, 06 Feb 2008 15:25:57 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.9 (X11/20080124) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <200802061122.m16BMrBv079324@fire.js.berklix.net> In-Reply-To: <200802061122.m16BMrBv079324@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on IPv6:2001:41d0:1:2ad2::1:1 Subject: Re: finstall alpha3 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, 06 Feb 2008 14:26:02 -0000 Julian H. Stacey wrote: > Ivan Voras wrote: >> As some of you may already know, I'm working on a graphical installer >> for FreeBSD 7, which was started as a Google SoC 2007 project but still >> continues. > > 10+ years back when Jordan did first pre= X, 24x80 graphical installer, > soon afer he'd finished a blind chap posted ~So how do I install ?~ > Answer then: ~Get a friend do it for you, or abandon FreeBSD & use NetBSD~ > > NetBSD still have Ascii installer, so more attractive to some. Idea > for another SOC project : An automated tool that could descramble > all the glitz of [arbitrary ?] graphics tools back to something > sensible / Ascii, a bit like what OCR does for printed paper. > > No doubt a bew grraphical installer might be nice (if X is reliable > which it often is Not, & don't rely on VESA either on old hardware), > but just so's we don't forget blind too, amazingly they > use computers (with expensive interfaces). > > Also visually impaired do too, the later simply with simple text > xterms with Monster fonts, rather than graphics I presume. > Just my opinion: Maybe you are great BUT YOU ARE TOOOOO DEROGATORY about a work witch may be usefull to some new users!!!! Henri From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 15:17:59 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65E6A16A417 for ; Wed, 6 Feb 2008 15:17:59 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id BE31213C45E for ; Wed, 6 Feb 2008 15:17:58 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m16FHsSX067365; Wed, 6 Feb 2008 16:17:54 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m16FHslq067364; Wed, 6 Feb 2008 16:17:54 +0100 (CET) (envelope-from olli) Date: Wed, 6 Feb 2008 16:17:54 +0100 (CET) Message-Id: <200802061517.m16FHslq067364@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, jhs@berklix.org In-Reply-To: <200801261540.m0QFepNs021618@fire.js.berklix.net> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 06 Feb 2008 16:17:55 +0100 (CET) Cc: Subject: Re: dmesg : no output on 1 of 2 7-stable boxes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, jhs@berklix.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2008 15:17:59 -0000 Hello Julian, I'm sorry this is a late reply, but I noticed your post on the freebsd-stable list just now. Julian H. Stacey wrote: > One of 2 laptops running 7-stable shows nothing with dmesg, (other is OK). Did you try "dmesg -a"? The dmesg buffer is a circular buffer containing both kernel output and console output. However, "dmesg" displays only the kernel output. If there was lots of console output, it filled all of the dmesg buffer, so "dmesg" displays nothing (all of the kernel output was overwritten by console output). "dmesg -a" will display everything, i.e. kernel + console output. If "dmesg -a" doesn't print anything either, I'm afraid I have no idea what might be wrong. Well, you could try "sysctl -b kern.msgbuf" which will retrieve the raw contents of the dmesg buffer. > - I tried loader.conf kern.msgbuf=64000 I think it must be a multiple of the pages size, i,e, 4K = 4096 on FreeBSD/i386. I usually set it to 65536 or 131072. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 17:08:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13E1216A417 for ; Wed, 6 Feb 2008 17:08:11 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 7D51C13C461 for ; Wed, 6 Feb 2008 17:08:10 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A68D7.dip.t-dialin.net [84.154.104.215]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id m16H88Qu023152 for ; Wed, 6 Feb 2008 17:08:09 GMT (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m16H9MPs004930 for ; Wed, 6 Feb 2008 18:09:22 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m16H9Hnc008537 for ; Wed, 6 Feb 2008 18:09:22 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200802061709.m16H9Hnc008537@fire.js.berklix.net> To: freebsd-stable@freebsd.org From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Wed, 06 Feb 2008 15:25:57 +0100." <47A9C375.8020805@restart.be> Date: Wed, 06 Feb 2008 18:09:17 +0100 Sender: jhs@berklix.org Subject: Re: finstall alpha3 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, 06 Feb 2008 17:08:11 -0000 Henri Hennebert wrote 2 emails with same common text To: "Julian H. Stacey" Date: Wed, 06 Feb 2008 15:20:38 +0100 Message-ID: <47A9C236.8040805@restart.be> The first private shouting got answered. Then came To: freebsd-stable@freebsd.org Date: Wed, 06 Feb 2008 15:25:57 +0100 Message-id: <47A9C375.8020805@restart.be> Assume Henri is too young to remember first graphical installer. Though a new graphical installer may be very nice as an option, let it not ever be the only way: Remember blind installers, non VESA supported consoles, non X recognised chips, serial line controlled installs, & non intel/AMD platforms with broken graphics terminal support. (Sparc maybe ? more later ?) -- Julian Stacey. BSD Unix Linux Net Consultant, Munich. http://berklix.com From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 18:33:57 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3CC316A420 for ; Wed, 6 Feb 2008 18:33:56 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 97B7F13C46A for ; Wed, 6 Feb 2008 18:33:56 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 81DE8405C67 for ; Wed, 6 Feb 2008 19:11:02 +0100 (CET) Message-ID: <47A9F835.1060200@bsdforen.de> Date: Wed, 06 Feb 2008 19:11:01 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: RELENG_7: interrupt eating whole cpu core 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, 06 Feb 2008 18:33:57 -0000 While ripping DVDs the irq14: ata0 eats ~95% of one of my cores. The channel is exclusive to the drive. # atacontrol list 64 /root ATA channel 0: Master: acd0 ATA/ATAPI revision 7 Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 Serial ATA v1.0 Slave: no device present ATA channel 3: Master: no device present Slave: no device present ATA channel 4: Master: no device present Slave: no device present The number of interrupts looks reasonable to me. # vmstat -i 0 /root interrupt total rate irq1: atkbd0 35171 1 irq9: acpi0 15729 0 irq12: psm0 10004 0 irq14: ata0 5148195 272 irq16: pcm0 uhci0 40783 2 irq17: uhci1+ 1446238 76 irq18: bge0 ehci0+ 38588 2 irq20: uhci2 ehci1 125447 6 irq21: uhci3 156783 8 cpu0: timer 37792079 1999 cpu1: timer 37784062 1999 Total 82593079 4370 I'm currently rebuilding world+kernel. I will report weather the behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone thinks it might be helpful, I can supply you with a dmesg and the output of pciconf -lv. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 19:12:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 492D016A41B for ; Wed, 6 Feb 2008 19:12:24 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id DF2FE13C46A for ; Wed, 6 Feb 2008 19:12:23 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id BCF22405C67 for ; Wed, 6 Feb 2008 20:12:22 +0100 (CET) Message-ID: <47AA0696.5020109@bsdforen.de> Date: Wed, 06 Feb 2008 20:12:22 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <47A9F835.1060200@bsdforen.de> In-Reply-To: <47A9F835.1060200@bsdforen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 06 Feb 2008 19:12:24 -0000 Dominic Fandrey wrote: > While ripping DVDs the irq14: ata0 eats ~95% of one of my cores. The > channel is exclusive to the drive. > > ... > > behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone thinks > it might be helpful, I can supply you with a dmesg and the output of > pciconf -lv. The problem remains with fresh sources: PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 12 root 1 171 ki31 0K 16K RUN 0 22:04 97.85% idle: cpu0 37 root 1 -64 - 0K 16K CPU1 1 2:35 96.00% irq14: ata0 11 root 1 171 ki31 0K 16K RUN 1 19:32 6.40% idle: cpu1 The rip is done by k3b, so the drive is accessed through the cam interface. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 19:21:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9073616A46C for ; Wed, 6 Feb 2008 19:21:30 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id 5A32713C44B for ; Wed, 6 Feb 2008 19:21:30 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 3229B205EDAF; Wed, 6 Feb 2008 11:21:30 -0800 (PST) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Mail Security) with ESMTP id 1EF2028083; Wed, 6 Feb 2008 11:21:30 -0800 (PST) X-AuditID: 1180711d-9d3edbb000001e9b-85-47aa08bab324 Received: from cswiger1.apple.com (cswiger1.apple.com [17.214.13.96]) by relay13.apple.com (Apple SCV relay) with ESMTP id F095528082; Wed, 6 Feb 2008 11:21:29 -0800 (PST) Message-Id: <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> From: Chuck Swiger To: Dominic Fandrey In-Reply-To: <47AA0696.5020109@bsdforen.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 6 Feb 2008 11:21:29 -0800 References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> X-Mailer: Apple Mail (2.915) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 06 Feb 2008 19:21:30 -0000 Hi, Dominic-- On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote: >> behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone >> thinks it might be helpful, I can supply you with a dmesg and the >> output of pciconf -lv. > > The problem remains with fresh sources: > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU > COMMAND > 12 root 1 171 ki31 0K 16K RUN 0 22:04 97.85% > idle: cpu0 > 37 root 1 -64 - 0K 16K CPU1 1 2:35 96.00% > irq14: ata0 > 11 root 1 171 ki31 0K 16K RUN 1 19:32 6.40% > idle: cpu1 > > The rip is done by k3b, so the drive is accessed through the cam > interface. What are the values being reported by "sysctl hw.ata"? If you're going to be burning CD/DVDs, you really want to make sure hw.ata.atapi_dma is on. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 19:45:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3474316A418 for ; Wed, 6 Feb 2008 19:45:05 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id C49FD13C465 for ; Wed, 6 Feb 2008 19:45:04 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 8188F405C67; Wed, 6 Feb 2008 20:45:03 +0100 (CET) Message-ID: <47AA0E3E.4020304@bsdforen.de> Date: Wed, 06 Feb 2008 20:45:02 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Chuck Swiger References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> In-Reply-To: <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 06 Feb 2008 19:45:05 -0000 Chuck Swiger wrote: > Hi, Dominic-- > > On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote: >>> behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone >>> thinks it might be helpful, I can supply you with a dmesg and the >>> output of pciconf -lv. >> >> The problem remains with fresh sources: >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND >> 12 root 1 171 ki31 0K 16K RUN 0 22:04 97.85% >> idle: cpu0 >> 37 root 1 -64 - 0K 16K CPU1 1 2:35 96.00% >> irq14: ata0 >> 11 root 1 171 ki31 0K 16K RUN 1 19:32 6.40% >> idle: cpu1 >> >> The rip is done by k3b, so the drive is accessed through the cam >> interface. > > What are the values being reported by "sysctl hw.ata"? If you're going > to be burning CD/DVDs, you really want to make sure hw.ata.atapi_dma is on. I cannot believe it was so trivial. The sysctl looks all right. # sysctl hw.ata 0 /root hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma: 1 But further research revealed: # atacontrol mode acd0 0 /root current mode = PIO4 # atacontrol mode acd0 udma33 0 /root changed the load dramatically: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 16K RUN 0 52:54 100.00% idle: cpu0 11 root 1 171 ki31 0K 16K CPU1 1 23:36 94.29% idle: cpu1 1087 kamikaze 3 -8 0 133M 36168K physrd 1 1:09 3.17% k3b 37 root 1 -64 - 0K 16K WAIT 1 30:10 0.00% irq14: ata0 Thank you very much! I used to think that UDMA33 was the default for CD-/DVD-Rom drives. I suppose I should review the BIOS settings or change something in the hints file. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 20:05:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3D7F16A420 for ; Wed, 6 Feb 2008 20:05:11 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (unknown [IPv6:2001:41d0:1:2ad2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0EB1B13C4D3 for ; Wed, 6 Feb 2008 20:05:11 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:1:2ad2::fffe:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTP id 87E241BAC2E; Wed, 6 Feb 2008 21:05:10 +0100 (CET) Received: from morzine.restart.bel (morzine6.restart.bel [IPv6:2001:41d0:1:2ad2::1:2]) (authenticated bits=0) by restart.be (8.14.2/8.14.2) with ESMTP id m16K5685087074; Wed, 6 Feb 2008 21:05:06 +0100 (CET) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1202328309; bh=+UhvIjkjMYrKjMZInV26r5EbeywQ4+4pt3LPqjo YX48=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-Scanned-By; b=uxVpWr2kPjj lYuKoh7be3cbDx2Y15FAz3Cjqt2Ozdbltp+o0MNKt4m8Nert4rwUQN0yGucAa/jQO5v CWaf5yRQ== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=weukyq/bZzeddWgg2DYvmT7GKXrAUyml39SnQYaWjIsJRrZCCE2wISWIFfdbTlQ05 JWaCIPp0UjfrSZDCxQzjQ== Message-ID: <47AA12F2.1000905@restart.be> Date: Wed, 06 Feb 2008 21:05:06 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.9 (X11/20080124) MIME-Version: 1.0 To: Julian Stacey References: <200802061709.m16H9Hnc008537@fire.js.berklix.net> In-Reply-To: <200802061709.m16H9Hnc008537@fire.js.berklix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on IPv6:2001:41d0:1:2ad2::1:1 Cc: freebsd-stable@freebsd.org Subject: Re: finstall alpha3 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, 06 Feb 2008 20:05:11 -0000 Julian Stacey wrote: > Henri Hennebert wrote 2 emails with same common text > To: "Julian H. Stacey" > Date: Wed, 06 Feb 2008 15:20:38 +0100 > Message-ID: <47A9C236.8040805@restart.be> > The first private shouting got answered. Then came > To: freebsd-stable@freebsd.org > Date: Wed, 06 Feb 2008 15:25:57 +0100 > Message-id: <47A9C375.8020805@restart.be> > Assume Henri is too young to remember first graphical installer. Thank you! I'm 60 this year :-) and using FreeBSD since 2.1. Xenix since 88 IIRC. My point is that a graphical installer may be usefull, that's all. > > Though a new graphical installer may be very nice as an option, > let it not ever be the only way: Remember blind installers, > non VESA supported consoles, non X recognised chips, serial line > controlled installs, & non intel/AMD platforms with broken > graphics terminal support. (Sparc maybe ? more later ?) > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 20:30:09 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D8D416A41B for ; Wed, 6 Feb 2008 20:30:09 +0000 (UTC) (envelope-from uspoerlein@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 D074B13C43E for ; Wed, 6 Feb 2008 20:30:08 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so886503nfb.33 for ; Wed, 06 Feb 2008 12:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=onOf1I+CaHC9q2a+oJRynNKAi9xgvuzPFYdlbXnO+8c=; b=e1CVrab2PRPoIOiItvB6Hl4lV+rwG6/Mvein/57KRB1M7/aYT+9nJA9RIkKnY49M6Dl8nu4hEoy1SCEsm7dRTxglZfXZg68of/shmKDlu//Y5cfCeWorNzI9ElhoI65PncbJAX0EJTYmbxwvP60k0AC69J1KmXkx14lCaltaRNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=QLUkaELA6UWYPB5ua0D/GKm8RlA3xSIH4JxqHc8Xde21l8xBXjHZSLBdfPIOgacsO2xJMmYBXBMw6ydCG6vYZ7BlQjT1QI0/X/h1QbBE+kSkaK0/MWJErUQnW6JANfOcRoVAC7/nLQDlokggZm2sCf+PW9RYfoZBmGUIlt6KOpc= Received: by 10.78.204.20 with SMTP id b20mr18524644hug.33.1202328263735; Wed, 06 Feb 2008 12:04:23 -0800 (PST) Received: by 10.78.173.4 with HTTP; Wed, 6 Feb 2008 12:04:23 -0800 (PST) Message-ID: <7ad7ddd90802061204p35d0368ekbb54149287618f6a@mail.gmail.com> Date: Wed, 6 Feb 2008 21:04:23 +0100 From: "Ulrich Spoerlein" To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Reconstruct disklabel for UFS and GELI volumes 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, 06 Feb 2008 20:30:09 -0000 Hi, Somehow[TM] an installation of 4.11 to ad0s3 managed to wipe out my existing disklabel for 7.0 on ad0s4. I now need to recover the disklabel to get my system to boot! There were three labels - ad0s4a: UFS, exact size unknown. Is it possible to infer this from the UFS partition size? I can mount this already, as I simply wrote an 'a' label of maximum size to the disklabel - ad0s4b: GELI encrypted swap - ad0s4d: GELI encrypted ZVOL I only need to find out the start of ad0s4d. Is the consumer size of an GELI device stored in the last 512 bytes metadata? Or are there some magic bytes in this 512 bytes so I could find out the exact end of ad0s4b and thus the start of ad0s4d? Any help or advice would be highly appreciated! Thanks, Uli From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 21:03:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B669516A421 for ; Wed, 6 Feb 2008 21:03:50 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 0F81E13C4D1 for ; Wed, 6 Feb 2008 21:03:49 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A3D56.dip.t-dialin.net [84.154.61.86]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id m16L3lF2024356; Wed, 6 Feb 2008 21:03:48 GMT (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m16L57BX006982; Wed, 6 Feb 2008 22:05:07 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m16L4qSH013410; Wed, 6 Feb 2008 22:05:02 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200802062105.m16L4qSH013410@fire.js.berklix.net> To: Henri Hennebert In-reply-to: <47AA12F2.1000905@restart.be> References: <200802061709.m16H9Hnc008537@fire.js.berklix.net> <47AA12F2.1000905@restart.be> Comments: In-reply-to Henri Hennebert message dated "Wed, 06 Feb 2008 21:05:06 +0100." Date: Wed, 06 Feb 2008 22:04:52 +0100 From: "Julian H. Stacey" Cc: freebsd-stable@freebsd.org Subject: Re: finstall alpha3 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, 06 Feb 2008 21:03:50 -0000 Henri Hennebert wrote: > Julian Stacey wrote: > > Henri Hennebert wrote 2 emails with same common text > > To: "Julian H. Stacey" > > Date: Wed, 06 Feb 2008 15:20:38 +0100 > > Message-ID: <47A9C236.8040805@restart.be> > > The first private shouting got answered. Then came > > To: freebsd-stable@freebsd.org > > Date: Wed, 06 Feb 2008 15:25:57 +0100 > > Message-id: <47A9C375.8020805@restart.be> > > Assume Henri is too young to remember first graphical installer. > > Thank you! I'm 60 this year :-) and using FreeBSD since 2.1. Xenix since > 88 IIRC. My point is that a graphical installer may be usefull, that's > all. Chuckle :-) Looks like we reach agreement :-)) -- Julian Stacey. BSD Unix Linux Net Consultant, Munich. http://berklix.com From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 23:05:35 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4112D16A419 for ; Wed, 6 Feb 2008 23:05:35 +0000 (UTC) (envelope-from mattboll@penia.org) Received: from penia.org (penia.org [82.228.156.113]) by mx1.freebsd.org (Postfix) with ESMTP id E89B913C478 for ; Wed, 6 Feb 2008 23:05:34 +0000 (UTC) (envelope-from mattboll@penia.org) Received: from [192.168.0.3] (unknown [192.168.0.3]) by penia.org (Postfix) with ESMTP id B16A1660E for ; Wed, 6 Feb 2008 23:48:39 +0100 (CET) From: Matthieu Bollot To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Wed, 06 Feb 2008 22:48:56 +0100 Message-Id: <1202334536.6146.10.camel@sarah.penia.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: synaptics 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: Wed, 06 Feb 2008 23:05:35 -0000 Hi, I've recently installed FreeBSD 6.3, and I've got a problem with synaptics. I've installed it, followed the pkg-message : hw.psm.synaptics_support=1 It works, dmesg gives : psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0 moused_enable="NO" ps shows me that moused doesn't run. xorg.conf : InputDevice "Synaptics_Touchpad" "CorePointer" ... Section "InputDevice" Identifier "Synaptics_Touchpad" Driver "synaptics" Option "Device" "/dev/psm0" Option "Protocol" "psm" ... And here is a part of Xorg.log : (WW) : No Device specified, looking for one... (II) : Setting Device option to "/dev/psm0" (--) : Device: "/dev/psm0" (==) : Protocol: "Auto" ... Synaptics DeviceInit called SynapticsCtrl called. (II) : SetupAuto: hw.iftype is 3, hw.model is 13 (II) : SetupAuto: protocol is SysMouse (WW) fcntl(15, O_ASYNC): Inappropriate ioctl for device Synaptics DeviceOn called (EE) xf86OpenSerial: Cannot open device /dev/psm0 Device busy. (WW) Synaptics_Touchpad: cannot open input device couldn't enable device 3 Protocol isn't psm, why ? Can I force it ? /dev/psm0 isn't used or it is used by Xorg (I saw it with fstat) any idea ? I didn't had this problem with 6.2 but may be I wasn't up to date with xorg. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 6 23:27:19 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 096EC16A420 for ; Wed, 6 Feb 2008 23:27:19 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from mindcrime.bit0.com (bit0.com [207.246.88.211]) by mx1.freebsd.org (Postfix) with ESMTP id 9F70A13C45E for ; Wed, 6 Feb 2008 23:27:18 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from localhost (localhost [127.0.0.1]) by mindcrime.bit0.com (Postfix) with ESMTP id 791801E33DB; Wed, 6 Feb 2008 18:27:17 -0500 (EST) X-Virus-Scanned: amavisd-new at bit0.com Received: from mindcrime.bit0.com ([127.0.0.1]) by localhost (mindcrime.int.bit0.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-+IvE+UozYq; Wed, 6 Feb 2008 18:27:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mindcrime.bit0.com (Postfix) with ESMTP; Wed, 6 Feb 2008 18:27:14 -0500 (EST) Date: Wed, 6 Feb 2008 18:27:14 -0500 (EST) From: Mike Andrews X-X-Sender: mandrews@mindcrime.int.bit0.com To: Dan Nelson In-Reply-To: <20080205192830.GB17472@dan.emsphone.com> Message-ID: <20080206181744.J36631@mindcrime.int.bit0.com> References: <20080204230945.J49853@mindcrime.int.bit0.com> <20080205192830.GB17472@dan.emsphone.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: mount -p and NFS 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: Wed, 06 Feb 2008 23:27:19 -0000 On Tue, 5 Feb 2008, Dan Nelson wrote: > In the last episode (Feb 04), Mike Andrews said: >> Is there anything like "mount -p" that will print the current NFS >> options in use? TCP vs UDP, v2 vs v3, read/write sizes etc. It >> doesn't have to be in fstab format; I just need to be able to see >> what the flags are for an active mount. >> >> This would be useful in tracking down an irritating NFS problem I've >> been experiencing with diskless systems in every 6.x release and >> 7.0-RC1, namely libc.so.6 appears to be truncated or corrupt to the >> client at somewhat random times... I think it may be related to >> mount options, hence the question. > > Theoretically, any filesystem that uses nmount(2) should have its > options recored in an easy-to-extract format, since one of the > arguments to nmount is an array of options. I patched my kernel and > /sbin/mount binary to do this (borrowing the f_charspare field in > struct statfs), and it mostly works. The stuff below in <> brackets > are from the options array. You can see that cd9660 was mounted with > the option "ssector=0": > [snip] > Unfortunately, mount_nfs simply calls nmount with a single "nfs_args" > option whose value is the same binary "struct nfs_args" it used to call > mount(2) with :( The fix would be to make nfs_vfsops.c and mount_nfs.c > use the options array instead of a custom struct, but > nfs_vfsops.c:nfs_decode_args scares me off every time I look at it. Hm. Well, that's a bummer. But it at least told me where to hack in some temporary printf() calls, and that helped me narrow my immediate problem down to the rsize/wsize parameters. My problem was, on a diskless 7.0-RC1 system, trying to compile anything resulted in ld SIGSEGV'ing. With diskless 6.3 ld said that libc.so.6 was truncated. ktrace hinted that 7.0's ld crash was right after reading libc.so.7 so it's probably the same issue -- problems reading libc. The problem goes away if I change rsize/wsize from 32K down to 16K or the default 8K, at least with TCP mounts. So for now in /boot/loader.conf I'm using boot.nfsroot.options="nfsv3 tcp rsize=8192 wsize=8192". (NFS options for the root filesystem in fstab seem to be ignored.) I don't know why it was libc consistently getting misread and why other files seem to always work, or why mounting other NFS filesystems with a 32K blocksize work fine... unless I'm hitting some edge case that's specific to NFS root vs NFS anything-else. Anyway, I've got a workaround for now. (FWIW, this happened with two different machines, one with an msk NIC and one with an em NIC, neither of which have jumbo frames enabled.) From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 00:05:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A04016A417 for ; Thu, 7 Feb 2008 00:05:05 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.freebsd.org (Postfix) with ESMTP id D76D913C45E for ; Thu, 7 Feb 2008 00:05:04 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0JVU00HL6DKFCAA0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 07 Feb 2008 01:05:03 +0100 (CET) Received: from kg-work.kg4.no ([80.202.173.59]) by osl1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0JVU008UXDKEZK12@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 07 Feb 2008 01:05:03 +0100 (CET) Date: Thu, 07 Feb 2008 01:05:02 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20080207010502.3f96fd3f.torfinn.ingolfsen@broadpark.no> In-reply-to: <7ad7ddd90802061204p35d0368ekbb54149287618f6a@mail.gmail.com> References: <7ad7ddd90802061204p35d0368ekbb54149287618f6a@mail.gmail.com> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; i386-portbld-freebsd6.3) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: Reconstruct disklabel for UFS and GELI volumes 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, 07 Feb 2008 00:05:05 -0000 On Wed, 06 Feb 2008 21:04:23 +0100 Ulrich Spoerlein wrote: > There were three labels Actually, it is one label per slice, unless you are doing something unusual? > - ad0s4a: UFS, exact size unknown. Is it possible to infer this from > the UFS partition size? I can mount this already, as I simply wrote an > 'a' label of maximum size to the disklabel > - ad0s4b: GELI encrypted swap > - ad0s4d: GELI encrypted ZVOL These are partitions in BSD-speak. > Any help or advice would be highly appreciated! FWIW, I have had success with scan_ffs[1] as documented in this short article[2]. It will recover lost labels, or at least try to. If you are downloading binary packages from somewhere, be sure to double check that you get the one that fits your platform (i386 / amd64 or whatever) and version. Take it slowly, and double check all steps before comitting anything. Good luck! References: 1) http://www.freshports.org/sysutils/scan_ffs/ 2) http://geekinfo.net/article.php?story=20071224175132586 -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 00:19:26 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B6CB16A417 for ; Thu, 7 Feb 2008 00:19:26 +0000 (UTC) (envelope-from nikola.lecic@anthesphoria.net) Received: from anthesphoria.net (anthesphoria.net [200.46.204.219]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA9E13C45A for ; Thu, 7 Feb 2008 00:19:25 +0000 (UTC) (envelope-from nikola.lecic@anthesphoria.net) X-Bogosity: No, tests=bogofilter X-DKIM: Sendmail DKIM Filter v2.4.1 anthesphoria.net m16Ntdan054611 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anthesphoria.net; s=phero; t=1202342149; bh=JG9NsjPnVhYGGsyG49qFzSZSkIkLIkWiCzhAy0+XR kQ=; l=1968; h=X-Bogosity:Date:From:To:Cc:Subject:Message-ID: In-Reply-To:References:X-Mailer:X-Face:X-Operating-System: X-OpenPGP-Fingerprint:X-OpenPGP-Preferred-Keyserver:Mime-Version: Content-Type:Content-Transfer-Encoding; b=wnV7OWxJNVwTRMaM6ChEiIg8 2kkVkpCgS1655LUux9j8zLdE80rvfMXWeP8l6KhcXDXHrQe6SwE41vjJNqAqua/TRj0 wBQ4LUufGhOcoLOoEY5zwEpYCqXqhwu+rUX2rIwEGJ/8DxAVHFG/DmPso2EAL7Rjccu 8nVagz2VGJe/s= Received: from anthesphoria.net (adsl-200-42.eunet.yu [213.198.200.42]) (authenticated bits=0) by anthesphoria.net (8.14.2/8.14.2) with ESMTP id m16Ntdan054611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2008 00:55:44 +0100 (CET) (envelope-from nikola.lecic@anthesphoria.net) Date: Thu, 7 Feb 2008 00:56:55 +0100 From: Nikola =?UTF-8?B?TGXEjWnEhw==?= To: "Ulrich Spoerlein" Message-ID: <20080207005655.54e54bd5@anthesphoria.net> In-Reply-To: <7ad7ddd90802061204p35d0368ekbb54149287618f6a@mail.gmail.com> References: <7ad7ddd90802061204p35d0368ekbb54149287618f6a@mail.gmail.com> X-Mailer: Claws Mail 3.1.0 (GTK+ 2.12.5; i386-portbld-freebsd6.2) X-Face: pbl6-.[$G'Fi(Ogs2xlXP-V6{3||$Y[LOYs&~GJoikj'cVjcFC[V7du;;0~6nO= [Vi2?uU1Pq~,=Adj@,T:|"`$AF~il]J.Nz#2pU',Y7.{B;m/?{#sO^Dvo$rnmY6] X-Operating-System: FreeBSD 6.2-RELEASE-p9 X-OpenPGP-Fingerprint: FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B X-OpenPGP-Preferred-Keyserver: x-hkp://pgpkeys.pca.dfn.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: stable@freebsd.org Subject: Re: Reconstruct disklabel for UFS and GELI volumes 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, 07 Feb 2008 00:19:26 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogUklQRU1EMTYwDQoNCk9u IFdlZCwgNiBGZWIgMjAwOCAyMTowNDoyMyArMDEwMA0KIlVscmljaCBTcG9lcmxlaW4iIDx1c3Bv ZXJsZWluQGdtYWlsLmNvbT4gd3JvdGU6DQogDQo+IEhpLA0KPiANCj4gU29tZWhvd1tUTV0gYW4g aW5zdGFsbGF0aW9uIG9mIDQuMTEgdG8gYWQwczMgbWFuYWdlZCB0byB3aXBlIG91dCBteQ0KPiBl eGlzdGluZyBkaXNrbGFiZWwgZm9yIDcuMCBvbiBhZDBzNC4gSSBub3cgbmVlZCB0byByZWNvdmVy IHRoZQ0KPiBkaXNrbGFiZWwgdG8gZ2V0IG15IHN5c3RlbSB0byBib290IQ0KPiANCj4gVGhlcmUg d2VyZSB0aHJlZSBsYWJlbHMNCj4gLSBhZDBzNGE6IFVGUywgZXhhY3Qgc2l6ZSB1bmtub3duLiBJ cyBpdCBwb3NzaWJsZSB0byBpbmZlciB0aGlzIGZyb20NCj4gdGhlIFVGUyBwYXJ0aXRpb24gc2l6 ZT8gSSBjYW4gbW91bnQgdGhpcyBhbHJlYWR5LCBhcyBJIHNpbXBseSB3cm90ZSBhbg0KPiAnYScg bGFiZWwgb2YgbWF4aW11bSBzaXplIHRvIHRoZSBkaXNrbGFiZWwNCj4gLSBhZDBzNGI6IEdFTEkg ZW5jcnlwdGVkIHN3YXANCj4gLSBhZDBzNGQ6IEdFTEkgZW5jcnlwdGVkIFpWT0wNCj4gDQo+IEkg b25seSBuZWVkIHRvIGZpbmQgb3V0IHRoZSBzdGFydCBvZiBhZDBzNGQuIElzIHRoZSBjb25zdW1l ciBzaXplIG9mDQo+IGFuIEdFTEkgZGV2aWNlIHN0b3JlZCBpbiB0aGUgbGFzdCA1MTIgYnl0ZXMg bWV0YWRhdGE/IE9yIGFyZSB0aGVyZQ0KPiBzb21lIG1hZ2ljIGJ5dGVzIGluIHRoaXMgNTEyIGJ5 dGVzIHNvIEkgY291bGQgZmluZCBvdXQgdGhlIGV4YWN0IGVuZA0KPiBvZiBhZDBzNGIgYW5kIHRo dXMgdGhlIHN0YXJ0IG9mIGFkMHM0ZD8NCg0KSGkgVWxyaWNoLA0KDQpUcnkgdG8gc2NhbiB0aGF0 IGRpc2sgd2l0aCBzeXN1dGlscy90ZXN0ZGlzazoNCg0KICBodHRwOi8vd3d3LmNnc2VjdXJpdHku b3JnL3dpa2kvVGVzdERpc2sNCg0KQmVzdCByZWdhcmRzLg0KLSAtLSANCk5pa29sYSBMZcSNacSH ID0g0J3QuNC60L7Qu9CwINCb0LXRh9C40ZsNCmZpbmdlcnByaW50IDogRkVGMyA2NkFGIEM5MEUg RURDMyBEODc4ICA3Q0RDIDk1NkQgRjRBQiBBMzc3IDFDOUINCg0KLS0tLS1CRUdJTiBQR1AgU0lH TkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYyLjAuNCAoRnJlZUJTRCkNCg0KaVFDVkF3VUJS NnBKVmZ6RFA5SzJDS0dZQVFNcnhBUDlGeG5nMlphSG1nQjVJRDZaVFZmT3dOVFREcnpQTmxNWA0K RlJsT0lLbmtzbGRUemhVZGswVWZzSlA5a2dZcEVJbno2Z1EzdW5TbFVTQkRUZ045alNXNnlRR00w Zlc0aFozSA0KMjdHZTVmcmR6RVRYZzkxVFJzeDFhUDI0aTNTZXpOSE8wQVlMUXc5Y2JEN2Z0RFZI SDF5emttWnJ4U1A3a1lKLw0KWVBnZS9nN1lSS0k9DQo9aC82Vg0KLS0tLS1FTkQgUEdQIFNJR05B VFVSRS0tLS0tDQo= From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 05:56:15 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A3916A418 for ; Thu, 7 Feb 2008 05:56:15 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: from sigma.octantis.com.au (ns2.octantis.com.au [207.44.189.124]) by mx1.freebsd.org (Postfix) with ESMTP id DB18413C461 for ; Thu, 7 Feb 2008 05:56:14 +0000 (UTC) (envelope-from freebsd@meijome.net) Received: (qmail 26965 invoked from network); 6 Feb 2008 23:56:14 -0600 Received: from 124-170-113-73.dyn.iinet.net.au (HELO localhost) (124.170.113.73) by sigma.octantis.com.au with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Feb 2008 23:56:14 -0600 Date: Thu, 7 Feb 2008 16:55:59 +1100 From: Norberto Meijome To: Torfinn Ingolfsen Message-ID: <20080207165559.4ed9266c@meijome.net> In-Reply-To: <20080207010502.3f96fd3f.torfinn.ingolfsen@broadpark.no> References: <7ad7ddd90802061204p35d0368ekbb54149287618f6a@mail.gmail.com> <20080207010502.3f96fd3f.torfinn.ingolfsen@broadpark.no> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.7; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Reconstruct disklabel for UFS and GELI volumes 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, 07 Feb 2008 05:56:15 -0000 On Thu, 07 Feb 2008 01:05:02 +0100 Torfinn Ingolfsen wrote: > Take it slowly, and double check all steps before comitting anything. depending on how valuable your data is, you may want to test any changes first (or at least make a backup of the raw disk...) I would try to do a raw dump of the data into a file (using dd) and mount this as a md device . Then play to your hearts contents getting the data back.... once u have done that, u can either start from scratch on the original disk and dump the data back into it from the image, or repeat the steps on the real disk [tm]. good luck! B _________________________ {Beto|Norberto|Numard} Meijome "Everything is interesting if you go into it deeply enough" Richard Feynman I speak for myself, not my employer. Contents may be hot. Slippery when wet. Reading disclaimers makes you go blind. Writing them is worse. You have been Warned. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 07:22:58 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 686A816A417 for ; Thu, 7 Feb 2008 07:22:58 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 1543D13C457 for ; Thu, 7 Feb 2008 07:22:57 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 9BA50405C67; Thu, 7 Feb 2008 08:22:56 +0100 (CET) Message-ID: <47AAB1CF.3090203@bsdforen.de> Date: Thu, 07 Feb 2008 08:22:55 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Matthieu Bollot References: <1202334536.6146.10.camel@sarah.penia.org> In-Reply-To: <1202334536.6146.10.camel@sarah.penia.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: synaptics 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: Thu, 07 Feb 2008 07:22:58 -0000 Matthieu Bollot wrote: > Hi, > > I've recently installed FreeBSD 6.3, and I've got a problem with > synaptics. > I've installed it, followed the pkg-message : > hw.psm.synaptics_support=1 > > It works, dmesg gives : > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Synaptics Touchpad, device ID 0 > > moused_enable="NO" > ps shows me that moused doesn't run. > > xorg.conf : > InputDevice "Synaptics_Touchpad" "CorePointer" > ... > Section "InputDevice" > Identifier "Synaptics_Touchpad" > Driver "synaptics" > Option "Device" "/dev/psm0" > Option "Protocol" "psm" > ... > > And here is a part of Xorg.log : > (WW) : No Device specified, looking for one... > (II) : Setting Device option to "/dev/psm0" > (--) : Device: "/dev/psm0" > (==) : Protocol: "Auto" > ... > Synaptics DeviceInit called > SynapticsCtrl called. > (II) : SetupAuto: hw.iftype is 3, hw.model is 13 > (II) : SetupAuto: protocol is SysMouse > (WW) fcntl(15, O_ASYNC): Inappropriate ioctl for device > Synaptics DeviceOn called > (EE) xf86OpenSerial: Cannot open device /dev/psm0 > Device busy. > (WW) Synaptics_Touchpad: cannot open input device > couldn't enable device 3 > > Protocol isn't psm, why ? Can I force it ? > /dev/psm0 isn't used or it is used by Xorg (I saw it with fstat) > > any idea ? I didn't had this problem with 6.2 but may be I wasn't up to > date with xorg. I think protocol has to stay auto. Is it possible that your Xorg.conf has more device sections? One of which already uses /dev/psm0? PS: On my new system the touchpad is recognized as an Intellimouse Explorer, no matter weather I set hw.psm.synaptics_support=1 or not. The Xorg synaptics driver rejects it, however, vertical scrolling works out of the box, even using moused. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 08:30:52 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91DB016A41B for ; Thu, 7 Feb 2008 08:30:52 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0B62E13C44B for ; Thu, 7 Feb 2008 08:30:51 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so961548nfb.33 for ; Thu, 07 Feb 2008 00:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=rHBp4lyK1h+h1GbbhmMs6aHFyJQHJLjGl1vmRxzoUyQ=; b=mSpbKmV2xB5O5CLFO2OLTG9wwT4zBvgXQxpH8o0WwgmEWKkcopNbA1QI2pXm25ru9uXX68OHEpUzbQnNzT+n0lTrBQGfICuK2gIDkB9WITJQ9a/Ay11JPSQXn1UgYZzIGJhoEGNFToj0k7mw42YWKhxUuijis7TtPCmDH2MnGrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KaE1AOd+zOnoOSkzZqi29RRTI2tA83lMWYoR2SIXKU8WMz+TMh0ATtwvBy0TFz4zPXB3hyMRsgoZ9bSONlg8oJexOJn0AzlaAgVFTmEFHWt13kc4U4NPrpM9Dri+XOAAroRzGMeSxQAj+kxZGsudsWkOA2xd7OlAUVOsoshw+UM= Received: by 10.78.176.20 with SMTP id y20mr5815921hue.36.1202373050368; Thu, 07 Feb 2008 00:30:50 -0800 (PST) Received: by 10.78.173.4 with HTTP; Thu, 7 Feb 2008 00:30:45 -0800 (PST) Message-ID: <7ad7ddd90802070030h3b42296et60d1e12f9d93d65f@mail.gmail.com> Date: Thu, 7 Feb 2008 09:30:45 +0100 From: "Ulrich Spoerlein" To: "Torfinn Ingolfsen" In-Reply-To: <20080207010502.3f96fd3f.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7ad7ddd90802061204p35d0368ekbb54149287618f6a@mail.gmail.com> <20080207010502.3f96fd3f.torfinn.ingolfsen@broadpark.no> Cc: freebsd-stable@freebsd.org Subject: Re: Reconstruct disklabel for UFS and GELI volumes 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, 07 Feb 2008 08:30:52 -0000 On Feb 7, 2008 1:05 AM, Torfinn Ingolfsen wrote: > Ulrich Spoerlein wrote: > > There were three labels > Actually, it is one label per slice, unless you are doing something > unusual? s/labels/partitions/ , that's what I meant. > > - ad0s4a: UFS, exact size unknown. Is it possible to infer this from > > the UFS partition size? I can mount this already, as I simply wrote an > > 'a' label of maximum size to the disklabel > > - ad0s4b: GELI encrypted swap > > - ad0s4d: GELI encrypted ZVOL > > FWIW, I have had success with scan_ffs[1] as documented in this short > article[2]. It will recover lost labels, or at least try to. > If you are downloading binary packages from somewhere, be sure to > double check that you get the one that fits your platform (i386 / amd64 > or whatever) and version. > Take it slowly, and double check all steps before comitting anything. I already made some progress. The GEOM classes place a label into the last sector (GEOM::GELI) in my case, so I could use this string to scan the whole slice overnight. Sadly, the geli swap partition has no such signature, only the geli ad0s4d partition has one. However, using geli dump I can get the original partition size. I now only have to adjust the offset/length in the bsdlabel and figure out the original size for ad0s4a (which I guess was 512MB). I should have this back running quickly, once I get home to the machine. Thanks for all the suggestions so far. Since I can't install any packages (I'm using the 6.2 fixit cd), how can I calculate the file system size from the ffsinfo output? Uli From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 13:04:37 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F14F16A494 for ; Thu, 7 Feb 2008 13:04:37 +0000 (UTC) (envelope-from me@che78-3-82-246-30-233.fbx.proxad.net) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id BA5CA13C4CE for ; Thu, 7 Feb 2008 13:04:36 +0000 (UTC) (envelope-from me@che78-3-82-246-30-233.fbx.proxad.net) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by postfix1-g20.free.fr (Postfix) with ESMTP id 9C0F72262A2E for ; Thu, 7 Feb 2008 13:44:10 +0100 (CET) Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id 7F29517F87A for ; Thu, 7 Feb 2008 13:44:08 +0100 (CET) Received: from che78-3-82-246-30-233.fbx.proxad.net (che78-3-82-246-30-233.fbx.proxad.net [82.246.30.233]) by smtp8-g19.free.fr (Postfix) with ESMTP id 5DBC517FF41 for ; Thu, 7 Feb 2008 13:44:08 +0100 (CET) Received: by che78-3-82-246-30-233.fbx.proxad.net (Postfix, from userid 1001) id 06EE94523C; Thu, 7 Feb 2008 13:44:03 +0100 (CET) Date: Thu, 7 Feb 2008 13:44:03 +0100 From: Harald Weis To: freebsd-stable@freebsd.org Message-ID: <20080207124403.GA2792@pollux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: X.org: Fatal server error 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, 07 Feb 2008 13:04:37 -0000 Hello All, *** Fatal server error: *** could not open default font 'fixed' This is the message (without the stars) I get on a laptop after a fresh install of FreeBSD 6.2-RELEASE i386 (previously 6.0). Searching the archives, I found two reasons which do not apply for me: 1. xorg-fonts-miscbitmaps-7.2 is properly installed 2. the same is true for font-alias-1.0.1 A good reason in my case seems to be: all fonts.dir files are empty. Running ``mkfontdir [-e encodings/] misc/'' creates always an empty fonts.dir file, but with the '-e' option a correct encodings.dir file. Conclusion: mkfontdir appears to be broken, or rather mkfontscale as the former is just a single-line shell script. xorg-7.2, xorg-fonts-7.2 and all the rest are properly installed. The instructions of the 20070519-section in UPDATING have successfully been executed. Fortunately, lynx and elinks work alright. Needless to say that I've portupgrade'd both mkfontdir and mkfontscale with the '-f' option, and that my ports tree is portsnap'ed up-to-date. What else could I do to find the bug ? Thanks in advance, Harald From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 15:55:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA28C16A41B; Thu, 7 Feb 2008 15:55:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 3389213C458; Thu, 7 Feb 2008 15:55:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 294FD74400F; Thu, 7 Feb 2008 17:55:03 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XSU1J0W846R; Thu, 7 Feb 2008 17:55:03 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3EAEA74400E; Thu, 7 Feb 2008 17:55:02 +0200 (EET) Message-ID: <47AB29D4.1040409@icyb.net.ua> Date: Thu, 07 Feb 2008 17:55:00 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: freebsd-hardware@freebsd.org, freebsd-stable@freebsd.org, freebsd-current@freebsd.org References: <4799D78F.6000405@icyb.net.ua> <47A097FA.3090303@icyb.net.ua> <20080130164508.GC6257@suse.cz> <47A2E7E5.1040307@icyb.net.ua> <20080201093806.GA4632@suse.cz> <47A738AE.5070900@icyb.net.ua> In-Reply-To: <47A738AE.5070900@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: ps/2 mouse patch [intellimouse explorer detection] 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, 07 Feb 2008 15:55:04 -0000 Still nobody comes forward. Is there any maintainer of psm driver? As a final authority I am forced to quote now Microsoft itself on this matter: http://www.microsoft.com/whdc/device/input/5b_wheel.mspx I've also found a PR for the similar hardware from the same vendor with the same symptoms: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/118578 I am moving this discussion there now, but knowing how the PRs are handled for the bits without a maintainer or with very-low-activity maintainer[*], this is a cry of hope and desperation. [*] - Well, I know that I am talking about very old code, for very old protocol where things should have long been settled. But apparently there are cases when the code works in 99% of cases and nobody cares about the rest 1%, even if that percent is not some quirky hardware, but the hardware that does follows its specification, only too rigidly. on 04/02/2008 18:09 Andriy Gapon said the following: > on 01/02/2008 11:38 Vojtech Pavlik said the following: >> On Fri, Feb 01, 2008 at 11:35:33AM +0200, Andriy Gapon wrote: >>> I compared FreeBSD and Linux sources more thoroughly and found the >>> following: >>> http://lxr.linux.no/linux+v2.6.24/drivers/input/mouse/psmouse-base.c#L464 >>> static int im_explorer_detect(struct psmouse *psmouse, int set_properties) >>> { >>> struct ps2dev *ps2dev = &psmouse->ps2dev; >>> unsigned char param[2]; >>> >>> intellimouse_detect(psmouse, 0); >>> >>> I.e., first thing the explorer probe does is massaging a mouse with >>> IntelliMouse magic commands. >>> >>> I did the same in FreeBSD psm.c, i.e., added a call to >>> enable_msintelli() at the very start of enable_msexplorer(). And voil - >>> everything is perfect, correct ID is returned, probing succeeds, the >>> mouse works great. >>> >>> I think that this change is quite safe to make in FreeBSD, because with >>> Linux user-base we can be 99% percent sure that this change won't break >>> anything. >> It is even correct: A mouse isn't required to be able to jump straight >> into the Explorer mode, it is supposed to always go through the >> IntelliMouse mode. > > Any takers to test this change with your current PS/2 mouse (either > working or non-working) ? > Any takers to commit this change ? :-) > > Will this issue get more traction if I file a PR? > > > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 17:00:24 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E9C216A417 for ; Thu, 7 Feb 2008 17:00:24 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (infra.dev.vega.ru [90.156.167.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1BDAC13C44B for ; Thu, 7 Feb 2008 17:00:23 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=63770 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JN9O1-0005Mu-Cp; Thu, 07 Feb 2008 16:14:05 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.2/8.14.2) with ESMTP id m17GE2YW066069; Thu, 7 Feb 2008 19:14:02 +0300 (MSK) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.2/8.14.2/Submit) id m17GDv87066050; Thu, 7 Feb 2008 19:13:57 +0300 (MSK) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Thu, 7 Feb 2008 19:13:57 +0300 From: Ruslan Ermilov To: Miguel Lopes Santos Ramos Message-ID: <20080207161357.GA65774@team.vega.ru> References: <20071028211538.GA92424@intserv.int1.b.intern> <200710290119.l9T1Jpvs009149@satan.anjos.strangled.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710290119.l9T1Jpvs009149@satan.anjos.strangled.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: hk@alogis.com, stable@FreeBSD.org, eugen@kuzbass.ru Subject: Re: date manupulation strangeness 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, 07 Feb 2008 17:00:24 -0000 On Mon, Oct 29, 2007 at 01:19:51AM +0000, Miguel Lopes Santos Ramos wrote: > > From: Holger Kipp > > > > On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote: > > > On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote: > > > > > > > > # unixtime=1193511599 > > > > > # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime > > > > > Sun Oct 28 02:59:59 KRAT 2007 > > > > > > Here it shows 'Sun Oct 28 02:59:59 KRAST 2007' really > > > (cut-n-paste error, mea culpa). Take a note of zone name, > > > KRAST stands for 'KRAsnoyarsk Summer Time' and > > > KRAT stands for 'KRAsnoyarsk Time' (winter one). > > > > ah, I see. I can reproduce it here as well: > > > > %setenv LC_ALL C > > %setenv TZ Asia/Krasnoyarsk > > %setenv unixtime 1193511599 > > > > %date -jr $unixtime > > Sun Oct 28 02:59:59 KRAST 2007 > > %date -jf $s $unixtime > > Sun Oct 28 02:59:59 KRAT 2007 > > %date -juf %s $unixtime > > Sat Oct 27 18:59:59 UTC 2007 > > %date -jur $unixtime > > Sat Oct 27 18:59:59 UTC 2007 > > This is a lot of fun! Bugs like this go unnoticed for years... > It is also very exciting finding people at GMT+8. Mind you, we programmers who live at > GMT+0 do a lot of timezone errors because we look at a time and often don't know > whether it's localtime or gmt. At least I do. Then we only find out when we > change to summer time. > > The problem is of course in src/bin/date.c, line 268. Someone added the > following on revision 1.32.2.4: > 267: /* Let mktime() decide whether summer time is in effect. */ > 268: lt->tm_isdst = -1; > > Now, who's mktime() to know? > This line is erasing the output of strptime(), and strptime() knows better than > anyone what the user might have wanted! > [...] > There's no point in naming the revision... the problematic line was introduced > 6 years and 5 months ago by ru... Complete reference: src/bin/date.c Revision 1.32.2.4 > > Is ru around? > > Who fills in a pr for this? > > In summary, I think we should move line 268 to line 191 and erase the comment > on line 267 (mktime() is no one to decide, strptime() must have the final word). > I've committed a different fix, so that it doesn't re-introduce the bug fixed in rev. 1.36 (or 1.32.2.4, which was an MFC of 1.36). Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 17:51:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A68916A417 for ; Thu, 7 Feb 2008 17:51:29 +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 0021913C45B for ; Thu, 7 Feb 2008 17:51:28 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anb.p.matik.com.br (anb.p.matik.com.br [200.152.83.34] (may be forged)) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m17GjQ5d096619; Thu, 7 Feb 2008 14:45:26 -0200 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Thu, 7 Feb 2008 14:43:03 -0200 User-Agent: KMail/1.9.7 References: <1202334536.6146.10.camel@sarah.penia.org> In-Reply-To: <1202334536.6146.10.camel@sarah.penia.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200802071443.03406.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Cc: Matthieu Bollot Subject: Re: synaptics 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: Thu, 07 Feb 2008 17:51:29 -0000 On Wednesday 06 February 2008 19:48:56 Matthieu Bollot wrote: > Hi, > > I've recently installed FreeBSD 6.3, and I've got a problem with > synaptics. > I've installed it, followed the pkg-message : > hw.psm.synaptics_support=3D1 > > It works, dmesg gives : > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Synaptics Touchpad, device ID 0 > > moused_enable=3D"NO" > ps shows me that moused doesn't run. > hi the synaptic thing is bad explained everywhere if you want to use synaptics driver in xorg.conf you need to run sysmouse=20 first from rc.conf otherwise you use as psm mouse and all synaptics options are availble in=20 =46reebsd's desktop then you do not need to set hw.psm.synaptics_support in loader,conf =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 Thu Feb 7 19:17:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8704616A419 for ; Thu, 7 Feb 2008 19:17:21 +0000 (UTC) (envelope-from myj@nyct.net) Received: from bsd4.nyct.net (mail-out8.nyct.net [216.139.141.8]) by mx1.freebsd.org (Postfix) with ESMTP id 33FA513C4F7 for ; Thu, 7 Feb 2008 19:17:20 +0000 (UTC) (envelope-from myj@nyct.net) Received: from bsd4.nyct.net (mail-out8.nyct.net [216.139.141.8]) by bsd4.nyct.net (8.13.4/8.13.4) with ESMTP id m17IsNqg078959 for ; Thu, 7 Feb 2008 13:54:24 -0500 (EST) (envelope-from myj@nyct.net) Received: from localhost (myj@localhost) by bsd4.nyct.net (8.13.4/8.13.1/Submit) with ESMTP id m17IsNpV078955 for ; Thu, 7 Feb 2008 13:54:23 -0500 (EST) (envelope-from myj@nyct.net) X-Authentication-Warning: bsd4.nyct.net: myj owned process doing -bs Date: Thu, 7 Feb 2008 13:54:23 -0500 (EST) From: Paul To: freebsd-stable@freebsd.org Message-ID: <20080207133127.T50745@bsd4.nyct.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: kevent on UDP sockets 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, 07 Feb 2008 19:17:21 -0000 I'm having trouble with kevent() in connection with UDP sockets (6.2-STABLE). Registering an event seems to work, but when UDP packet arrives on the socket, kevent returns with 0. Is there currently a working support for UDP sockets in kqueue/kevent, or does it only apply to TCP sockets ? Thanks, P. Paul Sandys network operations manager http://www.nyct.net/ 212.293.2620 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 20:19:56 2008 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D8CE16A418 for ; Thu, 7 Feb 2008 20:19:56 +0000 (UTC) (envelope-from nikola.lecic@anthesphoria.net) Received: from anthesphoria.net (anthesphoria.net [200.46.204.219]) by mx1.freebsd.org (Postfix) with ESMTP id 40DC413C468 for ; Thu, 7 Feb 2008 20:19:54 +0000 (UTC) (envelope-from nikola.lecic@anthesphoria.net) X-Bogosity: No, tests=bogofilter X-DKIM: Sendmail DKIM Filter v2.4.1 anthesphoria.net m17Jln80045089 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anthesphoria.net; s=phero; t=1202413682; bh=8Ke/YjF7E9nfv9FlVibXxuutkCVFC4ohC5qaSb1yS mo=; l=1864; h=X-Bogosity:Date:From:To:Cc:Subject:Message-ID: In-Reply-To:References:X-Mailer:X-Face:X-Operating-System: X-OpenPGP-Fingerprint:X-OpenPGP-Preferred-Keyserver:Mime-Version: Content-Type:Content-Transfer-Encoding; b=WUoIVNBt36ewYV/TXwMI/mr+ qspNaMrSuvhFu5rWA9wlE4B8RBiE81GvdmmD8EHCZO6dZ5S04FsFeWnUUwQMMJ4UblO M64RCg3H2+S0ZFWTBX5EXM++PI+H5z/qmz2SqPo8T5R34V6GTJpaTW4adnEaXSiEC+c KOy3aOJ3tbPqs= Received: from anthesphoria.net (adsl-200-42.eunet.yu [213.198.200.42]) (authenticated bits=0) by anthesphoria.net (8.14.2/8.14.2) with ESMTP id m17Jln80045089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2008 20:47:54 +0100 (CET) (envelope-from nikola.lecic@anthesphoria.net) Date: Thu, 7 Feb 2008 20:49:10 +0100 From: Nikola =?UTF-8?B?TGXEjWnEhw==?= To: "Ulrich Spoerlein" Message-ID: <20080207204910.68309fd1@anthesphoria.net> In-Reply-To: <7ad7ddd90802070030h3b42296et60d1e12f9d93d65f@mail.gmail.com> References: <7ad7ddd90802061204p35d0368ekbb54149287618f6a@mail.gmail.com> <20080207010502.3f96fd3f.torfinn.ingolfsen@broadpark.no> <7ad7ddd90802070030h3b42296et60d1e12f9d93d65f@mail.gmail.com> X-Mailer: Claws Mail 3.1.0 (GTK+ 2.12.5; i386-portbld-freebsd6.2) X-Face: pbl6-.[$G'Fi(Ogs2xlXP-V6{3||$Y[LOYs&~GJoikj'cVjcFC[V7du;;0~6nO= [Vi2?uU1Pq~,=Adj@,T:|"`$AF~il]J.Nz#2pU',Y7.{B;m/?{#sO^Dvo$rnmY6] X-Operating-System: FreeBSD 6.2-RELEASE-p9 X-OpenPGP-Fingerprint: FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B X-OpenPGP-Preferred-Keyserver: x-hkp://pgpkeys.pca.dfn.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: Torfinn Ingolfsen , FreeBSD-stable@FreeBSD.org Subject: Re: Reconstruct disklabel for UFS and GELI volumes 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, 07 Feb 2008 20:19:56 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogUklQRU1EMTYwDQoNCk9u IFRodSwgNyBGZWIgMjAwOCAwOTozMDo0NSArMDEwMA0KIlVscmljaCBTcG9lcmxlaW4iIDx1c3Bv ZXJsZWluQGdtYWlsLmNvbT4gd3JvdGU6DQogDQpbLi4uXSANCj4gVGhhbmtzIGZvciBhbGwgdGhl IHN1Z2dlc3Rpb25zIHNvIGZhci4gU2luY2UgSSBjYW4ndCBpbnN0YWxsIGFueQ0KPiBwYWNrYWdl cyAoSSdtIHVzaW5nIHRoZSA2LjIgZml4aXQgY2QpLCBob3cgY2FuIEkgY2FsY3VsYXRlIHRoZSBm aWxlDQo+IHN5c3RlbSBzaXplIGZyb20gdGhlIGZmc2luZm8gb3V0cHV0Pw0KDQpJIGhhdGUgdG8g YmUgYm9yaW5nIChzaW5jZSBJIGFscmVhZHkgc3VnZ2VzdGVkIHRoZSB1c2Ugb2YNCnN5c3V0aWxz L3Rlc3RkaXNrKSwgYnV0IGl0IHdvdWxkIGJlIHJlYWxseSBoZWxwZnVsIHRvIGdpdmUgaXQgYSB0 cnkuDQpQbGVhc2UgcmVhZCB0aGlzIHN1Y2Nlc3Mgc3RvcnkgKDUgbWFpbHMpOg0KDQogIGh0dHA6 Ly9saXN0cy5mcmVlYnNkLm9yZy9waXBlcm1haWwvZnJlZWJzZC1xdWVzdGlvbnMvMjAwNy1EZWNl bWJlci8xNjQ5MDEuaHRtbA0KDQpBbW9uZyBvdGhlcnMgdGhpbmdzLCBpdCBjb250YWlucyBzb21l IG5vdGVzIG9uIGhvdyB0byB1c2UgcGFja2FnZXMgdGhhdA0KYXJlIG5vdCBpbmNsdWRlZCBpbiBy ZXNjdWUgQ0QgYW5kIGhvdyB0byByZWNhbGN1bGF0ZSB5b3VyIGJzZGxhYmVsDQpvZmZzZXRzIGFu ZCBvdGhlciBwYXJhbWV0cmVzLiBBbmQgeWVzLCB3aXRoIG9yIHdpdGhvdXQgR0VMSSB5b3VyIHN3 YXANCndpbGwgYXBwZWFyIGp1c3QgYXMgYSBob2xlIGJldHdlZW4gIm5vcm1hbCIgcGFydGl0aW9u cyBzbyBpdHMNCmRpbWVuc2lvbnMgYXJlIHByb2JhYmx5IHRoZSBsYXN0IHRoaW5nIHlvdSB3aWxs IHJlY29uc3RydWN0Lg0KDQotIC0tIA0KTmlrb2xhIExlxI1pxIcgPSDQndC40LrQvtC70LAg0JvQ tdGH0LjRmw0KZmluZ2VycHJpbnQgOiBGRUYzIDY2QUYgQzkwRSBFREMzIEQ4NzggIDdDREMgOTU2 RCBGNEFCIEEzNzcgMUM5Qg0KDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lv bjogR251UEcgdjIuMC40IChGcmVlQlNEKQ0KDQppUUNWQXdVQlI2dGd4dnpEUDlLMkNLR1lBUVBS SkFQK1BzOStEdnh3Y0t5WTNuWWl4VWxqUS9adGk4Y3RkOFQvDQowaVJocHRVV3AzR0h4SlZ2NFlF S2JzeThwVkdoYWFLOXAraWVVelVFRWZleW1lME1BVmxGU1g2MEdiNjhMNkRRDQpQWGNwbU1wTUQy L09wU3ZGMVNncmNxcUNKZDY3OHR5NUUwYkFIMlE2RHg2YkZtcmRlSTUxYkQ0K2VzQjFFU3FLDQo2 K0FMYndUL2k3QT0NCj16NE1CDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 21:31:18 2008 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A34F16A46E for ; Thu, 7 Feb 2008 21:31:18 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (acme.spoerlein.net [217.172.44.86]) by mx1.freebsd.org (Postfix) with ESMTP id 76A9F13C45E for ; Thu, 7 Feb 2008 21:31:17 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180169055.adsl.alicedsl.de [85.180.169.55]) by acme.spoerlein.net (8.14.1/8.14.1) with ESMTP id m17LUxoa001054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Feb 2008 22:31:01 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.2/8.14.2) with ESMTP id m17LUrpE003165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2008 22:30:53 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.2/8.14.2/Submit) id m17LUqF4003164; Thu, 7 Feb 2008 22:30:52 +0100 (CET) (envelope-from uspoerlein@gmail.com) X-Authentication-Warning: roadrunner.spoerlein.net: uqs set sender to uspoerlein@gmail.com using -f Date: Thu, 7 Feb 2008 22:30:52 +0100 From: Ulrich Spoerlein To: Nikola =?utf-8?B?TGXEjWnEhw==?= Message-ID: <20080207213052.GA1435@roadrunner.spoerlein.net> Mail-Followup-To: Nikola =?utf-8?B?TGXEjWnEhw==?= , Torfinn Ingolfsen , FreeBSD-stable@FreeBSD.org References: <7ad7ddd90802061204p35d0368ekbb54149287618f6a@mail.gmail.com> <20080207010502.3f96fd3f.torfinn.ingolfsen@broadpark.no> <7ad7ddd90802070030h3b42296et60d1e12f9d93d65f@mail.gmail.com> <20080207204910.68309fd1@anthesphoria.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080207204910.68309fd1@anthesphoria.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Torfinn Ingolfsen , FreeBSD-stable@FreeBSD.org Subject: Re: Reconstruct disklabel for UFS and GELI volumes 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, 07 Feb 2008 21:31:18 -0000 On Thu, 07.02.2008 at 20:49:10 +0100, Nikola Lečić wrote: > > Thanks for all the suggestions so far. Since I can't install any > > packages (I'm using the 6.2 fixit cd), how can I calculate the file > > system size from the ffsinfo output? > > I hate to be boring (since I already suggested the use of > sysutils/testdisk), but it would be really helpful to give it a try. > Please read this success story (5 mails): I would, if installing packages was more easily possible with the fixit mode. Looks like I need to take up my own live CD project again. > http://lists.freebsd.org/pipermail/freebsd-questions/2007-December/164901.html > > Among others things, it contains some notes on how to use packages that > are not included in rescue CD and how to recalculate your bsdlabel > offsets and other parametres. And yes, with or without GELI your swap > will appear just as a hole between "normal" partitions so its > dimensions are probably the last thing you will reconstruct. Why is there no metadata for the GELI swap? Is it because the 'label' command is not used (would make sense to me). Anyway, I reconstructed my disklabel and everything is back to normal. A nice exercise it was, though I'd rather have done it on non critical data :) Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 21:46:25 2008 Return-Path: Delivered-To: FreeBSD-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E494B16A46B for ; Thu, 7 Feb 2008 21:46:24 +0000 (UTC) (envelope-from nikola.lecic@anthesphoria.net) Received: from anthesphoria.net (anthesphoria.net [200.46.204.219]) by mx1.freebsd.org (Postfix) with ESMTP id 5561A13C502 for ; Thu, 7 Feb 2008 21:46:23 +0000 (UTC) (envelope-from nikola.lecic@anthesphoria.net) X-Bogosity: No, tests=bogofilter X-DKIM: Sendmail DKIM Filter v2.4.1 anthesphoria.net m17LkAtq060272 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anthesphoria.net; s=phero; t=1202420780; bh=YzgZQlGmySIGmsRAc2JqaUul8Pkxyh0Zeu3uqX+h0 z0=; l=3342; h=X-Bogosity:Date:From:To:Cc:Subject:Message-ID: In-Reply-To:References:X-Mailer:X-Face:X-Operating-System: X-OpenPGP-Fingerprint:X-OpenPGP-Preferred-Keyserver:Mime-Version: Content-Type:Content-Transfer-Encoding; b=Xa3Iw7qr/Nft6VthuYdGWtLl VODXFw0nbp3H1uqrNfaxkRlfRFUJUsnFb/C0wW0vrF0m/DCjwN2xqIBMZzbwuAARmYw 1MHcUqEQ3en/rBKbqX2RwS6BnZ8kF5IuiforApPbSyefOct8xJjcrWTv0nVNlnq84GX 4/SAS7kTq9ORU= Received: from anthesphoria.net (adsl-200-42.eunet.yu [213.198.200.42]) (authenticated bits=0) by anthesphoria.net (8.14.2/8.14.2) with ESMTP id m17LkAtq060272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2008 22:46:14 +0100 (CET) (envelope-from nikola.lecic@anthesphoria.net) Date: Thu, 7 Feb 2008 22:47:34 +0100 From: Nikola =?UTF-8?B?TGXEjWnEhw==?= To: Ulrich Spoerlein Message-ID: <20080207224734.761bdc32@anthesphoria.net> In-Reply-To: <20080207213052.GA1435@roadrunner.spoerlein.net> References: <7ad7ddd90802061204p35d0368ekbb54149287618f6a@mail.gmail.com> <20080207010502.3f96fd3f.torfinn.ingolfsen@broadpark.no> <7ad7ddd90802070030h3b42296et60d1e12f9d93d65f@mail.gmail.com> <20080207204910.68309fd1@anthesphoria.net> <20080207213052.GA1435@roadrunner.spoerlein.net> X-Mailer: Claws Mail 3.1.0 (GTK+ 2.12.5; i386-portbld-freebsd6.2) X-Face: pbl6-.[$G'Fi(Ogs2xlXP-V6{3||$Y[LOYs&~GJoikj'cVjcFC[V7du;;0~6nO= [Vi2?uU1Pq~,=Adj@,T:|"`$AF~il]J.Nz#2pU',Y7.{B;m/?{#sO^Dvo$rnmY6] X-Operating-System: FreeBSD 6.2-RELEASE-p9 X-OpenPGP-Fingerprint: FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B X-OpenPGP-Preferred-Keyserver: x-hkp://pgpkeys.pca.dfn.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Cc: Torfinn Ingolfsen , FreeBSD-stable@FreeBSD.org Subject: Re: Reconstruct disklabel for UFS and GELI volumes 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, 07 Feb 2008 21:46:25 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogUklQRU1EMTYwDQoNCk9u IFRodSwgNyBGZWIgMjAwOCAyMjozMDo1MiArMDEwMA0KVWxyaWNoIFNwb2VybGVpbiA8dXNwb2Vy bGVpbkBnbWFpbC5jb20+IHdyb3RlOg0KIA0KPiBPbiBUaHUsIDA3LjAyLjIwMDggYXQgMjA6NDk6 MTAgKzAxMDAsIE5pa29sYSBMZcSNacSHIHdyb3RlOg0KPiA+ID4gVGhhbmtzIGZvciBhbGwgdGhl IHN1Z2dlc3Rpb25zIHNvIGZhci4gU2luY2UgSSBjYW4ndCBpbnN0YWxsIGFueQ0KPiA+ID4gcGFj a2FnZXMgKEknbSB1c2luZyB0aGUgNi4yIGZpeGl0IGNkKSwgaG93IGNhbiBJIGNhbGN1bGF0ZSB0 aGUNCj4gPiA+IGZpbGUgc3lzdGVtIHNpemUgZnJvbSB0aGUgZmZzaW5mbyBvdXRwdXQ/DQo+ID4g DQo+ID4gSSBoYXRlIHRvIGJlIGJvcmluZyAoc2luY2UgSSBhbHJlYWR5IHN1Z2dlc3RlZCB0aGUg dXNlIG9mDQo+ID4gc3lzdXRpbHMvdGVzdGRpc2spLCBidXQgaXQgd291bGQgYmUgcmVhbGx5IGhl bHBmdWwgdG8gZ2l2ZSBpdCBhIHRyeS4NCj4gPiBQbGVhc2UgcmVhZCB0aGlzIHN1Y2Nlc3Mgc3Rv cnkgKDUgbWFpbHMpOg0KPiANCj4gSSB3b3VsZCwgaWYgaW5zdGFsbGluZyBwYWNrYWdlcyB3YXMg bW9yZSBlYXNpbHkgcG9zc2libGUgd2l0aCB0aGUNCj4gZml4aXQgbW9kZS4gTG9va3MgbGlrZSBJ IG5lZWQgdG8gdGFrZSB1cCBteSBvd24gbGl2ZSBDRCBwcm9qZWN0IGFnYWluLg0KDQpJIHdhcyBz cGVha2luZyBhYm91dCBGcmVlU0JJRS4gWW91IGNvdWxkIHJ1biB0ZXN0ZGlzayBmcm9tIG1lbW9y eSBkaXNrDQooYXMgZXhwbGFpbmVkIHRoZXJlKTsgeW91IHdvdWxkIGp1c3QgZG93bmxvYWQgNi4y IHBhY2thZ2UsIGV4dHJhY3QgaXQNCmluIHZpcnR1YWwgfiBhbmQgcnVuIHRoZSBiaW5hcnkgdG8g c2NhbiB5b3VyIGRpc2suIEl0IHdvcmtzIGp1c3QgZmluZS4NCg0KPiA+ICAgaHR0cDovL2xpc3Rz LmZyZWVic2Qub3JnL3BpcGVybWFpbC9mcmVlYnNkLXF1ZXN0aW9ucy8yMDA3LURlY2VtYmVyLzE2 NDkwMS5odG1sDQo+ID4gDQo+ID4gQW1vbmcgb3RoZXJzIHRoaW5ncywgaXQgY29udGFpbnMgc29t ZSBub3RlcyBvbiBob3cgdG8gdXNlIHBhY2thZ2VzDQo+ID4gdGhhdCBhcmUgbm90IGluY2x1ZGVk IGluIHJlc2N1ZSBDRCBhbmQgaG93IHRvIHJlY2FsY3VsYXRlIHlvdXINCj4gPiBic2RsYWJlbCBv ZmZzZXRzIGFuZCBvdGhlciBwYXJhbWV0cmVzLiBBbmQgeWVzLCB3aXRoIG9yIHdpdGhvdXQNCj4g PiBHRUxJIHlvdXIgc3dhcCB3aWxsIGFwcGVhciBqdXN0IGFzIGEgaG9sZSBiZXR3ZWVuICJub3Jt YWwiDQo+ID4gcGFydGl0aW9ucyBzbyBpdHMgZGltZW5zaW9ucyBhcmUgcHJvYmFibHkgdGhlIGxh c3QgdGhpbmcgeW91IHdpbGwNCj4gPiByZWNvbnN0cnVjdC4NCj4gDQo+IFdoeSBpcyB0aGVyZSBu byBtZXRhZGF0YSBmb3IgdGhlIEdFTEkgc3dhcD8gSXMgaXQgYmVjYXVzZSB0aGUgJ2xhYmVsJw0K PiBjb21tYW5kIGlzIG5vdCB1c2VkICh3b3VsZCBtYWtlIHNlbnNlIHRvIG1lKS4NCg0KV2VsbCwg eWVzOyB3ZSdyZSBzcGVha2luZyBoZXJlIGFib3V0IHRvb2xzIHRoYXQgcmVjb2duaXNlIFVGUyBz cGVjaWZpYw0KZGF0YS4gQWxzbywgdGhlIHN3YXAgc2l6ZSByZXBvcnRlZCBieSBzd2FwaW5mbyAo cHN0YXQoOCkpIGlzIGVxdWFsIHRvDQp0aGUgYWN0dWFsIHBoeXNpY2FsIHNwYWNlIG9jY3VwaWVk IGJ5IHN3YXAgcGFydGl0aW9uIChub3Qgc3VyZSBpZg0Kc29tZXRoaW5nIGNoYW5nZXMgaW4gdGhl IGNhc2Ugb2YgR0VMSSBlbmNyeXB0ZWQgc3dhcCwgYnV0IEkgZ3Vlc3MgaXQNCmRvZXNuJ3QpLg0K DQo+IEFueXdheSwgSSByZWNvbnN0cnVjdGVkIG15IGRpc2tsYWJlbCBhbmQgZXZlcnl0aGluZyBp cyBiYWNrIHRvDQo+IG5vcm1hbC4gQSBuaWNlIGV4ZXJjaXNlIGl0IHdhcywgdGhvdWdoIEknZCBy YXRoZXIgaGF2ZSBkb25lIGl0IG9uIG5vbg0KPiBjcml0aWNhbCBkYXRhIDopDQoNCk5pY2UuIDot KSBCZXN0IHdpc2hlcy4NCi0gLS0gDQpOaWtvbGEgTGXEjWnEhyA9INCd0LjQutC+0LvQsCDQm9C1 0YfQuNGbDQpmaW5nZXJwcmludCA6IEZFRjMgNjZBRiBDOTBFIEVEQzMgRDg3OCAgN0NEQyA5NTZE IEY0QUIgQTM3NyAxQzlCDQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9u OiBHbnVQRyB2Mi4wLjQgKEZyZWVCU0QpDQoNCmlRQ1ZBd1VCUjZ0OGhQekRQOUsyQ0tHWUFRTjNZ QVArUHBuaTN2eW9UQUwwZTV5cVcrS2tWQ21LenZaSStPOTINCjJBaE1zYldLUDdpN0R4Z2NuaXE5 WmNaeW9qMFJqQWNDWS9PRVBMZ1VENENQWHBZaEhVQnppQkEzWEgzektLS1INCnBlcE5scVBDZTZT cWFqU0tieTNZMmtCZE5Ic3pvUGhPclo3VFpRdThUZktOUThBL1JJZlc4N0M1L1NaWHdUbWINCktS ZzMwbkxxang0PQ0KPXBoZlMNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 22:19:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEDE616A418 for ; Thu, 7 Feb 2008 22:19:09 +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 7D3AB13C448 for ; Thu, 7 Feb 2008 22:19:09 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JNF5F-0004Tl-Ew for freebsd-stable@freebsd.org; Thu, 07 Feb 2008 22:19:05 +0000 Received: from r5j156.net.upc.cz ([86.49.9.156]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Feb 2008 22:19:05 +0000 Received: from gamato by r5j156.net.upc.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Feb 2008 22:19:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: martinko Date: Thu, 07 Feb 2008 23:18:58 +0100 Lines: 56 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: r5j156.net.upc.cz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.11) Gecko/20080203 SeaMonkey/1.1.7 In-Reply-To: Sender: news Subject: Re: finstall alpha3 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, 07 Feb 2008 22:19:10 -0000 Ivan Voras wrote: > Hi, > > As some of you may already know, I'm working on a graphical installer > for FreeBSD 7, which was started as a Google SoC 2007 project but still > continues. Usually I'd announce a new build on blogs.freebsdish.org but > it's currently down and anyway maybe it's time for a wider exposure. > > The latest build can be found at > http://ivoras.sharanet.org/stuff/freebsd7-finstall-alpha3.iso.bz2 with > MD5 fingerprint of 4a11b172ed1c3030f530028a56f88ece. This is a i386 > build as I don't have an amd64 development machine. > > Caveat! This is to be considered alpha-quality software. In particular, > it still can't do any of the following things: > > - install on an already partitioned drive (so it's practically only > usable for experimentation in VMWare and similar tools) > - configure any of the more advanced features like RAID, X11 and sound > - configure system locale & similar features > > On the other hand, here's what it *can* do currently: > > - it's a "live" CD environment, completely like an already installed > FreeBSD system, only running from a read-only media (e.g. it's usable as > a "FixIt" system) > - it installs both the base system (7.0-RC1) and a pre-selected set of > packages which includes X.Org 7.3, XFce desktop 4.4, Firefox and Thunderbird > - supports UFS, UFS+gjournal, ZFS and Ext2 (only UFS has been well tested). > - configure simple services like ssh, ntpdate, bsdstats > > For those who tried earlier versions, the major changes are: > - several subtle bugs are fixed > - implemented ZFS support with proper tuning in loader.conf > - added bsdstats package in the default set > > I'd like to hear impressions and suggestions of potential users. Some of > the obvious features (like install on a already partitioned drive) will > be done in time for, or slightly after, 7.0 gets released (a rudimentary > support for remote installs will also be present), some features (RAID) > will almost certainly get done later. Anything other will require time > and probably sponsorship. > > I'm also interested in possible contributions to the project. In > particular, it needs many UI strings to be filled in (many of the text > labels and help texts are only placeholders). Interested people should > know how to use Subversion. The project is hosted on SourceForge at > http://sourceforge.net/projects/finstall - Perforce was avoided to allow > access to people without FreeBSD developer accounts. > > I'd like to thank Google for the SoC project funding, Murray Stokely who > was the mentor during the SoC and many other people who have helped. > BTW is bsdstats still running/working ? The site has been partially broken for months. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 22:33:39 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7D3716A418 for ; Thu, 7 Feb 2008 22:33:39 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 6314513C4EA for ; Thu, 7 Feb 2008 22:33:39 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 2C7FA3EC8F for ; Thu, 7 Feb 2008 23:33:37 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TE-p8GhjAZX for ; Thu, 7 Feb 2008 23:33:34 +0100 (CET) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 745DF3EC85; Thu, 7 Feb 2008 23:33:34 +0100 (CET) Date: Thu, 7 Feb 2008 23:33:34 +0100 From: Ollivier Robert To: freebsd-stable@freebsd.org Message-ID: <20080207223334.GA82442@keltia.freenix.fr> References: <200802061122.m16BMrBv079324@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / Macbook Pro - FreeBSD 6.2 / Dell D820 SMP User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: finstall alpha3 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, 07 Feb 2008 22:33:39 -0000 According to Ivan Voras: > features, like configuring GEOM RAID, etc. Even now it can set up > UFS+gjournal or ZFS file systems for users who want it. Including root on ZFS + UFS /boot? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 8.10.1: Wed May 23 16:33:00 PDT 2007 i386 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 7 23:04:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B730B16A469 for ; Thu, 7 Feb 2008 23:04:14 +0000 (UTC) (envelope-from otaviof@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 3599B13C459 for ; Thu, 7 Feb 2008 23:04:13 +0000 (UTC) (envelope-from otaviof@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so2918137fgg.35 for ; Thu, 07 Feb 2008 15:04:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; bh=98diN1mgPDrxIlF1JKGWSFAXhBoTub9E94LJFalMFRQ=; b=W4aotwSGn8MJYU90h1sUs0cVafNa49TMyFmgEf6MzHdavUmt3Pfi/CGAvhOV3RLg/XGKX6sf6Y9lLd3+fnLQH1ibENJYc0KwWW+0s5OLy2R3/pePOlurlCCAFj9fbEtaCfnhYLvlAOQLIors6gFOfNf5iGHxg2Xu48phM0ZRkn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=Gc/dsmh21XO4HgkcjMEF6w9iP/Gb7MF4OvkMfZ3kcXhV0OR1TosAZZqhManntnmiGCX6rgarFc0TbK+eT4NbnWN7J1KL3lRdyrJyFtVA99IJFDhzsavMWVv8qqfPfjNY0V0AjMd3Js67S/f6DppqCrEEKXrXOs29tUnYku8albo= Received: by 10.86.84.5 with SMTP id h5mr10950707fgb.53.1202423829272; Thu, 07 Feb 2008 14:37:09 -0800 (PST) Received: from nexus6.bluepex.com ( [201.75.210.52]) by mx.google.com with ESMTPS id e11sm10796219fga.5.2008.02.07.14.37.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Feb 2008 14:37:09 -0800 (PST) Date: Thu, 7 Feb 2008 20:36:57 -0200 From: =?ISO-8859-1?Q?Ot=E1vio?= Fernandes To: freebsd-stable@freebsd.org Message-ID: <20080207203657.45d87889@nexus6.bluepex.com> In-Reply-To: <1202334536.6146.10.camel@sarah.penia.org> References: <1202334536.6146.10.camel@sarah.penia.org> X-Mailer: Claws Mail 3.2.0 (GTK+ 2.12.7; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: synaptics 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: Thu, 07 Feb 2008 23:04:14 -0000 On Wed, 06 Feb 2008 22:48:56 +0100 Matthieu Bollot wrote: > Hi, >=20 > I've recently installed FreeBSD 6.3, and I've got a problem with > synaptics. > I've installed it, followed the pkg-message : > hw.psm.synaptics_support=3D1 >=20 > It works, dmesg gives : > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Synaptics Touchpad, device ID 0 >=20 > moused_enable=3D"NO" > ps shows me that moused doesn't run. >=20 > xorg.conf : > InputDevice "Synaptics_Touchpad" "CorePointer" > ... > Section "InputDevice" > Identifier "Synaptics_Touchpad" > Driver "synaptics" > Option "Device" "/dev/psm0" > Option "Protocol" "psm" > ... >=20 > And here is a part of Xorg.log : > (WW) : No Device specified, looking for one... > (II) : Setting Device option to "/dev/psm0" > (--) : Device: "/dev/psm0" > (=3D=3D) : Protocol: "Auto" > ... > Synaptics DeviceInit called > SynapticsCtrl called. > (II) : SetupAuto: hw.iftype is 3, hw.model is 13 > (II) : SetupAuto: protocol is SysMouse > (WW) fcntl(15, O_ASYNC): Inappropriate ioctl for device > Synaptics DeviceOn called > (EE) xf86OpenSerial: Cannot open device /dev/psm0 > Device busy. > (WW) Synaptics_Touchpad: cannot open input device > couldn't enable device 3 >=20 > Protocol isn't psm, why ? Can I force it ? > /dev/psm0 isn't used or it is used by Xorg (I saw it with fstat) >=20 > any idea ? I didn't had this problem with 6.2 but may be I wasn't up > to date with xorg. >=20 > _______________________________________________ > 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" Hello Matthieu, I have another sugestion to your synaptics: http://people.freebsd.org/~dumbbell/synaptics/ This patch make synaptics work with moused and, for me, it's awesome ! The only matter is to emulate middle button you need to tap with 3 fingers. best regards, --=20 | -- | Ot=E1vio Fernandes < otaviof | gmail | com > | FreeBSD 7.0-PRERELEASE && GNU/Linux User: 283.396 | (( Especial Programa=E7=E3o )) http://geekbr.podcastbrasil.com/ -- 0.15 | -- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 01:23:49 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1957E16A421 for ; Fri, 8 Feb 2008 01:23:49 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id CCCBD13C44B for ; Fri, 8 Feb 2008 01:23:48 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so5221915pyb.10 for ; Thu, 07 Feb 2008 17:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=4CaemwORAyM2+WSPeY6hGYwADIhkzu9yiShIAETlz5Q=; b=rt6EALXKRm1WS8qq3xzCEpT1uMHwupN09eXe7/UWFvmhXOvaPABGvghHwUn5/IfZU3USAIGUGZ6GaQ8xex67zP8EAOdXyETLYDavhw4FhXxTCOHFWH6yK1VRjz+4Ysakh60mLeg9uX34xe8SYYJ6vCMYfIiwScQGJVOUuL4iXkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=H/pcdoRpTia6bR2h+q5h2hz13qf5rV3jHRL/txcDcQki+Z+2k7ua6U836Z4x3VpEvfb2SksRA71gLk/ydeFx9ZZ9EbaY9kPnewwx7HUsD4GizGDTQyVfYwrLcDNKJmlM56kAXL3v3E+06RwfnZI9DkZjuaEneVH7+Lgkp5LtyyY= Received: by 10.64.208.20 with SMTP id f20mr23237733qbg.21.1202433827113; Thu, 07 Feb 2008 17:23:47 -0800 (PST) Received: by 10.64.195.8 with HTTP; Thu, 7 Feb 2008 17:23:47 -0800 (PST) Message-ID: <5f67a8c40802071723i6521622ata1c7773b41e0ca26@mail.gmail.com> Date: Thu, 7 Feb 2008 20:23:47 -0500 From: "Zaphod Beeblebrox" To: Paul In-Reply-To: <20080207133127.T50745@bsd4.nyct.net> MIME-Version: 1.0 References: <20080207133127.T50745@bsd4.nyct.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: kevent on UDP sockets 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, 08 Feb 2008 01:23:49 -0000 On Feb 7, 2008 1:54 PM, Paul wrote: > > I'm having trouble with kevent() in connection with UDP sockets > (6.2-STABLE). > > Registering an event seems to work, but when UDP packet arrives on the > socket, kevent returns with 0. > > Is there currently a working support for UDP sockets in kqueue/kevent, or > does it only apply to TCP sockets ? I have a fairly non-trivial application that sends and receives UDP packets with kqueue. Registering output queue events is not usful, but input queue events work just fine for me. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 02:22:40 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51EBF16A417 for ; Fri, 8 Feb 2008 02:22:40 +0000 (UTC) (envelope-from unixmania@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 C90BA13C457 for ; Fri, 8 Feb 2008 02:22:39 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1200257uge.37 for ; Thu, 07 Feb 2008 18:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=tnZqLgsM0GSrUCNMU6zCaHmTUGNtWfudTdDqActdEbM=; b=EqtUcYuwpAmsHMaEucgAnA6D2nAvsTSIuHiGGXHAVWp3Uw3p//CJTlApuHPAnRQ5GU8f3w1zmRoJTC5BF/qQ1L4ZwL1s1i7Is54/LF5kC2DGFtLfseRThMsSQYiCafu2KMFIU3XhP/zB1wzk4KjcdCxJ7mLzq/CRRU5pFbSSo4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mb4U4KV4mJcWB2aXj/JtPD4N+JF91tAfVR12f4yiA9pEiZi+T9S5dQYISbRnoIlQB6Nk+uPSMS5Jsq1+1oJDZyyFUbhyCfHOB5mzeowY7sQkelrsZgzAl1u72nUJc0TDDV1m4sm5syheUvTMXE0ms5BLd8CuW8ummSAwvkoqtN0= Received: by 10.67.19.9 with SMTP id w9mr4788343ugi.86.1202437358485; Thu, 07 Feb 2008 18:22:38 -0800 (PST) Received: by 10.67.30.5 with HTTP; Thu, 7 Feb 2008 18:22:38 -0800 (PST) Message-ID: Date: Fri, 8 Feb 2008 00:22:38 -0200 From: "Carlos A. M. dos Santos" To: freebsd-stable@freebsd.org In-Reply-To: <47AA0E3E.4020304@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 02:22:40 -0000 On Feb 6, 2008 5:45 PM, Dominic Fandrey wrote: > Chuck Swiger wrote: > > Hi, Dominic-- > > > > On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote: > >>> behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone > >>> thinks it might be helpful, I can supply you with a dmesg and the > >>> output of pciconf -lv. > >> > >> The problem remains with fresh sources: > >> > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND > >> 12 root 1 171 ki31 0K 16K RUN 0 22:04 97.85% > >> idle: cpu0 > >> 37 root 1 -64 - 0K 16K CPU1 1 2:35 96.00% > >> irq14: ata0 > >> 11 root 1 171 ki31 0K 16K RUN 1 19:32 6.40% > >> idle: cpu1 > >> > >> The rip is done by k3b, so the drive is accessed through the cam > >> interface. > > > > What are the values being reported by "sysctl hw.ata"? If you're going > > to be burning CD/DVDs, you really want to make sure hw.ata.atapi_dma is on. > > I cannot believe it was so trivial. The sysctl looks all right. > > # sysctl hw.ata 0 /root > hw.ata.wc: 1 > hw.ata.atapi_dma: 1 > hw.ata.ata_dma: 1 > > But further research revealed: > # atacontrol mode acd0 0 /root > current mode = PIO4 > > # atacontrol mode acd0 udma33 0 /root > > changed the load dramatically: > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root 1 171 ki31 0K 16K RUN 0 52:54 100.00% idle: cpu0 > 11 root 1 171 ki31 0K 16K CPU1 1 23:36 94.29% idle: cpu1 > 1087 kamikaze 3 -8 0 133M 36168K physrd 1 1:09 3.17% k3b > 37 root 1 -64 - 0K 16K WAIT 1 30:10 0.00% irq14: ata0 > > > Thank you very much! I used to think that UDMA33 was the default for > CD-/DVD-Rom drives. I suppose I should review the BIOS settings or change > something in the hints file. Wow, now I'm *really* surprised. I used to think that putting hw.ata.ata_dma="1" hw.ata.atapi_dma="1" in /boot/loader.conf would be enough to enable DMA mode. In fact I'm pretty sure it used to be in previous versions of FreeBSD. I created a /etc/rc.local containing #!/bin/sh - atacontrol mode acd0 udma33 Two questions, now: 1. Is this related to using atapicam? 2. Should this be considered a bug? -- Carlos A. M. dos Santos From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 05:34:58 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B836716A421; Fri, 8 Feb 2008 05:34:58 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 070C413C4E5; Fri, 8 Feb 2008 05:34:57 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m185ALtD050349; Fri, 8 Feb 2008 12:10:21 +0700 (KRAT) (envelope-from eugen@kuzbass.ru) Message-ID: <47ABE4B1.1711B94B@kuzbass.ru> Date: Fri, 08 Feb 2008 12:12:17 +0700 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Ruslan Ermilov References: <20071028211538.GA92424@intserv.int1.b.intern> <200710290119.l9T1Jpvs009149@satan.anjos.strangled.net> <20080207161357.GA65774@team.vega.ru> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Cc: hk@alogis.com, stable@FreeBSD.org, Miguel Lopes Santos Ramos Subject: Re: date manupulation strangeness 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, 08 Feb 2008 05:34:58 -0000 Ruslan Ermilov wrote: > > In summary, I think we should move line 268 to line 191 and erase the comment > > on line 267 (mktime() is no one to decide, strptime() must have the final word). > > > I've committed a different fix, so that it doesn't re-introduce the bug fixed > in rev. 1.36 (or 1.32.2.4, which was an MFC of 1.36). Thanks! Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 06:16:15 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C36F16A41A for ; Fri, 8 Feb 2008 06:16:15 +0000 (UTC) (envelope-from grayfoxbsd@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id 1A86613C465 for ; Fri, 8 Feb 2008 06:16:14 +0000 (UTC) (envelope-from grayfoxbsd@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so5328146pyb.10 for ; Thu, 07 Feb 2008 22:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=WLjx+/bo7XSbqSDUpqizAxihVMX/BRHbvzWuVt70Lrw=; b=LYriLYIKXcPLe4gMrtUwCS1ncwzPIDewIKJVIWXDqzr3r5abks7O7pce32f5GFV4lUfQWsSK2YTwwRZdJMFQjCQql9tZfS/Fb0Gr9em4mjoQ7VkBHI3muw2fbJLlTz3ZW4thgh+SKUcJGSYEhfJWxfp1edFA7pKLU62q6f9s3Q4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=Yt1sGiJXTZEcEa+Ei+xWxr2dRiEmKGlde9XbXpIP1/cVzReqdyyRB+AeGSjlPNaAgwePuOujuEBgPqzDicVz4dBXSpS3x2mEf1hEla7Wz2dFrLIt3y6VhM4wnc7UbYjVVLxJAq1AdAu/du8Rq/J6Hqj1rDtejM4fvycIHPzDBCM= Received: by 10.142.229.4 with SMTP id b4mr6673235wfh.125.1202451373643; Thu, 07 Feb 2008 22:16:13 -0800 (PST) Received: by 10.142.245.2 with HTTP; Thu, 7 Feb 2008 22:16:13 -0800 (PST) Message-ID: Date: Fri, 8 Feb 2008 04:16:13 -0200 From: "Thiago Pollachini" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: D-link ag 530 on freebsd (atheros) 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, 08 Feb 2008 06:16:15 -0000 Hi all, I bought a d-link ag530 pci card and I have a surprise. ath0: mem 0xdffe0000-0xdffeffff irq 18 at device 10.0 on pci0 ath0: unable to collect channel list from hal; regdomain likely 19 country code 0 I remember that we had to use ar5k.c to rewrite the regdomain on the eeprom. Some old ag530 cards I had done successfully, but the newer ones... On mikrotik routeros i have no problem. http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015267.html thanks From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 06:28:01 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DA8516A417 for ; Fri, 8 Feb 2008 06:28:01 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id D025D13C447 for ; Fri, 8 Feb 2008 06:28:00 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 960D0405D18; Fri, 8 Feb 2008 07:27:59 +0100 (CET) Message-ID: <47ABF66E.4040807@bsdforen.de> Date: Fri, 08 Feb 2008 07:27:58 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: "Carlos A. M. dos Santos" References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 06:28:01 -0000 Carlos A. M. dos Santos wrote: > On Feb 6, 2008 5:45 PM, Dominic Fandrey wrote: >> Chuck Swiger wrote: >>> Hi, Dominic-- >>> >>> On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote: >>>>> behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone >>>>> thinks it might be helpful, I can supply you with a dmesg and the >>>>> output of pciconf -lv. >>>> The problem remains with fresh sources: >>>> >>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND >>>> 12 root 1 171 ki31 0K 16K RUN 0 22:04 97.85% >>>> idle: cpu0 >>>> 37 root 1 -64 - 0K 16K CPU1 1 2:35 96.00% >>>> irq14: ata0 >>>> 11 root 1 171 ki31 0K 16K RUN 1 19:32 6.40% >>>> idle: cpu1 >>>> >>>> The rip is done by k3b, so the drive is accessed through the cam >>>> interface. >>> What are the values being reported by "sysctl hw.ata"? If you're going >>> to be burning CD/DVDs, you really want to make sure hw.ata.atapi_dma is on. >> I cannot believe it was so trivial. The sysctl looks all right. >> >> # sysctl hw.ata 0 /root >> hw.ata.wc: 1 >> hw.ata.atapi_dma: 1 >> hw.ata.ata_dma: 1 >> >> But further research revealed: >> # atacontrol mode acd0 0 /root >> current mode = PIO4 >> >> # atacontrol mode acd0 udma33 0 /root >> >> changed the load dramatically: >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 12 root 1 171 ki31 0K 16K RUN 0 52:54 100.00% idle: cpu0 >> 11 root 1 171 ki31 0K 16K CPU1 1 23:36 94.29% idle: cpu1 >> 1087 kamikaze 3 -8 0 133M 36168K physrd 1 1:09 3.17% k3b >> 37 root 1 -64 - 0K 16K WAIT 1 30:10 0.00% irq14: ata0 >> >> >> Thank you very much! I used to think that UDMA33 was the default for >> CD-/DVD-Rom drives. I suppose I should review the BIOS settings or change >> something in the hints file. > > Wow, now I'm *really* surprised. I used to think that putting > > hw.ata.ata_dma="1" > hw.ata.atapi_dma="1" > > in /boot/loader.conf would be enough to enable DMA mode. In fact I'm > pretty sure it used to be in previous versions of FreeBSD. I created a > /etc/rc.local containing > > #!/bin/sh - > atacontrol mode acd0 udma33 > Did you check weather you are affected, before you applied your solution? Only one machine is affected. I put the following into my rc.conf: # Set mode for CD/DVD drive. /sbin/atacontrol mode acd0 2>&1 | /usr/bin/grep PIO > /dev/null 2>&1 \ && /sbin/atacontrol mode acd0 UDMA33 > Two questions, now: > > 1. Is this related to using atapicam? Not for me. > 2. Should this be considered a bug? Yes, but not in FreeBSD. It's a bug in the BIOS of my Notebook. This is a guess, not certainty. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 10:01:43 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE7FE16A418 for ; Fri, 8 Feb 2008 10:01:43 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4F613C442 for ; Fri, 8 Feb 2008 10:01:43 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 0F0758FEFD; Fri, 8 Feb 2008 04:41:53 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 08 Feb 2008 04:41:53 -0500 X-Sasl-enc: Ha3IqUDcv0Z5+GxV+2LsGMoaOfZBl5IdF94UDk5WLzvi 1202463712 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 72A42BA97; Fri, 8 Feb 2008 04:41:52 -0500 (EST) Message-ID: <47AC23DF.5030306@FreeBSD.org> Date: Fri, 08 Feb 2008 09:41:51 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: Paul References: <20080207133127.T50745@bsd4.nyct.net> In-Reply-To: <20080207133127.T50745@bsd4.nyct.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: kevent on UDP sockets 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, 08 Feb 2008 10:01:43 -0000 Paul wrote: > > I'm having trouble with kevent() in connection with UDP sockets > (6.2-STABLE). > > Registering an event seems to work, but when UDP packet arrives on the > socket, kevent returns with 0. > > Is there currently a working support for UDP sockets in kqueue/kevent, > or does it only apply to TCP sockets ? I can't recall specifics but I had a working routing daemon skeleton using UDP with kqueue around 5 years ago. I didn't use oneshot, and treated it much like select() i.e. the input event is level triggered, every time you call you should get the event. This is unlike WSAEventSelect() in Windows which is edge triggered. later BMS From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 13:43:32 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D625816A421 for ; Fri, 8 Feb 2008 13:43:32 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.freebsd.org (Postfix) with ESMTP id 519B713C44B for ; Fri, 8 Feb 2008 13:43:32 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1327206uge.37 for ; Fri, 08 Feb 2008 05:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OxVTuSnspN/YaV+sWhCjU4WBuElYZLJ4nplEY5PN6ow=; b=GzuWMghRO6443TVtymzplvyiL96NtAc5Rc2kHLpEtLmokXKFH9cpph0GVNnMNs3aWLxPnaOqnxvOI7iFGOixJ5GCcGZn/bdVOBgP+L//eGCOldlMWowqr4n49QW5G88rGHeF3LdAhu4lrVclULD61s08elDRmhqoOAukgIPr8Mc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TLQXSlqAeiOI9k9/3RmbOdEIGUqEkV3zIzMdlHMcb68/udxE5IDgL0ekIE8zr4/b3WLZ7hv7LPUZJY+r4gPbG5tddhtWNvWlkpAqSA+6YJYgOs6PV0Z9G2PdEcG5ZRbVL3/lpX5NrMyLx2yeM3/AUhL3RSqA0YXYBBgvzcgqk84= Received: by 10.66.254.19 with SMTP id b19mr5413383ugi.7.1202478210837; Fri, 08 Feb 2008 05:43:30 -0800 (PST) Received: by 10.67.30.5 with HTTP; Fri, 8 Feb 2008 05:43:30 -0800 (PST) Message-ID: Date: Fri, 8 Feb 2008 11:43:30 -0200 From: "Carlos A. M. dos Santos" To: "Dominic Fandrey" In-Reply-To: <47ABF66E.4040807@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> <47ABF66E.4040807@bsdforen.de> Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 13:43:33 -0000 On Feb 8, 2008 4:27 AM, Dominic Fandrey wrote: > > Carlos A. M. dos Santos wrote: > > On Feb 6, 2008 5:45 PM, Dominic Fandrey wrote: > >> Chuck Swiger wrote: > >>> Hi, Dominic-- > >>> > >>> On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote: > >>>>> behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone > >>>>> thinks it might be helpful, I can supply you with a dmesg and the > >>>>> output of pciconf -lv. > >>>> The problem remains with fresh sources: > >>>> > >>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND > >>>> 12 root 1 171 ki31 0K 16K RUN 0 22:04 97.85% > >>>> idle: cpu0 > >>>> 37 root 1 -64 - 0K 16K CPU1 1 2:35 96.00% > >>>> irq14: ata0 > >>>> 11 root 1 171 ki31 0K 16K RUN 1 19:32 6.40% > >>>> idle: cpu1 > >>>> > >>>> The rip is done by k3b, so the drive is accessed through the cam > >>>> interface. > >>> What are the values being reported by "sysctl hw.ata"? If you're going > >>> to be burning CD/DVDs, you really want to make sure hw.ata.atapi_dma is on. > >> I cannot believe it was so trivial. The sysctl looks all right. > >> > >> # sysctl hw.ata 0 /root > >> hw.ata.wc: 1 > >> hw.ata.atapi_dma: 1 > >> hw.ata.ata_dma: 1 > >> > >> But further research revealed: > >> # atacontrol mode acd0 0 /root > >> current mode = PIO4 > >> > >> # atacontrol mode acd0 udma33 0 /root > >> > >> changed the load dramatically: > >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > >> 12 root 1 171 ki31 0K 16K RUN 0 52:54 100.00% idle: cpu0 > >> 11 root 1 171 ki31 0K 16K CPU1 1 23:36 94.29% idle: cpu1 > >> 1087 kamikaze 3 -8 0 133M 36168K physrd 1 1:09 3.17% k3b > >> 37 root 1 -64 - 0K 16K WAIT 1 30:10 0.00% irq14: ata0 > >> > >> > >> Thank you very much! I used to think that UDMA33 was the default for > >> CD-/DVD-Rom drives. I suppose I should review the BIOS settings or change > >> something in the hints file. > > > > Wow, now I'm *really* surprised. I used to think that putting > > > > hw.ata.ata_dma="1" > > hw.ata.atapi_dma="1" > > > > in /boot/loader.conf would be enough to enable DMA mode. In fact I'm > > pretty sure it used to be in previous versions of FreeBSD. I created a > > /etc/rc.local containing > > > > #!/bin/sh - > > atacontrol mode acd0 udma33 > > > > Did you check weather you are affected, before you applied your solution? > Only one machine is affected. Yes, it happens in my notebook (HP NX6320). > I put the following into my rc.conf: > # Set mode for CD/DVD drive. > /sbin/atacontrol mode acd0 2>&1 | /usr/bin/grep PIO > /dev/null 2>&1 \ > && /sbin/atacontrol mode acd0 UDMA33 Do not put this in rc.conf. It will be executed again each time a script in /etc/rc.d source rc.conf to obtain the configuration variables. > > Two questions, now: > > > > 1. Is this related to using atapicam? > > Not for me. > > > 2. Should this be considered a bug? > > Yes, but not in FreeBSD. It's a bug in the BIOS of my Notebook. This is a > guess, not certainty. I believe that the kernel must handle this transparently when hw.ata.atapi_dma is set to 1, but I will need to look at the code this to see what is happening. -- Carlos A. M. dos Santos From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 14:23:38 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DEE216A469 for ; Fri, 8 Feb 2008 14:23:38 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id BE4C413C45B for ; Fri, 8 Feb 2008 14:23:36 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (vpn-cl-162-193.rz.uni-karlsruhe.de [141.3.162.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 9D234405478; Fri, 8 Feb 2008 15:25:30 +0100 (CET) Message-ID: <47AC65E5.8080604@bsdforen.de> Date: Fri, 08 Feb 2008 15:23:33 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: "Carlos A. M. dos Santos" References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> <47ABF66E.4040807@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 14:23:38 -0000 Carlos A. M. dos Santos wrote: > On Feb 8, 2008 4:27 AM, Dominic Fandrey wrote: >> Carlos A. M. dos Santos wrote: >>> On Feb 6, 2008 5:45 PM, Dominic Fandrey wrote: >>>> Chuck Swiger wrote: >>>>> Hi, Dominic-- >>>>> >>>>> On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote: >>>>>>> behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone >>>>>>> thinks it might be helpful, I can supply you with a dmesg and the >>>>>>> output of pciconf -lv. >>>>>> The problem remains with fresh sources: >>>>>> >>>>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND >>>>>> 12 root 1 171 ki31 0K 16K RUN 0 22:04 97.85% >>>>>> idle: cpu0 >>>>>> 37 root 1 -64 - 0K 16K CPU1 1 2:35 96.00% >>>>>> irq14: ata0 >>>>>> 11 root 1 171 ki31 0K 16K RUN 1 19:32 6.40% >>>>>> idle: cpu1 >>>>>> >>>>>> The rip is done by k3b, so the drive is accessed through the cam >>>>>> interface. >>>>> What are the values being reported by "sysctl hw.ata"? If you're going >>>>> to be burning CD/DVDs, you really want to make sure hw.ata.atapi_dma is on. >>>> I cannot believe it was so trivial. The sysctl looks all right. >>>> >>>> # sysctl hw.ata 0 /root >>>> hw.ata.wc: 1 >>>> hw.ata.atapi_dma: 1 >>>> hw.ata.ata_dma: 1 >>>> >>>> But further research revealed: >>>> # atacontrol mode acd0 0 /root >>>> current mode = PIO4 >>>> >>>> # atacontrol mode acd0 udma33 0 /root >>>> >>>> changed the load dramatically: >>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >>>> 12 root 1 171 ki31 0K 16K RUN 0 52:54 100.00% idle: cpu0 >>>> 11 root 1 171 ki31 0K 16K CPU1 1 23:36 94.29% idle: cpu1 >>>> 1087 kamikaze 3 -8 0 133M 36168K physrd 1 1:09 3.17% k3b >>>> 37 root 1 -64 - 0K 16K WAIT 1 30:10 0.00% irq14: ata0 >>>> >>>> >>>> Thank you very much! I used to think that UDMA33 was the default for >>>> CD-/DVD-Rom drives. I suppose I should review the BIOS settings or change >>>> something in the hints file. >>> Wow, now I'm *really* surprised. I used to think that putting >>> >>> hw.ata.ata_dma="1" >>> hw.ata.atapi_dma="1" >>> >>> in /boot/loader.conf would be enough to enable DMA mode. In fact I'm >>> pretty sure it used to be in previous versions of FreeBSD. I created a >>> /etc/rc.local containing >>> >>> #!/bin/sh - >>> atacontrol mode acd0 udma33 >>> >> Did you check weather you are affected, before you applied your solution? >> Only one machine is affected. > > Yes, it happens in my notebook (HP NX6320). > >> I put the following into my rc.conf: >> # Set mode for CD/DVD drive. >> /sbin/atacontrol mode acd0 2>&1 | /usr/bin/grep PIO > /dev/null 2>&1 \ >> && /sbin/atacontrol mode acd0 UDMA33 > > Do not put this in rc.conf. It will be executed again each time a > script in /etc/rc.d source rc.conf to obtain the configuration > variables. Hence the check, weather the drive is in PIO mode or not. The way I understand the rc(8) manual page, the same is true for rc.local. > >>> Two questions, now: >>> >>> 1. Is this related to using atapicam? >> Not for me. >> >>> 2. Should this be considered a bug? >> Yes, but not in FreeBSD. It's a bug in the BIOS of my Notebook. This is a >> guess, not certainty. > > I believe that the kernel must handle this transparently when > hw.ata.atapi_dma is set to 1, but I will need to look at the code this > to see what is happening. I think it's the job of the BIOS to set this properly. Many BIOS allow you to choose the mode and FreeBSD obeys the settings made in the BIOS. To me that makes sense. It's a problem of HP that they do not allow to change the setting and have chosen such an ill fit default. Also you cannot just send everything into DMA mode, because all devices can have different capabilities. My preferred solution would be to have device hints for every device to override the BIOS settings. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 14:36:32 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D010D16A417 for ; Fri, 8 Feb 2008 14:36:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 81AB213C461 for ; Fri, 8 Feb 2008 14:36:32 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id m18EaSCi063304; Fri, 8 Feb 2008 06:36:28 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id m18EaSIZ063303; Fri, 8 Feb 2008 06:36:28 -0800 (PST) (envelope-from david) Date: Fri, 8 Feb 2008 06:36:27 -0800 From: David Wolfskill To: Dominic Fandrey Message-ID: <20080208143627.GL53191@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , Dominic Fandrey , "Carlos A. M. dos Santos" , freebsd-stable@freebsd.org References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> <47ABF66E.4040807@bsdforen.de> <47AC65E5.8080604@bsdforen.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4IYkFBVPN84tP7K" Content-Disposition: inline In-Reply-To: <47AC65E5.8080604@bsdforen.de> User-Agent: Mutt/1.4.2.1i Cc: "Carlos A. M. dos Santos" , freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 14:36:32 -0000 --T4IYkFBVPN84tP7K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2008 at 03:23:33PM +0100, Dominic Fandrey wrote: > Carlos A. M. dos Santos wrote: > >On Feb 8, 2008 4:27 AM, Dominic Fandrey wrote: > >>... > >>I put the following into my rc.conf: > >># Set mode for CD/DVD drive. > >>/sbin/atacontrol mode acd0 2>&1 | /usr/bin/grep PIO > /dev/null 2>&1 \ > >> && /sbin/atacontrol mode acd0 UDMA33 > > > >Do not put this in rc.conf. It will be executed again each time a > >script in /etc/rc.d source rc.conf to obtain the configuration > >variables. >=20 > Hence the check, weather the drive is in PIO mode or not. The way I=20 > understand the rc(8) manual page, the same is true for rc.local. >... As I learned some years ago, rc.conf is for configuration variable-setting, not executable code. Ref. (from rc.conf(5)): DESCRIPTION The file rc.conf contains descriptive information about the local host name, configuration details for any potential network interfaces and which services should be started up at system initial boot time.... /usr/local/etc/rc.d/* generally contains executable code, though. Peace, david --=20 David H. Wolfskill david@catwhisker.org I submit that "conspiracy" would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --T4IYkFBVPN84tP7K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkesaOsACgkQmprOCmdXAD0wmQCeNj2aiEsiYmh7LNlbaikuMq0r 1kwAn0cIJACJJTBI5v0n5txDII1kXuL0 =MTI+ -----END PGP SIGNATURE----- --T4IYkFBVPN84tP7K-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 14:40:43 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E53E16A477 for ; Fri, 8 Feb 2008 14:40:42 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id 6A88213C45B for ; Fri, 8 Feb 2008 14:40:42 +0000 (UTC) (envelope-from primeroz.lists@googlemail.com) Received: by rv-out-0910.google.com with SMTP id g13so2826028rvb.43 for ; Fri, 08 Feb 2008 06:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=kxPa1q0OhiutfMc1YDPKE+BD+sgArHVLMqtpdJ3weu0=; b=TtYUKuYar8f7bxSoiLmbkGOHIxOG35jKSja4owHoN9HAcCWD5uGIM70K4T27B25FalIqFEOUkN+iBt52yHd1RnNGWtIAIPnTmej2nw/BFLIfJ+gTPDUh2lzFkSzTSW33RV3MWzvvFhMvYzI9858WhukRgY3453KrE3ymePeN/Jw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YqnRZ3qSfHWNCgplDKYMFgtufmuNR9nhVERKwo13slpoA6yugVPgsbnI94NAGorALvD2VDE25JqCEziw9A43eVC28/YvjFuEC1D5IH/6g58mL49gtB89EnkFjpNtzd1lumYIM2rt2tAfYslE5VHW/TwgLAUNtB4VlNKg6CvB9hU= Received: by 10.140.141.15 with SMTP id o15mr8559713rvd.2.1202481642011; Fri, 08 Feb 2008 06:40:42 -0800 (PST) Received: by 10.140.203.6 with HTTP; Fri, 8 Feb 2008 06:40:41 -0800 (PST) Message-ID: <55b8c6fe0802080640l39fc5056gf02c1f64b4120594@mail.gmail.com> Date: Fri, 8 Feb 2008 14:40:41 +0000 From: "Primeroz lists" To: "Tom Samplonius" In-Reply-To: <55b8c6fe0802060131y6e0e27d8j4e7db10381c6bfab@mail.gmail.com> MIME-Version: 1.0 References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <28875927.5811202240277979.JavaMail.root@ly.sdf.com> <55b8c6fe0802060131y6e0e27d8j4e7db10381c6bfab@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 08 Feb 2008 14:40:43 -0000 U2VydmVyIGtlZXBzIGNyYXNoaW5nLCBJIG1hZ2VkIHRvIGhhdmUgYSBuZXcgY29yZWR1bXAgdGhh dCBzaG91bGQgYmUKcmVsaWFibGUgdGhpcyB0aW1lLgoKSGVyZSBpcyB0aGUgZGVidWdnaW5nIG9m IHRoZSBrZXJuZWwgLi4uIGknbSBub3QgcmVhbGx5IGFuIGV4cGVydCBpbiB0aGlzCnRvcGljIHNv IGlmIHlvdSBuZWVkIGFueSBtb3JlIGluZm9ybWF0aW9uIGp1c3QgbGV0IG1lIGtub3cgYW5kIGkg d2lsbCBkbyBteQpiZXN0IHRvIHByb3ZpZGUgaXQuCgpbR0RCIHdpbGwgbm90IGJlIGFibGUgdG8g ZGVidWcgdXNlci1tb2RlIHRocmVhZHM6IC91c3IvbGliL2xpYnRocmVhZF9kYi5zbzoKVW5kZWZp bmVkIHN5bWJvbCAicHNfcGdsb2JhbF9sb29rdXAiXQpHTlUgZ2RiIDYuMS4xIFtGcmVlQlNEXQpD b3B5cmlnaHQgMjAwNCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KR0RCIGlzIGZyZWUg c29mdHdhcmUsIGNvdmVyZWQgYnkgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCBhbmQg eW91IGFyZQp3ZWxjb21lIHRvIGNoYW5nZSBpdCBhbmQvb3IgZGlzdHJpYnV0ZSBjb3BpZXMgb2Yg aXQgdW5kZXIgY2VydGFpbgpjb25kaXRpb25zLgpUeXBlICJzaG93IGNvcHlpbmciIHRvIHNlZSB0 aGUgY29uZGl0aW9ucy4KVGhlcmUgaXMgYWJzb2x1dGVseSBubyB3YXJyYW50eSBmb3IgR0RCLiAg VHlwZSAic2hvdyB3YXJyYW50eSIgZm9yIGRldGFpbHMuClRoaXMgR0RCIHdhcyBjb25maWd1cmVk IGFzICJhbWQ2NC1tYXJjZWwtZnJlZWJzZCIuCgpVbnJlYWQgcG9ydGlvbiBvZiB0aGUga2VybmVs IG1lc3NhZ2UgYnVmZmVyOgoKCkZhdGFsIHRyYXAgOTogZ2VuZXJhbCBwcm90ZWN0aW9uIGZhdWx0 IHdoaWxlIGluIGtlcm5lbCBtb2RlCmNwdWlkID0gNTsgYXBpYyBpZCA9IDA1Cmluc3RydWN0aW9u IHBvaW50ZXIgICAgID0gMHg4OjB4ZmZmZmZmZmY4MDJhZjVlMwpzdGFjayBwb2ludGVyICAgICAg ICAgICA9IDB4MTA6MHhmZmZmZmZmZmJhMjI0OTgwCmZyYW1lIHBvaW50ZXIgICAgICAgICAgID0g MHgxMDoweDE1NmE5CmNvZGUgc2VnbWVudCAgICAgICAgICAgID0gYmFzZSAweDAsIGxpbWl0IDB4 ZmZmZmYsIHR5cGUgMHgxYgogICAgICAgICAgICAgICAgICAgICAgICA9IERQTCAwLCBwcmVzIDEs IGxvbmcgMSwgZGVmMzIgMCwgZ3JhbiAxCnByb2Nlc3NvciBlZmxhZ3MgICAgICAgID0gaW50ZXJy dXB0IGVuYWJsZWQsIHJlc3VtZSwgSU9QTCA9IDAKY3VycmVudCBwcm9jZXNzICAgICAgICAgPSAx MDcwIChteXNxbGQpCnRyYXAgbnVtYmVyICAgICAgICAgICAgID0gOQpwYW5pYzogZ2VuZXJhbCBw cm90ZWN0aW9uIGZhdWx0CmNwdWlkID0gNQpVcHRpbWU6IDFkMGgyMm0xcwpEdW1waW5nIDgxOTEg TUIgKDMgY2h1bmtzKQogIGNodW5rIDA6IDFNQiAoMTU2IHBhZ2VzKSAuLi4gb2sKICBjaHVuayAx OiAzMzI3TUIgKDg1MTYyNCBwYWdlcykgMzMxMSAzMjk1IDMyNzkgMzI2MyAzMjQ3IDMyMzEgMzIx NSAzMTk5CjMxODMgMzE2NyAzMTUxIDMxMzUgMzExOSAzMTAzIDMwODcgMzA3MSAzMDU1IDMwMzkg MzAyMyAzMDA3IDI5OTEgMjk3NSAyOTU5CjI5NDMgMjkyNyAyOTExIDI4OTUgMjg3OSAyODYzIDI4 NDcgMjgzMSAyODE1IDI3OTkgMjc4MyAyNzY3IDI3NTEgMjczNSAyNzE5CjI3MDMgMjY4NyAyNjcx IDI2NTUgMjYzOSAyNjIzIDI2MDcgMjU5MSAyNTc1IDI1NTkgMjU0MyAyNTI3IDI1MTEgMjQ5NSAy NDc5CjI0NjMgMjQ0NyAyNDMxIDI0MTUgMjM5OSAyMzgzIDIzNjcgMjM1MSAyMzM1IDIzMTkgMjMw MyAyMjg3IDIyNzEgMjI1NSAyMjM5CjIyMjMgMjIwNyAyMTkxIDIxNzUgMjE1OSAyMTQzIDIxMjcg MjExMSAyMDk1IDIwNzkgMjA2MyAyMDQ3IDIwMzEgMjAxNSAxOTk5CjE5ODMgMTk2NyAxOTUxIDE5 MzUgMTkxOSAxOTAzIDE4ODcgMTg3MSAxODU1IDE4MzkgMTgyMyAxODA3IDE3OTEgMTc3NSAxNzU5 CjE3NDMgMTcyNyAxNzExIDE2OTUgMTY3OSAxNjYzIDE2NDcgMTYzMSAxNjE1IDE1OTkgMTU4MyAx NTY3IDE1NTEgMTUzNSAxNTE5CjE1MDMgMTQ4NyAxNDcxIDE0NTUgMTQzOSAxNDIzIDE0MDcgMTM5 MSAxMzc1IDEzNTkgMTM0MyAxMzI3IDEzMTEgMTI5NSAxMjc5CjEyNjMgMTI0NyAxMjMxIDEyMTUg MTE5OSAxMTgzIDExNjcgMTE1MSAxMTM1IDExMTkgMTEwMyAxMDg3IDEwNzEgMTA1NSAxMDM5CjEw MjMgMTAwNyA5OTEgOTc1IDk1OSA5NDMgOTI3IDkxMSA4OTUgODc5IDg2MyA4NDcgODMxIDgxNSA3 OTkgNzgzIDc2NyA3NTEKNzM1IDcxOSA3MDMgNjg3IDY3MSA2NTUgNjM5IDYyMyA2MDcgNTkxIDU3 NSA1NTkgNTQzIDUyNyA1MTEgNDk1IDQ3OSA0NjMgNDQ3CjQzMSA0MTUgMzk5IDM4MyAzNjcgMzUx IDMzNSAzMTkgMzAzIDI4NyAyNzEgMjU1IDIzOSAyMjMgMjA3IDE5MSAxNzUgMTU5IDE0MwoxMjcg MTExIDk1IDc5IDYzIDQ3IDMxIDE1IC4uLiBvawogIGNodW5rIDI6IDQ4NjRNQiAoMTI0NTE4NCBw YWdlcykgNDg0OSA0ODMzIDQ4MTcgNDgwMSA0Nzg1IDQ3NjkgNDc1MyA0NzM3CjQ3MjEgNDcwNSA0 Njg5IDQ2NzMgNDY1NyA0NjQxIDQ2MjUgNDYwOSA0NTkzIDQ1NzcgNDU2MSA0NTQ1IDQ1MjkgNDUx MyA0NDk3CjQ0ODEgNDQ2NSA0NDQ5IDQ0MzMgNDQxNyA0NDAxIDQzODUgNDM2OSA0MzUzIDQzMzcg NDMyMSA0MzA1IDQyODkgNDI3MyA0MjU3CjQyNDEgNDIyNSA0MjA5IDQxOTMgNDE3NyA0MTYxIDQx NDUgNDEyOSA0MTEzIDQwOTcgNDA4MSA0MDY1IDQwNDkgNDAzMyA0MDE3CjQwMDEgMzk4NSAzOTY5 IDM5NTMgMzkzNyAzOTIxIDM5MDUgMzg4OSAzODczIDM4NTcgMzg0MSAzODI1IDM4MDkgMzc5MyAz Nzc3CjM3NjEgMzc0NSAzNzI5IDM3MTMgMzY5NyAzNjgxIDM2NjUgMzY0OSAzNjMzIDM2MTcgMzYw MSAzNTg1IDM1NjkgMzU1MyAzNTM3CjM1MjEgMzUwNSAzNDg5IDM0NzMgMzQ1NyAzNDQxIDM0MjUg MzQwOSAzMzkzIDMzNzcgMzM2MSAzMzQ1IDMzMjkgMzMxMyAzMjk3CjMyODEgMzI2NSAzMjQ5IDMy MzMgMzIxNyAzMjAxIDMxODUgMzE2OSAzMTUzIDMxMzcgMzEyMSAzMTA1IDMwODkgMzA3MyAzMDU3 CjMwNDEgMzAyNSAzMDA5IDI5OTMgMjk3NyAyOTYxIDI5NDUgMjkyOSAyOTEzIDI4OTcgMjg4MSAy ODY1IDI4NDkgMjgzMyAyODE3CjI4MDEgMjc4NSAyNzY5IDI3NTMgMjczNyAyNzIxIDI3MDUgMjY4 OSAyNjczIDI2NTcgMjY0MSAyNjI1IDI2MDkgMjU5MyAyNTc3CjI1NjEgMjU0NSAyNTI5IDI1MTMg MjQ5NyAyNDgxIDI0NjUgMjQ0OSAyNDMzIDI0MTcgMjQwMSAyMzg1IDIzNjkgMjM1MyAyMzM3CjIz MjEgMjMwNSAyMjg5IDIyNzMgMjI1NyAyMjQxIDIyMjUgMjIwOSAyMTkzIDIxNzcgMjE2MSAyMTQ1 IDIxMjkgMjExMyAyMDk3CjIwODEgMjA2NSAyMDQ5IDIwMzMgMjAxNyAyMDAxIDE5ODUgMTk2OSAx OTUzIDE5MzcgMTkyMSAxOTA1IDE4ODkgMTg3MyAxODU3CjE4NDEgMTgyNSAxODA5IDE3OTMgMTc3 NyAxNzYxIDE3NDUgMTcyOSAxNzEzIDE2OTcgMTY4MSAxNjY1IDE2NDkgMTYzMyAxNjE3CjE2MDEg MTU4NSAxNTY5IDE1NTMgMTUzNyAxNTIxIDE1MDUgMTQ4OSAxNDczIDE0NTcgMTQ0MSAxNDI1IDE0 MDkgMTM5MyAxMzc3CjEzNjEgMTM0NSAxMzI5IDEzMTMgMTI5NyAxMjgxIDEyNjUgMTI0OSAxMjMz IDEyMTcgMTIwMSAxMTg1IDExNjkgMTE1MyAxMTM3CjExMjEgMTEwNSAxMDg5IDEwNzMgMTA1NyAx MDQxIDEwMjUgMTAwOSA5OTMgOTc3IDk2MSA5NDUgOTI5IDkxMyA4OTcgODgxIDg2NQo4NDkgODMz IDgxNyA4MDEgNzg1IDc2OSA3NTMgNzM3IDcyMSA3MDUgNjg5IDY3MyA2NTcgNjQxIDYyNSA2MDkg NTkzIDU3NyA1NjEKNTQ1IDUyOSA1MTMgNDk3IDQ4MSA0NjUgNDQ5IDQzMyA0MTcgNDAxIDM4NSAz NjkgMzUzIDMzNyAzMjEgMzA1IDI4OSAyNzMgMjU3CjI0MSAyMjUgMjA5IDE5MyAxNzcgMTYxIDE0 NSAxMjkgMTEzIDk3IDgxIDY1IDQ5IDMzIDE3IDEKCiMwICBkb2FkdW1wICgpIGF0IHBjcHUuaDox NzIKMTcyICAgICBwY3B1Lmg6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkuCiAgICAgICAgaW4g cGNwdS5oCihrZ2RiKSBsaXN0ICoweGZmZmZmZmZmODAyYWY1ZTMKMHhmZmZmZmZmZjgwMmFmNWUz IGlzIGluIF9zeF94bG9jayAoL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zeC5jOjE5MikuCjE4NyAg ICAgICAgICAgICBMT0NLX0xPR19MT0NLKCJYTE9DSyIsICZzeC0+c3hfb2JqZWN0LCAwLCAwLCBm aWxlLCBsaW5lKTsKMTg4ICAgICAgICAgICAgIFdJVE5FU1NfTE9DSygmc3gtPnN4X29iamVjdCwg TE9QX0VYQ0xVU0lWRSwgZmlsZSwgbGluZSk7CjE4OSAgICAgICAgICAgICBjdXJ0aHJlYWQtPnRk X2xvY2tzKys7CjE5MAoxOTEgICAgICAgICAgICAgbXR4X3VubG9jayhzeC0+c3hfbG9jayk7CjE5 MiAgICAgfQoxOTMKMTk0ICAgICBpbnQKMTk1ICAgICBfc3hfdHJ5X3hsb2NrKHN0cnVjdCBzeCAq c3gsIGNvbnN0IGNoYXIgKmZpbGUsIGludCBsaW5lKQoxOTYgICAgIHsKKGtnZGIpIGJ0CiMwICBk b2FkdW1wICgpIGF0IHBjcHUuaDoxNzIKIzEgIDB4MDAwMDAwMDAwMDAwMDAwNCBpbiA/PyAoKQoj MiAgMHhmZmZmZmZmZjgwMmE3ZDY3IGluIGJvb3QgKGhvd3RvPTI2MCkgYXQKL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9zaHV0ZG93bi5jOjQwOQojMyAgMHhmZmZmZmZmZjgwMmE4NDAxIGluIHBhbmlj IChmbXQ9MHhmZmZmZmYwMGI3MjNmMjYwCiLvv70m77+9XDIwN1wwMDHvv73vv73vv71cMjAwZFww Mjfvv71cMDAx77+977+977+977+977+9I++/vSIpCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9r ZXJuX3NodXRkb3duLmM6NTY1CiM0ICAweGZmZmZmZmZmODA0MjVmN2YgaW4gdHJhcF9mYXRhbCAo ZnJhbWU9MHhmZmZmZmYwMGI3MjNmMjYwLApldmE9MTg0NDY3NDI5ODA3NzM5NDcwNTYpIGF0IC91 c3Ivc3JjL3N5cy9hbWQ2NC9hbWQ2NC90cmFwLmM6NjYwCiM1ICAweGZmZmZmZmZmODA0MjY0MjIg aW4gdHJhcCAoZnJhbWU9CiAgICAgIHt0Zl9yZGkgPSAtMjE0MDkzNzkzNiwgdGZfcnNpID0gNCwg dGZfcmR4ID0gLTIxNDA5Mzc5MzYsIHRmX3JjeCA9IDEsCnRmX3I4ID0gLTEwOTI3NzE0MzQzNDQs IHRmX3I5ID0gLTExNzIxNTc5MjAsIHRmX3JheCA9IDEsIHRmX3JieCA9Ci0yMTQ0NjY0ODk5LCB0 Zl9yYnAgPSA4NzcyMSwgdGZfcjEwID0gLTEwOTY0MzkwNDE0NDAsIHRmX3IxMSA9IDQzNTgzNjU5 MCwKdGZfcjEyID0gLTEwOTc0NTc4ODAwMDAsIHRmX3IxMyA9IC0xMDkyNzcxNDM0MzUyLCB0Zl9y MTQgPSA0MzU4MzU1MjAsIHRmX3IxNQo9IC0xMTcyMTU3OTI4LCB0Zl90cmFwbm8gPSA5LCB0Zl9h ZGRyID0gMCwgdGZfZmxhZ3MgPSAtMjE0NDYwNzAxOCwgdGZfZXJyID0KMCwgdGZfcmlwID0gLTIx NDQ2NjgxODksIHRmX2NzID0gOCwgdGZfcmZsYWdzID0gNjYxODIsIHRmX3JzcCA9IC0xMTcyMTU4 MDU2LAp0Zl9zcyA9IDE2fSkgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAuYzo0NjkK IzYgIDB4ZmZmZmZmZmY4MDQxMTczYiBpbiBjYWxsdHJhcCAoKSBhdAovdXNyL3NyYy9zeXMvYW1k NjQvYW1kNjQvZXhjZXB0aW9uLlM6MTY4CiM3ICAweGZmZmZmZmZmODAyYWY1ZTMgaW4gX3N4X3hs b2NrIChzeD0weGZmZmZmZmZmODAyYjAyYmQsIGZpbGU9MHg0CjxBZGRyZXNzIDB4NCBvdXQgb2Yg Ym91bmRzPiwgbGluZT0tMjE0MDkzNzkzNikKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f c3guYzoxOTIKIzggIDB4ZmZmZmZmMDE5MWJmMzA5OCBpbiA/PyAoKQojOSAgMHgwMmZmZmYwMGI3 MjNmMjYwIGluID8/ICgpCiMxMCAweGZmZmZmZmZmYmEyMjRhMTAgaW4gPz8gKCkKIzExIDB4ZmZm ZmZmMDE5MWJmMzA5MCBpbiA/PyAoKQojMTIgMHgwMDAwMDAwMDE5ZmE1MjgwIGluID8/ICgpCiMx MyAweGZmZmZmZjAwYjcyM2YyNjAgaW4gPz8gKCkKIzE0IDB4ZmZmZmZmMDE5MWJmMzA5MCBpbiA/ PyAoKQojMTUgMHgwMDAwMDAwMDAwMDAwMDA0IGluID8/ICgpCiMxNiAweDAwMDAwMDAwMDAwMDAw MDAgaW4gPz8gKCkKIzE3IDB4ZmZmZmZmZmY4MDJiODQ1ZSBpbiB1bXR4X2tleV9nZXQgKHRkPTB4 ZmZmZmZmMDA3YTY5YjQ0MCwKdW10eD0weGZmZmZmZmZmYmEyMjRhMjAsIGtleT0weDE1NmE5KQog ICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl91bXR4LmM6MzEyCiMxOCAweGZmZmZmZmZmODAy Yjg1NzggaW4gX2RvX2xvY2sgKHRkPTB4ZmZmZmZmMDBiNzIzZjI2MCwgdW10eD0weDE5ZmE1Mjgw LAppZD0xMDA2NTQsIHRpbW89MCkKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5j OjM2MgojMTkgMHhmZmZmZmZmZjgwMmI5OWU5IGluIF91bXR4X29wICh0ZD0weGZmZmZmZjAwYjcy M2YyNjAsIHVhcD0weDE4OTJlKSBhdAovdXNyL3NyYy9zeXMva2Vybi9rZXJuX3VtdHguYzo1NDUK IzIwIDB4ZmZmZmZmZmY4MDQyNmRkMSBpbiBzeXNjYWxsIChmcmFtZT0KICAgICAge3RmX3JkaSA9 IDQzNTgzNTUyMCwgdGZfcnNpID0gMCwgdGZfcmR4ID0gMTAwNjU0LCB0Zl9yY3ggPSAwLCB0Zl9y OCA9CjAsIHRmX3I5ID0gMTQwNzM3NDM3NDY0MzQ0LCB0Zl9yYXggPSA0NTQsIHRmX3JieCA9IDEw MDY1NCwgdGZfcmJwID0KNDM1ODM1NTIwLCB0Zl9yMTAgPSAxLCB0Zl9yMTEgPSA1ODIsIHRmX3Ix MiA9IDk5ODIxMjgsIHRmX3IxMyA9IDEwMjQsIHRmX3IxNAo9IDAsIHRmX3IxNSA9IDAsIHRmX3Ry YXBubyA9IDEyLCB0Zl9hZGRyID0gMTM5OTc5NTcxMiwgdGZfZmxhZ3MgPQo0Mjk0OTAyMDA0LCB0 Zl9lcnIgPSAyLCB0Zl9yaXAgPSAzNDM3ODIwNjc4MCwgdGZfY3MgPSA0MywgdGZfcmZsYWdzID0g NTgyLAp0Zl9yc3AgPSAxNDA3Mzc0Mzc0NjQyMzIsIHRmX3NzID0gMzV9KSBhdAovdXNyL3NyYy9z eXMvYW1kNjQvYW1kNjQvdHJhcC5jOjc5MgojMjEgMHhmZmZmZmZmZjgwNDExOGQ4IGluIFhmYXN0 X3N5c2NhbGwgKCkgYXQKL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlvbi5TOjI3MAoj MjIgMHgwMDAwMDAwODAxMTljZTNjIGluID8/ICgpClByZXZpb3VzIGZyYW1lIGlubmVyIHRvIHRo aXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQooa2dkYikgdXAgNwojNyAgMHhmZmZmZmZmZjgwMmFm NWUzIGluIF9zeF94bG9jayAoc3g9MHhmZmZmZmZmZjgwMmIwMmJkLCBmaWxlPTB4NAo8QWRkcmVz cyAweDQgb3V0IG9mIGJvdW5kcz4sIGxpbmU9LTIxNDA5Mzc5MzYpCiAgICBhdCAvdXNyL3NyYy9z eXMva2Vybi9rZXJuX3N4LmM6MTkyCjE5MiAgICAgfQooa2dkYikgdXAKIzggIDB4ZmZmZmZmMDE5 MWJmMzA5OCBpbiA/PyAoKQooa2dkYikgdXAKIzkgIDB4MDJmZmZmMDBiNzIzZjI2MCBpbiA/PyAo KQooa2dkYikgdXAKIzEwIDB4ZmZmZmZmZmZiYTIyNGExMCBpbiA/PyAoKQooa2dkYikgdXAKIzEx IDB4ZmZmZmZmMDE5MWJmMzA5MCBpbiA/PyAoKQooa2dkYikgdXAKIzEyIDB4MDAwMDAwMDAxOWZh NTI4MCBpbiA/PyAoKQooa2dkYikgdXAKIzEzIDB4ZmZmZmZmMDBiNzIzZjI2MCBpbiA/PyAoKQoo a2dkYikgdXAKIzE0IDB4ZmZmZmZmMDE5MWJmMzA5MCBpbiA/PyAoKQooa2dkYikgdXAKIzE1IDB4 MDAwMDAwMDAwMDAwMDAwNCBpbiA/PyAoKQooa2dkYikgdXAKIzE2IDB4MDAwMDAwMDAwMDAwMDAw MCBpbiA/PyAoKQooa2dkYikgdXAKIzE3IDB4ZmZmZmZmZmY4MDJiODQ1ZSBpbiB1bXR4X2tleV9n ZXQgKHRkPTB4ZmZmZmZmMDA3YTY5YjQ0MCwKdW10eD0weGZmZmZmZmZmYmEyMjRhMjAsIGtleT0w eDE1NmE5KQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl91bXR4LmM6MzEyCjMxMiAgICAg ICAgICAgICBpZiAodm1fbWFwX2xvb2t1cCgmbWFwLCAodm1fb2Zmc2V0X3QpdW10eCwgVk1fUFJP VF9XUklURSwKKGtnZGIpIHVwCiMxOCAweGZmZmZmZmZmODAyYjg1NzggaW4gX2RvX2xvY2sgKHRk PTB4ZmZmZmZmMDBiNzIzZjI2MCwgdW10eD0weDE5ZmE1MjgwLAppZD0xMDA2NTQsIHRpbW89MCkK ICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fdW10eC5jOjM2MgozNjIgICAgICAgICAgICAg aWYgKChlcnJvciA9IHVtdHhfa2V5X2dldCh0ZCwgdW10eCwgJnVxLT51cV9rZXkpKSAhPSAwKQoo a2dkYikgbGlzdAozNTcgICAgIHN0YXRpYyBpbmxpbmUgaW50CjM1OCAgICAgdW10eHFfcXVldWVf bWUoc3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCB1bXR4ICp1bXR4LCBzdHJ1Y3QgdW10eF9xCip1 cSkKMzU5ICAgICB7CjM2MCAgICAgICAgICAgICBpbnQgZXJyb3I7CjM2MQozNjIgICAgICAgICAg ICAgaWYgKChlcnJvciA9IHVtdHhfa2V5X2dldCh0ZCwgdW10eCwgJnVxLT51cV9rZXkpKSAhPSAw KQozNjMgICAgICAgICAgICAgICAgICAgICByZXR1cm4gKGVycm9yKTsKMzY0CjM2NSAgICAgICAg ICAgICB1cS0+dXFfYWRkciA9ICh2bV9vZmZzZXRfdCl1bXR4OwozNjYgICAgICAgICAgICAgdXEt PnVxX3RocmVhZCA9IHRkOwooa2dkYikgdXAKIzE5IDB4ZmZmZmZmZmY4MDJiOTllOSBpbiBfdW10 eF9vcCAodGQ9MHhmZmZmZmYwMGI3MjNmMjYwLCB1YXA9MHgxODkyZSkgYXQKL3Vzci9zcmMvc3lz L2tlcm4va2Vybl91bXR4LmM6NTQ1CjU0NSAgICAgICAgICAgICAgICAgICAgIGVycm9yID0gX2Rv X2xvY2sodGQsIHVtdHgsIGlkLCAwKTsKKGtnZGIpIHVwCiMyMCAweGZmZmZmZmZmODA0MjZkZDEg aW4gc3lzY2FsbCAoZnJhbWU9CiAgICAgIHt0Zl9yZGkgPSA0MzU4MzU1MjAsIHRmX3JzaSA9IDAs IHRmX3JkeCA9IDEwMDY1NCwgdGZfcmN4ID0gMCwgdGZfcjggPQowLCB0Zl9yOSA9IDE0MDczNzQz NzQ2NDM0NCwgdGZfcmF4ID0gNDU0LCB0Zl9yYnggPSAxMDA2NTQsIHRmX3JicCA9CjQzNTgzNTUy MCwgdGZfcjEwID0gMSwgdGZfcjExID0gNTgyLCB0Zl9yMTIgPSA5OTgyMTI4LCB0Zl9yMTMgPSAx MDI0LCB0Zl9yMTQKPSAwLCB0Zl9yMTUgPSAwLCB0Zl90cmFwbm8gPSAxMiwgdGZfYWRkciA9IDEz OTk3OTU3MTIsIHRmX2ZsYWdzID0KNDI5NDkwMjAwNCwgdGZfZXJyID0gMiwgdGZfcmlwID0gMzQz NzgyMDY3ODAsIHRmX2NzID0gNDMsIHRmX3JmbGFncyA9IDU4MiwKdGZfcnNwID0gMTQwNzM3NDM3 NDY0MjMyLCB0Zl9zcyA9IDM1fSkgYXQKL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L3RyYXAuYzo3 OTIKNzkyICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlcnJvciA9ICgqY2FsbHAtPnN5X2Nh bGwpKHRkLCBhcmdwKTsKKGtnZGIpIGxpc3QKNzg3ICAgICAgICAgICAgICAgICAgICAgaWYgKChj YWxscC0+c3lfbmFyZyAmIFNZRl9NUFNBRkUpID09IDApIHsKNzg4ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBtdHhfbG9jaygmR2lhbnQpOwo3ODkgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGVycm9yID0gKCpjYWxscC0+c3lfY2FsbCkodGQsIGFyZ3ApOwo3OTAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG10eF91bmxvY2soJkdpYW50KTsKNzkxICAgICAgICAgICAgICAgICAg ICAgfSBlbHNlCjc5MiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXJyb3IgPSAoKmNhbGxw LT5zeV9jYWxsKSh0ZCwgYXJncCk7Cjc5MyAgICAgICAgICAgICB9Cjc5NAo3OTUgICAgICAgICAg ICAgc3dpdGNoIChlcnJvcikgewo3OTYgICAgICAgICAgICAgY2FzZSAwOgooa2dkYikK From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 15:08:58 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37F2016A41B for ; Fri, 8 Feb 2008 15:08:58 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id DB4A613C465 for ; Fri, 8 Feb 2008 15:08:57 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (vpn-cl-162-193.rz.uni-karlsruhe.de [141.3.162.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 51470405478; Fri, 8 Feb 2008 16:10:38 +0100 (CET) Message-ID: <47AC7087.20109@bsdforen.de> Date: Fri, 08 Feb 2008 16:08:55 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: David Wolfskill , Dominic Fandrey , "Carlos A. M. dos Santos" , freebsd-stable@freebsd.org References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> <47ABF66E.4040807@bsdforen.de> <47AC65E5.8080604@bsdforen.de> <20080208143627.GL53191@bunrab.catwhisker.org> In-Reply-To: <20080208143627.GL53191@bunrab.catwhisker.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 15:08:58 -0000 David Wolfskill wrote: > On Fri, Feb 08, 2008 at 03:23:33PM +0100, Dominic Fandrey wrote: >> Carlos A. M. dos Santos wrote: >>> On Feb 8, 2008 4:27 AM, Dominic Fandrey wrote: >>>> ... >>>> I put the following into my rc.conf: >>>> # Set mode for CD/DVD drive. >>>> /sbin/atacontrol mode acd0 2>&1 | /usr/bin/grep PIO > /dev/null 2>&1 \ >>>> && /sbin/atacontrol mode acd0 UDMA33 >>> Do not put this in rc.conf. It will be executed again each time a >>> script in /etc/rc.d source rc.conf to obtain the configuration >>> variables. >> Hence the check, weather the drive is in PIO mode or not. The way I >> understand the rc(8) manual page, the same is true for rc.local. >> ... > > As I learned some years ago, rc.conf is for configuration > variable-setting, not executable code. Ref. (from rc.conf(5)): Why care about correctly implementing a sloppy solution? I'd rather have a good solution correctly implemented. For me that means offering the possibility to tweak the ata mode for each device in the /boot/device.hints file. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 15:45:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F5FD16A420 for ; Fri, 8 Feb 2008 15:45:09 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 875C413C469 for ; Fri, 8 Feb 2008 15:45:08 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by mu-out-0910.google.com with SMTP id w9so3086352mue.6 for ; Fri, 08 Feb 2008 07:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; bh=Y93sPgCWSsUhYwMi9PwZhZdaMafSRGQtR4QvbafJxN0=; b=P4L5Jt+05YcP+popMCirx7QFz2rdf1bPaBKzXt5xtr4blxWQCbkcOkuMuW6awCblAy/1r0euWqxToHJybcSXI3owepVS2wxaPfk+Gj4uLjhhe4az4MGK2aPi8VfD279qIc4c+kx4XjMq3cRN1qEbK+RAsG4yLJa3zgkrjjCzq8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=DRNle8lkHieR32D2kOVoaMBDGHj5rveuMb1MJs6duwjbxm+/v1cPvKOPmoAdOLBewV6bsThlz2fau1Z7NQ9q2b0q83PI3a7jiJ0OYCiFpt52S0Gcljb/16Cp7Gn0RDv1FHHn1wG3dHRcj9NKKXDtf+sJZE2yDEYqObx3hIy38Go= Received: by 10.78.161.4 with SMTP id j4mr15977503hue.10.1202485506558; Fri, 08 Feb 2008 07:45:06 -0800 (PST) Received: from ?127.0.0.1? ( [217.206.187.79]) by mx.google.com with ESMTPS id x6sm15991932gvf.0.2008.02.08.07.45.03 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Feb 2008 07:45:04 -0800 (PST) From: Tom Evans To: "Carlos A. M. dos Santos" In-Reply-To: References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> <47ABF66E.4040807@bsdforen.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yCddgQcEWhqDYwv1PPAG" Date: Fri, 08 Feb 2008 15:45:01 +0000 Message-Id: <1202485501.2126.34.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Cc: Dominic Fandrey , freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 15:45:09 -0000 --=-yCddgQcEWhqDYwv1PPAG Content-Type: multipart/mixed; boundary="=-/zHl9Htkrp+QR73sY7ya" --=-/zHl9Htkrp+QR73sY7ya Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-02-08 at 11:43 -0200, Carlos A. M. dos Santos wrote: > > Yes, it happens in my notebook (HP NX6320). Sorry to jump into this thread, as it is slightly off-topic - I have a HP NC6320 (so not quite exact same model, but specs seem extremely close - mine is a core duo, not core 2 duo, but chipset, graphics, screen size is identical), and cannot get my DVD drive to operate in DMA mode. I track RELENG_7, last updated 3rd Feb. I have:=20 acd0: DVDR at ata0-master PIO4 on a=20 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x60a0-0x60af irq 16 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] with settings of hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma: 1 atacontrol says this about the DVD drive: > # atacontrol info ata0; atacontrol cap acd0 Master: acd0 ATA/ATAPI revision 6 Slave: no device present Protocol ATA/ATAPI revision 6 device model MATSHITADVD-RAM UJ-840S serial number =20 firmware revision 1.11 cylinders 0 heads 0 sectors/track 0 lba supported =20 lba48 not supported =20 dma supported overlap not supported Feature Support Enable Value Vendor write cache no no read ahead no no Tagged Command Queuing (TCQ) no no 0/0x00 SMART no no microcode download no no security no no power management no no advanced power management no no 0/0x00 automatic acoustic management no no 0/0x00 0/0x00 > # atacontrol mode acd0 current mode =3D PIO4 If I try to turn on DMA, I just get WDMA2, which just doesn't cut it: > # atacontrol mode acd0 udma5 current mode =3D WDMA2 This occurs if I try to set mode udma[2-6] It doesn't bother me too much, as I rarely use the CD drive in this laptop, but if you have similar hardware and can set UDMA modes on your DVD, I'd be interested. (I've also attached an (aged) verbose boot log if anyone else is interested.. (actually, the verbose boot was ancient, March 2007, so I've attached a recent, non-verbose, log - ask if you need more!)) Cheers Tom --=-/zHl9Htkrp+QR73sY7ya Content-Disposition: attachment; filename=dmesg.boot.txt Content-Type: text/plain; name=dmesg.boot.txt; charset=UTF-8 Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg MTk5NA0KCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhl IEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgNy4wLVBSRVJFTEVBU0UgIzY6IE1vbiBGZWIg IDQgMTI6NDM6MTUgR01UIDIwMDgNCiAgICByb290QHpvb3QubWludGVsLmNvLnVrOi9kYXRhMi9G cmVlQlNEL1JFTEVOR183L29iai9kYXRhMi9GcmVlQlNEL1JFTEVOR183L3NyYy9zeXMvWk9PVA0K VGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDANCkNQVTog R2VudWluZSBJbnRlbChSKSBDUFUgICAgICAgICAgIFQyNTAwICBAIDIuMDBHSHogKDE5OTUuMDIt TUh6IDY4Ni1jbGFzcyBDUFUpDQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NmU4 ICBTdGVwcGluZyA9IDgNCiAgRmVhdHVyZXM9MHhiZmU5ZmJmZjxGUFUsVk1FLERFLFBTRSxUU0Ms TVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxDTEZMVVNILERU UyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+DQogIEZlYXR1cmVzMj0weGMx YTk8U1NFMyxNT04sVk1YLEVTVCxUTTIseFRQUixQRENNPg0KICBBTUQgRmVhdHVyZXM9MHgxMDAw MDA8Tlg+DQogIENvcmVzIHBlciBwYWNrYWdlOiAyDQpyZWFsIG1lbW9yeSAgPSAxMDY1MTU2NjA4 ICgxMDE1IE1CKQ0KYXZhaWwgbWVtb3J5ID0gMTAyODY1NzE1MiAoOTgxIE1CKQ0KQUNQSSBBUElD IFRhYmxlOiA8SFAgICAgIDMwQUEgICAgPg0KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5 c3RlbSBEZXRlY3RlZDogMiBDUFVzDQogY3B1MCAoQlNQKTogQVBJQyBJRDogIDANCiBjcHUxIChB UCk6IEFQSUMgSUQ6ICAxDQppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElEIHRvIDENCmlvYXBpYzAg PFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQNCmtiZDEgYXQga2JkbXV4MA0K YXRoX2hhbDogMC45LjIwLjMgKEFSNTIxMCwgQVI1MjExLCBBUjUyMTIsIFJGNTExMSwgUkY1MTEy LCBSRjI0MTMsIFJGNTQxMykNCmhwdHJyOiBIUFQgUm9ja2V0UkFJRCBjb250cm9sbGVyIGRyaXZl ciB2MS4xIChGZWIgIDQgMjAwOCAxMjo0Mjo1NSkNCmNyeXB0b3NvZnQwOiA8c29mdHdhcmUgY3J5 cHRvPiBvbiBtb3RoZXJib2FyZA0KYWNwaTA6IDxIUCAzMEFBPiBvbiBtb3RoZXJib2FyZA0KYWNw aTA6IFtJVEhSRUFEXQ0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpDQphY3BpMDogcmVzZXJ2 YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZA0KYWNwaTA6IHJlc2VydmF0aW9uIG9mIDEwMDAw MCwgM2Y3MDAwMDAgKDMpIGZhaWxlZA0KVGltZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5 IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwDQphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAz LjU3OTU0NU1Iej4gcG9ydCAweDEwMDgtMHgxMDBiIG9uIGFjcGkwDQphY3BpX2VjMDogPEVtYmVk ZGVkIENvbnRyb2xsZXI6IEdQRSAweDE2PiBwb3J0IDB4NjIsMHg2NiBvbiBhY3BpMA0KY3B1MDog PEFDUEkgQ1BVPiBvbiBhY3BpMA0KZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kg Q29udHJvbD4gb24gY3B1MA0KcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+ IG9uIGNwdTANCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTANCmVzdDE6IDxFbmhhbmNlZCBTcGVl ZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTENCnA0dGNjMTogPENQVSBGcmVxdWVuY3kg VGhlcm1hbCBDb250cm9sPiBvbiBjcHUxDQpwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBw b3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwDQpwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMA0K dmdhcGNpMDogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IHBvcnQgMHg2MDAwLTB4NjAwNyBtZW0g MHhlODQwMDAwMC0weGU4NDdmZmZmLDB4ZDAwMDAwMDAtMHhkZmZmZmZmZiwweGU4NDgwMDAwLTB4 ZTg0YmZmZmYgaXJxIDE2IGF0IGRldmljZSAyLjAgb24gcGNpMA0KYWdwMDogPEludGVsIDgyOTQ1 R00gKDk0NUdNIEdNQ0gpIFNWR0EgY29udHJvbGxlcj4gb24gdmdhcGNpMA0KYWdwMDogZGV0ZWN0 ZWQgNzkzMmsgc3RvbGVuIG1lbW9yeQ0KYWdwMDogYXBlcnR1cmUgc2l6ZSBpcyAyNTZNDQpkcm0w OiA8SW50ZWwgaTk0NUdNPiBvbiB2Z2FwY2kwDQppbmZvOiBbZHJtXSBBR1AgYXQgMHhkMDAwMDAw MCAyNTZNQg0KaW5mbzogW2RybV0gSW5pdGlhbGl6ZWQgaTkxNSAxLjUuMCAyMDA2MDExOQ0Kdmdh cGNpMTogPFZHQS1jb21wYXRpYmxlIGRpc3BsYXk+IG1lbSAweGU4NTAwMDAwLTB4ZTg1N2ZmZmYg YXQgZGV2aWNlIDIuMSBvbiBwY2kwDQpwY2kwOiA8bXVsdGltZWRpYT4gYXQgZGV2aWNlIDI3LjAg KG5vIGRyaXZlciBhdHRhY2hlZCkNCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE2 IGF0IGRldmljZSAyOC4wIG9uIHBjaTANCnBjaTg6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxDQpw Y2k4OiA8bmV0d29yaz4gYXQgZGV2aWNlIDAuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNpYjI6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTggYXQgZGV2aWNlIDI4LjIgb24gcGNpMA0KcGNp MjQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyDQpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGlycSAxOSBhdCBkZXZpY2UgMjguMyBvbiBwY2kwDQpwY2kzMjogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjMNCnVoY2kwOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg2MDIw LTB4NjAzZiBpcnEgMjAgYXQgZGV2aWNlIDI5LjAgb24gcGNpMA0KdWhjaTA6IFtHSUFOVC1MT0NL RURdDQp1aGNpMDogW0lUSFJFQURdDQp1c2IwOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xs ZXI+IG9uIHVoY2kwDQp1c2IwOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMDogPEludGVsIFVIQ0kg cm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IwDQp1aHVi MDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVoY2kxOiA8VUhDSSAo Z2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg2MDQwLTB4NjA1ZiBpcnEgMjEgYXQgZGV2 aWNlIDI5LjEgb24gcGNpMA0KdWhjaTE6IFtHSUFOVC1MT0NLRURdDQp1aGNpMTogW0lUSFJFQURd DQp1c2IxOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kxDQp1c2IxOiBV U0IgcmV2aXNpb24gMS4wDQp1aHViMTogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwg cmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IxDQp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVoY2kyOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xs ZXI+IHBvcnQgMHg2MDYwLTB4NjA3ZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMA0KdWhj aTI6IFtHSUFOVC1MT0NLRURdDQp1aGNpMjogW0lUSFJFQURdDQp1c2IyOiA8VUhDSSAoZ2VuZXJp YykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kyDQp1c2IyOiBVU0IgcmV2aXNpb24gMS4wDQp1aHVi MjogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx PiBvbiB1c2IyDQp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQN CnVoY2kzOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHg2MDgwLTB4NjA5 ZiBpcnEgMTkgYXQgZGV2aWNlIDI5LjMgb24gcGNpMA0KdWhjaTM6IFtHSUFOVC1MT0NLRURdDQp1 aGNpMzogW0lUSFJFQURdDQp1c2IzOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9u IHVoY2kzDQp1c2IzOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMzogPEludGVsIFVIQ0kgcm9vdCBo dWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IzDQp1aHViMzogMiBw b3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCmVoY2kwOiA8SW50ZWwgODI4MDFH Qi9SIChJQ0g3KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGU4NTg0MDAwLTB4ZTg1ODQzZmYg aXJxIDIwIGF0IGRldmljZSAyOS43IG9uIHBjaTANCmVoY2kwOiBbR0lBTlQtTE9DS0VEXQ0KZWhj aTA6IFtJVEhSRUFEXQ0KdXNiNDogRUhDSSB2ZXJzaW9uIDEuMA0KdXNiNDogY29tcGFuaW9uIGNv bnRyb2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjAgdXNiMSB1c2IyIHVzYjMNCnVzYjQ6IDxJbnRl bCA4MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTANCnVzYjQ6IFVT QiByZXZpc2lvbiAyLjANCnVodWI0OiA8SW50ZWwgRUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCBy ZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjQNCnVodWI0OiA4IHBvcnRzIHdpdGggOCByZW1v dmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjU6IDx2ZW5kb3IgMHgwNDI0IHByb2R1Y3QgMHgyNTAz LCBjbGFzcyA5LzAsIHJldiAyLjAwLzAuMDEsIGFkZHIgMj4gb24gdWh1YjQNCnVodWI1OiBtdWx0 aXBsZSB0cmFuc2FjdGlvbiB0cmFuc2xhdG9ycw0KdWh1YjU6IDMgcG9ydHMgd2l0aCAwIHJlbW92 YWJsZSwgc2VsZiBwb3dlcmVkDQp1Z2VuMDogPEJyb2FkY29tIENvcnAgSFAgSW50ZWdyYXRlZCBN b2R1bGUsIGNsYXNzIDIyNC8xLCByZXYgMi4wMC8xLjAwLCBhZGRyIDM+IG9uIHVodWI1DQp1Z2Vu MTogPHZlbmRvciAweDA4ZmYgRmluZ2VycHJpbnQgU2Vuc29yLCBjbGFzcyAyNTUvMjU1LCByZXYg MS4xMC82LjIxLCBhZGRyIDQ+IG9uIHVodWI1DQp1bWFzczA6IDxMYUNpZSBMYUNpZSBIYXJkIERy aXZlIFVTQiwgY2xhc3MgMC8wLCByZXYgMi4wMC8wLjAwLCBhZGRyIDU+IG9uIHVodWI0DQpwY2li NDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTANCnBjaTI6IDxB Q1BJIFBDSSBidXM+IG9uIHBjaWI0DQpjYmIwOiA8UENJLUNhcmRCdXMgQnJpZGdlPiBtZW0gMHhl ODEwMDAwMC0weGU4MTAwZmZmIGlycSAxOCBhdCBkZXZpY2UgNi4wIG9uIHBjaTINCmNhcmRidXMw OiA8Q2FyZEJ1cyBidXM+IG9uIGNiYjANCnBjY2FyZDA6IDwxNi1iaXQgUENDYXJkIGJ1cz4gb24g Y2JiMA0KY2JiMDogW0lUSFJFQURdDQpmd29oY2kwOiA8MTM5NCBPcGVuIEhvc3QgQ29udHJvbGxl ciBJbnRlcmZhY2U+IG1lbSAweGU4MTAxMDAwLTB4ZTgxMDE3ZmYsMHhlODEwNDAwMC0weGU4MTA3 ZmZmIGlycSAxOSBhdCBkZXZpY2UgNi4xIG9uIHBjaTINCmZ3b2hjaTA6IFtGSUxURVJdDQpmd29o Y2kwOiBPSENJIHZlcnNpb24gMS4xMCAoUk9NPTApDQpmd29oY2kwOiBOby4gb2YgSXNvY2hyb25v dXMgY2hhbm5lbHMgaXMgNC4NCmZ3b2hjaTA6IEVVSTY0IDAwOjAyOjNmOjk5OjI5OmY5OjJiOjBj DQpmd29oY2kwOiBQaHkgMTM5NGEgYXZhaWxhYmxlIFM0MDAsIDMgcG9ydHMuDQpmd29oY2kwOiBM aW5rIFM0MDAsIG1heF9yZWMgMjA0OCBieXRlcy4NCmZpcmV3aXJlMDogPElFRUUxMzk0KEZpcmVX aXJlKSBidXM+IG9uIGZ3b2hjaTANCmRjb25zX2Nyb20wOiA8ZGNvbnMgY29uZmlndXJhdGlvbiBS T00+IG9uIGZpcmV3aXJlMA0KZGNvbnNfY3JvbTA6IGJ1c19hZGRyIDB4YzNiZDYwDQpmd2UwOiA8 RXRoZXJuZXQgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdpcmUwDQppZl9md2UwOiBGYWtlIEV0aGVy bmV0IGFkZHJlc3M6IDAyOjAyOjNmOmY5OjJiOjBjDQpmd2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAw MjowMjozZjpmOToyYjowYw0KZndpcDA6IDxJUCBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAN CmZ3aXAwOiBGaXJld2lyZSBhZGRyZXNzOiAwMDowMjozZjo5OToyOTpmOToyYjowYyBAIDB4ZmZm ZTAwMDAwMDAwLCBTNDAwLCBtYXhyZWMgMjA0OA0Kc2JwMDogPFNCUC0yL1NDU0kgb3ZlciBGaXJl V2lyZT4gb24gZmlyZXdpcmUwDQpmd29oY2kwOiBJbml0aWF0ZSBidXMgcmVzZXQNCmZ3b2hjaTA6 IEJVUyByZXNldA0KZndvaGNpMDogbm9kZV9pZD0weGM4MDBmZmMwLCBnZW49MSwgQ1lDTEVNQVNU RVIgbW9kZQ0KcGNpMjogPG1hc3Mgc3RvcmFnZT4gYXQgZGV2aWNlIDYuMiAobm8gZHJpdmVyIGF0 dGFjaGVkKQ0KcGNpMjogPGJhc2UgcGVyaXBoZXJhbD4gYXQgZGV2aWNlIDYuMyAobm8gZHJpdmVy IGF0dGFjaGVkKQ0KYmdlMDogPEJyb2FkY29tIE5ldFh0cmVtZSBHaWdhYml0IEV0aGVybmV0IENv bnRyb2xsZXIsIEFTSUMgcmV2LiAweDMwMDM+IG1lbSAweGU4MTEwMDAwLTB4ZTgxMWZmZmYgaXJx IDE2IGF0IGRldmljZSAxNC4wIG9uIHBjaTINCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBiZ2UwDQpi cmdwaHkwOiA8QkNNNTcwNSAxMC8xMDAvMTAwMGJhc2VUWCBQSFk+IFBIWSAxIG9uIG1paWJ1czAN CmJyZ3BoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRY LCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8NCmJnZTA6IEV0aGVybmV0IGFkZHJlc3M6 IDAwOjE1OjYwOmM3OmZhOjZlDQpiZ2UwOiBbSVRIUkVBRF0NCmlzYWIwOiA8UENJLUlTQSBicmlk Z2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTANCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMA0KYXRh cGNpMDogPEludGVsIElDSDcgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4 M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4NjBhMC0weDYwYWYgaXJxIDE2IGF0IGRldmljZSAzMS4x IG9uIHBjaTANCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwDQphdGEwOiBbSVRIUkVB RF0NCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwDQphdGExOiBbSVRIUkVBRF0NCmF0 YXBjaTE6IDxJbnRlbCBBSENJIGNvbnRyb2xsZXI+IHBvcnQgMHgxM2YwLTB4MTNmNywweDE1ZjQt MHgxNWY3LDB4MTM3MC0weDEzNzcsMHgxNTc0LTB4MTU3NywweDYwZDAtMHg2MGRmIG1lbSAweGU4 NTg1MDAwLTB4ZTg1ODUzZmYgaXJxIDE3IGF0IGRldmljZSAzMS4yIG9uIHBjaTANCmF0YXBjaTE6 IFtJVEhSRUFEXQ0KYXRhcGNpMTogQUhDSSBWZXJzaW9uIDAxLjEwIGNvbnRyb2xsZXIgd2l0aCA0 IHBvcnRzIGRldGVjdGVkDQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQ0KYXRhMjog W0lUSFJFQURdDQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQ0KYXRhMzogcG9ydCBu b3QgaW1wbGVtZW50ZWQNCmF0YTM6IFtJVEhSRUFEXQ0KYXRhNDogPEFUQSBjaGFubmVsIDI+IG9u IGF0YXBjaTENCmF0YTQ6IHBvcnQgbm90IGltcGxlbWVudGVkDQphdGE0OiBbSVRIUkVBRF0NCmF0 YTU6IDxBVEEgY2hhbm5lbCAzPiBvbiBhdGFwY2kxDQphdGE1OiBwb3J0IG5vdCBpbXBsZW1lbnRl ZA0KYXRhNTogW0lUSFJFQURdDQpiYXR0ZXJ5MDogPEFDUEkgQ29udHJvbCBNZXRob2QgQmF0dGVy eT4gb24gYWNwaTANCmJhdHRlcnkxOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBh Y3BpMA0KYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwDQphY3BpX2J1dHRvbjA6IDxT bGVlcCBCdXR0b24+IG9uIGFjcGkwDQphY3BpX2xpZDA6IDxDb250cm9sIE1ldGhvZCBMaWQgU3dp dGNoPiBvbiBhY3BpMA0KYWNwaV90ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwDQphY3BpX3R6 MTogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTANCmFjcGlfdHoyOiA8VGhlcm1hbCBab25lPiBvbiBh Y3BpMA0KYWNwaV90ejM6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwDQphY3BpX3R6NDogPFRoZXJt YWwgWm9uZT4gb24gYWNwaTANCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+ IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwDQphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJx IDEgb24gYXRrYmRjMA0Ka2JkMCBhdCBhdGtiZDANCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0NCmF0 a2JkMDogW0lUSFJFQURdDQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzANCnBz bTA6IFtHSUFOVC1MT0NLRURdDQpwc20wOiBbSVRIUkVBRF0NCnBzbTA6IG1vZGVsIEludGVsbGlN b3VzZSwgZGV2aWNlIElEIDMNCnNpbzA6IDxTdGFuZGFyZCBQQyBDT00gcG9ydD4gcG9ydCAweDNm OC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkwDQpzaW8wOiB0eXBlIDE2NTUwQSwgY29u c29sZQ0Kc2lvMDogW0ZJTFRFUl0NCnBtdGltZXIwIG9uIGlzYTANCm9ybTA6IDxJU0EgT3B0aW9u IFJPTT4gYXQgaW9tZW0gMHhjMDAwMC0weGNmZmZmIHBucGlkIE9STTAwMDAgb24gaXNhMA0KcHBj MDogPFBhcmFsbGVsIHBvcnQ+IGF0IHBvcnQgMHgzNzgtMHgzN2YgaXJxIDcgb24gaXNhMA0KcHBj MDogU01DLWxpa2UgY2hpcHNldCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1v ZGUNCnBwYzA6IEZJRk8gd2l0aCAxNi8xNi84IGJ5dGVzIHRocmVzaG9sZA0KcHBidXMwOiA8UGFy YWxsZWwgcG9ydCBidXM+IG9uIHBwYzANCnBwYnVzMDogW0lUSFJFQURdDQpwbGlwMDogPFBMSVAg bmV0d29yayBpbnRlcmZhY2U+IG9uIHBwYnVzMA0KbHB0MDogPFByaW50ZXI+IG9uIHBwYnVzMA0K bHB0MDogSW50ZXJydXB0LWRyaXZlbiBwb3J0DQpwcGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBwcGJ1 czANCnBwYzA6IFtHSUFOVC1MT0NLRURdDQpwcGMwOiBbSVRIUkVBRF0NCnNjMDogPFN5c3RlbSBj b25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwDQpzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25z b2xlcywgZmxhZ3M9MHgzMDA+DQpzaW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAg b2YgcHJvYmVkIGlycXMgMA0Kc2lvMTogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQNCnZnYTA6IDxH ZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZm IG9uIGlzYTANCnVtczA6IDxMb2dpdGVjaCBVU0ItUFMvMiBPcHRpY2FsIE1vdXNlLCBjbGFzcyAw LzAsIHJldiAyLjAwLzIyLjAwLCBhZGRyIDI+IG9uIHVodWIxDQp1bXMwOiA4IGJ1dHRvbnMgYW5k IFogZGlyLg0KdWtiZDA6IDx2ZW5kb3IgMHgwZDNkIFVTQlBTMiwgY2xhc3MgMC8wLCByZXYgMS4x MC8wLjAxLCBhZGRyIDI+IG9uIHVodWIyDQprYmQyIGF0IHVrYmQwDQp1bXMxOiA8dmVuZG9yIDB4 MGQzZCBVU0JQUzIsIGNsYXNzIDAvMCwgcmV2IDEuMTAvMC4wMSwgYWRkciAyPiBvbiB1aHViMg0K dW1zMTogNSBidXR0b25zIGFuZCBaIGRpci4NClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAw IG1zZWMNCmhwdHJyOiBubyBjb250cm9sbGVyIGRldGVjdGVkLg0KZmlyZXdpcmUwOiAxIG5vZGVz LCBtYXhob3AgPD0gMCwgY2FibGUgSVJNID0gMCAobWUpDQpmaXJld2lyZTA6IGJ1cyBtYW5hZ2Vy IDAgKG1lKQ0KYWNkMDogRFZEUiA8TUFUU0hJVEFEVkQtUkFNIFVKLTg0MFMvMS4xMT4gYXQgYXRh MC1tYXN0ZXIgUElPNA0KYWQ0OiA5NTM5Nk1CIDxGVUpJVFNVIE1IVjIxMDBCSCA4OTJDPiBhdCBh dGEyLW1hc3RlciBTQVRBMTUwDQpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgYWQ0czIg aXMgbXNkb3Nmcy8gLg0KYWNkMDogRkFJTFVSRSAtIElOUVVJUlkgSUxMRUdBTCBSRVFVRVNUIGFz Yz0weDI0IGFzY3E9MHgwMCANCmFjZDA6IEZBSUxVUkUgLSBJTlFVSVJZIElMTEVHQUwgUkVRVUVT VCBhc2M9MHgyNCBhc2NxPTB4MDAgDQpTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCENCmRhMCBhdCB1 bWFzcy1zaW0wIGJ1cyAwIHRhcmdldCAwIGx1biAwDQpkYTA6IDxTQU1TVU5HIFNQMjUxNE4gVkYx MD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTIgZGV2aWNlIA0KZGEwOiA0MC4wMDBNQi9zIHRy YW5zZmVycw0KZGEwOiAyMzg0NzVNQiAoNDg4Mzk3MTY4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUgg NjNTL1QgMzA0MDFDKQ0KY2QwIGF0IGF0YTAgYnVzIDAgdGFyZ2V0IDAgbHVuIDANCmNkMDogPE1B VFNISVRBIERWRC1SQU0gVUotODQwUyAxLjExPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBkZXZp Y2UgDQpjZDA6IDE2LjAwME1CL3MgdHJhbnNmZXJzDQpjZDA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2 aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2VudA0KVHJ5aW5nIHRv IG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDRzM2ENCj== --=-/zHl9Htkrp+QR73sY7ya Content-Disposition: attachment; filename=pciconf.txt Content-Type: text/plain; name=pciconf.txt; charset=UTF-8 Content-Transfer-Encoding: base64 aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgzMGFhMTAzYyBjaGlwPTB4 MjdhMDgwODYgcmV2PTB4MDMgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBv cmF0aW9uJw0KICAgIGRldmljZSAgICAgPSAnOTU1WE0vOTQ1R00vUE0vR01TLzk0MEdNTCBFeHBy ZXNzIFByb2Nlc3NvciB0byBEUkFNIENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IGJyaWRn ZQ0KICAgIHN1YmNsYXNzICAgPSBIT1NULVBDSQ0KdmdhcGNpMEBwY2kwOjA6MjowOgljbGFzcz0w eDAzMDAwMCBjYXJkPTB4MzBhYTEwM2MgY2hpcD0weDI3YTI4MDg2IHJldj0weDAzIGhkcj0weDAw DQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicNCiAgICBkZXZpY2UgICAgID0g J01vYmlsZSBJbnRlZ3JhdGVkIEdyYXBoaWNzIENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9 IGRpc3BsYXkNCiAgICBzdWJjbGFzcyAgID0gVkdBDQp2Z2FwY2kxQHBjaTA6MDoyOjE6CWNsYXNz PTB4MDM4MDAwIGNhcmQ9MHgzMGFhMTAzYyBjaGlwPTB4MjdhNjgwODYgcmV2PTB4MDMgaGRyPTB4 MDANCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJw0KICAgIGRldmljZSAgICAg PSAnTW9iaWxlIEludGVncmF0ZWQgR3JhcGhpY3MgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAg ID0gZGlzcGxheQ0Kbm9uZTBAcGNpMDowOjI3OjA6CWNsYXNzPTB4MDQwMzAwIGNhcmQ9MHgzMGFh MTAzYyBjaGlwPTB4MjdkODgwODYgcmV2PTB4MDEgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0g J0ludGVsIENvcnBvcmF0aW9uJw0KICAgIGRldmljZSAgICAgPSAnODI4MDFHIChJQ0g3IEZhbWls eSkgSGlnaCBEZWZpbml0aW9uIEF1ZGlvJw0KICAgIGNsYXNzICAgICAgPSBtdWx0aW1lZGlhDQpw Y2liMUBwY2kwOjA6Mjg6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgy N2QwODA4NiByZXY9MHgwMSBoZHI9MHgwMQ0KICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nDQogICAgZGV2aWNlICAgICA9ICc4MjgwMUcgKElDSDcgRmFtaWx5KSBQQ0kgRXhwcmVz cyBSb290IFBvcnQnDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzICAgPSBQ Q0ktUENJDQpwY2liMkBwY2kwOjA6Mjg6MjoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDAw IGNoaXA9MHgyN2Q0ODA4NiByZXY9MHgwMSBoZHI9MHgwMQ0KICAgIHZlbmRvciAgICAgPSAnSW50 ZWwgQ29ycG9yYXRpb24nDQogICAgZGV2aWNlICAgICA9ICc4MjgwMUcgKElDSDcgRmFtaWx5KSBQ Q0kgRXhwcmVzcyBSb290IFBvcnQnDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0KICAgIHN1YmNs YXNzICAgPSBQQ0ktUENJDQpwY2liM0BwY2kwOjA6Mjg6MzoJY2xhc3M9MHgwNjA0MDAgY2FyZD0w eDAwMDAwMDAwIGNoaXA9MHgyN2Q2ODA4NiByZXY9MHgwMSBoZHI9MHgwMQ0KICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nDQogICAgZGV2aWNlICAgICA9ICc4MjgwMUcgKElDSDcg RmFtaWx5KSBQQ0kgRXhwcmVzcyBSb290IFBvcnQnDQogICAgY2xhc3MgICAgICA9IGJyaWRnZQ0K ICAgIHN1YmNsYXNzICAgPSBQQ0ktUENJDQp1aGNpMEBwY2kwOjA6Mjk6MDoJY2xhc3M9MHgwYzAz MDAgY2FyZD0weDMwYWExMDNjIGNoaXA9MHgyN2M4ODA4NiByZXY9MHgwMSBoZHI9MHgwMA0KICAg IHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nDQogICAgZGV2aWNlICAgICA9ICc4Mjgw MUcgKElDSDcgRmFtaWx5KSBVU0IgVW5pdmVyc2FsIEhvc3QgQ29udHJvbGxlcicNCiAgICBjbGFz cyAgICAgID0gc2VyaWFsIGJ1cw0KICAgIHN1YmNsYXNzICAgPSBVU0INCnVoY2kxQHBjaTA6MDoy OToxOgljbGFzcz0weDBjMDMwMCBjYXJkPTB4MzBhYTEwM2MgY2hpcD0weDI3Yzk4MDg2IHJldj0w eDAxIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicNCiAgICBk ZXZpY2UgICAgID0gJzgyODAxRyAoSUNINyBGYW1pbHkpIFVTQiBVbml2ZXJzYWwgSG9zdCBDb250 cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9IFVT Qg0KdWhjaTJAcGNpMDowOjI5OjI6CWNsYXNzPTB4MGMwMzAwIGNhcmQ9MHgzMGFhMTAzYyBjaGlw PTB4MjdjYTgwODYgcmV2PTB4MDEgaGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENv cnBvcmF0aW9uJw0KICAgIGRldmljZSAgICAgPSAnODI4MDFHIChJQ0g3IEZhbWlseSkgVVNCIFVu aXZlcnNhbCBIb3N0IENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMNCiAg ICBzdWJjbGFzcyAgID0gVVNCDQp1aGNpM0BwY2kwOjA6Mjk6MzoJY2xhc3M9MHgwYzAzMDAgY2Fy ZD0weDMwYWExMDNjIGNoaXA9MHgyN2NiODA4NiByZXY9MHgwMSBoZHI9MHgwMA0KICAgIHZlbmRv ciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nDQogICAgZGV2aWNlICAgICA9ICc4MjgwMUcgKElD SDcgRmFtaWx5KSBVU0IgVW5pdmVyc2FsIEhvc3QgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAg ID0gc2VyaWFsIGJ1cw0KICAgIHN1YmNsYXNzICAgPSBVU0INCmVoY2kwQHBjaTA6MDoyOTo3Oglj bGFzcz0weDBjMDMyMCBjYXJkPTB4MzBhYTEwM2MgY2hpcD0weDI3Y2M4MDg2IHJldj0weDAxIGhk cj0weDAwDQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicNCiAgICBkZXZpY2Ug ICAgID0gJzgyODAxRyAoSUNINyBGYW1pbHkpIFVTQiAyLjAgRW5oYW5jZWQgSG9zdCBDb250cm9s bGVyJw0KICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9IFVTQg0K cGNpYjRAcGNpMDowOjMwOjA6CWNsYXNzPTB4MDYwNDAxIGNhcmQ9MHgzMGFhMTAzYyBjaGlwPTB4 MjQ0ODgwODYgcmV2PTB4ZTEgaGRyPTB4MDENCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBv cmF0aW9uJw0KICAgIGRldmljZSAgICAgPSAnODI4MDFCQU0vQ0FNL0RCTSAoSUNIMi1NLzMtTS80 LU0pIEh1YiBJbnRlcmZhY2UgdG8gUENJIEJyaWRnZScNCiAgICBjbGFzcyAgICAgID0gYnJpZGdl DQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kNCmlzYWIwQHBjaTA6MDozMTowOgljbGFzcz0weDA2 MDEwMCBjYXJkPTB4MzBhYTEwM2MgY2hpcD0weDI3Yjk4MDg2IHJldj0weDAxIGhkcj0weDAwDQog ICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicNCiAgICBkZXZpY2UgICAgID0gJzgy ODAxR0JNIChJQ0g3LU0pIExQQyBJbnRlcmZhY2UgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICAg ID0gYnJpZGdlDQogICAgc3ViY2xhc3MgICA9IFBDSS1JU0ENCmF0YXBjaTBAcGNpMDowOjMxOjE6 CWNsYXNzPTB4MDEwMThhIGNhcmQ9MHgzMGFhMTAzYyBjaGlwPTB4MjdkZjgwODYgcmV2PTB4MDEg aGRyPTB4MDANCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJw0KICAgIGRldmlj ZSAgICAgPSAnODI4MDFHIChJQ0g3IEZhbWlseSkgVWx0cmEgQVRBIFN0b3JhZ2UgQ29udHJvbGxl cicNCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlDQogICAgc3ViY2xhc3MgICA9IEFUQQ0K YXRhcGNpMUBwY2kwOjA6MzE6MjoJY2xhc3M9MHgwMTA2MDEgY2FyZD0weDMwYWExMDNjIGNoaXA9 MHgyN2M1ODA4NiByZXY9MHgwMSBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29y cG9yYXRpb24nDQogICAgZGV2aWNlICAgICA9ICc4MjgwMUdCIE1vYmlsZSBJL08gQ29udHJvbGxl ciBIdWIgU0FUQSBjYz1BSENJJw0KICAgIGNsYXNzICAgICAgPSBtYXNzIHN0b3JhZ2UNCndwaTBA cGNpMDo4OjA6MDoJY2xhc3M9MHgwMjgwMDAgY2FyZD0weDEzNWMxMDNjIGNoaXA9MHg0MjIyODA4 NiByZXY9MHgwMiBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24n DQogICAgZGV2aWNlICAgICA9ICczOTQ1QUJHIEludGVsIDM5NDVBQkcgV2lyZWxlc3MgTEFOIGNv bnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IG5ldHdvcmsNCmNiYjBAcGNpMDoyOjY6MDoJY2xh c3M9MHgwNjA3MDAgY2FyZD0weDMwYWExMDNjIGNoaXA9MHg4MDM5MTA0YyByZXY9MHgwMCBoZHI9 MHgwMg0KICAgIHZlbmRvciAgICAgPSAnVGV4YXMgSW5zdHJ1bWVudHMgKFRJKScNCiAgICBkZXZp Y2UgICAgID0gJ1BDSXh4MTIgQ2FyZGJ1cyBDb250cm9sbGVyJw0KICAgIGNsYXNzICAgICAgPSBi cmlkZ2UNCiAgICBzdWJjbGFzcyAgID0gUENJLUNhcmRCdXMNCmZ3b2hjaTBAcGNpMDoyOjY6MToJ Y2xhc3M9MHgwYzAwMTAgY2FyZD0weDMwYWExMDNjIGNoaXA9MHg4MDNhMTA0YyByZXY9MHgwMCBo ZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnVGV4YXMgSW5zdHJ1bWVudHMgKFRJKScNCiAgICBk ZXZpY2UgICAgID0gJ1BDSXh4MTIgT0hDSSBJRUVFIDEzOTQgSG9zdCBDb250cm9sbGVyJw0KICAg IGNsYXNzICAgICAgPSBzZXJpYWwgYnVzDQogICAgc3ViY2xhc3MgICA9IEZpcmVXaXJlDQpub25l MUBwY2kwOjI6NjoyOgljbGFzcz0weDAxODAwMCBjYXJkPTB4MzBhYTEwM2MgY2hpcD0weDgwM2Ix MDRjIHJldj0weDAwIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdUZXhhcyBJbnN0cnVtZW50 cyAoVEkpJw0KICAgIGRldmljZSAgICAgPSAnUENJeHgxMiBJbnRlZ3JhdGVkIEZsYXNoIE1lZGlh IENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgICA9IG1hc3Mgc3RvcmFnZQ0Kbm9uZTJAcGNpMDoy OjY6MzoJY2xhc3M9MHgwODA1MDAgY2FyZD0weDMwYWExMDNjIGNoaXA9MHg4MDNjMTA0YyByZXY9 MHgwMCBoZHI9MHgwMA0KICAgIHZlbmRvciAgICAgPSAnVGV4YXMgSW5zdHJ1bWVudHMgKFRJKScN CiAgICBkZXZpY2UgICAgID0gJ1BDSXh4MTIgU0RBIEhvc3QgQ29udHJvbGxlcicNCiAgICBjbGFz cyAgICAgID0gYmFzZSBwZXJpcGhlcmFsDQpiZ2UwQHBjaTA6MjoxNDowOgljbGFzcz0weDAyMDAw MCBjYXJkPTB4MzBhYTEwM2MgY2hpcD0weDE2OWMxNGU0IHJldj0weDAzIGhkcj0weDAwDQogICAg dmVuZG9yICAgICA9ICdCcm9hZGNvbSBDb3Jwb3JhdGlvbicNCiAgICBkZXZpY2UgICAgID0gJ2Zo amZoamdoaiBCcm9hZGNvbSBHaWdhYml0IEV0aGVybmV0IEJDTTU3MHggTmV0WHRyZW1lJw0KICAg IGNsYXNzICAgICAgPSBuZXR3b3JrDQogICAgc3ViY2xhc3MgICA9IGV0aGVybmV0DQo= --=-/zHl9Htkrp+QR73sY7ya-- --=-yCddgQcEWhqDYwv1PPAG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHrHj5lcRvFfyds/cRAtHgAJ9m/+BF0EyMBWaYQ2pAVVBqzLmI1QCgrqVp gGoDysVfEvpJiXZ8uiAdgrI= =9C0M -----END PGP SIGNATURE----- --=-yCddgQcEWhqDYwv1PPAG-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 16:07:53 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8092616A420; Fri, 8 Feb 2008 16:07:53 +0000 (UTC) (envelope-from ws@au.dyndns.ws) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by mx1.freebsd.org (Postfix) with ESMTP id 32FB213C458; Fri, 8 Feb 2008 16:07:51 +0000 (UTC) (envelope-from ws@au.dyndns.ws) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJoKrEeWZWdv/2dsb2JhbAAIrBs X-IronPort-AV: E=Sophos;i="4.25,322,1199626200"; d="scan'208";a="50779739" Received: from ppp103-111.static.internode.on.net (HELO [192.168.1.131]) ([150.101.103.111]) by ipmail05.adl2.internode.on.net with ESMTP; 09 Feb 2008 02:37:50 +1030 From: Wayne Sierke To: Jeremy Chadwick In-Reply-To: <1201918236.5350.47.camel@predator-ii.buffyverse> References: <1201188590.2075.4.camel@predator-ii.buffyverse> <1201865411.5350.12.camel@predator-ii.buffyverse> <20080201151750.GA62488@eos.sc1.parodius.com> <1201918236.5350.47.camel@predator-ii.buffyverse> Content-Type: text/plain Date: Sat, 09 Feb 2008 02:37:45 +1030 Message-Id: <1202486866.1535.103.camel@predator-ii.buffyverse> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Frequent USB mouse disconnections under load with RELENG_7] 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, 08 Feb 2008 16:07:53 -0000 Curiouser and curiouser... Synopsis: attaching either or both of two Logitech MX500 mice directly to the (fixed) rear USB ports on this system results in frequent disconnections (disconnect/reconnects) of the mice (ums0/ums1). The frequency of the disconnections apparently increases under increased cpu load. A mouse attached via a second (expansion) pair of USB ports, taken from a header on the motherboard, results in no disconnections for that mouse. Interposing a 4-port USB hub between a mouse and the fixed rear USB ports results in no disconnections for that mouse - with the exception that attaching an FTDI serial adapter to the 4-port hub results in a single disconnection event, but the same symptom is not produced by attaching other assorted USB devices to the hub. Additionally, the disconnection so induced sometimes doesn't include a re-attach event for the mouse (i.e. it remains disconnected until physically detached then reattached). Now the details: After upgrading this system (i386) from RELENG_6 (6.3-PRERELEASE) to RELENG_7 (GENERIC) I started experiencing frequent disconnections with my Logitech USB MX500 mouse. After posting about it on -stable the only idea arrived at was to try removing the extant moused configuration from rc.conf, a remnant from previous configurations. What follows is the outcome of trying that and subsequent investigations. Removing moused_* from rc.conf didn't have any discernible effect other than eliminating the error from moused as seen in /var/log/messages. The disconnects still occur and I've done a little experimentation which has provided some interesting further info. This board (a Gigabyte 8SQ800) has two fixed USB ports on the rear connectors and four additional ports available via a pair of headers, one of which is currently fitted with a rear-panel expansion plate making two more ports accessible for a total of four out of the six supported by the board. kernel: ohci0: mem 0xfb001000-0xfb001fff irq 20 at device 3.0 on pci0 kernel: ohci0: [GIANT-LOCKED] kernel: ohci0: [ITHREAD] kernel: usb0: OHCI version 1.0, legacy support kernel: usb0: on ohci0 kernel: usb0: USB revision 1.0 kernel: uhub0: on usb0 kernel: uhub0: 2 ports with 2 removable, self powered kernel: ohci1: mem 0xfb002000-0xfb002fff irq 21 at device 3.1 on pci0 kernel: ohci1: [GIANT-LOCKED] kernel: ohci1: [ITHREAD] kernel: usb1: OHCI version 1.0, legacy support kernel: usb1: on ohci1 kernel: usb1: USB revision 1.0 kernel: uhub1: on usb1 kernel: uhub1: 2 ports with 2 removable, self powered kernel: ohci2: mem 0xfb003000-0xfb003fff irq 22 at device 3.2 on pci0 kernel: ohci2: [GIANT-LOCKED] kernel: ohci2: [ITHREAD] kernel: usb2: OHCI version 1.0, legacy support kernel: usb2: on ohci2 kernel: usb2: USB revision 1.0 kernel: uhub2: on usb2 kernel: uhub2: 2 ports with 2 removable, self powered kernel: ehci0: mem 0xfb004000-0xfb004fff irq 23 at device 3.3 on pci0 kernel: ehci0: [GIANT-LOCKED] kernel: ehci0: [ITHREAD] kernel: usb3: EHCI version 1.0 kernel: usb3: companion controllers, 2 ports each: usb0 usb1 usb2 kernel: usb3: on ehci0 kernel: usb3: USB revision 2.0 kernel: uhub3: on usb3 kernel: uhub3: 6 ports with 6 removable, self powered The original MX500 mouse was attached to usb0/port 1. I added a second MX500 mouse (same model, different revision) attached to usb0/port 2. root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub0 kernel: ums0: on uhub0 kernel: ums0: 8 buttons and Z dir. root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub0 kernel: ums1: on uhub0 kernel: ums1: 8 buttons and Z dir. It wasn't long before I experienced disconnections with both mice! kernel: ums1: at uhub0 port 2 (addr 3) disconnected kernel: ums1: detached root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub0 kernel: ums1: on uhub0 kernel: ums1: 8 buttons and Z dir. kernel: ums0: at uhub0 port 1 (addr 2) disconnected kernel: ums0: detached root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub0 kernel: ums0: on uhub0 kernel: ums0: 8 buttons and Z dir. # cat /var/log/messages | grep 'ums0: detached$' | wc -l 63 # cat /var/log/messages | grep 'ums1: detached$' | wc -l 49 I then attached both mice to the expansion USB ports. The disconnections ceased. One of the mice was then swapped back to the fixed USB ports. That mouse suffered disconnections while the mouse attached to the expansion port did not. It seemed that perhaps the fixed USB ports might be faulty. To further investigate that possibility I attached a 4-port USB hub to usb0: kernel: uhub4: on uhub0 kernel: uhub4: 4 ports with 4 removable, self powered and attached one of the mice to it: root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub4 kernel: ums1: on uhub4 kernel: ums1: 8 buttons and Z dir. that mouse didn't experience any subsequent disconnections. With one exception, when I attached to the hub a USB serial adapter that happened to be at hand: kernel: ums0: at uhub4 port 1 (addr 3) disconnected kernel: ums0: detached root: Unknown USB device: vendor 0x0403 product 0x6001 bus uhub4 kernel: ugen0: on uhub4 root: Unknown USB device: vendor 0x046d product 0xc025 bus uhub4 kernel: ums0: on uhub4 kernel: ums0: 8 buttons and Z dir. which turned out to be repeatable. It was subsequently observed that sometimes the mouse wouldn't re-attach and had to be physically detached and reattached. With both mice attached to the hub, attaching the FTDI adapter seemed to result in both mice detaching, and only one re-attaching. Moving the hub from one of the fixed rear ports to one of the expansion ports doesn't change this behaviour - subsequently attaching the FTDI device still results in the mouse (or both mice) detaching and only sometimes re-attaching. Attaching a couple of other devices to the hub (a USB flash drive, a bluetooth adapter) has not so far resulted in disconnection for the mouse/mice that are also attached to the hub. In summary: - mice attached directly to either of the fixed USB ports suffer frequent disconnect/reconnect events and affected by cpu load - mice attached via the expansion USB ports do not suffer disconnections of themselves even when attached to the fixed USB ports - introducing a usb hub between one or both mice and the fixed USB ports eliminates the disconnections for the mouse/mice attached to the hub, but not for a mouse attached directly to a fixed USB port - mice attached to the hub experience disconnects when a particular device is subsequently attached to the hub, apparently remaining unaffected by other assorted devices being attached to the hub, and regardless of which USB port the hub is attached to *phew* Any suggestions as to how to set about tracking this down are most welcome. Should I take this to -USB? In the course of this testing the system also suffered a panic, as best as I can tell from unplugging one of the "other" USB devices. I'll raise this again with specifics if I can reproduce it. I also conducted an admittedly brief test with a Knoppix (v5.0.1) CD during which I was unable to reproduce any of these symptoms. # usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), SiS(0x0000), rev 1.00 port 1 addr 2: low speed, power 98 mA, config 1, USB-PS/2 Optical Mouse(0xc025), Logitech(0x046d), rev 18.00 port 2 addr 3: full speed, self powered, config 1, product 0x0902(0x0902), vendor 0x03eb(0x03eb), rev 1.00 port 1 addr 4: full speed, power 90 mA, config 1, TTL232R(0x6001), FTDI(0x0403), rev 6.00 port 2 addr 5: low speed, power 98 mA, config 1, USB-PS/2 Optical Mouse(0xc025), B16_b_02(0x046d), rev 98.02 port 3 addr 6: full speed, power 100 mA, config 1, USB Mass Storage Device(0x4146), USB Disk(0x4146), rev 1.00 port 4 addr 7: full speed, power 100 mA, config 1, BCM2045B2(0x4500), Broadcom(0x0a5c), rev 1.00 port 1 addr 8: full speed, self powered, config 1, BCM92045DG-Flash_UHE(0x2100), Broadcom Corp(0x0a5c), rev 1.00 port 2 addr 9: full speed, self powered, config 1, BCM92045DG-Flash_UHE(0x4502), Broadcom Corp(0x0a5c), rev 1.00 port 3 addr 10: full speed, self powered, config 1, BCM92045DG-Flash_UHE(0x4503), Broadcom Corp(0x0a5c), rev 1.00 Controller /dev/usb1: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), SiS(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), SiS(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), SiS(0x0000), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 powered port 6 powered # pciconf -lv hostb0@pci0:0:0:0: class=0x060000 card=0x06551039 chip=0x06551039 rev=0x10 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS655 Host-to-PCI Bridge' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 chip=0x00021039 rev=0x00 hdr=0x01 vendor = 'Silicon Integrated Systems (SiS)' device = '6202 Virtual PCI to PCI Bridge (AGP)' class = bridge subclass = PCI-PCI isab0@pci0:0:2:0: class=0x060100 card=0x00000000 chip=0x00081039 rev=0x04 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS PCI to ISA Bridge (LPC Bridge)' class = bridge subclass = PCI-ISA fwohci0@pci0:0:2:3: class=0x0c0010 card=0x13941039 chip=0x70071039 rev=0x00 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS OHCI Compliant FireWire Controller' class = serial bus subclass = FireWire atapci0@pci0:0:2:5: class=0x010180 card=0x55131039 chip=0x55131039 rev=0x00 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5513 EIDE Controller (A,B step)' class = mass storage subclass = ATA pcm0@pci0:0:2:7: class=0x040100 card=0xa0021458 chip=0x70121039 rev=0xa0 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS7012 PCI Audio Accelerator' class = multimedia subclass = audio ohci0@pci0:0:3:0: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x0f hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5597/8 Universal Serial Bus Controller' class = serial bus subclass = USB ohci1@pci0:0:3:1: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x0f hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5597/8 Universal Serial Bus Controller' class = serial bus subclass = USB ohci2@pci0:0:3:2: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x0f hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS5597/8 Universal Serial Bus Controller' class = serial bus subclass = USB ehci0@pci0:0:3:3: class=0x0c0320 card=0x50041458 chip=0x70021039 rev=0x00 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS7002 USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB ahc0@pci0:0:10:0: class=0x010000 card=0x00000000 chip=0x71789004 rev=0x03 hdr=0x00 vendor = 'Adaptec Inc' device = 'AHA-2940/2940W Fast/Fast-Wide SCSI Ctrlr' class = mass storage subclass = SCSI rl0@pci0:0:11:0: class=0x020000 card=0x13031186 chip=0x13001186 rev=0x10 hdr=0x00 vendor = 'D-Link System Inc' device = 'DL 10038C or 10038D (Remark of Realtek RTL-8139) Fast Ethernet Adapter' class = network subclass = ethernet nvidia0@pci0:1:0:0: class=0x030000 card=0x809f1043 chip=0x017110de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'GeForce4 MX 440 [NV17.2]' class = display subclass = VGA # vmstat -ai interrupt total rate ??? 0 0 irq1: atkbd0 25536 4 stray irq1 0 0 irq0: 0 0 stray irq0 0 0 irq3: sio1 0 0 stray irq3 0 0 irq4: sio0 0 0 stray irq4 0 0 irq5: 0 0 stray irq5 0 0 irq6: fdc0 10 0 stray irq6 0 0 irq7: ppbus0 ppc0 0 0 stray irq7 0 0 irq8: 0 0 stray irq8 0 0 irq9: acpi0 0 0 stray irq9 0 0 irq10: 0 0 stray irq10 0 0 irq11: 0 0 stray irq11 0 0 irq12: 0 0 stray irq12 0 0 irq13: 0 0 stray irq13 0 0 irq14: ata0 16546 2 stray irq14 0 0 irq15: ata1 45670 7 stray irq15 0 0 irq16: nvidia0 334184 53 stray irq16 0 0 irq17: fwohci0 3 0 stray irq17 0 0 irq18: pcm0 ahc0 540635 86 stray irq18 0 0 irq19: rl0 8115 1 stray irq19 0 0 irq20: ohci0 892174 143 stray irq20 0 0 irq21: ohci1 120905 19 stray irq21 0 0 irq22: ohci2 0 0 stray irq22 0 0 irq23: ehci0 7 0 stray irq23 0 0 cpu0: timer 12441509 1999 Total 14425294 2318 Thanks, Wayne From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 16:14:51 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99DDC16A417 for ; Fri, 8 Feb 2008 16:14:51 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF5913C455 for ; Fri, 8 Feb 2008 16:14:51 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (vpn-cl-166-210.rz.uni-karlsruhe.de [141.3.166.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id D344F405478; Fri, 8 Feb 2008 17:16:11 +0100 (CET) Message-ID: <47AC7FF6.1020801@bsdforen.de> Date: Fri, 08 Feb 2008 17:14:46 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Tom Evans References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> <47ABF66E.4040807@bsdforen.de> <1202485501.2126.34.camel@localhost> In-Reply-To: <1202485501.2126.34.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Carlos A. M. dos Santos" , freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 16:14:51 -0000 Tom Evans wrote: > On Fri, 2008-02-08 at 11:43 -0200, Carlos A. M. dos Santos wrote: >> >> Yes, it happens in my notebook (HP NX6320). > > Sorry to jump into this thread, as it is slightly off-topic - I have a > HP NC6320 (so not quite exact same model, but specs seem extremely close > - mine is a core duo, not core 2 duo, but chipset, graphics, screen size > is identical), and cannot get my DVD drive to operate in DMA mode. I > track RELENG_7, last updated 3rd Feb. > > I have: > > acd0: DVDR at ata0-master PIO4 > > on a > > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x60a0-0x60af irq 16 at device 31.1 > on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > > with settings of > > hw.ata.wc: 1 > hw.ata.atapi_dma: 1 > hw.ata.ata_dma: 1 > > atacontrol says this about the DVD drive: > >> # atacontrol info ata0; atacontrol cap acd0 > Master: acd0 ATA/ATAPI revision 6 > Slave: no device present > > Protocol ATA/ATAPI revision 6 > device model MATSHITADVD-RAM UJ-840S > serial number > firmware revision 1.11 > cylinders 0 > heads 0 > sectors/track 0 > lba supported > lba48 not supported > dma supported > overlap not supported > > Feature Support Enable Value Vendor > write cache no no > read ahead no no > Tagged Command Queuing (TCQ) no no 0/0x00 > SMART no no > microcode download no no > security no no > power management no no > advanced power management no no 0/0x00 > automatic acoustic management no no 0/0x00 0/0x00 > >> # atacontrol mode acd0 > current mode = PIO4 > > If I try to turn on DMA, I just get WDMA2, which just doesn't cut it: I think any DMA mode is fast enough to handle a DVD drive. There's just no necessity for more. >> # atacontrol mode acd0 udma5 > current mode = WDMA2 Same as for me. I'm satisfied with the speed of the drive. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 17:18:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88D2D16A41B for ; Fri, 8 Feb 2008 17:18:14 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by mx1.freebsd.org (Postfix) with ESMTP id 612FC13C4D9 for ; Fri, 8 Feb 2008 17:18:05 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by fk-out-0910.google.com with SMTP id b27so4306897fka.11 for ; Fri, 08 Feb 2008 09:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; bh=7MYLmL6l6sPaw3sXiugSyFOX12SUk1C/rbzNsRdxaEs=; b=Wvbyu85GDbLzSgtPL1a1DPAIwbHDx6W7Xacrof9kyDWPTvigjw/CwUpi3AFS6fMRyRKWWiXi1fD2x/wFZ579sue+benY40dnyESznnvlr2ri1japEYIPvCEBCRdy7+QnE5hVzTkW77B6kJBbqP6exnq0ZGBsYm6a6wMKR93Rpdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=ftRx9/UUdnbWLo4xuJEjUmt1FtAjES5QptL6jz/hdHwEkAwUShKGj6qUSN132Ii+ROwF05sRjU7eZuYsg2dDmSGfJ6G9UQazE/I9H11dX12Blnx8qo2JS8tUuZeC/Gt4NOnIbLvIvxkrmdWsXDQZx8rOBl7e8n6X+aM7Biw3mLQ= Received: by 10.82.138.6 with SMTP id l6mr606142bud.13.1202491073357; Fri, 08 Feb 2008 09:17:53 -0800 (PST) Received: from ?127.0.0.1? ( [217.206.187.79]) by mx.google.com with ESMTPS id m5sm16777468gve.11.2008.02.08.09.17.52 (version=SSLv3 cipher=RC4-MD5); Fri, 08 Feb 2008 09:17:52 -0800 (PST) From: Tom Evans To: Dominic Fandrey In-Reply-To: <47AC7FF6.1020801@bsdforen.de> References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> <47ABF66E.4040807@bsdforen.de> <1202485501.2126.34.camel@localhost> <47AC7FF6.1020801@bsdforen.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-14vnf+Nq/tk3ELyiINLM" Date: Fri, 08 Feb 2008 17:17:51 +0000 Message-Id: <1202491071.2126.42.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Cc: "Carlos A. M. dos Santos" , freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 17:18:14 -0000 --=-14vnf+Nq/tk3ELyiINLM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-02-08 at 17:14 +0100, Dominic Fandrey wrote: > Tom Evans wrote: > > If I try to turn on DMA, I just get WDMA2, which just doesn't cut it: >=20 > I think any DMA mode is fast enough to handle a DVD drive. There's just n= o=20 > necessity for more. >=20 WDMA is not UDMA. Any UDMA variant would be enough. WDMA2 provides a maximum of 16MiB/s, which will frequently lead to buffer underruns viewing a DVD. UDMA2 provides a maximum of 33MiB/s, which IS plenty. > >> # atacontrol mode acd0 udma5 > > current mode =3D WDMA2 >=20 > Same as for me. I'm satisfied with the speed of the drive. I'm rarely satisfied - I'm quite often not bothered enough to pursue :) Tom --=-14vnf+Nq/tk3ELyiINLM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHrI64lcRvFfyds/cRArc5AJ9gLTJ55RUTP5E2ghd76RLBSloleACfcksw MP64ram49FYhtHN1zNR2O/M= =VqbW -----END PGP SIGNATURE----- --=-14vnf+Nq/tk3ELyiINLM-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 17:37:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B678E16A421 for ; Fri, 8 Feb 2008 17:37:09 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (unknown [IPv6:2001:610:1908:1000:204:23ff:feb7:ef56]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4F513C459 for ; Fri, 8 Feb 2008 17:37:09 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from lux.student.utwente.nl (lux.student.utwente.nl [130.89.170.81]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id m18Hb1nr024180; Fri, 8 Feb 2008 18:37:02 +0100 From: Pieter de Goeje To: freebsd-stable@freebsd.org Date: Fri, 8 Feb 2008 18:37:01 +0100 User-Agent: KMail/1.9.7 References: <47A9F835.1060200@bsdforen.de> <47AC7FF6.1020801@bsdforen.de> <1202491071.2126.42.camel@localhost> In-Reply-To: <1202491071.2126.42.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802081837.01676.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact servicedesk@icts.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Tom Evans , Dominic Fandrey , "Carlos A. M. dos Santos" Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 17:37:09 -0000 On Friday 08 February 2008, Tom Evans wrote: > On Fri, 2008-02-08 at 17:14 +0100, Dominic Fandrey wrote: > > Tom Evans wrote: > > > If I try to turn on DMA, I just get WDMA2, which just doesn't cut it: > > > > I think any DMA mode is fast enough to handle a DVD drive. There's just > > no necessity for more. > > WDMA is not UDMA. Any UDMA variant would be enough. WDMA2 provides a > maximum of 16MiB/s, which will frequently lead to buffer underruns > viewing a DVD. UDMA2 provides a maximum of 33MiB/s, which IS plenty. DVD video is encoded at max. ~7Mbit/sec, which is way below 16MB/sec. You should have no problems viewing dvds. > > > >> # atacontrol mode acd0 udma5 > > > > > > current mode = WDMA2 > > > > Same as for me. I'm satisfied with the speed of the drive. > > I'm rarely satisfied - I'm quite often not bothered enough to pursue :) > > Tom -- Pieter de Goeje From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 18:35:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB97216A469 for ; Fri, 8 Feb 2008 18:35:18 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 6D2B413C4D9 for ; Fri, 8 Feb 2008 18:35:18 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 02871405478; Fri, 8 Feb 2008 19:35:55 +0100 (CET) Message-ID: <47ACA0E4.2030905@bsdforen.de> Date: Fri, 08 Feb 2008 19:35:16 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: Tom Evans References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> <47ABF66E.4040807@bsdforen.de> <1202485501.2126.34.camel@localhost> <47AC7FF6.1020801@bsdforen.de> <1202491071.2126.42.camel@localhost> In-Reply-To: <1202491071.2126.42.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Carlos A. M. dos Santos" , freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 18:35:18 -0000 Tom Evans wrote: > On Fri, 2008-02-08 at 17:14 +0100, Dominic Fandrey wrote: >> Tom Evans wrote: >>> If I try to turn on DMA, I just get WDMA2, which just doesn't cut it: >> I think any DMA mode is fast enough to handle a DVD drive. There's just no >> necessity for more. >> > > WDMA is not UDMA. Any UDMA variant would be enough. WDMA2 provides a > maximum of 16MiB/s, which will frequently lead to buffer underruns > viewing a DVD. UDMA2 provides a maximum of 33MiB/s, which IS plenty. 16MB/s is exactly what is needed for 12x DVD access. I think this is the usual speed for a Notebook drive nowadays and it suffices for me. >>>> # atacontrol mode acd0 udma5 >>> current mode = WDMA2 >> Same as for me. I'm satisfied with the speed of the drive. > > I'm rarely satisfied - I'm quite often not bothered enough to pursue :) Well, if 12x speed is not enough for you, you have to use an external drive. This is not a driver issue. It's just what your drive supports. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 20:41:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25C5316A420 for ; Fri, 8 Feb 2008 20:41:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id A9CF113C46B for ; Fri, 8 Feb 2008 20:41:10 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m18Kf8Ai022559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2008 07:41:09 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m18Kf81E087541; Sat, 9 Feb 2008 07:41:08 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m18Kf8gq087540; Sat, 9 Feb 2008 07:41:08 +1100 (EST) (envelope-from peter) Date: Sat, 9 Feb 2008 07:41:08 +1100 From: Peter Jeremy To: "Carlos A. M. dos Santos" Message-ID: <20080208204107.GG4008@server.vk2pj.dyndns.org> References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+mr2ctTDD1GjnQwB" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core 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, 08 Feb 2008 20:41:11 -0000 --+mr2ctTDD1GjnQwB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2008 at 12:22:38AM -0200, Carlos A. M. dos Santos wrote: >Wow, now I'm *really* surprised. I used to think that putting > > hw.ata.ata_dma=3D"1" > hw.ata.atapi_dma=3D"1" hw.ata.ata_dma has no effect on ATAPI devices. >in /boot/loader.conf would be enough to enable DMA mode. Looking at the code, atapi_dma will enable UDMA modes if the drive supports at least UDMA2 them but ignores WDMA capabilities. This was part of the ATA mkIII update - which is in 6.x but was not MFC'd to 5.x. If you do a verbose boot, you will get a probe line reporting the drive capabilities. Unfortunately, atacontrol only reports 'dma [not] supported' - not what capabilities the drive has. >1. Is this related to using atapicam? No. >2. Should this be considered a bug? Possibly. The relevant commit message doesn't mention the ATAPI DMA changes so it's not clear whether this is an oversight or deliberate. I do recall that there have been problems in the past with ATAPI drives that would advertise DMA capabilities but would misbehave if you used DMA (atapi_dma was disabled by default in 5.x for this reason). I'm not sure if the current code is at effort to avoid this. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --+mr2ctTDD1GjnQwB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHrL5j/opHv/APuIcRAsMpAJ9J6MNX0fu10xG+msFVbb6HPQu2KwCeP30i kw5LNtRaCsy5CvHXyzHeKWo= =Uxbb -----END PGP SIGNATURE----- --+mr2ctTDD1GjnQwB-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 21:37:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF8E816A41B for ; Fri, 8 Feb 2008 21:37:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD5A13C442 for ; Fri, 8 Feb 2008 21:37:29 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m18LbIoG032196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2008 08:37:19 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m18LbIkt087880; Sat, 9 Feb 2008 08:37:18 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m18LbFJG087879; Sat, 9 Feb 2008 08:37:15 +1100 (EST) (envelope-from peter) Date: Sat, 9 Feb 2008 08:37:15 +1100 From: Peter Jeremy To: Primeroz lists Message-ID: <20080208213715.GL4008@server.vk2pj.dyndns.org> References: <55b8c6fe0802040450r7ca3e739s931be2d38f499fc2@mail.gmail.com> <28875927.5811202240277979.JavaMail.root@ly.sdf.com> <55b8c6fe0802060131y6e0e27d8j4e7db10381c6bfab@mail.gmail.com> <55b8c6fe0802080640l39fc5056gf02c1f64b4120594@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Ocr+Jy+jPJR1APa" Content-Disposition: inline In-Reply-To: <55b8c6fe0802080640l39fc5056gf02c1f64b4120594@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org, Tom Samplonius Subject: Re: Crashing repeatedly: 6.2-RELEASE-p5 and MySQL 5.0.41 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, 08 Feb 2008 21:37:30 -0000 --/Ocr+Jy+jPJR1APa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2008 at 02:40:41PM +0000, Primeroz lists wrote: >#7 0xffffffff802af5e3 in _sx_xlock (sx=3D0xffffffff802b02bd, file=3D0x4 >
, line=3D-2140937936) > at /usr/src/sys/kern/kern_sx.c:192 >192 } Well, the file and line are nonsense. >#17 0xffffffff802b845e in umtx_key_get (td=3D0xffffff007a69b440, >umtx=3D0xffffffffba224a20, key=3D0x156a9) > at /usr/src/sys/kern/kern_umtx.c:312 >312 if (vm_map_lookup(&map, (vm_offset_t)umtx, VM_PROT_WRITE, And there are some steps between these two calls that kgdb has not decoded properly. Next time you get a crash, can you please display the backtrace in ddb and then use addr2line or similar to convert the addresses into line numbers. This will allow us to determine the correct backtrace. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --/Ocr+Jy+jPJR1APa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHrMuL/opHv/APuIcRAmaAAJ0VEBb1lSBE79mQPzqej/ADw13iYwCfXtS/ Si7pp+3iDvtryM9gY44oOf8= =GltZ -----END PGP SIGNATURE----- --/Ocr+Jy+jPJR1APa-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 22:29:44 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D675416A417; Fri, 8 Feb 2008 22:29:44 +0000 (UTC) (envelope-from joe@skyrush.com) Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by mx1.freebsd.org (Postfix) with ESMTP id 75BD913C442; Fri, 8 Feb 2008 22:29:44 +0000 (UTC) (envelope-from joe@skyrush.com) Received: from [10.0.3.98] (mail.boulder.swri.edu [65.241.78.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id 301BB8F394; Fri, 8 Feb 2008 15:29:43 -0700 (MST) Message-ID: <47ACD7D4.5050905@skyrush.com> Date: Fri, 08 Feb 2008 15:29:40 -0700 From: Joe Peterson User-Agent: Thunderbird 2.0.0.9 (X11/20071119) MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Analysis of disk file block with ZFS checksum error 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, 08 Feb 2008 22:29:44 -0000 In my experimentation with the ZFS filesystem, I encountered one case of a file block with a checksum mismatch. Doing a "zpool scrub" revealed it, and trying to read the file yielded an error - only the part of the file before the bad block was read (ZFS aborts reading at this point, which makes sense), resulting in a short file. The reason the CKSUM error is not fixable is because my ZFS pool contains only one device (no mirror or RAIDZ), but I do have the original/good version of the file affected. Here's the output of zpool status (new scrub in process): pool: tank state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub in progress, 64.36% done, 0h18m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 2 hda6 ONLINE 0 0 2 errors: Permanent errors have been detected in the following files: /mnt/tank/fbsd/home/joe/music/jukebox/christmas/Esquivel/ Merry_XMas_from_the_SpaceAge_Bachelor_Pad/07-Snowfall.mp3 I was curious about what actually happened: was this a ZFS bug, trouble with its metadata, or truly a bad block? In order to determine this, I modified ZFS's source code temporarily to ignore the checksum mismatch and let the file read fully. What I then got was the full-length file and no errors, showing that there were no disk read errors associated with the read (I already had assumed this from the fact that zpool status showed only a non-zero CKSUM count), however, I may have seen other error counts previously (ZFS resets them to zero on, e.g., reboot). I received no errors when originally copying this file *to* the ZFS pool - only on subsequent reads/scrubs. (Note that I have posted before about DMA errors in my log for the disk I am using, but I have had nothing but successful SeaTools tests (surface scans) of the drive. Jeremy Chadwick had similar issues, as did others, so I think it is worth investigating if there is some OS/software cause rather than real HW issues. This is one reason I wanted to investigate my ZFS checksum issue more deeply.) I also have a good backup of the file in question, so I now have two copies of the file: one good, and one with a bad block. The file is 3575936 bytes long, and recordsize (in ZFS) is 128K, making the file about 27 blocks long. Curiously, the bad section of the file is exactly 65536 bytes long (1/2 a block). The bad block starts at exactly the 5th 128K block (byte 65536 or hex a0000). I wanted to see the characteristics of the bad data. Was just one bit flipped randomly? No. It is just one bit or set of bits in the bytes that are affected? It doesn't seem so. Were there any other stange patterns here? Well, yes, and maybe someout out there with more knowledge/experience in disk modes of failure will recognize something (I have included some data below). For one thing (as I mentioned), only 65536 bytes are bad (and it's exactly this many, with a few "good" bytes thrown in, but not far from what matches random chance would produce. Also, all bad bytes have a zero in the high bit - interesting? Also, near the end of the block, the bad bytes all go to zero, strangely coincident with the first "good" zero in that bad block - not sure if that's coincidence or not. Also, I calculated the number of "Bits same" (matching bits) in the good vs. bad bytes, and it appears fairly random, so it appears that the bad bytes are very random in nature and not correlated much at all with the good bytes. So except for the fact that the 2nd half (65536 bytes) of the ZFS block are good, the bad block seems to consist of random data, except for the string of zero bytes near the end and the zero high-bit. It's not as if one bit on the disk flipped - it affects the whole (1/2) block. Does this seem like a disk error, controller error/bug, cable problem (I recently put a new cable on, so I doubt this). It seems to me something more systemic rather than a random bit error - opinions are more than welcome. Here is some info from a python program I wrote to look at the data (I've left out spans of essentially uninteresting portions showing similar stuff, but I can get you the whole thing if interested): File pos Good Bad Match Good (bin) Bad (bin) Bits same 0009fff0 d9 d9 Yes 11011001 11011001 8 0009fff1 05 05 Yes 00000101 00000101 8 0009fff2 c1 c1 Yes 11000001 11000001 8 0009fff3 81 81 Yes 10000001 10000001 8 0009fff4 5f 5f Yes 01011111 01011111 8 0009fff5 66 66 Yes 01100110 01100110 8 0009fff6 5e 5e Yes 01011110 01011110 8 0009fff7 a1 a1 Yes 10100001 10100001 8 0009fff8 ca ca Yes 11001010 11001010 8 0009fff9 9d 9d Yes 10011101 10011101 8 0009fffa 00 00 Yes 00000000 00000000 8 0009fffb 90 90 Yes 10010000 10010000 8 0009fffc 32 32 Yes 00110010 00110010 8 0009fffd 62 62 Yes 01100010 01100010 8 0009fffe a8 a8 Yes 10101000 10101000 8 0009ffff b2 b2 Yes 10110010 10110010 8 --- Start of bad block --- 000a0000 d1 24 No 11010001 00100100 2 000a0001 6b 7b No 01101011 01111011 7 000a0002 d1 31 No 11010001 00110001 5 000a0003 56 33 No 01010110 00110011 4 000a0004 44 38 No 01000100 00111000 3 000a0005 c3 41 No 11000011 01000001 6 000a0006 df 46 No 11011111 01000110 4 000a0007 07 45 No 00000111 01000101 6 000a0008 4c 7b No 01001100 01111011 3 000a0009 a0 40 No 10100000 01000000 5 000a000a 54 0a No 01010100 00001010 3 000a000b 35 40 No 00110101 01000000 3 000a000c 88 24 No 10001000 00100100 4 000a000d 38 24 No 00111000 00100100 5 000a000e f5 7d No 11110101 01111101 6 000a000f 28 31 No 00101000 00110001 5 . . . 000af6c1 d3 33 No 11010011 00110011 5 000af6c2 97 39 No 10010111 00111001 3 000af6c3 a5 32 No 10100101 00110010 3 000af6c4 6a 41 No 01101010 01000001 4 000af6c5 16 39 No 00010110 00111001 3 000af6c6 f2 7d No 11110010 01111101 3 000af6c7 21 40 No 00100001 01000000 5 000af6c8 52 0a No 01010010 00001010 5 000af6c9 00 00 Yes 00000000 00000000 8 000af6ca 2c 00 No 00101100 00000000 5 000af6cb 42 00 No 01000010 00000000 6 000af6cc 31 00 No 00110001 00000000 5 000af6cd a1 00 No 10100001 00000000 5 000af6ce d1 00 No 11010001 00000000 4 000af6cf 90 00 No 10010000 00000000 6 000af6d0 9c 00 No 10011100 00000000 4 . . . 000afff8 26 00 No 00100110 00000000 5 000afff9 8c 00 No 10001100 00000000 5 000afffa a8 00 No 10101000 00000000 5 000afffb 0c 00 No 00001100 00000000 6 000afffc f1 00 No 11110001 00000000 3 000afffd 93 00 No 10010011 00000000 4 000afffe 2c 00 No 00101100 00000000 5 000affff 2e 00 No 00101110 00000000 4 --- End of bad block --- 000b0000 62 62 Yes 01100010 01100010 8 000b0001 56 56 Yes 01010110 01010110 8 000b0002 91 91 Yes 10010001 10010001 8 000b0003 04 04 Yes 00000100 00000100 8 000b0004 01 01 Yes 00000001 00000001 8 000b0005 2d 2d Yes 00101101 00101101 8 000b0006 0e 0e Yes 00001110 00001110 8 000b0007 89 89 Yes 10001001 10001001 8 000b0008 8a 8a Yes 10001010 10001010 8 000b0009 ad ad Yes 10101101 10101101 8 000b000a 4e 4e Yes 01001110 01001110 8 000b000b a3 a3 Yes 10100011 10100011 8 000b000c 13 13 Yes 00010011 00010011 8 000b000d 4d 4d Yes 01001101 01001101 8 000b000e 07 07 Yes 00000111 00000111 8 000b000f 66 66 Yes 01100110 01100110 8 . . . -Joe From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 22:31:58 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B17916A47E for ; Fri, 8 Feb 2008 22:31:58 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from acme.spoerlein.net (acme.spoerlein.net [217.172.44.86]) by mx1.freebsd.org (Postfix) with ESMTP id D5C0513C4E8 for ; Fri, 8 Feb 2008 22:31:57 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (e180159106.adsl.alicedsl.de [85.180.159.106]) by acme.spoerlein.net (8.14.1/8.14.1) with ESMTP id m18MVsQu011721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Feb 2008 23:31:55 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.2/8.14.2) with ESMTP id m18MJgKC005452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Feb 2008 23:19:42 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.2/8.14.2/Submit) id m18MJg7X005449; Fri, 8 Feb 2008 23:19:42 +0100 (CET) (envelope-from uspoerlein@gmail.com) X-Authentication-Warning: roadrunner.spoerlein.net: uqs set sender to uspoerlein@gmail.com using -f Date: Fri, 8 Feb 2008 23:19:41 +0100 From: Ulrich Spoerlein To: Ivan Voras Message-ID: <20080208221941.GD1479@roadrunner.spoerlein.net> Mail-Followup-To: Ivan Voras , freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: finstall alpha3 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, 08 Feb 2008 22:31:58 -0000 On Wed, 06.02.2008 at 11:48:22 +0100, Ivan Voras wrote: > On the other hand, here's what it *can* do currently: >=20 > - it's a "live" CD environment, completely like an already installed > FreeBSD system, only running from a read-only media (e.g. it's usable as > a "FixIt" system) This is great, and I think it's the way to go. Since I had to repair my system the last days with a 'FixIt' CD, I think this mode could get even more improvement. It would be nice, if there where some additional system repair tools available on this CD (license permitting, of course). You'd just have to make sure to still install a clean FreeBSD. This could be accomplished by using unionfs for the 'enhanced fixit overlay' or something like that. Cheers, Ulrich Spoerlein --=20 It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 22:58:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D7416A418; Fri, 8 Feb 2008 22:58:14 +0000 (UTC) (envelope-from joe@skyrush.com) Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by mx1.freebsd.org (Postfix) with ESMTP id B090F13C459; Fri, 8 Feb 2008 22:58:14 +0000 (UTC) (envelope-from joe@skyrush.com) Received: from [10.0.3.98] (mail.boulder.swri.edu [65.241.78.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id 9A00D8F394; Fri, 8 Feb 2008 15:58:12 -0700 (MST) Message-ID: <47ACDE82.1050100@skyrush.com> Date: Fri, 08 Feb 2008 15:58:10 -0700 From: Joe Peterson User-Agent: Thunderbird 2.0.0.9 (X11/20071119) MIME-Version: 1.0 To: Mark Day References: <47ACD7D4.5050905@skyrush.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 08 Feb 2008 22:58:15 -0000 Mark Day wrote: > Based on the subset of data you posted, the bad data looks like ASCII > text. > The bad data from offset a0000 to a000f is: > > ${138AFE{@ > @$$}1 > > The bad data from offset af6c1 to af6c8 is: > > 392A9}@ > > I don't recognize the content beyond that, but I'd guess that somehow > the > contents of some other file managed to overwrite that portion of the bad > file. As for how that happened, I don't know. But if someone > recognizes > where the bad content came from, that might be a clue. Gary/Mark, Good eye! Yes, it indeed does appear to be ASCII. I *thought* something in the repetition when I originally did an od -a looked interesting. I dumped the whole bad section as a string, and here's (partly) what I get: ${138AFE{@ @$$}138AFE}@ @$${138AFF{@ [A3:^80(^91^2146F)] @$$}138AFF}@ @$${138B00{@ @$$}138B00}@ @$${138B01{@ [181:^80(^91^2146F)] @$$}138B01}@ @$${138B02{@ @$$}138B02}@ @$${138B03{@ [2C:^80(^91^2146F)] @$$}138B03}@ @$${138B04{@ @$$}138B04}@ . . . @$${138B8B{@ <(21470=Thu Jan 24 23:20:58 2008)> [117:^80(^91^21470)] @$$}138B8B}@ . . . @$${138C18{@ <(21472=1201242069)>[-2:^80(^82^85)(^83^1B5)(^84=b)(^85=1)(^86=0)(^87=0) (^88=0)(^89^2146C)(^8A=)(^8B=40)(^8C=2e)(^8D^84)(^8E=0)(^90^21472) (^91^21460)] @$$}138C18}@ @$${138C19{@ <(21473=a72f78)>[2:^80(^89^21473)] @$$}138C19}@ @$${138C1A{@ @$$}138C1A}@ . . . and more of the same. Note the date string. There are several like that. Anyone recognize this text format? -Joe From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 23:02:08 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0B5916A468; Fri, 8 Feb 2008 23:02:08 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1F213C461; Fri, 8 Feb 2008 23:02:08 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 3680B1A4D82; Fri, 8 Feb 2008 15:02:08 -0800 (PST) Date: Fri, 8 Feb 2008 15:02:08 -0800 From: Alfred Perlstein To: Joe Peterson Message-ID: <20080208230208.GM99258@elvis.mu.org> References: <47ACD7D4.5050905@skyrush.com> <47ACDE82.1050100@skyrush.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47ACDE82.1050100@skyrush.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org, Mark Day , freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 08 Feb 2008 23:02:08 -0000 * Joe Peterson [080208 14:58] wrote: > Mark Day wrote: > > Based on the subset of data you posted, the bad data looks like ASCII > > text. > > The bad data from offset a0000 to a000f is: > > > > ${138AFE{@ > > @$$}1 > > > > The bad data from offset af6c1 to af6c8 is: > > > > 392A9}@ > > > > I don't recognize the content beyond that, but I'd guess that somehow > > the > > contents of some other file managed to overwrite that portion of the bad > > file. As for how that happened, I don't know. But if someone > > recognizes > > where the bad content came from, that might be a clue. > > > Gary/Mark, > > Good eye! Yes, it indeed does appear to be ASCII. I *thought* > something in the repetition when I originally did an od -a looked > interesting. > > I dumped the whole bad section as a string, and here's (partly) what I get: > > ${138AFE{@ > @$$}138AFE}@ > > @$${138AFF{@ > [A3:^80(^91^2146F)] > @$$}138AFF}@ > > @$${138B00{@ Looks like terminal output/codes that have been stripped... -Alfred From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 23:07:22 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FB6316A418; Fri, 8 Feb 2008 23:07:22 +0000 (UTC) (envelope-from mday@apple.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.freebsd.org (Postfix) with ESMTP id 81DCF13C465; Fri, 8 Feb 2008 23:07:22 +0000 (UTC) (envelope-from mday@apple.com) Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id 181D2218F490; Fri, 8 Feb 2008 14:49:55 -0800 (PST) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 00CE0464002; Fri, 8 Feb 2008 14:49:55 -0800 (PST) X-AuditID: 11807135-a9033bb00000423e-ab-47acdc921fbe Received: from doomsday.apple.com (doomsday.apple.com [17.202.43.217]) by relay12.apple.com (Apple SCV relay) with ESMTP id D0FE9420005; Fri, 8 Feb 2008 14:49:54 -0800 (PST) Message-Id: From: Mark Day To: Joe Peterson In-Reply-To: <47ACD7D4.5050905@skyrush.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 8 Feb 2008 14:49:54 -0800 References: <47ACD7D4.5050905@skyrush.com> X-Mailer: Apple Mail (2.919.2) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 08 Feb 2008 23:07:22 -0000 On Feb 8, 2008, at 2:29 PM, Joe Peterson wrote: > For one thing (as I mentioned), only 65536 bytes are bad (and it's > exactly this many, with a few "good" bytes thrown in, but not far from > what matches random chance would produce. Also, all bad bytes have a > zero in the high bit - interesting? Also, near the end of the block, > the bad bytes all go to zero, strangely coincident with the first > "good" > zero in that bad block - not sure if that's coincidence or not. > Also, I > calculated the number of "Bits same" (matching bits) in the good vs. > bad > bytes, and it appears fairly random, so it appears that the bad bytes > are very random in nature and not correlated much at all with the good > bytes. > > So except for the fact that the 2nd half (65536 bytes) of the ZFS > block > are good, the bad block seems to consist of random data, except for > the > string of zero bytes near the end and the zero high-bit. It's not > as if > one bit on the disk flipped - it affects the whole (1/2) block. Does > this seem like a disk error, controller error/bug, cable problem (I > recently put a new cable on, so I doubt this). It seems to me > something > more systemic rather than a random bit error - opinions are more than > welcome. Based on the subset of data you posted, the bad data looks like ASCII text. The bad data from offset a0000 to a000f is: ${138AFE{@ @$$}1 The bad data from offset af6c1 to af6c8 is: 392A9}@ I don't recognize the content beyond that, but I'd guess that somehow the contents of some other file managed to overwrite that portion of the bad file. As for how that happened, I don't know. But if someone recognizes where the bad content came from, that might be a clue. -Mark From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 23:15:57 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5FFF16A420; Fri, 8 Feb 2008 23:15:56 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id A2A9B13C45B; Fri, 8 Feb 2008 23:15:55 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 08 Feb 2008 17:46:28 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.8.6-GA) with ESMTP id OKA67028; Fri, 8 Feb 2008 17:46:23 -0500 (EST) Received: from 207-172-55-230.c3-0.tlg-ubr5.atw-tlg.pa.cable.rcn.com (HELO [10.56.78.161]) ([207.172.55.230]) by smtp01.lnh.mail.rcn.net with ESMTP; 08 Feb 2008 17:45:19 -0500 Message-ID: <47ACDBB1.40604@rcn.com> Date: Fri, 08 Feb 2008 17:46:09 -0500 From: Gary Corcoran User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Joe Peterson References: <47ACD7D4.5050905@skyrush.com> In-Reply-To: <47ACD7D4.5050905@skyrush.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 08 Feb 2008 23:15:57 -0000 Joe Peterson wrote: > In my experimentation with the ZFS filesystem, I encountered one case of > a file block with a checksum mismatch. Doing a "zpool scrub" revealed > it, and trying to read the file yielded an error - only the part of the > file before the bad block was read (ZFS aborts reading at this point, > which makes sense), resulting in a short file. The reason the CKSUM > error is not fixable is because my ZFS pool contains only one device (no > mirror or RAIDZ), but I do have the original/good version of the file > affected. Here's the output of zpool status (new scrub in process): > > pool: tank > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scrub: scrub in progress, 64.36% done, 0h18m to go > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 2 > hda6 ONLINE 0 0 2 > > errors: Permanent errors have been detected in the following files: > > /mnt/tank/fbsd/home/joe/music/jukebox/christmas/Esquivel/ > Merry_XMas_from_the_SpaceAge_Bachelor_Pad/07-Snowfall.mp3 > > > I was curious about what actually happened: was this a ZFS bug, trouble > with its metadata, or truly a bad block? In order to determine this, I > modified ZFS's source code temporarily to ignore the checksum mismatch > and let the file read fully. What I then got was the full-length file > and no errors, showing that there were no disk read errors associated > with the read (I already had assumed this from the fact that zpool > status showed only a non-zero CKSUM count), however, I may have seen > other error counts previously (ZFS resets them to zero on, e.g., > reboot). I received no errors when originally copying this file *to* > the ZFS pool - only on subsequent reads/scrubs. > > (Note that I have posted before about DMA errors in my log for the disk > I am using, but I have had nothing but successful SeaTools tests > (surface scans) of the drive. Jeremy Chadwick had similar issues, as > did others, so I think it is worth investigating if there is some > OS/software cause rather than real HW issues. This is one reason I > wanted to investigate my ZFS checksum issue more deeply.) > > I also have a good backup of the file in question, so I now have two > copies of the file: one good, and one with a bad block. The file is > 3575936 bytes long, and recordsize (in ZFS) is 128K, making the file > about 27 blocks long. Curiously, the bad section of the file is exactly > 65536 bytes long (1/2 a block). The bad block starts at exactly the 5th > 128K block (byte 65536 or hex a0000). > > I wanted to see the characteristics of the bad data. Was just one bit > flipped randomly? No. It is just one bit or set of bits in the bytes > that are affected? It doesn't seem so. Were there any other stange > patterns here? Well, yes, and maybe someout out there with more > knowledge/experience in disk modes of failure will recognize something > (I have included some data below). > > For one thing (as I mentioned), only 65536 bytes are bad (and it's > exactly this many, with a few "good" bytes thrown in, but not far from > what matches random chance would produce. Also, all bad bytes have a > zero in the high bit - interesting? Also, near the end of the block, > the bad bytes all go to zero, strangely coincident with the first "good" > zero in that bad block - not sure if that's coincidence or not. Also, I > calculated the number of "Bits same" (matching bits) in the good vs. bad > bytes, and it appears fairly random, so it appears that the bad bytes > are very random in nature and not correlated much at all with the good > bytes. > > So except for the fact that the 2nd half (65536 bytes) of the ZFS block > are good, the bad block seems to consist of random data, except for the > string of zero bytes near the end and the zero high-bit. It's not as if > one bit on the disk flipped - it affects the whole (1/2) block. Does > this seem like a disk error, controller error/bug, cable problem (I > recently put a new cable on, so I doubt this). It seems to me something > more systemic rather than a random bit error - opinions are more than > welcome. > > Here is some info from a python program I wrote to look at the data > (I've left out spans of essentially uninteresting portions showing > similar stuff, but I can get you the whole thing if interested): > > File pos Good Bad Match Good (bin) Bad (bin) Bits same > 0009fff0 d9 d9 Yes 11011001 11011001 8 > 0009fff1 05 05 Yes 00000101 00000101 8 > 0009fff2 c1 c1 Yes 11000001 11000001 8 > 0009fff3 81 81 Yes 10000001 10000001 8 > 0009fff4 5f 5f Yes 01011111 01011111 8 > 0009fff5 66 66 Yes 01100110 01100110 8 > 0009fff6 5e 5e Yes 01011110 01011110 8 > 0009fff7 a1 a1 Yes 10100001 10100001 8 > 0009fff8 ca ca Yes 11001010 11001010 8 > 0009fff9 9d 9d Yes 10011101 10011101 8 > 0009fffa 00 00 Yes 00000000 00000000 8 > 0009fffb 90 90 Yes 10010000 10010000 8 > 0009fffc 32 32 Yes 00110010 00110010 8 > 0009fffd 62 62 Yes 01100010 01100010 8 > 0009fffe a8 a8 Yes 10101000 10101000 8 > 0009ffff b2 b2 Yes 10110010 10110010 8 > --- Start of bad block --- > 000a0000 d1 24 No 11010001 00100100 2 > 000a0001 6b 7b No 01101011 01111011 7 > 000a0002 d1 31 No 11010001 00110001 5 > 000a0003 56 33 No 01010110 00110011 4 > 000a0004 44 38 No 01000100 00111000 3 > 000a0005 c3 41 No 11000011 01000001 6 > 000a0006 df 46 No 11011111 01000110 4 > 000a0007 07 45 No 00000111 01000101 6 > 000a0008 4c 7b No 01001100 01111011 3 > 000a0009 a0 40 No 10100000 01000000 5 > 000a000a 54 0a No 01010100 00001010 3 > 000a000b 35 40 No 00110101 01000000 3 > 000a000c 88 24 No 10001000 00100100 4 > 000a000d 38 24 No 00111000 00100100 5 > 000a000e f5 7d No 11110101 01111101 6 > 000a000f 28 31 No 00101000 00110001 5 > . > . > . > 000af6c1 d3 33 No 11010011 00110011 5 > 000af6c2 97 39 No 10010111 00111001 3 > 000af6c3 a5 32 No 10100101 00110010 3 > 000af6c4 6a 41 No 01101010 01000001 4 > 000af6c5 16 39 No 00010110 00111001 3 > 000af6c6 f2 7d No 11110010 01111101 3 > 000af6c7 21 40 No 00100001 01000000 5 > 000af6c8 52 0a No 01010010 00001010 5 > 000af6c9 00 00 Yes 00000000 00000000 8 > 000af6ca 2c 00 No 00101100 00000000 5 > 000af6cb 42 00 No 01000010 00000000 6 > 000af6cc 31 00 No 00110001 00000000 5 > 000af6cd a1 00 No 10100001 00000000 5 > 000af6ce d1 00 No 11010001 00000000 4 > 000af6cf 90 00 No 10010000 00000000 6 > 000af6d0 9c 00 No 10011100 00000000 4 > . > . > . > 000afff8 26 00 No 00100110 00000000 5 > 000afff9 8c 00 No 10001100 00000000 5 > 000afffa a8 00 No 10101000 00000000 5 > 000afffb 0c 00 No 00001100 00000000 6 > 000afffc f1 00 No 11110001 00000000 3 > 000afffd 93 00 No 10010011 00000000 4 > 000afffe 2c 00 No 00101100 00000000 5 > 000affff 2e 00 No 00101110 00000000 4 > --- End of bad block --- > 000b0000 62 62 Yes 01100010 01100010 8 > 000b0001 56 56 Yes 01010110 01010110 8 > 000b0002 91 91 Yes 10010001 10010001 8 > 000b0003 04 04 Yes 00000100 00000100 8 > 000b0004 01 01 Yes 00000001 00000001 8 > 000b0005 2d 2d Yes 00101101 00101101 8 > 000b0006 0e 0e Yes 00001110 00001110 8 > 000b0007 89 89 Yes 10001001 10001001 8 > 000b0008 8a 8a Yes 10001010 10001010 8 > 000b0009 ad ad Yes 10101101 10101101 8 > 000b000a 4e 4e Yes 01001110 01001110 8 > 000b000b a3 a3 Yes 10100011 10100011 8 > 000b000c 13 13 Yes 00010011 00010011 8 > 000b000d 4d 4d Yes 01001101 01001101 8 > 000b000e 07 07 Yes 00000111 00000111 8 > 000b000f 66 66 Yes 01100110 01100110 8 > . > . > . A wild guess: bytes all with the top bit zero, plus I see occasional 0x0a bytes in there - it looks like that 1/2 block might have gotten overwritten with some ASCII text. Don't ask me how though... (but if it did, I am afraid I would suspect a bug in ZFS :-( ) Gary From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 23:29:37 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A230B16A419 for ; Fri, 8 Feb 2008 23:29:37 +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 5E94513C448 for ; Fri, 8 Feb 2008 23:29:37 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.2/8.14.2) id m18NTPfx095860; Fri, 8 Feb 2008 17:29:25 -0600 (CST) (envelope-from dan) Date: Fri, 8 Feb 2008 17:29:24 -0600 From: Dan Nelson To: Joe Peterson Message-ID: <20080208232923.GD85696@dan.emsphone.com> References: <47ACD7D4.5050905@skyrush.com> <47ACDE82.1050100@skyrush.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47ACDE82.1050100@skyrush.com> X-OS: FreeBSD 7.0-PRERELEASE User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-fs@freebsd.org, Mark Day , freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 08 Feb 2008 23:29:37 -0000 In the last episode (Feb 08), Joe Peterson said: > Mark Day wrote: > > Based on the subset of data you posted, the bad data looks like > > ASCII text. The bad data from offset a0000 to a000f is: > > > > ${138AFE{@ > > @$$}1 > > > > The bad data from offset af6c1 to af6c8 is: > > > > 392A9}@ > > > > I don't recognize the content beyond that, but I'd guess that > > somehow the contents of some other file managed to overwrite that > > portion of the bad file. As for how that happened, I don't know. > > But if someone recognizes where the bad content came from, that > > might be a clue. > > Good eye! Yes, it indeed does appear to be ASCII. I *thought* > something in the repetition when I originally did an od -a looked > interesting. > > I dumped the whole bad section as a string, and here's (partly) what I get: > > @$${138B8B{@ > <(21470=Thu Jan 24 23:20:58 2008)> > [117:^80(^91^21470)] > @$$}138B8B}@ ... > @$${138C18{@ > <(21472=1201242069)>[-2:^80(^82^85)(^83^1B5)(^84=b)(^85=1)(^86=0)(^87=0) > (^88=0)(^89^2146C)(^8A=)(^8B=40)(^8C=2e)(^8D^84)(^8E=0)(^90^21472) > (^91^21460)] > @$$}138C18}@ > > and more of the same. Note the date string. There are several like > that. Anyone recognize this text format? It's a Mork database from the Mozilla project: http://developer.mozilla.org/en/docs/Mork_Structure#Rows -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 23:36:12 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D646916A418; Fri, 8 Feb 2008 23:36:12 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from dd15624.kasserver.com (dd15624.kasserver.com [85.13.136.215]) by mx1.freebsd.org (Postfix) with ESMTP id 9556213C448; Fri, 8 Feb 2008 23:36:12 +0000 (UTC) (envelope-from freebsd@chillt.de) Received: from hundertwasser.cs.tcd.ie (dslb-084-060-126-218.pools.arcor-ip.net [84.60.126.218]) by dd15624.kasserver.com (Postfix) with ESMTP id 8BED9181DEC20; Sat, 9 Feb 2008 00:09:05 +0100 (CET) Message-ID: <47ACE12A.6010205@chillt.de> Date: Fri, 08 Feb 2008 23:09:30 +0000 From: Bartosz Fabianowski User-Agent: Thunderbird 2.0.0.9 (X11/20080124) MIME-Version: 1.0 To: Joe Peterson References: <47ACD7D4.5050905@skyrush.com> <47ACDE82.1050100@skyrush.com> In-Reply-To: <47ACDE82.1050100@skyrush.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Mark Day , freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 08 Feb 2008 23:36:12 -0000 I'd say that's the mork database format [1,2], as used by Mozilla products, for example in the Firefox history.dat file. - Bartosz [1] http://www.mozilla.org/mailnews/arch/mork/primer.txt [2] http://www.jwz.org/hacks/mork.pl From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 23:54:34 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 772D616A418; Fri, 8 Feb 2008 23:54:34 +0000 (UTC) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4828E13C467; Fri, 8 Feb 2008 23:54:34 +0000 (UTC) (envelope-from cdillon@wolves.k12.mo.us) Received: from localhost (localhost [127.0.0.1]) by mail.wolves.k12.mo.us (Postfix) with ESMTP id 1558FB841; Fri, 8 Feb 2008 17:35:19 -0600 (CST) X-Virus-Scanned: amavisd-new at wolves.k12.mo.us Received: from mail.wolves.k12.mo.us ([127.0.0.1]) by localhost (mail.wolves.k12.mo.us [127.0.0.1]) (amavisd-new, port 10024) with LMTP id n-2JjJY+zU0K; Fri, 8 Feb 2008 17:35:18 -0600 (CST) Received: from wolves.k12.mo.us (localhost [127.0.0.1]) by mail.wolves.k12.mo.us (Postfix) with ESMTP id E20D8B820; Fri, 8 Feb 2008 17:35:17 -0600 (CST) Received: from rstech21.int.wolves.k12.mo.us (rstech21.int.wolves.k12.mo.us [10.1.3.201]) by www.wolves.k12.mo.us (Horde MIME library) with HTTP; Fri, 08 Feb 2008 17:35:17 -0600 Message-ID: <20080208173517.rdtobnxqg4g004c4@www.wolves.k12.mo.us> Date: Fri, 08 Feb 2008 17:35:17 -0600 From: Chris Dillon To: Joe Peterson References: <47ACD7D4.5050905@skyrush.com> <47ACDE82.1050100@skyrush.com> In-Reply-To: <47ACDE82.1050100@skyrush.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.5) / FreeBSD-6.2 Cc: freebsd-fs@freebsd.org, Mark Day , freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 08 Feb 2008 23:54:34 -0000 Quoting Joe Peterson : > I dumped the whole bad section as a string, and here's (partly) what I get: [...edited for brevity...] > @$${138B8B{@ > <(21470=Thu Jan 24 23:20:58 2008)> > [117:^80(^91^21470)] > @$$}138B8B}@ > > @$${138C18{@ > <(21472=1201242069)>[-2:^80(^82^85)(^83^1B5)(^84=b)(^85=1)(^86=0)(^87=0) > (^88=0)(^89^2146C)(^8A=)(^8B=40)(^8C=2e)(^8D^84)(^8E=0)(^90^21472) > (^91^21460)] > @$$}138C18}@ > > @$${138C19{@ > <(21473=a72f78)>[2:^80(^89^21473)] > @$$}138C19}@ > > @$${138C1A{@ > @$$}138C1A}@ > > and more of the same. Note the date string. There are several like > that. Anyone recognize this text format? That is a chunk of a Mozilla Mork-format database. Perhaps the Firefox URL history or address book from Thunderbird. -- Chris Dillon - NetEng/SysAdm Reeds Spring R-IV School District Technology Department 175 Elementary Rd. Reeds Spring, MO 65737 Voice: 417-272-8266 Fax: 417-272-0015 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 9 00:07:46 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5710416A417 for ; Sat, 9 Feb 2008 00:07:46 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id D7A6213C442 for ; Sat, 9 Feb 2008 00:07:45 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so2940654rvb.43 for ; Fri, 08 Feb 2008 16:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=oym9/9sbwd9BQvtphU65tnUC933mG94P1fTg61fiLEw=; b=uByqdFXl6As8CBNkVzEMYPcfhD/+Ik9aDU0sQoXKxwVnuMEfL3efqcKG2cnYCNI/DRszFD2cBzA+tXMIxDcZmJbdrJhzvF/ETQFtFPnlJHSH/Z4dPKFOnxJaYuEGsDhkbhIXml6iYKI+n/5K+CGs5yI9wQsYqGFvCxEmv1eZMgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=N6jxoKWELy2Nrw8CurvS2Pn7KXzxMDweokq4ZjjhlLsULLBuKcc7dosYiiYFHoMy+P3PY7LEpp/4uWdkWkwBF+RVirWQiborqwGByi4J2uo2ySzRGwpRcfWjvUw5+wadDalpA7hVlW+fu+h+TKlsU85aXoGXbyjLV3vu86E6vsw= Received: by 10.141.163.12 with SMTP id q12mr8909223rvo.260.1202514004738; Fri, 08 Feb 2008 15:40:04 -0800 (PST) Received: by 10.140.252.21 with HTTP; Fri, 8 Feb 2008 15:40:04 -0800 (PST) Message-ID: <9bbcef730802081540t5a9b8649we037bbcca2e8b53a@mail.gmail.com> Date: Sat, 9 Feb 2008 00:40:04 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Ivan Voras" , freebsd-stable@freebsd.org In-Reply-To: <20080208221941.GD1479@roadrunner.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080208221941.GD1479@roadrunner.spoerlein.net> X-Google-Sender-Auth: 787bf001e4f041a7 Cc: Subject: Re: finstall alpha3 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, 09 Feb 2008 00:07:46 -0000 On 08/02/2008, Ulrich Spoerlein wrote: > On Wed, 06.02.2008 at 11:48:22 +0100, Ivan Voras wrote: > > On the other hand, here's what it *can* do currently: > > > > - it's a "live" CD environment, completely like an already installed > > FreeBSD system, only running from a read-only media (e.g. it's usable as > > a "FixIt" system) > > This is great, and I think it's the way to go. Since I had to repair my > system the last days with a 'FixIt' CD, I think this mode could get even > more improvement. It would be nice, if there where some additional > system repair tools available on this CD (license permitting, of > course). You'd just have to make sure to still install a clean FreeBSD. > This could be accomplished by using unionfs for the 'enhanced fixit > overlay' or something like that. Feel welcome to suggest additional tools to include. I'm aiming at a 700 MB image and I'm currently only near 450 MB :) (I won't include multimedia software until hardware detection is implemented). Since I'm already installing a bunch of GPL software in the GUI/desktop environment, a few more won't make a difference. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 9 00:15:46 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9387716A418; Sat, 9 Feb 2008 00:15:46 +0000 (UTC) (envelope-from joe@skyrush.com) Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by mx1.freebsd.org (Postfix) with ESMTP id 61BFB13C467; Sat, 9 Feb 2008 00:15:46 +0000 (UTC) (envelope-from joe@skyrush.com) Received: from [10.0.3.98] (mail.boulder.swri.edu [65.241.78.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id 8FB708F42A; Fri, 8 Feb 2008 17:15:45 -0700 (MST) Message-ID: <47ACF0AE.3040802@skyrush.com> Date: Fri, 08 Feb 2008 17:15:42 -0700 From: Joe Peterson User-Agent: Thunderbird 2.0.0.9 (X11/20071119) MIME-Version: 1.0 To: Chris Dillon References: <47ACD7D4.5050905@skyrush.com> <47ACDE82.1050100@skyrush.com> <20080208173517.rdtobnxqg4g004c4@www.wolves.k12.mo.us> In-Reply-To: <20080208173517.rdtobnxqg4g004c4@www.wolves.k12.mo.us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 09 Feb 2008 00:15:46 -0000 Chris Dillon wrote: > That is a chunk of a Mozilla Mork-format database. Perhaps the > Firefox URL history or address book from Thunderbird. Interesting (thanks to all who recognized Mork). I do use Firefox and Thunderbird, so it's feasible, but how the heck would a piece of one of those files find its way into 1/2 of a ZFS block in one of my mp3 files? I wonder if it could have been done on write when the file was copied to the ZFS pool (maybe some write-caching issue?), but I thought ZFS would have verified the block after write. It seems unlikely that it would get changed later - I never rewrote that file after the original copy... -Joe From owner-freebsd-stable@FreeBSD.ORG Sat Feb 9 00:36:58 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3892716A419 for ; Sat, 9 Feb 2008 00:36:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outK.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4F013C448 for ; Sat, 9 Feb 2008 00:36:58 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 08 Feb 2008 16:26:27 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id DAC1E127152; Fri, 8 Feb 2008 16:26:26 -0800 (PST) Message-ID: <47ACF338.3020802@elischer.org> Date: Fri, 08 Feb 2008 16:26:32 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Joe Peterson References: <47ACD7D4.5050905@skyrush.com> <47ACDE82.1050100@skyrush.com> <20080208173517.rdtobnxqg4g004c4@www.wolves.k12.mo.us> <47ACF0AE.3040802@skyrush.com> In-Reply-To: <47ACF0AE.3040802@skyrush.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 09 Feb 2008 00:36:58 -0000 Joe Peterson wrote: > Chris Dillon wrote: >> That is a chunk of a Mozilla Mork-format database. Perhaps the >> Firefox URL history or address book from Thunderbird. > > Interesting (thanks to all who recognized Mork). I do use Firefox and > Thunderbird, so it's feasible, but how the heck would a piece of one of > those files find its way into 1/2 of a ZFS block in one of my mp3 files? > I wonder if it could have been done on write when the file was copied > to the ZFS pool (maybe some write-caching issue?), but I thought ZFS > would have verified the block after write. It seems unlikely that it > would g it could be an old file.. what kind of disks? I had a scenario where 3ware controllers were just failing to write to a drive in the array, so old data showed through. it was possible by looking to see where the boundary between good and bad was, to identify the culprit.. the filesystem and the partitions and the raids all were on different alignments so teh only part of the system that had a boundary that aligned with the bad data was the physical stripes laid down by the controller. It was 64k stripes and 64k data missing, exactly on stripe boundaries. Due to the fact that FreeBSD had partitioned the drive staring at 63 blocks in, nothing else aligned with the problem. > -Joe > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Feb 9 01:14:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 647A516A417 for ; Sat, 9 Feb 2008 01:14:11 +0000 (UTC) (envelope-from mattboll@penia.org) Received: from penia.org (penia.org [82.228.156.113]) by mx1.freebsd.org (Postfix) with ESMTP id 5604B13C4CC for ; Sat, 9 Feb 2008 01:14:10 +0000 (UTC) (envelope-from mattboll@penia.org) Received: from [192.168.0.3] (unknown [192.168.0.3]) by penia.org (Postfix) with ESMTP id 936136528 for ; Sat, 9 Feb 2008 02:14:07 +0100 (CET) From: Matthieu Bollot To: freebsd-stable In-Reply-To: <20080207203657.45d87889@nexus6.bluepex.com> References: <1202334536.6146.10.camel@sarah.penia.org> <20080207203657.45d87889@nexus6.bluepex.com> Date: Sat, 09 Feb 2008 01:14:20 +0100 Message-Id: <1202516060.1296.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 FreeBSD GNOME Team Port Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: synaptics 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, 09 Feb 2008 01:14:11 -0000 Le Jeudi 07 février 2008 à 20:36 -0200, Otávio Fernandes a écrit : > On Wed, 06 Feb 2008 22:48:56 +0100 > Matthieu Bollot wrote: > > > Hi, > > > > I've recently installed FreeBSD 6.3, and I've got a problem with > > synaptics. > > I've installed it, followed the pkg-message : > > hw.psm.synaptics_support=1 > > > > It works, dmesg gives : > > psm0: irq 12 on atkbdc0 > > psm0: [GIANT-LOCKED] > > psm0: model Synaptics Touchpad, device ID 0 > > > > moused_enable="NO" > > ps shows me that moused doesn't run. > > > > xorg.conf : > > InputDevice "Synaptics_Touchpad" "CorePointer" > > ... > > Section "InputDevice" > > Identifier "Synaptics_Touchpad" > > Driver "synaptics" > > Option "Device" "/dev/psm0" > > Option "Protocol" "psm" > > ... > > > > And here is a part of Xorg.log : > > (WW) : No Device specified, looking for one... > > (II) : Setting Device option to "/dev/psm0" > > (--) : Device: "/dev/psm0" > > (==) : Protocol: "Auto" > > ... > > Synaptics DeviceInit called > > SynapticsCtrl called. > > (II) : SetupAuto: hw.iftype is 3, hw.model is 13 > > (II) : SetupAuto: protocol is SysMouse > > (WW) fcntl(15, O_ASYNC): Inappropriate ioctl for device > > Synaptics DeviceOn called > > (EE) xf86OpenSerial: Cannot open device /dev/psm0 > > Device busy. > > (WW) Synaptics_Touchpad: cannot open input device > > couldn't enable device 3 > > > > Protocol isn't psm, why ? Can I force it ? > > /dev/psm0 isn't used or it is used by Xorg (I saw it with fstat) > > > > any idea ? I didn't had this problem with 6.2 but may be I wasn't up > > to date with xorg. > > > > _______________________________________________ > > 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" > > Hello Matthieu, > > I have another sugestion to your synaptics: > > http://people.freebsd.org/~dumbbell/synaptics/ > > This patch make synaptics work with moused and, for me, it's awesome ! > The only matter is to emulate middle button you need to tap with 3 > fingers. > > best regards, > Hi all, Dominic : My xorg.conf is fine, it worked previously on the same box (just versions have changed) and sadly, virtual scrolling doesn't works with moused. JoaoBR : I didn't understand what I should enable in rc.conf, what should be sysmouse ? I don't have any daemon with this name but may be I misunderstood. I tried using my touchpad as a psm mouse but I can't find a way to have synaptics option (scrolling) Otávio : I'll try soon, the patch still applies (it is 1 year old !) it's time to buildkernel now ^^ I'll continue to search, thanks all. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 9 03:09:48 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E18516A417; Sat, 9 Feb 2008 03:09:48 +0000 (UTC) (envelope-from joe@skyrush.com) Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by mx1.freebsd.org (Postfix) with ESMTP id 1151913C47E; Sat, 9 Feb 2008 03:09:47 +0000 (UTC) (envelope-from joe@skyrush.com) Received: from [67.40.138.82] (crater.wildlava.net [67.40.138.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id 033158F42A; Fri, 8 Feb 2008 20:09:47 -0700 (MST) Message-ID: <47AD1979.8020704@skyrush.com> Date: Fri, 08 Feb 2008 20:09:45 -0700 From: Joe Peterson User-Agent: Thunderbird 2.0.0.9 (X11/20071127) MIME-Version: 1.0 To: Julian Elischer References: <47ACD7D4.5050905@skyrush.com> <47ACDE82.1050100@skyrush.com> <20080208173517.rdtobnxqg4g004c4@www.wolves.k12.mo.us> <47ACF0AE.3040802@skyrush.com> <47ACF338.3020802@elischer.org> In-Reply-To: <47ACF338.3020802@elischer.org> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 09 Feb 2008 03:09:48 -0000 Julian Elischer wrote: > it could be an old file.. > what kind of disks? It's a Seagate ST3500630A parallel ATA drive. > I had a scenario where 3ware controllers were just failing to write to > a drive in the array, so old data showed through. I have an Intel ICH4 controller - nothing unusual. > the filesystem and the partitions and the raids all were on different > alignments so teh only part of the system that had a boundary that > aligned with the bad data was the physical stripes laid down by the > controller. It was 64k stripes and 64k data missing, exactly on > stripe boundaries. Due to the fact that FreeBSD had partitioned the > drive staring at 63 blocks in, nothing else aligned with the problem. Hmm, well this is a straight-forward disk situation - never used RAID on this drive. Give what is happening, I wonder the changes of it being HW, OS, or a filesystem issue. -Joe From owner-freebsd-stable@FreeBSD.ORG Sat Feb 9 04:22:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4748B16A417 for ; Sat, 9 Feb 2008 04:22:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outV.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id 30BB813C455 for ; Sat, 9 Feb 2008 04:22:08 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 08 Feb 2008 20:22:08 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id B145A12714B; Fri, 8 Feb 2008 20:22:07 -0800 (PST) Message-ID: <47AD2A75.8010908@elischer.org> Date: Fri, 08 Feb 2008 20:22:13 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Joe Peterson References: <47ACD7D4.5050905@skyrush.com> <47ACDE82.1050100@skyrush.com> <20080208173517.rdtobnxqg4g004c4@www.wolves.k12.mo.us> <47ACF0AE.3040802@skyrush.com> <47ACF338.3020802@elischer.org> <47AD1979.8020704@skyrush.com> In-Reply-To: <47AD1979.8020704@skyrush.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error 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, 09 Feb 2008 04:22:09 -0000 Joe Peterson wrote: > Julian Elischer wrote: >> it could be an old file.. >> what kind of disks? > > It's a Seagate ST3500630A parallel ATA drive. > >> I had a scenario where 3ware controllers were just failing to write to >> a drive in the array, so old data showed through. > > I have an Intel ICH4 controller - nothing unusual. > >> the filesystem and the partitions and the raids all were on different >> alignments so teh only part of the system that had a boundary that >> aligned with the bad data was the physical stripes laid down by the >> controller. It was 64k stripes and 64k data missing, exactly on >> stripe boundaries. Due to the fact that FreeBSD had partitioned the >> drive staring at 63 blocks in, nothing else aligned with the problem. > > Hmm, well this is a straight-forward disk situation - never used RAID on > this drive. Give what is happening, I wonder the changes of it being > HW, OS, or a filesystem issue. > > -Joe still, see whether the 64k lines up with the drive or with the filesystem (if the filesystem is not on an exact 64k boundary of the drive). From owner-freebsd-stable@FreeBSD.ORG Sat Feb 9 17:35:07 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11AC516A419 for ; Sat, 9 Feb 2008 17:35:07 +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 8D5B213C468 for ; Sat, 9 Feb 2008 17:35:06 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JNtbS-0007u6-Qd for freebsd-stable@freebsd.org; Sat, 09 Feb 2008 17:35:02 +0000 Received: from www.creo.hu ([217.113.62.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Feb 2008 17:35:02 +0000 Received: from csaba-ml by www.creo.hu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Feb 2008 17:35:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Csaba Henk Date: Sat, 9 Feb 2008 17:23:58 +0000 (UTC) Lines: 64 Message-ID: References: <47A7D8AC.7030104@micom.mng.net> <5f67a8c40802042229y5f407e3bo55f32e95c7997848@mail.gmail.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: www.creo.hu User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: fusefs-ntfs makes fatal trap/page fault in FreeBSD-7.0 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, 09 Feb 2008 17:35:07 -0000 Hi, On 2008-02-05, Zaphod Beeblebrox wrote: > I havn't seen this specific problem, but on my Dell XPS 1730 > (core-2-duo-extreme) The NTFS-3g mounts doen't seem to shutdown properly. > That is: many of the writes are uncommitted and the filesystem needs a check > and often information is lost ... unless I unmount the filesystems before > shutdown. Recently we added a feature called "synchronous unmount" which *might* improve the situation regarding shutdown. Probably soon there will be an update of fusefs-kmod which will include it. Anyway, here are the instructions how can you try it immediately: 1) Reinstall fusefs-libs with the following patch applied: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% diff -rup ../../work-orig/fuse-2.7.2/lib/mount_bsd.c ./lib/mount_bsd.c --- ../../work-orig/fuse-2.7.2/lib/mount_bsd.c Wed Dec 12 15:33:35 2007 +++ ./lib/mount_bsd.c Sat Feb 9 17:53:25 2008 @@ -228,7 +228,7 @@ void fuse_kern_unmount(const char *mount if (*ep != '\0') return; - asprintf(&umount_cmd, "/sbin/umount " _PATH_DEV "%s", dev); + asprintf(&umount_cmd, "/sbin/umount -f " _PATH_DEV "%s", dev); system(umount_cmd); } %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 2) Get the latest fuse4bsd code from the Mercurial repo by hg pull http://mercurial.creo.hu/repos/fuse4bsd-hg/ or as a direct tarball fetch: fetch http://mercurial.creo.hu/repos/fuse4bsd-hg/index.cgi/archive/tip.tar.gz Untar and make(1) it. Ignore the patches which are part of the fusefs-kmod port but you will need to do a cp /usr/local/include/fuse/fuse_kernel.h fuse_module/ before compilation. If you have a self-compiled kernel, you are suggested to use this make option: -DKERNCONF= 3) Load the module with "kldload fuse_module/fuse.ko". You can as well install it to a place within your module path. 4) The sysctl vfs.fuse.sync_unmount controls who is eligible to using the fs with synchronous unmount. Its default value is 1, which mean only the superuser is eligible. You are suggested to enable it for everyone by sysctl vfs.fuse.sync_unmount=2 Now take a look how cleanly does the ntfs-3g shutdown happen. Please report back, I'm eager to know if this technique helps. Regards, Csaba