From owner-freebsd-current Sun Dec 22 1:13:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0509437B401 for ; Sun, 22 Dec 2002 01:13:19 -0800 (PST) Received: from smtp.eos.ocn.ne.jp (eos.ocn.ne.jp [211.6.83.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1381643EDC for ; Sun, 22 Dec 2002 01:13:18 -0800 (PST) (envelope-from hrs@eos.ocn.ne.jp) Received: from mail.allbsd.org (p37089-adsao12honb4-acca.tokyo.ocn.ne.jp [219.161.134.89]) by smtp.eos.ocn.ne.jp (Postfix) with ESMTP id 79D122484 for ; Sun, 22 Dec 2002 18:13:16 +0900 (JST) Received: from localhost (alph.allbsd.org [192.168.0.10]) by mail.allbsd.org (8.12.3/3.7W/DomainMaster) with ESMTP id gBM9C5B2055129 for ; Sun, 22 Dec 2002 18:12:05 +0900 (JST) (envelope-from hrs@eos.ocn.ne.jp) Date: Sun, 22 Dec 2002 18:11:24 +0900 (JST) Message-Id: <20021222.181124.97201542.hrs@eos.ocn.ne.jp> To: current@FreeBSD.org Subject: panic: kmem_map too small From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I had "kmem_map too small" panic on 5.0-CURRENT/i386 as of Dec. 19 2002. It often occurred when the machine was running under heavy system loads (e.g. make -j20 release). |panic: kmem_malloc(4096): kmem_map too small: 275378176 total allocated |cpuid = 2; lapic.id = 01000000 |boot() called on cpu#2 | |syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? |cpuid = 2; lapic.id = 01000000 |boot() called on cpu#2 |Uptime: 13h56m30s |Dumping 3071 MB |ata0: resetting devices .. The machine's kernel is configured with the additional options: SMP and APIC_IO (4 CPUs are detected). The results of backtrace are: |(kgdb) bt |#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232 |#1 0xc02e498a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364 |#2 0xc02e4c47 in panic () at /usr/src/sys/kern/kern_shutdown.c:517 |#3 0xc032b882 in bwrite (bp=0xd5b8f728) at /usr/src/sys/kern/vfs_bio.c:796 |#4 0xc032bf39 in bawrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1085 |#5 0xc0332f2e in cluster_wbuild (vp=0xc9c56258, size=16384, start_lbn=776, | len=4) at /usr/src/sys/kern/vfs_cluster.c:981 |#6 0xc032cf46 in vfs_bio_awrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1626 |#7 0xc043623a in ffs_fsync (ap=0xe785b548) | at /usr/src/sys/ufs/ffs/ffs_vnops.c:258 |#8 0xc0435449 in ffs_sync (mp=0xc9963600, waitfor=2, cred=0xc5436e00, | td=0xc0549d00) at vnode_if.h:612 |#9 0xc0340bab in sync (td=0xc0549d00, uap=0x0) | at /usr/src/sys/kern/vfs_syscalls.c:138 |#10 0xc02e456b in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273 |#11 0xc02e4c47 in panic () at /usr/src/sys/kern/kern_shutdown.c:517 |#12 0xc044c46b in kmem_malloc (map=0xc083207c, size=4096, flags=0) | at /usr/src/sys/vm/vm_kern.c:336 |#13 0xc045cd77 in page_alloc (zone=0xc542aa80, bytes=0, pflag=0x0, wait=0) | at /usr/src/sys/vm/uma_core.c:798 |#14 0xc045ca71 in slab_zalloc (zone=0xc542aa80, wait=0) | at /usr/src/sys/vm/uma_core.c:707 |#15 0xc045dd5e in uma_zone_slab (zone=0xc542aa80, flags=0) | at /usr/src/sys/vm/uma_core.c:1486 |#16 0xc045df84 in uma_zalloc_bucket (zone=0xc542aa80, flags=0) | at /usr/src/sys/vm/uma_core.c:1590 |#17 0xc045dc0f in uma_zalloc_arg (zone=0xc542aa80, udata=0x0, flags=0) | at /usr/src/sys/vm/uma_core.c:1417 |#18 0xc02d8359 in malloc (size=7, type=0xc0553ba0, flags=0) | at /usr/src/sys/kern/kern_malloc.c:182 |#19 0xc032e3aa in allocbuf (bp=0xd5e545e0, size=2048) | at /usr/src/sys/kern/vfs_bio.c:2635 |#20 0xc032e16e in getblk (vp=0xcaaa2960, blkno=0, size=2048, slpflag=0, | slptimeo=0) at /usr/src/sys/kern/vfs_bio.c:2526 |#21 0xc0420b59 in ffs_balloc_ufs2 (vp=0xcaaa2960, startoffset=0, size=512, | cred=0xca0a6400, flags=65536, bpp=0xe785b9e0) | at /usr/src/sys/ufs/ffs/ffs_balloc.c:643 |#22 0xc044313a in ufs_mkdir (ap=0xe785bbac) | at /usr/src/sys/ufs/ufs/ufs_vnops.c:1580 |#23 0xc0444b48 in ufs_vnoperate (ap=0x0) | at /usr/src/sys/ufs/ufs/ufs_vnops.c:2796 |#24 0xc0345cf9 in kern_mkdir (td=0xcb907e00, | path=0xe785bca8 "$BT<(B\205$Bgi(B\2160$B@\(B020$B[LS"(B, segflg=3226816840, mode=448) | at vnode_if.h:757 |#25 0xc0345a79 in mkdir (td=0x0, uap=0x0) | at /usr/src/sys/kern/vfs_syscalls.c:2879 |#26 0xc049fe5c in syscall (frame= | {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 134618240, | tf_ebp = -1077937912, tf_isp = -410665612, tf_ebx = 134539164, | tf_edx = 134536188, tf_ecx = 672330072, tf_eax = 136, | tf_trapno = -1077938044, tf_err = 2, tf_eip = 671866435, tf_cs = 31, | tf_eflags = 514, tf_esp = -1077938052, tf_ss = 47}) | at /usr/src/sys/i386/i386/trap.c:1033 |#27 0xc0487dcd in Xint0x80_syscall () at {standard input}:141 |---Can't read userspace from dump, or kernel process--- -- | Hiroki SATO To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 3:38:38 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A466337B401; Sun, 22 Dec 2002 03:38:26 -0800 (PST) Received: from smtp.kolej.mff.cuni.cz (smtp.kolej.mff.cuni.cz [195.113.25.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8AD743ED8; Sun, 22 Dec 2002 03:38:24 -0800 (PST) (envelope-from dan@obluda.cz) X-Envelope-From: dan@obluda.cz Received: from obluda.cz (dan.kolej.mff.cuni.cz [195.113.21.110]) by smtp.kolej.mff.cuni.cz (8.11.6/8.11.6) with ESMTP id gBMBcKr32369; Sun, 22 Dec 2002 12:38:20 +0100 (CET) (envelope-from dan@obluda.cz) Message-ID: <3E05A429.7080506@obluda.cz> Date: Sun, 22 Dec 2002 12:38:17 +0100 From: Dan Lukes User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2b) Gecko/20021106 X-Accept-Language: cs MIME-Version: 1.0 To: Hiten Pandya Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, dcs@newsguy.com Subject: Re: VLAN v.s. NIC with VLAN hardware support bug. References: <3E038A1A.6070203@obluda.cz> <3E03A86C.6D15F650@newsguy.com> <3E03C706.5060508@obluda.cz> <20021221233424.GA23657@unixdaemons.com> In-Reply-To: <3E038A1A.6070203@obluda.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hiten Pandya wrote: > On Sat, Dec 21, 2002 at 02:42:30AM +0100, Dan Lukes wrote the words in > effect of: > > Dan, I believe you submitted a PR about this [1], what does patch try to > solve, regarding VLAN hardware support? > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46405 Hi. May be, I'm doesn't understand fully what you are asked for - my english isn't as good as should be. The problem: NIC with hardware VLAN support pass whole TAG to vlan_input(_tag). The TAG has the following structure: TAG & 0x8000 -> CFI (TAG & 0x7000)>>13 -> priority TAG & 0x0FFF -> VLAN ID The vlan_input(_tag) doesn't extract the VLAN ID from tag, it tried match the whole tag to configured VLAN's. It work - unless CFI or an priority bit has nonzero value. An example: you have configured VLAN 256 on your FreeBSD. The arrived packed has TAG 0x0100 (=256). For this packet it works, as TAG matched configured VLAN. Lets another packet has TAG 0x4100 (=16640). It's dropped because there are no configured vlan with ID 16640 - but should not be dropped, as it IS packed for VLAN 256 with priority 4. In short - vlan_input(_tag) doesn't extract the correct bits from TAG, so it drop packets that shouldn't be dropped. It's the bug fixed by my patches. I tested it on 4.7. The patch for CURRENT isn't tested, but it's simple to analyse that there are the same problem. It's the sufficient answer to your question ? Please note (it's mentioned in my PR also), the vlan code doesn't correctly handle the VLAN ID of "zero" which has special meaning . My patches doesn't solve it. Dan -- Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206 root of FIONet, KolejNET, webmaster of www.freebsd.cz AKA: dan@obluda.cz, dan@freebsd.cz, dan@kolej.mff.cuni.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 4:57:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59D8A37B401 for ; Sun, 22 Dec 2002 04:57:17 -0800 (PST) Received: from quantumnet.de (pD9E4963B.dip.t-dialin.net [217.228.150.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id E651043EE5 for ; Sun, 22 Dec 2002 04:57:15 -0800 (PST) (envelope-from gernot@quantumnet.de) Received: from homer.quantumnet.de (localhost.quantumnet.de [127.0.0.1]) by quantumnet.de (8.12.6/8.12.6) with ESMTP id gBMCwjRv034673 for ; Sun, 22 Dec 2002 13:58:45 +0100 (CET) (envelope-from gernot.weber) Received: from localhost (gernot@localhost) by homer.quantumnet.de (8.12.6/8.12.6/Submit) with ESMTP id gBMCwiTc034670 for ; Sun, 22 Dec 2002 13:58:45 +0100 (CET) Date: Sun, 22 Dec 2002 13:58:44 +0100 (CET) From: "Gernot A. Weber" To: current@freebsd.org Subject: cvsup to RC2 Message-ID: <20021222135430.A34632-100000@homer.quantumnet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, it's my first upgrade of a FreeBSD box. So I copied stable-supfile from /usr/share/examples/cvsup to /etc/cvsup and changed the following line: *default release=cvs tag=5.0-RC2 When I start cvsup /etc/cvsup it wants to delete all src files. Now I'm not aware, whether it just wants to delete it and than get the new source or it just doesn't find my changed tag. Did I get something wrong or is this the right way to upgrade my box? Thanks, Gernot -- Gernot A. Weber http://www.tux-web.de gernot@quantumnet.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 5: 9: 4 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95BA937B401 for ; Sun, 22 Dec 2002 05:09:03 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2237943ED8 for ; Sun, 22 Dec 2002 05:09:02 -0800 (PST) (envelope-from csharp@gmx.net) Received: (qmail 15354 invoked by uid 0); 22 Dec 2002 13:08:55 -0000 Received: from pd95527db.dip.t-dialin.net (HELO dagon.cthulhu.net) (217.85.39.219) by mail.gmx.net (mp022-rz3) with SMTP; 22 Dec 2002 13:08:55 -0000 Received: from mephisto by dagon.cthulhu.net with local (Exim 4.10) id 18Q5tu-000856-00 for current@freebsd.org; Sun, 22 Dec 2002 14:12:14 +0100 Date: Sun, 22 Dec 2002 14:12:14 +0100 From: Christopher Sharp To: current@freebsd.org Subject: Re: cvsup to RC2 Message-ID: <20021222131214.GC17517@gmx.net> Mail-Followup-To: current@freebsd.org References: <20021222135430.A34632-100000@homer.quantumnet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021222135430.A34632-100000@homer.quantumnet.de> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On (22/12/02 13:58), Gernot A. Weber wrote: > it's my first upgrade of a FreeBSD box. So I copied stable-supfile from > /usr/share/examples/cvsup to /etc/cvsup and changed the following line: > > *default release=cvs tag=5.0-RC2 > > When I start cvsup /etc/cvsup it wants to delete all src files. Now I'm > not aware, whether it just wants to delete it and than get the new source > or it just doesn't find my changed tag. Did I get something wrong or is > this the right way to upgrade my box? Change the tag to RELENG_5_0 to get the sources, or if you want just use "." to get the -current sources they don't differ much. - Christopher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 6:18:18 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 028D437B401 for ; Sun, 22 Dec 2002 06:18:17 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C7CA243EDE for ; Sun, 22 Dec 2002 06:18:15 -0800 (PST) (envelope-from ralf_schumacher@gmx.net) Received: (qmail 28566 invoked by uid 0); 22 Dec 2002 14:18:14 -0000 Received: from p508924b6.dip.t-dialin.net (HELO atlas.solaris) (80.137.36.182) by mail.gmx.net (mp015-rz3) with SMTP; 22 Dec 2002 14:18:14 -0000 Received: from gmx.net (wvcharon.solaris [192.168.101.50]) by atlas.solaris (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 5C5BF1A682 for ; Sun, 22 Dec 2002 15:17:36 +0100 (CET) Message-ID: <3E05C97F.4080907@gmx.net> Date: Sun, 22 Dec 2002 15:17:35 +0100 From: Ralf Schumacher User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Bootproblems of 5.0 DP2,RC1,RC2 on i845PE based Board Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! I have problems to boot the CD-based Kernel on the images for FreeBSD 5.0 DP2,RC1 and RC2. As ACPI is mostly the problem i have tried it with "unset acpi_load" but to no avail. It seems as if the Kernel probes the hardware and then there comes a kernel panic. 4.7 runs smoothly and without a hitch, besides that i have to boot windows first after a power-down to get DMA for my IDE-Drives. The Hardware is a ABIT BE7-RAID (i845PE-Based) with a P4 2,8 GHz and 512MB. The CD-ROM Drive is a Pioneer DVD-Drive as master on the second controller. The output says: Fatal trap 1: privileged instruction fault while in vm86 mode instruction point = 0xcc00:0xe3 stack pointer = 0x0:0xff8 frame pointer = 0x0:0x0 code segment = base 0x0, limit 0x0, type 0x0 DPL 0, pres 0, def32 0, gran 0 processor eflags = interrupt enabled, resume, vm86, IOPL = 0 current process = 0 (swapper) trap number = 1 panic: privileged instruction fault An tr on RC1 says (The only with the debugger built in): (null)(0,0,0,0,0) at 0xe3 Have someone an idea about this problem? Best Regards Ralf Schumacher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 7:44:37 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C85D537B401 for ; Sun, 22 Dec 2002 07:44:35 -0800 (PST) Received: from jangada.softinfo.com.br (BA000200.user.veloxzone.com.br [200.164.0.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9541B43EDC for ; Sun, 22 Dec 2002 07:44:34 -0800 (PST) (envelope-from vitor@softinfo.com.br) Received: from acaraje (acaraje.softinfo.com.br [192.168.10.2]) (authenticated bits=0) by jangada.softinfo.com.br (8.12.6/8.12.6) with ESMTP id gBMFiXfd000401 for ; Sun, 22 Dec 2002 13:44:33 -0200 (BRST) (envelope-from vitor@softinfo.com.br) Message-ID: <000f01c2a9d1$059a1c00$020aa8c0@acaraje> Reply-To: "Vitor de Matos Carvalho" From: "Vitor de Matos Carvalho" To: Subject: Couldn't alloc kernel virtual memory Date: Sun, 22 Dec 2002 13:44:32 -0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi :))) I am trying to give boot with the cd of the FreeBSD 5.0-RC1 and 5.0-RC2 alone that not of the o boot, gives acknowledgment of that kernel alloc virtual memory. memory enough to give boot. With the cd of the 4.4-release and the 4.6-release of the o boot without problem. -------------- real memory = 234881024 (224 MB) avail memory = 21682856 (206 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enable md0: Preload image 4423680 bytes at 0xc06237dc panic: pmap_mapdev: couldn't alloc kernel virtual memory -------------- The machine is a AMD Ahtlon 900MHz with 256MB Ram. Regards, Vitor de Matos Carvalho System Network Administrator - Softinfo Network FreeBSD - The Power To Serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 8: 8:49 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4607937B401 for ; Sun, 22 Dec 2002 08:08:48 -0800 (PST) Received: from mailgate5.cinetic.de (mailgate5.cinetic.de [217.72.192.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8AB643EDE for ; Sun, 22 Dec 2002 08:08:46 -0800 (PST) (envelope-from thorsten.greiner@web.de) Received: from web.de (fmomail02.dlan.cinetic.de [172.20.1.46]) by mailgate5.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id gBMG8eX05317 for current@freebsd.org; Sun, 22 Dec 2002 17:08:40 +0100 Date: Sun, 22 Dec 2002 17:08:40 +0100 Message-Id: <200212221608.gBMG8eX05317@mailgate5.cinetic.de> MIME-Version: 1.0 Organization: http://freemail.web.de/ From: Thorsten Greiner To: current@freebsd.org Subject: Missing MFC of geom_slice.c ? Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I just tried to compile 5.0-RC2 from using a recently cvsupped copy using the RELENG_5_0 tag and found that src/sys/geom/geom_slice.c does not compile. It seems that the version of geom_slice.h which was tagged as RELENG_5_0 is out of sync with the .c file. Getting the HEAD revision of geom_slice.c fixed this problem. Regards -Thorsten ______________________________________________________________________________ Verleihen Sie Ihren E-Mails eine personliche Note mit WEB.DE FreeMail http://freemail.web.de/features/?mc=021139 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 10: 1:42 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C37C37B401 for ; Sun, 22 Dec 2002 10:01:41 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59FB343EDC for ; Sun, 22 Dec 2002 10:01:40 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from [216.20.231.174] (helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18QAPc-0006NK-00; Sun, 22 Dec 2002 10:01:17 -0800 Message-ID: <3E05FD89.33D7D3E2@mindspring.com> Date: Sun, 22 Dec 2002 09:59:37 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Darren Reed Cc: Sergey Mokryshev , Vallo Kallaste , Sam Leffler , Hiten Pandya , current@FreeBSD.ORG Subject: Re: PFIL_HOOKS should be made default in 5.0 References: <200212220419.PAA21619@avalon.reed.wattle.id.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a42f948a55492d8dc4500f078f41e6ea9e666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Darren Reed wrote: > > If you make them non-optional, which is what started this thread, > > then you *are* talking about having to add an option in to get > > rid of them. > > Seriously, Terry, how many "NO_foo" options exist, today ? Any non-zero number of them is too many. Personally, I also dislike the "foo" options, too... anything that requires me to recompile something to use it annoys me. 8-). > > I understand that people all want their pet software to run out > > of the box without modification. > > I'm not the one who wants that, it's people who USE FreeBSD. You > remember users, don't you Terry ? :) Yeah... those are the people we've been writing the new installer for, for the last 6 years, but never finishing it, right? Seriously, the problem is that not enough work has been done to allow segmentation of the fastpath, with accessor/mutator functions, with zero or low cost. The closest you can really get to doing the right thing in the current FreeBSD codebase is to use existing hooks for things that are already there, and eat the overhead you were going to eat anyway. That works out to "no new overhead, abuse existing overhead, work to eliminate existing overhead in future releases". A good example of terrible overhead that should not be there is that the IPv4 code bloats the per connection data horribly, when IPSEC is enabled, but not being used. Another good example is in the ip_input code calling a function that does a pcb hash lookup for divert/fast bridging, and then calls it again in tcp_input, rather than passing the lookup, that was already completed, in as part of the context for the tcp_input. Ideally, there would be a combined has space that ipfilter, the bridging code, DSR, TCP splicing, the SYN cache, and everybody else who wanted to do connection state based decisions would use. The only reason I even commented was that it seems to me that there was an attempt at an end-run to get more overhead in for some excuse other than the real one. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 10: 3:24 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E21C437B401 for ; Sun, 22 Dec 2002 10:03:22 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEC5743ED8 for ; Sun, 22 Dec 2002 10:03:21 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id gBMI3Ku6002202; Sun, 22 Dec 2002 19:03:20 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Thorsten Greiner Cc: current@FreeBSD.ORG Subject: Re: Missing MFC of geom_slice.c ? From: phk@FreeBSD.ORG In-Reply-To: Your message of "Sun, 22 Dec 2002 17:08:40 +0100." <200212221608.gBMG8eX05317@mailgate5.cinetic.de> Date: Sun, 22 Dec 2002 19:03:20 +0100 Message-ID: <2201.1040580200@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200212221608.gBMG8eX05317@mailgate5.cinetic.de>, Thorsten Greiner w rites: >Hi, > >I just tried to compile 5.0-RC2 from using a recently cvsupped >copy using the RELENG_5_0 tag and found that src/sys/geom/geom_slice.c >does not compile. > >It seems that the version of geom_slice.h which was tagged as >RELENG_5_0 is out of sync with the .c file. Getting the HEAD revision >of geom_slice.c fixed this problem. I have no idea why cvs decided to ignore some of the files. I have just rerun the commit command using !rcvs and it discovered the rest now I think. :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 10:23: 8 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AF6637B405 for ; Sun, 22 Dec 2002 10:23:04 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9AAA43EE6 for ; Sun, 22 Dec 2002 10:23:03 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from [216.20.231.174] (helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18QAkT-0000Wh-00; Sun, 22 Dec 2002 10:22:49 -0800 Message-ID: <3E060298.70D2CA16@mindspring.com> Date: Sun, 22 Dec 2002 10:21:12 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Darren Reed Cc: Sergey Mokryshev , Vallo Kallaste , Sam Leffler , Hiten Pandya , current@FreeBSD.ORG Subject: Re: PFIL_HOOKS should be made default in 5.0 References: <200212220443.PAA21632@avalon.reed.wattle.id.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4f33ea3f1d6c6f3221ae605c3a5feb727350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Darren Reed wrote: > > My response to that was that you could create accessor/mutator > > functions which were always defined, but not always functional. > > By using these functions, instead of trying to access the pointers > > directly, there are no undefined symbols, and you get the specific > > error message, rather than the generic: any message you want it to > > print. > > That doesn't work when ipfilter is compiled outside of the kernel > build directory (as often happens), where it is going to be unaware > of whether or not PFIL_HOOKS has been defined for the kernel. Yes, it does work... to get the specific, rather than the general error message. What *doesn't* work is the module fails to register when the hooks aren't present. The original complaint was against the error message not being right, but what the complainer *really* wanted was to be able to load an ipfilter module into a GENERIC kernel. They were being disingenuous: they misrepresented their solution as being the only solution to the error message "problem" (a strawman), when what they really wanted was ipfilter support by default in GENERIC. I don't have a problem with people wanting that, but they should not misrepresent the request as if they were asking for something else ("Fix confusing error message for users"). Whether or not people would accept the slowdown, knowing the real reason behind the proposed change, is something else entirely. I think you touch on an important point here: kernel options that have to be known to modules at the time that the modules are compiled. PHK and other have touched on this as well, in the discussion about making the kernel structures stay the same size, no matter what options are being used to compile the kernel; that *part* of the fix. I think the real fix is to get rid of compile time options. But that can't be done for options that have a lot of overhead, whose pay-off is to add functionality that most people will never use. > > The real reason is that the > > people complaining don't want to have to recompile the kernel to > > use the ipfilter module: > > That or any other module that uses the pfil(9) interface. Sure. And they should have come out and said that, instead of pretending they were trying to de-obfuscate an error message. I think that, until the pfil(9) interface uses an existing hook, like the netgraph one, or until netgraph is rewriten to use the pfil(9) interface instead of having its own hooks, that adding yet-more-hooks -- and overhead -- to the packet processing path is a bad thing to have turned on by default. > > But compiling the kernel with the hooks in place is not the only > > way to solve the problem. > > It is a better step forward than the proposal I've seen you put > forward about accessor hooks and having them prevent the obscure > modload error message. It's a better step forward *for ipfilter*. Who else uses pfil(9)? My proposal was an equally valid means of being able to trap the fact that the kernel wasn't compiled with PFIL_HOOKS, without giving an obscure "undefined symbol" error. If the problem as stated were what was really being addressed, my solution would have been much better: it doesn't add overhead to the fast-path in the common case. 8-). > > Yeah, that's the reason that BPF and netgraph and streams and ... > > were invented, too. Wouldn't it be great if everyone adopted the > > API I like best? 8-) 8-). > > Terry, did you have any hand in writing netgraph ? I've seen hardly > anyone else put their hand up in favour of it so I'm suspecting a > certain amount of bias here :-) :) No, that's Julian's baby. I talked to him about it when it was happening, and with Archie on the tty node, and various other people, as they've written modules for it. My bias, if any, though, is actually against multiple packet processing path hook interfaces. I'd be just as happy to have pfil(9) be the only interface... if someone were to rewrite the netgraph, BPF, and other code to use pfil(9). > Well, for BPF it works. Lots of devices have bpf_*tap()s in them > and nobody bothers about the overhead from that. I do... 8-) 8-). > For STREAMS you don't need to do anything. > > I suppose I'm trying to push pfil(9) into the same kind of role as > BPF. Yep. And I'm saying "Dere can be only one!". 8-). > Well, let me describe how ipfilter works in a STREAMS environment, > or rather, how version 4.0 of ipfilter works. > > To separate the STREAMS gunk out of ipfilter (or as much as possible) > I wrote an equivalent of pfil(9) for HP-UX 11/Solaris. That is a > STREAMS module that gets push'd onto the network device before the > IP module does so all IP traffic goes through pfil(9). IPFilter > registers with pfil(9) to intercept the packets that would otherwise > be going straight through it to the IP routines. > > For it to be worthwhile to use netgraph on FreeBSD, FreeBSD would need > to be re-engineered such that the linkage between layer 2 devices (all > of the ethernet cards, etc) and layer 3 code (ip, ipv6, etc) was done > through netgraph - or at least that's how I see it. From a security > perspective that's definately how I'd want it to be - the filtering > as the middle man, not some inspector hanging off the side somewhere. You can ask Julian; I think this can be forced, using interface nodes (from my understanding of the code)... > > The ipfilter code is in the second category. > > > > It's really bogus to insist that everything take the slow path > > because something slow has to take the slow path. > > I think you're missing the point about why people want "everything" to > take the "slow path". People are using it for security and when you're > doing that, there is no "fast path" or "slow path", there is only a > "secure path". I typically do that only when I'm using FreeBSD as my firewall; I'm more likely to use PIX or something else for that role (that's a personal preferance thing). Once you are behind the firewall, the machines that are there aren't really doing dual-duty as a firewall *and* a web server. So one box out of a *lot* of boxes needs what you describe. After that, we're back to "fast path". > btw, I did make an effort to read how to use netgraph and I'm shocked. > It looks like even more effort to use than STREAMS and not in a good > way either. IMO, it's a lot of work to use. But it doesn't have the in vs. out pipeline stalls that you end up with STREAMS (where you have to have two run cycles to get a packet in and back), and it's a lot more flexible, generally (FWIW). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 11: 5:48 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56BB337B401 for ; Sun, 22 Dec 2002 11:05:47 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1C4143EE6 for ; Sun, 22 Dec 2002 11:05:46 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.12.6/8.12.6) with ESMTP id gBMJ5kNd067237 for ; Sun, 22 Dec 2002 11:05:46 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.12.6/8.12.6/Submit) id gBMJ5kGD067236 for freebsd-current@freebsd.org; Sun, 22 Dec 2002 11:05:46 -0800 (PST) Date: Sun, 22 Dec 2002 11:05:46 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: acpi panic Message-ID: <20021222190546.GA67145@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A kernel (and world) built from -current sources from Sunday morning about 9 am PST yields: panic: pmap_mapdev: Couldn't alloc kernel virtual memory Debugger("panic") Stopped at Debugger+0x54: xchgl %ebx, in_Debugger.0 db> tr panic AcpiOsMapMemory AcpiTbGetThisTable AcpiTbGetTableBody AcpiTbGetTable AcpiTbGetTableRsdt AcpiLoadTables acpi_identify bus_generic_probe nexus_attach device_probe_and_attach probe_and_attach root_bus_configure configure mi_strartup begin I get an instant reboot if I try to get a coredump, and the machine does not have a serial console. The panic is 100% reproducible, so I can get additional info if requested. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Dec 22 11: 8:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFCDE37B401 for ; Sun, 22 Dec 2002 11:08:54 -0800 (PST) Received: from weaponsof.massdestruction.net (massdestruction.net [205.252.38.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 042DE43ED8 for ; Sun, 22 Dec 2002 11:08:54 -0800 (PST) (envelope-from herb@massdestruction.net) Received: from weaponsof.massdestruction.net (herb@weaponsof.massdestruction.net [205.252.38.67]) by weaponsof.massdestruction.net (8.11.6/8.11.6) with ESMTP id gBMJ8qc06552 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Sun, 22 Dec 2002 14:08:52 -0500 (EST) (envelope-from herb@massdestruction.net) Date: Sun, 22 Dec 2002 14:08:52 -0500 (EST) From: Herb McNew To: current@FreeBSD.ORG Subject: lock order reversal Message-ID: <20021222140447.M61973-100000@weaponsof.massdestruction.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, In a cursory search of the mailing list archives I didn't find this LOR reported. I apologize if it's a repeat. lock order reversal 1st 0xc0b9e800 pcm0:play:0 (pcm channel) @ /usr/src/sys/dev/sound/pcm/dsp.c:150 2nd 0xc051ebe0 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:314 dmesg output (NEC VersaVX): Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-RC1 #0: Sat Dec 7 22:16:29 GMT 2002 root@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc06b1000. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc06b10a8. Preloaded elf module "/boot/kernel/linux.ko" at 0xc06b1154. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc06b1200. Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc06b12ac. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 498273583 Hz CPU: Pentium III/Pentium III Xeon/Celeron (498.27-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1 Features=0x383f9ff real memory = 134152192 (127 MB) avail memory = 123129856 (117 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled VESA: v2.0, 4096k memory, flags:0x0, mode table:0xc066eca2 (1000022) VESA: ATI MACH64 npx0: on motherboard npx0: INT 16 interface Using $PIR table, 5 entries at 0xc00f6030 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcm0: port 0xef00-0xef3f,0xe000-0xe0ff irq 10 at device 0.1 on pci0 pci0: at device 0.2 (no driver attached) cbb0: at device 3.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pci_cfgintr: 0:3 INTA routed to irq 5 cbb1: at device 3.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci_cfgintr: 0:3 INTB routed to irq 5 pci0: at device 5.0 (no driver attached) pci0: at device 6.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xef80-0xef9f irq 9 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) orm0: