From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 03:03:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0B2016A514 for ; Sun, 9 Dec 2007 03:03:12 +0000 (UTC) (envelope-from adrian.chadd@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 4D10B13C44B for ; Sun, 9 Dec 2007 03:03:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so2675576pyb for ; Sat, 08 Dec 2007 19:03:11 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=6zMqdzIdb7c3ZSSy5HCdzalTmL1WLLN0LWTkvhSFHfs=; b=TkuesrU8ltGtv9mXpymCqnHvJf//l/VKAhzsyOqEhFmusy2z1LBGqGPz78v/ye/4BGICihakGnl7S08JmD1g3d0Ft9EwkN+N+Gf2bhxGhYQQ/jk97rr2rSUqgBp40WHQREJX4J9YvyY6czW0skTJ4344RT7j9kCcaJrS9AwcJ/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kWkvu5SGtOdVDc83xeI0fBXNyunzYcZFnv7N3n506ypl8VslkUf9D20CMJfRRMgj3tyAW1FBQbfsrgFQ4vErM7B8CZlhapNbfKQdtVaa1D0TKTLQR24OHCbjFo/ccqPHGbUIteWvlxefOws5OeZB1VN1oNhChZwpuJseG97oMew= Received: by 10.65.214.2 with SMTP id r2mr10498817qbq.1197169391238; Sat, 08 Dec 2007 19:03:11 -0800 (PST) Received: by 10.65.155.16 with HTTP; Sat, 8 Dec 2007 19:03:11 -0800 (PST) Message-ID: Date: Sun, 9 Dec 2007 12:03:11 +0900 From: "Adrian Chadd" Sender: adrian.chadd@gmail.com To: "Jan Lentfer" In-Reply-To: <20071207101817.xcvz0wdi68cscwkg@neslonek.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4756BAD3.4060905@web.de> <95938867@bb.ipt.ru> <200712060051.26294.joao@matik.com.br> <20071207101817.xcvz0wdi68cscwkg@neslonek.homeunix.org> X-Google-Sender-Auth: 8200e56e105cfd2e Cc: freebsd-current@freebsd.org, JoaoBR Subject: Re: Problems Building 7.0-Beta3 with -Os X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 03:03:12 -0000 On 07/12/2007, Jan Lentfer wrote: > On the other hand, why you want to optimzie the hell out of a 4-way > 8-Gig Operton server or the like, for normal services you want feel > too much difference here, because it is fast as hell anyway. Because sometimes "optimising the hell out of a large server" is the difference between needing to buy 1 or 1.5 of said server. (It doesn't help that a lot of code out there these days is hideously inefficient - how many people still run apache-prefork? Or early versions of Squid? :) Adrian -- Adrian Chadd - adrian@freebsd.org From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 05:09:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24E416A41B for ; Sun, 9 Dec 2007 05:09:41 +0000 (UTC) (envelope-from sfourman@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 067B013C465 for ; Sun, 9 Dec 2007 05:09:40 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so804821nfb for ; Sat, 08 Dec 2007 21:09:39 -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=MuFDsTnInqXB4gEi/RWbRnQzHCeqbBwoZhfGTfmyH2c=; b=ijfq5s0zZ2yZAX5oueKiTiMBl1spal0/lC+hFGyWF0ndMN0GaOMBv8INY2WKBXnq7eqH3i5+XXZG0OyHfbqRkSOE5hE3RGSxg9sWZ8Cz5me7wszNrKDZNUro5bDFiSAonbN8NeDHHJnSRx6Jj3La63fkoRMNmrdrorBW9vGB3Us= 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=pdL3RtZGN9wkesc/06lZdpMPfCuYhtqh/fZwQa3EUuEIqNhLCRb9xK2CsraGuO0wWHoouizwVy/Mprs56dzMXHXBzK1MserLe+1ronFFnq8yYwtW6LnKCrSAAjt7JCnEJ4a1jlJzs9Lt40zaX96xdu1TInjxblwQcynVJjtrsU8= Received: by 10.86.66.1 with SMTP id o1mr4057788fga.1197176979515; Sat, 08 Dec 2007 21:09:39 -0800 (PST) Received: by 10.86.52.6 with HTTP; Sat, 8 Dec 2007 21:09:39 -0800 (PST) Message-ID: <11167f520712082109k1ddcbc4ande2f8051bc42ef97@mail.gmail.com> Date: Sat, 8 Dec 2007 23:09:39 -0600 From: "Sam Fourman Jr." 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: <200712081728.18710.Thomas.Sparrevohn@btinternet.com> <475AD8DE.4080302@conducive.net> <200712082118.30268.Thomas.Sparrevohn@btinternet.com> Cc: freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 05:09:41 -0000 the funny thing is, I thought I was crazy, but cpu overheating seems to be happening to me too. I have 5 identical computers 2 of witch are running FreeBSD 7.0 BETA1 and the other BETA3, this computer was compiled fresh last weekend, and twice wile running Deluge torrent the network cards stop working, and I reboot the computer,and it will not even start it hangs on starting the ssh daemon, and xwindows will not even start. I thought this was just the nfe driver being flaky again. but maybe not. if I leave the computer off for 20 minutes it boots perfect. bios reports my CPU temp at 48C and 53C again I have 2 Computers doing this with FreeBSD, the others Run Fedora core 8 and have no trouble and are in the same eviroment. the fedora core computers are at 29C and 31C my info for one of the computers is below. I would be happy to do anything neccary I could even arrange a root ssh on a public IP for any devloper that would find it useful, again I have 5 computers configured exactly the same, completly formating and fresh installing one of them and letting someone screw with it for a week or so would be no problem. Sam Fourman Jr. Sam# sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2388 dev.cpu.0.freq_levels: 2388/-1 2089/-1 1791/-1 1492/-1 1194/-1 895/-1 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/0 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.cx_supported: C1/0 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.cx_supported: C1/0 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-BETA3 #0: Fri Nov 16 22:20:33 UTC 2007 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2399.99-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 4 real memory = 2146369536 (2046 MB) avail memory = 2090807296 (1993 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fdf0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 924092406000924 device_attach: est3 attach returned 6 p4tcc3: on cpu3 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) pci0: at device 1.5 (no driver attached) pci0: at device 1.6 (no driver attached) pci0: at device 2.0 (no driver attached) pci0: at device 2.1 (no driver attached) pci0: at device 2.2 (no driver attached) pcib1: at device 3.0 on pci0 pci1: on pcib1 vgapci0: port 0xdf00-0xdf7f mem 0xec000000-0xecffffff,0xd0000000-0xdfffffff,0xea000000-0xebffffff irq 16 at device 0.0 on pci1 pcib2: at device 6.0 on pci0 pci2: on pcib2 pcib3: at device 7.0 on pci0 pci3: on pcib3 pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) ohci0: mem 0xeffff000-0xefffffff irq 21 at device 11.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xefffe000-0xefffe0ff irq 22 at device 11.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 13.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf700-0xf70f mem 0xefffd000-0xefffdfff irq 23 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf200-0xf20f mem 0xefffc000-0xefffcfff irq 20 at device 14.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xf100-0xf107,0xf000-0xf003,0xef00-0xef07,0xee00-0xee03,0xed00-0xed0f mem 0xefffb000-0xefffbfff irq 21 at device 14.2 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib4: at device 15.0 on pci0 pci4: on pcib4 fwohci0: port 0xcf00-0xcf7f mem 0xefbff000-0xefbff7ff irq 19 at device 11.0 on pci4 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:01:1e:3d:ab fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:d8:1e:3d:ab fwe0: Ethernet address: 02:11:d8:1e:3d:ab fwip0: on firewire0 fwip0: Firewire address: 00:11:d8:00:01:1e:3d:ab @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7d910000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pcm0: mem 0xefff0000-0xefff3fff irq 22 at device 15.1 on pci0 pcm0: [ITHREAD] nfe0: port 0xec00-0xec07 mem 0xefffa000-0xefffafff,0xefff9000-0xefff90ff,0xefff8000-0xefff800f irq 23 at device 17.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:1a:92:46:e0:44 nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe1: port 0xeb00-0xeb07 mem 0xefff7000-0xefff7fff,0xefff6000-0xefff60ff,0xefff5000-0xefff500f irq 20 at device 18.0 on pci0 miibus1: on nfe1 e1000phy1: PHY 1 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe1: Ethernet address: 00:1a:92:46:ed:f7 nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] pcib5: at device 19.0 on pci0 pci5: on pcib5 pcib6: at device 20.0 on pci0 pci6: on pcib6 pcib7: at device 21.0 on pci0 pci7: on pcib7 pcib8: at device 22.0 on pci0 pci8: on pcib8 atapci4: port 0x6f00-0x6f7f mem 0xef2ff000-0xef2ff07f,0xef2f8000-0xef2fbfff irq 16 at device 0.0 on pci8 atapci4: [ITHREAD] ata8: on atapci4 ata8: [ITHREAD] ata9: on atapci4 ata9: [ITHREAD] pcib9: at device 23.0 on pci0 pci9: on pcib9 pcib10: at device 24.0 on pci0 pci10: on pcib10 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd3fff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uhub2: on uhub0 uhub2: 4 ports with 2 removable, bus powered ukbd0: on uhub2 kbd2 at ukbd0 uhid0: on uhub2 uhid1: on uhub2 ums0: on uhub0 ums0: 8 buttons and Z dir. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DVDR at ata0-master UDMA66 acd1: CDRW at ata0-slave UDMA33 ad4: 152627MB at ata2-master SATA300 ad6: 152627MB at ata3-master SATA300 ad8: 152627MB at ata4-master SATA300 pcm0: pcm0: SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/ad4s1a nfe0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Sat Dec 8 19:15:48 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E73816A46B for ; Sat, 8 Dec 2007 19:15:48 +0000 (UTC) (envelope-from joemann@beefree.free.de) Received: from beefree.free.de (offshorenew.free.de [194.77.83.23]) by mx1.freebsd.org (Postfix) with ESMTP id C7EDF13C45B for ; Sat, 8 Dec 2007 19:15:45 +0000 (UTC) (envelope-from joemann@beefree.free.de) Received: (qmail 14033 invoked from network); 8 Dec 2007 19:42:53 +0100 Date: Sat, 8 Dec 2007 19:42:48 +0100 From: Johannes 5 Joemann To: "Bruce M. Simpson" Message-Id: <20071208194248.5cfcf0fd.joemann@beefree.free.de> In-Reply-To: <468A84FA.2090703@FreeBSD.org> References: <468A5B9D.6030401@FreeBSD.org> <468A84FA.2090703@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sat__8_Dec_2007_19_42_48_+0100_/Fu51QzRhA5OoiZa" X-Mailman-Approved-At: Sun, 09 Dec 2007 05:19:38 +0000 Cc: boris@tagnet.ru, current@freebsd.org Subject: Re: Multicast problems [PATCH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2007 19:15:48 -0000 This is a multi-part message in MIME format. --Multipart=_Sat__8_Dec_2007_19_42_48_+0100_/Fu51QzRhA5OoiZa Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi! On Tue, 03 Jul 2007 18:18:50 +0100 "Bruce M. Simpson" wrote: > Bruce M. Simpson wrote: > > I see now that Linux also supports ip_mreqn in its > > IP_ADD_MEMBERSHIP path. I could potentially change the ASM API > > ioctl paths (IP_ADD_MEMBERSHIP, IP_DEL_MEMBERSHIP) to detect and > > support the ip_mreqn structure -- however -- I am loathe to do > > this as it introduces another bunch of nested conditionals, as > > the same code now has to support IP_ADD_SOURCE_MEMBERSHIP in > > FreeBSD, which has the same structure size. It is also a > > retrograde change. > > I have attached a diff which emulates the Linux ip_mreqn kludge in > the IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP paths; this includes > the changes from the previous patch to workaround the non-existence > of a default route on boot. Thanx! > I do not plan to commit it at the moment and have not tested it. I tested your patch [1] on 7.0-BETA4 in order to make quagga's ospfd functional again (over here it is multicasting on 5 interfaces (3 of them point-to-point) - without the fix it only works on one interface). Your patch solves the problem that if quagga discovers ip_mreqn it also uses it for IP_ADD_MEMBERSHIP. Although you consider your patch to in_mcast.c to be a retrograde kludge, it made my day:-) For the convenience of other 7.0 users being lost in the Bermuda Triangle between RFC1724, Linuxisms, and RFC3678 I've attached a trivial modification of your patch, which makes it apply to the RELENG_7 version 1.3.2.1 of src/sys/netinet/in_mcast.c. > The right thing for applications to do is to use the RFC 3678 API Meanwhile users of ospfd might survive even without your kernel patch as outlined in [2]. I've attached that patch suggestion as a drop in for ports/net/quagga/files. It worked for me with an unpatched (and with a patched) 7.0-BETA4 kernel. > if they need to join an interface by index, the legacy ASM API can > only be relied upon if interfaces are assigned IPv4 addresses, and > it breaks for point-to-point because of legacy BSD behaviour. As long as FreeBSD supplies ip_mreqn in src/sys/netinet/in.h it seems reasonable to support associated operations like IP_ADD_MEMBERSHIP. It's certainly better to eradicate kludges and go with RFC3678, but meanwhile I'd support your patch being committed to RELENG_7 in order to make the ip_mreqn kludge smooth for production. (This is just a naive comment from a humble user who's not in the multicast business.-) Thanx for your work! Johannes ps I've Cc:ed the quagga maintainer (I hope that's OK) as I consider it undesirable to have 7.0 shipped with a broken quagga-ospfd. Whether this should be fixed in the kernel or the port (or both:) is another question, but something should happen ... [1] [2] --Multipart=_Sat__8_Dec_2007_19_42_48_+0100_/Fu51QzRhA5OoiZa Content-Type: text/x-diff; name="sys-netinet-in_mcast.c.patch" Content-Disposition: attachment; filename="sys-netinet-in_mcast.c.patch" Content-Transfer-Encoding: 7bit --- sys/netinet/in_mcast.c.orig 2007-11-30 18:01:05.000000000 +0100 +++ sys/netinet/in_mcast.c 2007-12-07 21:34:28.000000000 +0100 @@ -980,11 +980,40 @@ struct ip_mreq_source mreqs; if (sopt->sopt_name == IP_ADD_MEMBERSHIP) { - error = sooptcopyin(sopt, &mreqs, - sizeof(struct ip_mreq), - sizeof(struct ip_mreq)); /* - * Do argument switcharoo from ip_mreq into + * Handle the case where a struct ip_mreqn + * was passed to the IP_ADD_MEMBERSHIP ioctl to + * specify an interface index. This is an + * undocumented modification of the IPv4 ASM API + * obtained from Linux. + */ + if (sopt->sopt_valsize == sizeof(struct ip_mreqn)) { + struct ip_mreqn *mreqn = + (struct ip_mreqn *)&mreqs; + + error = sooptcopyin(sopt, mreqn, + sizeof(struct ip_mreqn), + sizeof(struct ip_mreqn)); + if (error) + return (error); + + if (mreqn->imr_ifindex < 0 || + if_index < mreqn->imr_ifindex) + return (EINVAL); + if (mreqn->imr_ifindex == 0) { + ifp = NULL; + } else { + ifp = ifnet_byindex(mreqn->imr_ifindex); + if (ifp == NULL) + return (EADDRNOTAVAIL); + } + } else { + error = sooptcopyin(sopt, &mreqs, + sizeof(struct ip_mreq), + sizeof(struct ip_mreq)); + } + /* + * Do argument switcharoo from ip_mreq[n] into * ip_mreq_source to avoid using two instances. */ mreqs.imr_interface = mreqs.imr_sourceaddr; @@ -1008,10 +1037,12 @@ } /* - * Obtain ifp. If no interface address was provided, - * use the interface of the route in the unicast FIB for - * the given multicast destination; usually, this is the - * default route. + * If ifp was not already overridden, obtain it. + * + * If no interface address was provided, use the interface + * of the route in the unicast FIB for the given multicast + * destination; usually, this is the default route. + * * If this lookup fails, attempt to use the first non-loopback * interface with multicast capability in the system as a * last resort. The legacy IPv4 ASM API requires that we do @@ -1020,9 +1051,9 @@ * If all of these conditions fail, return EADDRNOTAVAIL, and * reject the IPv4 multicast join. */ - if (mreqs.imr_interface.s_addr != INADDR_ANY) { - ifp = ip_multicast_if(&mreqs.imr_interface); - } else { + if (ifp == NULL && mreqs.imr_interface.s_addr != INADDR_ANY) { + INADDR_TO_IFP(mreqs.imr_interface, ifp); + } else if (ifp == NULL) { struct route ro; ro.ro_rt = NULL; @@ -1235,12 +1266,42 @@ case IP_DROP_MEMBERSHIP: case IP_DROP_SOURCE_MEMBERSHIP: if (sopt->sopt_name == IP_DROP_MEMBERSHIP) { - error = sooptcopyin(sopt, &mreqs, - sizeof(struct ip_mreq), - sizeof(struct ip_mreq)); + /* + * Handle the case where a struct ip_mreqn + * was passed to the IP_DROP_MEMBERSHIP ioctl to + * specify an interface index. This is an + * undocumented modification of the IPv4 ASM API + * obtained from Linux. + */ + if (sopt->sopt_valsize == sizeof(struct ip_mreqn)) { + struct ip_mreqn *mreqn = + (struct ip_mreqn *)&mreqs; + + error = sooptcopyin(sopt, mreqn, + sizeof(struct ip_mreqn), + sizeof(struct ip_mreqn)); + if (error) + return (error); + + if (mreqn->imr_ifindex < 0 || + if_index < mreqn->imr_ifindex) + return (EINVAL); + if (mreqn->imr_ifindex == 0) { + ifp = NULL; + } else { + ifp = ifnet_byindex(mreqn->imr_ifindex); + if (ifp == NULL) + return (EADDRNOTAVAIL); + } + } else { + error = sooptcopyin(sopt, &mreqs, + sizeof(struct ip_mreq), + sizeof(struct ip_mreq)); + } + /* * Swap interface and sourceaddr arguments, - * as ip_mreq and ip_mreq_source are laid + * as ip_mreq[n] and ip_mreq_source are laid * out differently. */ mreqs.imr_interface = mreqs.imr_sourceaddr; @@ -1263,7 +1324,7 @@ ssa->sin.sin_addr = mreqs.imr_sourceaddr; } - if (gsa->sin.sin_addr.s_addr != INADDR_ANY) + if (ifp == NULL && gsa->sin.sin_addr.s_addr != INADDR_ANY) INADDR_TO_IFP(mreqs.imr_interface, ifp); #ifdef DIAGNOSTIC --Multipart=_Sat__8_Dec_2007_19_42_48_+0100_/Fu51QzRhA5OoiZa Content-Type: text/x-diff; name="patch-lib_sockopt.c" Content-Disposition: attachment; filename="patch-lib_sockopt.c" Content-Transfer-Encoding: 7bit --- lib/sockopt.c.orig 2007-08-22 18:22:54.000000000 +0200 +++ lib/sockopt.c 2007-12-07 20:46:35.000000000 +0100 @@ -211,70 +211,12 @@ used instead of if_addr */) { -#ifdef HAVE_STRUCT_IP_MREQN_IMR_IFINDEX - /* This is better because it uses ifindex directly */ - struct ip_mreqn mreqn; - int ret; - - switch (optname) - { - case IP_MULTICAST_IF: - case IP_ADD_MEMBERSHIP: - case IP_DROP_MEMBERSHIP: - memset (&mreqn, 0, sizeof(mreqn)); - - if (mcast_addr) - mreqn.imr_multiaddr.s_addr = mcast_addr; - - if (ifindex) - mreqn.imr_ifindex = ifindex; - else - mreqn.imr_address = if_addr; - - ret = setsockopt(sock, IPPROTO_IP, optname, - (void *)&mreqn, sizeof(mreqn)); - if ((ret < 0) && (optname == IP_ADD_MEMBERSHIP) && (errno == EADDRINUSE)) - { - /* see above: handle possible problem when interface comes back up */ - char buf[2][INET_ADDRSTRLEN]; - zlog_info("setsockopt_multicast_ipv4 attempting to drop and " - "re-add (fd %d, ifaddr %s, mcast %s, ifindex %u)", - sock, - inet_ntop(AF_INET, &if_addr, buf[0], sizeof(buf[0])), - inet_ntop(AF_INET, &mreqn.imr_multiaddr, - buf[1], sizeof(buf[1])), ifindex); - setsockopt(sock, IPPROTO_IP, IP_DROP_MEMBERSHIP, - (void *)&mreqn, sizeof(mreqn)); - ret = setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, - (void *)&mreqn, sizeof(mreqn)); - } - return ret; - break; - - default: - /* Can out and give an understandable error */ - errno = EINVAL; - return -1; - break; - } - - /* Example defines for another OS, boilerplate off other code in this - function, AND handle optname as per other sections for consistency !! */ - /* #elif defined(BOGON_NIX) && EXAMPLE_VERSION_CODE > -100000 */ - /* Add your favourite OS here! */ - -#else /* #if OS_TYPE */ /* standard BSD API */ struct in_addr m; struct ip_mreq mreq; int ret; -#ifdef HAVE_BSD_STRUCT_IP_MREQ_HACK - if (ifindex) - m.s_addr = htonl(ifindex); - else -#endif m = if_addr; switch (optname) @@ -314,7 +256,6 @@ return -1; break; } -#endif /* #if OS_TYPE */ } --Multipart=_Sat__8_Dec_2007_19_42_48_+0100_/Fu51QzRhA5OoiZa-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 06:12:05 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AB0E16A417 for ; Sun, 9 Dec 2007 06:12:05 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2543513C457 for ; Sun, 9 Dec 2007 06:12:04 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by tydfam.jp (8.14.2/8.14.2) with ESMTP id lB95dLlv079035 for ; Sun, 9 Dec 2007 14:39:21 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sun, 09 Dec 2007 14:39:21 +0900 (JST) Message-Id: <20071209.143921.13767913.ken@tydfam.jp> To: freebsd-current@freebsd.org From: User ken X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5050/Sun Dec 9 13:44:32 2007 on daemon.sub.tydfam.jp X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=8.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on daemon.sub.tydfam.jp Subject: Kernel compilation fails w/ recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 06:12:05 -0000 Hi! I have the following errro when I compile kernel with recent current for about a week. Are there any fixes or workaround available? # cvsup ; make -j 32 KERNCONF=TYD3 -DNO_WERROR buildkernel : : : cc -O2 -fno-strict-aliasing -pipe -O3 -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/TYD3/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/usr/obj/usr/src/sys/TYD3 -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 /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_wakeup.c as -o assym.o assym.s cc1: warnings being treated as errors /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_perf.c: In function 'acpi_perf_attach': /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_perf.c:426: warning: 'set.freq' may be used uninitialized in this function /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_perf.c:426: note: 'set.freq' was declared here *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 : : : From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 06:30:49 2007 Return-Path: Delivered-To: freebsd-current@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 ; Sun, 9 Dec 2007 06:30:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id C6DBB13C457 for ; Sun, 9 Dec 2007 06:30:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id lB96QSha089179; Sat, 8 Dec 2007 22:26:28 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id lB96QSBR089178; Sat, 8 Dec 2007 22:26:28 -0800 (PST) (envelope-from sgk) Date: Sat, 8 Dec 2007 22:26:28 -0800 From: Steve Kargl To: User ken Message-ID: <20071209062628.GA89162@troutmask.apl.washington.edu> References: <20071209.143921.13767913.ken@tydfam.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071209.143921.13767913.ken@tydfam.jp> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Kernel compilation fails w/ recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 06:30:49 -0000 On Sun, Dec 09, 2007 at 02:39:21PM +0900, User ken wrote: > > I have the following errro when I compile kernel with recent current > for about a week. > Are there any fixes or workaround available? > > # cvsup ; make -j 32 KERNCONF=TYD3 -DNO_WERROR buildkernel Get rid of the '-j 32'. Get rid rid of the -DNO_ERROR. I built a new kernel less than an hour ago. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 07:09:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B35916A419 for ; Sun, 9 Dec 2007 07:09:55 +0000 (UTC) (envelope-from sfourman@gmail.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 D1CFA13C43E for ; Sun, 9 Dec 2007 07:09:54 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so1961346mue for ; Sat, 08 Dec 2007 23:09:53 -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=v9WZqCk4OKC/PkpGyWaVUusU2SUloPe9WijyadTMLg8=; b=snLmpHzXGeiRx3QeurkwD6WNOSCcOaL27UZfRUbPQRBRhbETUnXpzYjm1K8pQtGSkRUW3+ttxIUGjQiY9ffZQnZ0GZZ0V0rVUuoKD1fAlPUrXyA3iH5x6XJBpM4TORo5i4WfevEZZe5J1XtaE2SqCoZD2aDLMixtDlIazPGYWNA= 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=ito/XCEJBxKwn3v7kzG4ktEKptS/cFTUBlGlsHDfeaqOIrsfvMjvoSBYRE0f1EAxlJmnVf/eYgMuMBXmG7FSIgaz/0V1zBmRYPL+ahKaiNTeCWSxYgfKSYhI15nx7UsYxSIW2DmmbJHoHx0c8BuyR3KEavWrnVFwXkRdUorCBB8= Received: by 10.86.91.12 with SMTP id o12mr4133083fgb.1197184193082; Sat, 08 Dec 2007 23:09:53 -0800 (PST) Received: by 10.86.52.6 with HTTP; Sat, 8 Dec 2007 23:09:53 -0800 (PST) Message-ID: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> Date: Sun, 9 Dec 2007 01:09:53 -0600 From: "Sam Fourman Jr." To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: amd64 NVIDIA support in FreeBSD 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 07:09:55 -0000 Hello, I am aware that currently 3D accelerated support for Nvidia cards is not possible on the amd64 platform. My understanding is Nvidia (in 2006) requested some changes to the kernel that will improve performance,and ultimately provide support to the amd64 platform. the status of these changes can be found here http://wiki.freebsd.org/NvidiaFeatureRequests what I am confused about is how complex is the nature of these requests? is it realistic to think they will be MFC'ed to FreeBSD 7.x or will they have to be in 8.x ? assuming the changes outlined here http://wiki.freebsd.org/NvidiaFeatureRequests are completed would the Features and performance be on par with Linux Eg. FC8 ? I am hoping someone could explain these questions. Thank you Much Sam Fourman Jr. Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 07:35:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2DF316A417 for ; Sun, 9 Dec 2007 07:35:15 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id B3C0013C43E for ; Sun, 9 Dec 2007 07:35:15 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2657704waf for ; Sat, 08 Dec 2007 23:35:15 -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=4O6TArt/ihiZtO+MqVDRVbeZZPzNfUKUU1tcYsQxTUk=; b=fkdTR6ClhSgm2vkgi/KQNkF7YUJilWy4fwxzA0amnJctgUviPSldlj1m6gfvyZWlpDKP5oUILOikTZVDUcPNXpiDcuDJIjE3BRm19NFS4jiGHA3uGHv4ifGk27pjNdZIHEHVV6SZw0Dw7fCPrM55xL15WTwM1ucoFBPebxgi0pU= 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=fwXerCVVo3T6tU412vtn+soQHQDKEJulzqq86thyf4AfW+lkvBAI1BnGhGdmFRECOQn5JX+ETfcYJZ59w3xyThps+K0UqyCFsq7rfVjCCO4GbZqwzvvN+GjMInuVW6bD1Ua0NzvcF6DN9Pqi217sFRAjY7X2s5pZUlkAlNwu0p0= Received: by 10.115.23.12 with SMTP id a12mr5459936waj.1197185715020; Sat, 08 Dec 2007 23:35:15 -0800 (PST) Received: by 10.114.255.11 with HTTP; Sat, 8 Dec 2007 23:35:14 -0800 (PST) Message-ID: Date: Sat, 8 Dec 2007 23:35:14 -0800 From: "Kip Macy" To: "Sam Fourman Jr." , freebsd-current@freebsd.org In-Reply-To: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> Cc: Subject: Re: amd64 NVIDIA support in FreeBSD 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 07:35:16 -0000 The problem is that it is a moving target. In order to support NVIDIA long term FreeBSD would need to maintain API parity with Linux. As Linux adds new interfaces, NVIDIA incorporates them into their driver. Unless someone steps up and decides to own the continuing support effort to add those interfaces as the need arises, it isn't likely to happen. On the upside, it looks like ATI's opening up is starting to bear fruit. -Kip On 12/8/07, Sam Fourman Jr. wrote: > Hello, > > I am aware that currently 3D accelerated support for Nvidia cards is > not possible on the amd64 platform. > > My understanding is Nvidia (in 2006) requested some changes to the > kernel that will improve performance,and > ultimately provide support to the amd64 platform. > the status of these changes can be found here > http://wiki.freebsd.org/NvidiaFeatureRequests > > what I am confused about is how complex is the nature of these requests? > is it realistic to think they will be MFC'ed to FreeBSD 7.x or will > they have to be in 8.x ? > > assuming the changes outlined here > http://wiki.freebsd.org/NvidiaFeatureRequests are completed > > would the Features and performance be on par with Linux Eg. FC8 ? > > I am hoping someone could explain these questions. > > Thank you Much > > Sam Fourman Jr. > > > Sam Fourman Jr. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 09:58:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4B6116A418 for ; Sun, 9 Dec 2007 09:58:29 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4733B13C458 for ; Sun, 9 Dec 2007 09:58:28 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by tydfam.jp (8.14.2/8.14.2) with ESMTP id lB99wON7084497; Sun, 9 Dec 2007 18:58:24 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sun, 09 Dec 2007 18:58:24 +0900 (JST) Message-Id: <20071209.185824.58451009.ken@tydfam.jp> To: sgk@troutmask.apl.washington.edu From: User ken In-Reply-To: <20071209062628.GA89162@troutmask.apl.washington.edu> References: <20071209.143921.13767913.ken@tydfam.jp> <20071209062628.GA89162@troutmask.apl.washington.edu> X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5053/Sun Dec 9 17:39:12 2007 on daemon.sub.tydfam.jp X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=8.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on daemon.sub.tydfam.jp Cc: freebsd-current@freebsd.org Subject: Re: Kernel compilation fails w/ recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 09:58:29 -0000 Thank you for your reply. I accidentally left obsolete option in config file I used and it caused the error. Now, it is fixed. From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 13:30:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31D8E16A418 for ; Sun, 9 Dec 2007 13:30:10 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by mx1.freebsd.org (Postfix) with ESMTP id B17B313C474 for ; Sun, 9 Dec 2007 13:30:09 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAEt5W0d5LSIc/2dsb2JhbACBWg X-IronPort-AV: E=Sophos;i="4.23,273,1194183000"; d="scan'208";a="2891239" Received: from ppp121-45-34-28.lns10.adl2.internode.on.net (HELO mail.clearchain.com) ([121.45.34.28]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Dec 2007 23:44:49 +1030 Received: from [192.168.155.249] (draco.internal.clearchain.com [192.168.155.249]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id lB9DEjH0031087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Dec 2007 23:44:46 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <475BEA3C.5050305@clearchain.com> Date: Sun, 09 Dec 2007 23:44:36 +1030 From: Benjamin Close User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jeff Palmer References: <475759B7.6080502@gmail.com> <475762D0.8080404@acm.poly.edu> <4757FC17.4040605@clearchain.com> <47583D14.2020900@rexdb.com> <475870C0.9070908@errno.com> <4758A0A4.2090002@rexdb.com> In-Reply-To: <4758A0A4.2090002@rexdb.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Sun, 09 Dec 2007 23:44:47 +1030 (CST) Cc: Benjamin Adams , Boris Kochergin , freebsd-current@freebsd.org Subject: Re: wireless 3945ABG Wireless support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 13:30:10 -0000 Jeff Palmer wrote: > Sam Leffler wrote: > >> Jeff Palmer wrote: >> >>> Benjamin Close wrote: >>> >>> >>>> Boris Kochergin wrote: >>>> >>>> >>>>> Benjamin Adams wrote: >>>>> >>>>> >>>>>> I'm currently running 6.2 on my ibm T60. >>>>>> I want to upgrade to 7.0 or 8.0. >>>>>> Do either one have the intel 3945ABG wireless driver installed by >>>>>> default? >>>>>> or where can I download the latest drivers for it? >>>>>> Thanks >>>>>> >>>>>> ----------------------------------------- >>>>>> Ben Adams >>>>>> http://www.FreeBSD-World.com/ >>>>>> _______________________________________________ >>>>>> freebsd-current@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-current-unsubscribe@freebsd.org" >>>>>> >>>>>> >>>>> You can get the driver for 7/8 from >>>>> http://www.clearchain.com/wiki/Wpi, and it's included in 8-CURRENT. >>>>> >>>>> >>>> And about to be MFC'ed to 7... well at least in the next day. >>>> >>>> Cheers, >>>> Benjamin >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>>> >>>> >>>> >>>> >>>> >>>> >>> There seems to be a lot of reports of success using the wpi driver for >>> that chipset, however it's not working for everyone. Count me as one of >>> them it doesn't currently work for. You can search the archives if you >>> are interested in details. >>> >>> >>> >> If you've got a problem and want it fixed please file a PR w/ >> sufficient information for someone to diagnose. Referring to some old >> post is unlikely to result in help. >> >> Sam >> >> >> !DSPAM:8,475870d721261944516145! >> >> >> > Sam, > > I didn't feel a PR was in order just yet, because I had posted and > gotten a reply from Ben with a patch he wanted me to try. The patch got > my hardware a bit closer to associating. However it wasn't "quite there > yet." I'm aware he's busy, and I'm quite patient. So the fact that he > hasn't had me try anything else in the meantime doesn't annoy or bother > me in the least. > > It's quite the opposite actually. These developers who know enough to > write (or port) drivers, and then donate their time to actually _do_ it > have nothing but my utmost respect. > > I didn't mean for that post to sound like "RUN AWAY!" or like I was > complaining. That's actually why I mentioned the large number of > success stories, to show that many people do have it going without > problems. I'm not sure if there are different revisions of the chip, > or what the problem may be; but I was just making the original poster > aware that he may still have problems with it, and he probably wouldn't > be the only one if he did. > > At this point, I'll leave it up to Benjamin Close (who is being CC'd) > Would you prefer I filed a formal PR just to get it "on the record?" > > I've tried the p4fetch.rb script mentioned on the clearchain wpi page, > but apparantly I don't have something installed that it needs. I have > ruby installed, but it complains, so I'm guessing I'm missing a library > or plugin it needs. However, I don't know or use ruby, so I have no > clue what to install. Sadly, downloading things from perforce is a > serious pain if doing it manually, so I just haven't tried the p4 version. > > Hope that cleared things up. In summary: Thanks Ben (and all the > developers!) for some seriously great work. > > Jeff > Hi Jeff, For now please send me logs and a list of issues. I'll work with you to resolve them in the p4 branch as time permits. Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 13:46:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A8FC16A417 for ; Sun, 9 Dec 2007 13:46:00 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id BFAD413C45A for ; Sun, 9 Dec 2007 13:45:59 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so2888394pyb for ; Sun, 09 Dec 2007 05:45:58 -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=agI00n7f8J738qVUAl9zxhHf9CS7c5RfRiUmXgVDZ7w=; b=IrwWw3vkbQNL3p1mSTmXw4tHv3/uSz6bOOffYcwa/wrT+vIDJdgqEJUmtg20BWSb7ZepO0qK81EsK45HbysbK8BhnBKWdH+Upru3/Nv27DMhQr77OZtQEJrOQZbXgeRQl1+EizNC4xBSFYgkcEp3A1UAEnKyMmTUixl9lya9jWM= 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=xmEhMYSlC8hU+48h9I7T/gOJm+0KvJzSN0HZmfAJX+2enOL0JtCXfTV8cgSeF8en7+mas8U5YIaZPr/tOLYd2MoKEbvbbONRYa/1l16zGIqC/OmP0Psa4wko3Uhj+T4v9ABP92gnwKirMUUa4EXHl97RSYvRTDeEPwaCLMscrJI= Received: by 10.64.149.15 with SMTP id w15mr11435873qbd.1197207958255; Sun, 09 Dec 2007 05:45:58 -0800 (PST) Received: by 10.65.107.3 with HTTP; Sun, 9 Dec 2007 05:45:58 -0800 (PST) Message-ID: Date: Sun, 9 Dec 2007 08:45:58 -0500 From: "Aryeh Friedman" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: does this warrent a PR? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 13:46:00 -0000 First of all I know this deals with a port but the problem only appears on -current so I am asking here. devel/libtool15 does not correctly install (it places freebsd- as the version number for all libs) From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 13:49:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A194016A417 for ; Sun, 9 Dec 2007 13:49:39 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from galain.elvandar.org (galain.elvandar.org [217.148.169.56]) by mx1.freebsd.org (Postfix) with ESMTP id 68B1013C447 for ; Sun, 9 Dec 2007 13:49:39 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from evilcoder.xs4all.nl ([195.64.94.120] helo=elvandar.local) by galain.elvandar.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J1MXJ-000LLL-PH; Sun, 09 Dec 2007 14:49:37 +0100 Message-ID: <475BF295.1060509@FreeBSD.org> Date: Sun, 09 Dec 2007 14:50:13 +0100 From: Remko Lodder User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Aryeh Friedman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: does this warrent a PR? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 13:49:39 -0000 Aryeh Friedman wrote: > First of all I know this deals with a port but the problem only > appears on -current so I am asking here. > > devel/libtool15 does not correctly install (it places freebsd- as the > version number for all libs) > _______________________________________________ Eventhough this only occurs on current, i think we should ask the ports side for this. -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 16:06:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDA8416A419 for ; Sun, 9 Dec 2007 16:06:18 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id B3ABC13C46A for ; Sun, 9 Dec 2007 16:06:18 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from [216.89.228.170] (host-216-89-228-170.wireless.terranova.net [216.89.228.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTP id CEFCC29B61C; Sun, 9 Dec 2007 11:06:17 -0500 (EST) Message-ID: <475C1276.5010205@terranova.net> Date: Sun, 09 Dec 2007 11:06:14 -0500 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= , freebsd-current@freebsd.org References: <73807.10710.qm@web63912.mail.re1.yahoo.com> <200711280842.09340.jhb@freebsd.org> <474D726A.8080807@deepcore.dk> <200711280938.38545.jhb@freebsd.org> <474E5B69.7070406@yandex.ru> <474E65D6.4040403@deepcore.dk> <474E69AE.7000105@yandex.ru> <475978E1.2090507@deepcore.dk> <4759C63C.6070605@terranova.net> <4759E350.3090601@deepcore.dk> <475A04F3.8090701@terranova.net> <475AFF13.3030802@deepcore.dk> In-Reply-To: <475AFF13.3030802@deepcore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: Any successful installs on a Broadcom HT1000 chipset? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 16:06:19 -0000 Søren Schmidt wrote: > I'm there now, it even messes up the network packets when I hit the disk > a bit, showtime 8^) > > Anyhow I have a surefire way to reproduce here in the lab now, so I'll > crawl back under my rock and see if I can figure out whats wrong and how > to fix it.. > > later.... > > -Søren This is very good news! Myself and all of the afflicted ServerWorks/Broadcom HT1000 users wish you best of luck and happy hunting. From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 16:19:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A32216A417 for ; Sun, 9 Dec 2007 16:19:51 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0357713C4D9 for ; Sun, 9 Dec 2007 16:19:50 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5A69146EF6; Sun, 9 Dec 2007 11:19:50 -0500 (EST) Date: Sun, 9 Dec 2007 16:19:50 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Adrian Chadd In-Reply-To: Message-ID: <20071209161853.J71725@fledge.watson.org> References: <4756BAD3.4060905@web.de> <95938867@bb.ipt.ru> <200712060051.26294.joao@matik.com.br> <20071207101817.xcvz0wdi68cscwkg@neslonek.homeunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jan Lentfer , freebsd-current@freebsd.org, JoaoBR Subject: Re: Problems Building 7.0-Beta3 with -Os X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 16:19:51 -0000 On Sun, 9 Dec 2007, Adrian Chadd wrote: > On 07/12/2007, Jan Lentfer wrote: > >> On the other hand, why you want to optimzie the hell out of a 4-way 8-Gig >> Operton server or the like, for normal services you want feel too much >> difference here, because it is fast as hell anyway. > > Because sometimes "optimising the hell out of a large server" is the > difference between needing to buy 1 or 1.5 of said server. And this becomes even more of an argument when you're talking about 1000 or 1500 servers vs 2000 servers. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 19:42:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CBAB16A418 for ; Sun, 9 Dec 2007 19:42:40 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 24D6613C45A for ; Sun, 9 Dec 2007 19:42:39 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so3116624pyb for ; Sun, 09 Dec 2007 11:42: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:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type; bh=tT127C3/fcwoL0u+/7bWOqGeMyon3TZk77mFRJuzf5M=; b=aAUSW5p1O55gNXv4tBR7wUwEe02uA9E3Kmmp7PGhQk9EqpNGYZaZ+5GsbANgEg8q8WPcX7x0m9gv382BABPYBq89qf/4Dg2exTat9wF0NkkwqsmMtXLml5gj1aM5l437mWQleLJh1460mQMf/55w+PE0OVRgJs39FJEPCddVl5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type; b=TcXjh75GAFxNwEPrgJP7nxvKoZORQ+ZUpTgVX7DHzbBmKcELBHOfvWuykXFCPpr4Y8JKUx+I9vE9WJue5npXIo6NNNVe8AgJUARJHyn8csyXnyymwlIPcLp3RSzABrCKsjokY1O9SMK4+7NKovI8LiXRfsr17Rbg7mieUYtxSW4= Received: by 10.65.54.9 with SMTP id g9mr12176659qbk.1197229358129; Sun, 09 Dec 2007 11:42:38 -0800 (PST) Received: from ip4da3ae31.direct-adsl.nl.0.163.77.in-addr.arpa ( [77.163.174.49]) by mx.google.com with ESMTPS id f3sm3968897nfh.2007.12.09.11.42.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Dec 2007 11:42:36 -0800 (PST) Message-ID: <475C452A.4060502@gmail.com> Date: Sun, 09 Dec 2007 20:42:34 +0100 From: Rene Ladan User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <200712081728.18710.Thomas.Sparrevohn@btinternet.com> <475AD8DE.4080302@conducive.net> <200712082118.30268.Thomas.Sparrevohn@btinternet.com> In-Reply-To: <200712082118.30268.Thomas.Sparrevohn@btinternet.com> X-Enigmail-Version: 0.95.1 Content-Type: multipart/mixed; boundary="------------080601010503050902020007" Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 19:42:40 -0000 This is a multi-part message in MIME format. --------------080601010503050902020007 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Thomas Sparrevohn schreef: > On Saturday 08 December 2007 17:48:14 韓家暙 Bill Hacker wrote: >> Thomas Sparrevohn wrote: >>> Hi >>> >>> There something weird going on - at minimal workloads my system gets very >>> very hot - The system is watercooled, 4 Fan's etc its a quad core QX6700 - >>> make buildkernel - will make the fans run at highest speed (its impossibly to >>> be in the room at the same time). >>> >>> There are no problems when running other OS'es - Are anybody else having this >>> kind of problems (PS its a relatively new thing - maybe 2 weeks)? >> And 'top -S' reports what? >> > > I was trying to avoid to go back to running "pure UFS" again - but I guess I have to inorder > to eliminate ZFS as the potential source > On my Asus A6JE running todays HEAD, top -S -H -d 1 shows: last pid: 21503; load averages: 0.16, 0.12, 0.09 up 0+03:05:21 20:33:00 136 processes: 4 running, 113 sleeping, 19 waiting CPU states: % user, % nice, % system, % interrupt, % idle Mem: 217M Active, 253M Inact, 120M Wired, 19M Cache, 112M Buf, 1392M Free Swap: 4062M Total, 4062M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 root 171 ki31 0K 16K RUN 0 350:57 92.43% {idle: cpu0} 10 root 171 ki31 0K 16K RUN 1 350:57 86.52% {idle: cpu1} 889 rene 96 0 300M 42308K select 0 4:14 7.47% Xorg 975 rene 96 0 147M 92808K select 0 1:50 4.64% {initial thread} 928 rene 96 0 43704K 10208K select 1 1:13 0.05% xfce4-clipman-pl 950 rene 96 0 53760K 19772K select 0 0:09 0.05% Terminal 975 rene 97 0 147M 92808K ucond 1 1:50 0.00% {thunderbird-bin 975 rene 96 0 147M 92808K select 0 1:50 0.00% {thunderbird-bin 975 rene 96 0 147M 92808K ucond 0 1:50 0.00% {thunderbird-bin 975 rene 96 0 147M 92808K select 1 1:50 0.00% {thunderbird-bin 975 rene 96 0 147M 92808K select 0 1:50 0.00% {thunderbird-bin 975 rene 96 0 147M 92808K ucond 0 1:50 0.00% {thunderbird-bin 975 rene 96 0 147M 92808K ucond 0 1:50 0.00% {thunderbird-bin 975 rene 96 0 147M 92808K ucond 0 1:50 0.00% {thunderbird-bin 975 rene 96 0 147M 92808K ucond 0 1:50 0.00% {thunderbird-bin 930 rene 96 0 27408K 11076K select 0 1:24 0.00% xfce4-systemload root@ip4da3ae31:~# This is with UFS. sysctl hw.acpi.thermal shows: hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 70.0C hw.acpi.thermal.tz0.active: 0 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 95.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 105.0C hw.acpi.thermal.tz0._ACx: 60.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 The laptop is running idle, just running xfce4, some applets, and some desktop applications (thunderbird, firefox, pidgin). If I run boinc (einstein/seti/simap) from the ports on a few days old kernel, the temperature rises to 87C-92C, against 67C-72C when idle. At some point the cpus get too hot I guess, judging from a frozen console (the video card is still pushing out the screen image) and a hung ssh connection. Then only power cycling helps. kernel config and loader.conf are attached. Regards, Rene > >> FWIW - the opposite experience here. >> Core-2 Quad QX6600 on Asus and Gigabyte, Core-D dual on Tyan. >> >> Stock Intel cooler & fans, case fans on variable-speed MB connectors, PSU's with >> 'smart' fans. >> >> Fans run at nowhere near full-speed even with a long make -j 12. >> >> Under 'average load', not yet as quiet as my PowerBook G4, but getting close to >> our C3 MB with constant-speed fans. >> >> Something in the cooling water? Bacteria? Goldfish turds? >> >> Bill >> >> > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 --------------080601010503050902020007 Content-Type: text/plain; name="loader.conf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="loader.conf" bG9hZGVyX2xvZ289ImJlYXN0aWUiCmtlcm4ubWF4ZmlsZXM9IjI1MDAwIgpsZWdhbC5pbnRl bF93cGkubGljZW5zZV9hY2s9MQpyYW5kb21fbG9hZD0iWUVTIgphaGRfbG9hZD0iWUVTIgph aGNfbG9hZD0iWUVTIgphaGNfZWlzYV9sb2FkPSJZRVMiCmFoY19wY2lfbG9hZD0iWUVTIgph dGFkaXNrX2xvYWQ9IllFUyIKdWhpZF9sb2FkPSJZRVMiCm5nX3VidF9sb2FkPSJZRVMiCnNt YXBpX2xvYWQ9IllFUyIKdW1hc3NfbG9hZD0iWUVTIgptc2Rvc2ZzX2xvYWQ9IllFUyIKc3lz dnNobV9sb2FkPSJZRVMiCnN5c3Ztc2dfbG9hZD0iWUVTIgpzeXN2c2VtX2xvYWQ9IllFUyIK a2JkbXV4X2xvYWQ9IllFUyIKY2FyZGJ1c19sb2FkPSJZRVMiCnNpb19sb2FkPSJZRVMiCm1k X2xvYWQ9IllFUyIKaWZfdHVuX2xvYWQ9IllFUyIKaWZfZ2lmX2xvYWQ9IllFUyIKaWZfZmFp dGhfbG9hZD0iWUVTIgp1Z2VuX2xvYWQ9IllFUyIKdW1zX2xvYWQ9IllFUyIKbWlpYnVzX2xv YWQ9IllFUyIKYXRhcGljYW1fbG9hZD0iWUVTIgpzbWJ1c19sb2FkPSJZRVMiCnNtYl9sb2Fk PSJZRVMiCmljaHNtYl9sb2FkPSJZRVMiCmFjcGlfdmlkZW9fbG9hZD0iWUVTIgphdGFwaWNk X2xvYWQ9IllFUyIKc25kX2hkYV9sb2FkPSJZRVMiCnNwZWFrZXJfbG9hZD0iWUVTIgpsaWJp Y29udl9sb2FkPSJZRVMiCnVkZl9pY29udl9sb2FkPSJZRVMiCmNkOTY2MF9pY29udl9sb2Fk PSJZRVMiCmNiYl9sb2FkPSJZRVMiCnBjY2FyZF9sb2FkPSJZRVMiCndwaWZ3X2xvYWQ9IllF UyIKZmlyZXdpcmVfbG9hZD0iWUVTIgphY3BpX2FzdXNfbG9hZD0iWUVTIgp3bGFuX2xvYWQ9 IllFUyIKd2xhbl93ZXBfbG9hZD0iWUVTIgp3bGFuX2FtcnJfbG9hZD0iWUVTIgp3bGFuX3Nj YW5fc3RhX2xvYWQ9IllFUyIKd2xhbl9zY2FuX2FwX2xvYWQ9IllFUyIKZHJtX2xvYWQ9IllF UyIKdXNiX2xvYWQ9IllFUyIKI2lmX3dwaV9sb2FkPSJZRVMiCnNtYmlvc19sb2FkPSJZRVMi CmFjcGlfZG9ja19sb2FkPSJZRVMiCmNwdWZyZXFfbG9hZD0iWUVTIgpjb3JldGVtcF9sb2Fk PSJZRVMiCmlmX3JlX2xvYWQ9IllFUyIK --------------080601010503050902020007 Content-Type: text/plain; name="RENE.current" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="RENE.current" IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBG cmVlQlNEL2kzODYKIwojIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZmlsZSwgcGxl YXNlIHJlYWQgdGhlIGhhbmRib29rIHNlY3Rpb24gb24KIyBLZXJuZWwgQ29uZmlndXJhdGlv biBGaWxlczoKIwojICAgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvZG9jL2VuX1VTLklTTzg4 NTktMS9ib29rcy9oYW5kYm9vay9rZXJuZWxjb25maWctY29uZmlnLmh0bWwKIwojIFRoZSBo YW5kYm9vayBpcyBhbHNvIGF2YWlsYWJsZSBsb2NhbGx5IGluIC91c3Ivc2hhcmUvZG9jL2hh bmRib29rCiMgaWYgeW91J3ZlIGluc3RhbGxlZCB0aGUgZG9jIGRpc3RyaWJ1dGlvbiwgb3Ro ZXJ3aXNlIGFsd2F5cyBzZWUgdGhlCiMgRnJlZUJTRCBXb3JsZCBXaWRlIFdlYiBzZXJ2ZXIg KGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvKSBmb3IgdGhlCiMgbGF0ZXN0IGluZm9ybWF0aW9u LgojCiMgQW4gZXhoYXVzdGl2ZSBsaXN0IG9mIG9wdGlvbnMgYW5kIG1vcmUgZGV0YWlsZWQg ZXhwbGFuYXRpb25zIG9mIHRoZQojIGRldmljZSBsaW5lcyBpcyBhbHNvIHByZXNlbnQgaW4g dGhlIC4uLy4uL2NvbmYvTk9URVMgYW5kIE5PVEVTIGZpbGVzLgojIElmIHlvdSBhcmUgaW4g ZG91YnQgYXMgdG8gdGhlIHB1cnBvc2Ugb3IgbmVjZXNzaXR5IG9mIGEgbGluZSwgY2hlY2sg Zmlyc3QKIyBpbiBOT1RFUy4KIwoKbWFjaGluZQkJaTM4NgpjcHUJCUk2ODZfQ1BVCmlkZW50 CQlSRU5FCgojIFRvIHN0YXRpY2FsbHkgY29tcGlsZSBpbiBkZXZpY2Ugd2lyaW5nIGluc3Rl YWQgb2YgL2Jvb3QvZGV2aWNlLmhpbnRzCiNoaW50cwkJIkdFTkVSSUMuaGludHMiCQkjIERl ZmF1bHQgcGxhY2VzIHRvIGxvb2sgZm9yIGRldmljZXMuCgptYWtlb3B0aW9ucwlERUJVRz0t ZwkJIyBCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVidWcgc3ltYm9scwoKIyBEZWJ1Z2dp bmcgZm9yIHVzZSBpbiAtY3VycmVudApvcHRpb25zIAlLREIJCQkjIEVuYWJsZSBrZXJuZWwg ZGVidWdnZXIgc3VwcG9ydC4Kb3B0aW9ucyAJRERCCQkJIyBTdXBwb3J0IEREQi4Kb3B0aW9u cwkJS0RCX1RSQUNFCm9wdGlvbnMgCUdEQgkJCSMgU3VwcG9ydCByZW1vdGUgR0RCLgpvcHRp b25zIAlJTlZBUklBTlRTCQkjIEVuYWJsZSBjYWxscyBvZiBleHRyYSBzYW5pdHkgY2hlY2tp bmcKb3B0aW9ucyAJSU5WQVJJQU5UX1NVUFBPUlQJIyBFeHRyYSBzYW5pdHkgY2hlY2tzIG9m IGludGVybmFsIHN0cnVjdHVyZXMsIHJlcXVpcmVkIGJ5IElOVkFSSUFOVFMKb3B0aW9ucyAJ V0lUTkVTUwkJCSMgRW5hYmxlIGNoZWNrcyB0byBkZXRlY3QgZGVhZGxvY2tzIGFuZCBjeWNs ZXMKb3B0aW9ucyAJV0lUTkVTU19TS0lQU1BJTgkjIERvbid0IHJ1biB3aXRuZXNzIG9uIHNw aW5sb2NrcyBmb3Igc3BlZWQKCgojb3B0aW9ucyAJU0NIRURfVUxFCSMgQk9JTkM6IGxvYWQg YXZnLT40LCBzY2llbmNlIHByb2Nlc3NlcyBydW4gb25seSBhdCBuaWNlIDE5IGluc3RlYWQg b2YgaWRwcmlvIDMxLCBhbmQgc3RhcnZhdGlvbi0+cmVzdGFydCBvY2N1cnMgYW5kIGhpY2N1 cHM/Cm9wdGlvbnMJCVNDSEVEXzRCU0QJIyBzaWdoLi4uCm9wdGlvbnMgCVBSRUVNUFRJT04J CSMgRW5hYmxlIGtlcm5lbCB0aHJlYWQgcHJlZW1wdGlvbgpvcHRpb25zIAlJTkVUCQkJIyBJ bnRlck5FVHdvcmtpbmcKb3B0aW9ucyAJSU5FVDYJCQkjIElQdjYgY29tbXVuaWNhdGlvbnMg cHJvdG9jb2xzCm9wdGlvbnMgCUZGUwkJCSMgQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtCm9w dGlvbnMgCVNPRlRVUERBVEVTCQkjIEVuYWJsZSBGRlMgc29mdCB1cGRhdGVzIHN1cHBvcnQK b3B0aW9ucyAJVUZTX0FDTAkJCSMgU3VwcG9ydCBmb3IgYWNjZXNzIGNvbnRyb2wgbGlzdHMK b3B0aW9ucyAJVUZTX0RJUkhBU0gJCSMgSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGly ZWN0b3JpZXMKb3B0aW9ucyAJTURfUk9PVAkJCSMgTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBk ZXZpY2UKb3B0aW9ucyAJQ0Q5NjYwCQkJIyBJU08gOTY2MCBGaWxlc3lzdGVtCm9wdGlvbnMg CUNPTVBBVF80M1RUWQkJIyBDb21wYXRpYmxlIHdpdGggQlNEIDQuMyBbS0VFUCBUSElTIV0K b3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q1CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNENQpv cHRpb25zIAlDT01QQVRfRlJFRUJTRDYJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q2Cm9w dGlvbnMgCVNDU0lfREVMQVk9NTAwMAkJIyBEZWxheSAoaW4gbXMpIGJlZm9yZSBwcm9iaW5n IFNDU0kKb3B0aW9ucyAJS1RSQUNFCQkJIyBrdHJhY2UoMSkgc3VwcG9ydApvcHRpb25zIAlf S1BPU0lYX1BSSU9SSVRZX1NDSEVEVUxJTkcgIyBQT1NJWCBQMTAwM18xQiByZWFsLXRpbWUg ZXh0ZW5zaW9ucwpvcHRpb25zIAlLQkRfSU5TVEFMTF9DREVWCSMgaW5zdGFsbCBhIENERVYg ZW50cnkgaW4gL2RldgpvcHRpb25zIAlBSENfUkVHX1BSRVRUWV9QUklOVAkjIFByaW50IHJl Z2lzdGVyIGJpdGZpZWxkcyBpbiBkZWJ1ZwoJCQkJCSMgb3V0cHV0LiAgQWRkcyB+MTI4ayB0 byBkcml2ZXIuCm9wdGlvbnMgCUFIRF9SRUdfUFJFVFRZX1BSSU5UCSMgUHJpbnQgcmVnaXN0 ZXIgYml0ZmllbGRzIGluIGRlYnVnCgkJCQkJIyBvdXRwdXQuICBBZGRzIH4yMTVrIHRvIGRy aXZlci4Kb3B0aW9ucwkJU01QCQkJIyBEdWFsIGNvcmUgVDU2MDAKZGV2aWNlCQlhcGljCQkJ IyBJL08gQVBJQwpvcHRpb25zCQlTVE9QX05NSQkJIyBzdG9wIENQVXMgd2l0aCBOTUkgaW5z dGVhZCBvZiBJUEkKCm9wdGlvbnMJCU1QVEFCTEVfRk9SQ0VfSFRUCm9wdGlvbnMJCUlQSV9Q UkVFTVBUSU9OCgojIEJ1cyBzdXBwb3J0LgpkZXZpY2UJCXBjaQoKIyBBVEEgYW5kIEFUQVBJ IGRldmljZXMKZGV2aWNlCQlhdGEJCSMgYXMgbW9kdWxlID8gIyBwYW5pYyB3aXRob3V0PwoK IyBTQ1NJIHBlcmlwaGVyYWxzCmRldmljZQkJc2NidXMJCSMgU0NTSSBidXMgKHJlcXVpcmVk IGZvciBTQ1NJKQpkZXZpY2UJCWRhCQkjIERpcmVjdCBBY2Nlc3MgKGRpc2tzKQpkZXZpY2UJ CWNkCQkjIENECmRldmljZQkJcGFzcwkJIyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRpcmVjdCBT Q1NJIGFjY2VzcykKCiMgYXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQg dGhlIFBTLzIgbW91c2UKZGV2aWNlCQlhdGtiZGMJCSMgQVQga2V5Ym9hcmQgY29udHJvbGxl cgpkZXZpY2UJCWF0a2JkCQkjIEFUIGtleWJvYXJkCmRldmljZQkJcHNtCQkjIFBTLzIgbW91 c2UKCmRldmljZQkJdmdhCQkjIFZHQSB2aWRlbyBjYXJkIGRyaXZlcgoKZGV2aWNlCQlzcGxh c2gJCSMgU3BsYXNoIHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQKCiMgc3lzY29u cyBpcyB0aGUgZGVmYXVsdCBjb25zb2xlIGRyaXZlciwgcmVzZW1ibGluZyBhbiBTQ08gY29u c29sZQpkZXZpY2UJCXNjCgpkZXZpY2UJCWFncAkJIyBuZWVkZWQgdG8gbWFrZSBkcm0gY29t cGlsZQpkZXZpY2UJCWRybQoKIyBBZGQgc3VzcGVuZC9yZXN1bWUgc3VwcG9ydCBmb3IgdGhl IGk4MjU0LgpkZXZpY2UJCXBtdGltZXIKCiMgUHNldWRvIGRldmljZXMuCmRldmljZQkJbG9v cAkJIyBOZXR3b3JrIGxvb3BiYWNrCmRldmljZQkJZXRoZXIJCSMgRXRoZXJuZXQgc3VwcG9y dApkZXZpY2UJCXB0eQkJIyBQc2V1ZG8tdHR5cyAodGVsbmV0IGV0YykKCiMgVGhlIGBicGYn IGRldmljZSBlbmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQgRmlsdGVyLgojIEJlIGF3YXJl IG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyEK IyBOb3RlIHRoYXQgJ2JwZicgaXMgcmVxdWlyZWQgZm9yIERIQ1AuCmRldmljZQkJYnBmCQkj IEJlcmtlbGV5IHBhY2tldCBmaWx0ZXIKCiNhZGRlZApvcHRpb25zCQlERVZJQ0VfUE9MTElO RwoKI2V4cGVyaW1lbnRhbApkZXZpY2UJCW1tYwpkZXZpY2UJCW1tY3NkCgpvcHRpb25zCQlI V1BNQ19IT09LUwpkZXZpY2UJCWh3cG1jCgo= --------------080601010503050902020007-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 21:55:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CD9E16A41A for ; Sun, 9 Dec 2007 21:55:37 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2666B13C468 for ; Sun, 9 Dec 2007 21:55:36 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J1U5E-00008C-Mf for freebsd-current@freebsd.org; Sun, 09 Dec 2007 21:53:08 +0000 Received: from 78-0-75-192.adsl.net.t-com.hr ([78.0.75.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 09 Dec 2007 21:53:08 +0000 Received: from ivoras by 78-0-75-192.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 09 Dec 2007 21:53:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sun, 09 Dec 2007 22:51:05 +0100 Lines: 29 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1CDC93F7E4C366288A5D2A63" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-75-192.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) X-Enigmail-Version: 0.95.5 Sender: news Cc: freebsd-doc@freebsd.org Subject: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 21:55:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1CDC93F7E4C366288A5D2A63 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I've started a page with the intention of enumerating small errors or annoyances of RELENG_7: http://www.sharanet.org/%7Eivoras/freebsd/freebsd7-nags.html. I'm posting the link here as it might be useful to people compiling Release Notes or Errata documents for 7.0. --------------enig1CDC93F7E4C366288A5D2A63 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 iD8DBQFHXGNSldnAQVacBcgRAqu+AJ0cY7NlxDRqwImFB+MncQE9jji/TQCdGdD+ BUPH4M+JC6tBz6NOFg/g450= =lm7U -----END PGP SIGNATURE----- --------------enig1CDC93F7E4C366288A5D2A63-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 22:15:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 217BA16A419; Sun, 9 Dec 2007 22:15:54 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id CED1313C465; Sun, 9 Dec 2007 22:15:53 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from sp34.ipt.ru ([194.62.233.107] helo=bs1.sp34.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1J1URE-000Byy-2j; Mon, 10 Dec 2007 01:15:52 +0300 Received: from bsam by bs1.sp34.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1J1UUp-0001lv-PM; Mon, 10 Dec 2007 01:19:35 +0300 To: josh.carroll@gmail.com References: <97676449@bb.ipt.ru> <3bbf2fe10712062309j7c49aef7g9a5cfa6e2a52158c@mail.gmail.com> <53021179@bb.ipt.ru> <8cb6106e0712081413uc58f836w611b99ab0a536a4a@mail.gmail.com> From: Boris Samorodov Date: Mon, 10 Dec 2007 01:19:35 +0300 In-Reply-To: <8cb6106e0712081413uc58f836w611b99ab0a536a4a@mail.gmail.com> (Josh Carroll's message of "Sat, 8 Dec 2007 17:13:14 -0500") Message-ID: <31551976@bs1.sp34.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: sockstat: struct xtcpcb size mismatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 22:15:54 -0000 On Sat, 8 Dec 2007 17:13:14 -0500 Josh Carroll wrote: > > Thanks for the answer. And sorry, I can't understand what to do > > further. Is it by design and should stay so or should it be fixed? > > > > BTW, RELENG_7 behaves the same way. And "netstat -a" is broken: > Your world and kernel are out of sync. I would recommend a > buildworld/installworld and building a new kernel. That should do the > trick. I wish you were right. Fresh cvsup to RELENG_7, buildworld (after make clean twice), make kernel, install world, mergemaster. The kernel config (diff from GENERIC shown later) doesn't work. If "options LOCK_PROFILING" is removed and the kernel is rebuilt, all goes well. The bad case: ----- bb% uname -a FreeBSD bb.ipt.ru 7.0-BETA4 FreeBSD 7.0-BETA4 #15: Mon Dec 10 00:24:50 MSK 2007 root@bb.ipt.ru:/usr/obj/usr/src/sys/BB i386 bb% netstat -a | head Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr 0 #0 1 0 0 8aee8d00 0 0 0 #0 1 0 0 8aee8c30 0 0 0 #0 1 0 0 8aee9000 0 0 0 #0 1 0 0 8aee8ea0 0 0 0 #0 1 0 0 88636410 0 0 0 #0 1 0 0 88636340 0 0 0 #0 1 0 0 880d5a90 0 0 0 #0 1 0 0 880d59c0 0 0 bb% sysctl debug.lock.prof debug.lock.prof.stats: No locking recorded debug.lock.prof.collisions: 0 debug.lock.prof.hashsize: 4096 debug.lock.prof.rejected: 0 debug.lock.prof.maxrecords: 4096 debug.lock.prof.records: 0 debug.lock.prof.acquisitions: 0 debug.lock.prof.enable: 0 bb% cat /sys/i386/conf/GENERIC-BB.diff --- GENERIC 2007-10-11 10:20:26.000000000 +0400 +++ BB 2007-12-09 23:09:39.000000000 +0300 @@ -21,14 +21,14 @@ cpu I486_CPU cpu I586_CPU cpu I686_CPU -ident GENERIC +ident BB # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols -options SCHED_4BSD # 4BSD scheduler +options SCHED_ULE options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols @@ -302,3 +302,17 @@ device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons + +options SHMMAXPGS=65536 +options SEMMNI=40 +options SEMMNS=240 +options SEMUME=40 +options SEMMNU=120 + +options IPFIREWALL +options IPFIREWALL_VERBOSE +options IPFIREWALL_VERBOSE_LIMIT=100 +options IPFIREWALL_DEFAULT_TO_ACCEPT + +options KVA_PAGES=512 +options LOCK_PROFILING ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 22:29:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2DFC16A418; Sun, 9 Dec 2007 22:29:31 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-70484.0x50a6c9a6.abnxx16.customer.tele.dk [80.166.201.166]) by mx1.freebsd.org (Postfix) with ESMTP id A671513C45A; Sun, 9 Dec 2007 22:29:30 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from ws.local (ws.deepcore.dk [194.192.25.137]) by spider.deepcore.dk (8.13.8/8.13.8) with ESMTP id lB9MTIkb077723; Sun, 9 Dec 2007 23:29:18 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <475C6C3E.6070004@deepcore.dk> Date: Sun, 09 Dec 2007 23:29:18 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <73807.10710.qm@web63912.mail.re1.yahoo.com> <200711280842.09340.jhb@freebsd.org> <474D726A.8080807@deepcore.dk> <200711280938.38545.jhb@freebsd.org> <474E5B69.7070406@yandex.ru> <474E65D6.4040403@deepcore.dk> <474E69AE.7000105@yandex.ru> <475978E1.2090507@deepcore.dk> In-Reply-To: <475978E1.2090507@deepcore.dk> Content-Type: multipart/mixed; boundary="------------020200020504060708080606" Cc: Barney Cordoba , Travis Mikalson , freebsd-current@freebsd.org, Anton Yuzhaninov Subject: Re: Any successful installs on a Broadcom HT1000 chipset? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 22:29:31 -0000 This is a multi-part message in MIME format. --------------020200020504060708080606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable OK, so I found at least one problem with the HT1000, its sometimes=20 doesn't handle 128 sector transfers correctly, its DMA engine looses its = wits. The result is that it just messes up completely and barfs data all over=20 the place on the next read operation. Anyhow the attached patch seems to work around the problem by limitting=20 transfer to a max of 126 sectors in one go, at least I have move several = hundred Gb's around now on a zfs volume without problems, which=20 certainly wasn't possible before. Let me know how this turns out for you! Patch is against a clean RELENG_7 as last time, should fit both RELENG_6 = and -current... -S=F8ren --------------020200020504060708080606 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="swks-p2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="swks-p2" Index: ata-all.h =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-all.h,v retrieving revision 1.124.2.1 diff -u -r1.124.2.1 ata-all.h --- ata-all.h 21 Nov 2007 21:15:00 -0000 1.124.2.1 +++ ata-all.h 9 Dec 2007 22:15:29 -0000 @@ -464,6 +464,8 @@ int (*begin_transaction)(struct ata_request *request); int (*end_transaction)(struct ata_request *request); int (*command)(struct ata_request *request); + void (*tf_read)(struct ata_request *request); + void (*tf_write)(struct ata_request *request); }; /* structure holding resources for an ATA channel */ Index: ata-chipset.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v retrieving revision 1.202.2.4 diff -u -r1.202.2.4 ata-chipset.c --- ata-chipset.c 7 Dec 2007 17:58:55 -0000 1.202.2.4 +++ ata-chipset.c 9 Dec 2007 22:15:29 -0000 @@ -98,7 +98,7 @@ static void ata_intel_new_setmode(device_t dev, int mode); static int ata_intel_31244_allocate(device_t dev); static int ata_intel_31244_status(device_t dev); -static int ata_intel_31244_command(struct ata_request *request); +static void ata_intel_31244_tf_write(struct ata_request *request); static void ata_intel_31244_reset(device_t dev); static int ata_ite_chipinit(device_t dev); static void ata_ite_setmode(device_t dev, int mode); @@ -151,6 +151,8 @@ static void ata_promise_next_hpkt(struct ata_pci_controller *ctlr); static int ata_serverworks_chipinit(device_t dev); static int ata_serverworks_allocate(device_t dev); +static void ata_serverworks_tf_read(struct ata_request *request); +static void ata_serverworks_tf_write(struct ata_request *request); static void ata_serverworks_setmode(device_t dev, int mode); static int ata_sii_chipinit(device_t dev); static int ata_cmd_allocate(device_t dev); @@ -2044,7 +2046,7 @@ ch->flags |= ATA_NO_SLAVE; ata_pci_hw(dev); ch->hw.status = ata_intel_31244_status; - ch->hw.command = ata_intel_31244_command; + ch->hw.tf_write = ata_intel_31244_tf_write; /* enable PHY state change interrupt */ ATA_OUTL(ctlr->r_res2, 0x4, @@ -2062,32 +2064,55 @@ return ata_pci_status(dev); } -static int -ata_intel_31244_command(struct ata_request *request) +static void +ata_intel_31244_tf_write(struct ata_request *request) { struct ata_channel *ch = device_get_softc(device_get_parent(request->dev)); struct ata_device *atadev = device_get_softc(request->dev); - u_int64_t lba; - - if (!(atadev->flags & ATA_D_48BIT_ACTIVE)) - return (ata_generic_command(request)); - - lba = request->u.ata.lba; - ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_IBM | ATA_D_LBA | atadev->unit); - /* enable interrupt */ - ATA_IDX_OUTB(ch, ATA_CONTROL, ATA_A_4BIT); - ATA_IDX_OUTW(ch, ATA_FEATURE, request->u.ata.feature); - ATA_IDX_OUTW(ch, ATA_COUNT, request->u.ata.count); - ATA_IDX_OUTW(ch, ATA_SECTOR, ((lba >> 16) & 0xff00) | (lba & 0x00ff)); - ATA_IDX_OUTW(ch, ATA_CYL_LSB, ((lba >> 24) & 0xff00) | - ((lba >> 8) & 0x00ff)); - ATA_IDX_OUTW(ch, ATA_CYL_MSB, ((lba >> 32) & 0xff00) | - ((lba >> 16) & 0x00ff)); - /* issue command to controller */ - ATA_IDX_OUTB(ch, ATA_COMMAND, request->u.ata.command); - - return 0; + if (atadev->flags & ATA_D_48BIT_ACTIVE) { + ATA_IDX_OUTW(ch, ATA_FEATURE, request->u.ata.feature); + ATA_IDX_OUTW(ch, ATA_COUNT, request->u.ata.count); + ATA_IDX_OUTW(ch, ATA_SECTOR, ((request->u.ata.lba >> 16) & 0xff00) | + (request->u.ata.lba & 0x00ff)); + ATA_IDX_OUTW(ch, ATA_CYL_LSB, ((request->u.ata.lba >> 24) & 0xff00) | + ((request->u.ata.lba >> 8) & 0x00ff)); + ATA_IDX_OUTW(ch, ATA_CYL_MSB, ((request->u.ata.lba >> 32) & 0xff00) | + ((request->u.ata.lba >> 16) & 0x00ff)); + ATA_IDX_OUTW(ch, ATA_DRIVE, ATA_D_LBA | atadev->unit); + } + else { + ATA_IDX_OUTB(ch, ATA_FEATURE, request->u.ata.feature); + ATA_IDX_OUTB(ch, ATA_COUNT, request->u.ata.count); + if (atadev->flags & ATA_D_USE_CHS) { + int heads, sectors; + + if (atadev->param.atavalid & ATA_FLAG_54_58) { + heads = atadev->param.current_heads; + sectors = atadev->param.current_sectors; + } + else { + heads = atadev->param.heads; + sectors = atadev->param.sectors; + } + ATA_IDX_OUTB(ch, ATA_SECTOR, (request->u.ata.lba % sectors)+1); + ATA_IDX_OUTB(ch, ATA_CYL_LSB, + (request->u.ata.lba / (sectors * heads))); + ATA_IDX_OUTB(ch, ATA_CYL_MSB, + (request->u.ata.lba / (sectors * heads)) >> 8); + ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_IBM | atadev->unit | + (((request->u.ata.lba% (sectors * heads)) / + sectors) & 0xf)); + } + else { + ATA_IDX_OUTB(ch, ATA_SECTOR, request->u.ata.lba); + ATA_IDX_OUTB(ch, ATA_CYL_LSB, request->u.ata.lba >> 8); + ATA_IDX_OUTB(ch, ATA_CYL_MSB, request->u.ata.lba >> 16); + ATA_IDX_OUTB(ch, ATA_DRIVE, + ATA_D_IBM | ATA_D_LBA | atadev->unit | + ((request->u.ata.lba >> 24) & 0x0f)); + } + } } static void @@ -4199,10 +4224,96 @@ ch->flags |= ATA_NO_SLAVE; ata_pci_hw(dev); + ch->hw.tf_read = ata_serverworks_tf_read; + ch->hw.tf_write = ata_serverworks_tf_write; + + //ch->dma->alignment = 16; + ch->dma->max_iosize = 126 * DEV_BSIZE; + return 0; } static void +ata_serverworks_tf_read(struct ata_request *request) +{ + struct ata_channel *ch = device_get_softc(device_get_parent(request->dev)); + struct ata_device *atadev = device_get_softc(request->dev); + + if (atadev->flags & ATA_D_48BIT_ACTIVE) { + u_int16_t temp; + + request->u.ata.count = ATA_IDX_INW(ch, ATA_COUNT); + temp = ATA_IDX_INW(ch, ATA_SECTOR); + request->u.ata.lba = (u_int64_t)(temp & 0x00ff) | + ((u_int64_t)(temp & 0xff00) << 24); + temp = ATA_IDX_INW(ch, ATA_CYL_LSB); + request->u.ata.lba |= ((u_int64_t)(temp & 0x00ff) << 8) | + ((u_int64_t)(temp & 0xff00) << 32); + temp = ATA_IDX_INW(ch, ATA_CYL_MSB); + request->u.ata.lba |= ((u_int64_t)(temp & 0x00ff) << 16) | + ((u_int64_t)(temp & 0xff00) << 40); + } + else { + request->u.ata.count = ATA_IDX_INW(ch, ATA_COUNT) & 0x00ff; + request->u.ata.lba = (ATA_IDX_INW(ch, ATA_SECTOR) & 0x00ff) | + ((ATA_IDX_INW(ch, ATA_CYL_LSB) & 0x00ff) << 8) | + ((ATA_IDX_INW(ch, ATA_CYL_MSB) & 0x00ff) << 16) | + ((ATA_IDX_INW(ch, ATA_DRIVE) & 0xf) << 24); + } +} + +static void +ata_serverworks_tf_write(struct ata_request *request) +{ + struct ata_channel *ch = device_get_softc(device_get_parent(request->dev)); + struct ata_device *atadev = device_get_softc(request->dev); + + if (atadev->flags & ATA_D_48BIT_ACTIVE) { + ATA_IDX_OUTW(ch, ATA_FEATURE, request->u.ata.feature); + ATA_IDX_OUTW(ch, ATA_COUNT, request->u.ata.count); + ATA_IDX_OUTW(ch, ATA_SECTOR, ((request->u.ata.lba >> 16) & 0xff00) | + (request->u.ata.lba & 0x00ff)); + ATA_IDX_OUTW(ch, ATA_CYL_LSB, ((request->u.ata.lba >> 24) & 0xff00) | + ((request->u.ata.lba >> 8) & 0x00ff)); + ATA_IDX_OUTW(ch, ATA_CYL_MSB, ((request->u.ata.lba >> 32) & 0xff00) | + ((request->u.ata.lba >> 16) & 0x00ff)); + ATA_IDX_OUTW(ch, ATA_DRIVE, ATA_D_LBA | atadev->unit); + } + else { + ATA_IDX_OUTW(ch, ATA_FEATURE, request->u.ata.feature); + ATA_IDX_OUTW(ch, ATA_COUNT, request->u.ata.count); + if (atadev->flags & ATA_D_USE_CHS) { + int heads, sectors; + + if (atadev->param.atavalid & ATA_FLAG_54_58) { + heads = atadev->param.current_heads; + sectors = atadev->param.current_sectors; + } + else { + heads = atadev->param.heads; + sectors = atadev->param.sectors; + } + ATA_IDX_OUTW(ch, ATA_SECTOR, (request->u.ata.lba % sectors)+1); + ATA_IDX_OUTW(ch, ATA_CYL_LSB, + (request->u.ata.lba / (sectors * heads))); + ATA_IDX_OUTW(ch, ATA_CYL_MSB, + (request->u.ata.lba / (sectors * heads)) >> 8); + ATA_IDX_OUTW(ch, ATA_DRIVE, ATA_D_IBM | atadev->unit | + (((request->u.ata.lba% (sectors * heads)) / + sectors) & 0xf)); + } + else { + ATA_IDX_OUTW(ch, ATA_SECTOR, request->u.ata.lba); + ATA_IDX_OUTW(ch, ATA_CYL_LSB, request->u.ata.lba >> 8); + ATA_IDX_OUTW(ch, ATA_CYL_MSB, request->u.ata.lba >> 16); + ATA_IDX_OUTW(ch, ATA_DRIVE, + ATA_D_IBM | ATA_D_LBA | atadev->unit | + ((request->u.ata.lba >> 24) & 0x0f)); + } + } +} + +static void ata_serverworks_setmode(device_t dev, int mode) { device_t gparent = GRANDPARENT(dev); Index: ata-lowlevel.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-lowlevel.c,v retrieving revision 1.79 diff -u -r1.79 ata-lowlevel.c --- ata-lowlevel.c 6 Apr 2007 16:18:59 -0000 1.79 +++ ata-lowlevel.c 9 Dec 2007 22:15:29 -0000 @@ -50,6 +50,8 @@ static int ata_wait(struct ata_channel *ch, struct ata_device *, u_int8_t); static void ata_pio_read(struct ata_request *, int); static void ata_pio_write(struct ata_request *, int); +static void ata_tf_read(struct ata_request *); +static void ata_tf_write(struct ata_request *); /* * low level ATA functions @@ -63,6 +65,8 @@ ch->hw.end_transaction = ata_end_transaction; ch->hw.status = ata_generic_status; ch->hw.command = ata_generic_command; + ch->hw.tf_read = ata_tf_read; + ch->hw.tf_write = ata_tf_write; } /* must be called with ATA channel locked and state_mtx held */ @@ -244,28 +248,7 @@ /* on control commands read back registers to the request struct */ if (request->flags & ATA_R_CONTROL) { - if (atadev->flags & ATA_D_48BIT_ACTIVE) { - ATA_IDX_OUTB(ch, ATA_CONTROL, ATA_A_4BIT | ATA_A_HOB); - request->u.ata.count = (ATA_IDX_INB(ch, ATA_COUNT) << 8); - request->u.ata.lba = - ((u_int64_t)(ATA_IDX_INB(ch, ATA_SECTOR)) << 24) | - ((u_int64_t)(ATA_IDX_INB(ch, ATA_CYL_LSB)) << 32) | - ((u_int64_t)(ATA_IDX_INB(ch, ATA_CYL_MSB)) << 40); - - ATA_IDX_OUTB(ch, ATA_CONTROL, ATA_A_4BIT); - request->u.ata.count |= ATA_IDX_INB(ch, ATA_COUNT); - request->u.ata.lba |= - (ATA_IDX_INB(ch, ATA_SECTOR) | - (ATA_IDX_INB(ch, ATA_CYL_LSB) << 8) | - (ATA_IDX_INB(ch, ATA_CYL_MSB) << 16)); - } - else { - request->u.ata.count = ATA_IDX_INB(ch, ATA_COUNT); - request->u.ata.lba = ATA_IDX_INB(ch, ATA_SECTOR) | - (ATA_IDX_INB(ch, ATA_CYL_LSB) << 8) | - (ATA_IDX_INB(ch, ATA_CYL_MSB) << 16) | - ((ATA_IDX_INB(ch, ATA_DRIVE) & 0xf) << 24); - } + ch->hw.tf_read(request); } /* if we got an error we are done with the HW */ @@ -734,57 +717,96 @@ ATA_PROTO_ATAPI_12 ? 6 : 8); } else { - if (atadev->flags & ATA_D_48BIT_ACTIVE) { - ATA_IDX_OUTB(ch, ATA_FEATURE, request->u.ata.feature >> 8); - ATA_IDX_OUTB(ch, ATA_FEATURE, request->u.ata.feature); - ATA_IDX_OUTB(ch, ATA_COUNT, request->u.ata.count >> 8); - ATA_IDX_OUTB(ch, ATA_COUNT, request->u.ata.count); - ATA_IDX_OUTB(ch, ATA_SECTOR, request->u.ata.lba >> 24); - ATA_IDX_OUTB(ch, ATA_SECTOR, request->u.ata.lba); - ATA_IDX_OUTB(ch, ATA_CYL_LSB, request->u.ata.lba >> 32); - ATA_IDX_OUTB(ch, ATA_CYL_LSB, request->u.ata.lba >> 8); - ATA_IDX_OUTB(ch, ATA_CYL_MSB, request->u.ata.lba >> 40); - ATA_IDX_OUTB(ch, ATA_CYL_MSB, request->u.ata.lba >> 16); - ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_LBA | atadev->unit); - } - else { - ATA_IDX_OUTB(ch, ATA_FEATURE, request->u.ata.feature); - ATA_IDX_OUTB(ch, ATA_COUNT, request->u.ata.count); - if (atadev->flags & ATA_D_USE_CHS) { - int heads, sectors; + ch->hw.tf_write(request); + + /* issue command to controller */ + ATA_IDX_OUTB(ch, ATA_COMMAND, request->u.ata.command); + } + return 0; +} + +static void +ata_tf_read(struct ata_request *request) +{ + struct ata_channel *ch = device_get_softc(device_get_parent(request->dev)); + struct ata_device *atadev = device_get_softc(request->dev); + + if (atadev->flags & ATA_D_48BIT_ACTIVE) { + ATA_IDX_OUTB(ch, ATA_CONTROL, ATA_A_4BIT | ATA_A_HOB); + request->u.ata.count = (ATA_IDX_INB(ch, ATA_COUNT) << 8); + request->u.ata.lba = + ((u_int64_t)(ATA_IDX_INB(ch, ATA_SECTOR)) << 24) | + ((u_int64_t)(ATA_IDX_INB(ch, ATA_CYL_LSB)) << 32) | + ((u_int64_t)(ATA_IDX_INB(ch, ATA_CYL_MSB)) << 40); + + ATA_IDX_OUTB(ch, ATA_CONTROL, ATA_A_4BIT); + request->u.ata.count |= ATA_IDX_INB(ch, ATA_COUNT); + request->u.ata.lba |= + (ATA_IDX_INB(ch, ATA_SECTOR) | + (ATA_IDX_INB(ch, ATA_CYL_LSB) << 8) | + (ATA_IDX_INB(ch, ATA_CYL_MSB) << 16)); + } + else { + request->u.ata.count = ATA_IDX_INB(ch, ATA_COUNT); + request->u.ata.lba = ATA_IDX_INB(ch, ATA_SECTOR) | + (ATA_IDX_INB(ch, ATA_CYL_LSB) << 8) | + (ATA_IDX_INB(ch, ATA_CYL_MSB) << 16) | + ((ATA_IDX_INB(ch, ATA_DRIVE) & 0xf) << 24); + } +} + +static void +ata_tf_write(struct ata_request *request) +{ + struct ata_channel *ch = device_get_softc(device_get_parent(request->dev)); + struct ata_device *atadev = device_get_softc(request->dev); + + if (atadev->flags & ATA_D_48BIT_ACTIVE) { + ATA_IDX_OUTB(ch, ATA_FEATURE, request->u.ata.feature >> 8); + ATA_IDX_OUTB(ch, ATA_FEATURE, request->u.ata.feature); + ATA_IDX_OUTB(ch, ATA_COUNT, request->u.ata.count >> 8); + ATA_IDX_OUTB(ch, ATA_COUNT, request->u.ata.count); + ATA_IDX_OUTB(ch, ATA_SECTOR, request->u.ata.lba >> 24); + ATA_IDX_OUTB(ch, ATA_SECTOR, request->u.ata.lba); + ATA_IDX_OUTB(ch, ATA_CYL_LSB, request->u.ata.lba >> 32); + ATA_IDX_OUTB(ch, ATA_CYL_LSB, request->u.ata.lba >> 8); + ATA_IDX_OUTB(ch, ATA_CYL_MSB, request->u.ata.lba >> 40); + ATA_IDX_OUTB(ch, ATA_CYL_MSB, request->u.ata.lba >> 16); + ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_LBA | atadev->unit); + } + else { + ATA_IDX_OUTB(ch, ATA_FEATURE, request->u.ata.feature); + ATA_IDX_OUTB(ch, ATA_COUNT, request->u.ata.count); + if (atadev->flags & ATA_D_USE_CHS) { + int heads, sectors; - if (atadev->param.atavalid & ATA_FLAG_54_58) { - heads = atadev->param.current_heads; - sectors = atadev->param.current_sectors; - } - else { - heads = atadev->param.heads; - sectors = atadev->param.sectors; - } - ATA_IDX_OUTB(ch, ATA_SECTOR, (request->u.ata.lba % sectors)+1); - ATA_IDX_OUTB(ch, ATA_CYL_LSB, - (request->u.ata.lba / (sectors * heads))); - ATA_IDX_OUTB(ch, ATA_CYL_MSB, - (request->u.ata.lba / (sectors * heads)) >> 8); - ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_IBM | atadev->unit | - (((request->u.ata.lba% (sectors * heads)) / - sectors) & 0xf)); + if (atadev->param.atavalid & ATA_FLAG_54_58) { + heads = atadev->param.current_heads; + sectors = atadev->param.current_sectors; } else { - ATA_IDX_OUTB(ch, ATA_SECTOR, request->u.ata.lba); - ATA_IDX_OUTB(ch, ATA_CYL_LSB, request->u.ata.lba >> 8); - ATA_IDX_OUTB(ch, ATA_CYL_MSB, request->u.ata.lba >> 16); - ATA_IDX_OUTB(ch, ATA_DRIVE, - ATA_D_IBM | ATA_D_LBA | atadev->unit | - ((request->u.ata.lba >> 24) & 0x0f)); + heads = atadev->param.heads; + sectors = atadev->param.sectors; } - } - /* issue command to controller */ - ATA_IDX_OUTB(ch, ATA_COMMAND, request->u.ata.command); + ATA_IDX_OUTB(ch, ATA_SECTOR, (request->u.ata.lba % sectors)+1); + ATA_IDX_OUTB(ch, ATA_CYL_LSB, + (request->u.ata.lba / (sectors * heads))); + ATA_IDX_OUTB(ch, ATA_CYL_MSB, + (request->u.ata.lba / (sectors * heads)) >> 8); + ATA_IDX_OUTB(ch, ATA_DRIVE, ATA_D_IBM | atadev->unit | + (((request->u.ata.lba% (sectors * heads)) / + sectors) & 0xf)); + } + else { + ATA_IDX_OUTB(ch, ATA_SECTOR, request->u.ata.lba); + ATA_IDX_OUTB(ch, ATA_CYL_LSB, request->u.ata.lba >> 8); + ATA_IDX_OUTB(ch, ATA_CYL_MSB, request->u.ata.lba >> 16); + ATA_IDX_OUTB(ch, ATA_DRIVE, + ATA_D_IBM | ATA_D_LBA | atadev->unit | + ((request->u.ata.lba >> 24) & 0x0f)); + } } - - return 0; } static void --------------020200020504060708080606-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 23:50:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4549216A417; Sun, 9 Dec 2007 23:50:36 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB7F13C458; Sun, 9 Dec 2007 23:50:35 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup156.ach.sch.gr [81.186.70.156]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id lB9NniEg003274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Dec 2007 01:49:55 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id lB9Nnh4Q000413; Mon, 10 Dec 2007 01:49:43 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id lB9Nnhit000412; Mon, 10 Dec 2007 01:49:43 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 10 Dec 2007 01:49:43 +0200 From: Giorgos Keramidas To: Ivan Voras Message-ID: <20071209234943.GB2112@kobe.laptop> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.949, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.45, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-doc@freebsd.org, freebsd-current@freebsd.org Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 23:50:36 -0000 On 2007-12-09 22:51, Ivan Voras wrote: > Hi, > I've started a page with the intention of enumerating small errors or > annoyances of RELENG_7: > > http://www.sharanet.org/%7Eivoras/freebsd/freebsd7-nags.html > > I'm posting the link here as it might be useful to people compiling > Release Notes or Errata documents for 7.0. Nice page. Some of the features which are new in 7.0 will certainly need at least a bit of `love and care', so their release notes are useful. Some of these are in the PEBKAC range of problems, though, i.e.: => tmpfs and fstab/fsck errors Since tmpfs /tmp is a memory file system, which is created from scratch every time, it makes no sense to fsck it on boot. => SCTP depends on IPv6 This is clearly documented in NOTES. I don't think it should count as a surprising fact. From owner-freebsd-current@FreeBSD.ORG Sun Dec 9 23:54:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97FB916A469 for ; Sun, 9 Dec 2007 23:54:51 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6B47313C455 for ; Sun, 9 Dec 2007 23:54:51 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1551964rvb for ; Sun, 09 Dec 2007 15:54:51 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=0CUhV3gpBDcjX15ZQ1nMmqaxx7y6YFh7IKtj5jKdoAE=; b=JTBS04vmGaBjjz03ktjP/iDZukDJFvX5TYzqT7ouy0k2BuQzNK/YJdEXipRgE8nCV5flad2qqRB0/MAS9tbtZAcVuR5wlsQrAhCUl0iHGcEzSH5leMhnr4OVRlYKuFXnqspR4cUBgN6Mg0/FxMwg7UGj/F0fU1Wfy03Hyxcuk3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=hoke006fL6135tq7T1Gf01kWz7VA1h3JIAzhrOigkDBsCMjCjDn3bV5nEgjXh00LYuQ1lZFngB4PaMs/a7riCtBl31HkTHH0U01T3RJ+5O1ZQA+5eYXEUFGNTTvXK8IsZq6uZcOA+vzWvYFiBChy7tQ5By69hdSSCoOGNmE/V1Y= Received: by 10.141.18.14 with SMTP id v14mr3894093rvi.1197244490885; Sun, 09 Dec 2007 15:54:50 -0800 (PST) Received: by 10.141.63.14 with HTTP; Sun, 9 Dec 2007 15:54:50 -0800 (PST) Message-ID: <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> Date: Mon, 10 Dec 2007 00:54:50 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Giorgos Keramidas" In-Reply-To: <20071209234943.GB2112@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071209234943.GB2112@kobe.laptop> X-Google-Sender-Auth: 07896ded17c81573 Cc: freebsd-doc@freebsd.org, freebsd-current@freebsd.org Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2007 23:54:51 -0000 On 10/12/2007, Giorgos Keramidas wrote: > Some of these are in the PEBKAC range of problems, though, i.e.: > > => tmpfs and fstab/fsck errors > > Since tmpfs /tmp is a memory file system, which is created from > scratch every time, it makes no sense to fsck it on boot. And this gives it the right to block system from booting? I'd at least like a symlink from "true" to "fsck_tmpfs". > => SCTP depends on IPv6 > > This is clearly documented in NOTES. I don't think it should count > as a surprising fact. I know it's in the NOTES - I've added it when it bit me since I didn't read the notes. Maybe I'll remove it. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 00:09:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4C8516A417 for ; Mon, 10 Dec 2007 00:09:21 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.freebsd.org (Postfix) with ESMTP id 409A313C448 for ; Mon, 10 Dec 2007 00:09:21 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 75526EBB62C; Mon, 10 Dec 2007 08:09:20 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id 6fO4uM1qnlxp; Mon, 10 Dec 2007 08:09:15 +0800 (CST) Received: from charlie.delphij.net (c-67-161-39-180.hsd1.ca.comcast.net [67.161.39.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 14A64EB3686; Mon, 10 Dec 2007 08:09:13 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:content-type:content-transfer-encoding; b=gGdGRAao0APx0fDXGVtovxAIfwIytQmKJBSvPjUYGQyfpfcuQ5tAZI8opXkKYdlHg duG+/s5W4XKxstGdnCAHQ== Message-ID: <475C83A7.3010907@delphij.net> Date: Sun, 09 Dec 2007 16:09:11 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Ivan Voras References: <20071209234943.GB2112@kobe.laptop> <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> In-Reply-To: <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Giorgos Keramidas , freebsd-doc@freebsd.org, freebsd-current@freebsd.org Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 00:09:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ivan Voras wrote: > On 10/12/2007, Giorgos Keramidas wrote: > >> Some of these are in the PEBKAC range of problems, though, i.e.: >> >> => tmpfs and fstab/fsck errors >> >> Since tmpfs /tmp is a memory file system, which is created from >> scratch every time, it makes no sense to fsck it on boot. > > And this gives it the right to block system from booting? I'd at least > like a symlink from "true" to "fsck_tmpfs". Hmm... This is somewhat complex issue, the same happens when you do it for NFS, as there is no "fsck_nfs". Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHXIOnhcUczkLqiksRAkK2AJsGdjkhJ5ttZIeISWy89gnYDpUqvwCgjemg c7xidclsbr1d9gTODK5WJFI= =uTZB -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 00:22:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DC6916A418; Mon, 10 Dec 2007 00:22:01 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id ECF1413C43E; Mon, 10 Dec 2007 00:22:00 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup156.ach.sch.gr [81.186.70.156]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id lBA0LY8M005552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Dec 2007 02:21:47 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id lBA0LX77045813; Mon, 10 Dec 2007 02:21:33 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id lBA0LVlg045053; Mon, 10 Dec 2007 02:21:31 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 10 Dec 2007 02:21:31 +0200 From: Giorgos Keramidas To: Ivan Voras Message-ID: <20071210002131.GA74729@kobe.laptop> References: <20071209234943.GB2112@kobe.laptop> <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.949, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.45, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-doc@freebsd.org, freebsd-current@freebsd.org Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 00:22:01 -0000 On 2007-12-10 00:54, Ivan Voras wrote: >On 10/12/2007, Giorgos Keramidas wrote: >> Some of these are in the PEBKAC range of problems, though, i.e.: >> >> => tmpfs and fstab/fsck errors >> >> Since tmpfs /tmp is a memory file system, which is created from >> scratch every time, it makes no sense to fsck it on boot. > > And this gives it the right to block system from booting? I'd at least > like a symlink from "true" to "fsck_tmpfs". Heh, no, there's no reason to block the boot process because of a missing binary (although some may argue that botching fstab is not something that should be taken lightly). A *real* fix is probably something we should discuss with Julio M. Merino Vidal and the people who ported tmpfs to FreeBSD. For example, does it make sense to fsck a tmpfs, ever? When it's not mounted, is it accessible in any way? What are the `use cases' of the tmpfs filesystem, other than memory-backed /tmp mounts? > > => SCTP depends on IPv6 > > > > This is clearly documented in NOTES. I don't think it should count > > as a surprising fact. > > I know it's in the NOTES - I've added it when it bit me since I didn't > read the notes. Maybe I'll remove it. If it bit you, an experienced FreeBSD developer, it can bite others too. Let's work with re@ to get it in the release notes, if it's not already there (instead of deleting it from the list) :-) My last CVSup is from Wed Dec 05 19:32:59 2007 +0000 (right before I started preparing for Friday's FreeBSD talk at a nearby university), so I'll CVSup again tomorrow morning, and check how we can fit this into the release notes in a nice, non-intrusive but still useful manner. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 03:44:23 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D876016A417 for ; Mon, 10 Dec 2007 03:44:23 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from optimus.centralmiss.com (ns.centralmiss.com [206.156.254.79]) by mx1.freebsd.org (Postfix) with ESMTP id A6F6B13C455 for ; Mon, 10 Dec 2007 03:44:23 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by optimus.centralmiss.com (Postfix) with ESMTP id 7289328454; Sun, 9 Dec 2007 21:44:22 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 0AFDF61C42; Sun, 9 Dec 2007 21:44:22 -0600 (CST) Date: Sun, 9 Dec 2007 21:44:22 -0600 From: "Matthew D. Fuller" To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20071210034421.GA1373@over-yonder.net> References: <472A548B.50406@lxnt.info> <20071116144304.GA7950@stud.ntnu.no> <473DBABE.3070901@deepcore.dk> <47414319.6070303@deepcore.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47414319.6070303@deepcore.dk> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.16-fullermd.4 (2007-06-09) Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 03:44:23 -0000 On Mon, Nov 19, 2007 at 09:02:33AM +0100 I heard the voice of Søren Schmidt, and lo! it spake thus: > > I'd like to get the final verdict of the attached patch and if it > fixes the problem or not. Behind the curve, as usual, I just upgraded one of my systems that's had the problem in the past to RELENG_7 (which has the fix). It's since moved a bunch of data and done a bunch of builds without a hint of trouble, so looks good to me. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 04:44:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0857416A418 for ; Mon, 10 Dec 2007 04:44:29 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id CFAF413C4D3 for ; Mon, 10 Dec 2007 04:44:28 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from [216.89.228.170] (host-216-89-228-170.wireless.terranova.net [216.89.228.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTP id 1B21929B5FA; Sun, 9 Dec 2007 23:44:27 -0500 (EST) Message-ID: <475CC426.3060808@terranova.net> Date: Sun, 09 Dec 2007 23:44:22 -0500 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= , freebsd-current@freebsd.org References: <73807.10710.qm@web63912.mail.re1.yahoo.com> <200711280842.09340.jhb@freebsd.org> <474D726A.8080807@deepcore.dk> <200711280938.38545.jhb@freebsd.org> <474E5B69.7070406@yandex.ru> <474E65D6.4040403@deepcore.dk> <474E69AE.7000105@yandex.ru> <475978E1.2090507@deepcore.dk> <475C6C3E.6070004@deepcore.dk> In-Reply-To: <475C6C3E.6070004@deepcore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: Any successful installs on a Broadcom HT1000 chipset? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 04:44:29 -0000 Søren Schmidt wrote: > > OK, so I found at least one problem with the HT1000, its sometimes > doesn't handle 128 sector transfers correctly, its DMA engine looses its > wits. > The result is that it just messes up completely and barfs data all over > the place on the next read operation. > > Anyhow the attached patch seems to work around the problem by limitting > transfer to a max of 126 sectors in one go, at least I have move several > hundred Gb's around now on a zfs volume without problems, which > certainly wasn't possible before. > > Let me know how this turns out for you! > > Patch is against a clean RELENG_7 as last time, should fit both RELENG_6 > and -current... You definitely found the trouble area. This patch allows me to boot and use my Tyan on-board SATA controller without any errors or memory corruption. As an aside, this patch breaks dumping. The disk device (ad6) complains about an oversized DMA and fails to dump on panic now. (No, your patch hasn't created any new panics or anything, btw...) So this is a successful workaround for the HT1000 on-board SATA, and it looks like this additional workaround you just posted is pretty universal and would also limit a Marvell PCI-X SATA controller's DMA size. Do you suppose there will be some way to make this workaround more "global" so that in the presence of an HT1000 chipset, everything (not just ata) will avoid trying large DMA transfers and thus triggering the bug? I don't suppose you think ServerWorks/Broadcom would care to help comment on what might be a more proper global fix-all for this issue... I think it could really save some people with this hardware some trouble if an HT1000 workaround made it into 7.0-RELEASE. Without your fix, if someone afflicted by this HT1000 problem booted up 7.0 it would start corrupting their existing data and there could be some major crying at some point down the road :) Thanks for your work, good job finding it! -- TerraNovaNet Internet Services - Key Largo, FL Voice: (305)453-4011 x101 Fax: (305)451-5991 http://www.terranova.net/ ---------------------------------------------- Life's not fair, but the root password helps. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 05:12:05 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 202B316A417 for ; Mon, 10 Dec 2007 05:12:05 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id E949C13C442 for ; Mon, 10 Dec 2007 05:12:04 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from [216.89.228.170] (host-216-89-228-170.wireless.terranova.net [216.89.228.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTP id 4020029B61C; Mon, 10 Dec 2007 00:12:04 -0500 (EST) Message-ID: <475CCAA0.5040900@terranova.net> Date: Mon, 10 Dec 2007 00:12:00 -0500 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= , freebsd-current@freebsd.org References: <73807.10710.qm@web63912.mail.re1.yahoo.com> <200711280842.09340.jhb@freebsd.org> <474D726A.8080807@deepcore.dk> <200711280938.38545.jhb@freebsd.org> <474E5B69.7070406@yandex.ru> <474E65D6.4040403@deepcore.dk> <474E69AE.7000105@yandex.ru> <475978E1.2090507@deepcore.dk> <475C6C3E.6070004@deepcore.dk> <475CC426.3060808@terranova.net> In-Reply-To: <475CC426.3060808@terranova.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Any successful installs on a Broadcom HT1000 chipset? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 05:12:05 -0000 Travis Mikalson wrote: > So this is a successful workaround for the HT1000 on-board SATA, and it > looks like this additional workaround you just posted is pretty > universal and would also limit a Marvell PCI-X SATA controller's DMA size. Er, scratch that, I see the max_iosize you set is in ata_serverworks_allocate() so this fix wouldn't help with a Marvell SATA controller plugged into the HT1000 system's PCI-X slot. I also see this isn't first and only chipset to have the exact same dma max_iosize limit imposed :) -- TerraNovaNet Internet Services - Key Largo, FL Voice: (305)453-4011 x101 Fax: (305)451-5991 http://www.terranova.net/ ---------------------------------------------- Life's not fair, but the root password helps. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 07:26:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D720116A418 for ; Mon, 10 Dec 2007 07:26:02 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-70484.0x50a6c9a6.abnxx16.customer.tele.dk [80.166.201.166]) by mx1.freebsd.org (Postfix) with ESMTP id 5B46513C4D1 for ; Mon, 10 Dec 2007 07:26:02 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from ws.local (ws.deepcore.dk [194.192.25.137]) by spider.deepcore.dk (8.13.8/8.13.8) with ESMTP id lBA7PxRJ085847; Mon, 10 Dec 2007 08:26:00 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <475CEA07.1050500@deepcore.dk> Date: Mon, 10 Dec 2007 08:25:59 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Travis Mikalson References: <73807.10710.qm@web63912.mail.re1.yahoo.com> <200711280842.09340.jhb@freebsd.org> <474D726A.8080807@deepcore.dk> <200711280938.38545.jhb@freebsd.org> <474E5B69.7070406@yandex.ru> <474E65D6.4040403@deepcore.dk> <474E69AE.7000105@yandex.ru> <475978E1.2090507@deepcore.dk> <475C6C3E.6070004@deepcore.dk> <475CC426.3060808@terranova.net> <475CCAA0.5040900@terranova.net> In-Reply-To: <475CCAA0.5040900@terranova.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Any successful installs on a Broadcom HT1000 chipset? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 07:26:02 -0000 Travis Mikalson wrote: > Travis Mikalson wrote: >> So this is a successful workaround for the HT1000 on-board SATA, and=20 >> it looks like this additional workaround you just posted is pretty=20 >> universal and would also limit a Marvell PCI-X SATA controller's DMA=20 >> size. > > Er, scratch that, I see the max_iosize you set is in=20 > ata_serverworks_allocate() so this fix wouldn't help with a Marvell=20 > SATA controller plugged into the HT1000 system's PCI-X slot. Yep, I'm not convinced there are "generic" DMA problems with that=20 chipset, but the ATA part definitively has trouble, I'm (slowly) working = my way through the different results here to try pinpoint the problem=20 more precisely. I'm also going to try a Marvell ctlr later today, more news later... > > I also see this isn't first and only chipset to have the exact same=20 > dma max_iosize limit imposed :) Right, the usual need for this limit is that the 64K size means that the = count reg is set to zero, and some HW designers just didn't get that righ= t. In this case its different as it does not always fail, but I havn't=20 found the combo that makes it fail yet. However the workaround seems to=20 be quite solid, but there might be a better / more correct way to solve=20 it still. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 08:19:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEC0C16A417 for ; Mon, 10 Dec 2007 08:19:12 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [62.220.235.15]) by mx1.freebsd.org (Postfix) with ESMTP id 6259513C46B for ; Mon, 10 Dec 2007 08:19:12 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from localhost (unknown [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 2EEEE1CC93; Mon, 10 Dec 2007 10:17:56 +0200 (EET) Received: from www.liukuma.net ([127.0.0.1]) by localhost (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sb3OH18GeXh4; Mon, 10 Dec 2007 10:17:54 +0200 (EET) Received: from L02D81003 (unknown [195.148.43.230]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTP id 4D0E71CC59; Mon, 10 Dec 2007 10:17:54 +0200 (EET) Message-ID: <002801c83b05$56ab20b0$3a2a13ac@staff.ktc.lan> From: "Reko Turja" To: "Giorgos Keramidas" , "Ivan Voras" References: <20071209234943.GB2112@kobe.laptop><9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> <20071210002131.GA74729@kobe.laptop> Date: Mon, 10 Dec 2007 10:19:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 08:19:12 -0000 >> > => SCTP depends on IPv6 >> > >> > This is clearly documented in NOTES. I don't think it should >> > count >> > as a surprising fact. >> >> I know it's in the NOTES - I've added it when it bit me since I >> didn't >> read the notes. Maybe I'll remove it. > > If it bit you, an experienced FreeBSD developer, it can bite others > too. > Let's work with re@ to get it in the release notes, if it's not > already > there (instead of deleting it from the list) :-) > My last CVSup is from Wed Dec 05 19:32:59 2007 +0000 (right before I > started preparing for Friday's FreeBSD talk at a nearby university), > so I'll CVSup again tomorrow morning, and check how we can fit this > into > the release notes in a nice, non-intrusive but still useful manner. How about making a comment about the requirement in the GENERIC config file, in a manner used for device 'ed' or device 'sbp' for example? ... options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol # SCTP requires 'options INET6' options FFS ... Or are the comments about in requirement at 'GENERIC' phased out? -Reko From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 08:44:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7DC316A417 for ; Mon, 10 Dec 2007 08:44:51 +0000 (UTC) (envelope-from pmurray@nevada.net.nz) Received: from bellagio.open2view.net (bellagio.open2view.net [210.48.79.75]) by mx1.freebsd.org (Postfix) with ESMTP id A8FF813C455 for ; Mon, 10 Dec 2007 08:44:51 +0000 (UTC) (envelope-from pmurray@nevada.net.nz) Received: from mandalay.lan (219-89-76-113.ipnets.xtra.co.nz [219.89.76.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bellagio.open2view.net (Postfix) with ESMTP id 5291B7F379D for ; Mon, 10 Dec 2007 21:21:06 +1300 (NZDT) Message-Id: <2942A3E0-3E07-4CCB-B292-8DA25884AD3E@nevada.net.nz> From: Philip Murray To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Mon, 10 Dec 2007 21:21:04 +1300 X-Mailer: Apple Mail (2.912) Subject: Areca weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 08:44:51 -0000 Hi, After the recent commit of the new Areca (arcmsr) driver, I get this output during boot: arcmsr0: mem 0xfc7ff000-0xfc7fffff,0xfc000000-0xfc3fffff irq 31 at device 14.0 on pci2 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 arcmsr0: [ITHREAD] .... snip .... Waiting 5 seconds for SCSI devices to settle (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step ^^^ This line here ^^^ da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: 76293MB (156248064 512 byte sectors: 255H 63S/T 9725C) da1 at arcmsr0 bus 0 target 0 lun 1 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da1: 2784727MB (5703121920 512 byte sectors: 255H 63S/T 355002C) Not sure if it's anything to worry about (as I have no idea what it means), but doesn't seem to affect functionality at all Cheers Phil From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 13:23:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E94916A417 for ; Mon, 10 Dec 2007 13:23:40 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id D0E0213C43E for ; Mon, 10 Dec 2007 13:23:39 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so8717pyb for ; Mon, 10 Dec 2007 05:23:37 -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=2UVh9cNHVgBvGaoSSdd6/GSBYwrRG/FcH/PGlf/QXA4=; b=L03Hpd4i7gJN/ocQs4hs0qvZyfLEJYX/mYOrklg9hyTyea2JwMIIucRUeZjWU6fbHms+qPSfBg7V99AB+f/ZJY2lIcf+uJ3VO6ZRHAUdQcFMTi84+kD5WRWdbhYWP9Eed6/y4x9Ls9V2cPTcI6oTv9NcZVUSiTdT4TUDrFBYuSE= 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=PVNkj6T8Vdo8bLsLqNeFHk3+sTEAJGbUqueiQQUq36A7qr2JvormTbyOB9n5U7+okbcciFUcUwJ+2z339R9WVZ6H2iqSjF46feHGsvCXrCKE11Su+vYKTY083kzPf18NQ84jy+jPF/ZzmIaayLDyrQK+FDDUmESmVNRNAUAayC0= Received: by 10.64.208.20 with SMTP id f20mr13994871qbg.1197293015864; Mon, 10 Dec 2007 05:23:35 -0800 (PST) Received: by 10.64.184.9 with HTTP; Mon, 10 Dec 2007 05:23:35 -0800 (PST) Message-ID: <8e10486b0712100523k45c61865v7821d0522ad5f994@mail.gmail.com> Date: Mon, 10 Dec 2007 11:23:35 -0200 From: "Alexandre Biancalana" To: "Michael Haro" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0711280537n222d6cd5le33639b82a11f45@mail.gmail.com> <8e10486b0711290558q31217f5aif7b803e1ae08023c@mail.gmail.com> <9bbcef730711290634k347bc0c6re0da8676bab37873@mail.gmail.com> <8e10486b0711290637u711c67b3i17925777e4481346@mail.gmail.com> <8e10486b0711300247q4438235ata70ca42030871286@mail.gmail.com> <20071130124801.74c40ef9@peedub.jennejohn.org> <8e10486b0712040521u5c7015b8h86d0da5554162898@mail.gmail.com> <47556554.3010505@clearchain.com> <8e10486b0712040719ydcf32e0mbe690c3f18968691@mail.gmail.com> Cc: freebsd-current@freebsd.org, Benjamin Close Subject: Re: 7-BETA3 everyday reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 13:23:40 -0000 On 12/7/07, Michael Haro wrote: > > > > > I have found that turning off zil and prefetch seem to keep things > > > happier on one of the heavily loaded servers that I look after. > > > It also appears to prevent a deadlock under very heavy load - something > > > I've not yet had time to debug. > > > Try adding: > > > > > > vfs.zfs.zil_disable=1 > > > vfs.zfs.prefetch_disable="1" > > > > > > to /boot/loader.conf > > > > > > and let us know if it makes a difference. > > > > Added now only > > > > vfs.zfs.prefetch_disable="1" > > > > > > I let you know the result. > > Is the result promising? > > Yes ! The machine does not reboot anymore ! From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 15:13:35 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D6F616A417; Mon, 10 Dec 2007 15:13:35 +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 CCCDC13C459; Mon, 10 Dec 2007 15:13:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J1kK2-000Ffb-Cj; Mon, 10 Dec 2007 17:13:33 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id lBAFDUb5094019; Mon, 10 Dec 2007 17:13:30 +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 lBAFDTEo094018; Mon, 10 Dec 2007 17:13:29 +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, 10 Dec 2007 17:13:29 +0200 From: Kostik Belousov To: Marcus Alves Grando Message-ID: <20071210151329.GY83121@deviant.kiev.zoral.com.ua> References: <4756F844.2000405@FreeBSD.org> <4756F8DC.3070301@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j3eaMWZhMWMo+sdM" Content-Disposition: inline In-Reply-To: <4756F8DC.3070301@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 811d4bb63238b2e39a625e79cff8aaca X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1865 [Dec 10 2007] 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: current@freebsd.org Subject: Re: Fatal trap 12: page fault while in kernel mode [While close wine application] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 15:13:35 -0000 --j3eaMWZhMWMo+sdM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 05, 2007 at 05:15:40PM -0200, Marcus Alves Grando wrote: > # uname -a > FreeBSD sup-afu 7.0-BETA4 FreeBSD 7.0-BETA4 #9: Mon Dec 3 10:26:13 BRST= =20 > 2007 root@sup-afu:/usr/obj/usr/src/sys/MARCUS i386 >=20 > Marcus Alves Grando wrote: > >Fatal trap 12: page fault while in kernel mode > >cpuid =3D 0; apic id =3D 00 > >fault virtual address =3D 0x10 > >fault code =3D supervisor write, page not present > >instruction pointer =3D 0x20:0xc062c948 > >stack pointer =3D 0x28:0xe652eb68 > >frame pointer =3D 0x28:0xe652eb88 > >code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, def32 1, gran 1 > >processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >current process =3D 87845 (wine-pthread) > >trap number =3D 12 > >panic: page fault > >cpuid =3D 0 > >Uptime: 2d6h12m13s > >Physical memory: 1007 MB > >Dumping 231 MB: 216 200 184 168 152 136 120 104 88 72 56 40 24 8 > > > >#0 doadump () at pcpu.h:195 > >195 pcpu.h: No such file or directory. > > in pcpu.h > >(kgdb) bt > >#0 doadump () at pcpu.h:195 > >#1 0xc0652df7 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.= c:409 > >#2 0xc06530b9 in panic (fmt=3DVariable "fmt" is not available. > >) at /usr/src/sys/kern/kern_shutdown.c:563 > >#3 0xc08f772c in trap_fatal (frame=3D0xe652eb28, eva=3D16) at=20 > >/usr/src/sys/i386/i386/trap.c:872 > >#4 0xc08f7990 in trap_pfault (frame=3D0xe652eb28, usermode=3D0, eva=3D1= 6) at=20 > >/usr/src/sys/i386/i386/trap.c:785 > >#5 0xc08f82e2 in trap (frame=3D0xe652eb28) at=20 > >/usr/src/sys/i386/i386/trap.c:463 > >#6 0xc08decfb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > >#7 0xc062c948 in knlist_cleardel (knl=3D0xc44892b4, td=3D0x0, islocked= =3D1,=20 > >killkn=3D0) at atomic.h:149 > >#8 0xc068ba4d in pipeclose (cpipe=3D0xc4489244) at=20 > >/usr/src/sys/kern/sys_pipe.c:1508 > >#9 0xc068bb60 in pipe_close (fp=3D0xc48ef828, td=3D0xc41b5220) at=20 > >/usr/src/sys/kern/sys_pipe.c:1425 > >#10 0xc0622847 in fdrop (fp=3D0xc48ef828, td=3D0xc41b5220) at file.h:297 > >#11 0xc0623fef in closef (fp=3D0xc48ef828, td=3D0xc41b5220) at=20 > >/usr/src/sys/kern/kern_descrip.c:1958 > >#12 0xc06244ff in kern_close (td=3D0xc41b5220, fd=3D45) at=20 > >/usr/src/sys/kern/kern_descrip.c:1054 > >#13 0xc06245da in close (td=3D0xc41b5220, uap=3D0xe652ecfc) at=20 > >/usr/src/sys/kern/kern_descrip.c:1006 > >#14 0xc08f7ce5 in syscall (frame=3D0xe652ed38) at=20 > >/usr/src/sys/i386/i386/trap.c:1008 > >#15 0xc08ded60 in Xint0x80_syscall () at=20 > >/usr/src/sys/i386/i386/exception.s:196 > >#16 0x00000033 in ?? () > >Previous frame inner to this frame (corrupt stack?) > >(kgdb) l /usr/src/sys/kern/sys_pipe.c:1508 > >1503 PIPE_UNLOCK(cpipe); > >1504 pipe_free_kmem(cpipe); > >1505 PIPE_LOCK(cpipe); > >1506 cpipe->pipe_present =3D 0; > >1507 pipeunlock(cpipe); > >1508 knlist_clear(&cpipe->pipe_sel.si_note, 1); > >1509 knlist_destroy(&cpipe->pipe_sel.si_note); > >1510 =20 > >1511 /* > >1512 * If both endpoints are now closed, release the memory for = the > > > >I have a vmcore if need... Is it easily reproducable ? Could you, please, show the output of the kgdb commands p/x *cpipe p/x *(cpipe->pipe_peer) from the dump ? Also, it would be very useful to get an idea of what line of kern_event.c is actually faulted in frame #7. Try to do "list" in that frame. Thanks. --j3eaMWZhMWMo+sdM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHXVeZC3+MBN1Mb4gRAmxTAKCjdsGHNWRp7268T2cApdck1h4T8gCfYwmt kGaBaHROi9SF/pjsdCYK0rM= =s0lg -----END PGP SIGNATURE----- --j3eaMWZhMWMo+sdM-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 15:55:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97C4F16A41A for ; Mon, 10 Dec 2007 15:55:37 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id E974813C44B for ; Mon, 10 Dec 2007 15:55:35 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost.bsdunix.ch [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id D53785E32 for ; Mon, 10 Dec 2007 16:36:27 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id u+KPbDVAiIAx for ; Mon, 10 Dec 2007 16:36:24 +0100 (CET) Received: from bert.mlan.solnet.ch (bert.mlan.solnet.ch [212.101.1.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 20B3E5E15 for ; Mon, 10 Dec 2007 16:36:24 +0100 (CET) Message-ID: <475D5CF7.2020803@bsdunix.ch> Date: Mon, 10 Dec 2007 16:36:23 +0100 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.9 (X11/20071128) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: FreeBSD 7.0Beta4 (amd64) freezes with dummynet enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 15:55:37 -0000 Hi, I kindly ask for advice for debugging a problem with 7.0-Beta 4 (amd64). The machine freezes if dummynet rules are enabled on a gigabit port. The system runs fine on fast ethernet or with dummynet rules disabled. I can't trigger the bug if my upstream port is limited to 100mbit. The machine suddenly freezes after 3-4 minutes if dummynet rules are loaded. My Kernel already includes some debug options but I'm not able to produce a panic. Kernel: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options ZERO_COPY_SOCKETS options DEVICE_POLLING options HZ=1000 options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_VFS_LOCKS options DIAGNOSTIC options KDB options KDB_UNATTENDED options DDB options GDB options KDB_TRACE options SOCKBUF_DEBUG options BREAK_TO_DEBUGGER dmesg: Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-BETA4 #4: Fri Dec 7 12:45:37 UTC 2007 root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/SOLNETDEBUG WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (1739.55-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e33d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 4258033664 (4060 MB) avail memory = 4071751680 (3883 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 WITNESS: spin lock intrcnt not in order list ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 device_attach: acpi_perf0 attach returned 6 device_attach: acpi_perf0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 device_attach: acpi_perf1 attach returned 6 device_attach: acpi_perf1 attach returned 6 p4tcc1: on cpu1 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xca2,0xca3,0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 0.0 on pci1 pci2: on pcib2 pcib3: irq 16 at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 0.0 on pci3 pci4: on pcib4 arcmsr0: mem 0xc3d00000-0xc3d00fff,0xc3000000-0xc33fffff irq 18 at device 14.0 on pci4 ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 arcmsr0: [ITHREAD] pcib5: at device 0.2 on pci3 pci5: on pcib5 pcib6: irq 18 at device 2.0 on pci2 pci6: on pcib6 em0: port 0x2020-0x203f mem 0xc3c20000-0xc3c3ffff,0xc3800000-0xc3bfffff irq 18 at device 0.0 on pci6 em0: Using MSI interrupt em0: Ethernet address: 00:15:17:30:94:30 em0: [FILTER] em1: port 0x2000-0x201f mem 0xc3c00000-0xc3c1ffff,0xc3400000-0xc37fffff irq 19 at device 0.1 on pci6 em1: Using MSI interrupt em1: Ethernet address: 00:15:17:30:94:31 em1: [FILTER] pcib7: at device 0.3 on pci1 pci7: on pcib7 pcib8: at device 3.0 on pci0 pci8: on pcib8 pcib9: at device 4.0 on pci0 pci9: on pcib9 vgapci0: port 0x1000-0x107f mem 0xc2000000-0xc2ffffff,0xb0000000-0xbfffffff,0xc0000000-0xc1ffffff irq 16 at device 0.0 on pci9 pcib10: at device 5.0 on pci0 pci10: on pcib10 pcib11: at device 6.0 on pci0 pci11: on pcib11 pcib12: at device 7.0 on pci0 pci12: on pcib12 pci0: at device 8.0 (no driver attached) pci0: at device 27.0 (no driver attached) pcib13: irq 16 at device 28.0 on pci0 pci13: on pcib13 uhci0: port 0x3080-0x309f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3060-0x307f irq 22 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 23 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3020-0x303f irq 22 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xc3f04400-0xc3f047ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib14: at device 30.0 on pci0 pci14: on pcib14 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30b0-0x30bf irq 20 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x30c8-0x30cf,0x30e4-0x30e7,0x30c0-0x30c7,0x30e0-0x30e3,0x30a0-0x30af mem 0xc3f04000-0xc3f043ff irq 20 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] orm0: at iomem 0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging limited to 100 packets/entry by default Waiting 5 seconds for SCSI devices to settle acd0: DVDROM at ata0-master UDMA33 da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: 238418MB (488281088 512 byte sectors: 255H 63S/T 30394C) da1 at arcmsr0 bus 0 target 0 lun 1 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da1: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da2 at arcmsr0 bus 0 target 0 lun 2 da2: Fixed Direct Access SCSI-5 device da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da2: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da3 at arcmsr0 bus 0 target 0 lun 3 da3: Fixed Direct Access SCSI-5 device da3: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da3: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da4 at arcmsr0 bus 0 target 0 lun 4 da4: Fixed Direct Access SCSI-5 device da4: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da4: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da5 at arcmsr0 bus 0 target 0 lun 5 da5: Fixed Direct Access SCSI-5 device da5: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da5: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da6 at arcmsr0 bus 0 target 0 lun 6 da6: Fixed Direct Access SCSI-5 device da6: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da6: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da7 at arcmsr0 bus 0 target 0 lun 7 da7: Fixed Direct Access SCSI-5 device da7: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da7: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Trying to mount root from ufs:/dev/da0s1a WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 6 ZFS storage pool version 6 em1: Hardware Initialization Failed em1: Unable to initialize the hardware Expensive timeout(9) function: 0xffffffff80258fe0(0xffffff00012fc000) 0.008566172 s em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP Expensive timeout(9) function: 0xffffffff80507ae0(0) 0.105003251 s Expensive timeout(9) function: 0xffffffff80397260(0) 0.372032111 s Expensive timeout(9) function: 0xffffffff80469350(0xffffff0069b5f888) 0.403952336 s my ipfw rules: pipe 2 config bw 600Mbit/s queue 50KBytes queue 201 config pipe 2 weight 1 mask dst-ip 0x0000000f queue 50 queue 210 config pipe 2 weight 50 mask dst-ip 0x0000000f queue 50 add 100 permit ip from any to any via lo0 add 200 deny ip from any to 127.0.0.0/8 # Speedup Established add 5001 skipto 8000 ip from 82.220.2.0/24 to 212.101.0.0/19 via em1 add 6000 queue 210 ip from any to 212.101.0.0/19 out xmit em1 add 6001 skipto 8000 ip from any to 212.101.0.0/19 out xmit em1 add 6002 queue 210 ip from any to 212.41.65.0/18 out xmit em1 add 6003 skipto 8000 ip from any to 212.41.65.0/18 out xmit em1 add 6004 queue 210 ip from any to 82.220.0.0/18 out xmit em1 add 6005 skipto 8000 ip from any to 82.220.0.0/18 out xmit em1 add 6100 queue 201 ip from any to any out xmit em1 add 8000 permit tcp from any to any via em1 established # ICMP add 11700 permit icmp from any to any via em1 icmptype 0,3,4,8,11,12 # Traceroute add 1800 allow udp from any 30000-60000 to me 30000-60000 via em0 # SSH (external connections are allowed for portsnap maintainer) add 11900 allow ip from me to any ssh setup add 11901 allow ip from any to me ssh setup # HTTP OUT add 11910 permit tcp from me to any 80 setup via em1 # SMTP add 12100 permit tcp from me to 212.101.0.0/19 25 setup via em1 add 12110 allow tcp from me to any dst-port smtp via em1 setup # DNS UDP SolNet add 21100 permit udp from 212.101.0.10 domain to me recv em1 add 21101 permit udp from me to 212.101.0.10 domain out xmit em1 add 21110 permit udp from 212.101.4.253 domain to me recv em1 add 21111 permit udp from me to 212.101.4.253 domain out xmit em1 add 21120 permit udp from 212.101.4.251 domain to me recv em1 add 21121 permit udp from me to 212.101.4.251 domain out xmit em1 # NTP add 21440 permit udp from me ntp to 212.101.0.0/19 ntp out xmit em1 add 21445 permit udp from 224.0.1.1 ntp to 212.101.0.0/19 ntp out xmit em1 add 21450 permit udp from 212.101.0.0/19 ntp to me ntp recv em1 add 21460 permit udp from 212.101.0.0/19 ntp to 224.0.1.1 ntp recv em1 add 21470 permit udp from me ntp to 224.0.1.1 ntp out xmit em1 # WEB add 22250 permit tcp from any to 212.101.4.241 80 setup via em1 limit src-addr 4 add 22251 permit tcp from any to 212.101.4.241 443 setup via em1 limit src-addr 4 add 22253 permit tcp from 212.101.4.241 to any 1024-65535 setup via em1 # FTP add 22300 permit tcp from any to 212.101.4.244 21 setup via em1 limit src-addr 4 add 22301 permit tcp from 212.101.4.244 to any 21 setup via em1 add 22302 permit tcp from 212.101.4.244 20 to any 1024-65535 setup via em1 add 22320 permit tcp from any 20 to 212.101.4.244 1024-65535 setup via em1 add 22340 permit tcp from any to 212.101.4.244 49152-65535 setup via em1 # RSYNC add 22400 permit tcp from 212.101.4.244 to any rsync setup via em1 add 22410 permit tcp from any to me rsync setup via em1 # CVSUPD add 22500 permit tcp from 212.101.4.244 to any cvsup setup via em1 add 22510 permit tcp from any to me cvsup setup via em1 # # NO WINDOWS # add 30000 deny udp from any to any 137 via em1 # Internal Interface add 62000 allow tcp from 212.101.0.0/24 to any 22,23,25 via em0 setup add 62010 allow tcp from 212.101.1.0/24 to any 22,23,25 via em0 setup add 62020 allow tcp from 212.101.4.0/24 to any 22,25 via em0 setup add 63000 reset tcp from any to any 22,23,25,3306,111 via em0 setup add 65000 allow ip from any to any via em0 # F*** off the rest add 65500 deny log ip from any to any If i load the ipfw rules i see: lock order reversal: 1st 0xffffffff80839448 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0xffffffff80838440 in_multi_mtx (in_multi_mtx) @ /usr/src/sys/netinet/ip_output.c:302 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x605 _mtx_lock_flags() at _mtx_lock_flags+0x75 ip_output() at ip_output+0x570 dummynet_send() at dummynet_send+0x13f dummynet_io() at dummynet_io+0x322 ipfw_check_out() at ipfw_check_out+0x20a pfil_run_hooks() at pfil_run_hooks+0xbc ip_output() at ip_output+0x372 udp_send() at udp_send+0x350 sosend_dgram() at sosend_dgram+0x20f kern_sendit() at kern_sendit+0x122 sendit() at sendit+0xdc sendto() at sendto+0x4d syscall() at syscall+0x1f6 Xfast_syscall() at Xfast_syscall+0xab --- syscall (133, FreeBSD ELF64, sendto), rip = 0x800bebc8c, rsp = 0x7fffffffe6c8, rbp = 0x551420 --- Expensive timeout(9) function: 0xffffffff80469350(0xffffff004696e000) 0.530255650 s FreeBSD is installed on ufs but I have a zfs pool for my data. Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 496M 356M 100M 78% / devfs 1.0K 1.0K 0B 100% /dev /dev/da0s1g 169G 4.0K 155G 0% /disk1 /dev/da0s1f 3.9G 902K 3.6G 0% /tmp /dev/da0s1e 29G 3.9G 23G 15% /usr /dev/da0s1d 19G 4.0G 14G 22% /var pool 1.2T 0B 1.2T 0% /usr/local/data pool/cvsup 1.2T 5.1G 1.2T 0% /usr/local/data/cvsup pool/ftp 3.3T 2.2T 1.2T 65% /usr/local/data/ftp pool/portsnap 1.2T 591M 1.2T 0% /usr/local/data/portsnap pool/www 1.2T 78M 1.2T 0% /usr/local/data/www Any help? Best regards, Thomas From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 16:43:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9FD816A418 for ; Mon, 10 Dec 2007 16:43:04 +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 A314413C474 for ; Mon, 10 Dec 2007 16:43:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lBAGh0SD002702; Mon, 10 Dec 2007 09:43:01 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <475D6C81.5030308@samsco.org> Date: Mon, 10 Dec 2007 09:42:41 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Philip Murray References: <2942A3E0-3E07-4CCB-B292-8DA25884AD3E@nevada.net.nz> In-Reply-To: <2942A3E0-3E07-4CCB-B292-8DA25884AD3E@nevada.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Mon, 10 Dec 2007 09:43:01 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Areca weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 16:43:05 -0000 For the Areca driver, it's harmless. I still haven't narrowed down the actual problem, unfortunately. Scott Philip Murray wrote: > Hi, > > After the recent commit of the new Areca (arcmsr) driver, I get this > output during boot: > > arcmsr0: > mem 0xfc7ff000-0xfc7fffff,0xfc000000-0xfc3fffff irq 31 at device 14.0 > on pci2 > ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 > arcmsr0: [ITHREAD] > > .... snip .... > > Waiting 5 seconds for SCSI devices to settle > (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step > ^^^ This line here ^^^ > > da0 at arcmsr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da0: 76293MB (156248064 512 byte sectors: 255H 63S/T 9725C) > da1 at arcmsr0 bus 0 target 0 lun 1 > da1: Fixed Direct Access SCSI-5 device > da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da1: 2784727MB (5703121920 512 byte sectors: 255H 63S/T 355002C) > > > Not sure if it's anything to worry about (as I have no idea what it > means), but doesn't seem to affect functionality at all > > Cheers > > Phil > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 17:06:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9935F16A41A for ; Mon, 10 Dec 2007 17:06:53 +0000 (UTC) (envelope-from mharo-freebsd@haro.us) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 1B34813C447 for ; Mon, 10 Dec 2007 17:06:52 +0000 (UTC) (envelope-from mharo-freebsd@haro.us) Received: by ug-out-1314.google.com with SMTP id y2so2497854uge for ; Mon, 10 Dec 2007 09:06:51 -0800 (PST) Received: by 10.78.140.17 with SMTP id n17mr1640144hud.1197306410552; Mon, 10 Dec 2007 09:06:50 -0800 (PST) Received: by 10.78.199.10 with HTTP; Mon, 10 Dec 2007 09:06:50 -0800 (PST) Message-ID: Date: Mon, 10 Dec 2007 09:06:50 -0800 From: "Michael Haro" Sender: mharo-freebsd@haro.us To: "Alexandre Biancalana" In-Reply-To: <8e10486b0712100523k45c61865v7821d0522ad5f994@mail.gmail.com> MIME-Version: 1.0 References: <8e10486b0711280537n222d6cd5le33639b82a11f45@mail.gmail.com> <9bbcef730711290634k347bc0c6re0da8676bab37873@mail.gmail.com> <8e10486b0711290637u711c67b3i17925777e4481346@mail.gmail.com> <8e10486b0711300247q4438235ata70ca42030871286@mail.gmail.com> <20071130124801.74c40ef9@peedub.jennejohn.org> <8e10486b0712040521u5c7015b8h86d0da5554162898@mail.gmail.com> <47556554.3010505@clearchain.com> <8e10486b0712040719ydcf32e0mbe690c3f18968691@mail.gmail.com> <8e10486b0712100523k45c61865v7821d0522ad5f994@mail.gmail.com> X-Google-Sender-Auth: c0aa26caee958748 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-current@freebsd.org, Benjamin Close Subject: Re: 7-BETA3 everyday reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 17:06:53 -0000 On 12/10/07, Alexandre Biancalana wrote: > > On 12/7/07, Michael Haro wrote: > > > > > > > > I have found that turning off zil and prefetch seem to keep things > > > > happier on one of the heavily loaded servers that I look after. > > > > It also appears to prevent a deadlock under very heavy load - > something > > > > I've not yet had time to debug. > > > > Try adding: > > > > > > > > vfs.zfs.zil_disable=1 > > > > vfs.zfs.prefetch_disable="1" > > > > > > > > to /boot/loader.conf > > > > > > > > and let us know if it makes a difference. > > > > > > Added now only > > > > > > vfs.zfs.prefetch_disable="1" > > > > > > > > > I let you know the result. > > > > Is the result promising? > > > > > Yes ! The machine does not reboot anymore ! What combination of settings did you have to do to make it stable? I tried setting vfs.zfs.prefetch_disable="1' in loader.conf and my machine still panics within 20 minutes during (I think) large file transfers. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 17:19:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AEB816A417; Mon, 10 Dec 2007 17:19:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2056013C447; Mon, 10 Dec 2007 17:19:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7675747125; Mon, 10 Dec 2007 12:19:51 -0500 (EST) Date: Mon, 10 Dec 2007 17:19:51 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Boris Samorodov In-Reply-To: <31551976@bs1.sp34.ru> Message-ID: <20071210171726.V52506@fledge.watson.org> References: <97676449@bb.ipt.ru> <3bbf2fe10712062309j7c49aef7g9a5cfa6e2a52158c@mail.gmail.com> <53021179@bb.ipt.ru> <8cb6106e0712081413uc58f836w611b99ab0a536a4a@mail.gmail.com> <31551976@bs1.sp34.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: josh.carroll@gmail.com, Attilio Rao , freebsd-current@freebsd.org Subject: Re: sockstat: struct xtcpcb size mismatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 17:19:52 -0000 On Mon, 10 Dec 2007, Boris Samorodov wrote: > On Sat, 8 Dec 2007 17:13:14 -0500 Josh Carroll wrote: > >>> Thanks for the answer. And sorry, I can't understand what to do further. >>> Is it by design and should stay so or should it be fixed? >>> >>> BTW, RELENG_7 behaves the same way. And "netstat -a" is broken: > >> Your world and kernel are out of sync. I would recommend a >> buildworld/installworld and building a new kernel. That should do the >> trick. > > I wish you were right. > > Fresh cvsup to RELENG_7, buildworld (after make clean twice), make kernel, > install world, mergemaster. The kernel config (diff from GENERIC shown > later) doesn't work. If "options LOCK_PROFILING" is removed and the kernel > is rebuilt, all goes well. The bad case: This is currently an accepted failure mode -- lock profiling significantly swells the overhead of various data structures and operations, so is not compiled in by default, and when compiled in, does modify the ABI for the monitoring interfaces. You may be able to "fix" the user tools to match the kernel ABI by recompiling them but adding -DLOCK_PROFILING (or something along these lines). It turns out that the interfaces that export TCP information directly export kernel data structures to user space -- this was presumably easy at the time for whoever did the work, but is a Bad Idea. I've looked at fixing this before, but it's quite involved. I hope that we will fix it for 8.0. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 17:51:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 199F716A41B for ; Mon, 10 Dec 2007 17:51:33 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id DB20E13C455 for ; Mon, 10 Dec 2007 17:51:32 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1855873rvb for ; Mon, 10 Dec 2007 09:51:32 -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=pNaHaokQAciohtN0zjM0ximnTd6h/eNLXCqMUsb6U9U=; b=GWwrxdlbK7WQyDm6pzY6ZZW9jYiFyMOsfXP69cEmR2Ph8lFbCX6rKJEuRRncfb6DRu30CQ3aUAAcv6N8AikDOPn6/qYrtWG3fSsi/t5aBynA7DZ63che2DXDcMr4g+4zkNRflbbD0s3qt1+gQQdITiLOGIuHDagTGQsO0jCDPMM= 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=gMR62saMry63B1qEWrWqjgwpuTLi+JTxgMy2n7AtTNOh7yAB7M7kF6Lcj9THIipkiyeMZ2Px2qyQkpccPfTKKkKMj5fEvHtJsDGKVzA3KZ3xrLoXTnQHrDgxJ1aOrD5Y+QxHo2+FeiGAL7HRHhzM7k9kwW8W3yO1HbF9C4zWN78= Received: by 10.141.71.11 with SMTP id y11mr1206511rvk.1197309092203; Mon, 10 Dec 2007 09:51:32 -0800 (PST) Received: by 10.64.184.9 with HTTP; Mon, 10 Dec 2007 09:51:32 -0800 (PST) Message-ID: <8e10486b0712100951m85f0278neb73ac4277779ba4@mail.gmail.com> Date: Mon, 10 Dec 2007 15:51:32 -0200 From: "Alexandre Biancalana" To: "Michael Haro" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0711280537n222d6cd5le33639b82a11f45@mail.gmail.com> <8e10486b0711290637u711c67b3i17925777e4481346@mail.gmail.com> <8e10486b0711300247q4438235ata70ca42030871286@mail.gmail.com> <20071130124801.74c40ef9@peedub.jennejohn.org> <8e10486b0712040521u5c7015b8h86d0da5554162898@mail.gmail.com> <47556554.3010505@clearchain.com> <8e10486b0712040719ydcf32e0mbe690c3f18968691@mail.gmail.com> <8e10486b0712100523k45c61865v7821d0522ad5f994@mail.gmail.com> Cc: freebsd-current@freebsd.org, Benjamin Close Subject: Re: 7-BETA3 everyday reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 17:51:33 -0000 On 12/10/07, Michael Haro wrote: > > > > On 12/10/07, Alexandre Biancalana wrote: > > On 12/7/07, Michael Haro wrote: > > > > > > > > > > > I have found that turning off zil and prefetch seem to keep things > > > > > happier on one of the heavily loaded servers that I look after. > > > > > It also appears to prevent a deadlock under very heavy load - > something > > > > > I've not yet had time to debug. > > > > > Try adding: > > > > > > > > > > vfs.zfs.zil_disable=1 > > > > > vfs.zfs.prefetch_disable="1" > > > > > > > > > > to /boot/loader.conf > > > > > > > > > > and let us know if it makes a difference. > > > > > > > > Added now only > > > > > > > > vfs.zfs.prefetch_disable="1" > > > > > > > > > > > > I let you know the result. > > > > > > Is the result promising? > > > > > > > > Yes ! The machine does not reboot anymore ! > > What combination of settings did you have to do to make it stable? I tried > setting vfs.zfs.prefetch_disable="1' in loader.conf and my machine still > panics within 20 minutes during (I think) large file transfers. > Here is my /boot/loader.conf: kern.maxdsiz="2G" # Set the max data size to 4GB kern.maxssiz="1G" # Set the max stack size 2GB vfs.zfs.prefetch_disable="1" vfs.zfs.arc_max="1G" vm.kmem_size_max="1500M" vm.kmem_size="1500M" kern.ipc.nmbclusters="32768" From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 17:56:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32EC416A419; Mon, 10 Dec 2007 17:56:31 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id DE31C13C469; Mon, 10 Dec 2007 17:56:30 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from bb.ipt.ru ([194.62.233.89]) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1J1mrl-000Kul-IP; Mon, 10 Dec 2007 20:56:29 +0300 To: Robert Watson References: <97676449@bb.ipt.ru> <3bbf2fe10712062309j7c49aef7g9a5cfa6e2a52158c@mail.gmail.com> <53021179@bb.ipt.ru> <8cb6106e0712081413uc58f836w611b99ab0a536a4a@mail.gmail.com> <31551976@bs1.sp34.ru> <20071210171726.V52506@fledge.watson.org> From: Boris Samorodov Date: Mon, 10 Dec 2007 20:54:52 +0300 In-Reply-To: <20071210171726.V52506@fledge.watson.org> (Robert Watson's message of "Mon\, 10 Dec 2007 17\:19\:51 +0000 \(GMT\)") Message-ID: <95868243@bb.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: josh.carroll@gmail.com, Attilio Rao , freebsd-current@freebsd.org Subject: Re: sockstat: struct xtcpcb size mismatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 17:56:31 -0000 On Mon, 10 Dec 2007 17:19:51 +0000 (GMT) Robert Watson wrote: > On Mon, 10 Dec 2007, Boris Samorodov wrote: > > On Sat, 8 Dec 2007 17:13:14 -0500 Josh Carroll wrote: > > > >>> Thanks for the answer. And sorry, I can't understand what to do > >>> further. Is it by design and should stay so or should it be fixed? > >>> > >>> BTW, RELENG_7 behaves the same way. And "netstat -a" is broken: > > > >> Your world and kernel are out of sync. I would recommend a > >> buildworld/installworld and building a new kernel. That should do > >> the trick. > > > > I wish you were right. > > > > Fresh cvsup to RELENG_7, buildworld (after make clean twice), make > > kernel, install world, mergemaster. The kernel config (diff from > > GENERIC shown later) doesn't work. If "options LOCK_PROFILING" is > > removed and the kernel is rebuilt, all goes well. The bad case: Robert, thank you for the answer. Now I (hope) understand the case. > This is currently an accepted failure mode -- lock profiling > significantly swells the overhead of various data structures and > operations, so is not compiled in by default, and when compiled in, > does modify the ABI for the monitoring interfaces. You may be able to > "fix" the user tools to match the kernel ABI by recompiling them but > adding -DLOCK_PROFILING (or something along these lines). It turns Yes, I managed to build sockstat and netstat by adding a line "CFLAGS+=-DLOCK_PROFILING" to apropriate Makefiles, then make clean, make and make install did the trick. > out that the interfaces that export TCP information directly export > kernel data structures to user space -- this was presumably easy at > the time for whoever did the work, but is a Bad Idea. I've looked at > fixing this before, but it's quite involved. I hope that we will fix > it for 8.0. Meanwhile may be it's the right thing to mention this workaround at LOCK_PROFILING(9) man page? WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 19:10:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55E0516A417 for ; Mon, 10 Dec 2007 19:10:39 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (lath.rinet.ru [195.54.192.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC8913C46E for ; Mon, 10 Dec 2007 19:10:37 +0000 (UTC) (envelope-from oleg@lath.rinet.ru) Received: from lath.rinet.ru (localhost [127.0.0.1]) by lath.rinet.ru (8.14.2/8.14.1) with ESMTP id lBAIV07c032717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2007 21:31:00 +0300 (MSK) (envelope-from oleg@lath.rinet.ru) Received: (from oleg@localhost) by lath.rinet.ru (8.14.2/8.14.1/Submit) id lBAIV0lQ032716; Mon, 10 Dec 2007 21:31:00 +0300 (MSK) (envelope-from oleg) Date: Mon, 10 Dec 2007 21:31:00 +0300 From: Oleg Bulyzhin To: Thomas Vogt Message-ID: <20071210183100.GA32000@lath.rinet.ru> References: <475D5CF7.2020803@bsdunix.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475D5CF7.2020803@bsdunix.ch> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7.0Beta4 (amd64) freezes with dummynet enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 19:10:39 -0000 On Mon, Dec 10, 2007 at 04:36:23PM +0100, Thomas Vogt wrote: > Hi, > > I kindly ask for advice for debugging a problem with 7.0-Beta 4 (amd64). > > The machine freezes if dummynet rules are enabled on a gigabit port. The > system runs fine on fast ethernet or with dummynet rules disabled. I > can't trigger the bug if my upstream port is limited to 100mbit. The > machine suddenly freezes after 3-4 minutes if dummynet rules are loaded. > > My Kernel already includes some debug options but I'm not able to > produce a panic. > > Kernel: > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT=100 > options IPFIREWALL_DEFAULT_TO_ACCEPT > options DUMMYNET > options ZERO_COPY_SOCKETS > options DEVICE_POLLING > options HZ=1000 > > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options DEBUG_VFS_LOCKS > options DIAGNOSTIC > options KDB > options KDB_UNATTENDED > options DDB > options GDB > options KDB_TRACE > options SOCKBUF_DEBUG > options BREAK_TO_DEBUGGER > > dmesg: > Copyright (c) 1992-2007 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-BETA4 #4: Fri Dec 7 12:45:37 UTC 2007 > root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/SOLNETDEBUG > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (1739.55-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 > > Features=0xbfebfbff > Features2=0x4e33d > AMD Features=0x20100800 > AMD Features2=0x1 > Cores per package: 2 > usable memory = 4258033664 (4060 MB) > avail memory = 4071751680 (3883 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > WITNESS: spin lock intrcnt not in order list > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > lapic0: Forcing LINT1 to edge trigger > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 900 > cpu0: on acpi0 > device_attach: acpi_perf0 attach returned 6 > device_attach: acpi_perf0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > device_attach: acpi_perf1 attach returned 6 > device_attach: acpi_perf1 attach returned 6 > p4tcc1: on cpu1 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > pcib0: port 0xca2,0xca3,0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: irq 16 at device 0.0 on pci1 > pci2: on pcib2 > pcib3: irq 16 at device 0.0 on pci2 > pci3: on pcib3 > pcib4: at device 0.0 on pci3 > pci4: on pcib4 > arcmsr0: > mem 0xc3d00000-0xc3d00fff,0xc3000000-0xc33fffff irq 18 at device 14.0 > on pci4 > ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 > arcmsr0: [ITHREAD] > pcib5: at device 0.2 on pci3 > pci5: on pcib5 > pcib6: irq 18 at device 2.0 on pci2 > pci6: on pcib6 > em0: port > 0x2020-0x203f mem 0xc3c20000-0xc3c3ffff,0xc3800000-0xc3bfffff irq 18 at > device 0.0 on pci6 > em0: Using MSI interrupt > em0: Ethernet address: 00:15:17:30:94:30 > em0: [FILTER] > em1: port > 0x2000-0x201f mem 0xc3c00000-0xc3c1ffff,0xc3400000-0xc37fffff irq 19 at > device 0.1 on pci6 > em1: Using MSI interrupt > em1: Ethernet address: 00:15:17:30:94:31 > em1: [FILTER] > pcib7: at device 0.3 on pci1 > pci7: on pcib7 > pcib8: at device 3.0 on pci0 > pci8: on pcib8 > pcib9: at device 4.0 on pci0 > pci9: on pcib9 > vgapci0: port 0x1000-0x107f mem > 0xc2000000-0xc2ffffff,0xb0000000-0xbfffffff,0xc0000000-0xc1ffffff irq 16 > at device 0.0 on pci9 > pcib10: at device 5.0 on pci0 > pci10: on pcib10 > pcib11: at device 6.0 on pci0 > pci11: on pcib11 > pcib12: at device 7.0 on pci0 > pci12: on pcib12 > pci0: at device 8.0 (no driver attached) > pci0: at device 27.0 (no driver attached) > pcib13: irq 16 at device 28.0 on pci0 > pci13: on pcib13 > uhci0: port > 0x3080-0x309f irq 23 at device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > uhci0: [ITHREAD] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > uhci1: port > 0x3060-0x307f irq 22 at device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > uhci1: [ITHREAD] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port > 0x3040-0x305f irq 23 at device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > uhci2: [ITHREAD] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > uhci3: port > 0x3020-0x303f irq 22 at device 29.3 on pci0 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem 0xc3f04400-0xc3f047ff irq > 23 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: on usb4 > uhub4: 8 ports with 8 removable, self powered > pcib14: at device 30.0 on pci0 > pci14: on pcib14 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30b0-0x30bf irq 20 at device 31.1 > on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x30c8-0x30cf,0x30e4-0x30e7,0x30c0-0x30c7,0x30e0-0x30e3,0x30a0-0x30af > mem 0xc3f04000-0xc3f043ff irq 20 at device 31.2 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > pci0: at device 31.3 (no driver attached) > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > sio0: type 16550A, console > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > sio1: [FILTER] > orm0: at iomem > 0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff on isa0 > ppc0: cannot reserve I/O port range > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding > disabled, default to accept, logging limited to 100 packets/entry by default > Waiting 5 seconds for SCSI devices to settle > acd0: DVDROM at ata0-master UDMA33 > da0 at arcmsr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da0: 238418MB (488281088 512 byte sectors: 255H 63S/T 30394C) > da1 at arcmsr0 bus 0 target 0 lun 1 > da1: Fixed Direct Access SCSI-5 device > da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da1: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) > da2 at arcmsr0 bus 0 target 0 lun 2 > da2: Fixed Direct Access SCSI-5 device > da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da2: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) > da3 at arcmsr0 bus 0 target 0 lun 3 > da3: Fixed Direct Access SCSI-5 device > da3: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da3: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) > da4 at arcmsr0 bus 0 target 0 lun 4 > da4: Fixed Direct Access SCSI-5 device > da4: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da4: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) > da5 at arcmsr0 bus 0 target 0 lun 5 > da5: Fixed Direct Access SCSI-5 device > da5: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da5: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) > da6 at arcmsr0 bus 0 target 0 lun 6 > da6: Fixed Direct Access SCSI-5 device > da6: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da6: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) > da7 at arcmsr0 bus 0 target 0 lun 7 > da7: Fixed Direct Access SCSI-5 device > da7: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) > da7: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) > lapic1: Forcing LINT1 to edge trigger > SMP: AP CPU #1 Launched! > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/da0s1a > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > ZFS filesystem version 6 > ZFS storage pool version 6 > em1: Hardware Initialization Failed > em1: Unable to initialize the hardware > Expensive timeout(9) function: 0xffffffff80258fe0(0xffffff00012fc000) > 0.008566172 s > em1: link state changed to UP > em1: link state changed to DOWN > em1: link state changed to UP > Expensive timeout(9) function: 0xffffffff80507ae0(0) 0.105003251 s > Expensive timeout(9) function: 0xffffffff80397260(0) 0.372032111 s > Expensive timeout(9) function: 0xffffffff80469350(0xffffff0069b5f888) > 0.403952336 s > > > my ipfw rules: > pipe 2 config bw 600Mbit/s queue 50KBytes > queue 201 config pipe 2 weight 1 mask dst-ip 0x0000000f queue 50 > queue 210 config pipe 2 weight 50 mask dst-ip 0x0000000f queue 50 > > > add 100 permit ip from any to any via lo0 > add 200 deny ip from any to 127.0.0.0/8 > > # Speedup Established > add 5001 skipto 8000 ip from 82.220.2.0/24 to 212.101.0.0/19 via em1 > add 6000 queue 210 ip from any to 212.101.0.0/19 out xmit em1 > add 6001 skipto 8000 ip from any to 212.101.0.0/19 out xmit em1 > add 6002 queue 210 ip from any to 212.41.65.0/18 out xmit em1 > add 6003 skipto 8000 ip from any to 212.41.65.0/18 out xmit em1 > add 6004 queue 210 ip from any to 82.220.0.0/18 out xmit em1 > add 6005 skipto 8000 ip from any to 82.220.0.0/18 out xmit em1 > add 6100 queue 201 ip from any to any out xmit em1 > > add 8000 permit tcp from any to any via em1 established > > # ICMP > add 11700 permit icmp from any to any via em1 icmptype 0,3,4,8,11,12 > > # Traceroute > add 1800 allow udp from any 30000-60000 to me 30000-60000 via em0 > > > # SSH (external connections are allowed for portsnap maintainer) > add 11900 allow ip from me to any ssh setup > add 11901 allow ip from any to me ssh setup > > # HTTP OUT > add 11910 permit tcp from me to any 80 setup via em1 > > # SMTP > add 12100 permit tcp from me to 212.101.0.0/19 25 setup via em1 > add 12110 allow tcp from me to any dst-port smtp via em1 setup > > # DNS UDP SolNet > add 21100 permit udp from 212.101.0.10 domain to me recv em1 > add 21101 permit udp from me to 212.101.0.10 domain out xmit em1 > add 21110 permit udp from 212.101.4.253 domain to me recv em1 > add 21111 permit udp from me to 212.101.4.253 domain out xmit em1 > add 21120 permit udp from 212.101.4.251 domain to me recv em1 > add 21121 permit udp from me to 212.101.4.251 domain out xmit em1 > > # NTP > add 21440 permit udp from me ntp to 212.101.0.0/19 ntp out xmit em1 > add 21445 permit udp from 224.0.1.1 ntp to 212.101.0.0/19 ntp out xmit em1 > add 21450 permit udp from 212.101.0.0/19 ntp to me ntp recv em1 > add 21460 permit udp from 212.101.0.0/19 ntp to 224.0.1.1 ntp recv em1 > add 21470 permit udp from me ntp to 224.0.1.1 ntp out xmit em1 > > > # WEB > add 22250 permit tcp from any to 212.101.4.241 80 setup via em1 limit > src-addr 4 > add 22251 permit tcp from any to 212.101.4.241 443 setup via em1 limit > src-addr 4 > add 22253 permit tcp from 212.101.4.241 to any 1024-65535 setup via em1 > > > # FTP > add 22300 permit tcp from any to 212.101.4.244 21 setup via em1 limit > src-addr 4 > add 22301 permit tcp from 212.101.4.244 to any 21 setup via em1 > add 22302 permit tcp from 212.101.4.244 20 to any 1024-65535 setup via em1 > add 22320 permit tcp from any 20 to 212.101.4.244 1024-65535 setup via em1 > add 22340 permit tcp from any to 212.101.4.244 49152-65535 setup via em1 > > # RSYNC > add 22400 permit tcp from 212.101.4.244 to any rsync setup via em1 > add 22410 permit tcp from any to me rsync setup via em1 > > # CVSUPD > add 22500 permit tcp from 212.101.4.244 to any cvsup setup via em1 > add 22510 permit tcp from any to me cvsup setup via em1 > > # > # NO WINDOWS > # > add 30000 deny udp from any to any 137 via em1 > > # Internal Interface > add 62000 allow tcp from 212.101.0.0/24 to any 22,23,25 via em0 setup > add 62010 allow tcp from 212.101.1.0/24 to any 22,23,25 via em0 setup > add 62020 allow tcp from 212.101.4.0/24 to any 22,25 via em0 setup > add 63000 reset tcp from any to any 22,23,25,3306,111 via em0 setup > add 65000 allow ip from any to any via em0 > > # F*** off the rest > add 65500 deny log ip from any to any > > If i load the ipfw rules i see: > > lock order reversal: > 1st 0xffffffff80839448 PFil hook read/write mutex (PFil hook read/write > mutex) @ /usr/src/sys/net/pfil.c:73 > 2nd 0xffffffff80838440 in_multi_mtx (in_multi_mtx) @ > /usr/src/sys/netinet/ip_output.c:302 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > witness_checkorder() at witness_checkorder+0x605 > _mtx_lock_flags() at _mtx_lock_flags+0x75 > ip_output() at ip_output+0x570 > dummynet_send() at dummynet_send+0x13f > dummynet_io() at dummynet_io+0x322 > ipfw_check_out() at ipfw_check_out+0x20a > pfil_run_hooks() at pfil_run_hooks+0xbc > ip_output() at ip_output+0x372 > udp_send() at udp_send+0x350 > sosend_dgram() at sosend_dgram+0x20f > kern_sendit() at kern_sendit+0x122 > sendit() at sendit+0xdc > sendto() at sendto+0x4d > syscall() at syscall+0x1f6 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (133, FreeBSD ELF64, sendto), rip = 0x800bebc8c, rsp = > 0x7fffffffe6c8, rbp = 0x551420 --- > Expensive timeout(9) function: 0xffffffff80469350(0xffffff004696e000) > 0.530255650 s > > > FreeBSD is installed on ufs but I have a zfs pool for my data. > Filesystem Size Used Avail Capacity Mounted on > /dev/da0s1a 496M 356M 100M 78% / > devfs 1.0K 1.0K 0B 100% /dev > /dev/da0s1g 169G 4.0K 155G 0% /disk1 > /dev/da0s1f 3.9G 902K 3.6G 0% /tmp > /dev/da0s1e 29G 3.9G 23G 15% /usr > /dev/da0s1d 19G 4.0G 14G 22% /var > pool 1.2T 0B 1.2T 0% /usr/local/data > pool/cvsup 1.2T 5.1G 1.2T 0% /usr/local/data/cvsup > pool/ftp 3.3T 2.2T 1.2T 65% /usr/local/data/ftp > pool/portsnap 1.2T 591M 1.2T 0% /usr/local/data/portsnap > pool/www 1.2T 78M 1.2T 0% /usr/local/data/www > > Any help? > > Best regards, > Thomas > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Please try this patch: http://www.freebsd.org/cgi/query-pr.cgi?prp=113548-3-diff and report does it help or not. -- Oleg. ================================================================ === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg@rinet.ru === ================================================================ From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 20:48:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CCC416A41A for ; Mon, 10 Dec 2007 20:48:50 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id E06EE13C461 for ; Mon, 10 Dec 2007 20:48:49 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by koef.zs64.net (8.14.1/8.14.1) with ESMTP id lBAKB6jg091142; Mon, 10 Dec 2007 21:11:06 +0100 (CET) (envelope-from cracauer@koef.zs64.net) Received: (from cracauer@localhost) by koef.zs64.net (8.14.1/8.14.1/Submit) id lBAKB6qw091141; Mon, 10 Dec 2007 15:11:06 -0500 (EST) (envelope-from cracauer) Date: Mon, 10 Dec 2007 15:11:06 -0500 From: Martin Cracauer To: Thomas Sparrevohn Message-ID: <20071210201106.GB90158@cons.org> References: <200712081728.18710.Thomas.Sparrevohn@btinternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712081728.18710.Thomas.Sparrevohn@btinternet.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 20:48:50 -0000 Thomas Sparrevohn wrote on Sat, Dec 08, 2007 at 05:28:18PM +0000: > > Hi > > There something weird going on - at minimal workloads my system gets very very hot - The system is watercooled, 4 Fan's etc > its a quad core QX6700 - make buildkernel - will make the fans run at highest speed (its impossibly to be in the room at the same time). > > There are no problems when running other OS'es - Are anybody else having this kind of problems (PS its a relatively new thing - maybe 2 weeks)? What does the coretemp module report for the real CPU temperature? I think it is perfectly normal for a buildkernel run to kick the CPU fan into highest gear. buildkernel is not a "minimal workload". buildkernel causes 100% load on one core even in non-parallel, and that one certainly gets hot. Since all 4 cores are in one CPU package, off the one CPU fan goes. I am curious why do you have temperature-controlled fans when you use watercooling. If the other OSes don't do this then they probably have some powermanagement going on and don't think that a buildkernel is worth kicking in high gear. You might want to compare with something that runs on both FreeBSD and Linux, such as a drystones run, or a Linux kernel compile (which you can run in FreeBSD's Linux emulation for comparision). Another way to track down a difference between FreeBSD and Linux is monitor the CPU frequency in /proc/cpuinfo on Linux. By default the Linux kernel on most distributions messes with that on Core2 systems. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 21:06:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2C0616A41B for ; Mon, 10 Dec 2007 21:06:42 +0000 (UTC) (envelope-from mharo-freebsd@haro.us) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.231]) by mx1.freebsd.org (Postfix) with ESMTP id 5507E13C44B for ; Mon, 10 Dec 2007 21:06:42 +0000 (UTC) (envelope-from mharo-freebsd@haro.us) Received: by wr-out-0506.google.com with SMTP id 68so1394141wra for ; Mon, 10 Dec 2007 13:06:41 -0800 (PST) Received: by 10.78.206.9 with SMTP id d9mr3298796hug.1197320799713; Mon, 10 Dec 2007 13:06:39 -0800 (PST) Received: by 10.78.199.10 with HTTP; Mon, 10 Dec 2007 13:06:39 -0800 (PST) Message-ID: Date: Mon, 10 Dec 2007 13:06:39 -0800 From: "Michael Haro" Sender: mharo-freebsd@haro.us To: "Alexandre Biancalana" In-Reply-To: <8e10486b0712100951m85f0278neb73ac4277779ba4@mail.gmail.com> MIME-Version: 1.0 References: <8e10486b0711280537n222d6cd5le33639b82a11f45@mail.gmail.com> <8e10486b0711300247q4438235ata70ca42030871286@mail.gmail.com> <20071130124801.74c40ef9@peedub.jennejohn.org> <8e10486b0712040521u5c7015b8h86d0da5554162898@mail.gmail.com> <47556554.3010505@clearchain.com> <8e10486b0712040719ydcf32e0mbe690c3f18968691@mail.gmail.com> <8e10486b0712100523k45c61865v7821d0522ad5f994@mail.gmail.com> <8e10486b0712100951m85f0278neb73ac4277779ba4@mail.gmail.com> X-Google-Sender-Auth: 2d8818b057f03ced 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-current@freebsd.org, Benjamin Close Subject: Re: 7-BETA3 everyday reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 21:06:42 -0000 On 12/10/07, Alexandre Biancalana wrote: > > On 12/10/07, Michael Haro wrote: > > > > > > > > On 12/10/07, Alexandre Biancalana wrote: > > > On 12/7/07, Michael Haro wrote: > > > > > > > > > > > > > > I have found that turning off zil and prefetch seem to keep > things > > > > > > happier on one of the heavily loaded servers that I look after. > > > > > > It also appears to prevent a deadlock under very heavy load - > > something > > > > > > I've not yet had time to debug. > > > > > > Try adding: > > > > > > > > > > > > vfs.zfs.zil_disable=1 > > > > > > vfs.zfs.prefetch_disable="1" > > > > > > > > > > > > to /boot/loader.conf > > > > > > > > > > > > and let us know if it makes a difference. > > > > > > > > > > Added now only > > > > > > > > > > vfs.zfs.prefetch_disable="1" > > > > > > > > > > > > > > > I let you know the result. > > > > > > > > Is the result promising? > > > > > > > > > > > Yes ! The machine does not reboot anymore ! > > > > What combination of settings did you have to do to make it stable? I > tried > > setting vfs.zfs.prefetch_disable="1' in loader.conf and my machine still > > panics within 20 minutes during (I think) large file transfers. > > > > > Here is my /boot/loader.conf: > > kern.maxdsiz="2G" # Set the max data size to 4GB > kern.maxssiz="1G" # Set the max stack size 2GB > > vfs.zfs.prefetch_disable="1" > vfs.zfs.arc_max="1G" > > vm.kmem_size_max="1500M" > vm.kmem_size="1500M" > > kern.ipc.nmbclusters="32768" > I only have 1G of RAM. Any ideas what good values would be? Right now I have vm.kmem_size and kmem_size_max set to 512M as the wiki recommended and vfs.zfs.prefetch_disable="1" with everything else at their defaults and I can easily panic the kernel. I'm using i386 with a RELENG_7 kernel as of yesterday. Does this match what you're using? I wonder if that makes a difference. Thanks From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 21:25:32 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CEE616A418 for ; Mon, 10 Dec 2007 21:25:32 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C959113C461 for ; Mon, 10 Dec 2007 21:25:31 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 1C40817104; Mon, 10 Dec 2007 20:56:34 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id lBAKuXH0028656; Mon, 10 Dec 2007 20:56:33 GMT (envelope-from phk@critter.freebsd.dk) To: Martin Cracauer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 10 Dec 2007 15:11:06 EST." <20071210201106.GB90158@cons.org> Date: Mon, 10 Dec 2007 20:56:33 +0000 Message-ID: <28655.1197320193@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Thomas Sparrevohn , freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 21:25:32 -0000 In message <20071210201106.GB90158@cons.org>, Martin Cracauer writes: I installed this on my laptop yesterday: FreeBSD critter.freebsd.dk 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Dec 9 10:41:25 UTC 2007 root@critter.freebsd.dk:/usr/obj/freebsd/src/sys/C5 i386 And it does indeed look like the idle threads do not HLT the cpu. Interestingly, powerd(8) does the right thing and throttles down the cpu clock even though the idle threads churn away. top -HS shows: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 root 171 ki31 0K 16K CPU1 1 25.2H 100.00% {idle: cpu1} 10 root 171 ki31 0K 16K RUN 0 25.2H 95.36% {idle: cpu0} 928 phk 45 0 319M 68624K *Giant 0 42:46 0.98% Xorg 28654 phk 44 0 3540K 1552K CPU1 0 0:01 0.98% top 982 phk 44 0 6500K 3940K select 1 11:03 0.29% xterm 11 root -24 - 0K 112K WAIT 1 19:49 0.00% {swi6: task queu -- 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. From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 21:51:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B15616A4A0 for ; Mon, 10 Dec 2007 21:51:35 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id F117E13C4E7 for ; Mon, 10 Dec 2007 21:51:34 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id lBALpSow036547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2007 13:51:29 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <475DB4E0.3060401@errno.com> Date: Mon, 10 Dec 2007 13:51:28 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Poul-Henning Kamp References: <28655.1197320193@critter.freebsd.dk> In-Reply-To: <28655.1197320193@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: o.com; whitelist Cc: Martin Cracauer , freebsd-current@freebsd.org, Thomas Sparrevohn Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 21:51:35 -0000 Poul-Henning Kamp wrote: > In message <20071210201106.GB90158@cons.org>, Martin Cracauer writes: > > I installed this on my laptop yesterday: > > FreeBSD critter.freebsd.dk 8.0-CURRENT FreeBSD 8.0-CURRENT > #0: Sun Dec 9 10:41:25 UTC 2007 > root@critter.freebsd.dk:/usr/obj/freebsd/src/sys/C5 i386 > > And it does indeed look like the idle threads do not HLT the cpu. > > Interestingly, powerd(8) does the right thing and throttles down > the cpu clock even though the idle threads churn away. > > top -HS shows: > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 10 root 171 ki31 0K 16K CPU1 1 25.2H 100.00% {idle: cpu1} > 10 root 171 ki31 0K 16K RUN 0 25.2H 95.36% {idle: cpu0} > 928 phk 45 0 319M 68624K *Giant 0 42:46 0.98% Xorg > 28654 phk 44 0 3540K 1552K CPU1 0 0:01 0.98% top > 982 phk 44 0 6500K 3940K select 1 11:03 0.29% xterm > 11 root -24 - 0K 112K WAIT 1 19:49 0.00% {swi6: task queu > This might also explain why I started to see buildworld overheat my t41 where previously I'd built world countless times w/o an issue. The only good thing that came out of that was that I verified thermal shutdown worked correctly and it uncovered a bug in acpi where a failed read would cause acpi to fall over (still unfixed). Sam From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 22:06:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D9B316A46E for ; Mon, 10 Dec 2007 22:06:54 +0000 (UTC) (envelope-from r.c.ladan@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 B06FA13C455 for ; Mon, 10 Dec 2007 22:06:53 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so78301uge.37 for ; Mon, 10 Dec 2007 14:06:52 -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:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=JVyi1bgFlMuNDqQCOoJ3aLjW7w3e+wLNNLyCRuRXeQg=; b=K5Gv88uaP/Td4LXevywyydNgvy0kfwJQ6DL5Zkc/OON/eMzok+0yIGeGJiix0TY/0dcE/uYxaclRM1DxvyQoZhOxN93VLjSCu+f3kFlMq2ZPNNddeMaku1TR4ofl4nm5Yh+aOqoyf8xbiEIk6HUc8SRvcXww/Y2O/1ErsMrVAq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=HKLNPrL/pb0OMthdguT7fEpExjUkJAke/mOQxlja+N7ipL+mJTRCLzE2kaGQg80YhnZj9SybMjV+HH6q9f1sbYoLa2pn+WUitmSnzZ06n+UrzKNLlaAmklIyWqtTvPAd/jOBIhRaqSn/TFUS/ZKbOTouQFjrtXUQOGDiCXI01hI= Received: by 10.78.132.2 with SMTP id f2mr3907357hud.1197324412088; Mon, 10 Dec 2007 14:06:52 -0800 (PST) Received: from ip4da3ae31.direct-adsl.nl.0.163.77.in-addr.arpa ( [77.163.174.49]) by mx.google.com with ESMTPS id i4sm456013nfh.2007.12.10.14.06.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Dec 2007 14:06:50 -0800 (PST) Message-ID: <475DB877.1060306@gmail.com> Date: Mon, 10 Dec 2007 23:06:47 +0100 From: Rene Ladan User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Poul-Henning Kamp References: <28655.1197320193@critter.freebsd.dk> In-Reply-To: <28655.1197320193@critter.freebsd.dk> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Martin Cracauer , freebsd-current@freebsd.org, Thomas Sparrevohn Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 22:06:54 -0000 Poul-Henning Kamp schreef: > In message <20071210201106.GB90158@cons.org>, Martin Cracauer writes: > > I installed this on my laptop yesterday: > > FreeBSD critter.freebsd.dk 8.0-CURRENT FreeBSD 8.0-CURRENT > #0: Sun Dec 9 10:41:25 UTC 2007 > root@critter.freebsd.dk:/usr/obj/freebsd/src/sys/C5 i386 > > And it does indeed look like the idle threads do not HLT the cpu. > > Interestingly, powerd(8) does the right thing and throttles down > the cpu clock even though the idle threads churn away. > > top -HS shows: > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 10 root 171 ki31 0K 16K CPU1 1 25.2H 100.00% {idle: cpu1} > 10 root 171 ki31 0K 16K RUN 0 25.2H 95.36% {idle: cpu0} > 928 phk 45 0 319M 68624K *Giant 0 42:46 0.98% Xorg > 28654 phk 44 0 3540K 1552K CPU1 0 0:01 0.98% top > 982 phk 44 0 6500K 3940K select 1 11:03 0.29% xterm > 11 root -24 - 0K 112K WAIT 1 19:49 0.00% {swi6: task queu > Similar results here: last pid: 1698; load averages: 0.18, 0.08, 0.02 up 0+02:09:26 23:00:57 139 processes: 4 running, 116 sleeping, 19 waiting CPU states: % user, % nice, % system, % interrupt, % idle Mem: 250M Active, 211M Inact, 119M Wired, 19M Cache, 112M Buf, 1405M Free Swap: 4062M Total, 4062M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 root 171 ki31 0K 16K RUN 0 242:19 91.21% {idle: cpu0} 10 root 171 ki31 0K 16K RUN 1 242:19 84.72% {idle: cpu1} hw.acpi.thermal.tz0.temperature goes up from ~35C to >47C after logging in at the console. The box is otherwise idle. This is with SCHED_4BSD, PREEMPTION, IPI_PREEMPTION, MPTABLE_FORCE_HTT, STOP_NMI and the debugging options for CURRENT. Note that the TIME values are doubled in top (242:19 == 04:02:19 ~= 2*(02:09:26) ) Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 22:42:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48D7516A419 for ; Mon, 10 Dec 2007 22:42:33 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 56B3C13C457 for ; Mon, 10 Dec 2007 22:42:28 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so525825pyb for ; Mon, 10 Dec 2007 14:42:25 -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=9bBKbMlU4gAh+BKB/3/VqcGILe8gMWg9tJaEedQKgyg=; b=dde9lwLusF68kyJjEmwAQSYi40Q48d0KZCX7s9vLq7/SK6ujTc0O1/gBVuCS/Mq7iOxnL0bUedGW8NKsEe6bflf6G55HFMYWeljPCYmQMurHY0ftem9lXxkSalKRjsJZvP1R8NyPKeYJiXzJ8Dy5HU5HmzRA2tC9l+wKJRaEkhM= 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=oNmelwMr3/blTqQc1TupL/YEf3OYjlKBEdwK62aEOPlSeqggaSnaz+Kdw3OIbQ+vMrOUadpyWcChi848cdQO0fK2SfXHdIKR4ZypDJYK8QUpATy0vo8wV3bHFILbpgrrNuR09mdbuqb2XuLdslAa/fRHhiYNC5RfgazPtmy+JKY= Received: by 10.65.40.16 with SMTP id s16mr15185501qbj.1197326543982; Mon, 10 Dec 2007 14:42:23 -0800 (PST) Received: by 10.64.184.9 with HTTP; Mon, 10 Dec 2007 14:42:23 -0800 (PST) Message-ID: <8e10486b0712101442g4bf07385t129f04faa4cf8c4e@mail.gmail.com> Date: Mon, 10 Dec 2007 19:42:23 -0300 From: "Alexandre Biancalana" To: "Michael Haro" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0711280537n222d6cd5le33639b82a11f45@mail.gmail.com> <20071130124801.74c40ef9@peedub.jennejohn.org> <8e10486b0712040521u5c7015b8h86d0da5554162898@mail.gmail.com> <47556554.3010505@clearchain.com> <8e10486b0712040719ydcf32e0mbe690c3f18968691@mail.gmail.com> <8e10486b0712100523k45c61865v7821d0522ad5f994@mail.gmail.com> <8e10486b0712100951m85f0278neb73ac4277779ba4@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: 7-BETA3 everyday reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 22:42:33 -0000 On Dec 10, 2007 6:06 PM, Michael Haro wrote: > > > > On 12/10/07, Alexandre Biancalana wrote: > > On 12/10/07, Michael Haro wrote: > > > > > > > > > > > > On 12/10/07, Alexandre Biancalana wrote: > > > > On 12/7/07, Michael Haro wrote: > > Here is my /boot/loader.conf: > > > > kern.maxdsiz="2G" # Set the max data size to 4GB > > kern.maxssiz="1G" # Set the max stack size 2GB > > > > vfs.zfs.prefetch_disable="1" > > vfs.zfs.arc_max="1G" > > > > vm.kmem_size_max="1500M" > > vm.kmem_size="1500M" > > > > kern.ipc.nmbclusters="32768" > > > > I only have 1G of RAM. Any ideas what good values would be? > Right now I have > vm.kmem_size and kmem_size_max set to 512M as the wiki recommended and > vfs.zfs.prefetch_disable="1" with everything else at their defaults and I > can easily panic the kernel. > > I'm using i386 with a RELENG_7 kernel as of yesterday. Does this match what > you're using? I wonder if that makes a difference. Try to limit the arc size to something like this in your loader.conf vfs.zfs.arc_max="320M" From owner-freebsd-current@FreeBSD.ORG Mon Dec 10 23:10:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F006516A418; Mon, 10 Dec 2007 23:10:30 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [82.230.37.243]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9BF13C43E; Mon, 10 Dec 2007 23:10:30 +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 36FDE3A526; Mon, 10 Dec 2007 23:54:25 +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 Uv5uritWUbgc; Mon, 10 Dec 2007 23:54:22 +0100 (CET) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id 3EA3A3A0A3; Mon, 10 Dec 2007 23:54:22 +0100 (CET) Date: Mon, 10 Dec 2007 23:54:22 +0100 From: Ollivier Robert To: freebsd-current@freebsd.org, freebsd-doc@freebsd.org Message-ID: <20071210225421.GA28116@keltia.freenix.fr> References: <20071209234943.GB2112@kobe.laptop> <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 6.2 / Dell D820 SMP User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2007 23:10:31 -0000 According to Ivan Voras: > And this gives it the right to block system from booting? I'd at least > like a symlink from "true" to "fsck_tmpfs". It is in the are of « it hurts when I do this. Then don't do that! ». Like someone else said, "0" should be used on special fs (like nfs). -- 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-current@FreeBSD.ORG Tue Dec 11 00:43:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE4FA16A418 for ; Tue, 11 Dec 2007 00:43:41 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3348313C448 for ; Tue, 11 Dec 2007 00:43:40 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (vader.bytemobile-rio.ondsl.gr [83.235.57.37]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id lBB0h5gi005790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Dec 2007 02:43:25 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id lBB0h0hB011195; Tue, 11 Dec 2007 02:43:00 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id lBB0gxgx011194; Tue, 11 Dec 2007 02:42:59 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Tue, 11 Dec 2007 02:42:59 +0200 From: Giorgos Keramidas To: Reko Turja , rrs@freebsd.org Message-ID: <20071211004258.GA11140@kobe.laptop> References: <20071210002131.GA74729@kobe.laptop> <002801c83b05$56ab20b0$3a2a13ac@staff.ktc.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002801c83b05$56ab20b0$3a2a13ac@staff.ktc.lan> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.103, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.30, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Ivan Voras Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 00:43:41 -0000 On 2007-12-10 10:19, Reko Turja wrote: >>> > => SCTP depends on IPv6 >>> > >>> > This is clearly documented in NOTES. I don't think it should >>> > count as a surprising fact. >>> >>> I know it's in the NOTES - I've added it when it bit me since I >>> didn't read the notes. Maybe I'll remove it. >> >> If it bit you, an experienced FreeBSD developer, it can bite others >> too. Let's work with re@ to get it in the release notes, if it's not >> already there (instead of deleting it from the list) :-) >> >> My last CVSup is from Wed Dec 05 19:32:59 2007 +0000 (right before I >> started preparing for Friday's FreeBSD talk at a nearby university), >> so I'll CVSup again tomorrow morning, and check how we can fit this >> into the release notes in a nice, non-intrusive but still useful >> manner. > > How about making a comment about the requirement in the GENERIC > config file, in a manner used for device 'ed' or device 'sbp' for example? > > ... > options INET6 # IPv6 communications protocols > options SCTP # Stream Control Transmission > Protocol > # SCTP requires 'options > INET6' > options FFS > ... > > Or are the comments about in requirement at 'GENERIC' phased out? Does the following look ok? %%% diff -r eae64e5226db sys/i386/conf/GENERIC --- a/sys/i386/conf/GENERIC Mon Dec 10 12:03:23 2007 +0000 +++ b/sys/i386/conf/GENERIC Tue Dec 11 02:41:27 2007 +0200 @@ -32,7 +32,7 @@ options PREEMPTION # Enable kernel thr options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols -options SCTP # Stream Control Transmission Protocol +options SCTP # Stream Control Transmission Protocol (requires INET6) options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists %%% It's simple enough, and we already have a few lines which are a bit `longish' in GENERIC. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 00:45:51 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB0DF16A468 for ; Tue, 11 Dec 2007 00:45:51 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2A713C43E for ; Tue, 11 Dec 2007 00:45:50 +0000 (UTC) (envelope-from keramida@FreeBSD.org) Received: from kobe.laptop (vader.bytemobile-rio.ondsl.gr [83.235.57.37]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id lBB0jbo8005903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Dec 2007 02:45:43 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id lBB0jWGm011259; Tue, 11 Dec 2007 02:45:32 +0200 (EET) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id lBB0jWdU011258; Tue, 11 Dec 2007 02:45:32 +0200 (EET) (envelope-from keramida@FreeBSD.org) Date: Tue, 11 Dec 2007 02:45:31 +0200 From: Giorgos Keramidas To: Reko Turja , rrs@FreeBSD.org Message-ID: <20071211004531.GB11140@kobe.laptop> References: <20071210002131.GA74729@kobe.laptop> <002801c83b05$56ab20b0$3a2a13ac@staff.ktc.lan> <20071211004258.GA11140@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071211004258.GA11140@kobe.laptop> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.101, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.30, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@FreeBSD.org, Ivan Voras Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 00:45:51 -0000 On 2007-12-11 02:42, Giorgos Keramidas wrote: > Does the following look ok? > > %%% > diff -r eae64e5226db sys/i386/conf/GENERIC A more complete patch, touching GENERIC for all architectures would be like the following patch, of course: %%% diff -r eae64e5226db sys/amd64/conf/GENERIC --- a/sys/amd64/conf/GENERIC Mon Dec 10 12:03:23 2007 +0000 +++ b/sys/amd64/conf/GENERIC Tue Dec 11 02:44:22 2007 +0200 @@ -30,7 +30,7 @@ options PREEMPTION # Enable kernel thr options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols -options SCTP # Stream Control Transmission Protocol +options SCTP # Stream Control Transmission Protocol (requires INET6) options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists diff -r eae64e5226db sys/i386/conf/GENERIC --- a/sys/i386/conf/GENERIC Mon Dec 10 12:03:23 2007 +0000 +++ b/sys/i386/conf/GENERIC Tue Dec 11 02:44:22 2007 +0200 @@ -32,7 +32,7 @@ options PREEMPTION # Enable kernel thr options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols -options SCTP # Stream Control Transmission Protocol +options SCTP # Stream Control Transmission Protocol (requires INET6) options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists diff -r eae64e5226db sys/ia64/conf/GENERIC --- a/sys/ia64/conf/GENERIC Mon Dec 10 12:03:23 2007 +0000 +++ b/sys/ia64/conf/GENERIC Tue Dec 11 02:44:22 2007 +0200 @@ -34,7 +34,7 @@ options GDB # Support remote GDB options GDB # Support remote GDB options INET # InterNETworking options INET6 # IPv6 communications protocols -options SCTP # Stream Control Transmission Protocol +options SCTP # Stream Control Transmission Protocol (requires INET6) options KDB # Enable kernel debugger support options KTRACE # ktrace(1) syscall trace support options MD_ROOT # MD usable as root device diff -r eae64e5226db sys/pc98/conf/GENERIC --- a/sys/pc98/conf/GENERIC Mon Dec 10 12:03:23 2007 +0000 +++ b/sys/pc98/conf/GENERIC Tue Dec 11 02:44:22 2007 +0200 @@ -32,7 +32,7 @@ options SCHED_4BSD # 4BSD scheduler #options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols -options SCTP # Stream Control Transmission Protocol +options SCTP # Stream Control Transmission Protocol (requires INET6) options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists diff -r eae64e5226db sys/powerpc/conf/GENERIC --- a/sys/powerpc/conf/GENERIC Mon Dec 10 12:03:23 2007 +0000 +++ b/sys/powerpc/conf/GENERIC Tue Dec 11 02:44:22 2007 +0200 @@ -33,7 +33,7 @@ options SCHED_ULE #ULE scheduler options SCHED_ULE #ULE scheduler options INET #InterNETworking options INET6 #IPv6 communications protocols -options SCTP #Stream Control Transmission Protocol +options SCTP #Stream Control Transmission Protocol (requires INET6) options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists diff -r eae64e5226db sys/sparc64/conf/GENERIC --- a/sys/sparc64/conf/GENERIC Mon Dec 10 12:03:23 2007 +0000 +++ b/sys/sparc64/conf/GENERIC Tue Dec 11 02:44:22 2007 +0200 @@ -35,7 +35,7 @@ options SCHED_4BSD # 4BSD scheduler #options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols -options SCTP # Stream Control Transmission Protocol +options SCTP # Stream Control Transmission Protocol (requires INET6) options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists diff -r eae64e5226db sys/sun4v/conf/GENERIC --- a/sys/sun4v/conf/GENERIC Mon Dec 10 12:03:23 2007 +0000 +++ b/sys/sun4v/conf/GENERIC Tue Dec 11 02:44:22 2007 +0200 @@ -33,7 +33,7 @@ options SCHED_4BSD # 4BSD scheduler #options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols -options SCTP # Stream Control Transmission Protocol +options SCTP # Stream Control Transmission Protocol (requires INET6) options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists %%% From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 02:32:21 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C20116A417 for ; Tue, 11 Dec 2007 02:32:21 +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 D9E7013C43E for ; Tue, 11 Dec 2007 02:32:20 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A5012.dip.t-dialin.net [84.154.80.18]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id lBB2WHA7002792; Tue, 11 Dec 2007 02:32:18 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 lBB2XAZm082618; Tue, 11 Dec 2007 03:33:11 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id lBB2XAtl090250; Tue, 11 Dec 2007 03:33:10 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200712110233.lBB2XAtl090250@fire.js.berklix.net> To: current@freebsd.org From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich/Muenchen. User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com/~jhs/cv/ Date: Tue, 11 Dec 2007 03:33:10 +0100 Sender: jhs@berklix.org Cc: ghozzy@gmail.com Subject: PLIP - Parallel IP - does it still work ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 02:32:21 -0000 Hi current@ Has anyone used PLIP - Parallel IP on any of FreeBSD- 5,6,7 ? I last saw it working on 4.11-RELEASE, ghozzy@gmail.com saw it fail too http://www.berklix.com/~jhs/hardware/laptops/#plip A laptop here: Dell Latitude XPi P133ST http://www.berklix.com/~jhs/hardware/laptops/#hosts has problems with 7.0BETA4 on all of pcmcia cdrom, pcmcia ep0 ether, & ATA geom/ MBR (wont accept 2nd partition so cant store 7.0 cdrom files on 2nd partition), so Ive been trying PLIP - No luck. ( If PLIP doesnt work I only have 2 options left: SLIP or rip the drive out & install on another host, & hope the BIOS's compatible on disk layout. ) Julian - -- Julian Stacey. Munich Consultant: BSD Unix Linux. http://berklix.com Ihr Rauch=mein allergischer Kopfschmerz. Dump cigs 4 snuff. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 02:37:15 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7F6B16A417 for ; Tue, 11 Dec 2007 02:37:15 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id 81CAC13C465 for ; Tue, 11 Dec 2007 02:37:15 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from [216.89.228.170] (host-216-89-228-170.wireless.terranova.net [216.89.228.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTP id AE33929B5FB; Mon, 10 Dec 2007 21:37:14 -0500 (EST) Message-ID: <475DF7D8.2020203@terranova.net> Date: Mon, 10 Dec 2007 21:37:12 -0500 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= , freebsd-current@freebsd.org References: <73807.10710.qm@web63912.mail.re1.yahoo.com> <200711280842.09340.jhb@freebsd.org> <474D726A.8080807@deepcore.dk> <200711280938.38545.jhb@freebsd.org> <474E5B69.7070406@yandex.ru> <474E65D6.4040403@deepcore.dk> <474E69AE.7000105@yandex.ru> <475978E1.2090507@deepcore.dk> <475C6C3E.6070004@deepcore.dk> <475CC426.3060808@terranova.net> <475CCAA0.5040900@terranova.net> <475CEA07.1050500@deepcore.dk> In-Reply-To: <475CEA07.1050500@deepcore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: Any successful installs on a Broadcom HT1000 chipset? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 02:37:15 -0000 Søren Schmidt wrote: > Yep, I'm not convinced there are "generic" DMA problems with that > chipset, but the ATA part definitively has trouble, I'm (slowly) working > my way through the different results here to try pinpoint the problem > more precisely. > I'm also going to try a Marvell ctlr later today, more news later... Ah, very good, I was going to ask if you needed a Marvell PCI-X controller. You're by far the expert compared to me in this arena, but I was having the exact same issue (including the memory corruption) when booting from the Marvell PCI-X SATA controller... smells like a somewhat generic HT1000 barfing-on-DMA problem to my inexperienced nose :) >> I also see this isn't first and only chipset to have the exact same >> dma max_iosize limit imposed :) > Right, the usual need for this limit is that the 64K size means that the > count reg is set to zero, and some HW designers just didn't get that right. > > In this case its different as it does not always fail, but I havn't > found the combo that makes it fail yet. However the workaround seems to > be quite solid, but there might be a better / more correct way to solve > it still. Perhaps something could be devised involving a kernel option that works around the errata? Wouldn't be the first time. options HT1000_WORKAROUND... would suck if it involved making an ifdef for every ata driver :( -- TerraNovaNet Internet Services - Key Largo, FL Voice: (305)453-4011 x101 Fax: (305)451-5991 http://www.terranova.net/ ---------------------------------------------- Life's not fair, but the root password helps. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 04:01:31 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D665616A418 for ; Tue, 11 Dec 2007 04:01:31 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 5B38013C455 for ; Tue, 11 Dec 2007 04:01:31 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1371345nfb for ; Mon, 10 Dec 2007 20:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=Xan2GDxOVjlblLh6jc1T6nRgSQ0U0/RCX+X0Q1oGdo4=; b=HsWRiEMYOWTQ9x66yNzYgJZwFjxwjr74YPdVgEkiC5+4BcvQKDX6asJ/UtFHP2Qrhdbq3BcPEYBFbfm1Bi4dDVVKC7PfBu6J8cmArBBisg2qfJ1Wgq3+QGdJfvN2YgyAVUb7RKFEBpU/pE4aG4mE+BbCtOAQj/hDGsZ6q9y3AEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=ZOG2vx7w5cGzB9wKhUTG2nDIOj+BG7rzMTWtihau6BVTJwsfAQLoZwaUwtuDWLp2vsvNRrIC+cJj20I6Bt+mwllmM3dbuOthlxpHWMS1Df88FGBdLYV5SF/AL6WA9kI3CDViWo1tXYr6zZY9mbMUmZigCgdVhPV028t494pQct0= Received: by 10.86.60.7 with SMTP id i7mr319660fga.1197345689941; Mon, 10 Dec 2007 20:01:29 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id w7sm10067137mue.2007.12.10.20.01.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2007 20:01:28 -0800 (PST) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Tue, 11 Dec 2007 06:01:32 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> <20071210002131.GA74729@kobe.laptop> In-Reply-To: <20071210002131.GA74729@kobe.laptop> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4957032.RBAYOA31Wu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712110601.32453.qpadla@gmail.com> Cc: Giorgos Keramidas , freebsd-doc@freebsd.org, Ivan Voras Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 04:01:31 -0000 --nextPart4957032.RBAYOA31Wu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 10 December 2007 02:21:31 Giorgos Keramidas wrote: > What are the `use cases' of the > tmpfs filesystem, other than memory-backed /tmp mounts? You can also mount the dirs that do not need to survive after reboot=20 like /var/run or /var/lock. Also i think you can use it the same way as=20 plain old md device: on livecd's etc... =20 =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart4957032.RBAYOA31Wu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHXguc/2R6KvEYGaIRAvpXAJ4lo1idzsGNWyUkbaDvnidBUTgtxQCbBp/z UmUqyAeYKbewa9qC3Gu9FxE= =gLh+ -----END PGP SIGNATURE----- --nextPart4957032.RBAYOA31Wu-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 04:03:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD4DF16A41A for ; Tue, 11 Dec 2007 04:03:24 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 40BD313C447 for ; Tue, 11 Dec 2007 04:03:23 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1371713nfb for ; Mon, 10 Dec 2007 20:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=2z5T6UJGjXcvfozH1OQjzyO+/sClxwEp5JbhTgIeyZU=; b=XYsWVJpq9UHINFVNIcNQPZdr4U0LSqdaPMBVXWixhj8p7lhhNUmvPexeKzJavnLxblqCWvHTBYBWC5CMVGT5NSlayeiyN5VggYOXik8U6/xsJCU5xa6wTsfmZg+2pkvxOghNTYhvQMvEPgHXbtV2e3rlET8KA1QY3FBfZutNN0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=N1WON4CrXNhv+fWUaL2e0FuvwPrbVo6BecG/q26nLQzFrXdqlMQGexmYmR9G87/u7r2IZa4wxlPo1VSd1O4UKTOEt75U5lbjHSldDdrP05sPF3aMq4v4bT/a++QilghiF5zgUbfy+RqGeTvWMowDTjdrciipjAEMAsRA7mSbxDo= Received: by 10.86.76.16 with SMTP id y16mr6269852fga.1197345802977; Mon, 10 Dec 2007 20:03:22 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id u9sm10131940muf.2007.12.10.20.03.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2007 20:03:21 -0800 (PST) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Tue, 11 Dec 2007 06:03:25 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <8e10486b0711280537n222d6cd5le33639b82a11f45@mail.gmail.com> <8e10486b0712100951m85f0278neb73ac4277779ba4@mail.gmail.com> In-Reply-To: <8e10486b0712100951m85f0278neb73ac4277779ba4@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1209068.nuQNDBoAzd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712110603.25769.qpadla@gmail.com> Cc: Benjamin Close , Michael Haro , Alexandre Biancalana Subject: Re: 7-BETA3 everyday reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 04:03:24 -0000 --nextPart1209068.nuQNDBoAzd Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 10 December 2007 19:51:32 Alexandre Biancalana wrote: > Here is my /boot/loader.conf: > > kern.maxdsiz=3D"2G" =A0 =A0 =A0 # Set the max data size to 4GB > kern.maxssiz=3D"1G" =A0 =A0 =A0 # Set the max stack size 2GB > > vfs.zfs.prefetch_disable=3D"1" > vfs.zfs.arc_max=3D"1G" > > vm.kmem_size_max=3D"1500M" > vm.kmem_size=3D"1500M" > > kern.ipc.nmbclusters=3D"32768" Is this i386 or amd64? =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart1209068.nuQNDBoAzd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHXgwN/2R6KvEYGaIRAs0iAKCVDiSNiD2/vpFoTWaFbTZvxly+jwCgu3WZ BDOxgCGUbUquyg5vVI7lSWQ= =kEXI -----END PGP SIGNATURE----- --nextPart1209068.nuQNDBoAzd-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 07:15:45 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9549216A46E for ; Tue, 11 Dec 2007 07:15:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 55E8613C457 for ; Tue, 11 Dec 2007 07:15:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4B98917104; Tue, 11 Dec 2007 07:15:43 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id lBB7Fg9i030985; Tue, 11 Dec 2007 07:15:42 GMT (envelope-from phk@critter.freebsd.dk) To: "Julian Stacey" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 11 Dec 2007 03:33:10 +0100." <200712110233.lBB2XAtl090250@fire.js.berklix.net> Date: Tue, 11 Dec 2007 07:15:42 +0000 Message-ID: <30984.1197357342@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@freebsd.org, ghozzy@gmail.com Subject: Re: PLIP - Parallel IP - does it still work ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 07:15:45 -0000 In message <200712110233.lBB2XAtl090250@fire.js.berklix.net>, "Julian Stacey" w rites: >( If PLIP doesnt work I only have 2 options left: SLIP or rip the > drive out & install on another host, & hope the BIOS's compatible > on disk layout. ) PLIP is sensitive to cpu clock speeds, you may have to extend the loops somewhat in order to give all the EMC/EMI protection time to pass the signals. -- 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. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 07:31:32 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C66216A468; Tue, 11 Dec 2007 07:31:32 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 3AAA113C468; Tue, 11 Dec 2007 07:31:32 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 861F71B10EED; Tue, 11 Dec 2007 08:31:30 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from [10.1.1.3] (unknown [192.168.25.6]) by blah.sun-fish.com (Postfix) with ESMTP id BE39F1B10D0F; Tue, 11 Dec 2007 08:31:27 +0100 (CET) Message-ID: <475E3CCB.40709@moneybookers.com> Date: Tue, 11 Dec 2007 09:31:23 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Giorgos Keramidas References: <20071210002131.GA74729@kobe.laptop> <002801c83b05$56ab20b0$3a2a13ac@staff.ktc.lan> <20071211004258.GA11140@kobe.laptop> In-Reply-To: <20071211004258.GA11140@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5083/Tue Dec 11 07:22:03 2007 on blah.cmotd.com X-Virus-Status: Clean Cc: Reko Turja , rrs@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 07:31:32 -0000 Hi, Giorgos Keramidas wrote: > On 2007-12-10 10:19, Reko Turja wrote: > >>>>> => SCTP depends on IPv6 >>>>> >>>>> This is clearly documented in NOTES. I don't think it should >>>>> count as a surprising fact. >>>>> >>>> I know it's in the NOTES - I've added it when it bit me since I >>>> didn't read the notes. Maybe I'll remove it. >>>> >>> If it bit you, an experienced FreeBSD developer, it can bite others >>> too. Let's work with re@ to get it in the release notes, if it's not >>> already there (instead of deleting it from the list) :-) >>> >>> My last CVSup is from Wed Dec 05 19:32:59 2007 +0000 (right before I >>> started preparing for Friday's FreeBSD talk at a nearby university), >>> so I'll CVSup again tomorrow morning, and check how we can fit this >>> into the release notes in a nice, non-intrusive but still useful >>> manner. >>> >> How about making a comment about the requirement in the GENERIC >> config file, in a manner used for device 'ed' or device 'sbp' for example? >> >> ... >> options INET6 # IPv6 communications protocols >> options SCTP # Stream Control Transmission >> Protocol >> # SCTP requires 'options >> INET6' >> options FFS >> ... >> >> Or are the comments about in requirement at 'GENERIC' phased out? >> > > Does the following look ok? > > %%% > diff -r eae64e5226db sys/i386/conf/GENERIC > --- a/sys/i386/conf/GENERIC Mon Dec 10 12:03:23 2007 +0000 > +++ b/sys/i386/conf/GENERIC Tue Dec 11 02:41:27 2007 +0200 > @@ -32,7 +32,7 @@ options PREEMPTION # Enable kernel thr > options PREEMPTION # Enable kernel thread preemption > options INET # InterNETworking > options INET6 # IPv6 communications protocols > -options SCTP # Stream Control Transmission Protocol > +options SCTP # Stream Control Transmission Protocol (requires INET6) > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control lists > %%% > > It's simple enough, and we already have a few lines which are a bit > `longish' in GENERIC. > > I feel that "requires INET6" have to be changed to "requires both INET and INET6", or just leave comments in NOTES., because the offered change is inaccurate. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 08:17:06 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3303216A417 for ; Tue, 11 Dec 2007 08:17:06 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 48EFB13C45A for ; Tue, 11 Dec 2007 08:17:05 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost.bsdunix.ch [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id E236F5E47; Tue, 11 Dec 2007 09:17:03 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MhMKF-Kq1Q3B; Tue, 11 Dec 2007 09:16:59 +0100 (CET) Received: from thomas-vogts-powerbook-g4-12.local (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 50F545E45; Tue, 11 Dec 2007 09:16:59 +0100 (CET) Message-ID: <475E477A.80802@bsdunix.ch> Date: Tue, 11 Dec 2007 09:16:58 +0100 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070807) MIME-Version: 1.0 To: Oleg Bulyzhin References: <475D5CF7.2020803@bsdunix.ch> <20071210183100.GA32000@lath.rinet.ru> In-Reply-To: <20071210183100.GA32000@lath.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 7.0Beta4 (amd64) freezes with dummynet enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 08:17:06 -0000 Hi Oleg Bulyzhin wrote: > On Mon, Dec 10, 2007 at 04:36:23PM +0100, Thomas Vogt wrote: >> Hi, >> >> I kindly ask for advice for debugging a problem with 7.0-Beta 4 (amd64). >> >> The machine freezes if dummynet rules are enabled on a gigabit port. The >> system runs fine on fast ethernet or with dummynet rules disabled. I >> can't trigger the bug if my upstream port is limited to 100mbit. The >> machine suddenly freezes after 3-4 minutes if dummynet rules are loaded. >> >> My Kernel already includes some debug options but I'm not able to >> produce a panic. >> >> Kernel: >> options IPFIREWALL >> options IPFIREWALL_VERBOSE >> options IPFIREWALL_VERBOSE_LIMIT=100 >> options IPFIREWALL_DEFAULT_TO_ACCEPT >> options DUMMYNET >> options ZERO_COPY_SOCKETS >> options DEVICE_POLLING >> options HZ=1000 >> >> options INVARIANTS >> options INVARIANT_SUPPORT >> options WITNESS >> options DEBUG_VFS_LOCKS >> options DIAGNOSTIC >> options KDB >> options KDB_UNATTENDED >> options DDB >> options GDB >> options KDB_TRACE >> options SOCKBUF_DEBUG >> options BREAK_TO_DEBUGGER >> >> dmesg: >> Copyright (c) 1992-2007 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 7.0-BETA4 #4: Fri Dec 7 12:45:37 UTC 2007 >> root@lisa.mlan.solnet.ch:/usr/obj/usr/src/sys/SOLNETDEBUG >> WARNING: WITNESS option enabled, expect reduced performance. >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (1739.55-MHz >> K8-class CPU) >> Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 >> >> Features=0xbfebfbff >> Features2=0x4e33d >> AMD Features=0x20100800 >> AMD Features2=0x1 >> Cores per package: 2 >> usable memory = 4258033664 (4060 MB) >> avail memory = 4071751680 (3883 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> WITNESS: spin lock intrcnt not in order list >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 24-47 on motherboard >> lapic0: Forcing LINT1 to edge trigger >> kbd1 at kbdmux0 >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: reservation of 0, a0000 (3) failed >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on >> acpi0 >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> cpu0: on acpi0 >> device_attach: acpi_perf0 attach returned 6 >> device_attach: acpi_perf0 attach returned 6 >> p4tcc0: on cpu0 >> cpu1: on acpi0 >> device_attach: acpi_perf1 attach returned 6 >> device_attach: acpi_perf1 attach returned 6 >> p4tcc1: on cpu1 >> acpi_button0: on acpi0 >> acpi_button1: on acpi0 >> pcib0: port 0xca2,0xca3,0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: at device 2.0 on pci0 >> pci1: on pcib1 >> pcib2: irq 16 at device 0.0 on pci1 >> pci2: on pcib2 >> pcib3: irq 16 at device 0.0 on pci2 >> pci3: on pcib3 >> pcib4: at device 0.0 on pci3 >> pci4: on pcib4 >> arcmsr0: >> mem 0xc3d00000-0xc3d00fff,0xc3000000-0xc33fffff irq 18 at device 14.0 >> on pci4 >> ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 >> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 >> arcmsr0: [ITHREAD] >> pcib5: at device 0.2 on pci3 >> pci5: on pcib5 >> pcib6: irq 18 at device 2.0 on pci2 >> pci6: on pcib6 >> em0: port >> 0x2020-0x203f mem 0xc3c20000-0xc3c3ffff,0xc3800000-0xc3bfffff irq 18 at >> device 0.0 on pci6 >> em0: Using MSI interrupt >> em0: Ethernet address: 00:15:17:30:94:30 >> em0: [FILTER] >> em1: port >> 0x2000-0x201f mem 0xc3c00000-0xc3c1ffff,0xc3400000-0xc37fffff irq 19 at >> device 0.1 on pci6 >> em1: Using MSI interrupt >> em1: Ethernet address: 00:15:17:30:94:31 >> em1: [FILTER] >> pcib7: at device 0.3 on pci1 >> pci7: on pcib7 >> pcib8: at device 3.0 on pci0 >> pci8: on pcib8 >> pcib9: at device 4.0 on pci0 >> pci9: on pcib9 >> vgapci0: port 0x1000-0x107f mem >> 0xc2000000-0xc2ffffff,0xb0000000-0xbfffffff,0xc0000000-0xc1ffffff irq 16 >> at device 0.0 on pci9 >> pcib10: at device 5.0 on pci0 >> pci10: on pcib10 >> pcib11: at device 6.0 on pci0 >> pci11: on pcib11 >> pcib12: at device 7.0 on pci0 >> pci12: on pcib12 >> pci0: at device 8.0 (no driver attached) >> pci0: at device 27.0 (no driver attached) >> pcib13: irq 16 at device 28.0 on pci0 >> pci13: on pcib13 >> uhci0: port >> 0x3080-0x309f irq 23 at device 29.0 on pci0 >> uhci0: [GIANT-LOCKED] >> uhci0: [ITHREAD] >> usb0: on uhci0 >> usb0: USB revision 1.0 >> uhub0: on usb0 >> uhub0: 2 ports with 2 removable, self powered >> uhci1: port >> 0x3060-0x307f irq 22 at device 29.1 on pci0 >> uhci1: [GIANT-LOCKED] >> uhci1: [ITHREAD] >> usb1: on uhci1 >> usb1: USB revision 1.0 >> uhub1: on usb1 >> uhub1: 2 ports with 2 removable, self powered >> uhci2: port >> 0x3040-0x305f irq 23 at device 29.2 on pci0 >> uhci2: [GIANT-LOCKED] >> uhci2: [ITHREAD] >> usb2: on uhci2 >> usb2: USB revision 1.0 >> uhub2: on usb2 >> uhub2: 2 ports with 2 removable, self powered >> uhci3: port >> 0x3020-0x303f irq 22 at device 29.3 on pci0 >> uhci3: [GIANT-LOCKED] >> uhci3: [ITHREAD] >> usb3: on uhci3 >> usb3: USB revision 1.0 >> uhub3: on usb3 >> uhub3: 2 ports with 2 removable, self powered >> ehci0: mem 0xc3f04400-0xc3f047ff irq >> 23 at device 29.7 on pci0 >> ehci0: [GIANT-LOCKED] >> ehci0: [ITHREAD] >> usb4: EHCI version 1.0 >> usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 >> usb4: on ehci0 >> usb4: USB revision 2.0 >> uhub4: on usb4 >> uhub4: 8 ports with 8 removable, self powered >> pcib14: at device 30.0 on pci0 >> pci14: on pcib14 >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30b0-0x30bf irq 20 at device 31.1 >> on pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> atapci1: port >> 0x30c8-0x30cf,0x30e4-0x30e7,0x30c0-0x30c7,0x30e0-0x30e3,0x30a0-0x30af >> mem 0xc3f04000-0xc3f043ff irq 20 at device 31.2 on pci0 >> atapci1: [ITHREAD] >> ata2: on atapci1 >> ata2: [ITHREAD] >> ata3: on atapci1 >> ata3: [ITHREAD] >> pci0: at device 31.3 (no driver attached) >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on >> acpi0 >> sio0: type 16550A, console >> sio0: [FILTER] >> sio1: configured irq 3 not in bitmap of probed irqs 0 >> sio1: port may not be enabled >> sio1: configured irq 3 not in bitmap of probed irqs 0 >> sio1: port may not be enabled >> sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 >> sio1: type 16550A >> sio1: [FILTER] >> orm0: at iomem >> 0xcd000-0xcdfff,0xce000-0xcefff,0xcf000-0xcffff on isa0 >> ppc0: cannot reserve I/O port range >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> Timecounters tick every 1.000 msec >> ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding >> disabled, default to accept, logging limited to 100 packets/entry by default >> Waiting 5 seconds for SCSI devices to settle >> acd0: DVDROM at ata0-master UDMA33 >> da0 at arcmsr0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-5 device >> da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> da0: 238418MB (488281088 512 byte sectors: 255H 63S/T 30394C) >> da1 at arcmsr0 bus 0 target 0 lun 1 >> da1: Fixed Direct Access SCSI-5 device >> da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> da1: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) >> da2 at arcmsr0 bus 0 target 0 lun 2 >> da2: Fixed Direct Access SCSI-5 device >> da2: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> da2: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) >> da3 at arcmsr0 bus 0 target 0 lun 3 >> da3: Fixed Direct Access SCSI-5 device >> da3: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> da3: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) >> da4 at arcmsr0 bus 0 target 0 lun 4 >> da4: Fixed Direct Access SCSI-5 device >> da4: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> da4: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) >> da5 at arcmsr0 bus 0 target 0 lun 5 >> da5: Fixed Direct Access SCSI-5 device >> da5: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> da5: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) >> da6 at arcmsr0 bus 0 target 0 lun 6 >> da6: Fixed Direct Access SCSI-5 device >> da6: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> da6: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) >> da7 at arcmsr0 bus 0 target 0 lun 7 >> da7: Fixed Direct Access SCSI-5 device >> da7: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> da7: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) >> lapic1: Forcing LINT1 to edge trigger >> SMP: AP CPU #1 Launched! >> WARNING: WITNESS option enabled, expect reduced performance. >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> Trying to mount root from ufs:/dev/da0s1a >> WARNING: ZFS is considered to be an experimental feature in FreeBSD. >> ZFS filesystem version 6 >> ZFS storage pool version 6 >> em1: Hardware Initialization Failed >> em1: Unable to initialize the hardware >> Expensive timeout(9) function: 0xffffffff80258fe0(0xffffff00012fc000) >> 0.008566172 s >> em1: link state changed to UP >> em1: link state changed to DOWN >> em1: link state changed to UP >> Expensive timeout(9) function: 0xffffffff80507ae0(0) 0.105003251 s >> Expensive timeout(9) function: 0xffffffff80397260(0) 0.372032111 s >> Expensive timeout(9) function: 0xffffffff80469350(0xffffff0069b5f888) >> 0.403952336 s >> >> >> my ipfw rules: >> pipe 2 config bw 600Mbit/s queue 50KBytes >> queue 201 config pipe 2 weight 1 mask dst-ip 0x0000000f queue 50 >> queue 210 config pipe 2 weight 50 mask dst-ip 0x0000000f queue 50 >> >> >> add 100 permit ip from any to any via lo0 >> add 200 deny ip from any to 127.0.0.0/8 >> >> # Speedup Established >> add 5001 skipto 8000 ip from 82.220.2.0/24 to 212.101.0.0/19 via em1 >> add 6000 queue 210 ip from any to 212.101.0.0/19 out xmit em1 >> add 6001 skipto 8000 ip from any to 212.101.0.0/19 out xmit em1 >> add 6002 queue 210 ip from any to 212.41.65.0/18 out xmit em1 >> add 6003 skipto 8000 ip from any to 212.41.65.0/18 out xmit em1 >> add 6004 queue 210 ip from any to 82.220.0.0/18 out xmit em1 >> add 6005 skipto 8000 ip from any to 82.220.0.0/18 out xmit em1 >> add 6100 queue 201 ip from any to any out xmit em1 >> >> add 8000 permit tcp from any to any via em1 established >> >> # ICMP >> add 11700 permit icmp from any to any via em1 icmptype 0,3,4,8,11,12 >> >> # Traceroute >> add 1800 allow udp from any 30000-60000 to me 30000-60000 via em0 >> >> >> # SSH (external connections are allowed for portsnap maintainer) >> add 11900 allow ip from me to any ssh setup >> add 11901 allow ip from any to me ssh setup >> >> # HTTP OUT >> add 11910 permit tcp from me to any 80 setup via em1 >> >> # SMTP >> add 12100 permit tcp from me to 212.101.0.0/19 25 setup via em1 >> add 12110 allow tcp from me to any dst-port smtp via em1 setup >> >> # DNS UDP SolNet >> add 21100 permit udp from 212.101.0.10 domain to me recv em1 >> add 21101 permit udp from me to 212.101.0.10 domain out xmit em1 >> add 21110 permit udp from 212.101.4.253 domain to me recv em1 >> add 21111 permit udp from me to 212.101.4.253 domain out xmit em1 >> add 21120 permit udp from 212.101.4.251 domain to me recv em1 >> add 21121 permit udp from me to 212.101.4.251 domain out xmit em1 >> >> # NTP >> add 21440 permit udp from me ntp to 212.101.0.0/19 ntp out xmit em1 >> add 21445 permit udp from 224.0.1.1 ntp to 212.101.0.0/19 ntp out xmit em1 >> add 21450 permit udp from 212.101.0.0/19 ntp to me ntp recv em1 >> add 21460 permit udp from 212.101.0.0/19 ntp to 224.0.1.1 ntp recv em1 >> add 21470 permit udp from me ntp to 224.0.1.1 ntp out xmit em1 >> >> >> # WEB >> add 22250 permit tcp from any to 212.101.4.241 80 setup via em1 limit >> src-addr 4 >> add 22251 permit tcp from any to 212.101.4.241 443 setup via em1 limit >> src-addr 4 >> add 22253 permit tcp from 212.101.4.241 to any 1024-65535 setup via em1 >> >> >> # FTP >> add 22300 permit tcp from any to 212.101.4.244 21 setup via em1 limit >> src-addr 4 >> add 22301 permit tcp from 212.101.4.244 to any 21 setup via em1 >> add 22302 permit tcp from 212.101.4.244 20 to any 1024-65535 setup via em1 >> add 22320 permit tcp from any 20 to 212.101.4.244 1024-65535 setup via em1 >> add 22340 permit tcp from any to 212.101.4.244 49152-65535 setup via em1 >> >> # RSYNC >> add 22400 permit tcp from 212.101.4.244 to any rsync setup via em1 >> add 22410 permit tcp from any to me rsync setup via em1 >> >> # CVSUPD >> add 22500 permit tcp from 212.101.4.244 to any cvsup setup via em1 >> add 22510 permit tcp from any to me cvsup setup via em1 >> >> # >> # NO WINDOWS >> # >> add 30000 deny udp from any to any 137 via em1 >> >> # Internal Interface >> add 62000 allow tcp from 212.101.0.0/24 to any 22,23,25 via em0 setup >> add 62010 allow tcp from 212.101.1.0/24 to any 22,23,25 via em0 setup >> add 62020 allow tcp from 212.101.4.0/24 to any 22,25 via em0 setup >> add 63000 reset tcp from any to any 22,23,25,3306,111 via em0 setup >> add 65000 allow ip from any to any via em0 >> >> # F*** off the rest >> add 65500 deny log ip from any to any >> >> If i load the ipfw rules i see: >> >> lock order reversal: >> 1st 0xffffffff80839448 PFil hook read/write mutex (PFil hook read/write >> mutex) @ /usr/src/sys/net/pfil.c:73 >> 2nd 0xffffffff80838440 in_multi_mtx (in_multi_mtx) @ >> /usr/src/sys/netinet/ip_output.c:302 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> witness_checkorder() at witness_checkorder+0x605 >> _mtx_lock_flags() at _mtx_lock_flags+0x75 >> ip_output() at ip_output+0x570 >> dummynet_send() at dummynet_send+0x13f >> dummynet_io() at dummynet_io+0x322 >> ipfw_check_out() at ipfw_check_out+0x20a >> pfil_run_hooks() at pfil_run_hooks+0xbc >> ip_output() at ip_output+0x372 >> udp_send() at udp_send+0x350 >> sosend_dgram() at sosend_dgram+0x20f >> kern_sendit() at kern_sendit+0x122 >> sendit() at sendit+0xdc >> sendto() at sendto+0x4d >> syscall() at syscall+0x1f6 >> Xfast_syscall() at Xfast_syscall+0xab >> --- syscall (133, FreeBSD ELF64, sendto), rip = 0x800bebc8c, rsp = >> 0x7fffffffe6c8, rbp = 0x551420 --- >> Expensive timeout(9) function: 0xffffffff80469350(0xffffff004696e000) >> 0.530255650 s >> >> >> FreeBSD is installed on ufs but I have a zfs pool for my data. >> Filesystem Size Used Avail Capacity Mounted on >> /dev/da0s1a 496M 356M 100M 78% / >> devfs 1.0K 1.0K 0B 100% /dev >> /dev/da0s1g 169G 4.0K 155G 0% /disk1 >> /dev/da0s1f 3.9G 902K 3.6G 0% /tmp >> /dev/da0s1e 29G 3.9G 23G 15% /usr >> /dev/da0s1d 19G 4.0G 14G 22% /var >> pool 1.2T 0B 1.2T 0% /usr/local/data >> pool/cvsup 1.2T 5.1G 1.2T 0% /usr/local/data/cvsup >> pool/ftp 3.3T 2.2T 1.2T 65% /usr/local/data/ftp >> pool/portsnap 1.2T 591M 1.2T 0% /usr/local/data/portsnap >> pool/www 1.2T 78M 1.2T 0% /usr/local/data/www >> >> Any help? >> >> Best regards, >> Thomas >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > Please try this patch: > http://www.freebsd.org/cgi/query-pr.cgi?prp=113548-3-diff > and report does it help or not. Thank you. It looks good. No freeze so far with your patch. I hope it will get into 7.0. Best regards, Thomas From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 09:55:11 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B50C16A418 for ; Tue, 11 Dec 2007 09:55:11 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8432013C46E for ; Tue, 11 Dec 2007 09:55:10 +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 lBB9t1SL080596; Tue, 11 Dec 2007 10:55:07 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id lBB9t0k6080579; Tue, 11 Dec 2007 10:55:00 +0100 (CET) (envelope-from olli) Date: Tue, 11 Dec 2007 10:55:00 +0100 (CET) Message-Id: <200712110955.lBB9t0k6080579@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, phk@phk.freebsd.dk, jhs@berklix.org, ghozzy@gmail.com In-Reply-To: <30984.1197357342@critter.freebsd.dk> X-Newsgroups: list.freebsd-current 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]); Tue, 11 Dec 2007 10:55:08 +0100 (CET) Cc: Subject: Re: PLIP - Parallel IP - does it still work ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, phk@phk.freebsd.dk, jhs@berklix.org, ghozzy@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 09:55:11 -0000 Poul-Henning Kamp wrote: > In message <200712110233.lBB2XAtl090250@fire.js.berklix.net>, "Julian Stacey" writes: > > > ( If PLIP doesnt work I only have 2 options left: SLIP or rip the > > drive out & install on another host, & hope the BIOS's compatible > > on disk layout. ) > > PLIP is sensitive to cpu clock speeds, you may have to extend the > loops somewhat in order to give all the EMC/EMI protection time to > pass the signals. FWIW, I also noticed that PLIP seems to work best when both machines are about the same speed. If you can't get it to work between a very fast machine and a slow one, then I suggest you try a different machine (if possible) that is of similar speed as the other one. Unfortunately, nowadays computers don't have "turbo buttons" anymore to make them slower. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 10:25:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A03C716A41B for ; Tue, 11 Dec 2007 10:25:26 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id AC7FA13C448 for ; Tue, 11 Dec 2007 10:25:25 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so34474pyb for ; Tue, 11 Dec 2007 02:25:24 -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=Crh81/2JNHy+P+knLYRJzdZhoAbJOKbrEOrSaePntBY=; b=jLl5b2QV33mbuw1MJDcsjs/apNd0uEOfARxjLPVbm6TRs3iCDzN2Bm6eQAySLXD7JsW3gQVfFBA558AxzU7/HpVyKMnCMga7uOgOjt3iAabpwwwp/XHcnbcYhBJMFdqGHLm6+5NScqYaPQgTe7cYJ7h6FFbZodSDkp6DF/WYRRg= 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=LmJDJ01XuZ6P/Hb+FCpdhOYfsq3RKsYpkUsrWYUOvIqkTDVjTIP6OQt+t7w+UbN0KtLMQJ4ob42BKmTkNhSWdbXryLcw3MipjMopsAedwzJaDp4D6ur04YP96zQ85MiSEZVFHTf1U3Y+HiBwTWmyR+wk0RBEyhZijC2Uz+uqDVQ= Received: by 10.65.133.8 with SMTP id k8mr16456571qbn.1197368721586; Tue, 11 Dec 2007 02:25:21 -0800 (PST) Received: by 10.64.184.9 with HTTP; Tue, 11 Dec 2007 02:25:21 -0800 (PST) Message-ID: <8e10486b0712110225gc61b83co37e91ef008f1c9d3@mail.gmail.com> Date: Tue, 11 Dec 2007 07:25:21 -0300 From: "Alexandre Biancalana" To: qpadla@gmail.com In-Reply-To: <200712110603.25769.qpadla@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0711280537n222d6cd5le33639b82a11f45@mail.gmail.com> <8e10486b0712100951m85f0278neb73ac4277779ba4@mail.gmail.com> <200712110603.25769.qpadla@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: 7-BETA3 everyday reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 10:25:26 -0000 On 12/11/07, Nikolay Pavlov wrote: > On Monday 10 December 2007 19:51:32 Alexandre Biancalana wrote: > > Here is my /boot/loader.conf: > > > > kern.maxdsiz="2G" # Set the max data size to 4GB > > kern.maxssiz="1G" # Set the max stack size 2GB > > > > vfs.zfs.prefetch_disable="1" > > vfs.zfs.arc_max="1G" > > > > vm.kmem_size_max="1500M" > > vm.kmem_size="1500M" > > > > kern.ipc.nmbclusters="32768" > > Is this i386 or amd64? this loader.conf is from one amd64 server From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 11:01:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9B8F16A41A for ; Tue, 11 Dec 2007 11:01:16 +0000 (UTC) (envelope-from vaunus@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id A77C513C474 for ; Tue, 11 Dec 2007 11:01:16 +0000 (UTC) (envelope-from vaunus@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so4157535waf for ; Tue, 11 Dec 2007 03:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:message-id:mime-version:content-type:x-mailer:thread-index:content-language; bh=Id0qZa3TEzFDMLB9e3OClg054/meIY0/YsimG8UbC2M=; b=NZDw28QpLNzn04toyTxRhFPhUQNweMn7IzJTBm1kxJmNGvfNcQ5weFuZpq4Nna9L3ReOJU9RMj5hB8e6TZUsX64x8mPT6A27BWmMRkGNJCA6gqsCNwYgBW9toNX7+0uguvDIW+8Z8KqM9qNHYbiEufSFeAjHVHrTEGm6XZ5G76M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer:thread-index:content-language; b=n16GIJ036hgmIKzDyXtdaoZNktfDR66ds20KfGhkjT6cg/ov7N+fKnvWBcq0vNLqXx653r59KErrBHfNNSTma/VSW63powFCLp8TtjZ/52CoVAnsabznHRI6yTt/KDpP7zC5+VR3DTvoLEaaiSiS4smd3t6aLvzdlPzGYLOxkCY= Received: by 10.114.26.1 with SMTP id 1mr762429waz.1197369240751; Tue, 11 Dec 2007 02:34:00 -0800 (PST) Received: from shark ( [203.161.96.51]) by mx.google.com with ESMTPS id m6sm6333246wag.2007.12.11.02.33.58 (version=SSLv3 cipher=RC4-MD5); Tue, 11 Dec 2007 02:33:59 -0800 (PST) From: "Vaughan Reid" To: Date: Tue, 11 Dec 2007 19:33:57 +0900 Message-ID: <000001c83be1$581f3620$085da260$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg74VXscE3VuDhUQquD8m2yzWvgOg== Content-Language: en-au Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problems Installing 7.0-BETA4 on Tyan Tiger K8SSA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 11:01:16 -0000 I have been trying to install FreeBSD 7.0-BETA4 amd64 on my Tyan K8SSA dual opteron 940 board but have been having problems. The install runs as per normal but upon trying to load the actual OS I have been getting Exec format errors for /bin/sh and other various things. The system never actually gets to the login prompt and sometimes hangs right after the BSD boot loader. I've installed 6.2 i386 and 6.2 amd64 without any issues but have to use 7 as I need the newer linux_base kernel support. Does anyone know what the problem might be here? From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 11:41:45 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E57C16A46B for ; Tue, 11 Dec 2007 11:41:45 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id DFB2113C458 for ; Tue, 11 Dec 2007 11:41:44 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 29743 invoked from network); 11 Dec 2007 11:15:03 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 11 Dec 2007 11:15:03 -0000 Message-ID: <475E7136.8060202@FreeBSD.org> Date: Tue, 11 Dec 2007 12:15:02 +0100 From: Alex Dupre User-Agent: Thunderbird 2.0.0.9 (X11/20071126) MIME-Version: 1.0 To: Vaughan Reid References: <000001c83be1$581f3620$085da260$@com> In-Reply-To: <000001c83be1$581f3620$085da260$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems Installing 7.0-BETA4 on Tyan Tiger K8SSA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 11:41:45 -0000 Vaughan Reid ha scritto: > Does anyone know what the problem might be here? HT1000 chipset ATA problem. See recent posts from sos for a temporary fix. -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 11:52:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB39516A418 for ; Tue, 11 Dec 2007 11:52:54 +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 3BC9613C44B for ; Tue, 11 Dec 2007 11:52:53 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A5A13.dip.t-dialin.net [84.154.90.19]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id lBBBqpTe011126; Tue, 11 Dec 2007 11:52:52 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 lBBBrm5Q085228; Tue, 11 Dec 2007 12:53:48 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id lBBBrmYl001945; Tue, 11 Dec 2007 12:53:48 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200712111153.lBBBrmYl001945@fire.js.berklix.net> To: Giorgos Keramidas In-reply-to: <20071211004531.GB11140@kobe.laptop> References: <20071210002131.GA74729@kobe.laptop> <002801c83b05$56ab20b0$3a2a13ac@staff.ktc.lan> <20071211004258.GA11140@kobe.laptop> <20071211004531.GB11140@kobe.laptop> Comments: In-reply-to Giorgos Keramidas message dated "Tue, 11 Dec 2007 02:45:31 +0200." Date: Tue, 11 Dec 2007 12:53:48 +0100 From: "Julian H. Stacey" Cc: Reko Turja , rrs@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 11:52:54 -0000 Giorgos Keramidas wrote: > > Does the following look ok? > A more complete patch, touching GENERIC for all architectures would be > like the following patch, of course: Looks good, it would be nice if someone commited that. ( I too got bitten by SCTP, when commenting out INET6 (which I didnt want, while leaving in SCTP for later removal, as I didnt know if something else new might depend on SCTP). Julian -- Julian Stacey. Munich Consultant: BSD Unix Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 18:20:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0835116A417; Tue, 11 Dec 2007 18:20:54 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 86CD413C44B; Tue, 11 Dec 2007 18:20:53 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (vader.bytemobile-rio.ondsl.gr [83.235.57.37]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id lBBIJT0R008968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Dec 2007 20:19:50 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id lBBIJNp7001918; Tue, 11 Dec 2007 20:19:23 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id lBBIJM10001917; Tue, 11 Dec 2007 20:19:22 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Tue, 11 Dec 2007 20:19:22 +0200 From: Giorgos Keramidas To: "Julian H. Stacey" Message-ID: <20071211181921.GC1712@kobe.laptop> References: <20071210002131.GA74729@kobe.laptop> <002801c83b05$56ab20b0$3a2a13ac@staff.ktc.lan> <20071211004258.GA11140@kobe.laptop> <20071211004531.GB11140@kobe.laptop> <200712111153.lBBBrmYl001945@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712111153.lBBBrmYl001945@fire.js.berklix.net> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.1, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.30, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Reko Turja , rrs@freebsd.org, freebsd-current@freebsd.org, Ivan Voras Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 18:20:54 -0000 On 2007-12-11 12:53, "Julian H. Stacey" wrote: >Giorgos Keramidas wrote: >> > Does the following look ok? >> A more complete patch, touching GENERIC for all architectures would be >> like the following patch, of course: > > Looks good, it would be nice if someone commited that. > ( I too got bitten by SCTP, when commenting out INET6 (which > I didnt want, while leaving in SCTP for later removal, as I > didnt know if something else new might depend on SCTP). Thanks! :) I am not sure if SCTP can work, or if it's expected to work at all, in INET6-only systems, so it's probably worth waiting for rrs@ to review the patch first. I'll commit it once we get his approval. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 18:39:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 146A616A417 for ; Tue, 11 Dec 2007 18:39:59 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA5913C458 for ; Tue, 11 Dec 2007 18:39:58 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so292793pyb for ; Tue, 11 Dec 2007 10:39:53 -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=swKM/s30lE0+I1dpdtgjtZ6AIVsLYAEb/4feyGPYK1w=; b=vJ2s+YY3ZGIRCAZPKQc/4r4RTSB8eIxuxiXxQiH1VGTH0EkePN2AuSPbEqtznDq6nn02bt+Gync2M5XQvtpJrswOKRvOdBDfjL9BATu09zH5+QVwm6lfUz3gkgQnijQuXzxN+GQAOVKYy9j+uc6/ikSyvpE+ATE1CCCEaiXEquU= 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=orGkj4u8T1DsQKtSDKrlkDd9JtJfXDV7ygL0a5gjXpkEpyctOn8QCJDejehcbrYPC2gzSWS9ppPd+yXz6wjjvIHuEfxXikGL6SqPVCfypvDsg1eA67yZvv0eS6RXBzYhACMF843DLmI0FljBS9++Mnj0Y30GNtC9+nORJZUsLKE= Received: by 10.142.72.21 with SMTP id u21mr1272271wfa.1197397960565; Tue, 11 Dec 2007 10:32:40 -0800 (PST) Received: by 10.142.174.5 with HTTP; Tue, 11 Dec 2007 10:32:40 -0800 (PST) Message-ID: <3a142e750712111032g62eddc62o736c231762b7c562@mail.gmail.com> Date: Tue, 11 Dec 2007 19:32:40 +0100 From: "Paul B. Mahol" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: wpa_supplicant and wired driver? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 18:39:59 -0000 It would be nice if wpa_supplicant Makefile have entries for wired driver (which is I think only supported on FreeBSD and Linux) It is rather trivial to edit Makefile and add support for optional wired driver(if there is no reasons to activate it by default) BTW I tested it and it works fine. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 18:53:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C11C816A418 for ; Tue, 11 Dec 2007 18:53:37 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by mx1.freebsd.org (Postfix) with ESMTP id 68A5C13C45D for ; Tue, 11 Dec 2007 18:53:37 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so898079nzf for ; Tue, 11 Dec 2007 10:53:36 -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=TBlsHr2nFd83XbFUn7IpN+ABy1YwBrxutMSvlv0wfVY=; b=Bl6NnRzMAEU8bwkpr/0f/9ycZ3Tc6CoVBbfclkSTXqG2KBt/LpRwizt05uC2Cw05ceN0LImOOK42gZYmptbKgMl0rvk6pJoMEANXzPmlpXxgeO5J0VvrDhLobjMhTKGZ6Zgd6G1Va+Sg5WkNUnJ+91cimFf/eicnekvTHq0GFwg= 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=NvIuWwokrhYuEOQMLnXugwRxe5M8KUyvsbsI/RhjUeOTUBh6YmXUjoViZehokvIJTVXhKyYro76UVqJr1bWGnOvxNrtZ3CDo4e/5dsUYB5flAF2KvTrw91YNhAd0/IPiBzs5j/xXVBvhKhSBDlF39EXO75qwU3XDdiiuRqpGNfQ= Received: by 10.143.6.1 with SMTP id j1mr1189387wfi.1197397673219; Tue, 11 Dec 2007 10:27:53 -0800 (PST) Received: by 10.142.174.5 with HTTP; Tue, 11 Dec 2007 10:27:53 -0800 (PST) Message-ID: <3a142e750712111027m2b9ee846r3ee358a20700f309@mail.gmail.com> Date: Tue, 11 Dec 2007 19:27:53 +0100 From: "Paul B. Mahol" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ukbd messed up dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 18:53:37 -0000 8.0 CURRENT It happens only if USB keyboard is actually used (just # kldload ukbd will not trigger bug) After that using # halt -p will display mess when syncing disk. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 19:05:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A37B516A418 for ; Tue, 11 Dec 2007 19:05:56 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id 3158A13C459 for ; Tue, 11 Dec 2007 19:05:55 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so428123uge.37 for ; Tue, 11 Dec 2007 11:05: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=zxZFvo7aWcBkadQDPU2n6fetk/sw1WH09gkA5CFr8Hg=; b=sWgnfcetViST01JubyjnkJw+J9IwfFxQcxxUEA/3P2V0qDp5BvAwuUvHtFvNlopJMoUwFqrCEOtToOp0OEVN+lh58MUG98FV+MujQRCjRJmqDIHfHxq7GW8YzRm9LcwWneHMBRWzhgk4/j9QbOiRFoiixNU8j30AnHsy4oB41Jk= 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=h3HkQFg+6JqcYNZCBssywiRhonT1H8Q1cfn7fIf5RD/g4WvD5Nv0lhu8kOiObfOdwQImA3cszAq6h/+PMT3M7Pl5DeHgy9Yx3uPhiLEGBh/bRZIiVbhRiLZhGlQLXZGPx9fEvSUmLf+UTjHMHwA6dXoo68ikwHSjburVVDPwhnk= Received: by 10.86.96.18 with SMTP id t18mr7023882fgb.1197399954498; Tue, 11 Dec 2007 11:05:54 -0800 (PST) Received: by 10.86.91.5 with HTTP; Tue, 11 Dec 2007 11:05:54 -0800 (PST) Message-ID: <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> Date: Tue, 11 Dec 2007 13:05:54 -0600 From: "Sam Fourman Jr." To: "Kip Macy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: amd64 NVIDIA support in FreeBSD 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 19:05:56 -0000 On Dec 9, 2007 1:35 AM, Kip Macy wrote: > The problem is that it is a moving target. In order to support NVIDIA > long term FreeBSD would need to maintain API parity with Linux. As > Linux adds new interfaces, NVIDIA incorporates them into their driver. > Unless someone steps up and decides to own the continuing support > effort to add those interfaces as the need arises, it isn't likely to > happen. so if I understand the situation correctly, maintaining feature / Performance parity with Linux for Nvidia video cards is possible, but it isn't likely that a current FreeBSD developer will donate the (probably large) amount of time to maintain it. would maintaining API parity with linux for the purpose of allowing 64bit 3D acceleration support in any way hurt FreeBSD's long term Goals ? > > On the upside, it looks like ATI's opening up is starting to bear fruit. from what it sounds like it ATI may be more of a realistic hope for compiz, and 3D video games to one day work on 64bit FreeBSD Thank you for taking the time to explain this. Sam Fourman Jr. > > > -Kip > > > > On 12/8/07, Sam Fourman Jr. wrote: > > Hello, > > > > I am aware that currently 3D accelerated support for Nvidia cards is > > not possible on the amd64 platform. > > > > My understanding is Nvidia (in 2006) requested some changes to the > > kernel that will improve performance,and > > ultimately provide support to the amd64 platform. > > the status of these changes can be found here > > http://wiki.freebsd.org/NvidiaFeatureRequests > > > > what I am confused about is how complex is the nature of these requests? > > is it realistic to think they will be MFC'ed to FreeBSD 7.x or will > > they have to be in 8.x ? > > > > assuming the changes outlined here > > http://wiki.freebsd.org/NvidiaFeatureRequests are completed > > > > would the Features and performance be on par with Linux Eg. FC8 ? > > > > I am hoping someone could explain these questions. > > > > Thank you Much > > > > Sam Fourman Jr. > > > > > > Sam Fourman Jr. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 19:16:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAFE916A469 for ; Tue, 11 Dec 2007 19:16:33 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from rn-out-0102.google.com (rn-out-0910.google.com [64.233.170.186]) by mx1.freebsd.org (Postfix) with ESMTP id 72C8113C442 for ; Tue, 11 Dec 2007 19:16:33 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by rn-out-0102.google.com with SMTP id e5so360144rng for ; Tue, 11 Dec 2007 11:16:32 -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=AmBmsmm703ZYa+jX14R7wKN4iBQSwauziVAb54K+OVc=; b=Rl1tjnTo1vgExdymVIoeRHCutCY6zFLV8KbUY251kUB6bLhHkZ25RW0KSns2mOyNJr0K82w27ltoEw0oJva9twkSB9U2EirpRqF5UIPAtO0S9EHFwd3ymc1BszNtPYr9eeVyqIlIIV74FJYI6tqfH9YLF+fZtv03DCi8D6HmJgc= 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=Zej0hvc4sPe/qJBIqnFj8l4gQoQU52fIrYONzL9rb0lRMFOT8XBNOeMckP3+paPmawqBZWCDufgaUr/0//vCol8vWoSLNuR73kC7AtAbKEKnjTs/aS3pSsmjneF0AfhAh7NFCWzl6c0cyLQxJropa4B2FNCvRFU4E87LwON2vsw= Received: by 10.150.192.7 with SMTP id p7mr375869ybf.1197400592158; Tue, 11 Dec 2007 11:16:32 -0800 (PST) Received: by 10.150.200.17 with HTTP; Tue, 11 Dec 2007 11:16:32 -0800 (PST) Message-ID: Date: Tue, 11 Dec 2007 11:16:32 -0800 From: "Kip Macy" To: "Sam Fourman Jr." In-Reply-To: <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: amd64 NVIDIA support in FreeBSD 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 19:16:33 -0000 On Dec 11, 2007 11:05 AM, Sam Fourman Jr. wrote: > On Dec 9, 2007 1:35 AM, Kip Macy wrote: > > The problem is that it is a moving target. In order to support NVIDIA > > long term FreeBSD would need to maintain API parity with Linux. As > > Linux adds new interfaces, NVIDIA incorporates them into their driver. > > Unless someone steps up and decides to own the continuing support > > effort to add those interfaces as the need arises, it isn't likely to > > happen. > > so if I understand the situation correctly, maintaining feature / > Performance parity with Linux for Nvidia video cards is possible, > but it isn't likely that a current FreeBSD developer will donate the > (probably large) amount of time to maintain it. It isn't that large, but that is the gist of it. > would maintaining API parity with linux for the purpose of allowing > 64bit 3D acceleration support in any way hurt FreeBSD's long term > Goals ? Not at all. It simply isn't a priority for the handful of people that are currently able to do this. > > > > On the upside, it looks like ATI's opening up is starting to bear fruit. > > from what it sounds like it ATI may be more of a realistic hope for > compiz, and 3D video games to one day work on 64bit FreeBSD > > Thank you for taking the time to explain this. I don't know the status of ATI at the moment - if you want 3D support on FreeBSD right *now* I think nvidia/i386 is your only option. -Kip From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 20:30:40 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D66C516A468 for ; Tue, 11 Dec 2007 20:30:40 +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 109D213C4EA for ; Tue, 11 Dec 2007 20:30:39 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A4E2E.dip.t-dialin.net [84.154.78.46]) (authenticated bits=0) by tower.berklix.org (8.13.6/8.13.6) with ESMTP id lBBKUV0j013749; Tue, 11 Dec 2007 20:30:33 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 lBBKUQJ6089770; Tue, 11 Dec 2007 21:30:26 +0100 (CET) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost.js.berklix.net [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id lBBKUeUO009646; Tue, 11 Dec 2007 21:30:40 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200712112030.lBBKUeUO009646@fire.js.berklix.net> To: current@freebsd.org, ghozzy@gmail.com In-reply-to: <30984.1197357342@critter.freebsd.dk> References: <30984.1197357342@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Tue, 11 Dec 2007 07:15:42 +0000." Date: Tue, 11 Dec 2007 21:30:40 +0100 From: "Julian H. Stacey" Cc: Poul-Henning Kamp , Oliver Fromme Subject: Re: PLIP - Parallel IP - does it still work ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 20:30:40 -0000 Oliver Fromme wrote: > FWIW, I also noticed that PLIP seems to work best when > both machines are about the same speed. If you can't > get it to work between a very fast machine and a slow > one, then I suggest you try a different machine (if > possible) that is of similar speed as the other one. Thanks. I started with a similar slow server "lapl" which the 7.0BETA3 installer on install client "norb" failed to contact, then I switched to a fast server "fire" that also failed. Hosts "lapa" & "lapl" below work, so a reference to test PL-IP links with: HOST RELEASE PROCESSOR fire 6.2 AMD Athlon(tm) 64 Processor 3000+ (2010.06-MHz K8-class CPU) lapa 4.11 Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) lapd 7.0-BETA3 Pentium/P55C (166-MHz 586 CPU) (no ppc yet, config prob) lapl 4.11 Pentium/P55C (120.27-MHz 586-class CPU) loft 6.2 Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU) norb 7.0-BETA3 Intel Pentium (P54C) (586-class), 133.65 MHz, id 0x52c Links: lapa-loft, & fire-lapl dont work. ( Host fire (X server) display same sticky mouse latency I've seen previously on a working FreeBSD plip/slip though, so some activity on that cable, it's trying even if not a working IP link. (No lpd of course, 3 PLIP cables, all tested OK on lapa-lapl) I think PLIP in much or all of FreeBSD-[5-7].* is defective. http://www.freebsd.org/cgi/query-pr.cgi?pr=113856 http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/share/man/man4/lp.4.REL=ALL.diff http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/share/man/man4/plip.4.send-pr.ignore http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/jhs/sys/dev/ppbus/if_plip.c.REL=ALL.diff Probably time `man plip` is marked as Dead, until fixed. "Poul-Henning Kamp" wrote: > PLIP is sensitive to cpu clock speeds, you may have to extend the > loops somewhat in order to give all the EMC/EMI protection time to > pass the signals. Thanks, Some time I'll hope to look in /usr/src/sys/ dev/ppc & modules/ppc if no one else does. -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 20:43:54 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3414F16A417 for ; Tue, 11 Dec 2007 20:43:54 +0000 (UTC) (envelope-from haws@ethereal.net) Received: from camel.ethereal.net (camel.ethereal.net [207.241.238.17]) by mx1.freebsd.org (Postfix) with ESMTP id 30B0513C45B for ; Tue, 11 Dec 2007 20:43:54 +0000 (UTC) (envelope-from haws@ethereal.net) Received: by camel.ethereal.net (Postfix, from userid 1089) id B0BE52C96F8; Tue, 11 Dec 2007 12:26:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=bork; d=ethereal.net; c=nofws; q=dns; h=date:from:to:subject:message-id:mime-version:content-type: content-disposition:user-agent; b=rZuR/Z2bNYqnOWGwROYkvupxjC431Bo2mXyDpPx6t9CWiAL7iioTjvKqkfNTG6+LX dk0vFymgSN6/rlByl3ViQ== Date: Tue, 11 Dec 2007 12:26:32 -0800 From: Brad Hall To: freebsd-current@freebsd.org Message-ID: <20071211202632.GA18719@ethereal.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Segfault in installer (7.0-Beta4) when loading package index X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 20:43:54 -0000 Hi, When installing fbsd 7.0beta4 on a vmware instance on a macbook pro (leopard) I'm getting a setfault when it tries to load the package index in teh isntaller. To reprooduce (every time) I just run sysintall, go to configure -> packages, select media as ftp passive, ftp.freebsd.org, then it segfaults while loading the package index. I can try with a debug build alter today after I have time to get the entire source tree, until then here is truss output. gdb just dislpays a couple thousand ?? messages, no symbols. 52363: poll({0/POLLIN},1,0) = 0 (0x0) 52363: poll({0/POLLIN},1,0) = 0 (0x0) 52363: write(1,"\^[[22;14H\^[[36m\^[[44m\^[[1m "...,444) = 444 (0x1bc) 52363: sigaction(SIGTSTP,{ 0x28102fa0 SA_RESTART ss_t },0x0) = 0 (0x0) 52363: fstat(6,{mode=srw-rw-rw- ,inode=0,size=2896,blksize=33580}) = 0 (0x0) 52363: read(6,"accerciser-1.0.1_1|/usr/ports/ac"...,33580) = 2896 (0xb50) 52363: read(6,"ile-0.2.6 libbonobo-2.20.1_1 lib"...,33580) = 1448 (0x5a8) 52363: read(6,".8.2_1 totem-2.20.1 trapproto-3."...,33580) = 1448 (0x5a8) 52363: read(6,"-bad-0.10.5_2,3 gstreamer-plugin"...,33580) = 1448 (0x5a8) 52363: read(6,"7.4_1 libao-0.8.8_1 libart_lgpl-"...,33580) = 1448 (0x5a8) 52363: read(6,"tup-notification-0.9_1 tiff-3.8."...,33580) = 2896 (0xb50) 52363: access("/var/db/pkg/3.11.7 openldap-client-2.3.39 p5-XML-Parser-2.34_2 pango-1.18.3 pciids-20071004 pcre-7.4 perl-5.8.8_1 pixman-0.9.6 pkg-config-0.22_1 png-1.2.22 policykit-0.1.20060514_4 popt-1.7_4 printproto-1.0.3 py25-cairo-1.4.0_1 py25-gnome-2.20.0 py25-gnome-desktop-2.20.0 py25-gobject-2.14.0 py25-gtk-2.12.0 py25-libxml2-2.6.30 py25-numeric-24.2 py25-orbit-2.14.3 python25-2.5.1_1 randrproto-1.2.1 rarian-0.6.0_1 recordproto-1.13.2 renderproto-0.9.3 samba-libsmbclient-3.0.26a_2 scrnsaverproto-1.1.0 sdocbook-xml-1.1,1 shared-mime-info-0.22_1 startup-notification-0.9_1 tiff-3.8.2_1 totem-2.20.1 trapproto-3.4.3 videoproto-2.2.2 xbitmaps-1.0.1 xextproto-7.0.2 xf86dgaproto-2.0.3 xf86miscproto-0.9.2 xf86vidmodeproto-2.2.2 xineramaproto-1.1.2 xkbcomp-1.0.3 xmlcatmgr-2.2 xorg-fonts-truetype-7.3 xorg-libraries-7.3_1 xproto-7.0.10_1 xtrans-1.0.4 xvid-1.1.3,1",4) ERR#63 'File name too long' 52363: SIGNAL 11 (SIGSEGV) Please let me know if there is any more info that woudl be usefull. Thanks, Brad From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 20:46:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BE5E16A4A9 for ; Tue, 11 Dec 2007 20:46:13 +0000 (UTC) (envelope-from kenfreebsd@icarz.com) Received: from deanna.icarz.com (deanna.icarz.com [207.99.22.19]) by mx1.freebsd.org (Postfix) with ESMTP id 2AA2413C458 for ; Tue, 11 Dec 2007 20:46:12 +0000 (UTC) (envelope-from kenfreebsd@icarz.com) Received: from kenxp (netb-138.icarz.com [209.123.219.138]) by deanna.icarz.com (8.13.8/8.13.8) with SMTP id lBBKZWdW058958; Tue, 11 Dec 2007 15:35:32 -0500 (EST) (envelope-from kenfreebsd@icarz.com) Message-ID: <0be001c83c35$605d0020$8adb7bd1@icarz.com> From: "Ken Menzel" To: "Martin Cracauer" , "Poul-Henning Kamp" References: <28655.1197320193@critter.freebsd.dk> Date: Tue, 11 Dec 2007 15:35:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: -98.6 () ALL_TRUSTED, AWL, BAYES_00, STOX_REPLY_TYPE, USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.63 on 207.99.22.19 Cc: Thomas Sparrevohn , freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ken Menzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 20:46:13 -0000 ----- Original Message ----- From: "Poul-Henning Kamp" To: "Martin Cracauer" Cc: "Thomas Sparrevohn" ; Sent: Monday, December 10, 2007 3:56 PM Subject: Re: CURRENT Kernel makes the system run very very hot > In message <20071210201106.GB90158@cons.org>, Martin Cracauer > writes: > > I installed this on my laptop yesterday: > > FreeBSD critter.freebsd.dk 8.0-CURRENT FreeBSD 8.0-CURRENT > #0: Sun Dec 9 10:41:25 UTC 2007 > root@critter.freebsd.dk:/usr/obj/freebsd/src/sys/C5 i386 > > And it does indeed look like the idle threads do not HLT the cpu. > > Interestingly, powerd(8) does the right thing and throttles down > the cpu clock even though the idle threads churn away. > > top -HS shows: So did anyone file a PR? Or is someone already working on this? Seems fairly major to me as I am seeing the same thing here, on single CPU systems and a dual quad core system. If needed I will create the PR. Ken From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 20:46:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA90216A4A0 for ; Tue, 11 Dec 2007 20:46:17 +0000 (UTC) (envelope-from kenfreebsd@icarz.com) Received: from deanna.icarz.com (deanna.icarz.com [207.99.22.19]) by mx1.freebsd.org (Postfix) with ESMTP id 7B71513C4D1 for ; Tue, 11 Dec 2007 20:46:17 +0000 (UTC) (envelope-from kenfreebsd@icarz.com) Received: from kenxp (netb-138.icarz.com [209.123.219.138]) by deanna.icarz.com (8.13.8/8.13.8) with SMTP id lBBKbi4f058970; Tue, 11 Dec 2007 15:37:44 -0500 (EST) (envelope-from kenfreebsd@icarz.com) Message-ID: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com> From: "Ken Menzel" To: "Ken Menzel" , "Martin Cracauer" , "Poul-Henning Kamp" Date: Tue, 11 Dec 2007 15:37:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: -100.049 () ALL_TRUSTED, AWL, BAYES_00, FAKE_REPLY_C, USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.63 on 207.99.22.19 Cc: Thomas Sparrevohn , freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ken Menzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 20:46:17 -0000 > > So did anyone file a PR? Or is someone already working on this? > Seems fairly major to me as I am seeing the same thing here, on > single CPU systems and a dual quad core system. If needed I will > create the PR. > > Ken P.S. I should have added I am running releng_7 beta 4 and seeing the same problem. Ken From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 21:39:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 780D816A420 for ; Tue, 11 Dec 2007 21:39:13 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E7E6913C455 for ; Tue, 11 Dec 2007 21:39:12 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 18919 invoked from network); 11 Dec 2007 21:08:35 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Dec 2007 21:08:35 -0000 Message-ID: <475F037F.4000702@freebsd.org> Date: Tue, 11 Dec 2007 22:39:11 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Scott Long References: <2942A3E0-3E07-4CCB-B292-8DA25884AD3E@nevada.net.nz> <475D6C81.5030308@samsco.org> In-Reply-To: <475D6C81.5030308@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Philip Murray Subject: Re: Areca weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 21:39:13 -0000 Scott Long wrote: > For the Areca driver, it's harmless. I still haven't narrowed > down the actual problem, unfortunately. I see the same on a new box with FreeBSD 7.0BETA4 AMD64. Unfortunately it just stops and hangs here: arcmsr0: mem 0xfdbff000-0xfdbfffff,0xfd400000-0xfd7fffff irq 16 at device 14.0 on pci10 ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 arcmsr0: [ITHRRAD] ... Waiting 5 seconds for SCSI devices to settle (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step [hangs...] The controller is an ARC-1220 PCI-Express with 8 SATA ports. The firmware is the newest according to their website. Connected are 4 Seagate 750GB SATA drives (the ES 24x7 variant). With 6.3RC1 AMD64 it works just fine. -- Andre > Scott > > Philip Murray wrote: > >> Hi, >> >> After the recent commit of the new Areca (arcmsr) driver, I get this >> output during boot: >> >> arcmsr0: > > mem 0xfc7ff000-0xfc7fffff,0xfc000000-0xfc3fffff irq 31 at device >> 14.0 on pci2 >> ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 >> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 >> arcmsr0: [ITHREAD] >> >> .... snip .... >> >> Waiting 5 seconds for SCSI devices to settle >> (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >> ^^^ This line here ^^^ >> >> da0 at arcmsr0 bus 0 target 0 lun 0 >> da0: Fixed Direct Access SCSI-5 device >> da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> da0: 76293MB (156248064 512 byte sectors: 255H 63S/T 9725C) >> da1 at arcmsr0 bus 0 target 0 lun 1 >> da1: Fixed Direct Access SCSI-5 device >> da1: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) >> da1: 2784727MB (5703121920 512 byte sectors: 255H 63S/T 355002C) >> >> >> Not sure if it's anything to worry about (as I have no idea what it >> means), but doesn't seem to affect functionality at all >> >> Cheers >> >> Phil >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 22:11:21 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0330416A417 for ; Tue, 11 Dec 2007 22:11:21 +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 C5A4513C45B for ; Tue, 11 Dec 2007 22:11:20 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lBBMBHmf010805; Tue, 11 Dec 2007 15:11:18 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <475F0AF0.50208@samsco.org> Date: Tue, 11 Dec 2007 15:10:56 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Andre Oppermann References: <2942A3E0-3E07-4CCB-B292-8DA25884AD3E@nevada.net.nz> <475D6C81.5030308@samsco.org> <475F037F.4000702@freebsd.org> In-Reply-To: <475F037F.4000702@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 11 Dec 2007 15:11:18 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Philip Murray Subject: Re: Areca weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 22:11:21 -0000 Andre Oppermann wrote: > Scott Long wrote: >> For the Areca driver, it's harmless. I still haven't narrowed >> down the actual problem, unfortunately. > > I see the same on a new box with FreeBSD 7.0BETA4 AMD64. Unfortunately > it just stops and hangs here: > > arcmsr0: mem > 0xfdbff000-0xfdbfffff,0xfd400000-0xfd7fffff irq 16 at device 14.0 on pci10 > ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 > arcmsr0: [ITHRRAD] > ... > Waiting 5 seconds for SCSI devices to settle > (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step > > [hangs...] > > The controller is an ARC-1220 PCI-Express with 8 SATA ports. The > firmware is the newest according to their website. Connected are > 4 Seagate 750GB SATA drives (the ES 24x7 variant). With 6.3RC1 > AMD64 it works just fine. > Can you break into the debugger and see if it's getting an interrupt storm or is spinning in code or is sleeping somewhere odd? Scott From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 22:48:34 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00E6416A417 for ; Tue, 11 Dec 2007 22:48:34 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id 73E0F13C467 for ; Tue, 11 Dec 2007 22:48:33 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix2-g20.free.fr (Postfix) with ESMTP id D39712111232 for ; Tue, 11 Dec 2007 21:14:52 +0100 (CET) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 2116C3F6183 for ; Tue, 11 Dec 2007 23:15:40 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 6D4163F617E for ; Tue, 11 Dec 2007 23:15:39 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 0664D9B497 for ; Tue, 11 Dec 2007 22:13:19 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id EC9DE405D; Tue, 11 Dec 2007 23:13:18 +0100 (CET) Date: Tue, 11 Dec 2007 23:13:18 +0100 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20071211221318.GB47521@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Subject: Patch to enable SSP on RELENG_7/CURRENT by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 22:48:34 -0000 --cvVnyQ+4j833TQvp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi list, I already posted a couple of month ago for a patch to bring in ProPolice/SSP into 6-STABLE and 7-CURRENT [1]. Understandably, it has never been commited because this required to heavily patch GCC 3.4.6, which is a contributed software. Now that RELENG_7 and CURRENT have GCC 4.2.1, which provides SSP, FreeBSD just lacks the "glue" bits to make the best of it. Once applied, FreeBSD will be compiled with SSP unless WITHOUT_SSP is set. This patch is a kind of proof of concept. For example, the FreeBSD team might not want to enable SSP by default (any benchmark from other users than me would be welcome). The Makefile guy(s?) may also have comments on how I've implemented it in the build infrastructure (SSP_CFLAGS notably). Also, the kernel bits I scrawled in sys/kern/stack_protector.c should surely be improved. Best regards, [1] http://tataz.chchile.org/~tataz/FreeBSD/SSP/ -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --cvVnyQ+4j833TQvp Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="fbsd7-ssp-glue.patch" diff -urNp src.0/Makefile.inc1 src/Makefile.inc1 --- src.0/Makefile.inc1 2007-10-31 09:26:42.000000000 +0000 +++ src/Makefile.inc1 2007-12-11 12:20:31.000000000 +0000 @@ -213,6 +213,7 @@ BMAKE= MAKEOBJDIRPREFIX=${WORLDTMP} \ ${BMAKEENV} ${MAKE} -f Makefile.inc1 \ DESTDIR= \ BOOTSTRAPPING=${OSRELDATE} \ + SSP_CFLAGS= \ -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN \ -DWITHOUT_NLS -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED \ -DNO_CPU_CFLAGS -DNO_WARNS @@ -222,6 +223,7 @@ TMAKE= MAKEOBJDIRPREFIX=${OBJTREE} \ ${BMAKEENV} ${MAKE} -f Makefile.inc1 \ TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \ DESTDIR= \ + SSP_CFLAGS= \ BOOTSTRAPPING=${OSRELDATE} -DNO_LINT -DNO_CPU_CFLAGS -DNO_WARNS # cross-tools stage @@ -433,7 +435,7 @@ build32: .if ${MK_KERBEROS} != "no" .for _t in obj depend all cd ${.CURDIR}/kerberos5/tools; \ - MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} DESTDIR= ${_t} + MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} SSP_CFLAGS= DESTDIR= ${_t} .endfor .endif .for _t in obj includes @@ -455,7 +457,7 @@ build32: .endfor .for _dir in lib/ncurses/ncurses lib/ncurses/ncursesw lib/libmagic cd ${.CURDIR}/${_dir}; \ - MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} DESTDIR= build-tools + MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} SSP_CFLAGS= DESTDIR= build-tools .endfor cd ${.CURDIR}; \ ${LIB32WMAKE} -f Makefile.inc1 libraries @@ -728,13 +730,13 @@ buildkernel: @echo "--------------------------------------------------------------" cd ${KRNLOBJDIR}/${_kernel}; \ MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \ - ${MAKE} -DNO_CPU_CFLAGS -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile + ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile # XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case. .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists(${KERNSRCDIR}/modules) .for target in obj depend all cd ${KERNSRCDIR}/modules/aic7xxx/aicasm; \ MAKEOBJDIRPREFIX=${KRNLOBJDIR}/${_kernel}/modules \ - ${MAKE} -DNO_CPU_CFLAGS ${target} + ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS ${target} .endfor .endif .if !defined(NO_KERNELDEPEND) Files src.0/lib/libc/sys/.stack_protector.c.swp and src/lib/libc/sys/.stack_protector.c.swp differ diff -urNp src.0/lib/libstand/Makefile src/lib/libstand/Makefile --- src.0/lib/libstand/Makefile 2007-10-24 21:32:57.000000000 +0000 +++ src/lib/libstand/Makefile 2007-12-11 12:22:04.000000000 +0000 @@ -12,6 +12,7 @@ NO_PIC= INCS= stand.h MAN= libstand.3 +SSP_CFLAGS= CFLAGS+= -ffreestanding -Wformat CFLAGS+= -I${.CURDIR} diff -urNp src.0/share/mk/bsd.README src/share/mk/bsd.README --- src.0/share/mk/bsd.README 2006-06-18 11:26:17.000000000 +0000 +++ src/share/mk/bsd.README 2007-12-11 12:17:35.000000000 +0000 @@ -37,6 +37,7 @@ bsd.port.pre.mk - building ports bsd.port.subdir.mk - targets for building subdirectories for ports bsd.prog.mk - building programs from source files bsd.snmpmod.mk - building modules for the SNMP daemon bsnmpd +bsd.ssp.mk - handle ProPolice (SSP) settings bsd.subdir.mk - targets for building subdirectories bsd.sys.mk - common settings used for building FreeBSD sources sys.mk - default rules for all makes diff -urNp src.0/share/mk/bsd.own.mk src/share/mk/bsd.own.mk --- src.0/share/mk/bsd.own.mk 2007-10-20 19:01:49.000000000 +0000 +++ src/share/mk/bsd.own.mk 2007-12-11 14:37:38.000000000 +0000 @@ -111,6 +111,7 @@ SRCCONF?= /etc/src.conf .endif .endif +.if !defined(_ONLY_SRCCONF) # Binaries BINOWN?= root BINGRP?= wheel @@ -173,6 +174,7 @@ STRIP?= -s COMPRESS_CMD?= gzip -cn COMPRESS_EXT?= .gz +.endif # !_ONLY_SRCCONF .if !defined(_WITHOUT_SRCCONF) # diff -urNp src.0/share/mk/bsd.port.mk src/share/mk/bsd.port.mk --- src.0/share/mk/bsd.port.mk 2006-11-19 16:28:52.000000000 +0000 +++ src/share/mk/bsd.port.mk 2007-12-11 12:16:29.000000000 +0000 @@ -9,3 +9,10 @@ _WITHOUT_SRCCONF= .include .include "${BSDPORTMK}" + +# XXX This belongs to ports/Mk/bsd.port.mk where it should be documented as +# well, but it is easier to distribute as long as it is a patch. +.if defined(USE_SSP) +SSP_CFLAGS ?= -fstack-protector +CFLAGS += ${SSP_CFLAGS} +.endif diff -urNp src.0/share/mk/bsd.ssp.mk src/share/mk/bsd.ssp.mk --- src.0/share/mk/bsd.ssp.mk 1970-01-01 00:00:00.000000000 +0000 +++ src/share/mk/bsd.ssp.mk 2007-12-11 14:47:22.000000000 +0000 @@ -0,0 +1,10 @@ +# $FreeBSD$ + +# Handle stack protection flags. +.if ${MK_SSP} != "no" && ${CC} != 'icc' +SSP_CFLAGS ?= -fstack-protector +CFLAGS += ${SSP_CFLAGS} +. if defined(SSP_WARNS) && !empty(SSP_FLAGS) +CWARNFLAGS += -Wstack-protector +. endif +.endif diff -urNp src.0/share/mk/bsd.sys.mk src/share/mk/bsd.sys.mk --- src.0/share/mk/bsd.sys.mk 2007-11-22 23:21:12.000000000 +0000 +++ src/share/mk/bsd.sys.mk 2007-12-11 12:15:35.000000000 +0000 @@ -76,3 +76,5 @@ CWARNFLAGS += -Wno-unknown-pragmas # Allow user-specified additional warning flags CFLAGS += ${CWARNFLAGS} + +.include diff -urNp src.0/sys/boot/efi/Makefile.inc src/sys/boot/efi/Makefile.inc --- src.0/sys/boot/efi/Makefile.inc 2004-02-12 08:10:33.000000000 +0000 +++ src/sys/boot/efi/Makefile.inc 2007-12-11 12:23:20.000000000 +0000 @@ -5,3 +5,6 @@ BINDIR?= /boot # Options used when building app-specific efi components CFLAGS+= -ffreestanding -fshort-wchar -Wformat LDFLAGS+= -nostdlib + +# No SSP in /boot. +SSP_CFLAGS= diff -urNp src.0/sys/boot/ficl/Makefile src/sys/boot/ficl/Makefile --- src.0/sys/boot/ficl/Makefile 2007-10-15 14:20:24.000000000 +0000 +++ src/sys/boot/ficl/Makefile 2007-12-11 12:24:13.000000000 +0000 @@ -7,6 +7,8 @@ BASE_SRCS= dict.c ficl.c fileaccess.c fl SRCS= ${BASE_SRCS} sysdep.c softcore.c CLEANFILES= softcore.c testmain testmain.o CFLAGS+= -ffreestanding +# No SSP in /boot. +SSP_CFLAGS= .if ${MACHINE_ARCH} == "i386" || ${MACHINE_ARCH} == "amd64" CFLAGS+= -mpreferred-stack-boundary=2 CFLAGS+= -mno-mmx -mno-3dnow -mno-sse -mno-sse2 diff -urNp src.0/sys/boot/i386/Makefile.inc src/sys/boot/i386/Makefile.inc --- src.0/sys/boot/i386/Makefile.inc 2006-09-28 10:02:04.000000000 +0000 +++ src/sys/boot/i386/Makefile.inc 2007-12-11 12:24:40.000000000 +0000 @@ -15,6 +15,9 @@ LDFLAGS+= -m elf_i386_fbsd AFLAGS+= --32 .endif +# No SSP in /boot. +SSP_CFLAGS= + # BTX components .if exists(${.OBJDIR}/../btx) BTXDIR= ${.OBJDIR}/../btx diff -urNp src.0/sys/boot/ofw/libofw/Makefile src/sys/boot/ofw/libofw/Makefile --- src.0/sys/boot/ofw/libofw/Makefile 2007-06-17 00:17:15.000000000 +0000 +++ src/sys/boot/ofw/libofw/Makefile 2007-12-11 12:25:16.000000000 +0000 @@ -17,6 +17,9 @@ CFLAGS+= -ffreestanding CFLAGS+= -msoft-float .endif +# No SSP in /boot. +SSP_CFLAGS= + .ifdef(BOOT_DISK_DEBUG) # Make the disk code more talkative CFLAGS+= -DDISK_DEBUG diff -urNp src.0/sys/boot/sparc64/Makefile.inc src/sys/boot/sparc64/Makefile.inc --- src.0/sys/boot/sparc64/Makefile.inc 2004-02-09 14:17:02.000000000 +0000 +++ src/sys/boot/sparc64/Makefile.inc 2007-12-11 12:25:34.000000000 +0000 @@ -3,3 +3,6 @@ BINDIR?= /boot CFLAGS+= -ffreestanding LDFLAGS+= -nostdlib + +# No SSP in /boot. +SSP_CFLAGS= diff -urNp src.0/sys/conf/files src/sys/conf/files --- src.0/sys/conf/files 2007-11-21 21:42:55.000000000 +0000 +++ src/sys/conf/files 2007-12-11 15:08:38.000000000 +0000 @@ -1474,6 +1474,7 @@ kern/posix4_mib.c standard kern/sched_4bsd.c optional sched_4bsd kern/sched_ule.c optional sched_ule kern/serdev_if.m standard +kern/stack_protector.c standard kern/subr_acl_posix1e.c standard kern/subr_autoconf.c standard kern/subr_blist.c standard diff -urNp src.0/sys/conf/kern.mk src/sys/conf/kern.mk --- src.0/sys/conf/kern.mk 2007-05-24 21:53:42.000000000 +0000 +++ src/sys/conf/kern.mk 2007-12-11 14:49:31.000000000 +0000 @@ -97,3 +97,11 @@ CFLAGS+= -ffreestanding .if ${CC} == "icc" CFLAGS+= -restrict .endif + +# +# GCC SSP support. +# +.if ${MK_SSP} != 'no' && ${CC} != 'icc' +SSP_CFLAGS?= -fstack-protector +CFLAGS+= ${SSP_CFLAGS} +.endif diff -urNp src.0/sys/conf/kern.pre.mk src/sys/conf/kern.pre.mk --- src.0/sys/conf/kern.pre.mk 2007-08-08 19:12:06.000000000 +0000 +++ src/sys/conf/kern.pre.mk 2007-12-11 14:39:59.000000000 +0000 @@ -3,10 +3,8 @@ # Part of a unified Makefile for building kernels. This part contains all # of the definitions that need to be before %BEFORE_DEPEND. -SRCCONF?= /etc/src.conf -.if exists(${SRCCONF}) -.include "${SRCCONF}" -.endif +_ONLY_SRCCONF= +.include # Can be overridden by makeoptions or /etc/make.conf KERNEL_KO?= kernel diff -urNp src.0/sys/kern/stack_protector.c src/sys/kern/stack_protector.c --- src.0/sys/kern/stack_protector.c 1970-01-01 00:00:00.000000000 +0000 +++ src/sys/kern/stack_protector.c 2007-12-11 15:51:39.000000000 +0000 @@ -0,0 +1,13 @@ +void panic(const char *, ...); +void __stack_chk_fail(void); + +long __stack_chk_guard[8] = { 0, 0, 0, 0, 0, 0, 0, 0 }; + +void +__stack_chk_fail(void) +{ + static char *msg = "stack overflow caught by SSP; backtrace may be " + "corrupted."; + + panic(msg); +} --cvVnyQ+4j833TQvp-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 23:02:18 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76FF416A418 for ; Tue, 11 Dec 2007 23:02:18 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4511813C442 for ; Tue, 11 Dec 2007 23:02:18 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id 55DFE3EA0B6 for ; Wed, 12 Dec 2007 00:02:17 +0100 (CET) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id 275203EA0D8 for ; Wed, 12 Dec 2007 00:02:17 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by mail.herbelot.nom (8.14.0/8.14.0) with ESMTP id lBBN2E5c025071; Wed, 12 Dec 2007 00:02:14 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Wed, 12 Dec 2007 00:02:06 +0100 User-Agent: KMail/1.9.7 References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> In-Reply-To: X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712120002.08386.thierry@herbelot.com> Cc: Kip Macy Subject: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 23:02:18 -0000 > I don't know the status of ATI at the moment - if you want 3D support > on FreeBSD right *now* I think nvidia/i386 is your only option. > > -Kip Hello, with less ambitious goals : what graphic card can I use these days to drive my 1680x1050 LCD under X11 ? (I used to use my oldish radeon, with an ATI9200, but the radeon support in xorg 7.3 seems to have been broken for around 3 months and VESA does not drive 1680x1050) does the xorg nv driver support 1680x1050 ? TfH From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 23:17:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8059C16A418 for ; Tue, 11 Dec 2007 23:17:00 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id EEF0F13C457 for ; Tue, 11 Dec 2007 23:16:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 19810 invoked from network); 11 Dec 2007 22:46:21 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Dec 2007 22:46:21 -0000 Message-ID: <475F1A6E.8080805@freebsd.org> Date: Wed, 12 Dec 2007 00:17:02 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Scott Long References: <2942A3E0-3E07-4CCB-B292-8DA25884AD3E@nevada.net.nz> <475D6C81.5030308@samsco.org> <475F037F.4000702@freebsd.org> <475F0AF0.50208@samsco.org> In-Reply-To: <475F0AF0.50208@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Philip Murray Subject: Re: Areca weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 23:17:00 -0000 Scott Long wrote: > Andre Oppermann wrote: >> Scott Long wrote: >>> For the Areca driver, it's harmless. I still haven't narrowed >>> down the actual problem, unfortunately. >> >> I see the same on a new box with FreeBSD 7.0BETA4 AMD64. Unfortunately >> it just stops and hangs here: >> >> arcmsr0: mem >> 0xfdbff000-0xfdbfffff,0xfd400000-0xfd7fffff irq 16 at device 14.0 on >> pci10 >> ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 >> ARECA RAID ADAPTER0: FIRMWARE VERSION V1.43 2007-4-17 >> arcmsr0: [ITHREAD] >> ... >> Waiting 5 seconds for SCSI devices to settle >> (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step >> >> [hangs...] >> >> The controller is an ARC-1220 PCI-Express with 8 SATA ports. The >> firmware is the newest according to their website. Connected are >> 4 Seagate 750GB SATA drives (the ES 24x7 variant). With 6.3RC1 >> AMD64 it works just fine. >> > > Can you break into the debugger and see if it's getting an interrupt > storm or is spinning in code or is sleeping somewhere odd? No, break doesn't work. It's the generic kernel from the BETA4 boot CDROM. Neither does CTRL-ALT-DEL work. NumLock can be toggled though. Other than that only a hard reset recovers the box. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Dec 11 23:48:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D62B016A421; Tue, 11 Dec 2007 23:48:04 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4343E13C461; Tue, 11 Dec 2007 23:48:03 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup79.ach.sch.gr [81.186.70.79]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id lBBNl4Cu029883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Dec 2007 01:47:40 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id lBBNkvrf001711; Wed, 12 Dec 2007 01:47:00 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id lBBKwDYq001583; Tue, 11 Dec 2007 22:58:13 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Tue, 11 Dec 2007 22:58:13 +0200 From: Giorgos Keramidas To: Ollivier Robert Message-ID: <20071211205813.GB1455@kobe.laptop> References: <20071209234943.GB2112@kobe.laptop> <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> <20071210225421.GA28116@keltia.freenix.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20071210225421.GA28116@keltia.freenix.fr> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.949, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.45, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-doc@freebsd.org, freebsd-current@freebsd.org Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 23:48:04 -0000 On 2007-12-10 23:54, Ollivier Robert wrote: >According to Ivan Voras: >> And this gives it the right to block system from booting? I'd at >> least like a symlink from "true" to "fsck_tmpfs". > > It is in the are of « it hurts when I do this. Then don't do that! ». > > Like someone else said, "0" should be used on special fs (like nfs). I was the one. After a couple of email exchanges with Ivan, I also proposed something like the following, to see if he likes it better than stopping the boot process on mount failures: % Here's the source ofmy confusion, then. I don't really % understand why setting the sixth field to zero is something you % don't like. It's explicitly described in the fstab manpage as % the way to disable fsck on the particular filesystem: % % The sixth field, (fs_passno), is used by the fsck(8) and % quotacheck(8) programs to determine the order in which file % system checks are done at reboot time. [...] If the sixth % field is not present or is zero, a value of zero is % returned and fsck(8) and quotacheck(8) will assume that the % file system does not need to be checked. % % The suggestion to make it non-fatal sounds nice though. Maybe % we should consider an `rc.conf' option which controls if mount % failures are actually considered fatal or just `annoying', and % then make the failure conditional on that option, i.e.: % % mount_failure_level={IGNORE,WARN,FATAL} % % Adding a mount(8) option, which can be set per filesystem is % probably also a good idea, i.e. something like: % % /dev/acd0 /cdrom cd9660 ro,auto,mounterror=ignore 0 0 % % It's too late to introduce something like this to 7.0, but if % it works and is accepted as an idea, we can implement it on % HEAD and backport it later :-) I still don't see why user-error in fstab for tmpfs should be treated as a special case, but that's probably me being blinded by a few years of "UNIX can let you shoot your foot, but it's not the fault of UNIX if you do, in fact, blast it off". - Giorgos From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 01:04:14 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EA9816A41A for ; Wed, 12 Dec 2007 01:04:14 +0000 (UTC) (envelope-from rodperson@verizon.net) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mx1.freebsd.org (Postfix) with ESMTP id 63DAB13C4E8 for ; Wed, 12 Dec 2007 01:04:09 +0000 (UTC) (envelope-from rodperson@verizon.net) Received: from atomizer.opensourcebeef.net ([72.95.167.167]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JSW0035MWC06D52@vms040.mailsrvcs.net> for freebsd-current@freebsd.org; Tue, 11 Dec 2007 19:04:48 -0600 (CST) Date: Tue, 11 Dec 2007 19:56:43 -0500 From: Rod Person In-reply-to: <200712120002.08386.thierry@herbelot.com> To: freebsd-current@freebsd.org Message-id: <20071211195643.7faaac28@atomizer.opensourcebeef.net> Organization: Open Source Beef MIME-version: 1.0 X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: base64 References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> <200712120002.08386.thierry@herbelot.com> Cc: thierry@herbelot.com Subject: Re: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 01:04:14 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBXZWQs IDEyIERlYyAyMDA3IDAwOjAyOjA2ICswMTAwDQpUaGllcnJ5IEhlcmJlbG90IDx0aGllcnJ5QGhl cmJlbG90LmNvbT4gd3JvdGU6DQo+IA0KPiB3aXRoIGxlc3MgYW1iaXRpb3VzIGdvYWxzIDogd2hh dCBncmFwaGljIGNhcmQgY2FuIEkgdXNlIHRoZXNlIGRheXMgdG8NCj4gZHJpdmUgbXkgMTY4MHgx MDUwIExDRCB1bmRlciBYMTEgPyAoSSB1c2VkIHRvIHVzZSBteSBvbGRpc2ggcmFkZW9uLA0KPiB3 aXRoIGFuIEFUSTkyMDAsIGJ1dCB0aGUgcmFkZW9uIHN1cHBvcnQgaW4geG9yZyA3LjMgc2VlbXMg dG8gaGF2ZQ0KPiBiZWVuIGJyb2tlbiBmb3IgYXJvdW5kIDMgbW9udGhzIGFuZCBWRVNBIGRvZXMg bm90IGRyaXZlIDE2ODB4MTA1MCkNCj4gZG9lcyB0aGUgeG9yZyBudiBkcml2ZXIgc3VwcG9ydCAx NjgweDEwNTAgPw0KPiANCg0KSSBoYXZlIGEgbnZpZGlhIDc4MDBndHggcnVubmluZyBhdCB0aGlz IHJlc29sdXRpb24uIEkgd291bGQgdGhpbmsgbW9zdA0Kb2YgdGhlIG5ld2VyIGNhcmRzIHdpbGwg aGFuZGxlIGl0LiBUaGUgbnYgZHJpdmVyIGluIHRoZSA3Lnggc2VyaWVzIHhvcmcNCmFyZSBhYmxl IGRvIHRoaXMgcmVzb2x1dGlvbi4NCg0KLSAtLSANClJvZA0KDQpodHRwOi8vcm9kZGllcm9kLmhv bWV1bml4Lm5ldDo4MDgwDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lvbjog R251UEcgdjEuNC43IChGcmVlQlNEKQ0KDQppRDhEQlFGSFh6SExjWkFJYUdTdGNuQVJBZ0IzQUo5 QSsyZnF4bVljWTREckVWd3FzR0NrR0QyK0N3Q2RFUmloDQpBY1psenlCOHd0amRXV3ZsSDJDS2g4 OD0NCj1UREtPDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 03:04:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3C3E16A421 for ; Wed, 12 Dec 2007 03:04:19 +0000 (UTC) (envelope-from qpadla@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 3B01713C465 for ; Wed, 12 Dec 2007 03:04:18 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so59731nfb.33 for ; Tue, 11 Dec 2007 19:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=FGzSv73+k4zIrjuB00dYfMM5IAmmQduZU4BOPgj38aA=; b=dka0JW2diFEsiopTUvW/bz1Cq8eMugSJO4khHID3M0tXmjS8VslBD2JfrByi6qt0O2UMNBqz+hYQmJ6BCa8wrio4K2lO11gnGjX4qwSLm+1+92OdAc5joipDhvtMVybz7syEY9Xzqh785LG940GLCsP2LdQmTl7hfTTkBBBy9i4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=Ervcb7vdGn8oLhelXDLKILPzJA3HysQa6fi1R4jw3MqbkncwqT/Q1h9ceXUS1X3eqFj3lVCQfVVF+A51zULB4fh5/UpGbwkiUaE95OwJelYTCVISmALOTtlAiioajPxAT7G9gFsKS4auPI6jt4UzmsDZLjO1gggdh3mNM9AfkYQ= Received: by 10.86.91.12 with SMTP id o12mr138882fgb.55.1197428657082; Tue, 11 Dec 2007 19:04:17 -0800 (PST) Received: from 77-109-39-227.dynamic.peoplenet.ua ( [77.109.39.227]) by mx.google.com with ESMTPS id p38sm7616309fke.2007.12.11.19.04.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Dec 2007 19:04:16 -0800 (PST) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Wed, 12 Dec 2007 05:04:19 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071211221318.GB47521@obiwan.tataz.chchile.org> In-Reply-To: <20071211221318.GB47521@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7267659.BUuPRfjGbe"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712120504.19496.qpadla@gmail.com> Cc: Jeremie Le Hen Subject: Re: Patch to enable SSP on RELENG_7/CURRENT by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 03:04:19 -0000 --nextPart7267659.BUuPRfjGbe Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 12 December 2007 00:13:18 Jeremie Le Hen wrote: > Hi list, > > I already posted a couple of month ago for a patch to bring in > ProPolice/SSP into 6-STABLE and 7-CURRENT [1]. Understandably, it has > never been commited because this required to heavily patch GCC 3.4.6, > which is a contributed software. > > Now that RELENG_7 and CURRENT have GCC 4.2.1, which provides SSP, > FreeBSD just lacks the "glue" bits to make the best of it. Once > applied, FreeBSD will be compiled with SSP unless WITHOUT_SSP is set. > > This patch is a kind of proof of concept. For example, the FreeBSD > team might not want to enable SSP by default (any benchmark from other > users than me would be welcome). The Makefile guy(s?) may also have > comments on how I've implemented it in the build infrastructure > (SSP_CFLAGS notably). Also, the kernel bits I scrawled in > sys/kern/stack_protector.c should surely be improved. > > Best regards, > > [1] http://tataz.chchile.org/~tataz/FreeBSD/SSP/ Hi Jeremie. There is already WITHOUT_SSP option documented in src.conf in a BETA4 is this some kind of a stub? =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart7267659.BUuPRfjGbe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHX0+z/2R6KvEYGaIRAmniAKC9NI9Rv2ZEWY/4VKVZbXofbdKScACeMZSM 5wADfKRgHJJqnvFuYvbFpfg= =xTE5 -----END PGP SIGNATURE----- --nextPart7267659.BUuPRfjGbe-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 03:12:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 531C016A419 for ; Wed, 12 Dec 2007 03:12:43 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 6A94713C474 for ; Wed, 12 Dec 2007 03:12:42 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so61782nfb.33 for ; Tue, 11 Dec 2007 19:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id; bh=oP/2MQ2hI9lCovlGssbgvYqubtobZw0rygiiEr342wU=; b=xP/tMK0Wj22blCnR563lVgkIfCQDBKdGmKcMr/VTvWEqKCufJp4xpRandzoW23vBRAiGr5UhgqvK4ivARCZpGyxWAmWghtq/UXunM51jH6uZdEf+VOvGwrd1/gEAFZjbRnGKCftQaVlWEkp+EIU1dFjOWIOkcPdt8Iri0xKyDiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:message-id; b=UpgTAg+ma/rPN8Ffz1Ok5NV0qbwpOPkML1BWxdlnVBObcWLa+4a/hA0QqQk162xxv+9zyj5DTT6JpaUW0X4u8BQMsoYs8DzlrxcxD5+XoUqSUSmyd+weCh+n4GLOx1RYWvSLc7LrE4ewRrykqBplPhkvUjzqeQOhhdIkyoIqvTw= Received: by 10.86.25.17 with SMTP id 17mr166217fgy.19.1197429159664; Tue, 11 Dec 2007 19:12:39 -0800 (PST) Received: from 77-109-39-227.dynamic.peoplenet.ua ( [77.109.39.227]) by mx.google.com with ESMTPS id p9sm7571929fkb.2007.12.11.19.12.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Dec 2007 19:12:38 -0800 (PST) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Wed, 12 Dec 2007 05:12:42 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1963907.frzayP3o4C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712120512.42689.qpadla@gmail.com> Subject: Unable to shutdown jail on BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 03:12:43 -0000 --nextPart1963907.frzayP3o4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all. Not sure were to go with this... I see a weird jail behavior on recent=20 BETA4. After successful "/etc/rc.d/jail stop cell" execution the jail is=20 still could be listed with jls command: root@cassini:~# jls = = =20 JID IP Address Hostname Path 4 xxx.53.51.236 php-cgi /home/jails/php-cgi But i am unable to find any processes with this jid in the system: root@cassini:~# ps ax -o jid | grep 4 = = =20 root@cassini:~# =20 Any comments? =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart1963907.frzayP3o4C Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHX1Gq/2R6KvEYGaIRAsxUAJ48Xg7f1+5MlxAf8Q0N28ywZlSDbwCfZpFN GXSfnzxJzep1ogo9lO90SkA= =Qb4m -----END PGP SIGNATURE----- --nextPart1963907.frzayP3o4C-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 03:17:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED5AF16A420 for ; Wed, 12 Dec 2007 03:17:29 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 9C18213C457 for ; Wed, 12 Dec 2007 03:17:29 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 48FD67131; Wed, 12 Dec 2007 16:17:27 +1300 (NZDT) Date: Wed, 12 Dec 2007 16:17:27 +1300 From: Andrew Thompson To: Nikolay Pavlov Message-ID: <20071212031727.GA43155@heff.fud.org.nz> References: <200712120512.42689.qpadla@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712120512.42689.qpadla@gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: Unable to shutdown jail on BETA4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 03:17:30 -0000 On Wed, Dec 12, 2007 at 05:12:42AM +0200, Nikolay Pavlov wrote: > Hi all. > Not sure were to go with this... I see a weird jail behavior on recent > BETA4. After successful "/etc/rc.d/jail stop cell" execution the jail is > still could be listed with jls command: > root@cassini:~# jls > JID IP Address Hostname Path > 4 xxx.53.51.236 php-cgi /home/jails/php-cgi > > But i am unable to find any processes with this jid in the system: > root@cassini:~# ps ax -o jid | grep 4 > root@cassini:~# > > Any comments? This has been fixed (sort of), make sure you have r1.208.2.1 of /usr/src/sys/kern/kern_conf.c cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 03:20:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD44D16A417 for ; Wed, 12 Dec 2007 03:20:38 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7C49E13C442 for ; Wed, 12 Dec 2007 03:20:38 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so58576rvb.43 for ; Tue, 11 Dec 2007 19:20:37 -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=ZKJQKDDqGwv8ucjDHm7OMyFVaqSYEW8THZeh5HugExs=; b=tGHAep2/ZxJtpfH2bwJ0mQ4sUJkCL7jLgSn9qkEVqJ4SXC8PBbZB9XzOOBckBkvcYyBL6XDkzjWwAp5mkHckcstesg5+27OpWFB48729wnWvExpSoraTZftcR14UDqd+vm7Lz/JeyAnXxmdTVxtnBPmNaBDLQIPDwM2oH1BuYio= 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=KK/FtrHjBGNXqn4srRv3NfcuAqwI11T1DrEXxEea7L5R6ZZrqwyGRTFwYkQQia4e3gP2mqDXr5eNWGBDBHPLh9XeI0wqqthm+nf7Pq710ivPjEZSnabLSS7v5YbSIymZztJw1so8Mg9tLdzJOULDAmmgLU4oKiCmgkPewT/CovE= Received: by 10.140.133.11 with SMTP id g11mr67872rvd.235.1197429637441; Tue, 11 Dec 2007 19:20:37 -0800 (PST) Received: from ?10.0.0.6? ( [218.111.42.229]) by mx.google.com with ESMTPS id b39sm2391571rvf.2007.12.11.19.20.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Dec 2007 19:20:35 -0800 (PST) From: OutBackDingo To: thierry@herbelot.com In-Reply-To: <200712120002.08386.thierry@herbelot.com> References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> <200712120002.08386.thierry@herbelot.com> Content-Type: text/plain Date: Wed, 12 Dec 2007 11:20:17 +0800 Message-Id: <1197429617.8914.1.camel@dingo-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.21.3 Content-Transfer-Encoding: 7bit Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 03:20:38 -0000 my ATI card in my laptop has no issue with this resolution using the ati driver, though my card is an x600 it does run at 1680x1050 all day long for a year now On Wed, 2007-12-12 at 00:02 +0100, Thierry Herbelot wrote: > > I don't know the status of ATI at the moment - if you want 3D support > > on FreeBSD right *now* I think nvidia/i386 is your only option. > > > > -Kip > > Hello, > > with less ambitious goals : what graphic card can I use these days to drive my > 1680x1050 LCD under X11 ? (I used to use my oldish radeon, with an ATI9200, > but the radeon support in xorg 7.3 seems to have been broken for around 3 > months and VESA does not drive 1680x1050) does the xorg nv driver support > 1680x1050 ? > > TfH > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 03:35:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D90E316A479 for ; Wed, 12 Dec 2007 03:35:10 +0000 (UTC) (envelope-from lihong.chen@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id AF3CC13C469 for ; Wed, 12 Dec 2007 03:35:10 +0000 (UTC) (envelope-from lihong.chen@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so62123rvb.43 for ; Tue, 11 Dec 2007 19:35:10 -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:content-type:date:message-id:mime-version:x-mailer:sender; bh=4vQ309Wbp/sIlG+ni0YeMbSKg0vd5RMRRWCygYdV/tU=; b=jH/C/2xvBzzKUetcVcsCqEXRq777ZKNk7eh+yL/yPrgtp0Wt6uFXPTxBafF+CsaKyXrFPMzmCTLKmOEsYL6CwLWhOf5hsD95kYktU9Yv9l19chxeDzhKr4EwbE5SLo9gNIjQxAtQZKXrL9ZzIMoFbfS3z5ER7NNFRM6S1kCt//8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer:sender; b=TaPQ6tE+lOtLOUNq9FL2rN0W6kTnxpYbmdImxvAttSd30H9ZXeeRVuAZ7vug+W8qJgsY5a646/1wl0YrajVS0VO+ydRT+HxW6kHvTHYIDCBymmChR743pm98qISWYHsdGTMx/uje5J2QTKTq/behTvf37LsuZkjpt7q9cFCYy9c= Received: by 10.140.139.3 with SMTP id m3mr82744rvd.38.1197428815950; Tue, 11 Dec 2007 19:06:55 -0800 (PST) Received: from ?192.168.10.84? ( [59.125.13.44]) by mx.google.com with ESMTPS id c19sm10560931rvf.2007.12.11.19.06.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Dec 2007 19:06:54 -0800 (PST) From: "Eric L. Chen" To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Content-Type: multipart/mixed; boundary="=-a3QXkU35vvFSIr/5c+sL" Date: Wed, 12 Dec 2007 11:06:48 +0800 Message-Id: <1197428808.1576.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Sender: "Eric L. Chen" Cc: Subject: Fix cannot build mencoder on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 03:35:10 -0000 --=-a3QXkU35vvFSIr/5c+sL Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi! I cannot build mencoder on freebsd-7/amd64 successfully, like this: {standard input}: Assembler messages: {standard input}:1289: Error: can't encode register '%ch' in an instruction requiring REX prefix. {standard input}:1290: Error: can't encode register '%ah' in an instruction requiring REX prefix. {standard input}:1291: Error: can't encode register '%dh' in an instruction requiring REX prefix. make[3]: *** [osd.o] Error 1 After tried some guy's patch, it works on FreeBSD too. I tried encoding some DVDs to x264 encoded no any problem found. --=-a3QXkU35vvFSIr/5c+sL Content-Disposition: attachment; filename=ports.patch Content-Type: text/x-patch; name=ports.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit diff -urN /usr/ports/multimedia/mencoder/Makefile /usr/ports/multimedia/mencoder/Makefile --- /usr/ports/multimedia/mencoder/Makefile 2007-12-10 09:45:16.000000000 +0800 +++ /usr/ports/multimedia/mencoder/Makefile 2007-12-10 09:46:45.000000000 +0800 @@ -55,7 +55,10 @@ sws-test w32codec_dl.pl wma2ogg.pl x2mpsub.sh .include - +.if ${ARCH} == amd64 +PATCH_SITES+=http://launchpadlibrarian.net/4441618/ +PATCHFILES+=mplayer-0.99+1.0pre8-X64.diff +.endif LIB_DEPENDS+= mp3lame.0:${PORTSDIR}/audio/lame BUILD_DEPENDS+= mplayer:${PORTSDIR}/multimedia/mplayer RUN_DEPENDS+= mplayer:${PORTSDIR}/multimedia/mplayer diff -urN mencoder/distinfo mencoder/distinfo --- /usr/ports/multimedia/mencoder/distinfo 2007-12-10 09:45:16.000000000 +0800 +++ /usr/ports/multimedia/mencoder/distinfo 2007-12-10 09:44:51.000000000 +0800 @@ -4,3 +4,6 @@ MD5 (asmrules_fix_20061231.diff) = f0b71c38b1207c1d604be091876ac051 SHA256 (asmrules_fix_20061231.diff) = 3f71e6f4e07940d4d55084d0df12404371bc4e534a3a6b0756ca73e44ddbc3c4 SIZE (asmrules_fix_20061231.diff) = 1450 +MD5 (mplayer-0.99+1.0pre8-X64.diff) = 47d76978861df599973c9a4822780a1d +SHA256 (mplayer-0.99+1.0pre8-X64.diff) = 5f44021e1d10dcaba72fa391bd49fcfa3a0592a7dd7da6dd5f2325e7c976de3c +SIZE (mplayer-0.99+1.0pre8-X64.diff) = 360 --=-a3QXkU35vvFSIr/5c+sL-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 06:36:52 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B6E116A417 for ; Wed, 12 Dec 2007 06:36:52 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from ape.monkeybrains.net (ape.monkeybrains.net [208.69.40.11]) by mx1.freebsd.org (Postfix) with ESMTP id 0496613C469 for ; Wed, 12 Dec 2007 06:36:51 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from monchichi.monkeybrains.net (adsl-76-221-207-113.dsl.pltn13.sbcglobal.net [76.221.207.113]) (authenticated bits=0) by ape.monkeybrains.net (8.14.1/8.14.1) with ESMTP id lBC6apKs083651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Dec 2007 22:36:51 -0800 (PST) (envelope-from crapsh@monkeybrains.net) Message-ID: <475F81AB.6050709@monkeybrains.net> Date: Tue, 11 Dec 2007 22:37:31 -0800 From: Rudy User-Agent: Thunderbird 2.0.0.9 (X11/20071122) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on pita.monkeybrains.net X-Virus-Status: Clean Subject: BTX loader fails via USB-CDROM on some motherboards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 06:36:52 -0000 I cannot install FreeBSD 7.0-BETA4 on a SuperMicro PDSML motherboard via USB-CDROM drive. Here is an example motherboard that is a pain in the butt to install FreeBSD onto: http://supermicro.com/products/motherboard/Xeon3000/3000/PDSML-LN2+.cfm Sure this is an old problem... http://docs.freebsd.org/cgi/getmsg.cgi?fetch=78298+0+archive/2007/freebsd-stable/20070128.freebsd-stable http://lists.freebsd.org/pipermail/freebsd-stable/2007-May/035447.html http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/143730.html http://lists.freebsd.org/pipermail/freebsd-qa/2006-September/000783.html Sure would be nice if someone found fix the 'real mode' 'vm86' problem that plagues FreeBSD install disks but no other OS that I know of. I am offering a $50 bounty to FreeBSD http://www.freebsd.org/donations/ if the standard ISO for FreeBSD 7.0-RELEASE does not have this problem. Rudy From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 07:12:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B2B016A417 for ; Wed, 12 Dec 2007 07:12:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.freebsd.org (Postfix) with ESMTP id 8CCD413C461 for ; Wed, 12 Dec 2007 07:12:28 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-064-186-128.pools.arcor-ip.net [88.64.186.128]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1J2Lla3QBv-0003FB; Wed, 12 Dec 2007 08:12:27 +0100 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org, thierry@herbelot.com Date: Wed, 12 Dec 2007 08:12:14 +0100 User-Agent: KMail/1.9.7 References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <200712120002.08386.thierry@herbelot.com> In-Reply-To: <200712120002.08386.thierry@herbelot.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1775694.zpvUllSMC7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712120812.22499.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+06clv6EeH9Im9EZaG5T67A4Q2RI0S6pk7kRP I4xFBEvlNMWa5AkCGWfwR5RnWkgQqh3awrUjk12o1EWEOZGmmq 2vBp4UU2Lf36khMixKT48mJSQqJzByruAkS7c9tvmo= Cc: Subject: Re: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 07:12:29 -0000 --nextPart1775694.zpvUllSMC7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 12 December 2007, Thierry Herbelot wrote: > > I don't know the status of ATI at the moment - if you want 3D support > > on FreeBSD right *now* I think nvidia/i386 is your only option. > > > > -Kip > > Hello, > > with less ambitious goals : what graphic card can I use these days to > drive my 1680x1050 LCD under X11 ? (I used to use my oldish radeon, > with an ATI9200, but the radeon support in xorg 7.3 seems to have been > broken for around 3 months and VESA does not drive 1680x1050) does the > xorg nv driver support 1680x1050 ? I'm using the "ati" driver with my Radeon 9200 to drive my 1680x1050. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1775694.zpvUllSMC7 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) iD8DBQBHX4nWXyyEoT62BG0RAs/9AJ9++BoaEZEvxQbNRyt/gkRZj3bPjACdGqIf Mw6s/QlxIyVx9cuxvbAKQpU= =T1Nu -----END PGP SIGNATURE----- --nextPart1775694.zpvUllSMC7-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 07:38:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19CA616A418 for ; Wed, 12 Dec 2007 07:38:51 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 9181F13C469 for ; Wed, 12 Dec 2007 07:38:50 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so125261nfb.33 for ; Tue, 11 Dec 2007 23:38: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=o6Bk4gu+z9h+guaHHWQGAz77DohFjI6hraMs9bWYoi4=; b=AYBsSpHB2T2cQj4cc8bK9e9LZf/OjiKmK5OP9P/DXxsb2geIJuXujhq7QGmGWApQbEfMfZE8vPGvwdKJG9UIhyPrxvVfPfgYhsWf+joQwVBi+h+DmhJgduLngnfG6ADXdDu1TmGqj6UlpvGsbI0NGUCNciY4wrz9MJJpklbi2pc= 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=EIHoKQ5FwQgXXgSKxRKoX3Twef0dtHFM/xhH4cCzVSX9EKMs/3ZH4O/8jUf1uRKOxpLAkkfUyRA0AhnRcwoN1zg1ushU0ystS5ULuS09kUtNEWi/33+GTz+zkuhssFUW89K3m7lvWkEPOHAwo7vnKftmZpGAKvXzAbJ8VcVy+DY= Received: by 10.86.4.2 with SMTP id 2mr378517fgd.5.1197445129331; Tue, 11 Dec 2007 23:38:49 -0800 (PST) Received: by 10.86.91.5 with HTTP; Tue, 11 Dec 2007 23:38:49 -0800 (PST) Message-ID: <11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com> Date: Wed, 12 Dec 2007 01:38:49 -0600 From: "Sam Fourman Jr." To: "Ken Menzel" In-Reply-To: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com> Cc: Thomas Sparrevohn , Martin Cracauer , freebsd-current@freebsd.org, Poul-Henning Kamp Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 07:38:51 -0000 On Dec 11, 2007 2:37 PM, Ken Menzel wrote: > > > > So did anyone file a PR? Or is someone already working on this? > > Seems fairly major to me as I am seeing the same thing here, on > > single CPU systems and a dual quad core system. If needed I will > > create the PR. > > > > Ken > P.S. I should have added I am running releng_7 beta 4 and seeing the > same problem. i did not file a PR (I don't know how I have never done one.) I am Running 7.0 BETA_3 here Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 08:17:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF67616A41A for ; Wed, 12 Dec 2007 08:17:11 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 7872413C47E for ; Wed, 12 Dec 2007 08:17:11 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 18EB83F6183; Wed, 12 Dec 2007 09:17:10 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id DD3523F6152; Wed, 12 Dec 2007 09:17:09 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 4F1519C36B; Wed, 12 Dec 2007 08:14:48 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 3C4D9405B; Wed, 12 Dec 2007 09:14:48 +0100 (CET) Date: Wed, 12 Dec 2007 09:14:48 +0100 From: Jeremie Le Hen To: Nikolay Pavlov Message-ID: <20071212081448.GA60133@obiwan.tataz.chchile.org> References: <20071211221318.GB47521@obiwan.tataz.chchile.org> <200712120504.19496.qpadla@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200712120504.19496.qpadla@gmail.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-current@freebsd.org Subject: Re: Patch to enable SSP on RELENG_7/CURRENT by default X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 08:17:11 -0000 Hi Nikolay, On Wed, Dec 12, 2007 at 05:04:19AM +0200, Nikolay Pavlov wrote: > There is already WITHOUT_SSP option documented in src.conf in a BETA4 > is this some kind of a stub? Yes, it already exists but only to build libssp. I've diverted it because it was more straightforward :), but it would be easy to create a new knob for this. Currently, the documentation for WITHOUT_SSP is: « Set to not build propolice stack smashing protection library. » I would change it to: « Set to build libraries, programs, kernel, and modules with propolice. GNU libssp will not be built either. » I will happily submit the documentation if the patch hits the tree. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 09:40:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7510E16A41A for ; Wed, 12 Dec 2007 09:40:39 +0000 (UTC) (envelope-from kockac@zuikaku.org) Received: from saratoga.zuikaku.org (unknown [IPv6:2001:1ba0::20a:e4ff:fe5a:25bb]) by mx1.freebsd.org (Postfix) with ESMTP id ED0AB13C46A for ; Wed, 12 Dec 2007 09:40:38 +0000 (UTC) (envelope-from kockac@zuikaku.org) Received: from saratoga.zuikaku.org (localhost [127.0.0.1]) by saratoga.zuikaku.org (8.14.2/8.14.1) with ESMTP id lBC9eVog004577; Wed, 12 Dec 2007 10:40:31 +0100 (CET) (envelope-from kockac@zuikaku.org) Received: (from kockac@localhost) by saratoga.zuikaku.org (8.14.2/8.14.1/Submit) id lBC9eUig004576; Wed, 12 Dec 2007 10:40:30 +0100 (CET) (envelope-from kockac@zuikaku.org) X-Authentication-Warning: saratoga.zuikaku.org: kockac set sender to kockac@zuikaku.org using -f Date: Wed, 12 Dec 2007 10:40:30 +0100 From: Matej Kubik To: S?ren Schmidt , freebsd-current@freebsd.org Message-ID: <20071212094029.GA993@saratoga.zuikaku.org> References: <73807.10710.qm@web63912.mail.re1.yahoo.com> <200711280842.09340.jhb@freebsd.org> <474D726A.8080807@deepcore.dk> <200711280938.38545.jhb@freebsd.org> <474E5B69.7070406@yandex.ru> <474E65D6.4040403@deepcore.dk> <474E69AE.7000105@yandex.ru> <475978E1.2090507@deepcore.dk> <475C6C3E.6070004@deepcore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475C6C3E.6070004@deepcore.dk> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Any successful installs on a Broadcom HT1000 chipset? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 09:40:39 -0000 On Sun, Dec 09, 2007 at 11:29:18PM +0100, S?ren Schmidt wrote: > Anyhow the attached patch seems to work around the problem by limitting > transfer to a max of 126 sectors in one go, at least I have move several > hundred Gb's around now on a zfs volume without problems, which > certainly wasn't possible before. Thank you for you work, this patch really did help. At least I had no errors for about 16 hours, I'll try some stress-testing today or tomorrow if I have time. I haven't had any kernel panic yet, so I can't comment on the broken dumping on panic thing... I agree with Travis Mikalson that it would be nice if the patch could make it into 7.0-RELEASE so that HT1000 users could install it without corrupting their data. Once again - thanks for the patch, it really helped me :-) Matej Kubik From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 09:43:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F6916A41B for ; Wed, 12 Dec 2007 09:43:11 +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 05CB013C458 for ; Wed, 12 Dec 2007 09:43:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J2O7K-000JYn-Vt for freebsd-current@freebsd.org; Wed, 12 Dec 2007 11:43:09 +0200 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 lBC9gwVl035056; Wed, 12 Dec 2007 11:42:58 +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 lBC9gvRu035055; Wed, 12 Dec 2007 11:42:57 +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: Wed, 12 Dec 2007 11:42:57 +0200 From: Kostik Belousov To: Rudy Message-ID: <20071212094257.GA2138@deviant.kiev.zoral.com.ua> References: <475F81AB.6050709@monkeybrains.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <475F81AB.6050709@monkeybrains.net> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: f2683d8df775da069012ccac6e6e6321 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1872 [Dec 11 2007] 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-current@freebsd.org Subject: Re: BTX loader fails via USB-CDROM on some motherboards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 09:43:11 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 11, 2007 at 10:37:31PM -0800, Rudy wrote: >=20 > I cannot install FreeBSD 7.0-BETA4 on a SuperMicro PDSML motherboard via= =20 > USB-CDROM drive. >=20 >=20 > Here is an example motherboard that is a pain in the butt to install=20 > FreeBSD onto: > http://supermicro.com/products/motherboard/Xeon3000/3000/PDSML-LN2+.cfm >=20 > Sure this is an old problem...=20 > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D78298+0+archive/2007/freeb= sd-stable/20070128.freebsd-stable > http://lists.freebsd.org/pipermail/freebsd-stable/2007-May/035447.html > http://lists.freebsd.org/pipermail/freebsd-questions/2007-March/143730.h= tml > http://lists.freebsd.org/pipermail/freebsd-qa/2006-September/000783.html >=20 > Sure would be nice if someone found fix the 'real mode' 'vm86' problem th= at=20 > plagues FreeBSD install disks but no other OS that I know of. I am=20 > offering a $50 bounty to FreeBSD > http://www.freebsd.org/donations/ > if the standard ISO for FreeBSD 7.0-RELEASE does not have this problem. Take the http://people.freebsd.org/~kib/realbtx/realbtx.2.patch and rebuild the ISO image with the patch. Code is not ready for inclusion into the CVS. --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHX60gC3+MBN1Mb4gRApUcAJ0fkAAiH9ES8g8MRVdudrAi3lFywACeLRiU 4Zd0I+O74XgkWs+Z5W+jdM8= =xzhE -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 10:09:49 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FBC016A469 for ; Wed, 12 Dec 2007 10:09:49 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2001:1b20:1:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7549513C45B for ; Wed, 12 Dec 2007 10:09:48 +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 lBCA9bVc035756; Wed, 12 Dec 2007 11:09:46 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id lBCA9bvF035755; Wed, 12 Dec 2007 11:09:37 +0100 (CET) (envelope-from olli) Date: Wed, 12 Dec 2007 11:09:37 +0100 (CET) Message-Id: <200712121009.lBCA9bvF035755@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, kip.macy@gmail.com, sfourman@gmail.com In-Reply-To: X-Newsgroups: list.freebsd-current 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, 12 Dec 2007 11:09:47 +0100 (CET) Cc: Subject: Re: amd64 NVIDIA support in FreeBSD 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG, kip.macy@gmail.com, sfourman@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 10:09:49 -0000 Kip Macy wrote: > Sam Fourman Jr. wrote: > > from what it sounds like it ATI may be more of a realistic hope for > > compiz, and 3D video games to one day work on 64bit FreeBSD > > > > Thank you for taking the time to explain this. > > I don't know the status of ATI at the moment - if you want 3D support > on FreeBSD right *now* I think nvidia/i386 is your only option. It depends on your performance requirements. If you don't need the latest and fastest, an intel graphics chip might be an option. 3D acceleration support works fine with the i915 in my two years old notebook, and it's supposed to work as well with newer ones (although I've seen a problem report for the i965 recently). 3D performance is sufficient to run typical OpenGL screen savers or OpenGL games such as crack-attack or xkobo-deluxe in full screen (1400 x 1050) without flicker or jitter. That's a 2-years old 1.6 GHz Pentium-M. Of course, if you need only standard 2D acceleration (no 3D games and stuff), just about any graphics hardware should be fine. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd cat man du : where Unix geeks go when they die From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 10:28:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6E7516A419 for ; Wed, 12 Dec 2007 10:28:09 +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 800AE13C45B for ; Wed, 12 Dec 2007 10:28:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J2Oot-000L40-LE for freebsd-current@freebsd.org; Wed, 12 Dec 2007 12:28:08 +0200 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 lBCARt9v064502; Wed, 12 Dec 2007 12:27:55 +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 lBCARrnc064459; Wed, 12 Dec 2007 12:27:53 +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: Wed, 12 Dec 2007 12:27:53 +0200 From: Kostik Belousov To: "Sam Fourman Jr." Message-ID: <20071212102753.GD2138@deviant.kiev.zoral.com.ua> References: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com> <11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3Gf/FFewwPeBMqCJ" Content-Disposition: inline In-Reply-To: <11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: bb9f355b5be917825c280d06cf0e20ab X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1872 [Dec 11 2007] 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: Ken Menzel , Thomas Sparrevohn , freebsd-current@freebsd.org, Poul-Henning Kamp , Martin Cracauer Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 10:28:10 -0000 --3Gf/FFewwPeBMqCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 12, 2007 at 01:38:49AM -0600, Sam Fourman Jr. wrote: > On Dec 11, 2007 2:37 PM, Ken Menzel wrote: > > > > > > So did anyone file a PR? Or is someone already working on this? > > > Seems fairly major to me as I am seeing the same thing here, on > > > single CPU systems and a dual quad core system. If needed I will > > > create the PR. > > > > > > Ken > > P.S. I should have added I am running releng_7 beta 4 and seeing the > > same problem. >=20 >=20 > i did not file a PR (I don't know how I have never done one.) I am > Running 7.0 BETA_3 here >=20 > Sam Fourman Jr. You can start investigating by looking at the value of the cpu_idle_hook on your machine. Most likely, it should point to the acpi_cpu_idle(). If yes, this would forward the question to the ACPI code. --3Gf/FFewwPeBMqCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHX7epC3+MBN1Mb4gRAsIMAJsHO9RKkBcVhoWJcYIzYLf5VOILAQCg7ZwP t1WW/qZwd6iR/7sYJm+Ukdc= =X45Z -----END PGP SIGNATURE----- --3Gf/FFewwPeBMqCJ-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 12:13:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6C5916A419 for ; Wed, 12 Dec 2007 12:13:27 +0000 (UTC) (envelope-from simias.n@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA5013C46A for ; Wed, 12 Dec 2007 12:13:26 +0000 (UTC) (envelope-from simias.n@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so393325mue.3 for ; Wed, 12 Dec 2007 04:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=KJesgXGsloOxEucZJsH0tHq+Gp303YGz1YOzWajMNIU=; b=NLptlcILWpbKnF5COthGGtrjgKoIz0viJ+Z23VAJjXm/vXRumDzfsot1tK5enx776pTaMmrL6mzF2TEB78yCUVO6oaz1xDEpBov/CR/F5ilZ815qUceLVB14TwCVIj2/B+WQs/YncMk84xNBQnbV26NKlCH+jAgaMwwOCPh6f9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; b=H7EuCpSOrxOsShsX93UVJAbWcAFH9s3txHNwCxSa5bYfX4A6RCpiCXsdsGA86Zk4K6MSZc2ZSS+alIPIJE/CIqs64/HwMeOVqV/8bTF+13F6JYVjm3O/TRdWQRqFkBHDoJ1rJDK9ZV/gsfGrWDHaCITcernAVY3pR5OF5v7kJsI= Received: by 10.82.167.5 with SMTP id p5mr1708664bue.2.1197461605411; Wed, 12 Dec 2007 04:13:25 -0800 (PST) Received: from simias.hd.free.fr ( [82.243.51.8]) by mx.google.com with ESMTPS id y34sm7393163iky.2007.12.12.04.13.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2007 04:13:24 -0800 (PST) From: Lionel Flandrin To: thierry@herbelot.com References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> <200712120002.08386.thierry@herbelot.com> Date: Wed, 12 Dec 2007 13:13:20 +0100 In-Reply-To: <200712120002.08386.thierry@herbelot.com> (Thierry Herbelot's message of "Wed, 12 Dec 2007 00:02:06 +0100") Message-ID: <86ejdsqffj.fsf@simias.hd.free.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 12:13:27 -0000 Thierry Herbelot writes: > Hello, > > with less ambitious goals : what graphic card can I use these days to drive my > 1680x1050 LCD under X11 ? (I used to use my oldish radeon, with an ATI9200, > but the radeon support in xorg 7.3 seems to have been broken for around 3 > months and VESA does not drive 1680x1050) does the xorg nv driver support > 1680x1050 ? > > TfH I have a radeon 9600 for my dual head display @ 1920x1440, the 3d is partly broken tho, but as the man page of radeon(4x) states: ,---- | Option "RenderAccel" "boolean" | Enables or disables hardware Render acceleration. This driver | does not support component alpha (subpixel) rendering. It is | only supported on Radeon series up to and including 9200 | (9500/9700 and newer unsupported). The default is to enable | Render acceleration. `---- So it might work with your 9200 card. I don't know why you say the radeon support is broken in Xorg 7.3, it works well here. The only problem I've got was because of an nforce 2 related breakage in the FreeBSD kernel itself, a patch has been posted on this mailing list a couple of weeks ago if you're concerned. I hope that helps, -- Lionel Flandrin From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 07:42:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8D0A16A473 for ; Wed, 12 Dec 2007 07:42:08 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id A526C13C4F2 for ; Wed, 12 Dec 2007 07:42:08 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 5A2F78C0EE; Wed, 12 Dec 2007 01:42:08 -0600 (CST) Date: Wed, 12 Dec 2007 01:42:08 -0600 To: "Sam Fourman Jr." Message-ID: <20071212074208.GD29211@soaustin.net> References: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com> <11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Wed, 12 Dec 2007 12:17:46 +0000 Cc: freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 07:42:08 -0000 On Wed, Dec 12, 2007 at 01:38:49AM -0600, Sam Fourman Jr. wrote: > I did not file a PR (I don't know how I have never done one.) Please see http://www.freebsd.org/support/bugreports.html. mcl From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 15:08:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DEC316A419 for ; Wed, 12 Dec 2007 15:08:34 +0000 (UTC) (envelope-from guru@pramana.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 4F45A13C4CC for ; Wed, 12 Dec 2007 15:08:34 +0000 (UTC) (envelope-from guru@pramana.com) Received: by an-out-0708.google.com with SMTP id c14so75248anc.13 for ; Wed, 12 Dec 2007 07:08:33 -0800 (PST) Received: by 10.100.206.11 with SMTP id d11mr1563196ang.98.1197470542495; Wed, 12 Dec 2007 06:42:22 -0800 (PST) Received: from GuruRajanPC ( [74.7.5.109]) by mx.google.com with ESMTPS id 7sm8284246agd.2007.12.12.06.42.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2007 06:42:21 -0800 (PST) From: "Guru Rajan" To: Date: Wed, 12 Dec 2007 09:42:46 -0500 Message-ID: <000401c83ccd$43b53350$cb1f99f0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg8zULS7R7O+LCDQt+HA/mxIladPA== Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Freebsd 6.2-current install on dell optiplex GX520 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 15:08:34 -0000 I am trying to install on dell GX520 platform. The boot starts ok and sysinstall starts to run, with disk partitioning completed, it gives an error message "unable to transfer the base distribution from acd0". I have burned 4 cd's of the boot disk so far and I can reproduce this issue consistently. What is wrong here. Is there some other thing clashing with the cdrom driver routine, please give me your insight as to what problem this is. Thanks Guru From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 16:55:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B9F916A420 for ; Wed, 12 Dec 2007 16:55:56 +0000 (UTC) (envelope-from kenfreebsd@icarz.com) Received: from deanna.icarz.com (deanna.icarz.com [207.99.22.19]) by mx1.freebsd.org (Postfix) with ESMTP id B7E3813C467 for ; Wed, 12 Dec 2007 16:55:55 +0000 (UTC) (envelope-from kenfreebsd@icarz.com) Received: from kenxp (netb-138.icarz.com [209.123.219.138]) by deanna.icarz.com (8.13.8/8.13.8) with SMTP id lBCGtrpL064124 for ; Wed, 12 Dec 2007 11:55:53 -0500 (EST) (envelope-from kenfreebsd@icarz.com) Message-ID: <136c01c83cdf$db5f0430$8adb7bd1@icarz.com> From: "Ken Menzel" To: References: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com><11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com> <20071212074208.GD29211@soaustin.net> Date: Wed, 12 Dec 2007 11:55:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: -101.164 () ALL_TRUSTED, AWL, BAYES_00, STOX_REPLY_TYPE, USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.63 on 207.99.22.19 Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ken Menzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 16:55:56 -0000 ----- Original Message ----- From: "Mark Linimon" To: "Sam Fourman Jr." Cc: Sent: Wednesday, December 12, 2007 2:42 AM Subject: Re: CURRENT Kernel makes the system run very very hot > On Wed, Dec 12, 2007 at 01:38:49AM -0600, Sam Fourman Jr. wrote: >> I did not file a PR (I don't know how I have never done one.) > > Please see http://www.freebsd.org/support/bugreports.html. > > mcl Thanks Mark, It seems like it may be an ACPI problem based on: (kgdb) print cpu_idle_hook $1 = (void (*)(void)) 0xffffffff801d0bb0 (kgdb) q Thanks to Kostik Belousov for the advice on where to go next. And based on that I will move this to the ACPI mailing list and file a PR. Thanks, Ken From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 17:11:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E69116A417 for ; Wed, 12 Dec 2007 17:11:30 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 33B7813C448 for ; Wed, 12 Dec 2007 17:11:30 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id lBCHBTXq053895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2007 09:11:29 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47601641.7050707@errno.com> Date: Wed, 12 Dec 2007 09:11:29 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Ken Menzel References: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com><11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com> <20071212074208.GD29211@soaustin.net> <136c01c83cdf$db5f0430$8adb7bd1@icarz.com> In-Reply-To: <136c01c83cdf$db5f0430$8adb7bd1@icarz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Rhyolite-Metrics: o.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 17:11:30 -0000 Ken Menzel wrote: > ----- Original Message ----- From: "Mark Linimon" > To: "Sam Fourman Jr." > Cc: > Sent: Wednesday, December 12, 2007 2:42 AM > Subject: Re: CURRENT Kernel makes the system run very very hot > > >> On Wed, Dec 12, 2007 at 01:38:49AM -0600, Sam Fourman Jr. wrote: >>> I did not file a PR (I don't know how I have never done one.) >> >> Please see http://www.freebsd.org/support/bugreports.html. >> >> mcl > Thanks Mark, It seems like it may be an ACPI problem based on: > > (kgdb) print cpu_idle_hook > $1 = (void (*)(void)) 0xffffffff801d0bb0 > (kgdb) q > > Thanks to Kostik Belousov for the advice on where to go next. And > based on that I will move this to the ACPI mailing list and file a PR. > My PR is http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/117727. Not clear if the issues are the same (my PR is about operation on a UP laptop). Sam From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 17:18:01 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8A0A16A419 for ; Wed, 12 Dec 2007 17:18:01 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 9B8E813C474 for ; Wed, 12 Dec 2007 17:18:01 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so534753waf.3 for ; Wed, 12 Dec 2007 09:18:01 -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=1lf1lC2JITEH+Z15dsBuvbsCIdqunwk5J3qT73dxkR0=; b=a/zJdassbVg33E/qs2sfbRuTOnns+s+YdA1yZr3dKuotVHc5l3vtS6IIEVHvmFRurt89C9MyMiePaTFlfc0DKYs63Ulop2PUNGb0ue3qqVV39JgN6NagjitJpS+oLeZ029eiK39mE3cPLl9+aP0VdiI7osqyWSJILfEnO1QVJLQ= 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=xdJNjFk6ayI4dk0PbG1PO02CYeiq3vzasQh3+39uzdNPfiFr52orCdIxOff+/CjWIYqMP7WEPdjguqeaSbIxbhUID0WusQvbe4l/IKVZEX9YOxf/r5AIycYHbSQ2q5w0iasmFj8cMYqE/V0zOyfNGlFQ0u6H5Iy266xDA+oN9to= Received: by 10.115.77.1 with SMTP id e1mr1029574wal.103.1197479880853; Wed, 12 Dec 2007 09:18:00 -0800 (PST) Received: by 10.114.110.16 with HTTP; Wed, 12 Dec 2007 09:18:00 -0800 (PST) Message-ID: Date: Wed, 12 Dec 2007 18:18:00 +0100 From: "Rene Ladan" To: "Ken Menzel" In-Reply-To: <136c01c83cdf$db5f0430$8adb7bd1@icarz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com> <11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com> <20071212074208.GD29211@soaustin.net> <136c01c83cdf$db5f0430$8adb7bd1@icarz.com> Cc: freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 17:18:02 -0000 2007/12/12, Ken Menzel : > ----- Original Message ----- > From: "Mark Linimon" > To: "Sam Fourman Jr." > Cc: > Sent: Wednesday, December 12, 2007 2:42 AM > Subject: Re: CURRENT Kernel makes the system run very very hot > > > > On Wed, Dec 12, 2007 at 01:38:49AM -0600, Sam Fourman Jr. wrote: > >> I did not file a PR (I don't know how I have never done one.) > > > > Please see http://www.freebsd.org/support/bugreports.html. > > > > mcl > Thanks Mark, It seems like it may be an ACPI problem based on: > > (kgdb) print cpu_idle_hook > $1 = (void (*)(void)) 0xffffffff801d0bb0 > (kgdb) q > > Thanks to Kostik Belousov for the advice on where to go next. And > based on that I will move this to the ACPI mailing list and file a PR. > Hmm, on my too hot i386 laptop: # make installkernel.debug #gdb /boot/kernel/kernel GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) print cpu_idle_hook $1 = (void (*)(void)) 0xc063cc9b (gdb) print cpu_idle_default $2 = {void (void)} 0xc063cc9b #grep -r cpu_idle_default * amd64/amd64/machdep.c:cpu_idle_default(void) amd64/amd64/machdep.c:void (*cpu_idle_hook)(void) = cpu_idle_default; dev/acpica/acpi_cpu.c: /* Take over idling from cpu_idle_default(). */ i386/i386/machdep.c:cpu_idle_default(void) i386/i386/machdep.c:void (*cpu_idle_hook)(void) = cpu_idle_default; ia64/ia64/machdep.c:cpu_idle_default(void) ia64/ia64/machdep.c:void (*cpu_idle_hook)(void) = cpu_idle_default; pc98/pc98/machdep.c:cpu_idle_default(void) pc98/pc98/machdep.c:void (*cpu_idle_hook)(void) = cpu_idle_default; #dmesg |grep -i acpi Features=0xbfebfbff ACPI APIC Table: acpi0: <_ASUS_ Notebook> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of e0000, 20000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 cpu0: on acpi0 cpu1: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [SSDT] - 99, should be 2C [20070320] acpi_asus0: Unsupported Asus laptop: A6Je pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 acpi_video0: on vgapci0 pcib2: irq 20 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 19 at device 28.3 on pci0 pci3: on pcib3 pcib4: at device 30.0 on pci0 pci4: on pcib4 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 speaker0: port 0x61 on acpi0 acpi_asus0: Unsupported Asus laptop: A6Je hw.acpi.cpu.cx_lowest: C1 So I have an ACPI capable CPU but it is not (properly) loaded? Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 17:46:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F9E316A420 for ; Wed, 12 Dec 2007 17:46:49 +0000 (UTC) (envelope-from kenfreebsd@icarz.com) Received: from deanna.icarz.com (deanna.icarz.com [207.99.22.19]) by mx1.freebsd.org (Postfix) with ESMTP id 32BC813C468 for ; Wed, 12 Dec 2007 17:46:48 +0000 (UTC) (envelope-from kenfreebsd@icarz.com) Received: from kenxp (netb-138.icarz.com [209.123.219.138]) by deanna.icarz.com (8.13.8/8.13.8) with SMTP id lBCHklTR064330; Wed, 12 Dec 2007 12:46:47 -0500 (EST) (envelope-from kenfreebsd@icarz.com) Message-ID: <13cc01c83ce6$f7483bb0$8adb7bd1@icarz.com> From: "Ken Menzel" To: "Rene Ladan" References: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com><11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com><20071212074208.GD29211@soaustin.net><136c01c83cdf$db5f0430$8adb7bd1@icarz.com> Date: Wed, 12 Dec 2007 12:46:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: -101.972 () ALL_TRUSTED, AWL, BAYES_00, STOX_REPLY_TYPE, USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.63 on 207.99.22.19 Cc: freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ken Menzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 17:46:49 -0000 ----- Original Message ----- From: "Rene Ladan" To: "Ken Menzel" Cc: Sent: Wednesday, December 12, 2007 12:18 PM Subject: Re: CURRENT Kernel makes the system run very very hot > 2007/12/12, Ken Menzel : >> ----- Original Message ----- >> From: "Mark Linimon" >> To: "Sam Fourman Jr." >> Cc: >> Sent: Wednesday, December 12, 2007 2:42 AM >> Subject: Re: CURRENT Kernel makes the system run very very hot >> >> >> > On Wed, Dec 12, 2007 at 01:38:49AM -0600, Sam Fourman Jr. wrote: >> >> I did not file a PR (I don't know how I have never done one.) >> > >> > Please see http://www.freebsd.org/support/bugreports.html. >> > >> > mcl >> Thanks Mark, It seems like it may be an ACPI problem based on: >> >> (kgdb) print cpu_idle_hook >> $1 = (void (*)(void)) 0xffffffff801d0bb0 >> (kgdb) q >> >> Thanks to Kostik Belousov for the advice on where to go next. And >> based on that I will move this to the ACPI mailing list and file a >> PR. >> > Hmm, on my too hot i386 laptop: > > # make installkernel.debug > #gdb /boot/kernel/kernel > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd"... > (gdb) print cpu_idle_hook > $1 = (void (*)(void)) 0xc063cc9b > (gdb) print cpu_idle_default > $2 = {void (void)} 0xc063cc9b > Rene, please try cd /usr/obj/usr/src/sys/GENERIC (or where-ever you built your kernel) kgdb kernel.debug /dev/mem print cpu_idle_hook This should show what is running in memory. > #grep -r cpu_idle_default * > amd64/amd64/machdep.c:cpu_idle_default(void) > amd64/amd64/machdep.c:void (*cpu_idle_hook)(void) = > cpu_idle_default; > dev/acpica/acpi_cpu.c: /* Take over idling from > cpu_idle_default(). */ > i386/i386/machdep.c:cpu_idle_default(void) > i386/i386/machdep.c:void (*cpu_idle_hook)(void) = cpu_idle_default; > ia64/ia64/machdep.c:cpu_idle_default(void) > ia64/ia64/machdep.c:void (*cpu_idle_hook)(void) = cpu_idle_default; > pc98/pc98/machdep.c:cpu_idle_default(void) > pc98/pc98/machdep.c:void (*cpu_idle_hook)(void) = cpu_idle_default; > > #dmesg |grep -i acpi > Features=0xbfebfbff > ACPI APIC Table: > acpi0: <_ASUS_ Notebook> on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of e0000, 20000 (3) failed > acpi0: reservation of 100000, 7ff00000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff > on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > ACPI Warning (tbutils-0243): Incorrect checksum in table [SSDT] - > 99, > should be 2C [20070320] > acpi_asus0: Unsupported Asus laptop: A6Je > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > acpi_video0: on vgapci0 > pcib2: irq 20 at device 28.0 on pci0 > pci2: on pcib2 > pcib3: irq 19 at device 28.3 on pci0 > pci3: on pcib3 > pcib4: at device 30.0 on pci0 > pci4: on pcib4 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_tz0: on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > speaker0: port 0x61 on acpi0 > acpi_asus0: Unsupported Asus laptop: A6Je > > hw.acpi.cpu.cx_lowest: C1 > > So I have an ACPI capable CPU but it is not (properly) loaded? > > Regards, > Rene > -- > GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 > (subkeys.pgp.net) > > "It won't fit on the line." > -- me, 2001 See instruction in text above. Ken From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 18:51:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 068D416A41B for ; Wed, 12 Dec 2007 18:51:39 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 81D1713C467 for ; Wed, 12 Dec 2007 18:51:38 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J2Wfs-000655-EM for freebsd-current@freebsd.org; Wed, 12 Dec 2007 18:51:16 +0000 Received: from 78-1-103-240.adsl.net.t-com.hr ([78.1.103.240]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Dec 2007 18:51:16 +0000 Received: from ivoras by 78-1-103-240.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Dec 2007 18:51:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Wed, 12 Dec 2007 19:50:56 +0100 Lines: 81 Message-ID: References: <20071209234943.GB2112@kobe.laptop> <9bbcef730712091554p63d4ec54sdaf0abcb6e5b1c65@mail.gmail.com> <20071210225421.GA28116@keltia.freenix.fr> <20071211205813.GB1455@kobe.laptop> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAFD02F3760159A8DDB6B7D75" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-103-240.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <20071211205813.GB1455@kobe.laptop> X-Enigmail-Version: 0.95.5 Sender: news Cc: freebsd-doc@freebsd.org Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 18:51:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAFD02F3760159A8DDB6B7D75 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Giorgos Keramidas wrote: > % The suggestion to make it non-fatal sounds nice though. Maybe > % we should consider an `rc.conf' option which controls if mount > % failures are actually considered fatal or just `annoying', and > % then make the failure conditional on that option, i.e.: > % > % mount_failure_level=3D{IGNORE,WARN,FATAL} I like this, but will like to suggest that "WARN" or "IGNORE" be the default, since I think there's practically no chance of backward compatibility issues. > % Adding a mount(8) option, which can be set per filesystem is > % probably also a good idea, i.e. something like: > % > % /dev/acd0 /cdrom cd9660 ro,auto,mounterror=3Dignore 0 0 Perhaps you mean "fsckerror=3Dignore"? IIRC Linux has something like this (the "mounterror" variant), and in some way it's nice to have this fine-grained per-file system, but this particular instance won't save the user from having a machine non-bootable with file systems that don't have fsck (if you already know you need to ignore this type of error, you already know that you need "2" in the fsck field). > % It's too late to introduce something like this to 7.0, but if > % it works and is accepted as an idea, we can implement it on > % HEAD and backport it later :-) >=20 > I still don't see why user-error in fstab for tmpfs should be > treated as a special case, but that's probably me being blinded Making tmpfs a special case for stab would certainly be a bad idea :) I was always suggesting generic solutions. > by a few years of "UNIX can let you shoot your foot, but it's not > the fault of UNIX if you do, in fact, blast it off". I appreciate the charm and the wisdom of the "old-school" way of thinking, but you will recognize that, in additions to many good things, it has brought us some not so good, among which are: - kernel panics on file system corruption (instead of just unmounting the= m) - kernel panics when mounted devices go missing, e.g. USB (instead of just umounting it) - "root is god" model which everyone except the embedded people are trying hard to replace nowadays (ok, this one's hard to solve) - "kern_map too small" panics in ZFS (anything's better than panics; why isn't it delaying requests in low memory conditions?) - ...probably more; this subject pops up every now and then on the lists.= Modern systems should fail gracefully - Unix thrived on small systems with limited resources which maybe couldn't afford this policy, but current systems can do better. --------------enigAFD02F3760159A8DDB6B7D75 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 iD8DBQFHYC2XldnAQVacBcgRAmU1AJ45Y903C+dVxSmcoAttZN5LNVNqIQCdHu/K uU53a8eIp1gAYLFe16WLU4Q= =Ff3G -----END PGP SIGNATURE----- --------------enigAFD02F3760159A8DDB6B7D75-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 19:12:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D8F16A417 for ; Wed, 12 Dec 2007 19:12:43 +0000 (UTC) (envelope-from pneumann@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 9F65D13C43E for ; Wed, 12 Dec 2007 19:12:42 +0000 (UTC) (envelope-from pneumann@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so107239anc.13 for ; Wed, 12 Dec 2007 11:12:42 -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=MCBV5hLieG7TiByxb9KjQ9Lv32kugU8KQ6yMk2xXZNw=; b=cnCjhFL1g+SnYnje5PztOZNuTRH5h8jrFa6juOl9+1OpgJvplQIm6WedS04z4SMscvDiWqBRnfwh10KXfp4MzUIRLxbVyxVwurRt2yT2astfvOIssbyt+MdWmEhjiX0LoA/AM73zMOXD0FzyCvJyhp1NWIkkf3I8SPeyhd1SEIY= 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=H1R1epEj5LrTDc4nBzp2aGkf2TNox6Ht/+RzHCfRIxW3abhwRGSOe2494SCPo/MndtQcLCI3BmOzZs1iFKQPrpCFWaMnEIGrDJwMCjrOsSj1iWQSqJfIK1oGdJD9+I++rgC20KrHg2xPcoJb1cfKPdr4v/28vF1eG9H8rDsIjgg= Received: by 10.100.216.3 with SMTP id o3mr2175380ang.95.1197486762033; Wed, 12 Dec 2007 11:12:42 -0800 (PST) Received: from ?192.168.2.203? ( [190.82.12.211]) by mx.google.com with ESMTPS id v26sm2481317ele.2007.12.12.11.12.39 (version=SSLv3 cipher=RC4-MD5); Wed, 12 Dec 2007 11:12:41 -0800 (PST) From: "Phillip N." To: Andre Oppermann In-Reply-To: <475F1A6E.8080805@freebsd.org> References: <2942A3E0-3E07-4CCB-B292-8DA25884AD3E@nevada.net.nz> <475D6C81.5030308@samsco.org> <475F037F.4000702@freebsd.org> <475F0AF0.50208@samsco.org> <475F1A6E.8080805@freebsd.org> Content-Type: text/plain Date: Wed, 12 Dec 2007 19:12:34 +0000 Message-Id: <1197486754.1296.30.camel@negro> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Philip Murray Subject: Re: Areca weirdness X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 19:12:44 -0000 Is it sharing irq with something else? I had to disable firewire from the kernel to make it boot. bye. -- Phillip N. From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 20:32:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C16016A41B for ; Wed, 12 Dec 2007 20:32:24 +0000 (UTC) (envelope-from r.c.ladan@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 189A013C442 for ; Wed, 12 Dec 2007 20:32:23 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so818213uge.37 for ; Wed, 12 Dec 2007 12:32:20 -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:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=4RBLbYYuupFgrV1602iOP0b5mkvWb39y+ZFSYxNxoAc=; b=YO61bguOtoK96vbYQZ15KqdEhfqUHuPUcxdp3LvYq5z00Bo8EE3tCwidxGWf77IPRcz4FOZ4hL07vKp/PFxuKSQgzdDd0cYMeOGoOoK1IwMFXzTmH695QM5YgipxzuC4uFWKsx5k/N7nyvkBgEZEP1zvxGIX1wnuNjOnEXgEOaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=Fe0TVdshKrLz+RMmFVvxRVc9qcbIa5hvflOqv+gp7pqU9KNynPmiSdPzOUTlSB44EyCcFR4FzS7vNezKbKlGxPb+YwU8Y9DyfLpRcLKABRcvF/grV+qZDDWKCZQkNReiNfCgFd/HqLvaZWcpvBldijYRp4DqKX06GxNt8GCTvb0= Received: by 10.78.162.4 with SMTP id k4mr1374058hue.66.1197491539551; Wed, 12 Dec 2007 12:32:19 -0800 (PST) Received: from ip4da3ae31.direct-adsl.nl.0.163.77.in-addr.arpa ( [77.163.174.49]) by mx.google.com with ESMTPS id h1sm9092363nfh.2007.12.12.12.32.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Dec 2007 12:32:17 -0800 (PST) Message-ID: <4760454F.4070905@gmail.com> Date: Wed, 12 Dec 2007 21:32:15 +0100 From: Rene Ladan User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Ken Menzel References: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com><11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com><20071212074208.GD29211@soaustin.net><136c01c83cdf$db5f0430$8adb7bd1@icarz.com> <13cc01c83ce6$f7483bb0$8adb7bd1@icarz.com> In-Reply-To: <13cc01c83ce6$f7483bb0$8adb7bd1@icarz.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 20:32:24 -0000 Ken Menzel schreef: > ----- Original Message ----- From: "Rene Ladan" > To: "Ken Menzel" > Cc: > Sent: Wednesday, December 12, 2007 12:18 PM > Subject: Re: CURRENT Kernel makes the system run very very hot > > >> 2007/12/12, Ken Menzel : >>> ----- Original Message ----- >>> From: "Mark Linimon" >>> To: "Sam Fourman Jr." >>> Cc: >>> Sent: Wednesday, December 12, 2007 2:42 AM >>> Subject: Re: CURRENT Kernel makes the system run very very hot >>> >>> >>> > On Wed, Dec 12, 2007 at 01:38:49AM -0600, Sam Fourman Jr. wrote: >>> >> I did not file a PR (I don't know how I have never done one.) >>> > >>> > Please see http://www.freebsd.org/support/bugreports.html. >>> > >>> > mcl >>> Thanks Mark, It seems like it may be an ACPI problem based on: >>> >>> (kgdb) print cpu_idle_hook >>> $1 = (void (*)(void)) 0xffffffff801d0bb0 >>> (kgdb) q >>> >>> Thanks to Kostik Belousov for the advice on where to go next. And >>> based on that I will move this to the ACPI mailing list and file a PR. >>> >> Hmm, on my too hot i386 laptop: >> >> # make installkernel.debug >> #gdb /boot/kernel/kernel >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and >> you are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "i386-marcel-freebsd"... >> (gdb) print cpu_idle_hook >> $1 = (void (*)(void)) 0xc063cc9b >> (gdb) print cpu_idle_default >> $2 = {void (void)} 0xc063cc9b >> > > > Rene, please try > > cd /usr/obj/usr/src/sys/GENERIC (or where-ever you built your kernel) > kgdb kernel.debug /dev/mem > print cpu_idle_hook > > This should show what is running in memory. > But it doens't :( (at least not human-readable). ----- root@ip4da3ae31:/usr/obj/usr/src/sys/RENE#kgdb kernel.debug /dev/mem [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Ready to go. Enter 'tr' to connect to the remote target with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port or 'trf portno' to connect to the remote target with the firewire interface. portno defaults to 5556. Type 'getsyms' after connection to load kld symbols. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. During symbol reading...location expression too complex... During symbol reading, unsupported tag: 'DW_TAG_const_type'. #0 0x00000000 in ?? () (kgdb) print cpu_idle_hook $1 = (void (*)(void)) 0xc080b6fd (kgdb) print *0xc080b6fd $2 = 0x57e58955 (kgdb) print *0x57e58955 Error accessing memory address 0x57e58955: Bad address. (kgdb) q ----- The result is the same after all daily modules are loaded (my kernel is quite minimal). I manually booted /boot/kernel.debug/kernel.debug which I manually copied from the build directory. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 20:12:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F4B416A419 for ; Wed, 12 Dec 2007 20:12:47 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 771D813C459 for ; Wed, 12 Dec 2007 20:12:47 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: (qmail 28980 invoked from network); 12 Dec 2007 20:12:46 -0000 Received: from april.chuckr.org (chuckr@[66.92.151.30]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 12 Dec 2007 20:12:46 -0000 Message-ID: <47604019.1010408@chuckr.org> Date: Wed, 12 Dec 2007 15:10:01 -0500 From: Chuck Robey User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.9) Gecko/20071107 SeaMonkey/1.1.6 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 12 Dec 2007 20:48:10 +0000 Subject: regarding that odd problem with scp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 20:12:47 -0000 I found out what it was .... Just to remind, when I tried to use scp, I got an error message complaining about the PermitLocalCommand variable not being recognized, so that I could transfer nothing via scp. Well, it's an artifact of doing a buildworld & installworld, but not doing a new kernel, and not even doing a reboot. Once I did a new kernel and rebooted, the problem disappeared. Glad about that, because the way that the problem presented, well, it was more than a little unusual, and responded to none of the normal things you do to troubleshoot ssh problems. So, this problem (at least) is taken care of. Back to my audio driver distractions. From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 21:03:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E123D16A419 for ; Wed, 12 Dec 2007 21:03:39 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 652B513C455 for ; Wed, 12 Dec 2007 21:03:39 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so644587waf.3 for ; Wed, 12 Dec 2007 13:03:37 -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=A+++eRv8vz16fo7eUfqaRuCOFPwJkDvD3wCTsWTisjI=; b=Yo/ATQd24oepp9DkzncxioIhtDAsPt1grcVrMxiwwcqEWqmG1Zv+bmZxj+0RfMg9Nvqc5Cfg7S4DYx9oQhnTvpGlDPQSWSdXa5b51Z/YVK1fnUw6obZYfW1myNfk2cPLpoRe7nsxPhT7tgp4uwLLYrXCDRIUBZOBMelDM3q1Npw= 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=naBVt7a8aKYHEYrKSTs2Luy9XktkCZ2jamgxGHW1+Nt0CMrtUNZmfDrYRPJI73k6sLCXgtCpc0w1um3Q32qujkdAonM2mQx6ZDViu8Jydv1DupsT8AoeCN8BLphCSraGZj/ww94ojN9aoVP8Ww/KCBVS+flD8dS2SIDaaHdB+Ro= Received: by 10.114.135.1 with SMTP id i1mr1288674wad.88.1197493416451; Wed, 12 Dec 2007 13:03:36 -0800 (PST) Received: by 10.114.255.11 with HTTP; Wed, 12 Dec 2007 13:03:36 -0800 (PST) Message-ID: Date: Wed, 12 Dec 2007 13:03:36 -0800 From: "Kip Macy" To: "Robert Watson" , "Sam Leffler" , freebsd-arch@freebsd.org, "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 21:03:40 -0000 After review by Mike Silbersack I've committed the hooks that provide a driver independent interface to TCP offload. I would like to commit the changes to tcp_subr.c and tcp_usrreq.c to actually make use of the new interface. Please review the following: http://www.fsmware.com/freebsd/tcp/tcp_subr.c.diff http://www.fsmware.com/freebsd/tcp/tcp_usrreq.c.diff The new KPI is provided by the following 2 files: http://www.fsmware.com/freebsd/tcp/tcp_ofld.c http://www.fsmware.com/freebsd/tcp/tcp_ofld.h Thank you for taking the time to review and provide feedback. -Kip From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 22:23:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86CBC16A421 for ; Wed, 12 Dec 2007 22:23:34 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id 4492013C447 for ; Wed, 12 Dec 2007 22:23:34 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so131234anc.13 for ; Wed, 12 Dec 2007 14:23:33 -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:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=FG1PcRSsLh1EaZSs0tbwRShGxU/HETXgkzJQ+i8VFV0=; b=sJXQuGZ9rJeqYMFf5hUfAYa7f0N/bQSZGR/eVyZuhnFzVyD5sg/AHoLPmSZ36sZ1D4zVENcUG9H67OIXbRCO2M+UZ3G/VxupqXHpU9bhf18ebDIKqDK+H28cIopFsTujOquOMTmEyA8+ftsvQ2M1JvbpxjxvP+3Oq5vzAVALKWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=fU24hPSTKdBQxETAxLWMRin2NJdNFsoDEcF+oQMcX6xntKXbfiVV24X1WI7tb1xUCp6XsfcfvWcloOq+H7uTkGf1Q4ob2XQ2IfN2+GF1sp8Eg/SAt0evfqad5NBdrg7jGLK9uZ/+TdoK9CQO7lgiulOnc9WrmQwVOYo07tusIn8= Received: by 10.100.215.5 with SMTP id n5mr2568479ang.3.1197496642141; Wed, 12 Dec 2007 13:57:22 -0800 (PST) Received: from ?192.168.12.8? ( [97.101.40.241]) by mx.google.com with ESMTPS id q26sm3493082ele.2007.12.12.13.57.20 (version=SSLv3 cipher=RC4-MD5); Wed, 12 Dec 2007 13:57:21 -0800 (PST) Message-ID: <4760593D.7070203@gmail.com> Date: Wed, 12 Dec 2007 16:57:17 -0500 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Igor Soumenkov <2igosha@gmail.com> References: <472A6708.9030109@clearchain.com> <20071102004248.GA5253@e.0x20.net> <200711020152.53535.max@love2party.net> <472A7ADD.3010002@clearchain.com> <20071104102803.GD5253@e.0x20.net> <20071104105147.GE5253@e.0x20.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 22:23:34 -0000 Igor Soumenkov wrote: > But - strange enough - it changes the connection speed frequently > while being 2 meters away from the access point (which is 802.11g). > Right now it is 36 Mbps only. The signal might be too strong. Have seen poor performance and poor TX rate selection under such conditions with other cards. Try sitting between the computer and the AP and investigate power readings. Just my $0.2 -- Sten Daniel Soersdal From owner-freebsd-current@FreeBSD.ORG Wed Dec 12 23:17:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3F4F16A41B for ; Wed, 12 Dec 2007 23:17:29 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c]) by mx1.freebsd.org (Postfix) with ESMTP id D934813C468 for ; Wed, 12 Dec 2007 23:17:29 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id A9F5111401E for ; Wed, 12 Dec 2007 23:17:28 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Received: from manx.isc.org (manx.isc.org [IPv6:2001:4f8:3:bb::37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by farside.isc.org (Postfix) with ESMTP id 5FFE9E6056 for ; Wed, 12 Dec 2007 23:17:29 +0000 (UTC) (envelope-from Peter_Losher@isc.org) Message-ID: <47606C09.2070209@isc.org> Date: Wed, 12 Dec 2007 15:17:29 -0800 From: Peter Losher Organization: ISC User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAB71B231D3E7261D9266AEBE" Subject: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2007 23:17:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAB71B231D3E7261D9266AEBE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, As part of our testing 7.0/ZFS we tried putting it thru it's paces having ZFS act as our storage medium for some test pgsql db's (like for sqlgrey, etc) and in both BETA2 and BETA4 (amd64) we get the same results with a RAIDZ2 container: -=3D- Dec 12 14:24:12 nsa sqlgrey: fatal: setconfig error at /usr/local/sbin/sqlgrey line 186. Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad4 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad6 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad8 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad10 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad12 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad14 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad16 offset=3D3665128448 size=3D21504 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad18 offset=3D3665128448 size=3D21504 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad4 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad6 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad8 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad10 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad12 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad14 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad16 offset=3D3665128448 size=3D21504 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad18 offset=3D3665128448 size=3D21504 Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=3Dvault error=3D8= 6 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad4 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad6 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad8 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad10 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad12 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad14 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad16 offset=3D3665128448 size=3D21504 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad18 offset=3D3665128448 size=3D21504 Dec 12 16:49:53 nsa postgres[50527]: [5-1] PANIC: could not write to log file 2, segment 53 at offset 7864320, length 8192: Input/output error= Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad4 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad6 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad8 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad10 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad12 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad14 offset=3D3665128448 size=3D22016 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad16 offset=3D3665128448 size=3D21504 Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=3Dvault path=3D/dev/ad18 offset=3D3665128448 size=3D21504 Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=3Dvault error=3D8= 6 Dec 12 16:49:53 nsa postgres[50596]: [1-1] FATAL: the database system is starting up Dec 12 16:49:53 nsa kernel: pid 50527 (postgres), uid 70: exited on signal 6 (core dumped) -=3D- It basically corrupts the container from the inside until it fails completely (usually withing 24-48 hours depending on how busy the db is) I had thought it was a bad SATA replicator/controller, but we had that replaced w/ one from Supermicro. So it's either the disks, or something in ZFS. Anyone used ZFS to backend any db's (mysql or pgsql?) If you need more info, let me know... --=20 Peter_Losher@isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow" --------------enigAB71B231D3E7261D9266AEBE 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.7 (Darwin) iD8DBQFHYGwJPtVx9OgEjQgRAsPuAKCUOz2/Jj9V/+mnK6sdTatoFb9nSwCgsJws PbXTr1C+vOsKWqfdfYZpe9Q= =H4Ak -----END PGP SIGNATURE----- --------------enigAB71B231D3E7261D9266AEBE-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 00:16:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 330AE16A418 for ; Thu, 13 Dec 2007 00:16:10 +0000 (UTC) (envelope-from skafte@trollkarl.net) Received: from worlock.trollkarl.net (018.216-123-203-0.interbaun.com [216.123.203.18]) by mx1.freebsd.org (Postfix) with ESMTP id CF35E13C467 for ; Thu, 13 Dec 2007 00:16:09 +0000 (UTC) (envelope-from skafte@trollkarl.net) Received: from trollkarl.trollkarl.net (trollkarl [192.168.100.16]) by worlock.trollkarl.net (8.14.2/8.14.2) with ESMTP id lBCNah8v088231; Wed, 12 Dec 2007 16:36:45 -0700 (MST) (envelope-from skafte@trollkarl.net) Received: from trollkarl.trollkarl.net (localhost.trollkarl.net [127.0.0.1]) by trollkarl.trollkarl.net (8.14.2/8.14.2) with ESMTP id lBCNahZm001798; Wed, 12 Dec 2007 16:36:43 -0700 (MST) (envelope-from skafte@trollkarl.trollkarl.net) Received: (from skafte@localhost) by trollkarl.trollkarl.net (8.14.2/8.14.2/Submit) id lBCNagKx001797; Wed, 12 Dec 2007 16:36:42 -0700 (MST) (envelope-from skafte) Date: Wed, 12 Dec 2007 16:36:42 -0700 From: Greg Skafte To: Thierry Herbelot Message-ID: <20071212233642.GF1267@trollkarl.trollkarl.net> References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> <200712120002.08386.thierry@herbelot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712120002.08386.thierry@herbelot.com> User-Agent: Mutt/1.4.2.3i Organization: Greg's Hidey Hole Errors-To: skafte@trollkarl.net X-Spam-Status: No, score=-10.0 required=5.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on worlock.trollkarl.net Cc: freebsd-current@freebsd.org Subject: Re: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 00:16:10 -0000 I'm using a Radeon 9500 agp card with little issue, I'm using the radeon driver not the ati driver, and a DVI connector not the Analog VGA connector. Using the Analog VGA connection prevented me from using 1680x1050 mode.... Dec 12 14:42:50 trollkarl kernel: drm0: on vgapci0 Dec 12 14:42:50 trollkarl kernel: info: [drm] AGP at 0xf8000000 64MB Dec 12 14:42:50 trollkarl kernel: info: [drm] Initialized radeon 1.25.0 20060524 Dec 12 14:42:53 trollkarl kernel: info: [drm] Setting GART location based on new memory map Dec 12 14:42:53 trollkarl kernel: info: [drm] Loading R300 Microcode Dec 12 14:42:53 trollkarl kernel: info: [drm] writeback test succeeded in 1 usecs Dec 12 14:42:53 trollkarl kernel: drm0: [ITHREAD] Quoting Thierry Herbelot (thierry@herbelot.com) On Subject: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) Date: Wed, Dec 12, 2007 at 12:02:06AM +0100 > > I don't know the status of ATI at the moment - if you want 3D support > > on FreeBSD right *now* I think nvidia/i386 is your only option. > > > > -Kip > > Hello, > > with less ambitious goals : what graphic card can I use these days to drive my > 1680x1050 LCD under X11 ? (I used to use my oldish radeon, with an ATI9200, > but the radeon support in xorg 7.3 seems to have been broken for around 3 > months and VESA does not drive 1680x1050) does the xorg nv driver support > 1680x1050 ? > > TfH > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Email: skafte@trollkarl.net Contact me for ICQ,MSN,AIM,Yahoo,Jabber -- -- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 00:37:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A324016A50D for ; Thu, 13 Dec 2007 00:37:48 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from omta04ps.mx.bigpond.com (omta04ps.mx.bigpond.com [144.140.83.156]) by mx1.freebsd.org (Postfix) with ESMTP id 4672813C468 for ; Thu, 13 Dec 2007 00:37:47 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from oaamta01ps.mx.bigpond.com ([124.188.162.219]) by omta04ps.mx.bigpond.com with ESMTP id <20071213003746.ZVLG18971.omta04ps.mx.bigpond.com@oaamta01ps.mx.bigpond.com> for ; Thu, 13 Dec 2007 00:37:46 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by oaamta01ps.mx.bigpond.com with ESMTP id <20071213003746.OHWF9264.oaamta01ps.mx.bigpond.com@areilly.bpa.nu> for ; Thu, 13 Dec 2007 00:37:46 +0000 Received: (qmail 19755 invoked by uid 501); 13 Dec 2007 00:37:42 -0000 Date: Thu, 13 Dec 2007 11:37:42 +1100 From: Andrew Reilly To: Rod Person Message-ID: <20071213003742.GB15059@duncan.reilly.home> References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> <200712120002.08386.thierry@herbelot.com> <20071211195643.7faaac28@atomizer.opensourcebeef.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071211195643.7faaac28@atomizer.opensourcebeef.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, thierry@herbelot.com Subject: Re: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 00:37:48 -0000 On Tue, Dec 11, 2007 at 07:56:43PM -0500, Rod Person wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 12 Dec 2007 00:02:06 +0100 > Thierry Herbelot wrote: > > > > with less ambitious goals : what graphic card can I use these days to > > drive my 1680x1050 LCD under X11 ? (I used to use my oldish radeon, > > with an ATI9200, but the radeon support in xorg 7.3 seems to have > > been broken for around 3 months and VESA does not drive 1680x1050) > > does the xorg nv driver support 1680x1050 ? > > > > I have a nvidia 7800gtx running at this resolution. I would think most > of the newer cards will handle it. The nv driver in the 7.x series xorg > are able do this resolution. I have a 6600GE or something like that (low-ish end fanless card) and I can't get the nv driver to go above 1280x1024, even though my LCD screen's native resolution is 1600x1200. It says something (in the logs) about being prevented by bios, which seems odd. Did you have to put anything fancy in your xorg.conf file to enable the higher resolution? Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 01:02:09 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D37316A419; Thu, 13 Dec 2007 01:02:09 +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 D818013C468; Thu, 13 Dec 2007 01:02:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lBD127OD055548; Wed, 12 Dec 2007 20:02:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id lBD127c0072812; Wed, 12 Dec 2007 20:02:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AF8BF73039; Wed, 12 Dec 2007 20:02:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071213010207.AF8BF73039@freebsd-current.sentex.ca> Date: Wed, 12 Dec 2007 20:02:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 01:02:09 -0000 TB --- 2007-12-12 23:54:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-12-12 23:54:50 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-12-12 23:54:50 - cleaning the object tree TB --- 2007-12-12 23:55:19 - cvsupping the source tree TB --- 2007-12-12 23:55:19 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2007-12-12 23:55:27 - building world (CFLAGS=-O -pipe) TB --- 2007-12-12 23:55:27 - cd /src TB --- 2007-12-12 23:55:27 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 12 23:55:28 UTC 2007 >>> 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 Thu Dec 13 00:56:34 UTC 2007 TB --- 2007-12-13 00:56:34 - generating LINT kernel config TB --- 2007-12-13 00:56:34 - cd /src/sys/powerpc/conf TB --- 2007-12-13 00:56:34 - /usr/bin/make -B LINT TB --- 2007-12-13 00:56:34 - building LINT kernel (COPTFLAGS=) TB --- 2007-12-13 00:56:34 - cd /src TB --- 2007-12-13 00:56:34 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 13 00:56:34 UTC 2007 >>> 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 -c -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -Werror /src/sys/netinet/tcp_ofld.c In file included from /src/sys/netinet/tcp_ofld.c:50: /src/sys/netinet/tcp_ofld.h: In function 'tcp_gen_connect': /src/sys/netinet/tcp_ofld.h:61: error: 'SO_NOOFFLOAD' undeclared (first use in this function) /src/sys/netinet/tcp_ofld.h:61: error: (Each undeclared identifier is reported only once /src/sys/netinet/tcp_ofld.h:61: error: for each function it appears in.) /src/sys/netinet/tcp_ofld.h: In function 'tcp_gen_listen_open': /src/sys/netinet/tcp_ofld.h:118: error: 'SO_NOOFFLOAD' undeclared (first use in this function) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-12-13 01:02:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-12-13 01:02:07 - ERROR: failed to build lint kernel TB --- 2007-12-13 01:02:07 - tinderbox aborted TB --- 3047.70 user 356.22 system 4037.27 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 01:48:48 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 415CE16A420; Thu, 13 Dec 2007 01:48:48 +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 0AC8713C448; Thu, 13 Dec 2007 01:48:47 +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.1/8.13.8) with ESMTP id lBD1ml7M011154; Wed, 12 Dec 2007 20:48:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id lBD1mkxV028773; Wed, 12 Dec 2007 20:48:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E17C473039; Wed, 12 Dec 2007 20:48:46 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071213014846.E17C473039@freebsd-current.sentex.ca> Date: Wed, 12 Dec 2007 20:48:46 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 01:48:48 -0000 TB --- 2007-12-13 00:44:17 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-12-13 00:44:17 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2007-12-13 00:44:17 - cleaning the object tree TB --- 2007-12-13 00:44:45 - cvsupping the source tree TB --- 2007-12-13 00:44:45 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2007-12-13 00:44:53 - building world (CFLAGS=-O -pipe) TB --- 2007-12-13 00:44:53 - cd /src TB --- 2007-12-13 00:44:53 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 13 00:44:54 UTC 2007 >>> 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 Thu Dec 13 01:42:12 UTC 2007 TB --- 2007-12-13 01:42:12 - generating LINT kernel config TB --- 2007-12-13 01:42:12 - cd /src/sys/sparc64/conf TB --- 2007-12-13 01:42:12 - /usr/bin/make -B LINT TB --- 2007-12-13 01:42:12 - building LINT kernel (COPTFLAGS=) TB --- 2007-12-13 01:42:12 - cd /src TB --- 2007-12-13 01:42:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 13 01:42:12 UTC 2007 >>> 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 -c -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netinet/tcp_ofld.c In file included from /src/sys/netinet/tcp_ofld.c:50: /src/sys/netinet/tcp_ofld.h: In function 'tcp_gen_connect': /src/sys/netinet/tcp_ofld.h:61: error: 'SO_NOOFFLOAD' undeclared (first use in this function) /src/sys/netinet/tcp_ofld.h:61: error: (Each undeclared identifier is reported only once /src/sys/netinet/tcp_ofld.h:61: error: for each function it appears in.) /src/sys/netinet/tcp_ofld.h: In function 'tcp_gen_listen_open': /src/sys/netinet/tcp_ofld.h:118: error: 'SO_NOOFFLOAD' undeclared (first use in this function) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-12-13 01:48:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-12-13 01:48:46 - ERROR: failed to build lint kernel TB --- 2007-12-13 01:48:46 - tinderbox aborted TB --- 2873.26 user 354.76 system 3869.70 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 02:03:08 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 338F116A41B; Thu, 13 Dec 2007 02:03:08 +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 EFEDF13C447; Thu, 13 Dec 2007 02:03:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lBD2379n059024; Wed, 12 Dec 2007 21:03:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id lBD237uF044880; Wed, 12 Dec 2007 21:03:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id ECCF573039; Wed, 12 Dec 2007 21:03:06 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071213020306.ECCF573039@freebsd-current.sentex.ca> Date: Wed, 12 Dec 2007 21:03:06 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 02:03:08 -0000 TB --- 2007-12-13 01:02:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-12-13 01:02:07 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2007-12-13 01:02:07 - cleaning the object tree TB --- 2007-12-13 01:02:27 - cvsupping the source tree TB --- 2007-12-13 01:02:27 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2007-12-13 01:02:35 - building world (CFLAGS=-O -pipe) TB --- 2007-12-13 01:02:35 - cd /src TB --- 2007-12-13 01:02:35 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 13 01:02:37 UTC 2007 >>> 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 Thu Dec 13 01:58:11 UTC 2007 TB --- 2007-12-13 01:58:11 - generating LINT kernel config TB --- 2007-12-13 01:58:11 - cd /src/sys/sun4v/conf TB --- 2007-12-13 01:58:11 - /usr/bin/make -B LINT TB --- 2007-12-13 01:58:11 - building LINT kernel (COPTFLAGS=) TB --- 2007-12-13 01:58:11 - cd /src TB --- 2007-12-13 01:58:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 13 01:58:12 UTC 2007 >>> 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 -c -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/netinet/tcp_ofld.c In file included from /src/sys/netinet/tcp_ofld.c:50: /src/sys/netinet/tcp_ofld.h: In function 'tcp_gen_connect': /src/sys/netinet/tcp_ofld.h:61: error: 'SO_NOOFFLOAD' undeclared (first use in this function) /src/sys/netinet/tcp_ofld.h:61: error: (Each undeclared identifier is reported only once /src/sys/netinet/tcp_ofld.h:61: error: for each function it appears in.) /src/sys/netinet/tcp_ofld.h: In function 'tcp_gen_listen_open': /src/sys/netinet/tcp_ofld.h:118: error: 'SO_NOOFFLOAD' undeclared (first use in this function) *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-12-13 02:03:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-12-13 02:03:06 - ERROR: failed to build lint kernel TB --- 2007-12-13 02:03:06 - tinderbox aborted TB --- 2865.47 user 351.95 system 3659.14 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 02:04:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DA7E16A41A for ; Thu, 13 Dec 2007 02:04:40 +0000 (UTC) (envelope-from rodperson@verizon.net) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5BB5013C4CC for ; Thu, 13 Dec 2007 02:04:40 +0000 (UTC) (envelope-from rodperson@verizon.net) Received: from atomizer.opensourcebeef.net ([72.95.167.167]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JSY000NPQVVF0EA@vms173003.mailsrvcs.net> for freebsd-current@freebsd.org; Wed, 12 Dec 2007 19:02:20 -0600 (CST) Date: Wed, 12 Dec 2007 19:56:35 -0500 From: Rod Person In-reply-to: <20071213003742.GB15059@duncan.reilly.home> To: Andrew Reilly Message-id: <20071212195635.71d754aa@atomizer.opensourcebeef.net> Organization: Open Source Beef MIME-version: 1.0 X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: base64 References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> <200712120002.08386.thierry@herbelot.com> <20071211195643.7faaac28@atomizer.opensourcebeef.net> <20071213003742.GB15059@duncan.reilly.home> Cc: freebsd-current@freebsd.org, thierry@herbelot.com Subject: Re: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 02:04:40 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBUaHUs IDEzIERlYyAyMDA3IDExOjM3OjQyICsxMTAwDQpBbmRyZXcgUmVpbGx5IDxhbmRyZXctZnJlZWJz ZEBhcmVpbGx5LmJwYy11c2Vycy5vcmc+IHdyb3RlOg0KPiANCj4gSSBoYXZlIGEgNjYwMEdFIG9y IHNvbWV0aGluZyBsaWtlIHRoYXQgKGxvdy1pc2ggZW5kIGZhbmxlc3MNCj4gY2FyZCkgYW5kIEkg Y2FuJ3QgZ2V0IHRoZSBudiBkcml2ZXIgdG8gZ28gYWJvdmUgMTI4MHgxMDI0LCBldmVuDQo+IHRo b3VnaCBteSBMQ0Qgc2NyZWVuJ3MgbmF0aXZlIHJlc29sdXRpb24gaXMgMTYwMHgxMjAwLiAgSXQg c2F5cw0KPiBzb21ldGhpbmcgKGluIHRoZSBsb2dzKSBhYm91dCBiZWluZyBwcmV2ZW50ZWQgYnkg Ymlvcywgd2hpY2gNCj4gc2VlbXMgb2RkLiAgRGlkIHlvdSBoYXZlIHRvIHB1dCBhbnl0aGluZyBm YW5jeSBpbiB5b3VyIHhvcmcuY29uZg0KPiBmaWxlIHRvIGVuYWJsZSB0aGUgaGlnaGVyIHJlc29s dXRpb24/DQoNCk5vIEkgZG9uJ3QgYmVsaWV2ZSBJIHB1dCBhbnl0aGluZyBmYW5jeSBpbnRvIGl0 LiBJIGhhZCB0aGF0IHByb2JsZW0NCndpdGggdGhlIHhvcmcgNiBzZXJpZXMgYW5kIEkgYmVsaWV2 ZSB3aXRoIHhvcmcgNy4wLCBidXQgNy4xIEkga25vdw0Kd29ya2VkIGZvciBtZS4gSSBjYW4gbG9v ayBhbmQgc2VlIGlmIEkgc3RpbGwgaGF2ZSBhIGNvcHkgb2YgbXkNCnhvcmcuY29uZiBmaWxlIEkg dXNlZCB3aXRoIHRoZSBudiBkcml2ZXIgaWYgdGhhdCB3b3VsZCBiZSBoZWxwZnVsIHRvDQp5b3Uu DQoNCg0KLSAtLSANClJvZA0KDQpodHRwOi8vcm9kZGllcm9kLmhvbWV1bml4Lm5ldDo4MDgwDQot LS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lvbjogR251UEcgdjEuNC43IChGcmVl QlNEKQ0KDQppRDhEQlFGSFlJTkRjWkFJYUdTdGNuQVJBb3BMQUo0MHhYTzZ0dXVXNDhJOGFyb0lD UlJHcWgwODV3Q2ZmTS9jDQpmMnlPTnZlc0FRT0VmQVdYMVFNdnJaMD0NCj03eXpwDQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg== From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 02:47:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FE2716A4FF for ; Thu, 13 Dec 2007 02:47:30 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 22B6A13C4D3 for ; Thu, 13 Dec 2007 02:47:30 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so809254waf.3 for ; Wed, 12 Dec 2007 18:47: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=IZWraeaO3BCMuayCLq4k2sgyuh2COX80eghqyq1j5fk=; b=pawAHoKYjghdXs5WlP64n4X1zMj/PkTJOgxkWF2FilHeuBdrwVWgMbsX2GnuAPEB1afrZXjDkSF2H9xjQdcNcOqoBmZerF40NrbpJrDAacA1jdCLa6WN5HkuedQvOH0b+ZF1G7rpTiPZIhpMHQnDwNIUB3fO10JhjmbyIAyhbOg= 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=S8QXFCH6Prd7ixrRtO61VO2i2hAjkE4Ve8S4sEx6ARbws6vecL6zfkQ9N1XZrUx4eFFLaUKVH73vZSRppNzvdkYLa4AxTGThWJ3ABzq5dZoO3N+bMu0DXQoqGl+zFa9NKGcyeUE1qnljogs7ijNLBUL+e3wlSPCgSoMUeHQqMdc= Received: by 10.115.55.1 with SMTP id h1mr1633832wak.69.1197514049340; Wed, 12 Dec 2007 18:47:29 -0800 (PST) Received: by 10.114.255.11 with HTTP; Wed, 12 Dec 2007 18:47:29 -0800 (PST) Message-ID: Date: Wed, 12 Dec 2007 18:47:29 -0800 From: "Kip Macy" To: "Mark Kirkwood" In-Reply-To: <47609B9F.7020601@paradise.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> <200712120002.08386.thierry@herbelot.com> <47609B9F.7020601@paradise.net.nz> Cc: freebsd-current@freebsd.org, thierry@herbelot.com Subject: Re: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 02:47:30 -0000 On Dec 12, 2007 6:40 PM, Mark Kirkwood wrote: > Thierry Herbelot wrote: > > > > with less ambitious goals : what graphic card can I use these days to drive my > > 1680x1050 LCD under X11 ? (I used to use my oldish radeon, with an ATI9200, > > but the radeon support in xorg 7.3 seems to have been broken for around 3 > > months and VESA does not drive 1680x1050) does the xorg nv driver support > > 1680x1050 ? > > > > > I'm using a radeon 9600 Pro driving a display at 1680x1050. I was using > a 9500 before that - both seem to work fine with Xorg 7.3. I've also > experimented with a 9800 Pro - which also works fine (but generates too > much heat, requiring active cooling whereas the 9600 does not). > > My experience has been that certainly older ATI cards are fine. On the topic of newer cards: I have a FireGL V3600 - it works just fine with radeonhd at 1920x1200 (single-link) on amd64, radeonhd doesn't have support for dual-link so I can't use it at 2580x1600. The atombios-support branch of the ati driver has dual link support and works for some people, but crashes for me in the atombios parser. -Kip From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 02:52:11 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 226C416A41A for ; Thu, 13 Dec 2007 02:52:11 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by mx1.freebsd.org (Postfix) with ESMTP id 73B9413C45A for ; Thu, 13 Dec 2007 02:52:10 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAE4qYEd5LSgsWmdsb2JhbACBWo4JASCBOw X-IronPort-AV: E=Sophos;i="4.24,159,1196602200"; d="scan'208";a="16344416" Received: from ppp121-45-40-44.lns10.adl2.internode.on.net (HELO mail.clearchain.com) ([121.45.40.44]) by ipmail05.adl2.internode.on.net with ESMTP; 13 Dec 2007 13:22:07 +1030 Received: from benjamin-closes-powerbook-g4-12.local (wcl.ml.unisa.edu.au [130.220.166.5]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id lBD2pq1q068216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 13:22:04 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <47609F0A.7010805@clearchain.com> Date: Thu, 13 Dec 2007 13:25:06 +1030 From: Benjamin Close User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Peter Losher References: <47606C09.2070209@isc.org> In-Reply-To: <47606C09.2070209@isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Thu, 13 Dec 2007 13:22:05 +1030 (CST) Cc: FreeBSD Current Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 02:52:11 -0000 Peter Losher wrote: > Hi, > > As part of our testing 7.0/ZFS we tried putting it thru it's paces > having ZFS act as our storage medium for some test pgsql db's (like for > sqlgrey, etc) and in both BETA2 and BETA4 (amd64) we get the same > results with a RAIDZ2 container: > > -=- > Dec 12 14:24:12 nsa sqlgrey: fatal: setconfig error at > /usr/local/sbin/sqlgrey line 186. > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad4 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad6 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad8 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad10 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad12 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad14 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad16 offset=3665128448 size=21504 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad18 offset=3665128448 size=21504 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad4 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad6 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad8 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad10 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad12 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad14 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad16 offset=3665128448 size=21504 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad18 offset=3665128448 size=21504 > Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault error=86 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad4 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad6 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad8 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad10 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad12 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad14 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad16 offset=3665128448 size=21504 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad18 offset=3665128448 size=21504 > Dec 12 16:49:53 nsa postgres[50527]: [5-1] PANIC: could not write to > log file 2, segment 53 at offset 7864320, length 8192: Input/output error > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad4 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad6 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad8 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad10 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad12 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad14 offset=3665128448 size=22016 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad16 offset=3665128448 size=21504 > Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > path=/dev/ad18 offset=3665128448 size=21504 > Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault error=86 > Dec 12 16:49:53 nsa postgres[50596]: [1-1] FATAL: the database system > is starting up > Dec 12 16:49:53 nsa kernel: pid 50527 (postgres), uid 70: exited on > signal 6 (core dumped) > -=- > > It basically corrupts the container from the inside until it fails > completely (usually withing 24-48 hours depending on how busy the db is) > > I had thought it was a bad SATA replicator/controller, but we had that > replaced w/ one from Supermicro. So it's either the disks, or something > in ZFS. Anyone used ZFS to backend any db's (mysql or pgsql?) > > If you need more info, let me know... > > Try turning of zil, whilst I don't use a db, I have zfs under high load. I've found without zil turned off I see checksum corruption as well: /boot/loader.conf vfs.zfs.zil_disable=1 Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 02:53:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2107516A504; Thu, 13 Dec 2007 02:53:17 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1F513C448; Thu, 13 Dec 2007 02:53:15 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HANItYEd5LSgsWmdsb2JhbACBWo4JASA X-IronPort-AV: E=Sophos;i="4.24,160,1196602200"; d="scan'208";a="16344959" Received: from ppp121-45-40-44.lns10.adl2.internode.on.net (HELO mail.clearchain.com) ([121.45.40.44]) by ipmail05.adl2.internode.on.net with ESMTP; 13 Dec 2007 13:23:08 +1030 Received: from benjamin-closes-powerbook-g4-12.local (wcl.ml.unisa.edu.au [130.220.166.5]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id lBD2r03p068234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 13:23:08 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <47609F4F.2000109@clearchain.com> Date: Thu, 13 Dec 2007 13:26:15 +1030 From: Benjamin Close User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Sten Daniel Soersdal References: <472A6708.9030109@clearchain.com> <20071102004248.GA5253@e.0x20.net> <200711020152.53535.max@love2party.net> <472A7ADD.3010002@clearchain.com> <20071104102803.GD5253@e.0x20.net> <20071104105147.GE5253@e.0x20.net> <4760593D.7070203@gmail.com> In-Reply-To: <4760593D.7070203@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Thu, 13 Dec 2007 13:23:08 +1030 (CST) Cc: Igor Soumenkov <2igosha@gmail.com>, freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org, freebsd-current@freebsd.org Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 02:53:17 -0000 Sten Daniel Soersdal wrote: > Igor Soumenkov wrote: >> But - strange enough - it changes the connection speed frequently >> while being 2 meters away from the access point (which is 802.11g). >> Right now it is 36 Mbps only. > > The signal might be too strong. Have seen poor performance and poor TX > rate selection under such conditions with other cards. Try sitting > between the computer and the AP and investigate power readings. > Just my $0.2 > Kevin Lo has provided a patch which should fix this issue. I'll apply it shortly. Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 02:55:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F138B16A419 for ; Thu, 13 Dec 2007 02:55:37 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id CE37913C4EC for ; Thu, 13 Dec 2007 02:55:37 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from zmori.markir.net (121-72-71-54.dsl.telstraclear.net [121.72.71.54]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0JSY000PEVFLQN30@smtp3.clear.net.nz> for freebsd-current@freebsd.org; Thu, 13 Dec 2007 15:40:35 +1300 (NZDT) Date: Thu, 13 Dec 2007 15:40:31 +1300 From: Mark Kirkwood In-reply-to: <200712120002.08386.thierry@herbelot.com> To: thierry@herbelot.com Message-id: <47609B9F.7020601@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <11167f520712082309s20895ae0se1780b029745c055@mail.gmail.com> <11167f520712111105l7a897d60w36de6c8ad7cb7b1d@mail.gmail.com> <200712120002.08386.thierry@herbelot.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071203) Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: 1680x1050 support under FreeBSD (was Re: amd64 NVIDIA support in FreeBSD 7) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 02:55:38 -0000 Thierry Herbelot wrote: > > with less ambitious goals : what graphic card can I use these days to drive my > 1680x1050 LCD under X11 ? (I used to use my oldish radeon, with an ATI9200, > but the radeon support in xorg 7.3 seems to have been broken for around 3 > months and VESA does not drive 1680x1050) does the xorg nv driver support > 1680x1050 ? > I'm using a radeon 9600 Pro driving a display at 1680x1050. I was using a 9500 before that - both seem to work fine with Xorg 7.3. I've also experimented with a 9800 Pro - which also works fine (but generates too much heat, requiring active cooling whereas the 9600 does not). My experience has been that certainly older ATI cards are fine. Cheers Mark From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 02:58:29 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43D3C16A41A for ; Thu, 13 Dec 2007 02:58:29 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.19.101.164]) by mx1.freebsd.org (Postfix) with ESMTP id 31FD313C4D1 for ; Thu, 13 Dec 2007 02:58:28 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from localhost (localhost [127.0.0.1]) by mail.barafranca.com (Postfix) with ESMTP id 41094C4D85; Thu, 13 Dec 2007 03:04:40 +0000 (UTC) Received: from mail.barafranca.com ([67.19.101.164]) by localhost (mail.barafranca.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61901-04; Thu, 13 Dec 2007 03:04:00 +0000 (UTC) Received: from nexus.bsdlan.org (a213-22-38-76.cpe.netcabo.pt [213.22.38.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTP id EB5C3C4D3C; Thu, 13 Dec 2007 03:03:59 +0000 (UTC) Message-ID: <47609FE3.8040606@barafranca.com> Date: Thu, 13 Dec 2007 02:58:43 +0000 From: Hugo Silva User-Agent: Thunderbird 2.0.0.6 (X11/20070816) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> In-Reply-To: <47609F0A.7010805@clearchain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at barafranca.com X-Spam-Status: No, score=0 tagged_above=-1 required=4 tests=[none] X-Spam-Score: 0 X-Spam-Level: Cc: Benjamin Close Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 02:58:29 -0000 Benjamin Close wrote: > Peter Losher wrote: >> Hi, >> >> As part of our testing 7.0/ZFS we tried putting it thru it's paces >> having ZFS act as our storage medium for some test pgsql db's (like for >> sqlgrey, etc) and in both BETA2 and BETA4 (amd64) we get the same >> results with a RAIDZ2 container: >> >> -=- >> Dec 12 14:24:12 nsa sqlgrey: fatal: setconfig error at >> /usr/local/sbin/sqlgrey line 186. >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad4 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad6 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad8 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad10 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad12 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad14 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad16 offset=3665128448 size=21504 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad18 offset=3665128448 size=21504 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad4 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad6 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad8 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad10 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad12 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad14 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad16 offset=3665128448 size=21504 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad18 offset=3665128448 size=21504 >> Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault error=86 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad4 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad6 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad8 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad10 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad12 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad14 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad16 offset=3665128448 size=21504 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad18 offset=3665128448 size=21504 >> Dec 12 16:49:53 nsa postgres[50527]: [5-1] PANIC: could not write to >> log file 2, segment 53 at offset 7864320, length 8192: Input/output >> error >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad4 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad6 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad8 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad10 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad12 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad14 offset=3665128448 size=22016 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad16 offset=3665128448 size=21504 >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >> path=/dev/ad18 offset=3665128448 size=21504 >> Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault error=86 >> Dec 12 16:49:53 nsa postgres[50596]: [1-1] FATAL: the database system >> is starting up >> Dec 12 16:49:53 nsa kernel: pid 50527 (postgres), uid 70: exited on >> signal 6 (core dumped) >> -=- >> >> It basically corrupts the container from the inside until it fails >> completely (usually withing 24-48 hours depending on how busy the db is) >> >> I had thought it was a bad SATA replicator/controller, but we had that >> replaced w/ one from Supermicro. So it's either the disks, or something >> in ZFS. Anyone used ZFS to backend any db's (mysql or pgsql?) >> >> If you need more info, let me know... >> >> > Try turning of zil, whilst I don't use a db, I have zfs under high > load. I've found without zil turned off I see checksum corruption as > well: > > /boot/loader.conf > > vfs.zfs.zil_disable=1 > > Cheers, > Benjamin Wouldn't it be a bad idea to disable ZIL ? http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Disabling_the_ZIL_.28Don.27t.29 Regards, Hugo > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 03:00:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43B6216A419 for ; Thu, 13 Dec 2007 03:00:50 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 2719813C43E for ; Thu, 13 Dec 2007 03:00:49 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so815729waf.3 for ; Wed, 12 Dec 2007 19:00: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=Z0mL4D9QB11RYjGmCKHAIfbJ/QHviX3LADvgiAZy0Ok=; b=ML3lN6qA1rb6QRfM/T+mhvx+pFsioSGVobCCOejWwgxPW8EA8GZPyiBdFrSQDhToxOPSdkLxxblHqo4708GTKnrEtrPiqIxi3ER1+0W57j/SwzDP1gjsnj3XOpH+Wo6ynXgvAPrgcuzbEYDqTk0UAesB4bNtZ7wtFJsMe7UIlCw= 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=AxzLF8tgoLcj7uWoBzqvG0pdDz8ABfKbbLiU5V8Ub6V7n6YZCcLJC29KxL3iL7o0f7Dn6BZiTMAl+dRIY7S/KiteED68M3t2eMTMh6xU4RRoIginglVw1DSN1anCzGcL4MpLBRoBPxEQZ9f87WAVHW9Z+egHQVNJ/Sx3AIZnkyY= Received: by 10.114.26.1 with SMTP id 1mr1640728waz.80.1197514846848; Wed, 12 Dec 2007 19:00:46 -0800 (PST) Received: by 10.114.255.11 with HTTP; Wed, 12 Dec 2007 19:00:46 -0800 (PST) Message-ID: Date: Wed, 12 Dec 2007 19:00:46 -0800 From: "Kip Macy" To: "Hugo Silva" In-Reply-To: <47609FE3.8040606@barafranca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> Cc: freebsd-current@freebsd.org, Benjamin Close Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 03:00:50 -0000 On Dec 12, 2007 6:58 PM, Hugo Silva wrote: > > Benjamin Close wrote: > > Peter Losher wrote: > >> Hi, > >> > >> As part of our testing 7.0/ZFS we tried putting it thru it's paces > >> having ZFS act as our storage medium for some test pgsql db's (like for > >> sqlgrey, etc) and in both BETA2 and BETA4 (amd64) we get the same > >> results with a RAIDZ2 container: > >> > >> -=- > >> Dec 12 14:24:12 nsa sqlgrey: fatal: setconfig error at > >> /usr/local/sbin/sqlgrey line 186. > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad4 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad6 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad8 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad10 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad12 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad14 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad16 offset=3665128448 size=21504 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad18 offset=3665128448 size=21504 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad4 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad6 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad8 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad10 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad12 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad14 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad16 offset=3665128448 size=21504 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad18 offset=3665128448 size=21504 > >> Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault error=86 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad4 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad6 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad8 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad10 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad12 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad14 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad16 offset=3665128448 size=21504 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad18 offset=3665128448 size=21504 > >> Dec 12 16:49:53 nsa postgres[50527]: [5-1] PANIC: could not write to > >> log file 2, segment 53 at offset 7864320, length 8192: Input/output > >> error > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad4 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad6 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad8 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad10 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad12 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad14 offset=3665128448 size=22016 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad16 offset=3665128448 size=21504 > >> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault > >> path=/dev/ad18 offset=3665128448 size=21504 > >> Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault error=86 > >> Dec 12 16:49:53 nsa postgres[50596]: [1-1] FATAL: the database system > >> is starting up > >> Dec 12 16:49:53 nsa kernel: pid 50527 (postgres), uid 70: exited on > >> signal 6 (core dumped) > >> -=- > >> > >> It basically corrupts the container from the inside until it fails > >> completely (usually withing 24-48 hours depending on how busy the db is) > >> > >> I had thought it was a bad SATA replicator/controller, but we had that > >> replaced w/ one from Supermicro. So it's either the disks, or something > >> in ZFS. Anyone used ZFS to backend any db's (mysql or pgsql?) > >> > >> If you need more info, let me know... > >> > >> > > Try turning of zil, whilst I don't use a db, I have zfs under high > > load. I've found without zil turned off I see checksum corruption as > > well: > > > > /boot/loader.conf > > > > vfs.zfs.zil_disable=1 > > > > Cheers, > > Benjamin > > Wouldn't it be a bad idea to disable ZIL ? > > http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Disabling_the_ZIL_.28Don.27t.29 Yes. However, FreeBSD suffers from deadlocks under load if ZIL is enabled. -Kip From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 03:00:57 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C93216A529 for ; Thu, 13 Dec 2007 03:00:57 +0000 (UTC) (envelope-from kenfreebsd@icarz.com) Received: from deanna.icarz.com (deanna.icarz.com [207.99.22.19]) by mx1.freebsd.org (Postfix) with ESMTP id DB30313C457 for ; Thu, 13 Dec 2007 03:00:56 +0000 (UTC) (envelope-from kenfreebsd@icarz.com) Received: from kenxp (netb-138.icarz.com [209.123.219.138]) by deanna.icarz.com (8.13.8/8.13.8) with SMTP id lBD30qEd066422; Wed, 12 Dec 2007 22:00:52 -0500 (EST) (envelope-from kenfreebsd@icarz.com) Message-ID: <019501c83d34$5f03afd0$8adb7bd1@icarz.com> From: "Ken Menzel" To: "Rene Ladan" References: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com><11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com><20071212074208.GD29211@soaustin.net><136c01c83cdf$db5f0430$8adb7bd1@icarz.com><13cc01c83ce6$f7483bb0$8adb7bd1@icarz.com> <4760454F.4070905@gmail.com> Date: Wed, 12 Dec 2007 22:00:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: -102.457 () ALL_TRUSTED, AWL, BAYES_00, STOX_REPLY_TYPE, USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.63 on 207.99.22.19 Cc: freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ken Menzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 03:00:57 -0000 ----- Original Message ----- From: "Rene Ladan" To: "Ken Menzel" Cc: Sent: Wednesday, December 12, 2007 3:32 PM Subject: Re: CURRENT Kernel makes the system run very very hot > Ken Menzel schreef: >> ----- Original Message ----- From: "Rene Ladan" >> >> To: "Ken Menzel" >> Cc: >> Sent: Wednesday, December 12, 2007 12:18 PM >> Subject: Re: CURRENT Kernel makes the system run very very hot >> >> >>> 2007/12/12, Ken Menzel : >>>> ----- Original Message ----- >>>> From: "Mark Linimon" >>>> To: "Sam Fourman Jr." >>>> Cc: >>>> Sent: Wednesday, December 12, 2007 2:42 AM >>>> Subject: Re: CURRENT Kernel makes the system run very very hot >>>> >>>> >>>> > On Wed, Dec 12, 2007 at 01:38:49AM -0600, Sam Fourman Jr. >>>> > wrote: >>>> >> I did not file a PR (I don't know how I have never done one.) >>>> > >>>> > Please see http://www.freebsd.org/support/bugreports.html. >>>> > >>>> > mcl >>>> Thanks Mark, It seems like it may be an ACPI problem based on: >>>> >>>> (kgdb) print cpu_idle_hook >>>> $1 = (void (*)(void)) 0xffffffff801d0bb0 >>>> (kgdb) q >>>> >>>> Thanks to Kostik Belousov for the advice on where to go next. >>>> And >>>> based on that I will move this to the ACPI mailing list and file >>>> a PR. >>>> >>> Hmm, on my too hot i386 laptop: >>> >>> # make installkernel.debug >>> #gdb /boot/kernel/kernel >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, >>> and >>> you are >>> welcome to change it and/or distribute copies of it under certain >>> conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for >>> details. >>> This GDB was configured as "i386-marcel-freebsd"... >>> (gdb) print cpu_idle_hook >>> $1 = (void (*)(void)) 0xc063cc9b >>> (gdb) print cpu_idle_default >>> $2 = {void (void)} 0xc063cc9b >>> >> >> >> Rene, please try >> >> cd /usr/obj/usr/src/sys/GENERIC (or where-ever you built your >> kernel) >> kgdb kernel.debug /dev/mem >> print cpu_idle_hook >> >> This should show what is running in memory. >> > But it doens't :( (at least not human-readable). > > ----- > > root@ip4da3ae31:/usr/obj/usr/src/sys/RENE#kgdb kernel.debug /dev/mem > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd". > Ready to go. Enter 'tr' to connect to the remote target > with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port > or 'trf portno' to connect to the remote target with the firewire > interface. portno defaults to 5556. > > Type 'getsyms' after connection to load kld symbols. > > If you're debugging a local system, you can use 'kldsyms' instead > to load the kld symbols. That's a less obnoxious interface. > During symbol reading...location expression too complex... > During symbol reading, unsupported tag: 'DW_TAG_const_type'. Symbols did not load??? Did you strip the kernel or not compile with makeoptions DEBUG=-g ? I have this and options DDB and options KDB. > #0 0x00000000 in ?? () > (kgdb) print cpu_idle_hook > $1 = (void (*)(void)) 0xc080b6fd > (kgdb) print *0xc080b6fd > $2 = 0x57e58955 > (kgdb) print *0x57e58955 > Error accessing memory address 0x57e58955: Bad address. > (kgdb) q > > ----- > > The result is the same after all daily modules are loaded (my kernel > is quite minimal). > I manually booted /boot/kernel.debug/kernel.debug which I manually > copied from the > build directory. > > Regards, > Rene Hmmmm -- looks like symbols did not load. I am not an expert in this area. But I do know acpi is loaded after boot and I believe you have check the running kernel or a core dump from a running kernel. Otherwise you will always see the cpu_idle_default on the unloaded kernel, as I do also. I am working with Nate Lawson privately on this. I do believe we are all seeing the same problem, the idle is not sleeping, hopefully the same fix will work for everyone. I will post here if Nate can come up with a patch to try. Hope this helps! Ken > -- > GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 > (subkeys.pgp.net) > > "It won't fit on the line." > -- me, 2001 > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 04:18:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 822DD16A50A for ; Thu, 13 Dec 2007 04:18:19 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by mx1.freebsd.org (Postfix) with ESMTP id B8CB313C4F5 for ; Thu, 13 Dec 2007 04:18:18 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAGc/YEd5LSgsWmdsb2JhbACBWo4JASCBOw X-IronPort-AV: E=Sophos;i="4.24,160,1196602200"; d="scan'208";a="16390890" Received: from ppp121-45-40-44.lns10.adl2.internode.on.net (HELO mail.clearchain.com) ([121.45.40.44]) by ipmail05.adl2.internode.on.net with ESMTP; 13 Dec 2007 14:48:15 +1030 Received: from benjamin-closes-powerbook-g4-12.local (wcl.ml.unisa.edu.au [130.220.166.5]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id lBD4I7VY068878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 14:48:13 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <4760B342.4000301@clearchain.com> Date: Thu, 13 Dec 2007 14:51:22 +1030 From: Benjamin Close User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Kip Macy References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Thu, 13 Dec 2007 14:48:14 +1030 (CST) Cc: freebsd-current@freebsd.org, Hugo Silva Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 04:18:19 -0000 Kip Macy wrote: > On Dec 12, 2007 6:58 PM, Hugo Silva wrote: > >> Benjamin Close wrote: >> >>> Peter Losher wrote: >>> >>>> Hi, >>>> >>>> As part of our testing 7.0/ZFS we tried putting it thru it's paces >>>> having ZFS act as our storage medium for some test pgsql db's (like for >>>> sqlgrey, etc) and in both BETA2 and BETA4 (amd64) we get the same >>>> results with a RAIDZ2 container: >>>> >>>> -=- >>>> Dec 12 14:24:12 nsa sqlgrey: fatal: setconfig error at >>>> /usr/local/sbin/sqlgrey line 186. >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad4 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad6 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad8 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad10 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad12 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad14 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad16 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad18 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad4 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad6 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad8 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad10 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad12 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad14 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad16 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad18 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault error=86 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad4 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad6 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad8 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad10 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad12 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad14 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad16 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad18 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa postgres[50527]: [5-1] PANIC: could not write to >>>> log file 2, segment 53 at offset 7864320, length 8192: Input/output >>>> error >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad4 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad6 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad8 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad10 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad12 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad14 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad16 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad18 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault error=86 >>>> Dec 12 16:49:53 nsa postgres[50596]: [1-1] FATAL: the database system >>>> is starting up >>>> Dec 12 16:49:53 nsa kernel: pid 50527 (postgres), uid 70: exited on >>>> signal 6 (core dumped) >>>> -=- >>>> >>>> It basically corrupts the container from the inside until it fails >>>> completely (usually withing 24-48 hours depending on how busy the db is) >>>> >>>> I had thought it was a bad SATA replicator/controller, but we had that >>>> replaced w/ one from Supermicro. So it's either the disks, or something >>>> in ZFS. Anyone used ZFS to backend any db's (mysql or pgsql?) >>>> >>>> If you need more info, let me know... >>>> >>>> >>>> >>> Try turning of zil, whilst I don't use a db, I have zfs under high >>> load. I've found without zil turned off I see checksum corruption as >>> well: >>> >>> /boot/loader.conf >>> >>> vfs.zfs.zil_disable=1 >>> >>> Cheers, >>> Benjamin >>> >> Wouldn't it be a bad idea to disable ZIL ? >> >> http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Disabling_the_ZIL_.28Don.27t.29 >> > > Yes. However, FreeBSD suffers from deadlocks under load if ZIL is enabled. > > -Kip > It also comes down to what your doing. ZFS is always consistent on disk. ZIL provides the journal between the last pool transaction write and what has changed since that write. Either way zfs will come up cleanly after a power failure, it's just whether you have those last few sync's or not. For the application I'm using zfs for (rsynced backups, snapshoted daily) that'll be corrected the next day anyway. For a DB, this could be a show stopper. Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 04:22:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B34016A417 for ; Thu, 13 Dec 2007 04:22:37 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by mx1.freebsd.org (Postfix) with ESMTP id 94FFD13C442 for ; Thu, 13 Dec 2007 04:22:36 +0000 (UTC) (envelope-from Benjamin.Close@clearchain.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4HAGc/YEd5LSgsWmdsb2JhbACBWo4JASCBOw X-IronPort-AV: E=Sophos;i="4.24,160,1196602200"; d="scan'208";a="16393155" Received: from ppp121-45-40-44.lns10.adl2.internode.on.net (HELO mail.clearchain.com) ([121.45.40.44]) by ipmail05.adl2.internode.on.net with ESMTP; 13 Dec 2007 14:52:34 +1030 Received: from benjamin-closes-powerbook-g4-12.local (wcl.ml.unisa.edu.au [130.220.166.5]) (authenticated bits=0) by mail.clearchain.com (8.13.8/8.13.8) with ESMTP id lBD4MQ4h068911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 14:52:32 +1030 (CST) (envelope-from Benjamin.Close@clearchain.com) Message-ID: <4760B444.1080604@clearchain.com> Date: Thu, 13 Dec 2007 14:55:40 +1030 From: Benjamin Close User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Hugo Silva References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> In-Reply-To: <47609FE3.8040606@barafranca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on pegasus.clearchain.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (mail.clearchain.com [192.168.154.1]); Thu, 13 Dec 2007 14:52:32 +1030 (CST) Cc: freebsd-current@FreeBSD.ORG Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 04:22:37 -0000 Hugo Silva wrote: > Benjamin Close wrote: >> Peter Losher wrote: >>> Hi, >>> >>> As part of our testing 7.0/ZFS we tried putting it thru it's paces >>> having ZFS act as our storage medium for some test pgsql db's (like for >>> sqlgrey, etc) and in both BETA2 and BETA4 (amd64) we get the same >>> results with a RAIDZ2 container: >>> >>> -=- >>> Dec 12 14:24:12 nsa sqlgrey: fatal: setconfig error at >>> /usr/local/sbin/sqlgrey line 186. >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad4 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad6 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad8 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad10 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad12 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad14 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad16 offset=3665128448 size=21504 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad18 offset=3665128448 size=21504 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad4 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad6 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad8 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad10 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad12 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad14 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad16 offset=3665128448 size=21504 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad18 offset=3665128448 size=21504 >>> Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault error=86 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad4 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad6 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad8 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad10 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad12 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad14 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad16 offset=3665128448 size=21504 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad18 offset=3665128448 size=21504 >>> Dec 12 16:49:53 nsa postgres[50527]: [5-1] PANIC: could not write to >>> log file 2, segment 53 at offset 7864320, length 8192: Input/output >>> error >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad4 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad6 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad8 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad10 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad12 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad14 offset=3665128448 size=22016 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad16 offset=3665128448 size=21504 >>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>> path=/dev/ad18 offset=3665128448 size=21504 >>> Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault error=86 >>> Dec 12 16:49:53 nsa postgres[50596]: [1-1] FATAL: the database system >>> is starting up >>> Dec 12 16:49:53 nsa kernel: pid 50527 (postgres), uid 70: exited on >>> signal 6 (core dumped) >>> -=- >>> >>> It basically corrupts the container from the inside until it fails >>> completely (usually withing 24-48 hours depending on how busy the db >>> is) >>> >>> I had thought it was a bad SATA replicator/controller, but we had that >>> replaced w/ one from Supermicro. So it's either the disks, or >>> something >>> in ZFS. Anyone used ZFS to backend any db's (mysql or pgsql?) >>> >>> If you need more info, let me know... >>> >>> >> Try turning of zil, whilst I don't use a db, I have zfs under high >> load. I've found without zil turned off I see checksum corruption as >> well: >> >> /boot/loader.conf >> >> vfs.zfs.zil_disable=1 >> >> Cheers, >> Benjamin > > Wouldn't it be a bad idea to disable ZIL ? > > http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Disabling_the_ZIL_.28Don.27t.29 > A good read is: http://blogs.sun.com/perrin/entry/the_lumberjack Which shows why zil exists. Cheers, Benjamin From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 07:00:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A486F16A417 for ; Thu, 13 Dec 2007 07:00:55 +0000 (UTC) (envelope-from weongyo.jeong@gmail.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 7205F13C44B for ; Thu, 13 Dec 2007 07:00:53 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so496281rvb.43 for ; Wed, 12 Dec 2007 23:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:organization:x-operation-sytem:from; bh=JO6Bwm2mEmGrmRKnr3igIyoBeSeLP4ETR6lOisW5xPs=; b=sV2MOHXBUr1J+fEeoGGQDn08YRXkM82SD/+gDvinYnpfnozkz6fND+Ys7pMagRH3XmZpOYO6ivAAbRebEbrPNWds89B8UY5BRuiPJdIWCslV9s5Mwjf7Fqr3iBs6RknDHuj+9j3wpu9XcOuj1d3MDm3Cv6wnFY9xBukbSOGo4Ws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:organization:x-operation-sytem:from; b=CmJcAdUSljhRAZPY8rBnc4W40U1wgTtLFaDLtP2zekCCrojclKLG88wyFdLUaYRnQR+uVkg8F3EQdQLBtEmFkqzIXWm7MVeYrPFnSzJPa6bbBy7GTM04yYoDJYWKgf/54wnzYj3kwU1ExY9E7QwJEDEct3rt83UfmBffJRNwlJU= Received: by 10.141.99.4 with SMTP id b4mr892087rvm.254.1197529251146; Wed, 12 Dec 2007 23:00:51 -0800 (PST) Received: from freebsd.weongyo.org ( [211.53.35.67]) by mx.google.com with ESMTPS id l32sm4975535rvb.2007.12.12.23.00.47 (version=SSLv3 cipher=OTHER); Wed, 12 Dec 2007 23:00:49 -0800 (PST) Received: by freebsd.weongyo.org (sSMTP sendmail emulation); Thu, 13 Dec 2007 16:00:52 +0900 Date: Thu, 13 Dec 2007 16:00:51 +0900 To: Leonardo Midolo Message-ID: <20071213070051.GA52728@freebsd.weongyo.org> Mail-Followup-To: Leonardo Midolo , freebsd-current@freebsd.org References: <1196593676.6051.19.camel@leo-laptop.homeunix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196593676.6051.19.camel@leo-laptop.homeunix.net> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD From: Weongyo Jeong Cc: freebsd-current@freebsd.org Subject: Re: Panic 7.0 BETA-3 (page fault) using D-Link DWL-G122 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 07:00:55 -0000 Hello Leonardo, I think your problem is a known issue and commited a fix to HEAD. Can you try to test the rum(4) HEAD driver? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/if_rum.c (rev 1.15) Regards, Weongyo Jeong On Sun, Dec 02, 2007 at 12:07:56PM +0100, Leonardo Midolo wrote: > Hello everyone > I'm tracking RELENG_7 (i386, SCHED_SMP, last build: today, 2 dec) on my > laptop (core 2 duo) and I've recently bought an usb wireless adapter > (D-Link DWL-G122 rev C1). > Everything works properly (i can connect to the access point using WPA > and do normal network activities) but sometimes (I must say, randomly) I > get a kernel panic. > > Here's the debug info, hope it helps: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x12 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06b976a > stack pointer = 0x28:0xe296cbe4 > frame pointer = 0x28:0xe296cbfc > 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 = 24 (irq23: uhci0 ehci0) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 3m44s > Physical memory: 1009 MB > Dumping 107 MB: 92 76 60 44 28 12 > > Backtrace > #0 doadump () at pcpu.h:195 > #1 0xc0752e07 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc07530c9 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc0a184fc in trap_fatal (frame=0xe296cba4, eva=18) > at /usr/src/sys/i386/i386/trap.c:872 > #4 0xc0a18760 in trap_pfault (frame=0xe296cba4, usermode=0, eva=18) > at /usr/src/sys/i386/i386/trap.c:785 > #5 0xc0a190b2 in trap (frame=0xe296cba4) > at /usr/src/sys/i386/i386/trap.c:463 > #6 0xc09ffacb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc06b976a in rum_txeof (xfer=0xc4343800, priv=0xc40a7498, > status=USBD_NORMAL_COMPLETION) at /usr/src/sys/dev/usb/if_rum.c:842 > #8 0xc06d2fa5 in usb_transfer_complete (xfer=0xc4343800) > at /usr/src/sys/dev/usb/usbdi.c:977 > #9 0xc06a5ba1 in ehci_softintr (v=0xc3fe5800) > at /usr/src/sys/dev/usb/ehci.c:884 > #10 0xc06ceb52 in usb_schedsoftintr (bus=0xc3fe5800) > at /usr/src/sys/dev/usb/usb.c:844 > #11 0xc06a737e in ehci_intr1 (sc=0xc3fe5800) > at /usr/src/sys/dev/usb/ehci.c:603 > #12 0xc06a7db5 in ehci_intr (v=0xc3fe5800) > at /usr/src/sys/dev/usb/ehci.c:562 > #13 0xc07366cb in ithread_loop (arg=0xc4057b00) > at /usr/src/sys/kern/kern_intr.c:1036 > #14 0xc0733609 in fork_exit (callout=0xc0736520 , > arg=0xc4057b00, frame=0xe296cd38) > at /usr/src/sys/kern/kern_fork.c:754 > #15 0xc09ffb40 in fork_trampoline () > at /usr/src/sys/i386/i386/exception.s:205 > > Thanks, > Leonardo > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 07:58:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D68016A418 for ; Thu, 13 Dec 2007 07:58:08 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id B6E4313C4DD for ; Thu, 13 Dec 2007 07:58:07 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1484139pyb.3 for ; Wed, 12 Dec 2007 23:58: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=3dLBqxXP6Z6wyJXoagogMgOhxoVyY+OcnnBkvoR0ayI=; b=lgODIoPqEaCcOWR4vgFBRw8oiepbszF4/RgdJdIgE7I0tNMeBP228H7NXPyoduzE7oM0ca+4PqD/Ox8jSgFjLwzkwHmmOGrbvytKjaa1CaDEbS8sXpyVBhT1qNvxZzU2vMrd0wcM5rUx4ZCof8e9Qt3+OBglccyCLEWg7xzHWh0= 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=YNYcwlqLMS4wugLzeygPm69r5CotLhhwS9fiZdhjebmmRPUKkhWnp+kCXw2CDQziO6u1xb+JUJfb71PoGbo2mq0Tct7QF4+omzNMB2luUtziUmGxapjNkFxK4l4/28DjanlnQsMo9OSihxZTCMhIQNWHoWBl+QXU0qZickHwDnM= Received: by 10.142.225.11 with SMTP id x11mr659847wfg.115.1197532685893; Wed, 12 Dec 2007 23:58:05 -0800 (PST) Received: by 10.142.50.12 with HTTP; Wed, 12 Dec 2007 23:58:05 -0800 (PST) Message-ID: Date: Thu, 13 Dec 2007 08:58:05 +0100 From: "Rene Ladan" To: "Ken Menzel" In-Reply-To: <019501c83d34$5f03afd0$8adb7bd1@icarz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0beb01c83c35$aeb48ae0$8adb7bd1@icarz.com> <11167f520712112338v654d7686rf9db06647ec28f88@mail.gmail.com> <20071212074208.GD29211@soaustin.net> <136c01c83cdf$db5f0430$8adb7bd1@icarz.com> <13cc01c83ce6$f7483bb0$8adb7bd1@icarz.com> <4760454F.4070905@gmail.com> <019501c83d34$5f03afd0$8adb7bd1@icarz.com> Cc: freebsd-current@freebsd.org Subject: Re: CURRENT Kernel makes the system run very very hot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 07:58:08 -0000 2007/12/13, Ken Menzel : > ----- Original Message ----- > From: "Rene Ladan" > To: "Ken Menzel" > Cc: > Sent: Wednesday, December 12, 2007 3:32 PM > Subject: Re: CURRENT Kernel makes the system run very very hot > > > > Ken Menzel schreef: > >> ----- Original Message ----- From: "Rene Ladan" > >> > >> To: "Ken Menzel" > >> Cc: > >> Sent: Wednesday, December 12, 2007 12:18 PM > >> Subject: Re: CURRENT Kernel makes the system run very very hot > >> > >> > >>> 2007/12/12, Ken Menzel : > >>>> ----- Original Message ----- > >>>> From: "Mark Linimon" > >>>> To: "Sam Fourman Jr." > >>>> Cc: > >>>> Sent: Wednesday, December 12, 2007 2:42 AM > >>>> Subject: Re: CURRENT Kernel makes the system run very very hot > >>>> > >>>> > >>>> > On Wed, Dec 12, 2007 at 01:38:49AM -0600, Sam Fourman Jr. > >>>> > wrote: > >>>> >> I did not file a PR (I don't know how I have never done one.) > >>>> > > >>>> > Please see http://www.freebsd.org/support/bugreports.html. > >>>> > > >>>> > mcl > >>>> Thanks Mark, It seems like it may be an ACPI problem based on: > >>>> > >>>> (kgdb) print cpu_idle_hook > >>>> $1 = (void (*)(void)) 0xffffffff801d0bb0 > >>>> (kgdb) q > >>>> > >>>> Thanks to Kostik Belousov for the advice on where to go next. > >>>> And > >>>> based on that I will move this to the ACPI mailing list and file > >>>> a PR. > >>>> > >>> Hmm, on my too hot i386 laptop: > >>> > >>> # make installkernel.debug > >>> #gdb /boot/kernel/kernel > >>> GNU gdb 6.1.1 [FreeBSD] > >>> Copyright 2004 Free Software Foundation, Inc. > >>> GDB is free software, covered by the GNU General Public License, > >>> and > >>> you are > >>> welcome to change it and/or distribute copies of it under certain > >>> conditions. > >>> Type "show copying" to see the conditions. > >>> There is absolutely no warranty for GDB. Type "show warranty" for > >>> details. > >>> This GDB was configured as "i386-marcel-freebsd"... > >>> (gdb) print cpu_idle_hook > >>> $1 = (void (*)(void)) 0xc063cc9b > >>> (gdb) print cpu_idle_default > >>> $2 = {void (void)} 0xc063cc9b > >>> > >> > >> > >> Rene, please try > >> > >> cd /usr/obj/usr/src/sys/GENERIC (or where-ever you built your > >> kernel) > >> kgdb kernel.debug /dev/mem > >> print cpu_idle_hook > >> > >> This should show what is running in memory. > >> > > But it doens't :( (at least not human-readable). > > > > ----- > > > > root@ip4da3ae31:/usr/obj/usr/src/sys/RENE#kgdb kernel.debug /dev/mem > > [GDB will not be able to debug user-mode threads: > > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and > > you are > > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > > details. > > This GDB was configured as "i386-marcel-freebsd". > > Ready to go. Enter 'tr' to connect to the remote target > > with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port > > or 'trf portno' to connect to the remote target with the firewire > > interface. portno defaults to 5556. > > > > Type 'getsyms' after connection to load kld symbols. > > > > If you're debugging a local system, you can use 'kldsyms' instead > > to load the kld symbols. That's a less obnoxious interface. > > During symbol reading...location expression too complex... > > During symbol reading, unsupported tag: 'DW_TAG_const_type'. > > Symbols did not load??? Did you strip the kernel or not compile with > makeoptions DEBUG=-g ? I have this and options DDB and options KDB. > My kernel has "makeoptions DEBUG=-g" and options DDB,KDB too. > > #0 0x00000000 in ?? () > > (kgdb) print cpu_idle_hook > > $1 = (void (*)(void)) 0xc080b6fd > > (kgdb) print *0xc080b6fd > > $2 = 0x57e58955 > > (kgdb) print *0x57e58955 > > Error accessing memory address 0x57e58955: Bad address. > > (kgdb) q > > > > ----- > > > > The result is the same after all daily modules are loaded (my kernel > > is quite minimal). > > I manually booted /boot/kernel.debug/kernel.debug which I manually > > copied from the > > build directory. > > > > Regards, > > Rene > > Hmmmm -- looks like symbols did not load. I am not an expert in this > area. But I do know acpi is loaded after boot and I believe you have > check the running kernel or a core dump from a running kernel. > Otherwise you will always see the cpu_idle_default on the unloaded > kernel, as I do also. I am working with Nate Lawson privately on > this. I do believe we are all seeing the same problem, the idle is > not sleeping, hopefully the same fix will work for everyone. > > I will post here if Nate can come up with a patch to try. > Ok :) Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 12:52:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6819216A417 for ; Thu, 13 Dec 2007 12:52:42 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id CCA6713C457 for ; Thu, 13 Dec 2007 12:52:41 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so608926nfb.33 for ; Thu, 13 Dec 2007 04:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=geYOq7vzDuKBX68qy8Y9NdMc3ADUogjqKFU7/iAIw7Q=; b=hqGCmYdfJAwBtuTcZNTI2mHuB42hp58P/PVv0puGrwKWH7S+JpknID9sE1wbAikUG/tI2/8vQlzT8Ox5dZzH7fLPj47d5IWlHE0UHEXimNh7c278OIyYkOrHebRxWwSaiq2d7dIR1D0hTCq6jz6uCaC3XB5e03eWKvXth6/zAXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=bm9gkJslrF+et8ddfHLcZl2GUdgsNepbuwboY/BfeRGRGjKnRNISIqffULxGVt6411hI0c7BWk6p4ORqpoEmWd/fl2rBCHfWzkULqzaV2xLG50XaCqTgJBsARYIuHh4axJc4gT2KS0qglgdmBabnigTLZOlANI7auye+dsOYFTM= Received: by 10.78.180.18 with SMTP id c18mr2254547huf.24.1197550360175; Thu, 13 Dec 2007 04:52:40 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id y6sm18108751mug.2007.12.13.04.52.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2007 04:52:38 -0800 (PST) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Thu, 13 Dec 2007 14:52:30 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <20071211205813.GB1455@kobe.laptop> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1772793.P2GptbU4c5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712131452.30994.qpadla@gmail.com> Cc: freebsd-doc@freebsd.org, Ivan Voras Subject: Re: FreeBSD 7 trivial problems / notes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 12:52:42 -0000 --nextPart1772793.P2GptbU4c5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 12 December 2007 20:50:56 Ivan Voras wrote: > Giorgos Keramidas wrote: > > % The suggestion to make it non-fatal sounds nice though. Maybe > > % we should consider an `rc.conf' option which controls if mount > > % failures are actually considered fatal or just `annoying', and > > % then make the failure conditional on that option, i.e.: > > % > > % mount_failure_level=3D{IGNORE,WARN,FATAL} > > I like this, but will like to suggest that "WARN" or "IGNORE" be the > default, since I think there's practically no chance of backward > compatibility issues. > > > % Adding a mount(8) option, which can be set per filesystem is > > % probably also a good idea, i.e. something like: > > % > > % /dev/acd0 /cdrom cd9660 ro,auto,mounterror=3Dignore 0 0 > > Perhaps you mean "fsckerror=3Dignore"? > IIRC Linux has something like this (the "mounterror" variant), and in > some way it's nice to have this fine-grained per-file system, but this > particular instance won't save the user from having a machine > non-bootable with file systems that don't have fsck (if you already know > you need to ignore this type of error, you already know that you need > "2" in the fsck field). If you mean the "errors=3Dcontinue / errors=3Dremount-ro / errors=3Dpanic" option in Linux then it's define the behavior of the system when the=20 filesystem is found to be in non consistent state, but not whether fsck is= =20 able to check it or not. So it's somewhat diffrent. Personally i do not=20 see the requirements for this option too.=20 Also there is a knob in defaults/rc.conf called "netfs_types" may be it=20 could be used to skip network filesystem checking? > > > % It's too late to introduce something like this to 7.0, but if > > % it works and is accepted as an idea, we can implement it on > > % HEAD and backport it later :-) > > > > I still don't see why user-error in fstab for tmpfs should be > > treated as a special case, but that's probably me being blinded > > Making tmpfs a special case for stab would certainly be a bad idea :) I > was always suggesting generic solutions. > > > by a few years of "UNIX can let you shoot your foot, but it's not > > the fault of UNIX if you do, in fact, blast it off". > > I appreciate the charm and the wisdom of the "old-school" way of > thinking, but you will recognize that, in additions to many good things, > it has brought us some not so good, among which are: > > - kernel panics on file system corruption (instead of just unmounting > them) - kernel panics when mounted devices go missing, e.g. USB (instead > of just umounting it) > - "root is god" model which everyone except the embedded people are > trying hard to replace nowadays (ok, this one's hard to solve) > - "kern_map too small" panics in ZFS (anything's better than panics; why > isn't it delaying requests in low memory conditions?) > - ...probably more; this subject pops up every now and then on the > lists. > > Modern systems should fail gracefully - Unix thrived on small systems > with limited resources which maybe couldn't afford this policy, but > current systems can do better. =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart1772793.P2GptbU4c5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHYSsO/2R6KvEYGaIRAkcyAJ0YUWkljGre+QlCFurda1hWo5l8dQCeKU14 nKIzA0PfEjDdfoUXNmTJihI= =P4CU -----END PGP SIGNATURE----- --nextPart1772793.P2GptbU4c5-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 14:15:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E608816A418 for ; Thu, 13 Dec 2007 14:15:27 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from sr-6-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.freebsd.org (Postfix) with ESMTP id AB82013C457 for ; Thu, 13 Dec 2007 14:15:27 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from localhost (localhost.tamu.edu [127.0.0.1]) by sr-6-int.cis.tamu.edu (Postfix) with ESMTP id 03AC828D648; Thu, 13 Dec 2007 07:59:48 -0600 (CST) Received: from [192.168.1.46] (pool-71-113-249-98.herntx.dsl-w.verizon.net [71.113.249.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sr-6-int.cis.tamu.edu (Postfix) with ESMTP id 5951328DE4A; Thu, 13 Dec 2007 07:59:44 -0600 (CST) In-Reply-To: <4760B444.1080604@clearchain.com> References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-203849357; protocol="application/pkcs7-signature" Message-Id: <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> From: David Duchscher Date: Thu, 13 Dec 2007 07:59:35 -0600 To: Benjamin Close X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: amavisd-new at tamu.edu X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Hugo Silva Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 14:15:28 -0000 --Apple-Mail-1-203849357 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 12, 2007, at 10:25 PM, Benjamin Close wrote: > Hugo Silva wrote: >> Benjamin Close wrote: >>> Peter Losher wrote: >>>> Hi, >>>> >>>> As part of our testing 7.0/ZFS we tried putting it thru it's paces >>>> having ZFS act as our storage medium for some test pgsql db's >>>> (like for >>>> sqlgrey, etc) and in both BETA2 and BETA4 (amd64) we get the same >>>> results with a RAIDZ2 container: >>>> >>>> -=- >>>> Dec 12 14:24:12 nsa sqlgrey: fatal: setconfig error at >>>> /usr/local/sbin/sqlgrey line 186. >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad4 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad6 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad8 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad10 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad12 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad14 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad16 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad18 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad4 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad6 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad8 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad10 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad12 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad14 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad16 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad18 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault >>>> error=86 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad4 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad6 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad8 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad10 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad12 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad14 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad16 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad18 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa postgres[50527]: [5-1] PANIC: could not >>>> write to >>>> log file 2, segment 53 at offset 7864320, length 8192: Input/ >>>> output error >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad4 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad6 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad8 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad10 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad12 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad14 offset=3665128448 size=22016 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad16 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: checksum mismatch, zpool=vault >>>> path=/dev/ad18 offset=3665128448 size=21504 >>>> Dec 12 16:49:53 nsa root: ZFS: zpool I/O failure, zpool=vault >>>> error=86 >>>> Dec 12 16:49:53 nsa postgres[50596]: [1-1] FATAL: the database >>>> system >>>> is starting up >>>> Dec 12 16:49:53 nsa kernel: pid 50527 (postgres), uid 70: exited on >>>> signal 6 (core dumped) >>>> -=- >>>> >>>> It basically corrupts the container from the inside until it fails >>>> completely (usually withing 24-48 hours depending on how busy >>>> the db is) >>>> >>>> I had thought it was a bad SATA replicator/controller, but we >>>> had that >>>> replaced w/ one from Supermicro. So it's either the disks, or >>>> something >>>> in ZFS. Anyone used ZFS to backend any db's (mysql or pgsql?) >>>> >>>> If you need more info, let me know... >>>> >>>> >>> Try turning of zil, whilst I don't use a db, I have zfs under >>> high load. I've found without zil turned off I see checksum >>> corruption as well: >>> >>> /boot/loader.conf >>> >>> vfs.zfs.zil_disable=1 >>> >>> Cheers, >>> Benjamin >> >> Wouldn't it be a bad idea to disable ZIL ? >> >> http://www.solarisinternals.com/wiki/index.php/ >> ZFS_Evil_Tuning_Guide#Disabling_the_ZIL_.28Don.27t.29 > > A good read is: > > http://blogs.sun.com/perrin/entry/the_lumberjack > > Which shows why zil exists. > > Cheers, > Benjamin So does anybody know of a battery backed NVRAM card that can be used with FreeBSD that the ZIL could be offloaded to? -- DaveD --Apple-Mail-1-203849357-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 15:43:02 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A788916A46C; Thu, 13 Dec 2007 15:43:02 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:1f1::2]) by mx1.freebsd.org (Postfix) with ESMTP id E789413C47E; Thu, 13 Dec 2007 15:43:01 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from prawn.unsane.co.uk (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id lBDFgRse023302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 15:42:28 GMT (envelope-from jhary@unsane.co.uk) Message-ID: <476152E9.3090707@unsane.co.uk> Date: Thu, 13 Dec 2007 15:42:33 +0000 From: Vince User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: Benjamin Close References: <472A6708.9030109@clearchain.com> In-Reply-To: <472A6708.9030109@clearchain.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current , freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 15:43:02 -0000 Benjamin Close wrote: > Howdy All, I'm pleased to announce the first 'official' > experimental version of the wpi wireless driver and hence require your > help in making it become stable. > Expect a few things not to work (ie bg scanning, setting txpower) but in > general the driver should be usable in station mode (hostap is not yet > supported). > > If you've got an Intel 3945abg wireless card, grab the tarball at: > > > http://people.freebsd.org/~benjsc/downloads/wpi/20071102-freebsd-wpi.tar.gz > > Untar and follow the instructions in the README. > If you want more info about the driver, or to checkout the FAQ checkout: > > http://www.clearchain.com/wiki/Wpi > > I'm interested in all reports related to panics, things not working as > expected, etc. > The driver still has debug enabled so expect a few messages to be dumped > to the screen whilst in use. > > Finally, many thanks to all those that have been helping debug the > driver along the way. > Thanks for getting this driver going, I'm now using the version in 7.0, Its working very well for me other than one (reasonably minor) thing, which is that "ifconfig wpi0 scan" just sits there until I kill it. the driver works in every other way, associates, works with WEP (havent tried with WPA.) It will find and associate with a network if I just put in "ifconfig wpi0 up" or if i use wpa_supplicant. (jhary@prawn)$uname -a FreeBSD prawn.unsane.co.uk 7.0-BETA4 FreeBSD 7.0-BETA4 #39: Tue Dec 11 12:51:33 GMT 2007 toor@prawn.unsane.co.uk:/usr/local/obj/usr/src/sys/PRAWN7ULE i386 Vince > Cheers, > Benjamin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 17:55:09 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 726D016A419 for ; Thu, 13 Dec 2007 17:55:09 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0B56313C4DD for ; Thu, 13 Dec 2007 17:55:08 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J2s2v-0007E9-BO for freebsd-current@freebsd.org; Thu, 13 Dec 2007 17:40:29 +0000 Received: from 78-1-88-159.adsl.net.t-com.hr ([78.1.88.159]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Dec 2007 17:40:29 +0000 Received: from ivoras by 78-1-88-159.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Dec 2007 17:40:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Thu, 13 Dec 2007 18:26:41 +0100 Lines: 29 Message-ID: References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig63DE3A6A01F84C5519633464" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-88-159.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 17:55:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig63DE3A6A01F84C5519633464 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kip Macy wrote: > Yes. However, FreeBSD suffers from deadlocks under load if ZIL is enabl= ed. Do you know how such deadlocks manifest? Do they perhaps result in a process locked in "zfs" wchan (not "zfs:&...")? --------------enig63DE3A6A01F84C5519633464 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 iD8DBQFHYWtRldnAQVacBcgRAoHkAJ4uvn1BeKMqHRZEysgK4Vh68C9RxACg2J3c DawH96eBYFHK5JqljUB2q1A= =Fu6n -----END PGP SIGNATURE----- --------------enig63DE3A6A01F84C5519633464-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:35:20 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F20016A41A for ; Thu, 13 Dec 2007 21:35:20 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 18F8B13C448 for ; Thu, 13 Dec 2007 21:35:19 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 89459 invoked from network); 13 Dec 2007 21:31:38 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@128.238.66.5) by acm.poly.edu with AES256-SHA encrypted SMTP; 13 Dec 2007 21:31:38 -0000 Message-ID: <4761A58F.3070605@acm.poly.edu> Date: Thu, 13 Dec 2007 16:35:11 -0500 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.0 (X11/20070609) MIME-Version: 1.0 To: Benjamin Close References: <472A6708.9030109@clearchain.com> In-Reply-To: <472A6708.9030109@clearchain.com> Content-Type: multipart/mixed; boundary="------------080401030803020405030909" Cc: freebsd-current , freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 21:35:20 -0000 This is a multi-part message in MIME format. --------------080401030803020405030909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benjamin Close wrote: > Howdy All, I'm pleased to announce the first 'official' > experimental version of the wpi wireless driver and hence require your > help in making it become stable. > Expect a few things not to work (ie bg scanning, setting txpower) but > in general the driver should be usable in station mode (hostap is not > yet supported). > > If you've got an Intel 3945abg wireless card, grab the tarball at: > > > http://people.freebsd.org/~benjsc/downloads/wpi/20071102-freebsd-wpi.tar.gz > > > Untar and follow the instructions in the README. > If you want more info about the driver, or to checkout the FAQ checkout: > > http://www.clearchain.com/wiki/Wpi > > I'm interested in all reports related to panics, things not working as > expected, etc. > The driver still has debug enabled so expect a few messages to be > dumped to the screen whilst in use. > > Finally, many thanks to all those that have been helping debug the > driver along the way. > > Cheers, > Benjamin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" First, thanks a lot for working on this. I installed 7.0-BETA4/amd64 onto my friend's Dell Inspiron E1505, which has one of these (pciconf says it's a "10418086 Intel 3945ABG Wireless LAN Controller"). With the module built from RELENG_7 sources from a few hours ago, "ifconfig wpi0 up" panics the kernel with (copied by hand): Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff806f6bd2 stack pointer = 0x10:0xffffffffae6ba970 frame pointer = 0x10:0xffffffae6babc0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, press 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1108 (wpi taskq) trap number = 12 panic: page fault cpuid = 1 The 20071102-freebsd-wpi.tar.gz tarball behaves the same way, and it also happens on FreeBSD/i386. If it's not a known problem, shall I provide a backtrace? -Boris --------------080401030803020405030909 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-BETA4 #0: Sun Dec 2 16:34:41 UTC 2007 root@myers.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (1828.76-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 2133782528 (2034 MB) avail memory = 2059112448 (1963 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi0: reservation of 0, 9fc00 (3) failed acpi0: reservation of 100000, 7fdd3400 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130b2406000b24 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6130b2406000b24 device_attach: est1 attach returned 6 p4tcc1: on cpu1 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xee00-0xeeff mem 0xd0000000-0xdfffffff,0xefdf0000-0xefdfffff irq 16 at device 0.0 on pci1 pci0: at device 27.0 (no driver attached) pcib2: at device 28.0 on pci0 pci11: on pcib2 pci11: at device 0.0 (no driver attached) pcib3: at device 28.3 on pci0 pci12: on pcib3 uhci0: port 0xbf80-0xbf9f irq 20 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xbf60-0xbf7f irq 21 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbf40-0xbf5f irq 22 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xbf20-0xbf3f irq 23 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xffa80000-0xffa803ff irq 20 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib4: at device 30.0 on pci0 pci3: on pcib4 bfe0: mem 0xef9fe000-0xef9fffff irq 17 at device 0.0 on pci3 miibus0: on bfe0 bmtphy0: PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: using obsoleted if_watchdog interface bfe0: Ethernet address: 00:15:c5:c8:10:70 bfe0: [ITHREAD] fwohci0: <1394 Open Host Controller Interface> mem 0xef9fd800-0xef9fdfff irq 19 at device 1.0 on pci3 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 47:4f:c0:00:1f:15:95:61 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x27ec000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 46:4f:c0:15:95:61 fwe0: Ethernet address: 46:4f:c0:15:95:61 fwip0: on firewire0 fwip0: Firewire address: 47:4f:c0:00:1f:15:95:61 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pci3: at device 1.1 (no driver attached) pci3: at device 1.2 (no driver attached) pci3: at device 1.3 (no driver attached) pci3: at device 1.4 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf irq 17 at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64,0x62,0x66 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 orm0: at iomem 0xc0000-0xcffff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 76319MB at ata0-master SATA150 acd0: DVDR at ata1-master UDMA33 GEOM_LABEL: Label for provider ad0s1 is ntfs/Windows. SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s3a --------------080401030803020405030909-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 13 21:39:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8878A16A477 for ; Thu, 13 Dec 2007 21:39:04 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id CB31713C4D5 for ; Thu, 13 Dec 2007 21:39:03 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 13 Dec 2007 21:39:02 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO homeKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp043) with SMTP; 13 Dec 2007 22:39:02 +0100 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX1/r4A4pTYHrHGJv+UMP4XhQscEhU6JUcaKqFsTo0i ovFdLQXrPVlFfJ Message-ID: <4761A673.7040009@gmx.de> Date: Thu, 13 Dec 2007 22:38:59 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20071203) MIME-Version: 1.0 To: Vince References: <472A6708.9030109@clearchain.com> <476152E9.3090707@unsane.co.uk> In-Reply-To: <476152E9.3090707@unsane.co.uk> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Thu, 13 Dec 2007 21:42:36 +0000 Cc: freebsd-current , Benjamin Close , freebsd-drivers@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: [RFT] Intel 3945abg wireless driver (wpi) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 21:39:04 -0000 Vince wrote: > Benjamin Close wrote: > Thanks for getting this driver going, I'm now using the version in 7.0, > Its working very well for me other than one (reasonably minor) thing, > which is that "ifconfig wpi0 scan" just sits there until I kill it. the > driver works in every other way, associates, works with WEP (havent > tried with WPA.) It will find and associate with a network if I just put > in "ifconfig wpi0 up" or if i use wpa_supplicant. I've had the same problem with ipw0 until my thinkpad burst into flames. A workaround is something like this: # ifconfig wpi0 up && sleep 3 && ifconfig wpi0 list scan On a sidenote, with RELENG_7 WPA finally started working for ipw on my system (which so shortly after the transition burst into flames). From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 03:47:56 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36DC216A511; Fri, 14 Dec 2007 03:47:56 +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 C309F13C448; Fri, 14 Dec 2007 03:47:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lBE3lq2i081726; Thu, 13 Dec 2007 22:47:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id lBE3lqQt009211; Thu, 13 Dec 2007 22:47:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4512973039; Thu, 13 Dec 2007 22:47:52 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071214034752.4512973039@freebsd-current.sentex.ca> Date: Thu, 13 Dec 2007 22:47:52 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 03:47:56 -0000 TB --- 2007-12-14 03:27:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-12-14 03:27:59 - starting HEAD tinderbox run for i386/i386 TB --- 2007-12-14 03:27:59 - cleaning the object tree TB --- 2007-12-14 03:28:31 - cvsupping the source tree TB --- 2007-12-14 03:28:31 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2007-12-14 03:28:37 - building world (CFLAGS=-O -pipe) TB --- 2007-12-14 03:28:37 - cd /src TB --- 2007-12-14 03:28:37 - /usr/bin/make -B buildworld >>> World build started on Fri Dec 14 03:28:38 UTC 2007 >>> 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 [...] cc -O -pipe -I/src/lib/msun/../libc/include -I/src/lib/msun/../libc/i386 -c /src/lib/msun/i387/s_scalbnl.S cc -O -pipe -I/src/lib/msun/../libc/include -I/src/lib/msun/../libc/i386 -c /src/lib/msun/i387/s_truncl.S building static m library ranlib libm.a cat /src/lib/msun/i387/Symbol.map /src/lib/msun/Symbol.map | cpp - - | awk -v vfile=/src/lib/msun/../libc/Versions.def -f /src/share/mk/version_gen.awk > Version.map File , line 83: Unknown directive: `carg'. File , line 84: Unknown directive: `cargf'. 2 error(s) total. *** Error code 1 Stop in /src/lib/msun. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-12-14 03:47:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-12-14 03:47:52 - ERROR: failed to build world TB --- 2007-12-14 03:47:52 - tinderbox aborted TB --- 866.58 user 109.49 system 1192.63 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 09:47:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43E4416A419 for ; Fri, 14 Dec 2007 09:47:55 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id F007013C4DB for ; Fri, 14 Dec 2007 09:47:54 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Message-ID:MIME-Version:Content-Type:Content-Disposition:Sender:X-Spam-Status:Subject; b=eXbsXuhWU+Hq47NPDemaZFDSwWJ5VXpIb4dj5gB3w4zUO5dAN8wSk3RVu8jx2HRSbvbnV4D2+r8/eOmcSzUh0+5dm4pA0ybnJHjbmQ0MYaKj4m0AAX08qEVTaUo97YqXqo3XVj/o5WLf3zKIx1ONI0aNJKLekZkmXA5ruO+CsWk=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1J3797-00076N-6V for freebsd-current@freebsd.org; Fri, 14 Dec 2007 12:47:53 +0300 Date: Fri, 14 Dec 2007 12:47:51 +0300 From: Eygene Ryabinkin To: freebsd-current@freebsd.org Message-ID: <7ExUpek150AdEdP4WR1b6w@lz+EvuNSgXKgs9kqjMxQNA> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Subject: [RFC] Automated generation of /etc/resolv.conf from the rc.d script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 09:47:55 -0000 Good day. I happened to use my notebook in the variety of the networks and some of them have no DHCP servers. So I had made my network settings in the /etc/rc.conf to be conditional. But there is one bit that I am missing with the current /etc/rc.d scripts: automated construction of /etc/resolv.conf basing on the variables from /etc/rc.conf. I know that just now I can achieve my needs by doing something like ----- rm -f /etc/resolv.conf kenv dhcp.domain-name-servers="IP1,IP2,IP3" kenv dhcp.domain-name="domain" ----- but the use of variables in /etc/rc.conf sounds a bit better to me. After all, dhcp.* values belong to the DHCP data, so playing with kenv looks like a hack. Below is the patch that adds two variables that are recognized by /etc/rc.d/resolv: resolv_domain and resolv_nameservers. If any of two has some value, then /etc/resolv.conf will be built from scratch. Values from kenv take higher precedence, so the default behaviour is not changed. Can this modification hit the tree, or it is completely unneeded, or it should be reworked? Any comments? The patch follows. ----- --- resolv.orig 2007-12-13 11:57:17.000000000 +0300 +++ resolv 2007-12-13 11:57:17.000000000 +0300 @@ -37,6 +37,23 @@ load_rc_config $name +# Helper that echoes the contents of the resolv.conf to the stdout. +# Arguments: +# 1. domain name, +# 2. list of name servers separated by ','. +# Either argument can be empty. If so, it won't be included to the output. + +build_resolv () { + if [ -n "$1" ]; then + echo domain "$1" > /etc/resolv.conf + fi + + set -- "$2" + for ns in `IFS=','; echo $*`; do + echo nameserver $ns >> /etc/resolv.conf; + done +} + # if the info is available via dhcp/kenv # build the resolv.conf # @@ -44,13 +61,13 @@ -n "`/bin/kenv dhcp.domain-name-servers 2> /dev/null`" ]; then > /etc/resolv.conf - if [ -n "`/bin/kenv dhcp.domain-name 2> /dev/null`" ]; then - echo domain `/bin/kenv dhcp.domain-name` > /etc/resolv.conf - fi + build_resolv \ + "`/bin/kenv dhcp.domain-name 2> /dev/null`" \ + "`/bin/kenv dhcp.domain-name-servers`" +elif [ -n "${resolv_domain}" -o -n "${resolv_nameservers}" ]; then + > /etc/resolv.conf - set -- `/bin/kenv dhcp.domain-name-servers` - for ns in `IFS=','; echo $*`; do - echo nameserver $ns >> /etc/resolv.conf; - done + build_resolv \ + "${resolv_domain}" "${resolv_nameservers}" fi ----- -- Eygene From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 09:55:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC30F16A418 for ; Fri, 14 Dec 2007 09:55:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A511313C4F4 for ; Fri, 14 Dec 2007 09:55:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0B51017105; Fri, 14 Dec 2007 09:55:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id lBE9tTWk072124; Fri, 14 Dec 2007 09:55:30 GMT (envelope-from phk@critter.freebsd.dk) To: Eygene Ryabinkin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 14 Dec 2007 12:47:51 +0300." <7ExUpek150AdEdP4WR1b6w@lz+EvuNSgXKgs9kqjMxQNA> Date: Fri, 14 Dec 2007 09:55:29 +0000 Message-ID: <72123.1197626129@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: [RFC] Automated generation of /etc/resolv.conf from the rc.d script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 09:55:30 -0000 In message <7ExUpek150AdEdP4WR1b6w@lz+EvuNSgXKgs9kqjMxQNA>, Eygene Ryabinkin writes: >But there is one bit that >I am missing with the current /etc/rc.d scripts: automated construction >of /etc/resolv.conf basing on the variables from /etc/rc.conf. It's worse than that. It should be possible to run a local named even when we run DHCP, and it shuld be an option, to have it automatically forward to the DNS servers we learn from DHCP. -- 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. From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 10:14:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 899E316A468 for ; Fri, 14 Dec 2007 10:14:43 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 445DC13C442 for ; Fri, 14 Dec 2007 10:14:43 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=pyVtuUz8ZbPrAn2yxKnM7kyYrIYNPb9B1VbCvtpEXBndQcnSROcjOobOCFfjfVxp0jgDRu4Rjmu7se9r8arV/OH5a+oe9yj1JimOdCdR6L4rwdSNuSxXUQEHLb//rAiRcpTgSa77fuLcKJMlRjzas0EsdxqrTgif4n/EB85DWG0=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1J37Z3-0007Gm-Tf; Fri, 14 Dec 2007 13:14:42 +0300 Date: Fri, 14 Dec 2007 13:14:40 +0300 From: Eygene Ryabinkin To: Poul-Henning Kamp Message-ID: References: <7ExUpek150AdEdP4WR1b6w@lz+EvuNSgXKgs9kqjMxQNA> <72123.1197626129@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <72123.1197626129@critter.freebsd.dk> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-current@freebsd.org Subject: Re: [RFC] Automated generation of /etc/resolv.conf from the rc.d script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 10:14:43 -0000 Poul-Henning, good day. Fri, Dec 14, 2007 at 09:55:29AM +0000, Poul-Henning Kamp wrote: > In message <7ExUpek150AdEdP4WR1b6w@lz+EvuNSgXKgs9kqjMxQNA>, Eygene Ryabinkin writes: > > >But there is one bit that > >I am missing with the current /etc/rc.d scripts: automated construction > >of /etc/resolv.conf basing on the variables from /etc/rc.conf. > > It's worse than that. > > It should be possible to run a local named even when we run DHCP, > and it shuld be an option, to have it automatically forward to the > DNS servers we learn from DHCP. This can be achieved with the script /etc/dhclient-exit-hooks that will create the file with named 'forwarders' clause using values from 'new_domain_name' and 'new_domain_name_servers' variables that are exported to the hooks script by /sbin/dhclient-script. The former file can be included from named.conf, so the restart or reload of the local named instance from the exit hooks script will do the trick. Did you meant that? -- Eygene From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 10:57:38 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D397E16A41A for ; Fri, 14 Dec 2007 10:57:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9B35413C455 for ; Fri, 14 Dec 2007 10:57:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2A27E17105; Fri, 14 Dec 2007 10:57:37 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id lBEAvcRZ072390; Fri, 14 Dec 2007 10:57:38 GMT (envelope-from phk@critter.freebsd.dk) To: Eygene Ryabinkin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 14 Dec 2007 13:14:40 +0300." Date: Fri, 14 Dec 2007 10:57:38 +0000 Message-ID: <72389.1197629858@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: [RFC] Automated generation of /etc/resolv.conf from the rc.d script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 10:57:38 -0000 In message , Eygene Ryabinkin writes: >> It's worse than that. >> >> It should be possible to run a local named even when we run DHCP, >> and it shuld be an option, to have it automatically forward to the >> DNS servers we learn from DHCP. > >This can be achieved with the script /etc/dhclient-exit-hooks that >will create the file with named 'forwarders' clause [...] Yes, I know that, but I would like to see it controllable from rc.conf like the rest of our network configuration. -- 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. From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 10:59:07 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD92416A418 for ; Fri, 14 Dec 2007 10:59:07 +0000 (UTC) (envelope-from leo_midolo@yahoo.it) Received: from smtp010.mail.ukl.yahoo.com (smtp010.mail.ukl.yahoo.com [217.12.11.79]) by mx1.freebsd.org (Postfix) with SMTP id 40FDD13C457 for ; Fri, 14 Dec 2007 10:59:06 +0000 (UTC) (envelope-from leo_midolo@yahoo.it) Received: (qmail 56719 invoked from network); 14 Dec 2007 10:59:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.it; h=Received:X-YMail-OSG:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-Id:Mime-Version:X-Mailer:Content-Transfer-Encoding; b=m+b2HZY6Ua20X6Lwm9jSwUr4/QC7evy6al8jZeSGUgBXkQ3JU2YwgXydKetjHZVXzH4FzrIzZEuTQRDFtLKy5NTzdnmRRXpTaSVVSUpWMapDHWt+nGy7OjmlcLwmTfOrPQk4E4AXUG2nDcQM5JTehR9No5dZ3eiWw5y6JuZb9Xw= ; Received: from unknown (HELO ?192.168.0.6?) (leo_midolo@87.5.214.193 with plain) by smtp010.mail.ukl.yahoo.com with SMTP; 14 Dec 2007 10:59:04 -0000 X-YMail-OSG: qTFrnXYVM1nefdIpjxPw3o1Vi8pbaWW9KepspQwowegTk9mFxAszLfJcA5V1rlLNlPMmU_rlcsb.nc2Bu40hTFs98DXtw5qi2vJ7L7luAM0ZWRF1TYaFzcdW.Og- From: Leonardo Midolo To: Weongyo Jeong In-Reply-To: <20071213070051.GA52728@freebsd.weongyo.org> References: <1196593676.6051.19.camel@leo-laptop.homeunix.net> <20071213070051.GA52728@freebsd.weongyo.org> Content-Type: text/plain Date: Fri, 14 Dec 2007 11:59:03 +0100 Message-Id: <1197629943.6054.5.camel@leo-laptop.homeunix.net> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Panic 7.0 BETA-3 (page fault) using D-Link DWL-G122 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 10:59:07 -0000 Thanks for your reply, I downloaded the if_rum.c rev 1.15 and recompiled the kernel (BETA-3, 2 dec). I still get a page fault: (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0752e37 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc07530f9 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a1852c in trap_fatal (frame=0xe296cb78, eva=4) at /usr/src/sys/i386/i386/trap.c:872 #4 0xc0a18790 in trap_pfault (frame=0xe296cb78, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:785 #5 0xc0a190e2 in trap (frame=0xe296cb78) at /usr/src/sys/i386/i386/trap.c:463 #6 0xc09ffafb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0811f72 in ieee80211_free_node (ni=0x0) at /usr/src/sys/net80211/ieee80211_node.c:1289 #8 0xc06b984d in rum_txeof (xfer=0xc43d1200, priv=0xc40a7498, status=USBD_NORMAL_COMPLETION) at /usr/src/sys/dev/usb/if_rum.c:861 #9 0xc06d2fd5 in usb_transfer_complete (xfer=0xc43d1200) at /usr/src/sys/dev/usb/usbdi.c:977 #10 0xc06a5ba1 in ehci_softintr (v=0xc3fe5800) at /usr/src/sys/dev/usb/ehci.c:884 #11 0xc06ceb82 in usb_schedsoftintr (bus=0xc3fe5800) at /usr/src/sys/dev/usb/usb.c:844 #12 0xc06a737e in ehci_intr1 (sc=0xc3fe5800) at /usr/src/sys/dev/usb/ehci.c:603 #13 0xc06a7db5 in ehci_intr (v=0xc3fe5800) at /usr/src/sys/dev/usb/ehci.c:562 #14 0xc07366fb in ithread_loop (arg=0xc4057b00) at /usr/src/sys/kern/kern_intr.c:1036 #15 0xc0733639 in fork_exit (callout=0xc0736550 , arg=0xc4057b00, frame=0xe296cd38) at /usr/src/sys/kern/kern_fork.c:754 #16 0xc09ffb70 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 Thanks, best regards. Leonardo Midolo > Hello Leonardo, > > I think your problem is a known issue and commited a fix to HEAD. Can > you try to test the rum(4) HEAD driver? > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/if_rum.c > (rev 1.15) > > Regards, > Weongyo Jeong > > On Sun, Dec 02, 2007 at 12:07:56PM +0100, Leonardo Midolo wrote: > > Hello everyone > > I'm tracking RELENG_7 (i386, SCHED_SMP, last build: today, 2 dec) on my > > laptop (core 2 duo) and I've recently bought an usb wireless adapter > > (D-Link DWL-G122 rev C1). > > Everything works properly (i can connect to the access point using WPA > > and do normal network activities) but sometimes (I must say, randomly) I > > get a kernel panic. > > > > Here's the debug info, hope it helps: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 1; apic id = 01 > > fault virtual address = 0x12 > > fault code = supervisor read, page not present > > instruction pointer = 0x20:0xc06b976a > > stack pointer = 0x28:0xe296cbe4 > > frame pointer = 0x28:0xe296cbfc > > 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 = 24 (irq23: uhci0 ehci0) > > trap number = 12 > > panic: page fault > > cpuid = 1 > > Uptime: 3m44s > > Physical memory: 1009 MB > > Dumping 107 MB: 92 76 60 44 28 12 > > > > Backtrace > > #0 doadump () at pcpu.h:195 > > #1 0xc0752e07 in boot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:409 > > #2 0xc07530c9 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:563 > > #3 0xc0a184fc in trap_fatal (frame=0xe296cba4, eva=18) > > at /usr/src/sys/i386/i386/trap.c:872 > > #4 0xc0a18760 in trap_pfault (frame=0xe296cba4, usermode=0, eva=18) > > at /usr/src/sys/i386/i386/trap.c:785 > > #5 0xc0a190b2 in trap (frame=0xe296cba4) > > at /usr/src/sys/i386/i386/trap.c:463 > > #6 0xc09ffacb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > #7 0xc06b976a in rum_txeof (xfer=0xc4343800, priv=0xc40a7498, > > status=USBD_NORMAL_COMPLETION) at /usr/src/sys/dev/usb/if_rum.c:842 > > #8 0xc06d2fa5 in usb_transfer_complete (xfer=0xc4343800) > > at /usr/src/sys/dev/usb/usbdi.c:977 > > #9 0xc06a5ba1 in ehci_softintr (v=0xc3fe5800) > > at /usr/src/sys/dev/usb/ehci.c:884 > > #10 0xc06ceb52 in usb_schedsoftintr (bus=0xc3fe5800) > > at /usr/src/sys/dev/usb/usb.c:844 > > #11 0xc06a737e in ehci_intr1 (sc=0xc3fe5800) > > at /usr/src/sys/dev/usb/ehci.c:603 > > #12 0xc06a7db5 in ehci_intr (v=0xc3fe5800) > > at /usr/src/sys/dev/usb/ehci.c:562 > > #13 0xc07366cb in ithread_loop (arg=0xc4057b00) > > at /usr/src/sys/kern/kern_intr.c:1036 > > #14 0xc0733609 in fork_exit (callout=0xc0736520 , > > arg=0xc4057b00, frame=0xe296cd38) > > at /usr/src/sys/kern/kern_fork.c:754 > > #15 0xc09ffb40 in fork_trampoline () > > at /usr/src/sys/i386/i386/exception.s:205 > > > > Thanks, > > Leonardo > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 11:07:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3555316A418 for ; Fri, 14 Dec 2007 11:07:04 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id E552A13C455 for ; Fri, 14 Dec 2007 11:07:03 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=Ehp/vFZOKXoqPTZanKca+1RuZij8Vaimb3CK8Ca+KDPZ44/PZED6YA4Y99TtoSYz934U1SelGSxVrTW5woZE2vaDPVkHFTZ6UPE0lsoUMTPumHBvZJx7NcmMspit1R15mXUWLTN+Jg/YCpZs7ZZLxlQ09XQ7rt9BiUqyhSoDRxA=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1J38Nh-0007Zi-SO; Fri, 14 Dec 2007 14:07:02 +0300 Date: Fri, 14 Dec 2007 14:07:00 +0300 From: Eygene Ryabinkin To: Poul-Henning Kamp Message-ID: References: <72389.1197629858@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <72389.1197629858@critter.freebsd.dk> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-current@freebsd.org Subject: Re: [RFC] Automated generation of /etc/resolv.conf from the rc.d script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 11:07:04 -0000 Fri, Dec 14, 2007 at 10:57:38AM +0000, Poul-Henning Kamp wrote: > In message , Eygene Ryabinkin writes: > >> It should be possible to run a local named even when we run DHCP, > >> and it shuld be an option, to have it automatically forward to the > >> DNS servers we learn from DHCP. > > > >This can be achieved with the script /etc/dhclient-exit-hooks that > >will create the file with named 'forwarders' clause [...] > > Yes, I know that, but I would like to see it controllable from rc.conf > like the rest of our network configuration. OK, since running local DNS instance is a neat idea, I will try to draft the modifications for the dhclient-exit-hooks, as I described in the previous mail. Just now I see no other way to implement it, because dhclient is asynchronious in the general case, so I can not teach /etc/rc.d/dhclient to do the job. So I expect that /etc/dhclient-exit-hooks will be born and it will build 'forwarders' file for the named, if this will be requested by /etc/rc.conf. I still not sure how to modify named.conf: automatically or let the user make the needed modifications. I am inclined to the latter, but this can pose some troubles to the users that are not very familiar with named.conf. Any thoughts? If you have other ideas how it can be done, please share. Thanks! -- Eygene From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 11:57:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A81416A421 for ; Fri, 14 Dec 2007 11:57:48 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.de [194.25.134.84]) by mx1.freebsd.org (Postfix) with ESMTP id 2F17213C46B for ; Fri, 14 Dec 2007 11:57:47 +0000 (UTC) (envelope-from oliver@akephalos.de) Received: from fwd27.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1J38lF-0008Rf-00; Fri, 14 Dec 2007 12:31:21 +0100 Received: from localhost (VgsFUGZcot9DJe9XlJIETMwH1G0xSWQ0VyVs1Mczu96aXzoE92Ai8nJaQ0lvLQEFTq8Ydm+Nub@[91.21.94.141]) by fwd27.t-online.de with esmtp id 1J38kZ-22EY080; Fri, 14 Dec 2007 12:30:39 +0100 Date: Fri, 14 Dec 2007 12:30:39 +0100 From: Oliver Herold To: freebsd-current@freebsd.org Message-ID: <20071214113039.GA3929@olymp.home> Mail-Followup-To: freebsd-current@freebsd.org References: <1196593676.6051.19.camel@leo-laptop.homeunix.net> <20071213070051.GA52728@freebsd.weongyo.org> <1197629943.6054.5.camel@leo-laptop.homeunix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1197629943.6054.5.camel@leo-laptop.homeunix.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-ID: VgsFUGZcot9DJe9XlJIETMwH1G0xSWQ0VyVs1Mczu96aXzoE92Ai8nJaQ0lvLQEFTq8Ydm+Nub X-TOI-MSGID: a5199a01-55c9-40a2-84f2-aaaf2b37457b Subject: Re: Panic 7.0 BETA-3 (page fault) using D-Link DWL-G122 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 11:57:48 -0000 Hi, it just happens, imho, if I'm using WPA. While using WEP there is no panic at all. Together with WPA it happens afters some minutes with or without network traffic. Cheers, Oliver On Fri, Dec 14, 2007 at 11:59:03AM +0100, Leonardo Midolo wrote: > Thanks for your reply, > I downloaded the if_rum.c rev 1.15 and recompiled the kernel (BETA-3, 2 > dec). I still get a page fault: > > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc0752e37 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc07530f9 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc0a1852c in trap_fatal (frame=0xe296cb78, eva=4) > at /usr/src/sys/i386/i386/trap.c:872 > #4 0xc0a18790 in trap_pfault (frame=0xe296cb78, usermode=0, eva=4) > at /usr/src/sys/i386/i386/trap.c:785 > #5 0xc0a190e2 in trap (frame=0xe296cb78) > at /usr/src/sys/i386/i386/trap.c:463 > #6 0xc09ffafb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc0811f72 in ieee80211_free_node (ni=0x0) > at /usr/src/sys/net80211/ieee80211_node.c:1289 > #8 0xc06b984d in rum_txeof (xfer=0xc43d1200, priv=0xc40a7498, > status=USBD_NORMAL_COMPLETION) at /usr/src/sys/dev/usb/if_rum.c:861 > #9 0xc06d2fd5 in usb_transfer_complete (xfer=0xc43d1200) > at /usr/src/sys/dev/usb/usbdi.c:977 > #10 0xc06a5ba1 in ehci_softintr (v=0xc3fe5800) > at /usr/src/sys/dev/usb/ehci.c:884 > #11 0xc06ceb82 in usb_schedsoftintr (bus=0xc3fe5800) > at /usr/src/sys/dev/usb/usb.c:844 > #12 0xc06a737e in ehci_intr1 (sc=0xc3fe5800) > at /usr/src/sys/dev/usb/ehci.c:603 > #13 0xc06a7db5 in ehci_intr (v=0xc3fe5800) > at /usr/src/sys/dev/usb/ehci.c:562 > #14 0xc07366fb in ithread_loop (arg=0xc4057b00) > at /usr/src/sys/kern/kern_intr.c:1036 > #15 0xc0733639 in fork_exit (callout=0xc0736550 , > arg=0xc4057b00, frame=0xe296cd38) > at /usr/src/sys/kern/kern_fork.c:754 > #16 0xc09ffb70 in fork_trampoline () > at /usr/src/sys/i386/i386/exception.s:205 > > Thanks, > best regards. > > Leonardo Midolo > > > > Hello Leonardo, > > > > I think your problem is a known issue and commited a fix to HEAD. Can > > you try to test the rum(4) HEAD driver? > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/if_rum.c > > (rev 1.15) > > > > Regards, > > Weongyo Jeong > > > > On Sun, Dec 02, 2007 at 12:07:56PM +0100, Leonardo Midolo wrote: > > > Hello everyone > > > I'm tracking RELENG_7 (i386, SCHED_SMP, last build: today, 2 dec) on my > > > laptop (core 2 duo) and I've recently bought an usb wireless adapter > > > (D-Link DWL-G122 rev C1). > > > Everything works properly (i can connect to the access point using WPA > > > and do normal network activities) but sometimes (I must say, randomly) I > > > get a kernel panic. > > > > > > Here's the debug info, hope it helps: > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 1; apic id = 01 > > > fault virtual address = 0x12 > > > fault code = supervisor read, page not present > > > instruction pointer = 0x20:0xc06b976a > > > stack pointer = 0x28:0xe296cbe4 > > > frame pointer = 0x28:0xe296cbfc > > > 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 = 24 (irq23: uhci0 ehci0) > > > trap number = 12 > > > panic: page fault > > > cpuid = 1 > > > Uptime: 3m44s > > > Physical memory: 1009 MB > > > Dumping 107 MB: 92 76 60 44 28 12 > > > > > > Backtrace > > > #0 doadump () at pcpu.h:195 > > > #1 0xc0752e07 in boot (howto=260) > > > at /usr/src/sys/kern/kern_shutdown.c:409 > > > #2 0xc07530c9 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:563 > > > #3 0xc0a184fc in trap_fatal (frame=0xe296cba4, eva=18) > > > at /usr/src/sys/i386/i386/trap.c:872 > > > #4 0xc0a18760 in trap_pfault (frame=0xe296cba4, usermode=0, eva=18) > > > at /usr/src/sys/i386/i386/trap.c:785 > > > #5 0xc0a190b2 in trap (frame=0xe296cba4) > > > at /usr/src/sys/i386/i386/trap.c:463 > > > #6 0xc09ffacb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > > #7 0xc06b976a in rum_txeof (xfer=0xc4343800, priv=0xc40a7498, > > > status=USBD_NORMAL_COMPLETION) at /usr/src/sys/dev/usb/if_rum.c:842 > > > #8 0xc06d2fa5 in usb_transfer_complete (xfer=0xc4343800) > > > at /usr/src/sys/dev/usb/usbdi.c:977 > > > #9 0xc06a5ba1 in ehci_softintr (v=0xc3fe5800) > > > at /usr/src/sys/dev/usb/ehci.c:884 > > > #10 0xc06ceb52 in usb_schedsoftintr (bus=0xc3fe5800) > > > at /usr/src/sys/dev/usb/usb.c:844 > > > #11 0xc06a737e in ehci_intr1 (sc=0xc3fe5800) > > > at /usr/src/sys/dev/usb/ehci.c:603 > > > #12 0xc06a7db5 in ehci_intr (v=0xc3fe5800) > > > at /usr/src/sys/dev/usb/ehci.c:562 > > > #13 0xc07366cb in ithread_loop (arg=0xc4057b00) > > > at /usr/src/sys/kern/kern_intr.c:1036 > > > #14 0xc0733609 in fork_exit (callout=0xc0736520 , > > > arg=0xc4057b00, frame=0xe296cd38) > > > at /usr/src/sys/kern/kern_fork.c:754 > > > #15 0xc09ffb40 in fork_trampoline () > > > at /usr/src/sys/i386/i386/exception.s:205 > > > > > > Thanks, > > > Leonardo > > > > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- If you fool around with something long enough, it will eventually break. From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 12:01:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C360C16A420 for ; Fri, 14 Dec 2007 12:01:47 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:1f1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 54A8413C45D for ; Fri, 14 Dec 2007 12:01:47 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from prawn.unsane.co.uk (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id lBEC1WPC042478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Dec 2007 12:01:33 GMT (envelope-from jhary@unsane.co.uk) Message-ID: <476270A6.4050805@unsane.co.uk> Date: Fri, 14 Dec 2007 12:01:42 +0000 From: Vince User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Little bit of a gotcha for zfs with gjournal. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 12:01:47 -0000 This is more for the archives than anything else. I have my home server build as a gmirror / and zfs for the rest, I was having regular kmem_map too small panics when building port even after putting in the various zfs tuning suggestions. I was thinking I must have a hardware issue or something weirder as the issue appeared after I added WRKDIRPREFIX= pointing to a new disk that wasnt on the zfs mirror (formatted ufs2 with gjournal) after i managed to panic the box building openoffice on the zfs (hadnt managed to panic it in a few months prior to that.) The problem I was having I finally managed to track down (I believe) to the fact that the default value of kern.geom.journal.cache.limit was high enough that when I started the build of the jdk15 port I was hitting the kmem limit by the combined efforts of zfs and gjournal. fixed by taking the value of kern.geom.journal.cache.limit down. Panic String: kmem_malloc(131072): kmem_map too small: 388349952 total allocated Like I said not a bug, more a tuning hint. Hope someone finds this useful although I cant see it being a common configuration. Vince From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 12:17:56 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE78816A418 for ; Fri, 14 Dec 2007 12:17:56 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 8AB8A13C4E3 for ; Fri, 14 Dec 2007 12:17:56 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from [127.0.0.1] (fw.axelero.hu [195.228.243.120]) by people.fsn.hu (Postfix) with ESMTP id 5D70610DB2A for ; Fri, 14 Dec 2007 13:17:43 +0100 (CET) Message-ID: <47627451.5040508@fsn.hu> Date: Fri, 14 Dec 2007 13:17:21 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: current@FreeBSD.org References: <474ECB7E.5090707@fsn.hu> In-Reply-To: <474ECB7E.5090707@fsn.hu> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: MySQL cluster ndb_mgmd problems on FreeBSD 7.x - libkse works, libthr doesn't X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 12:17:56 -0000 On 2007.11.29. 15:23, Attila Nagy wrote: > So: with an ndb_mgmd built on 6.x and ran on 7.x the whole stack > works, with the same binary, but built and ran on 7.x it does not (the > NDB management client is unusable and the MySQL daemon can't connect > too). I could find the time to play with it a little. It seems that switching the threading libraries make this (ndb_mgmd) fail. If I build libkse and link ndb_mgmd against that, the application works wonderfully. If I try to use it with libthr, it doesn't. See http://bugs.mysql.com/bug.php?id=32896 about it. Any ideas about what is broken here? (the application, which works with libkse, but not with libthr, or libthr itself) Thanks, From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 12:50:08 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6321F16A41A for ; Fri, 14 Dec 2007 12:50:08 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 284EA13C455 for ; Fri, 14 Dec 2007 12:50:08 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id D326420A0; Fri, 14 Dec 2007 13:49:59 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id BB7442099; Fri, 14 Dec 2007 13:49:59 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 986DE8449A; Fri, 14 Dec 2007 13:49:59 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Aryeh Friedman" References: Date: Fri, 14 Dec 2007 13:49:59 +0100 In-Reply-To: (Aryeh Friedman's message of "Sun\, 9 Dec 2007 08\:45\:58 -0500") Message-ID: <86mysdxwy0.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: does this warrent a PR? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 12:50:08 -0000 "Aryeh Friedman" writes: > First of all I know this deals with a port but the problem only > appears on -current so I am asking here. > > devel/libtool15 does not correctly install (it places freebsd- as the > version number for all libs) It installs and works just fine. You are probably using it wrong. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 12:57:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0452516A419 for ; Fri, 14 Dec 2007 12:57:27 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id BAEA913C447 for ; Fri, 14 Dec 2007 12:57:26 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 3A0B520B1; Fri, 14 Dec 2007 13:57:18 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id A175A2099; Fri, 14 Dec 2007 13:57:17 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 723F384492; Fri, 14 Dec 2007 13:57:17 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: David Duchscher References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> Date: Fri, 14 Dec 2007 13:57:17 +0100 In-Reply-To: <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> (David Duchscher's message of "Thu\, 13 Dec 2007 07\:59\:35 -0600") Message-ID: <86ir31xwlu.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Benjamin Close , Hugo Silva Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 12:57:27 -0000 David Duchscher writes: > So does anybody know of a battery backed NVRAM card that can be used > with FreeBSD that the ZIL could be offloaded to? Any CF card or similar will do. You don't need battery backup for flash memory. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 13:09:00 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D64BF16A419 for ; Fri, 14 Dec 2007 13:09:00 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2001:618:400::50b1:e8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 62FD113C46B for ; Fri, 14 Dec 2007 13:09:00 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [80.177.232.250] (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id lBED8Ktp081211; Fri, 14 Dec 2007 13:08:20 GMT (envelope-from dfr@rabson.org) From: Doug Rabson To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <86ir31xwlu.fsf@ds4.des.no> References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 14 Dec 2007 13:08:20 +0000 Message-Id: <1197637700.1250.35.camel@herring.rabson.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.87.1/5117/Fri Dec 14 11:59:16 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: David Duchscher , freebsd-current@freebsd.org, Benjamin Close , Hugo Silva Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 13:09:00 -0000 On Fri, 2007-12-14 at 13:57 +0100, Dag-Erling Smørgrav wrote: > David Duchscher writes: > > So does anybody know of a battery backed NVRAM card that can be used > > with FreeBSD that the ZIL could be offloaded to? > > Any CF card or similar will do. You don't need battery backup for > flash memory. THis may also have to wait for a future version of ZFS. I remember reading about this kind of thing as an upcoming feature in Solaris. I believe the way this feature would work is that ZFS would allow creating the ZIL on a different pool to the filesystem - i.e. create a zpool on the CF card and get the ZIL to live there. From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 13:25:19 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA22416A420 for ; Fri, 14 Dec 2007 13:25:19 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 78F1F13C455 for ; Fri, 14 Dec 2007 13:25:18 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 5C3DC20B1; Fri, 14 Dec 2007 14:25:10 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 3D67020AF; Fri, 14 Dec 2007 14:25:10 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 0F13D844A7; Fri, 14 Dec 2007 14:25:10 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Doug Rabson References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> <1197637700.1250.35.camel@herring.rabson.org> Date: Fri, 14 Dec 2007 14:25:10 +0100 In-Reply-To: <1197637700.1250.35.camel@herring.rabson.org> (Doug Rabson's message of "Fri\, 14 Dec 2007 13\:08\:20 +0000") Message-ID: <86abodxvbd.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: David Duchscher , freebsd-current@freebsd.org, Benjamin Close , Hugo Silva Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 13:25:19 -0000 Doug Rabson writes: > Dag-Erling Sm=C3=B8rgrav writes: > > David Duchscher writes: > > > So does anybody know of a battery backed NVRAM card that can be used > > > with FreeBSD that the ZIL could be offloaded to? > > Any CF card or similar will do. You don't need battery backup for > > flash memory. > > THis may also have to wait for a future version of ZFS. I remember > reading about this kind of thing as an upcoming feature in Solaris. I > believe the way this feature would work is that ZFS would allow creating > the ZIL on a different pool to the filesystem - i.e. create a zpool on > the CF card and get the ZIL to live there. AFAIK this is already implemented in ZFS, though I'm not sure Pawel has merged it into FreeBSD yet. Note that you can also get disk drives with a certain amount of NAND flash built-in, but FreeBSD doesn't support that yet. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 13:46:35 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FAAD16A419 for ; Fri, 14 Dec 2007 13:46:35 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.freebsd.org (Postfix) with ESMTP id 8E42313C45A for ; Fri, 14 Dec 2007 13:46:34 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (qmail 51019 invoked by uid 89); 14 Dec 2007 13:46:32 -0000 Received: by simscan 1.1.0 ppid: 51003, pid: 51015, t: 3.5539s scanners: attach: 1.1.0 clamav: 0.88.7/m:44/d:4673 spam: 3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on bsd.ultra-secure.de X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from unknown (HELO ?212.71.117.70?) (rainer@ultra-secure.de@212.71.117.70) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Dec 2007 13:46:29 -0000 Message-ID: <47628934.6000007@ultra-secure.de> Date: Fri, 14 Dec 2007 14:46:28 +0100 From: Rainer Duffner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20060911 SUSE/1.5.0.12-3.4 Thunderbird/1.5.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> <1197637700.1250.35.camel@herring.rabson.org> <86abodxvbd.fsf@ds4.des.no> In-Reply-To: <86abodxvbd.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 13:46:35 -0000 Dag-Erling SmÞrgrav wrote: > > Note that you can also get disk drives with a certain amount of NAND > flash built-in, but FreeBSD doesn't support that yet. > > They are intended for use with Vista - and have recently been found to be marginally more effective than a placebo (for Vista-performance). The speed-gains are barely distinguishable from measurement-errors... So, if the drives would help ZFS, it would be a big irony. There are companies that manufacture "pure" SSDs (www.superssd.com, www.soliddata.com) with battery-backup. Unfortunately, the price-tag of these systems is still beyond reach for normal customers. cheers, Rainer From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 14:07:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DC5716A418 for ; Fri, 14 Dec 2007 14:07:24 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id F2C4013C467 for ; Fri, 14 Dec 2007 14:07:23 +0000 (UTC) (envelope-from kvs@binarysolutions.dk) Received: from coruscant.binarysolutions.dk (naboo.binarysolutions.dk [80.196.17.173]) by solow.pil.dk (Postfix) with ESMTP id 8E97D1CC22F for ; Fri, 14 Dec 2007 14:47:29 +0100 (CET) Received: by coruscant.binarysolutions.dk (Postfix, from userid 502) id 34B6B91F98C; Fri, 14 Dec 2007 14:47:29 +0100 (CET) From: Kenneth Vestergaard Schmidt To: freebsd-current@freebsd.org References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> <1197637700.1250.35.camel@herring.rabson.org> <86abodxvbd.fsf@ds4.des.no> Date: Fri, 14 Dec 2007 14:47:29 +0100 In-Reply-To: <86abodxvbd.fsf@ds4.des.no> ("Dag-Erling =?iso-8859-1?Q?Sm=F8?= =?iso-8859-1?Q?rgrav=22's?= message of "Fri, 14 Dec 2007 14:25:10 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 14:07:24 -0000 Dag-Erling Sm=F8rgrav writes: > Doug Rabson writes: >> Dag-Erling Sm=F8rgrav writes: >> > David Duchscher writes: >> > > So does anybody know of a battery backed NVRAM card that can be used >> > > with FreeBSD that the ZIL could be offloaded to? >> > Any CF card or similar will do. You don't need battery backup for >> > flash memory. >> >> THis may also have to wait for a future version of ZFS. I remember >> reading about this kind of thing as an upcoming feature in Solaris. I >> believe the way this feature would work is that ZFS would allow creating >> the ZIL on a different pool to the filesystem - i.e. create a zpool on >> the CF card and get the ZIL to live there. > > AFAIK this is already implemented in ZFS, though I'm not sure Pawel has > merged it into FreeBSD yet. http://www.opensolaris.org/os/community/zfs/version/7/ You simply add a 'log' vdev to a pool. It's included in snv_75, maybe earlier. /Kenneth From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 14:24:44 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92CCA16A419 for ; Fri, 14 Dec 2007 14:24:44 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 0E1A013C447 for ; Fri, 14 Dec 2007 14:24:43 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from [127.0.0.1] (kevlo.org [220.128.136.52]) (authenticated bits=0) by ns.kevlo.org (8.14.1/8.14.1) with ESMTP id lBEDqaMk010235; Fri, 14 Dec 2007 21:52:42 +0800 (CST) (envelope-from kevlo@kevlo.org) From: Kevin Lo To: Leonardo Midolo In-Reply-To: <1197629943.6054.5.camel@leo-laptop.homeunix.net> References: <1196593676.6051.19.camel@leo-laptop.homeunix.net> <20071213070051.GA52728@freebsd.weongyo.org> <1197629943.6054.5.camel@leo-laptop.homeunix.net> Content-Type: multipart/mixed; boundary="=-vxePk/qQXnAban4Tt0vf" Date: Fri, 14 Dec 2007 21:53:12 +0800 Message-Id: <1197640392.6307.3.camel@monet> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Cc: freebsd-current@freebsd.org Subject: Re: Panic 7.0 BETA-3 (page fault) using D-Link DWL-G122 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 14:24:44 -0000 --=-vxePk/qQXnAban4Tt0vf Content-Type: text/plain Content-Transfer-Encoding: 7bit Leonardo Midolo wrote: > Thanks for your reply, > I downloaded the if_rum.c rev 1.15 and recompiled the kernel (BETA-3, 2 > dec). I still get a page fault: Please try attached patch, thanks. > Thanks, > best regards. > > Leonardo Midolo Kevin --=-vxePk/qQXnAban4Tt0vf Content-Disposition: attachment; filename=patch-if_rum.c Content-Type: text/x-patch; name=patch-if_rum.c; charset=UTF-8 Content-Transfer-Encoding: 7bit --- if_rum.c.orig 2007-12-14 21:37:20.000000000 +0800 +++ if_rum.c 2007-12-14 21:45:46.000000000 +0800 @@ -839,6 +839,9 @@ struct rum_softc *sc = data->sc; struct ifnet *ifp = sc->sc_ic.ic_ifp; + if (!priv) + return; + if (data->m != NULL && data->m->m_flags & M_TXCB) ieee80211_process_callback(data->ni, data->m, 0/*XXX*/); --=-vxePk/qQXnAban4Tt0vf-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 15:11:27 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0307E16A419 for ; Fri, 14 Dec 2007 15:11:27 +0000 (UTC) (envelope-from m.rebele@web.de) Received: from fmmailgate01.web.de (fmmailgate01.web.de [217.72.192.221]) by mx1.freebsd.org (Postfix) with ESMTP id 8CE1313C4CC for ; Fri, 14 Dec 2007 15:11:26 +0000 (UTC) (envelope-from m.rebele@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate01.web.de (Postfix) with ESMTP id 31ADEBCA57BB for ; Fri, 14 Dec 2007 16:08:30 +0100 (CET) Received: from [194.94.240.61] (helo=[10.100.2.35]) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.108 #208) id 1J3C9O-0006dT-00 for freebsd-current@freebsd.org; Fri, 14 Dec 2007 16:08:30 +0100 Message-ID: <47629C63.7010204@web.de> Date: Fri, 14 Dec 2007 16:08:19 +0100 From: Michael Rebele User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: m.rebele@web.de X-Sender: m.rebele@web.de X-Provags-ID: V01U2FsdGVkX19GJpJEJ1UEGET1veEhSsoDz4qgtk4FHgXeJWmz BIpsMHjzr8XmVNBlkbf7p0H9QHJYLC8vv90NR4ErYlyHT5HHZG O0jBVG8Rc= Subject: Re: 7.0-Beta 3: zfs makes system reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: m.rebele@web.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 15:11:27 -0000 Hello, replying my own message is a funny thing ;-) This message has more informational character than it is a error report. > Michael Rebele wrote: > Von: m.rebele@web.de > Gesendet: 03.12.07 15:54:59 > An: freebsd-current@freebsd.org > Betreff: Re: 7.0-Beta 3: zfs makes system reboot > > Alexandre Biancalana wrote: > > On Nov 30, 2007 2:27 PM, Michael Rebele wrote: > >> 4. The applied kernel settings > >> kern.maxvnodes="400000" > >> vm.kmem_size_max="512M" > >> vm.kmem_size="512M" > >> > >> 5. Output from zpool > >> [root@zfs /root]# zpool status > >> pool: tank > >> state: ONLINE > >> scrub: none requested > >> config: > >> > >> NAME STATE READ WRITE CKSUM > >> tank ONLINE 0 0 0 > >> ad4s1g ONLINE 0 0 0 > >> > >> errors: No known data errors > >> > >> [kmem_map too small error] > > > > Have you tried this patch > > http://people.freebsd.org/~pjd/patches/vm_kern.c.2.patch ? > I've applied the mentioned patch to the Beta3. Now the iozone-Benchmark runs through. Fine - be warned, on my machine it took about 30 hours (a 3GHz DualCore and a 160GB SATA HD w. 10000rpm). After the first successful run on a ZFS since my first try i tried the next step. Three parallel iozone (for your reference, here's again the setup: iozone -R -a -z -b filez-512M.wks -g 4G -f testile) runs on the mentioned machine. Nearly 5 days everything went fine, but then the system made a reboot. Unfortunately there's no log and the reboot happened in the night. Though, i don't really know the reason for this. I guess, the kmem_map error is the cause, because the symptoms are the same as on the BETA3-system before the applied patch. The last output i have from the benchmark, showed that the file size were in the 4GB area with a reclen in the 8192 area (well, short before iozone should finish). The problem is to track down the stuff, as it may took quite long until the error occurs - or lets say it better, even on a quite fast machine, iozone is quite slow. But the problem is not the CPU, it's the HD. Maybe somebody with access to a fast HD-Array can investigate this again. My conclusions to my tests: 1. You should really apply the mentioned patch if you plan to use ZFS on your Box for more than just testing and experimenting (well, ZFS is marked as that, though - you're warned). The memory/kernel parameter tuning recommendations helped me not really. 2. With the applied patch, ZFS seems quite robust for the average use. Maybe, there's a problem with a bigger load under some (rare?) circumstances. 3. The patch should find his way to the 'regular' kernel sources (or is it even in BETA4?). A big thanks to Pawel Jakub Dawidek for his great job. Michael -- Die Erde ist die Irrenanstalt des Universums. Public Key: http://sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0x5D0A2BC3CEB 3F472 From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 15:21:43 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11AB016A419 for ; Fri, 14 Dec 2007 15:21:43 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from sr-7-int.cis.tamu.edu (smtp-relay.tamu.edu [165.91.22.120]) by mx1.freebsd.org (Postfix) with ESMTP id B821D13C46B for ; Fri, 14 Dec 2007 15:21:42 +0000 (UTC) (envelope-from daved@tamu.edu) Received: from localhost (localhost.tamu.edu [127.0.0.1]) by sr-7-int.cis.tamu.edu (Postfix) with ESMTP id F2A0855CCF; Fri, 14 Dec 2007 09:21:41 -0600 (CST) Received: from [192.168.1.46] (pool-71-113-249-98.herntx.dsl-w.verizon.net [71.113.249.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sr-7-int.cis.tamu.edu (Postfix) with ESMTP id 6B0DE55D18; Fri, 14 Dec 2007 09:21:38 -0600 (CST) In-Reply-To: <86ir31xwlu.fsf@ds4.des.no> References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-295164636; protocol="application/pkcs7-signature" Message-Id: From: David Duchscher Date: Fri, 14 Dec 2007 09:21:32 -0600 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: amavisd-new at tamu.edu X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Benjamin Close , Hugo Silva Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 15:21:43 -0000 --Apple-Mail-1-295164636 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On Dec 14, 2007, at 6:57 AM, Dag-Erling Sm=F8rgrav wrote: > David Duchscher writes: >> So does anybody know of a battery backed NVRAM card that can be used >> with FreeBSD that the ZIL could be offloaded to? > > Any CF card or similar will do. You don't need battery backup for > flash memory. I did think of that but is a CF card faster than a good SAS or SATA =20 drive? Fastest ones I found have a top rating of 45MB/s. The one =20 battery backed NVARM card that showed up in a google search had a =20 peak rate of 533MB/s. The question seems moot though since FreeBSD =20 doesn't currently support them. Thanks for your time, -- DaveD --Apple-Mail-1-295164636-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 15:32:50 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75E7816A41A; Fri, 14 Dec 2007 15:32:50 +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 2420213C447; Fri, 14 Dec 2007 15:32:49 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (ip-83-134-212-48.dsl.scarlet.be [83.134.212.48]) (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 380A21BAC2E; Fri, 14 Dec 2007 16:32:46 +0100 (CET) Received: from avoriaz.restart.bel (avoriaz.restart.bel [192.168.24.1]) (authenticated bits=0) by restart.be (8.14.2/8.14.2) with ESMTP id lBEFWho2016089; Fri, 14 Dec 2007 16:32:43 +0100 (CET) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1197646365; bh=FGkueWyc4fnC0hSRN2PY5NY+nIx2+L+yrNTwZc5 s8ao=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:Subject:Content-Type:X-Scanned-By; b=y0 /QIoTH2GAU4IU/qWewhaUvtWRGJl1YT6vH4pWwEvyas+1ujoASMZDswi1Gxh1iUfv7g lHcmvQrp5QqoLwn4g== 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:content-type:x-scanned-by; b=uWyufnrxrCCi1m1+RGBcBVFBLBoSLyleJ7rL418ePnXH+6iXAMcLVsuI9+4PXS6EL XbMcePbEoR5PNYq8oncaQ== Message-ID: <4762A21B.7010208@restart.be> Date: Fri, 14 Dec 2007 16:32:43 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------060002070804090203090509" X-Scanned-By: MIMEDefang 2.63 on 192.168.24.1 Cc: Subject: 7.0-BETA4 - i386 - root on zfs - system freeze X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 15:32:50 -0000 This is a multi-part message in MIME format. --------------060002070804090203090509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I'm running 7.0-BETA4 - i386 with the root fs on zfs. This nigth, the system freeze. I can enter kdb - see attached file - If I request the wrong informations let me know for the next time... I use the patch http://people.freebsd.org/~pjd/patches/zgd_done.patch . Henri --------------060002070804090203090509 Content-Type: text/plain; name="minicom.cap" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="minicom.cap" show lockedvnods Locked vnodes 0xa6ce1330: tag zfs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags (VV_ROOT) v_object 0xaaca4554 ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xabc69440 (pid 1200) with 1 pending 0xabcfc880: tag zfs, type VDIR usecount 25, writecount 0, refcount 27 mountedhere 0 flags () v_object 0xba6ec1f0 ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xabc6c220 (pid 1195) with 1 pending 0xabaa0bb0: tag zfs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xaeea61f0 ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xa5ba7440 (pid 1190) with 1 pending 0xa938e000: tag zfs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xae7f983c ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xa5b40000 (pid 50869) 0xc2270000: tag zfs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xb0a7a07c ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xa5ba7000 (pid 33960) db> ps pid ppid pgrp uid state wmesg wchan cmd 33962 33959 33943 0 S piperd 0xa5dad4a4 wc 33961 33959 33943 0 S piperd 0xa69a7dec tee 33960 33959 33943 0 R find 33959 33955 33943 0 S wait 0xa61ea000 sh 33955 33952 33943 0 S piperd 0xa5ea6dec sh 33954 33953 33943 0 S piperd 0xa5d0b4a4 mail 33953 33945 33943 0 S wait 0xa6435ab0 sh 33952 33945 33943 0 S wait 0xa88fe2ac sh 33945 33943 33943 0 S wait 0xa6439804 sh 33943 33941 33943 0 Ss wait 0xa65e0ab0 sh 33941 1047 1047 0 S piperd 0xa60d9000 cron 33909 886 865 8 R sleep 96256 1 96256 25 Rs sendmail 96252 1 96252 0 Rs sendmail 96004 1 96004 389 Ss (threaded) slapd 100382 S ucond 0xa6113c00 slapd 100171 S select 0xa089b7f8 slapd 100343 S uwait 0xa5b56a00 slapd 95808 95796 95796 80 R (threaded) httpd --More-- 100381 CanRun httpd 100380 S ucond 0xab0f03c0 httpd 100379 S ucond 0xa63c2c00 httpd 100378 S ucond 0xaf422a80 httpd 100377 S ucond 0xac2c4d80 httpd 100376 S ucond 0xa5b1ab40 httpd 100375 S ucond 0xa6417800 httpd 100374 S ucond 0xa5b7a480 httpd 100373 S ucond 0xa984f640 httpd 100372 S ucond 0xa79f1580 httpd 100371 S ucond 0xa9dcfb80 httpd 100370 S ucond 0xa6ec48c0 httpd 100369 S ucond 0xa6418900 httpd 100368 S ucond 0xa79f1b00 httpd 100342 S ucond 0xa894b000 httpd 100341 S ucond 0xa991e940 httpd 100274 S piperd 0xa6534318 httpd 95805 95796 95796 80 S accept 0xa930103a httpd 95804 95798 95796 0 S piperd 0xa5fefdec cronolog 95803 95800 95796 0 S piperd 0xa5b60630 cronolog 95802 95799 95796 0 S piperd 0xa6121000 cronolog 95801 95797 95796 0 S piperd 0xa5c86ad4 cronolog 95800 95796 95796 0 S wait 0xaadbaab0 sh 95799 95796 95796 0 S wait 0xa7f82000 sh 95798 95796 95796 0 S wait 0xa6283804 sh 95797 95796 95796 0 S wait 0xa8b9dab0 sh 95796 1 95796 0 Rs httpd 95792 95787 95777 0 S+ piperd 0xa588718c cronolog 95787 1 95777 0 S+ wait 0xa623b804 sh 95764 1 95764 0 Ss kqread 0xa5f70b80 cupsd 50945 50869 50945 100 Ss piperd 0xa5ea6948 unlinkd 50869 50867 50867 100 R (threaded) squid 100397 S ucond 0xa682ca00 squid 100396 S ucond 0xa5b1b740 squid 100395 S ucond 0xa79f7c40 squid 100394 S ucond 0xa7842c40 squid 100393 S ucond 0xab0f06c0 squid 100392 S ucond 0xa718b4c0 squid 100391 S ucond 0xc2453000 squid 100390 S ucond 0xa647dd00 squid 100389 S ucond 0xb053b080 squid 100388 S ucond 0xa718c000 squid 100387 S ucond 0xa5b56e00 squid 100386 S ucond 0xa991e300 squid 100385 S ucond 0xa58842c0 squid 100384 S ucond 0xaa09d180 squid 100383 S ucond 0xa5e84c80 squid 100367 S ucond 0xaf422780 squid 100207 RunQ initial thread 50867 1 50867 100 Ss wait 0xaa606000 squid 70740 0 0 0 SL vgeom:io 0xafddb7c8 [vdev:worker ad6s3] 70739 0 0 0 SL vgeom:io 0xacd3dcc8 [vdev:worker ad4s3] 68268 1 68268 53 Rs (threaded) named 100143 RunQ named 100142 RunQ named 100141 S ucond 0xc2453240 named 100140 S ucond 0xaa447e40 named 100111 S sigwait 0xe8af1be0 named 67097 1 67097 0 SLs aiordy 0xa65bc220 [aiod4] 67096 1 67096 0 SLs aiordy 0xa63c1880 [aiod3] 67095 1 67095 0 SLs aiordy 0xa8939880 [aiod2] 67094 1 67094 0 SLs aiordy 0xaa604220 [aiod1] 67057 0 0 0 SL - 0xaedecc80 [aiod_bio taskq] 44891 0 0 0 SL vgeom:io 0xa86675c8 [vdev:worker da1s2] 44890 0 0 0 SL vgeom:io 0xaaa7c148 [vdev:worker da0s2] 44882 1 44881 2001 R initial thread 34948 34903 34902 88 R+ (threaded) mysqld 100365 S sigwait 0xeb269be0 mysqld 100364 S ucond 0xabd79480 mysqld 100363 RunQ mysqld 100362 CanRun mysqld 100361 S ucond 0xc0e6d600 mysqld 100360 S ucond 0xab209880 mysqld 100359 S ucond 0xa7843880 mysqld 100358 S ucond 0xa7842300 mysqld 100344 S select 0xa089b7f8 initial thread 34903 1 34902 88 S+ wait 0xa62842ac sh 3432 0 0 0 SL zfs:(&tq 0xa5589b78 [zil_clean] 3431 0 0 0 SL zfs:(&tq 0xa5589aac [zil_clean] 3430 0 0 0 SL zfs:(&tq 0xa55899e0 [zil_clean] 3429 0 0 0 SL zfs:(&tq 0xa5589914 [zil_clean] 3428 0 0 0 SL zfs:(&tq 0xa5589848 [zil_clean] 3427 0 0 0 SL zfs:(&tq 0xa558977c [zil_clean] 3426 0 0 0 SL zfs:(&tq 0xa55896b0 [zil_clean] 3423 0 0 0 RL [txg_thread_enter] 3422 0 0 0 RL CPU 0 [txg_thread_enter] 3421 0 0 0 SL zfs:(&tx 0xa9bad51c [txg_thread_enter] 3418 0 0 0 SL zfs:(&tq 0xa55895e4 [spa_zio_intr_5] 3417 0 0 0 SL zfs:(&tq 0xa55895e4 [spa_zio_intr_5] 3416 0 0 0 SL zfs:(&tq 0xa5589518 [spa_zio_issue_5] 3415 0 0 0 SL zfs:(&tq 0xa5589518 [spa_zio_issue_5] 3414 0 0 0 SL zfs:(&tq 0xa558944c [spa_zio_intr_4] 3413 0 0 0 SL zfs:(&tq 0xa558944c [spa_zio_intr_4] 3412 0 0 0 SL zfs:(&tq 0xa5b9f914 [spa_zio_issue_4] 3411 0 0 0 SL zfs:(&tq 0xa5b9f914 [spa_zio_issue_4] 3410 0 0 0 SL zfs:(&tq 0xa5b9f848 [spa_zio_intr_3] 3409 0 0 0 SL zfs:(&tq 0xa5b9f848 [spa_zio_intr_3] 3408 0 0 0 SL zfs:(&tq 0xa5b9f77c [spa_zio_issue_3] 3407 0 0 0 SL zfs:(&tq 0xa5b9f77c [spa_zio_issue_3] 3406 0 0 0 SL zfs:(&tq 0xa5b9f6b0 [spa_zio_intr_2] 3405 0 0 0 SL zfs:(&tq 0xa5b9f6b0 [spa_zio_intr_2] 3404 0 0 0 SL zfs:(&tq 0xa5b9f5e4 [spa_zio_issue_2] 3403 0 0 0 SL zfs:(&tq 0xa5b9f5e4 [spa_zio_issue_2] 3402 0 0 0 SL zfs:(&tq 0xa5b9f518 [spa_zio_intr_1] 3401 0 0 0 SL zfs:(&tq 0xa5b9f518 [spa_zio_intr_1] 3400 0 0 0 SL zfs:(&tq 0xa5b9f44c [spa_zio_issue_1] 3399 0 0 0 SL zfs:(&tq 0xa5b9f44c [spa_zio_issue_1] 3398 0 0 0 SL zfs:(&tq 0xa5b9f380 [spa_zio_intr_0] 3397 0 0 0 SL zfs:(&tq 0xa5b9f380 [spa_zio_intr_0] 3396 0 0 0 SL zfs:(&tq 0xa5b9f2b4 [spa_zio_issue_0] 3395 0 0 0 SL zfs:(&tq 0xa5b9f2b4 [spa_zio_issue_0] 3367 0 0 0 SL zfs:(&tq 0xa61171e8 [zil_clean] 3366 0 0 0 SL zfs:(&tq 0xa61172b4 [zil_clean] 3365 0 0 0 SL zfs:(&tq 0xa6117380 [zil_clean] 3362 0 0 0 RL [txg_thread_enter] 3361 0 0 0 SL zfs:(&tx 0xaeaae70c [txg_thread_enter] 3360 0 0 0 SL zfs:(&tx 0xaeaae71c [txg_thread_enter] 3359 0 0 0 SL vgeom:io 0xa991e588 [vdev:worker da1s3] 3358 0 0 0 SL vgeom:io 0xa7843688 [vdev:worker da0s3] 3357 0 0 0 SL zfs:(&tq 0xa611744c [spa_zio_intr_5] 3356 0 0 0 SL zfs:(&tq 0xa611744c [spa_zio_intr_5] 3355 0 0 0 SL zfs:(&tq 0xa6117518 [spa_zio_issue_5] 3354 0 0 0 SL zfs:(&tq 0xa6117518 [spa_zio_issue_5] 3353 0 0 0 SL zfs:(&tq 0xa61175e4 [spa_zio_intr_4] 3352 0 0 0 SL zfs:(&tq 0xa61175e4 [spa_zio_intr_4] 3351 0 0 0 SL zfs:(&tq 0xa61176b0 [spa_zio_issue_4] 3350 0 0 0 SL zfs:(&tq 0xa61176b0 [spa_zio_issue_4] 3349 0 0 0 SL zfs:(&tq 0xa611777c [spa_zio_intr_3] 3348 0 0 0 SL zfs:(&tq 0xa611777c [spa_zio_intr_3] 3347 0 0 0 SL zfs:(&tq 0xa5b9f1e8 [spa_zio_issue_3] 3346 0 0 0 SL zfs:(&tq 0xa5b9f1e8 [spa_zio_issue_3] 3345 0 0 0 SL zfs:(&tq 0xa5b9f11c [spa_zio_intr_2] 3344 0 0 0 SL zfs:(&tq 0xa5b9f11c [spa_zio_intr_2] 3343 0 0 0 SL zfs:(&tq 0xa5589050 [spa_zio_issue_2] 3342 0 0 0 SL zfs:(&tq 0xa5589050 [spa_zio_issue_2] 3341 0 0 0 SL zfs:(&tq 0xa558911c [spa_zio_intr_1] 3340 0 0 0 SL zfs:(&tq 0xa558911c [spa_zio_intr_1] 3339 0 0 0 SL zfs:(&tq 0xa55891e8 [spa_zio_issue_1] 3338 0 0 0 SL zfs:(&tq 0xa55891e8 [spa_zio_issue_1] 3337 0 0 0 SL zfs:(&tq 0xa55892b4 [spa_zio_intr_0] 3336 0 0 0 SL zfs:(&tq 0xa55892b4 [spa_zio_intr_0] 3335 0 0 0 SL zfs:(&tq 0xa5589380 [spa_zio_issue_0] 3334 0 0 0 SL zfs:(&tq 0xa5589380 [spa_zio_issue_0] 1398 1 1374 2001 R initial thread 1396 1392 1374 2001 R (threaded) firefox-bin 100234 S ucond 0xa5884900 firefox-bin 100233 S ucond 0xa682cd40 firefox-bin 100232 S ucond 0xa5884580 firefox-bin 100227 RunQ firefox-bin 100226 S select 0xa089b7f8 firefox-bin 100170 S select 0xa089b7f8 initial thread 1392 1388 1374 2001 S wait 0xb00fc558 sh 1388 1 1374 2001 S wait 0xaf03aab0 sh 1223 1213 1223 0 S+ ttyin 0xa5df0010 bash 1221 1211 1221 0 S+ ttyin 0xa5db0c10 bash 1219 1209 1219 0 S+ ttyin 0xa5def810 bash 1217 1207 1217 0 S+ ttyin 0xa5e97410 bash 1215 1205 1215 0 S+ ttyin 0xa5e9c410 bash 1213 1200 1213 2001 Ss+ wait 0xadc6cab0 su 1211 1200 1211 2001 Ss+ wait 0xadc6c000 su 1209 1200 1209 2001 Ss+ wait 0xaa606804 su 1207 1200 1207 2001 Ss+ wait 0xaa606ab0 su 1205 1200 1205 2001 Ss+ wait 0xadc6c2ac su 1204 1200 1169 2001 S+ sbwait 0xa7c7da04 initial thread 1200 1 1169 2001 S+ zfs 0xabcfc8d8 initial thread 1196 1191 1169 2001 R+ initial thread 1195 1191 1169 2001 S+ zfs 0xabaa0c08 initial thread 1192 1184 1169 2001 R+ initial thread 1191 1184 1169 2001 S+ zfs 0xa6ce1388 initial thread 1190 1184 1169 2001 R+ initial thread 1189 1184 1169 2001 S+ select 0xa089b7f8 initial thread 1188 1 1188 2001 Rs xfce-mcs-manager 1184 1169 1169 2001 S+ select 0xa089b7f8 initial thread 1182 1 1182 2001 Ss select 0xa089b7f8 dbus-daemon 1181 1 1169 2001 S+ select 0xa089b7f8 dbus-launch 1176 1 1176 2001 Ss select 0xa089b7f8 ssh-agent 1169 1163 1169 2001 S+ wait 0xa6e3f558 sh 1164 1163 1164 2001 S+ select 0xa089b7f8 Xorg 1163 1161 1163 2001 S+ wait 0xa5b3eab0 xinit 1161 1160 1161 2001 S+ wait 0xa6e3f000 bash 1160 1 1160 0 Ss+ wait 0xa56d9ab0 login 1126 1 1126 0 Ss+ ttyin 0xa56fdc10 getty 1125 1 1125 0 Ss+ ttyin 0xa5707010 getty 1124 1 1124 0 Ss+ ttyin 0xa5707410 getty 1108 1 1108 0 Ss select 0xa089b7f8 inetd 1079 1 1079 0 Ss select 0xa089b7f8 moused 1047 1 1047 0 Rs cron 1042 1 1042 0 Rs sshd 931 1 931 501 Ss select 0xa089b7f8 cvsupd 903 883 883 8 S select 0xa089b7f8 innfeed 889 885 865 8 R+ initial thread 886 884 865 8 S+ wait 0xa5b8a2ac sh 885 1 865 8 S+ wait 0xa56d9804 sh 884 1 865 8 S+ wait 0xa5be6ab0 sh 883 1 883 8 Rs innd 853 1 853 279 Rs perl 843 1 843 0 Rs bsnmpd 834 1 834 556 Ss select 0xa089b7f8 dbus-daemon 826 823 826 70 Rs postgres 825 823 825 70 Rs postgres 823 1 823 70 Rs postgres 806 802 802 0 S lockf 0xa7910580 saslauthd 805 802 802 0 S lockf 0xa5af1280 saslauthd 804 802 802 0 S lockf 0xa5af1440 saslauthd 803 802 802 0 S accept 0xa820366a saslauthd 802 1 802 0 Ss lockf 0xa78431c0 saslauthd 774 1 773 0 R smartd 750 1 750 0 Rs ntpd 710 1 710 0 Rs (threaded) apcupsd 100144 RunQ apcupsd 100081 CanRun apcupsd 681 1 681 0 Ss auditd 0xa08aaa68 auditd 668 1 668 0 Rs rpcbind 587 1 587 0 Rs syslogd 176 0 0 0 SL zfs:(&tq 0xa5589ddc [zil_clean] 175 0 0 0 SL zfs:(&tq 0xa5589ea8 [zil_clean] 174 0 0 0 SL zfs:(&tq 0xa558ad10 [zil_clean] 173 0 0 0 SL zfs:(&tq 0xa558ac44 [zil_clean] 172 0 0 0 SL zfs:(&tq 0xa558ab78 [zil_clean] 113 0 0 0 SL zfs:(&tq 0xa558aaac [zil_clean] 112 0 0 0 RL [txg_thread_enter] 111 0 0 0 RL [txg_thread_enter] 110 0 0 0 SL zfs:(&tx 0xa58c031c [txg_thread_enter] 107 0 0 0 SL zfs:(&tq 0xa558a9e0 [spa_zio_intr_5] 106 0 0 0 SL zfs:(&tq 0xa558a9e0 [spa_zio_intr_5] 105 0 0 0 SL zfs:(&tq 0xa558a914 [spa_zio_issue_5] 104 0 0 0 SL zfs:(&tq 0xa558a914 [spa_zio_issue_5] 103 0 0 0 SL zfs:(&tq 0xa558a848 [spa_zio_intr_4] 102 0 0 0 SL zfs:(&tq 0xa558a848 [spa_zio_intr_4] 101 0 0 0 SL zfs:(&tq 0xa558a11c [spa_zio_issue_4] 100 0 0 0 SL zfs:(&tq 0xa558a11c [spa_zio_issue_4] 99 0 0 0 SL zfs:(&tq 0xa558a1e8 [spa_zio_intr_3] 98 0 0 0 SL zfs:(&tq 0xa558a1e8 [spa_zio_intr_3] 97 0 0 0 SL zfs:(&tq 0xa558a2b4 [spa_zio_issue_3] 96 0 0 0 SL zfs:(&tq 0xa558a2b4 [spa_zio_issue_3] 95 0 0 0 SL zfs:(&tq 0xa558a380 [spa_zio_intr_2] 94 0 0 0 SL zfs:(&tq 0xa558a380 [spa_zio_intr_2] 93 0 0 0 SL zfs:(&tq 0xa558a44c [spa_zio_issue_2] 92 0 0 0 SL zfs:(&tq 0xa558a44c [spa_zio_issue_2] 91 0 0 0 SL zfs:(&tq 0xa558a518 [spa_zio_intr_1] 90 0 0 0 SL zfs:(&tq 0xa558a518 [spa_zio_intr_1] 89 0 0 0 SL zfs:(&tq 0xa558a5e4 [spa_zio_issue_1] 88 0 0 0 SL zfs:(&tq 0xa558a5e4 [spa_zio_issue_1] 87 0 0 0 SL zfs:(&tq 0xa558a6b0 [spa_zio_intr_0] 86 0 0 0 SL zfs:(&tq 0xa558a6b0 [spa_zio_intr_0] 85 0 0 0 SL zfs:(&tq 0xa558a77c [spa_zio_issue_0] 84 0 0 0 SL zfs:(&tq 0xa558a77c [spa_zio_issue_0] 57 0 0 0 SL m:w1 0xa5894a00 [g_mirror gm0s1] 56 0 0 0 SL sdflush 0xa08aab64 [softdepflush] 55 0 0 0 RL [syncer] 54 0 0 0 SL vlruwt 0xa5b3e000 [vnlru] 53 0 0 0 SL psleep 0xa089bc44 [bufdaemon] 52 0 0 0 RL [pagezero] 51 0 0 0 SL psleep 0xa08ab338 [vmdaemon] 50 0 0 0 SL psleep 0xa08ab300 [pagedaemon] 49 0 0 0 SL gj:work 0xa5aff200 [g_journal ad4s2] 48 0 0 0 SL zgd 0xa0a03974 [zgd_done] 47 0 0 0 RL CPU 1 [arc_reclaim_thread] 46 0 0 0 SL jsw:wait 0xa088e834 [g_journal switcher] 45 0 0 0 SL waiting_ 0xa089f28c [sctp_iterator] 44 0 0 0 RL [swi0: sio] 43 0 0 0 WL [irq12: psm0] 42 0 0 0 WL [irq1: atkbd0] 41 0 0 0 WL [irq15: ata1] 40 0 0 0 WL [irq14: ata0] 39 0 0 0 SL usbevt 0xa55d2210 [usb4] 38 0 0 0 SL usbevt 0xa56b9210 [usb3] 37 0 0 0 RL [usb2] 36 0 0 0 RL [irq18: uhci2] 35 0 0 0 RL [usb1] 34 0 0 0 WL [irq19: uhci1++] 33 0 0 0 SL usbtsk 0xa088e454 [usbtask-dr] 32 0 0 0 SL usbtsk 0xa088e440 [usbtask-hc] 31 0 0 0 SL usbevt 0xa56a3210 [usb0] 30 0 0 0 WL [irq17: uhci0 ehci0] 29 0 0 0 SL idle 0xa5689000 [mpt_recovery0] 28 0 0 0 RL [em0 taskq] 27 0 0 0 RL [irq16: nvidia0+++] 26 0 0 0 WL [irq9: acpi0] 25 0 0 0 SL - 0xa5568900 [kqueue taskq] 24 0 0 0 WL [swi6: task queue] 23 0 0 0 SL - 0xa5568a80 [acpi_task_2] 22 0 0 0 SL - 0xa5568a80 [acpi_task_1] 21 0 0 0 SL - 0xa5568a80 [acpi_task_0] 20 0 0 0 WL [swi6: Giant taskq] 19 0 0 0 SL - 0xa5568c00 [thread taskq] 18 0 0 0 WL [swi5: +] 17 0 0 0 WL [swi2: cambio] 9 0 0 0 SL ccb_scan 0xa0878654 [xpt_thrd] 16 0 0 0 RL [yarrow] 8 0 0 0 SL crypto_r 0xa08aa354 [crypto returns] 7 0 0 0 SL crypto_w 0xa08aa32c [crypto] 6 0 0 0 SL zfs:(&tq 0xa558a050 [system_taskq] 5 0 0 0 SL zfs:(&tq 0xa558a050 [system_taskq] 4 0 0 0 SL - 0xa088e7ec [g_down] 3 0 0 0 SL - 0xa088e7e8 [g_up] 2 0 0 0 SL - 0xa088e7e0 [g_event] 15 0 0 0 WL [swi3: vm] 14 0 0 0 RL [swi4: clock sio] 13 0 0 0 WL [swi1: net] 12 0 0 0 RL [idle: cpu0] 11 0 0 0 RL [idle: cpu1] 1 0 1 0 SLs wait 0xa5528ab0 [init] 10 0 0 0 SL audit_wo 0xa08aa5b8 [audit] 0 0 0 0 WLs [swapper] db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xa5ebe440: pid 3422 "txg_thread_enter" curpcb = 0xeb175d90 fpcurthread = none idlethread = 0xa5529aa0: pid 12 "idle: cpu0" APIC ID = 0 currentldt = 0x50 cpuid = 1 curthread = 0xa56ab220: pid 47 "arc_reclaim_thread" curpcb = 0xe6837d90 fpcurthread = none idlethread = 0xa5529880: pid 11 "idle: cpu1" APIC ID = 1 currentldt = 0x50 db> reboot cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 --------------060002070804090203090509-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 16:12:51 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DA4516A533 for ; Fri, 14 Dec 2007 16:12:51 +0000 (UTC) (envelope-from dtynan@kalopa.com) Received: from mail.kalopa.net (mail.kalopa.net [82.195.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 1753813C469 for ; Fri, 14 Dec 2007 16:12:49 +0000 (UTC) (envelope-from dtynan@kalopa.com) Received: from mail.kalopa.com (mail.kgbb.net [84.203.222.58]) by mail.kalopa.net (8.13.6/8.13.3) with ESMTP id lBEFfP8I075980; Fri, 14 Dec 2007 15:41:25 GMT (envelope-from dtynan@kalopa.com) Received: (from dtynan@localhost) by mail.kalopa.com (8.11.3/8.11.3) id lBEFZ1u39983; Fri, 14 Dec 2007 15:35:01 GMT (envelope-from dtynan) Received: from mail.kalopa.net (mail.kalopa.net [82.195.155.65]) by mail.kalopa.com (8.11.3/8.11.3) with ESMTP id lBEFYx539973 for ; Fri, 14 Dec 2007 15:34:59 GMT (envelope-from owner-freebsd-stable@freebsd.org) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by mail.kalopa.net (8.13.6/8.13.3) with ESMTP id lBEFeXfQ075914 for ; Fri, 14 Dec 2007 15:41:04 GMT (envelope-from owner-freebsd-stable@freebsd.org) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id AEDD71703EF; Fri, 14 Dec 2007 15:32:57 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A062016A4AC; Fri, 14 Dec 2007 15:32:57 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) 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 75E7816A41A; Fri, 14 Dec 2007 15:32:50 +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 2420213C447; Fri, 14 Dec 2007 15:32:49 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (ip-83-134-212-48.dsl.scarlet.be [83.134.212.48]) (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 380A21BAC2E; Fri, 14 Dec 2007 16:32:46 +0100 (CET) Received: from avoriaz.restart.bel (avoriaz.restart.bel [192.168.24.1]) (authenticated bits=0) by restart.be (8.14.2/8.14.2) with ESMTP id lBEFWho2016089; Fri, 14 Dec 2007 16:32:43 +0100 (CET) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1197646365; bh=FGkueWyc4fnC0hSRN2PY5NY+nIx2+L+yrNTwZc5 s8ao=; h=DomainKey-Signature:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:Subject:Content-Type:X-Scanned-By; b=y0 /QIoTH2GAU4IU/qWewhaUvtWRGJl1YT6vH4pWwEvyas+1ujoASMZDswi1Gxh1iUfv7g lHcmvQrp5QqoLwn4g== 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:content-type:x-scanned-by; b=uWyufnrxrCCi1m1+RGBcBVFBLBoSLyleJ7rL418ePnXH+6iXAMcLVsuI9+4PXS6EL XbMcePbEoR5PNYq8oncaQ== Message-ID: <4762A21B.7010208@restart.be> Date: Fri, 14 Dec 2007 16:32:43 +0100 From: Henri Hennebert X-DoIKnowU: Addr=[/v/dtynan/Mail/Addresses] X-Known: NO Organization: RestartSoft User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------060002070804090203090509" X-Scanned-By: MIMEDefang 2.63 on 192.168.24.1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org X-Virus-Scanned: ClamAV 0.88.1/5119/Fri Dec 14 14:16:31 2007 on mail.kalopa.net X-Virus-Scanned: ClamAV 0.88.1/5119/Fri Dec 14 14:16:31 2007 on mail.kalopa.net X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=6.0 tests=AWL,BAYES_00,DK_SIGNED, FORGED_RCVD_HELO,SPF_SOFTFAIL autolearn=no version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on mail.kalopa.net Cc: Subject: 7.0-BETA4 - i386 - root on zfs - system freeze X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 16:12:51 -0000 This is a multi-part message in MIME format. --------------060002070804090203090509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I'm running 7.0-BETA4 - i386 with the root fs on zfs. This nigth, the system freeze. I can enter kdb - see attached file - If I request the wrong informations let me know for the next time... I use the patch http://people.freebsd.org/~pjd/patches/zgd_done.patch . Henri --------------060002070804090203090509 Content-Type: text/plain; name="minicom.cap" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="minicom.cap" show lockedvnods Locked vnodes 0xa6ce1330: tag zfs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags (VV_ROOT) v_object 0xaaca4554 ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xabc69440 (pid 1200) with 1 pending 0xabcfc880: tag zfs, type VDIR usecount 25, writecount 0, refcount 27 mountedhere 0 flags () v_object 0xba6ec1f0 ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xabc6c220 (pid 1195) with 1 pending 0xabaa0bb0: tag zfs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xaeea61f0 ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xa5ba7440 (pid 1190) with 1 pending 0xa938e000: tag zfs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xae7f983c ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xa5b40000 (pid 50869) 0xc2270000: tag zfs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xb0a7a07c ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xa5ba7000 (pid 33960) db> ps pid ppid pgrp uid state wmesg wchan cmd 33962 33959 33943 0 S piperd 0xa5dad4a4 wc 33961 33959 33943 0 S piperd 0xa69a7dec tee 33960 33959 33943 0 R find 33959 33955 33943 0 S wait 0xa61ea000 sh 33955 33952 33943 0 S piperd 0xa5ea6dec sh 33954 33953 33943 0 S piperd 0xa5d0b4a4 mail 33953 33945 33943 0 S wait 0xa6435ab0 sh 33952 33945 33943 0 S wait 0xa88fe2ac sh 33945 33943 33943 0 S wait 0xa6439804 sh 33943 33941 33943 0 Ss wait 0xa65e0ab0 sh 33941 1047 1047 0 S piperd 0xa60d9000 cron 33909 886 865 8 R sleep 96256 1 96256 25 Rs sendmail 96252 1 96252 0 Rs sendmail 96004 1 96004 389 Ss (threaded) slapd 100382 S ucond 0xa6113c00 slapd 100171 S select 0xa089b7f8 slapd 100343 S uwait 0xa5b56a00 slapd 95808 95796 95796 80 R (threaded) httpd --More-- 100381 CanRun httpd 100380 S ucond 0xab0f03c0 httpd 100379 S ucond 0xa63c2c00 httpd 100378 S ucond 0xaf422a80 httpd 100377 S ucond 0xac2c4d80 httpd 100376 S ucond 0xa5b1ab40 httpd 100375 S ucond 0xa6417800 httpd 100374 S ucond 0xa5b7a480 httpd 100373 S ucond 0xa984f640 httpd 100372 S ucond 0xa79f1580 httpd 100371 S ucond 0xa9dcfb80 httpd 100370 S ucond 0xa6ec48c0 httpd 100369 S ucond 0xa6418900 httpd 100368 S ucond 0xa79f1b00 httpd 100342 S ucond 0xa894b000 httpd 100341 S ucond 0xa991e940 httpd 100274 S piperd 0xa6534318 httpd 95805 95796 95796 80 S accept 0xa930103a httpd 95804 95798 95796 0 S piperd 0xa5fefdec cronolog 95803 95800 95796 0 S piperd 0xa5b60630 cronolog 95802 95799 95796 0 S piperd 0xa6121000 cronolog 95801 95797 95796 0 S piperd 0xa5c86ad4 cronolog 95800 95796 95796 0 S wait 0xaadbaab0 sh 95799 95796 95796 0 S wait 0xa7f82000 sh 95798 95796 95796 0 S wait 0xa6283804 sh 95797 95796 95796 0 S wait 0xa8b9dab0 sh 95796 1 95796 0 Rs httpd 95792 95787 95777 0 S+ piperd 0xa588718c cronolog 95787 1 95777 0 S+ wait 0xa623b804 sh 95764 1 95764 0 Ss kqread 0xa5f70b80 cupsd 50945 50869 50945 100 Ss piperd 0xa5ea6948 unlinkd 50869 50867 50867 100 R (threaded) squid 100397 S ucond 0xa682ca00 squid 100396 S ucond 0xa5b1b740 squid 100395 S ucond 0xa79f7c40 squid 100394 S ucond 0xa7842c40 squid 100393 S ucond 0xab0f06c0 squid 100392 S ucond 0xa718b4c0 squid 100391 S ucond 0xc2453000 squid 100390 S ucond 0xa647dd00 squid 100389 S ucond 0xb053b080 squid 100388 S ucond 0xa718c000 squid 100387 S ucond 0xa5b56e00 squid 100386 S ucond 0xa991e300 squid 100385 S ucond 0xa58842c0 squid 100384 S ucond 0xaa09d180 squid 100383 S ucond 0xa5e84c80 squid 100367 S ucond 0xaf422780 squid 100207 RunQ initial thread 50867 1 50867 100 Ss wait 0xaa606000 squid 70740 0 0 0 SL vgeom:io 0xafddb7c8 [vdev:worker ad6s3] 70739 0 0 0 SL vgeom:io 0xacd3dcc8 [vdev:worker ad4s3] 68268 1 68268 53 Rs (threaded) named 100143 RunQ named 100142 RunQ named 100141 S ucond 0xc2453240 named 100140 S ucond 0xaa447e40 named 100111 S sigwait 0xe8af1be0 named 67097 1 67097 0 SLs aiordy 0xa65bc220 [aiod4] 67096 1 67096 0 SLs aiordy 0xa63c1880 [aiod3] 67095 1 67095 0 SLs aiordy 0xa8939880 [aiod2] 67094 1 67094 0 SLs aiordy 0xaa604220 [aiod1] 67057 0 0 0 SL - 0xaedecc80 [aiod_bio taskq] 44891 0 0 0 SL vgeom:io 0xa86675c8 [vdev:worker da1s2] 44890 0 0 0 SL vgeom:io 0xaaa7c148 [vdev:worker da0s2] 44882 1 44881 2001 R initial thread 34948 34903 34902 88 R+ (threaded) mysqld 100365 S sigwait 0xeb269be0 mysqld 100364 S ucond 0xabd79480 mysqld 100363 RunQ mysqld 100362 CanRun mysqld 100361 S ucond 0xc0e6d600 mysqld 100360 S ucond 0xab209880 mysqld 100359 S ucond 0xa7843880 mysqld 100358 S ucond 0xa7842300 mysqld 100344 S select 0xa089b7f8 initial thread 34903 1 34902 88 S+ wait 0xa62842ac sh 3432 0 0 0 SL zfs:(&tq 0xa5589b78 [zil_clean] 3431 0 0 0 SL zfs:(&tq 0xa5589aac [zil_clean] 3430 0 0 0 SL zfs:(&tq 0xa55899e0 [zil_clean] 3429 0 0 0 SL zfs:(&tq 0xa5589914 [zil_clean] 3428 0 0 0 SL zfs:(&tq 0xa5589848 [zil_clean] 3427 0 0 0 SL zfs:(&tq 0xa558977c [zil_clean] 3426 0 0 0 SL zfs:(&tq 0xa55896b0 [zil_clean] 3423 0 0 0 RL [txg_thread_enter] 3422 0 0 0 RL CPU 0 [txg_thread_enter] 3421 0 0 0 SL zfs:(&tx 0xa9bad51c [txg_thread_enter] 3418 0 0 0 SL zfs:(&tq 0xa55895e4 [spa_zio_intr_5] 3417 0 0 0 SL zfs:(&tq 0xa55895e4 [spa_zio_intr_5] 3416 0 0 0 SL zfs:(&tq 0xa5589518 [spa_zio_issue_5] 3415 0 0 0 SL zfs:(&tq 0xa5589518 [spa_zio_issue_5] 3414 0 0 0 SL zfs:(&tq 0xa558944c [spa_zio_intr_4] 3413 0 0 0 SL zfs:(&tq 0xa558944c [spa_zio_intr_4] 3412 0 0 0 SL zfs:(&tq 0xa5b9f914 [spa_zio_issue_4] 3411 0 0 0 SL zfs:(&tq 0xa5b9f914 [spa_zio_issue_4] 3410 0 0 0 SL zfs:(&tq 0xa5b9f848 [spa_zio_intr_3] 3409 0 0 0 SL zfs:(&tq 0xa5b9f848 [spa_zio_intr_3] 3408 0 0 0 SL zfs:(&tq 0xa5b9f77c [spa_zio_issue_3] 3407 0 0 0 SL zfs:(&tq 0xa5b9f77c [spa_zio_issue_3] 3406 0 0 0 SL zfs:(&tq 0xa5b9f6b0 [spa_zio_intr_2] 3405 0 0 0 SL zfs:(&tq 0xa5b9f6b0 [spa_zio_intr_2] 3404 0 0 0 SL zfs:(&tq 0xa5b9f5e4 [spa_zio_issue_2] 3403 0 0 0 SL zfs:(&tq 0xa5b9f5e4 [spa_zio_issue_2] 3402 0 0 0 SL zfs:(&tq 0xa5b9f518 [spa_zio_intr_1] 3401 0 0 0 SL zfs:(&tq 0xa5b9f518 [spa_zio_intr_1] 3400 0 0 0 SL zfs:(&tq 0xa5b9f44c [spa_zio_issue_1] 3399 0 0 0 SL zfs:(&tq 0xa5b9f44c [spa_zio_issue_1] 3398 0 0 0 SL zfs:(&tq 0xa5b9f380 [spa_zio_intr_0] 3397 0 0 0 SL zfs:(&tq 0xa5b9f380 [spa_zio_intr_0] 3396 0 0 0 SL zfs:(&tq 0xa5b9f2b4 [spa_zio_issue_0] 3395 0 0 0 SL zfs:(&tq 0xa5b9f2b4 [spa_zio_issue_0] 3367 0 0 0 SL zfs:(&tq 0xa61171e8 [zil_clean] 3366 0 0 0 SL zfs:(&tq 0xa61172b4 [zil_clean] 3365 0 0 0 SL zfs:(&tq 0xa6117380 [zil_clean] 3362 0 0 0 RL [txg_thread_enter] 3361 0 0 0 SL zfs:(&tx 0xaeaae70c [txg_thread_enter] 3360 0 0 0 SL zfs:(&tx 0xaeaae71c [txg_thread_enter] 3359 0 0 0 SL vgeom:io 0xa991e588 [vdev:worker da1s3] 3358 0 0 0 SL vgeom:io 0xa7843688 [vdev:worker da0s3] 3357 0 0 0 SL zfs:(&tq 0xa611744c [spa_zio_intr_5] 3356 0 0 0 SL zfs:(&tq 0xa611744c [spa_zio_intr_5] 3355 0 0 0 SL zfs:(&tq 0xa6117518 [spa_zio_issue_5] 3354 0 0 0 SL zfs:(&tq 0xa6117518 [spa_zio_issue_5] 3353 0 0 0 SL zfs:(&tq 0xa61175e4 [spa_zio_intr_4] 3352 0 0 0 SL zfs:(&tq 0xa61175e4 [spa_zio_intr_4] 3351 0 0 0 SL zfs:(&tq 0xa61176b0 [spa_zio_issue_4] 3350 0 0 0 SL zfs:(&tq 0xa61176b0 [spa_zio_issue_4] 3349 0 0 0 SL zfs:(&tq 0xa611777c [spa_zio_intr_3] 3348 0 0 0 SL zfs:(&tq 0xa611777c [spa_zio_intr_3] 3347 0 0 0 SL zfs:(&tq 0xa5b9f1e8 [spa_zio_issue_3] 3346 0 0 0 SL zfs:(&tq 0xa5b9f1e8 [spa_zio_issue_3] 3345 0 0 0 SL zfs:(&tq 0xa5b9f11c [spa_zio_intr_2] 3344 0 0 0 SL zfs:(&tq 0xa5b9f11c [spa_zio_intr_2] 3343 0 0 0 SL zfs:(&tq 0xa5589050 [spa_zio_issue_2] 3342 0 0 0 SL zfs:(&tq 0xa5589050 [spa_zio_issue_2] 3341 0 0 0 SL zfs:(&tq 0xa558911c [spa_zio_intr_1] 3340 0 0 0 SL zfs:(&tq 0xa558911c [spa_zio_intr_1] 3339 0 0 0 SL zfs:(&tq 0xa55891e8 [spa_zio_issue_1] 3338 0 0 0 SL zfs:(&tq 0xa55891e8 [spa_zio_issue_1] 3337 0 0 0 SL zfs:(&tq 0xa55892b4 [spa_zio_intr_0] 3336 0 0 0 SL zfs:(&tq 0xa55892b4 [spa_zio_intr_0] 3335 0 0 0 SL zfs:(&tq 0xa5589380 [spa_zio_issue_0] 3334 0 0 0 SL zfs:(&tq 0xa5589380 [spa_zio_issue_0] 1398 1 1374 2001 R initial thread 1396 1392 1374 2001 R (threaded) firefox-bin 100234 S ucond 0xa5884900 firefox-bin 100233 S ucond 0xa682cd40 firefox-bin 100232 S ucond 0xa5884580 firefox-bin 100227 RunQ firefox-bin 100226 S select 0xa089b7f8 firefox-bin 100170 S select 0xa089b7f8 initial thread 1392 1388 1374 2001 S wait 0xb00fc558 sh 1388 1 1374 2001 S wait 0xaf03aab0 sh 1223 1213 1223 0 S+ ttyin 0xa5df0010 bash 1221 1211 1221 0 S+ ttyin 0xa5db0c10 bash 1219 1209 1219 0 S+ ttyin 0xa5def810 bash 1217 1207 1217 0 S+ ttyin 0xa5e97410 bash 1215 1205 1215 0 S+ ttyin 0xa5e9c410 bash 1213 1200 1213 2001 Ss+ wait 0xadc6cab0 su 1211 1200 1211 2001 Ss+ wait 0xadc6c000 su 1209 1200 1209 2001 Ss+ wait 0xaa606804 su 1207 1200 1207 2001 Ss+ wait 0xaa606ab0 su 1205 1200 1205 2001 Ss+ wait 0xadc6c2ac su 1204 1200 1169 2001 S+ sbwait 0xa7c7da04 initial thread 1200 1 1169 2001 S+ zfs 0xabcfc8d8 initial thread 1196 1191 1169 2001 R+ initial thread 1195 1191 1169 2001 S+ zfs 0xabaa0c08 initial thread 1192 1184 1169 2001 R+ initial thread 1191 1184 1169 2001 S+ zfs 0xa6ce1388 initial thread 1190 1184 1169 2001 R+ initial thread 1189 1184 1169 2001 S+ select 0xa089b7f8 initial thread 1188 1 1188 2001 Rs xfce-mcs-manager 1184 1169 1169 2001 S+ select 0xa089b7f8 initial thread 1182 1 1182 2001 Ss select 0xa089b7f8 dbus-daemon 1181 1 1169 2001 S+ select 0xa089b7f8 dbus-launch 1176 1 1176 2001 Ss select 0xa089b7f8 ssh-agent 1169 1163 1169 2001 S+ wait 0xa6e3f558 sh 1164 1163 1164 2001 S+ select 0xa089b7f8 Xorg 1163 1161 1163 2001 S+ wait 0xa5b3eab0 xinit 1161 1160 1161 2001 S+ wait 0xa6e3f000 bash 1160 1 1160 0 Ss+ wait 0xa56d9ab0 login 1126 1 1126 0 Ss+ ttyin 0xa56fdc10 getty 1125 1 1125 0 Ss+ ttyin 0xa5707010 getty 1124 1 1124 0 Ss+ ttyin 0xa5707410 getty 1108 1 1108 0 Ss select 0xa089b7f8 inetd 1079 1 1079 0 Ss select 0xa089b7f8 moused 1047 1 1047 0 Rs cron 1042 1 1042 0 Rs sshd 931 1 931 501 Ss select 0xa089b7f8 cvsupd 903 883 883 8 S select 0xa089b7f8 innfeed 889 885 865 8 R+ initial thread 886 884 865 8 S+ wait 0xa5b8a2ac sh 885 1 865 8 S+ wait 0xa56d9804 sh 884 1 865 8 S+ wait 0xa5be6ab0 sh 883 1 883 8 Rs innd 853 1 853 279 Rs perl 843 1 843 0 Rs bsnmpd 834 1 834 556 Ss select 0xa089b7f8 dbus-daemon 826 823 826 70 Rs postgres 825 823 825 70 Rs postgres 823 1 823 70 Rs postgres 806 802 802 0 S lockf 0xa7910580 saslauthd 805 802 802 0 S lockf 0xa5af1280 saslauthd 804 802 802 0 S lockf 0xa5af1440 saslauthd 803 802 802 0 S accept 0xa820366a saslauthd 802 1 802 0 Ss lockf 0xa78431c0 saslauthd 774 1 773 0 R smartd 750 1 750 0 Rs ntpd 710 1 710 0 Rs (threaded) apcupsd 100144 RunQ apcupsd 100081 CanRun apcupsd 681 1 681 0 Ss auditd 0xa08aaa68 auditd 668 1 668 0 Rs rpcbind 587 1 587 0 Rs syslogd 176 0 0 0 SL zfs:(&tq 0xa5589ddc [zil_clean] 175 0 0 0 SL zfs:(&tq 0xa5589ea8 [zil_clean] 174 0 0 0 SL zfs:(&tq 0xa558ad10 [zil_clean] 173 0 0 0 SL zfs:(&tq 0xa558ac44 [zil_clean] 172 0 0 0 SL zfs:(&tq 0xa558ab78 [zil_clean] 113 0 0 0 SL zfs:(&tq 0xa558aaac [zil_clean] 112 0 0 0 RL [txg_thread_enter] 111 0 0 0 RL [txg_thread_enter] 110 0 0 0 SL zfs:(&tx 0xa58c031c [txg_thread_enter] 107 0 0 0 SL zfs:(&tq 0xa558a9e0 [spa_zio_intr_5] 106 0 0 0 SL zfs:(&tq 0xa558a9e0 [spa_zio_intr_5] 105 0 0 0 SL zfs:(&tq 0xa558a914 [spa_zio_issue_5] 104 0 0 0 SL zfs:(&tq 0xa558a914 [spa_zio_issue_5] 103 0 0 0 SL zfs:(&tq 0xa558a848 [spa_zio_intr_4] 102 0 0 0 SL zfs:(&tq 0xa558a848 [spa_zio_intr_4] 101 0 0 0 SL zfs:(&tq 0xa558a11c [spa_zio_issue_4] 100 0 0 0 SL zfs:(&tq 0xa558a11c [spa_zio_issue_4] 99 0 0 0 SL zfs:(&tq 0xa558a1e8 [spa_zio_intr_3] 98 0 0 0 SL zfs:(&tq 0xa558a1e8 [spa_zio_intr_3] 97 0 0 0 SL zfs:(&tq 0xa558a2b4 [spa_zio_issue_3] 96 0 0 0 SL zfs:(&tq 0xa558a2b4 [spa_zio_issue_3] 95 0 0 0 SL zfs:(&tq 0xa558a380 [spa_zio_intr_2] 94 0 0 0 SL zfs:(&tq 0xa558a380 [spa_zio_intr_2] 93 0 0 0 SL zfs:(&tq 0xa558a44c [spa_zio_issue_2] 92 0 0 0 SL zfs:(&tq 0xa558a44c [spa_zio_issue_2] 91 0 0 0 SL zfs:(&tq 0xa558a518 [spa_zio_intr_1] 90 0 0 0 SL zfs:(&tq 0xa558a518 [spa_zio_intr_1] 89 0 0 0 SL zfs:(&tq 0xa558a5e4 [spa_zio_issue_1] 88 0 0 0 SL zfs:(&tq 0xa558a5e4 [spa_zio_issue_1] 87 0 0 0 SL zfs:(&tq 0xa558a6b0 [spa_zio_intr_0] 86 0 0 0 SL zfs:(&tq 0xa558a6b0 [spa_zio_intr_0] 85 0 0 0 SL zfs:(&tq 0xa558a77c [spa_zio_issue_0] 84 0 0 0 SL zfs:(&tq 0xa558a77c [spa_zio_issue_0] 57 0 0 0 SL m:w1 0xa5894a00 [g_mirror gm0s1] 56 0 0 0 SL sdflush 0xa08aab64 [softdepflush] 55 0 0 0 RL [syncer] 54 0 0 0 SL vlruwt 0xa5b3e000 [vnlru] 53 0 0 0 SL psleep 0xa089bc44 [bufdaemon] 52 0 0 0 RL [pagezero] 51 0 0 0 SL psleep 0xa08ab338 [vmdaemon] 50 0 0 0 SL psleep 0xa08ab300 [pagedaemon] 49 0 0 0 SL gj:work 0xa5aff200 [g_journal ad4s2] 48 0 0 0 SL zgd 0xa0a03974 [zgd_done] 47 0 0 0 RL CPU 1 [arc_reclaim_thread] 46 0 0 0 SL jsw:wait 0xa088e834 [g_journal switcher] 45 0 0 0 SL waiting_ 0xa089f28c [sctp_iterator] 44 0 0 0 RL [swi0: sio] 43 0 0 0 WL [irq12: psm0] 42 0 0 0 WL [irq1: atkbd0] 41 0 0 0 WL [irq15: ata1] 40 0 0 0 WL [irq14: ata0] 39 0 0 0 SL usbevt 0xa55d2210 [usb4] 38 0 0 0 SL usbevt 0xa56b9210 [usb3] 37 0 0 0 RL [usb2] 36 0 0 0 RL [irq18: uhci2] 35 0 0 0 RL [usb1] 34 0 0 0 WL [irq19: uhci1++] 33 0 0 0 SL usbtsk 0xa088e454 [usbtask-dr] 32 0 0 0 SL usbtsk 0xa088e440 [usbtask-hc] 31 0 0 0 SL usbevt 0xa56a3210 [usb0] 30 0 0 0 WL [irq17: uhci0 ehci0] 29 0 0 0 SL idle 0xa5689000 [mpt_recovery0] 28 0 0 0 RL [em0 taskq] 27 0 0 0 RL [irq16: nvidia0+++] 26 0 0 0 WL [irq9: acpi0] 25 0 0 0 SL - 0xa5568900 [kqueue taskq] 24 0 0 0 WL [swi6: task queue] 23 0 0 0 SL - 0xa5568a80 [acpi_task_2] 22 0 0 0 SL - 0xa5568a80 [acpi_task_1] 21 0 0 0 SL - 0xa5568a80 [acpi_task_0] 20 0 0 0 WL [swi6: Giant taskq] 19 0 0 0 SL - 0xa5568c00 [thread taskq] 18 0 0 0 WL [swi5: +] 17 0 0 0 WL [swi2: cambio] 9 0 0 0 SL ccb_scan 0xa0878654 [xpt_thrd] 16 0 0 0 RL [yarrow] 8 0 0 0 SL crypto_r 0xa08aa354 [crypto returns] 7 0 0 0 SL crypto_w 0xa08aa32c [crypto] 6 0 0 0 SL zfs:(&tq 0xa558a050 [system_taskq] 5 0 0 0 SL zfs:(&tq 0xa558a050 [system_taskq] 4 0 0 0 SL - 0xa088e7ec [g_down] 3 0 0 0 SL - 0xa088e7e8 [g_up] 2 0 0 0 SL - 0xa088e7e0 [g_event] 15 0 0 0 WL [swi3: vm] 14 0 0 0 RL [swi4: clock sio] 13 0 0 0 WL [swi1: net] 12 0 0 0 RL [idle: cpu0] 11 0 0 0 RL [idle: cpu1] 1 0 1 0 SLs wait 0xa5528ab0 [init] 10 0 0 0 SL audit_wo 0xa08aa5b8 [audit] 0 0 0 0 WLs [swapper] db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xa5ebe440: pid 3422 "txg_thread_enter" curpcb = 0xeb175d90 fpcurthread = none idlethread = 0xa5529aa0: pid 12 "idle: cpu0" APIC ID = 0 currentldt = 0x50 cpuid = 1 curthread = 0xa56ab220: pid 47 "arc_reclaim_thread" curpcb = 0xe6837d90 fpcurthread = none idlethread = 0xa5529880: pid 11 "idle: cpu1" APIC ID = 1 currentldt = 0x50 db> reboot cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 --------------060002070804090203090509 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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" --------------060002070804090203090509-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 18:18:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DDFE16A41A for ; Fri, 14 Dec 2007 18:18:39 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id 4216D13C455 for ; Fri, 14 Dec 2007 18:18:39 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se (c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.130]) by smtp.infidyne.com (Postfix) with ESMTP id 9A35E755AB; Fri, 14 Dec 2007 19:18:37 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Fri, 14 Dec 2007 19:20:23 +0100 User-Agent: KMail/1.9.7 References: <47606C09.2070209@isc.org> <47609FE3.8040606@barafranca.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2951599.g1pyaAQCj7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712141920.32937.peter.schuller@infidyne.com> Cc: Kip Macy , Benjamin Close , Hugo Silva Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 18:18:39 -0000 --nextPart2951599.g1pyaAQCj7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > Yes. However, FreeBSD suffers from deadlocks under load if ZIL is enabled. Is there some ML post / documentation on this? I am trying to keep up-to-da= te=20 on ZFS status (on FreeBSD and otherwise), but I don't think this has been=20 discussed on any of the usual mailing lists. =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart2951599.g1pyaAQCj7 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) iD8DBQBHYslwDNor2+l1i30RAs2iAKCvcL9lPVvdDgzVIvMoxQszlT8VuQCfTjj/ ISCjxHGLozD4nttc1Xk2d/g= =oFln -----END PGP SIGNATURE----- --nextPart2951599.g1pyaAQCj7-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 18:21:58 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EF6716A41A for ; Fri, 14 Dec 2007 18:21:58 +0000 (UTC) (envelope-from qpadla@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 F175E13C4D3 for ; Fri, 14 Dec 2007 18:21:57 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1452403uge.37 for ; Fri, 14 Dec 2007 10:21:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=+Ag3ClWoRUxrT+nwluP9Q5tlVHDIpTWq1hkduYwcnWM=; b=UOl3Ypqdz+ppdHuZXKPBmx/k9CrIlXnZazBOtlrocNR3YhVge2WWuoJWr78HWnqf7a03xRcIS4Z+BupqeqgmM6LTxZMJ/O+lmDgb0nes7hqGCP+wHakCKLk6gtge4G/UnsRORInBsotIUWdMLP5qONuibcCeJ4beRt0VgPq7lec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=OqJT0yH71cw+GMjk7Oit57B7fJ579c+CMnsbjBVSo61s372e8iPEkerVbbMVWT2+S34OylWPmPcVTPO5DG5AO4k/i6FC9/GkARoaqrwtSmCXgrDqNIArcNFXOX086xeNXOpBlmCsl8iaKzskME57ddZBj6dnhMWLWM5XmtfCOxE= Received: by 10.78.201.15 with SMTP id y15mr4575049huf.38.1197656513050; Fri, 14 Dec 2007 10:21:53 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id u9sm22313437muf.2007.12.14.10.21.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2007 10:21:51 -0800 (PST) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Fri, 14 Dec 2007 20:21:48 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <72123.1197626129@critter.freebsd.dk> In-Reply-To: <72123.1197626129@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1304564.LecKMEXKHz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712142021.48724.qpadla@gmail.com> Cc: Poul-Henning Kamp Subject: Re: [RFC] Automated generation of /etc/resolv.conf from the rc.d script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 18:21:58 -0000 --nextPart1304564.LecKMEXKHz Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 14 December 2007 11:55:29 Poul-Henning Kamp wrote: > In message <7ExUpek150AdEdP4WR1b6w@lz+EvuNSgXKgs9kqjMxQNA>, Eygene=20 Ryabinkin writes: > >But there is one bit that > >I am missing with the current /etc/rc.d scripts: automated construction > >of /etc/resolv.conf basing on the variables from /etc/rc.conf. > > It's worse than that. > > It should be possible to run a local named even when we run DHCP, > and it shuld be an option, to have it automatically forward to the > DNS servers we learn from DHCP. Why not to use nscd? Or do you want to serve local zones in addition? =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart1304564.LecKMEXKHz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHYsm8/2R6KvEYGaIRAiyqAKCIQkJLjzU8warfNBpsCquTeLgaVwCfV27j W5D2jaYP2MiQgUeNw0LdYg8= =KeoG -----END PGP SIGNATURE----- --nextPart1304564.LecKMEXKHz-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 18:39:16 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 112B316A419 for ; Fri, 14 Dec 2007 18:39:16 +0000 (UTC) (envelope-from qpadla@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 7D86713C47E for ; Fri, 14 Dec 2007 18:39:15 +0000 (UTC) (envelope-from qpadla@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1457827uge.37 for ; Fri, 14 Dec 2007 10:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; bh=9uwpmWS1TIqlIzlMMRIR+z+V83xjPl9kybVpBc3Rxa8=; b=kaeJZ2HPnyQHoixcb+aJbOsroHAwvf5wMupzMN+RDVEjxFBKXKsqxTRFPDVzJPWxrJQAqRitgA0V/2F/ltvqU7DCwug0bc32njif2xTxkZCP+31zZn5Keyqml0xg49CyK7lX6I8UukyGte5jt8iPo2tzBR93Lo2RIQtiSs9X74w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:message-id; b=dXDj5cwzUic+WAhry+t812ghXdrfhbvU4YcacIYPnep3AT865n+NyPjbZHEBrRJ2SluWUWogcAi5MMEJ9Jk/BGFxAubLcYhNbr/vHZp2wy1unvfLvXT7TNwWPJq3t+VE/WMS12088QLUdsDbi84lOHkeQnJGpLuHzYh1omsvrAQ= Received: by 10.78.162.4 with SMTP id k4mr4589700hue.66.1197657553633; Fri, 14 Dec 2007 10:39:13 -0800 (PST) Received: from orion ( [89.162.141.1]) by mx.google.com with ESMTPS id y6sm22384570mug.2007.12.14.10.39.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Dec 2007 10:39:10 -0800 (PST) From: Nikolay Pavlov To: freebsd-current@freebsd.org Date: Fri, 14 Dec 2007 20:39:07 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <72389.1197629858@critter.freebsd.dk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4613370.M3EtAJ3uH5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712142039.07590.qpadla@gmail.com> Cc: Poul-Henning Kamp Subject: Re: [RFC] Automated generation of /etc/resolv.conf from the rc.d script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qpadla@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 18:39:16 -0000 --nextPart4613370.M3EtAJ3uH5 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 14 December 2007 13:07:00 Eygene Ryabinkin wrote: > Fri, Dec 14, 2007 at 10:57:38AM +0000, Poul-Henning Kamp wrote: > > In message ,=20 Eygene Ryabinkin writes: > > >> It should be possible to run a local named even when we run DHCP, > > >> and it shuld be an option, to have it automatically forward to the > > >> DNS servers we learn from DHCP. > > > > > >This can be achieved with the script /etc/dhclient-exit-hooks that > > >will create the file with named 'forwarders' clause [...] > > > > Yes, I know that, but I would like to see it controllable from rc.conf > > like the rest of our network configuration. > > OK, since running local DNS instance is a neat idea, I will try to > draft the modifications for the dhclient-exit-hooks, as I described > in the previous mail. > > Just now I see no other way to implement it, because dhclient is > asynchronious in the general case, so I can not teach /etc/rc.d/dhclient > to do the job. So I expect that /etc/dhclient-exit-hooks will be > born and it will build 'forwarders' file for the named, if this > will be requested by /etc/rc.conf. > > I still not sure how to modify named.conf: automatically or let the > user make the needed modifications. I am inclined to the latter, > but this can pose some troubles to the users that are not very > familiar with named.conf. Any thoughts? > > If you have other ideas how it can be done, please share. > > Thanks! Hi Eygene. You might get some ideas from this implementation then: http://packages.debian.org/sid/resolvconf At least it contains those ugly sed expression to edit forwarders in a=20 named.conf. =2D-=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =2D Best regards, Nikolay Pavlov. <<<----------------------------------- = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 --nextPart4613370.M3EtAJ3uH5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHYs3L/2R6KvEYGaIRAlodAKCsSqxJredmVMMfMSH+55I5untrwgCePciL aPHcI0rNXxJfzhI31Dw8N8Y= =uwjR -----END PGP SIGNATURE----- --nextPart4613370.M3EtAJ3uH5-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 18:51:56 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F3C016A418 for ; Fri, 14 Dec 2007 18:51:56 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 08D1613C44B for ; Fri, 14 Dec 2007 18:51:55 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=etjb+fTucHjORNRWL9SOS1iifk74sOZaJAUVnKIV54Og2j/hPlXOZUXaUzxEEeQpl596QQPvcwha2xFMWPNL8aMyHFGLdKvqJkhx4X2zF5jnp4FaaBquWqU3cMK8VCBzyo8fgCQoAzTYs05EIOlhJVpPpHUAxYH/sA65eX8tXx4=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1J3Fda-000AI6-2t; Fri, 14 Dec 2007 21:51:54 +0300 Date: Fri, 14 Dec 2007 21:51:52 +0300 From: Eygene Ryabinkin To: Nikolay Pavlov Message-ID: References: <72389.1197629858@critter.freebsd.dk> <200712142039.07590.qpadla@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200712142039.07590.qpadla@gmail.com> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-2.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_40 Cc: freebsd-current@freebsd.org Subject: Re: [RFC] Automated generation of /etc/resolv.conf from the rc.d script X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 18:51:56 -0000 Nikolay, good day. Fri, Dec 14, 2007 at 08:39:07PM +0200, Nikolay Pavlov wrote: > You might get some ideas from this implementation then: > http://packages.debian.org/sid/resolvconf > At least it contains those ugly sed expression to edit forwarders in a > named.conf. Will look at it. Thanks for the pointer! -- Eygene From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 18:57:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EEA016A417 for ; Fri, 14 Dec 2007 18:57:36 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from mx2.confluenttech.com (mx2.confluentasp.com [216.26.153.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8AF9713C465 for ; Fri, 14 Dec 2007 18:57:30 +0000 (UTC) (envelope-from mikej@paymentallianceintl.com) Received: from calvin.pai.local ([10.0.6.33]) by mx2.confluenttech.com (8.14.1/8.12.9) with ESMTP id lBEIMweM055607 for ; Fri, 14 Dec 2007 13:23:14 -0500 (EST) (envelope-from mikej@paymentallianceintl.com) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Content-class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Date: Fri, 14 Dec 2007 13:13:54 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 7.0-BETA4 - witness_warn on boot Thread-Index: Acg+UgGpCL5rSjc7SyCq8MAtvXhE5QAA/vFgAAnDzTA= References: From: "Michael Jung" To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 7.0-BETA4 - witness_warn on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 18:57:36 -0000 I was running 7.0-BETA4 and had problems with SEG_FAULT 12 in g_up so I rebuilt a stock GENERIC kernel with these additional options: options KDB option DDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC Here is the build date: FreeBSD charon.confluentasp.com 7.0-BETA4 FreeBSD 7.0-BETA4 #6: Tue Dec 11 09:05:50 EST 2007 mikej@charon.confluentasp.com:/usr/obj/usr/src/sys/CHARON i386 (I cvsup'd source on this day just prior to kernel build - tag=RELENG_7) Now when my SCSI array is plugged into the AHA-2944 controller the kernel panics on boot. If the array is not plugged into the controller the system boots and runs fine. I've read the handbook and tried to follow what posts I read as to what would be of use in trouble shooting this. Please don't shoot the messenger. I'll be glad to supply and additional information - this box is not in production so I'm willing to try anything. Just to note, the controller and array had been in production under 6.2-RELEASE and prior versions and has been running for years without any problems. Thanks. --mikej KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-BETA4 #6: Tue Dec 11 09:05:50 EST 2007 mikej@charon.confluentasp.com:/usr/obj/usr/src/sys/CHARON WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile AMD Sempron(tm) Processor 3000+ (1799.81-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20fc2 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xc2500800 AMD Features2=0x1 real memory = 1005453312 (958 MB) avail memory = 969691136 (924 MB) ACPI APIC Table: WITNESS: spin lock intrcnt not in order list ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3bde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 powernow0: on cpu0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xf0000000-0xf3ffffff,0xf4000000-0xf4ffffff irq 16 at device 0.0 on pci1 pcib2: at device 8.0 on pci0 pci2: on pcib2 ahc0: port 0xc000-0xc0ff mem 0xf6013000-0xf6013fff irq 16 at device 4.0 on pci2 ahc0: [ITHREAD] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs ahc1: port 0xc400-0xc4ff mem 0xf6010000-0xf6010fff irq 17 at device 5.0 on pci2 ahc1: [ITHREAD] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs ahc2: port 0xc800-0xc8ff mem 0xf6011000-0xf6011fff irq 18 at device 6.0 on pci2 ahc2: [ITHREAD] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs ahc3: port 0xcc00-0xccff mem 0xf6012000-0xf6012fff irq 19 at device 7.0 on pci2 ahc3: [ITHREAD] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs atapci0: port 0xe100-0xe107,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xe000-0xe00f,0x d000-0xd0ff irq 20 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe200-0xe20f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xe300-0xe31f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe400-0xe41f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe500-0xe51f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xe600-0xe61f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xf6100000-0xf61000ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 pci0: at device 17.5 (no driver attached) vr0: port 0xdc00-0xdcff mem 0xf6101000-0xf61010ff irq 23 at device 18.0 on pci0 vr0: Quirks: 0x0 miibus0: on vr0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: using obsoleted if_watchdog interface vr0: Ethernet address: 00:e0:4d:0a:1b:e6 vr0: [ITHREAD] acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xcc000-0xcc7ff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 plip0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1799808459 Hz quality 800 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle ad4: 381554MB at ata2-master SATA150 suspending ithread with the following locks held: exclusive sleep mutex XPT lock r = 0 (0xc0b883a4) locked @ /usr/src/sys/cam/cam_xpt.c:3852 panic: witness_warn cpuid = 0 KDB: enter: panic [thread pid 18 tid 100016 ] Stopped at kdb_enter+0x32: leave db> ps pid ppid pgrp uid state wmesg wchan cmd 53 0 0 0 SL waiting_ 0xc0c084cc [sctp_iterator] 52 0 0 0 WL [irq7: ppc0] 51 0 0 0 WL [irq12: psm0] 50 0 0 0 WL [irq1: atkbd0] 49 0 0 0 WL [swi0: sio] 48 0 0 0 SL - 0xc401f23c [fdc0] 47 0 0 0 SL cooling 0xc3fedad4 [acpi_cooling0] 46 0 0 0 SL tzpoll 0xc0d85d40 [acpi_thermal] 45 0 0 0 WL [irq23: vr0] 44 0 0 0 SL usbevt 0xc3fe4210 [usb4] 43 0 0 0 SL usbevt 0xc3ffb210 [usb3] 42 0 0 0 SL usbevt 0xc3ff5210 [usb2] 41 0 0 0 SL usbevt 0xc3fee210 [usb1] 40 0 0 0 SL usbtsk 0xc0bb7174 [usbtask-dr] 39 0 0 0 SL usbtsk 0xc0bb7160 [usbtask-hc] 38 0 0 0 SL usbevt 0xc3fc8210 [usb0] 37 0 0 0 WL [irq21: uhci0 uhci*] 36 0 0 0 WL [irq15: ata1] 35 0 0 0 WL [irq14: ata0] --More-- 34 0 0 0 WL [irq20: atapci0] 33 0 0 0 SL idle 0xc3ef1e00 [aic_recovery3] 32 0 0 0 RL [irq19: ahc3] 31 0 0 0 SL idle 0xc3ef1e00 [aic_recovery3] 30 0 0 0 SL idle 0xc3ef1400 [aic_recovery2] 29 0 0 0 RL [irq18: ahc2] 28 0 0 0 SL idle 0xc3ef1400 [aic_recovery2] 27 0 0 0 SL idle 0xc3ef0a00 [aic_recovery1] 26 0 0 0 RL [irq17: ahc1] 25 0 0 0 SL idle 0xc3ef0a00 [aic_recovery1] 24 0 0 0 SL idle 0xc3ef0c00 [aic_recovery0] 23 0 0 0 WL [irq16: ahc0] 22 0 0 0 SL idle 0xc3ef0c00 [aic_recovery0] 21 0 0 0 WL [irq9: acpi0] 20 0 0 0 SL - 0xc3ed9580 [thread taskq] 19 0 0 0 WL [swi5: +] 18 0 0 0 RL CPU 0 [swi2: cambio] 9 0 0 0 SL ccb_scan 0xc0b88374 [xpt_thrd] 8 0 0 0 SL - 0xc3ed9900 [acpi_task_2] 7 0 0 0 SL - 0xc3ed9900 [acpi_task_1] --More-- 6 0 0 0 SL - 0xc3ed9900 [acpi_task_0] 5 0 0 0 SL - 0xc3ed9980 [kqueue taskq] 17 0 0 0 WL [swi6: task queue] 16 0 0 0 WL [swi6: Giant taskq] 15 0 0 0 SL - 0xc0bb94d4 [yarrow] 4 0 0 0 SL - 0xc0bb754c [g_down] 3 0 0 0 SL - 0xc0bb7548 [g_up] 2 0 0 0 SL - 0xc0bb7540 [g_event] 14 0 0 0 WL [swi3: vm] 13 0 0 0 RL [swi4: clock sio] 12 0 0 0 WL [swi1: net] 11 0 0 0 RL [idle: cpu0] 1 0 0 0 ?L [swapper] 10 0 0 0 SL audit_wo 0xc0c11ad4 [audit] 0 0 0 0 SLs conifhk 0xc0b599ec [swapper] db> show reg cs 0x20 ds 0x28 es 0x28 fs 0x8 ss 0x28 eax 0x12 ecx 0xc1434bde edx 0 ebx 0x100 esp 0xe175cc5c ebp 0xe175cc64 esi 0x1 edi 0xc3dea210 eip 0xc0777ca2 kdb_enter+0x32 efl 0x80282 kdb_enter+0x32: leave db> show locks exclusive sleep mutex XPT lock r = 0 (0xc0b883a4) locked @ /usr/src/sys/cam/cam_xpt.c:3852 db> show lockedvnods Locked vnodes db> bt Tracing pid 18 tid 100016 td 0xc3dea210 kdb_enter(c0aa2af2,0,c0aa7718,e175cc9c,0,...) at kdb_enter+0x32 panic(c0aa7718,e175ccd8,0,0,0,...) at panic+0x124 witness_warn(2,0,c0a9f7d0,471,c3ed97e4,...) at witness_warn+0x19c ithread_loop(c3ed80d0,e175cd38,c0a9f445,2ea,c3ee42ac,...) at ithread_loop+0x2ca fork_exit(c0735670,c3ed80d0,e175cd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe175cd70, ebp = 0 --- db> CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 11857 Commonwealth Drive, Louisville, KY 40299. Thank you. From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 19:35:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30D9516A420 for ; Fri, 14 Dec 2007 19:35:04 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8AA13C457 for ; Fri, 14 Dec 2007 19:35:03 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J3GHJ-0004Rf-Tp for freebsd-current@freebsd.org; Fri, 14 Dec 2007 19:32:57 +0000 Received: from 78-0-85-236.adsl.net.t-com.hr ([78.0.85.236]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Dec 2007 19:32:57 +0000 Received: from ivoras by 78-0-85-236.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Dec 2007 19:32:57 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 14 Dec 2007 20:29:56 +0100 Lines: 53 Message-ID: References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1A1DEE1A2CE5DCBF3237FE53" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-85-236.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 19:35:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1A1DEE1A2CE5DCBF3237FE53 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable David Duchscher wrote: > On Dec 14, 2007, at 6:57 AM, Dag-Erling Sm=C3=B8rgrav wrote: >=20 >> David Duchscher writes: >>> So does anybody know of a battery backed NVRAM card that can be used >>> with FreeBSD that the ZIL could be offloaded to? >> >> Any CF card or similar will do. You don't need battery backup for >> flash memory. >=20 > I did think of that but is a CF card faster than a good SAS or SATA > drive?=20 Not in transfer rate, but it could help hugely with seek-intensive IO loads (since seeks are instantaneous on flash or other solid-state drives). In theory, they could be of immense benefit for databases and seek-intensive operations on file systems, but the limited bulk transfer rates and relatively small sizes (for decent money) currently prevent their wide-spread use. It would be logical to use a limited size SSD for something like a file system journal for a large file system, except that these kind of journals are usually not seek-intensive :) > Fastest ones I found have a top rating of 45MB/s. The one > battery backed NVARM card that showed up in a google search had a peak > rate of 533MB/s. The question seems moot though since FreeBSD doesn't > currently support them. If a NVRAM or SSD, or other technology presents the drive as a (S)ATA drive, there's no reason it shouldn't. --------------enig1A1DEE1A2CE5DCBF3237FE53 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 iD8DBQFHYtm5ldnAQVacBcgRAuFqAKCMNnIyN55dgZ8C8SYfXPuTHAEUGACgyh4l 9zh8woR+VEufqAF8aCLjQik= =S9hA -----END PGP SIGNATURE----- --------------enig1A1DEE1A2CE5DCBF3237FE53-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 19:41:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0088416A417 for ; Fri, 14 Dec 2007 19:41:41 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9D2FA13C4D3 for ; Fri, 14 Dec 2007 19:41:40 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1J3GOA-0006oV-Rt for freebsd-current@freebsd.org; Fri, 14 Dec 2007 19:40:02 +0000 Received: from 78-0-85-236.adsl.net.t-com.hr ([78.0.85.236]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Dec 2007 19:40:02 +0000 Received: from ivoras by 78-0-85-236.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Dec 2007 19:40:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Fri, 14 Dec 2007 20:32:18 +0100 Lines: 34 Message-ID: References: <47606C09.2070209@isc.org> <47609FE3.8040606@barafranca.com> <200712141920.32937.peter.schuller@infidyne.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC2DE4124C7AD7DB581709D5A" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-85-236.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <200712141920.32937.peter.schuller@infidyne.com> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 19:41:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC2DE4124C7AD7DB581709D5A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter Schuller wrote: >> Yes. However, FreeBSD suffers from deadlocks under load if ZIL is enab= led. >=20 > Is there some ML post / documentation on this? I am trying to keep up-t= o-date=20 > on ZFS status (on FreeBSD and otherwise), but I don't think this has be= en=20 > discussed on any of the usual mailing lists. Should I open a page on wiki.freebsd.org to account the ZFS-related bugs?= :) --------------enigC2DE4124C7AD7DB581709D5A 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 iD8DBQFHYtpDldnAQVacBcgRAp9lAKCMDLjXd8PPTssHcobTxXxzabr9EQCgoCrK w/1xN501LRHT9h1LxuTZn8I= =4qt9 -----END PGP SIGNATURE----- --------------enigC2DE4124C7AD7DB581709D5A-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 21:01:48 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18C3E16A468 for ; Fri, 14 Dec 2007 21:01:48 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from smtp.vzavenue.net (smtp.vzavenue.net [66.171.59.140]) by mx1.freebsd.org (Postfix) with ESMTP id BAE8A13C45B for ; Fri, 14 Dec 2007 21:01:47 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from 98.79.171.66.subscriber.vzavenue.net (HELO homobox.opal.com) ([66.171.79.98]) by smtp.vzavenue.net with ESMTP; 14 Dec 2007 15:32:35 -0500 X-REPUTATION: None X-REMOTE-IP: 66.171.79.98 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAON1YkdCq09i/2dsb2JhbACBWohUnz8 X-IronPort-AV: i="4.24,169,1196658000"; d="asc'?scan'208"; a="172723310:sNHT21812931" Received: from linwhf.opal.com (localhost [127.0.0.1]) (authenticated bits=0) by homobox.opal.com (8.13.8/8.13.8) with ESMTP id lBEKWYjf077409 for ; Fri, 14 Dec 2007 15:32:34 -0500 (EST) (envelope-from fbsd@opal.com) Received: from linwhf.opal.com ([192.168.3.65] helo=linwhf.opal.com) by ASSP-nospam; 14 Dec 2007 15:32:34 -0500 Date: Fri, 14 Dec 2007 15:32:29 -0500 From: "J.R. Oldroyd" To: freebsd-current@freebsd.org Message-ID: <20071214153229.17383065@linwhf.opal.com> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-unknown-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/77qU.+OSP7ZSI7qVKYHCr/M"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Mailman-Approved-At: Fri, 14 Dec 2007 21:18:00 +0000 Subject: deprecate ftp-proxy in favor of ftp/pftpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 21:01:48 -0000 --Sig_/77qU.+OSP7ZSI7qVKYHCr/M Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The two main tools most users appear to use for FTP, viz ftp and firefox, do not work well with ftp-proxy any more. While ftp can be configured to work, firefox cannot. The problem is that ftp-proxy only supports active mode connections and firefox only supports passive ones. Ftp, itself, defaults to passive (or even epsv4) and has to be configured to default to active. The port ftp/pftpx is an alternate FTP proxy which handles passive and epsv4 just fine. Is it time to deprecate ftp-proxy and elevate ftp/pftpx to the base system and recommend its use instead? -jr =20 --Sig_/77qU.+OSP7ZSI7qVKYHCr/M Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHYuhdls33urr0k4kRAugIAJ9McKwb0g4cSoyfM3oTTVsKeY9TUwCdHh7+ KUB9vkBAqFVG/8KDS6XB6rk= =TY5r -----END PGP SIGNATURE----- --Sig_/77qU.+OSP7ZSI7qVKYHCr/M-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 21:30:41 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26CAC16A420 for ; Fri, 14 Dec 2007 21:30:41 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from galain.elvandar.org (galain.elvandar.org [217.148.169.56]) by mx1.freebsd.org (Postfix) with ESMTP id D186E13C46B for ; Fri, 14 Dec 2007 21:30:40 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from evilcoder.xs4all.nl ([195.64.94.120] helo=elvandar.local) by galain.elvandar.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J3I7D-000CHa-QQ; Fri, 14 Dec 2007 22:30:39 +0100 Message-ID: <4762F626.4080809@FreeBSD.org> Date: Fri, 14 Dec 2007 22:31:18 +0100 From: Remko Lodder User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "J.R. Oldroyd" References: <20071214153229.17383065@linwhf.opal.com> In-Reply-To: <20071214153229.17383065@linwhf.opal.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-current@freebsd.org Subject: Re: deprecate ftp-proxy in favor of ftp/pftpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 21:30:41 -0000 J.R. Oldroyd wrote: > The two main tools most users appear to use for FTP, viz ftp > and firefox, do not work well with ftp-proxy any more. While > ftp can be configured to work, firefox cannot. The problem is > that ftp-proxy only supports active mode connections and firefox > only supports passive ones. Ftp, itself, defaults to passive > (or even epsv4) and has to be configured to default to active. > > The port ftp/pftpx is an alternate FTP proxy which handles > passive and epsv4 just fine. > > Is it time to deprecate ftp-proxy and elevate ftp/pftpx to the > base system and recommend its use instead? > > -jr > I am a bit sceptical against this because ftp-proxy is a tool derived from OpenBSD ( afair ) and it works very well together with PF and things like that. Max: Your thoughts? :) -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 21:39:17 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 191B716A417 for ; Fri, 14 Dec 2007 21:39:17 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 8E48713C467 for ; Fri, 14 Dec 2007 21:39:16 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-064-177-134.pools.arcor-ip.net [88.64.177.134]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1J3IFX09km-0003Xl; Fri, 14 Dec 2007 22:39:15 +0100 From: Max Laier Organization: FreeBSD To: Remko Lodder Date: Fri, 14 Dec 2007 22:39:04 +0100 User-Agent: KMail/1.9.7 References: <20071214153229.17383065@linwhf.opal.com> <4762F626.4080809@FreeBSD.org> In-Reply-To: <4762F626.4080809@FreeBSD.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2144223.h2Xy4a60yB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712142239.13422.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+g5ABLxvssPYrJ76EON8yhaywiWTlxn0H7jOQ wTWdMOBtQT/zeKoSWSoKLSdi9yGXoJ67b7TN10DEsNy2zAMPU9 rR/iAS//K8elr5vZ0E/NVmSWf/ILjrr4NDsKKXY/1Y= Cc: freebsd-current@freebsd.org, "J.R. Oldroyd" Subject: Re: deprecate ftp-proxy in favor of ftp/pftpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 21:39:17 -0000 --nextPart2144223.h2Xy4a60yB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 14 December 2007, Remko Lodder wrote: > J.R. Oldroyd wrote: > > The two main tools most users appear to use for FTP, viz ftp > > and firefox, do not work well with ftp-proxy any more. While > > ftp can be configured to work, firefox cannot. The problem is > > that ftp-proxy only supports active mode connections and firefox > > only supports passive ones. Ftp, itself, defaults to passive > > (or even epsv4) and has to be configured to default to active. > > > > The port ftp/pftpx is an alternate FTP proxy which handles > > passive and epsv4 just fine. > > > > Is it time to deprecate ftp-proxy and elevate ftp/pftpx to the > > base system and recommend its use instead? > > > > -jr > > I am a bit sceptical against this because ftp-proxy is a tool derived > from OpenBSD ( afair ) and it works very well together with PF and > things like that. > > Max: Your thoughts? :) This is a bit of a confuseing situation, but I'll try to explain: In RELENG_6 we have the OpenBSD 3.7 derived ftp-proxy (which has some=20 shortcomings, but I don't feel that switching it for a completely=20 different version will be in POLA compliant). In RELENG_7 and HEAD we have the OpenBSD 4.1 derived ftp-proxy (which is a= =20 completely different tool). IIRC, the pftpx project started off of OpenBSD's ftp-proxy which later=20 merged in the changes from the pftpx project and added further=20 improvements. Bottom line: The ftp-proxy in HEAD and RELENG_7 is believed to work, if it= =20 doesn't please submit details to freebsd-pf@ This version of ftp-proxy=20 can be obtained from the ports collection for RELENG_6, too=20 (ftp/ftp-proxy) and is believed to supercede pftpx. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2144223.h2Xy4a60yB 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) iD8DBQBHYvgBXyyEoT62BG0RAhmWAJoDp3rVn3edDlTDWmjmixKAo+WJCQCeJxIO boqRL3LxW3/6F6m/iI2W5qA= =NJLq -----END PGP SIGNATURE----- --nextPart2144223.h2Xy4a60yB-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 22:16:32 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9BED16A418 for ; Fri, 14 Dec 2007 22:16:32 +0000 (UTC) (envelope-from SRS0=be4de6480801af553ad9ecfe07bae72c734ddbd9=549=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3E513C448 for ; Fri, 14 Dec 2007 22:16:32 +0000 (UTC) (envelope-from SRS0=be4de6480801af553ad9ecfe07bae72c734ddbd9=549=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id TIE29831 for ; Fri, 14 Dec 2007 14:16:31 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 0AE8645014 for ; Fri, 14 Dec 2007 14:16:31 -0800 (PST) To: current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1197670590_6001P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 14 Dec 2007 14:16:31 -0800 From: "Kevin Oberman" Message-Id: <20071214221631.0AE8645014@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; X-Sender: X-To_Name: X-To_Domain: freebsd.org X-To: current@freebsd.org X-To_Email: current@freebsd.org X-To_Alias: current Cc: Subject: Dust out your heat syncs! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 22:16:32 -0000 --==_Exmh_1197670590_6001P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is a bit off topic, but I have commented on the issue of dusty heat syncs in the past. With the recent discussion of the high temps generated by the last V7-beta on some systems (not mine), I thought that I would remind folks. I just dusted out my 2.5 year old laptop (2 GHz Pentium-M) and the difference was impressive. (And so was the cloud of dust I blew out!) Quiescent temperature dropped from 60C to 53C and the peak temperature during a kernel build dropped from a very toasty 90C to a comfortable 72C. 18C (32F) is a huge improvement! The dust either a laptop or a tower can collect is impressive, even in a fairly clean environment. I suspect an annual cleaning of heat syncs could significantly increase both the reliability and lifetime of systems. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1197670590_6001P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHYwC+kn3rs5h7N1ERArTCAKCgb7k+Sf8eT7AkngRt8IhngELp4wCeJ+yA 2eh8XH/CrMqFPzwz5kqRw1w= =jsQ6 -----END PGP SIGNATURE----- --==_Exmh_1197670590_6001P-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 22:07:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E63F016A420 for ; Fri, 14 Dec 2007 22:07:29 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from smtp.vzavenue.net (smtp.vzavenue.net [66.171.59.140]) by mx1.freebsd.org (Postfix) with ESMTP id 792E813C46B for ; Fri, 14 Dec 2007 22:07:29 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from 98.79.171.66.subscriber.vzavenue.net (HELO homobox.opal.com) ([66.171.79.98]) by smtp.vzavenue.net with ESMTP; 14 Dec 2007 17:07:28 -0500 X-REPUTATION: None X-REMOTE-IP: 66.171.79.98 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAPODYkdCq09i/2dsb2JhbACBWqge X-IronPort-AV: i="4.24,169,1196658000"; d="asc'?scan'208"; a="172728970:sNHT21207375" Received: from linwhf.opal.com (localhost [127.0.0.1]) (authenticated bits=0) by homobox.opal.com (8.13.8/8.13.8) with ESMTP id lBEM7RBf078363; Fri, 14 Dec 2007 17:07:27 -0500 (EST) (envelope-from fbsd@opal.com) Received: from linwhf.opal.com ([192.168.3.65] helo=linwhf.opal.com) by ASSP-nospam; 14 Dec 2007 17:07:27 -0500 Date: Fri, 14 Dec 2007 17:07:22 -0500 From: "J.R. Oldroyd" To: Max Laier Message-ID: <20071214170722.5e5853c3@linwhf.opal.com> In-Reply-To: <200712142239.13422.max@love2party.net> References: <20071214153229.17383065@linwhf.opal.com> <4762F626.4080809@FreeBSD.org> <200712142239.13422.max@love2party.net> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-unknown-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/kFIHJ8nFlh3I_03bmVq4zXC"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Mailman-Approved-At: Fri, 14 Dec 2007 22:18:35 +0000 Cc: Remko Lodder , freebsd-current@freebsd.org Subject: Re: deprecate ftp-proxy in favor of ftp/pftpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 22:07:30 -0000 --Sig_/kFIHJ8nFlh3I_03bmVq4zXC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 14 Dec 2007 22:39:04 +0100, Max Laier wrote: >=20 > Bottom line: The ftp-proxy in HEAD and RELENG_7 is believed to work, if i= t=20 > doesn't please submit details to freebsd-pf@ This version of ftp-proxy=20 > can be obtained from the ports collection for RELENG_6, too=20 > (ftp/ftp-proxy) and is believed to supercede pftpx. >=20 Hmm. I wonder if the new ftp-proxy requires a different config in pf.conf or something, then? I'll post a follow-up to freebsd-pf@ and continue this there, but, for me, ftp-proxy no longer works and pftpx just worked. -jr --Sig_/kFIHJ8nFlh3I_03bmVq4zXC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHYv6als33urr0k4kRAt2YAJ46Ew2LOyXwE1+mZyHqSObBFn8NcQCbBSVv xZ0mB5Zl1MGTzaBrT4dYg8U= =hR9d -----END PGP SIGNATURE----- --Sig_/kFIHJ8nFlh3I_03bmVq4zXC-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 22:22:33 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7EB716A418; Fri, 14 Dec 2007 22:22:33 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.freebsd.org (Postfix) with ESMTP id 274EE13C45B; Fri, 14 Dec 2007 22:22:33 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-064-177-134.pools.arcor-ip.net [88.64.177.134]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1J3IvN3srX-0001v9; Fri, 14 Dec 2007 23:22:30 +0100 From: Max Laier Organization: FreeBSD To: "J.R. Oldroyd" Date: Fri, 14 Dec 2007 23:22:22 +0100 User-Agent: KMail/1.9.7 References: <20071214153229.17383065@linwhf.opal.com> <200712142239.13422.max@love2party.net> <20071214170722.5e5853c3@linwhf.opal.com> In-Reply-To: <20071214170722.5e5853c3@linwhf.opal.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9690532.kjMzpJAIj7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200712142322.29072.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+RzWr9h2aGjur+0lbzFI7p0+pxzjNV12I1ezF OYRAQcnkxsQ3unwij61OgKbaNvtuNbaQIksi81wTlq79auq1lZ c1mprgpwdmJY3wKWQxtDZriCK/tpv2itEz4BIlpuWg= Cc: Remko Lodder , freebsd-current@freebsd.org Subject: Re: deprecate ftp-proxy in favor of ftp/pftpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 22:22:33 -0000 --nextPart9690532.kjMzpJAIj7 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 14 December 2007, J.R. Oldroyd wrote: > On Fri, 14 Dec 2007 22:39:04 +0100, Max Laier =20 wrote: > > Bottom line: The ftp-proxy in HEAD and RELENG_7 is believed to work, > > if it doesn't please submit details to freebsd-pf@ This version of > > ftp-proxy can be obtained from the ports collection for RELENG_6, too > > (ftp/ftp-proxy) and is believed to supercede pftpx. > > Hmm. I wonder if the new ftp-proxy requires a different config > in pf.conf or something, then? I'll post a follow-up to freebsd-pf@ > and continue this there, but, for me, ftp-proxy no longer works > and pftpx just worked. from src/UPDATING: 20070702: The packet filter (pf) code has been updated to OpenBSD 4.1 Please note the changed syntax - keep state is now on by default. Also note the fact that ftp-proxy(8) has been changed from bottom up and has been moved from libexec to usr/sbin. Changes in the ALTQ handling also affect users of IPFW's ALTQ capabilities. I'm afraid it hasn't made it's way to the Release notes, yet. The ftp-proxy(8) manpage provides configuration examples and details. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart9690532.kjMzpJAIj7 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) iD8DBQBHYwIlXyyEoT62BG0RAoBNAJsHu0HCBsKt7fDWVj0Tvv82R7Z24gCfaysF ov7cKp7PjUuniwjcvx7kctA= =t3td -----END PGP SIGNATURE----- --nextPart9690532.kjMzpJAIj7-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 22:55:49 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3142216A41B; Fri, 14 Dec 2007 22:55:49 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from smtp.vzavenue.net (smtp.vzavenue.net [66.171.59.140]) by mx1.freebsd.org (Postfix) with ESMTP id B65F713C458; Fri, 14 Dec 2007 22:55:48 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from 98.79.171.66.subscriber.vzavenue.net (HELO homobox.opal.com) ([66.171.79.98]) by smtp.vzavenue.net with ESMTP; 14 Dec 2007 17:55:46 -0500 X-REPUTATION: None X-REMOTE-IP: 66.171.79.98 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAMaRYkdCq09i/2dsb2JhbACBWqgN X-IronPort-AV: i="4.24,169,1196658000"; d="asc'?scan'208"; a="172731642:sNHT39582981" Received: from linwhf.opal.com (localhost [127.0.0.1]) (authenticated bits=0) by homobox.opal.com (8.13.8/8.13.8) with ESMTP id lBEMtj6x078689; Fri, 14 Dec 2007 17:55:46 -0500 (EST) (envelope-from fbsd@opal.com) Received: from linwhf.opal.com ([192.168.3.65] helo=linwhf.opal.com) by ASSP-nospam; 14 Dec 2007 17:55:45 -0500 Date: Fri, 14 Dec 2007 17:55:41 -0500 From: "J.R. Oldroyd" To: Max Laier Message-ID: <20071214175541.158bfa29@linwhf.opal.com> In-Reply-To: <200712142322.29072.max@love2party.net> References: <20071214153229.17383065@linwhf.opal.com> <200712142239.13422.max@love2party.net> <20071214170722.5e5853c3@linwhf.opal.com> <200712142322.29072.max@love2party.net> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-unknown-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/85en72jKkEPn7rOr2MhpDa+"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: Remko Lodder , freebsd-current@freebsd.org Subject: Re: deprecate ftp-proxy in favor of ftp/pftpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 22:55:49 -0000 --Sig_/85en72jKkEPn7rOr2MhpDa+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 14 Dec 2007 23:22:22 +0100, Max Laier wrote: >=20 > from src/UPDATING: >=20 > 20070702: > The packet filter (pf) code has been updated to OpenBSD 4.1 Please > note the changed syntax - keep state is now on by default. Also > note the fact that ftp-proxy(8) has been changed from bottom up and > has been moved from libexec to usr/sbin. Changes in the ALTQ > handling also affect users of IPFW's ALTQ capabilities. >=20 > I'm afraid it hasn't made it's way to the Release notes, yet. >=20 > The ftp-proxy(8) manpage provides configuration examples and details. >=20 Ah, I have found the problem. =20 Admittedly, I was under the impression that the proxy host here had been upgraded to 7.0; this turns out to be not the case. The ftp-proxy host in question is one of the few here that has not yet been upgraded from 6.2 to 7.0. It is therefore still running the OpenBSD 3.7-derived ftp-proxy. A bunch of desk/laptops here have recently been upgraded to 7.0 and with that came recent versions of firefox. I gather that a change in firefox documented here: http://www.mozilla.org/security/announce/2007/mfsa2007-11.html no longer permits the behavior of ftp-proxy in changing the data port, making recent versions of firefox incompatible with the old ftp-proxy. That's why firefox appeared to stop working. I do see that the ftp-proxy on 7.0 has been changed and that the man page does look rather like the one for pftpx, so I now see that what you're saying, Max, looks right. =20 The problem I ran into, that of having new 7.0 desktops and recent versions of tools like firefox, together with a 6.x firewall/proxy host, may be a situation others run into over the next few weeks. Perhaps it's worth posting a heads up to stable@ once 7.0 is released, explaining that folks still using 6.x on a firewall/proxy will need to replace ftp-proxy with ftp/pftpx, and then go back to ftp-proxy when they upgrade the firewall/proxy host to 7.x. I had seen the note in UPDATING, but that note does not mention the breakage with firefox or what the solution is. -jr --Sig_/85en72jKkEPn7rOr2MhpDa+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHYwntls33urr0k4kRAoYVAJ0a8N48ksfB3KM3MtS2W6II77CHGwCdE0tD 5LqIbsyiUVpN4mRTHNXn7O4= =+8iu -----END PGP SIGNATURE----- --Sig_/85en72jKkEPn7rOr2MhpDa+-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 23:02:08 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67DFB16A417 for ; Fri, 14 Dec 2007 23:02:08 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from mail.potentialtech.com (internet.potentialtech.com [66.167.251.6]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4A013C45B for ; Fri, 14 Dec 2007 23:02:08 +0000 (UTC) (envelope-from wmoran@potentialtech.com) Received: from working (c-71-60-127-199.hsd1.pa.comcast.net [71.60.127.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.potentialtech.com (Postfix) with ESMTP id D920EEBC3C; Fri, 14 Dec 2007 17:42:09 -0500 (EST) Date: Fri, 14 Dec 2007 17:42:09 -0500 From: Bill Moran To: "Kevin Oberman" Message-Id: <20071214174209.e1a90a92.wmoran@potentialtech.com> In-Reply-To: <20071214221631.0AE8645014@ptavv.es.net> References: <20071214221631.0AE8645014@ptavv.es.net> X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Dust out your heat syncs! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 23:02:08 -0000 "Kevin Oberman" wrote: > > This is a bit off topic, but I have commented on the issue of dusty heat > syncs in the past. With the recent discussion of the high temps generated [snip] "sink" They are not "heat syncs". They are "heat sinks". Sorry, but it was like fingernails on a chalkboard ... -- Bill Moran http://www.potentialtech.com From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 23:10:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFD3A16A417 for ; Fri, 14 Dec 2007 23:10:39 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 8F46D13C43E for ; Fri, 14 Dec 2007 23:10:39 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1161569rvb.43 for ; Fri, 14 Dec 2007 15:10:39 -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=Ry8w2/1fMJx3Em+UUNhHDpfgkfSAmMzP7ctJZFC2Yvk=; b=LODc3HWcs41K6s0u/mpWw8TX+4Ujy4XnR3yD3HOpUby4M7IiGlg0IigeJO8+pV2Zp7Q8wCtwmTpXS/PiS7V7/q2RLtM7P5nDsN9/EkK3rBHeiAopQRoOZXM7JQxSl//kFD3EZHmPYHqenMmz9P8O0AV3izpz0DWQ5dRO3sVeiCA= 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=j8QxI4BrbRdqFkO006wtaRTUS/JpuJrrcVicOIDA/o5BYHOCddKLjgXQQhIXBwZpgkJAZB2WO51Zxtiv8A9ggYxxvarBBV0yIuSAM4B12WU9lJlXk+mlPRxgomXwhYLK0pW7Jx3ZhQIcdCK+N6aQiBo0PTI1eN1DpIoX2QS99rs= Received: by 10.141.29.18 with SMTP id g18mr2275773rvj.298.1197673839191; Fri, 14 Dec 2007 15:10:39 -0800 (PST) Received: by 10.140.193.9 with HTTP; Fri, 14 Dec 2007 15:10:39 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 18:10:39 -0500 From: "Scott Ullrich" To: "J.R. Oldroyd" In-Reply-To: <20071214175541.158bfa29@linwhf.opal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071214153229.17383065@linwhf.opal.com> <200712142239.13422.max@love2party.net> <20071214170722.5e5853c3@linwhf.opal.com> <200712142322.29072.max@love2party.net> <20071214175541.158bfa29@linwhf.opal.com> Cc: Max Laier , Remko Lodder , freebsd-current@freebsd.org Subject: Re: deprecate ftp-proxy in favor of ftp/pftpx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 23:10:39 -0000 On Dec 14, 2007 5:55 PM, J.R. Oldroyd wrote: > > Admittedly, I was under the impression that the proxy host here had > been upgraded to 7.0; this turns out to be not the case. > > The ftp-proxy host in question is one of the few here that has not > yet been upgraded from 6.2 to 7.0. It is therefore still running the > OpenBSD 3.7-derived ftp-proxy. A bunch of desk/laptops here have > recently been upgraded to 7.0 and with that came recent versions > of firefox. I gather that a change in firefox documented here: > http://www.mozilla.org/security/announce/2007/mfsa2007-11.html > no longer permits the behavior of ftp-proxy in changing the data port, > making recent versions of firefox incompatible with the old ftp-proxy. > That's why firefox appeared to stop working. > > I do see that the ftp-proxy on 7.0 has been changed and that the > man page does look rather like the one for pftpx, so I now see > that what you're saying, Max, looks right. > > The problem I ran into, that of having new 7.0 desktops and recent > versions of tools like firefox, together with a 6.x firewall/proxy > host, may be a situation others run into over the next few weeks. > Perhaps it's worth posting a heads up to stable@ once 7.0 is > released, explaining that folks still using 6.x on a firewall/proxy > will need to replace ftp-proxy with ftp/pftpx, and then go back > to ftp-proxy when they upgrade the firewall/proxy host to 7.x. > > I had seen the note in UPDATING, but that note does not mention > the breakage with firefox or what the solution is. I recently ported the latest OpenBSD ftp-proxy over (v1.15) and it is available if anyone wants to use it at http://www.pfsense.com/~sullrich/ported_software/ftp-proxy_v1.15.tgz This version should hopefully do everything you need. Scott From owner-freebsd-current@FreeBSD.ORG Fri Dec 14 23:42:35 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEA8A16A4A0 for ; Fri, 14 Dec 2007 23:42:35 +0000 (UTC) (envelope-from estrabd@gmail.com) Received: from bc1.hpc.lsu.edu (bc1.hpc.lsu.edu [130.39.198.6]) by mx1.freebsd.org (Postfix) with ESMTP id 5210B13C468 for ; Fri, 14 Dec 2007 23:42:35 +0000 (UTC) (envelope-from estrabd@gmail.com) Received: from bc1.hpc.lsu.edu (localhost.hpc.lsu.edu [127.0.0.1]) by bc1.hpc.lsu.edu (8.14.1/8.13.8) with ESMTP id lBENMZuj007792; Fri, 14 Dec 2007 23:22:35 GMT (envelope-from estrabd@gmail.com) Received: (from estrabd@localhost) by bc1.hpc.lsu.edu (8.14.1/8.13.8/Submit) id lBENMZRu007791; Fri, 14 Dec 2007 23:22:35 GMT (envelope-from estrabd@gmail.com) X-Authentication-Warning: bc1.hpc.lsu.edu: estrabd set sender to estrabd@gmail.com using -f Date: Fri, 14 Dec 2007 23:22:35 +0000 From: "B. Estrade" To: Bill Moran Message-ID: <20071214232235.GY25282@bc1.hpc.lsu.edu> References: <20071214221631.0AE8645014@ptavv.es.net> <20071214174209.e1a90a92.wmoran@potentialtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071214174209.e1a90a92.wmoran@potentialtech.com> User-Agent: Mutt/1.4.2.3i mailed-by: estrabd@lsu.edu Cc: current@freebsd.org Subject: Re: Dust out your heat syncs! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 23:42:35 -0000 On Fri, Dec 14, 2007 at 05:42:09PM -0500, Bill Moran wrote: > "Kevin Oberman" wrote: > > > > This is a bit off topic, but I have commented on the issue of dusty heat > > syncs in the past. With the recent discussion of the high temps generated > > [snip] > > "sink" They are not "heat syncs". They are "heat sinks". > > Sorry, but it was like fingernails on a chalkboard ... I don't know. If you consider that different hot components use a single chunk of metal to reach some sort of equilibrium temperature, I don't think it is a stretch to call it a sync :) > > -- > Bill Moran > http://www.potentialtech.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 03:02:29 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A3DF16A418 for ; Sat, 15 Dec 2007 03:02:29 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 361FE13C45D for ; Sat, 15 Dec 2007 03:02:28 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.3] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id lBF32Q2Z036708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2007 19:02:27 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <476343B4.8080208@FreeBSD.org> Date: Fri, 14 Dec 2007 19:02:12 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Ivan Voras References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 03:02:29 -0000 Ivan Voras wrote: > David Duchscher wrote: >> On Dec 14, 2007, at 6:57 AM, Dag-Erling SmÞrgrav wrote: >> >>> David Duchscher writes: >>>> So does anybody know of a battery backed NVRAM card that can be used >>>> with FreeBSD that the ZIL could be offloaded to? >>> Any CF card or similar will do. You don't need battery backup for >>> flash memory. >> I did think of that but is a CF card faster than a good SAS or SATA >> drive? > > Not in transfer rate, but it could help hugely with seek-intensive IO > loads (since seeks are instantaneous on flash or other solid-state > drives). In theory, they could be of immense benefit for databases and > seek-intensive operations on file systems, but the limited bulk transfer > rates and relatively small sizes (for decent money) currently prevent > their wide-spread use. That's no longer true. You can't get more than 5-10MB/s from seek-intensive RAID0 with two 15K drives, while 20-30MB/s is not a problem for the comparable priced/sized SSD drive. -Maxim From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 04:44:30 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB7D816A418 for ; Sat, 15 Dec 2007 04:44:30 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id A2AB913C455 for ; Sat, 15 Dec 2007 04:44:30 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 2CDF37B954; Fri, 14 Dec 2007 23:44:30 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 14 Dec 2007 23:44:30 -0500 X-Sasl-enc: yJrPS7bZumjsI6MghvrHL10A7GwSkbDxu935d/e0XA4T 1197693868 Received: from [192.168.1.100] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTP id 1B36DDB3D; Fri, 14 Dec 2007 23:44:26 -0500 (EST) Message-ID: <47635BA3.7080004@freebsd.org> Date: Sat, 15 Dec 2007 15:44:19 +1100 From: Darren Reed Organization: FreeBSD User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kevin Oberman References: <20071214221631.0AE8645014@ptavv.es.net> In-Reply-To: <20071214221631.0AE8645014@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Dust out your heat syncs! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 04:44:30 -0000 Kevin Oberman wrote: > This is a bit off topic, but I have commented on the issue of dusty heat > syncs in the past. With the recent discussion of the high temps generated > by the last V7-beta on some systems (not mine), I thought that I would > remind folks. > > I just dusted out my 2.5 year old laptop (2 GHz Pentium-M) and the > difference was impressive. (And so was the cloud of dust I blew out!) Some of us make it a habit to do this on at least a yearly basis, if not every 6 months. Keeping computers dust free is a good place to start for system longevity. Darren From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 04:59:12 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EE8716A417; Sat, 15 Dec 2007 04:59:12 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from darklight.org.ru (darklight.org.ru [194.186.18.14]) by mx1.freebsd.org (Postfix) with ESMTP id 2C08313C4DB; Sat, 15 Dec 2007 04:59:10 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from darklight.org.ru (darklight.org.ru [127.0.0.1]) by darklight.org.ru (8.14.2/8.14.2) with ESMTP id lBF4lxN8007348; Sat, 15 Dec 2007 07:48:00 +0300 (MSK) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.org.ru (8.14.2/8.14.2/Submit) id lBF4lwRk007347; Sat, 15 Dec 2007 07:47:58 +0300 (MSK) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.org.ru: yuri set sender to yuri.pankov@gmail.com using -f Date: Sat, 15 Dec 2007 07:47:58 +0300 From: Yuri Pankov To: Michael Bushkov Message-ID: <20071215044758.GB88672@darklight.org.ru> References: <200712121008.lBCA83r2090165@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200712121008.lBCA83r2090165@repoman.freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@FreeBSD.org Subject: Re: cvs commit: src/include nsswitch.h src/lib/libc/gen getgrent.c getgrouplist.c src/lib/libc/net nsdispatch.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 04:59:12 -0000 On Wed, Dec 12, 2007 at 10:08:03AM +0000, Michael Bushkov wrote: > bushman 2007-12-12 10:08:03 UTC > > FreeBSD src repository > > Modified files: > include nsswitch.h > lib/libc/gen getgrent.c getgrouplist.c > lib/libc/net nsdispatch.c > Log: > Implementing 'fallback' nsswitch source. 'fallback' source is used > when particular function can't be found in nsswitch-module. For > example, getgrouplist(3) will use module-supplied 'getgroupmembership' > function (which can work in an optimal way for such source as LDAP) and > will fall back to the stanard iterate-through-all-groups implementation > otherwise. > > PR: ports/114655 > Submitted by: Michael Hanselmann > Reviewed by: brooks (mentor) > > Revision Changes Path > 1.5 +3 -1 src/include/nsswitch.h > 1.37 +190 -74 src/lib/libc/gen/getgrent.c > 1.16 +4 -39 src/lib/libc/gen/getgrouplist.c > 1.15 +26 -3 src/lib/libc/net/nsdispatch.c I'm getting debug.log filled up with: NSSWITCH(nss_method_lookup): __fallback, passwd, getpwuid_r, not found Could this be related to this commit or is it PEBKAC? Yuri From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 05:35:34 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from miki (localhost [IPv6:::1]) by hub.freebsd.org (Postfix) with SMTP id 3FBF616A417; Sat, 15 Dec 2007 05:35:33 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Sat, 15 Dec 2007 13:34:58 +0800 From: Ariff Abdullah To: Yuri Pankov Message-Id: <20071215133458.322748aa.ariff@FreeBSD.org> In-Reply-To: <20071215044758.GB88672@darklight.org.ru> References: <200712121008.lBCA83r2090165@repoman.freebsd.org> <20071215044758.GB88672@darklight.org.ru> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sat__15_Dec_2007_13_34_58_+0800_TPDyGHhkdz+B1u4O" Cc: bushman@FreeBSD.org, current@FreeBSD.org Subject: Re: cvs commit: src/include nsswitch.h src/lib/libc/gen getgrent.c getgrouplist.c src/lib/libc/net nsdispatch.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 05:35:34 -0000 --Signature=_Sat__15_Dec_2007_13_34_58_+0800_TPDyGHhkdz+B1u4O Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 15 Dec 2007 07:47:58 +0300 Yuri Pankov wrote: > On Wed, Dec 12, 2007 at 10:08:03AM +0000, Michael Bushkov wrote: > > bushman 2007-12-12 10:08:03 UTC > >=20 > > FreeBSD src repository > >=20 > > Modified files: > > include nsswitch.h=20 > > lib/libc/gen getgrent.c getgrouplist.c=20 > > lib/libc/net nsdispatch.c=20 > > Log: > > Implementing 'fallback' nsswitch source. 'fallback' source is > > used when particular function can't be found in nsswitch-module. > > For example, getgrouplist(3) will use module-supplied > > 'getgroupmembership' function (which can work in an optimal way > > for such source as LDAP) and will fall back to the stanard > > iterate-through-all-groups implementation otherwise. > > =20 > > PR: ports/114655 > > Submitted by: Michael Hanselmann > > Reviewed by: brooks (mentor) > > =20 > > Revision Changes Path > > 1.5 +3 -1 src/include/nsswitch.h > > 1.37 +190 -74 src/lib/libc/gen/getgrent.c > > 1.16 +4 -39 src/lib/libc/gen/getgrouplist.c > > 1.15 +26 -3 src/lib/libc/net/nsdispatch.c >=20 > I'm getting debug.log filled up with: > NSSWITCH(nss_method_lookup): __fallback, passwd, getpwuid_r, not > found >=20 Seconded, plus x11/mrxvt winding into infinite loop and attempt to kill it (and just it) will mass kill X, getty restarted, terminate few background daemons (eg: ssh-agent), etc. Reverting the last 3 files seems fix it. > Could this be related to this commit or is it PEBKAC? >=20 -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Sat__15_Dec_2007_13_34_58_+0800_TPDyGHhkdz+B1u4O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHY2eClr+deMUwTNoRAjnPAKDHycNsJuMKaMrASqIcnxCO9WMwZwCdGkI0 eWhlY2zCe7C5OX2jXUF70Oo= =v/2z -----END PGP SIGNATURE----- --Signature=_Sat__15_Dec_2007_13_34_58_+0800_TPDyGHhkdz+B1u4O-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 08:57:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A6ED16A41B for ; Sat, 15 Dec 2007 08:57:30 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.242]) by mx1.freebsd.org (Postfix) with ESMTP id D554D13C448 for ; Sat, 15 Dec 2007 08:57:29 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by hs-out-2122.google.com with SMTP id j58so1733839hsj.11 for ; Sat, 15 Dec 2007 00:57: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ryS8L/M2sdKR7XEu9LbiBGN65DlXsIXf4/PuLSk2vco=; b=nyPIN7I8wZMuxCNc8/LbyJPeB2YsdrHS8QHfg5UaREd0zroNd5VIUW77rO1oKNkZb66HWkRAo1St61VlmY+Pce92l7J73tXi5eItCbIxHsJj0buzmKBzF/TOt9+aeTT5fX/uLH+8MJy/SKxlSevxwYLiaRE/KTbAB6MQVfQ7Hlk= 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=YA/wz/B3JlbGK3a7d9q9eUnynhIcUoLW7xdWNYN9UKFDCO/j0WP20ogtzG9YC/iswnsLbbcsvNLaSPnL6s+IRF9bEfUBrUUZT5OKn45DCMg3JaC+pP7eVjLVFRzhKsFTg4DSk75JRzsswo4gGoS54MCi2+5cbtuuNg+gv/JnYbo= Received: by 10.150.124.2 with SMTP id w2mr1572036ybc.2.1197709047753; Sat, 15 Dec 2007 00:57:27 -0800 (PST) Received: by 10.150.200.17 with HTTP; Sat, 15 Dec 2007 00:57:27 -0800 (PST) Message-ID: Date: Sat, 15 Dec 2007 00:57:27 -0800 From: "Kip Macy" To: "Robert Watson" , "Sam Leffler" , freebsd-arch@freebsd.org, "FreeBSD Current" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 08:57:30 -0000 The updated patch is at: http://www.fsmware.com/tcp/tcp_offload.diff I've only had structural feedback from one person. Please let me know if you intend to provide feedback I'd like to get this in without much further delay. -Kip On 12/12/07, Kip Macy wrote: > After review by Mike Silbersack I've committed the hooks that provide > a driver independent interface to TCP offload. > > I would like to commit the changes to tcp_subr.c and tcp_usrreq.c to > actually make use of the new interface. Please review the following: > > http://www.fsmware.com/freebsd/tcp/tcp_subr.c.diff > > http://www.fsmware.com/freebsd/tcp/tcp_usrreq.c.diff > > The new KPI is provided by the following 2 files: > http://www.fsmware.com/freebsd/tcp/tcp_ofld.c > http://www.fsmware.com/freebsd/tcp/tcp_ofld.h > > > Thank you for taking the time to review and provide feedback. > > -Kip > From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 09:02:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E836716A41B for ; Sat, 15 Dec 2007 09:02:37 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from hs-out-2122.google.com (hs-out-0708.google.com [64.233.178.240]) by mx1.freebsd.org (Postfix) with ESMTP id 9094D13C461 for ; Sat, 15 Dec 2007 09:02:37 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by hs-out-2122.google.com with SMTP id j58so1735238hsj.11 for ; Sat, 15 Dec 2007 01:02:36 -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=1F0mj4+hO7HRQbji9Jr+IxNt9hbOM5Ga9ssh/rkKp9w=; b=Ml+1dwZkXs5sOrZjEBCR2UKTjtbassUP8gzQ+pddM4G2Nfl7ChFv6vU6SCcHG+aShk3oNEqjzDK6T6qlJstE5Gmy6qNdNT7mtxK3/wGn2/uSd5Dj6Ay9ZZISnaI/FLAyQ9cO20A9O0tJ2pk4XS04MSFZV6LXkt3dtb0QXquX1KQ= 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=Lqc5i3Zt9sHIDGCkckyvfbSubaCO4GOsKU3CpLoWzB3r8+jIMGbII9mECXFFSLJu4iXi80KGqteURvECUjI54Q5YBt0NJ5zPILBBzUPYGBsp+wLCNW9sj1j/1b6P51zBxfSwlvTPgZleUsue7XK4yn0IDJWTDJKLd0kbOY4Bz4w= Received: by 10.150.192.7 with SMTP id p7mr1555696ybf.90.1197709356543; Sat, 15 Dec 2007 01:02:36 -0800 (PST) Received: by 10.150.200.17 with HTTP; Sat, 15 Dec 2007 01:02:36 -0800 (PST) Message-ID: Date: Sat, 15 Dec 2007 01:02:36 -0800 From: "Kip Macy" To: "Robert Watson" , "Sam Leffler" , freebsd-arch@freebsd.org, "FreeBSD Current" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 09:02:38 -0000 http://www.fsmware.com/freebsd/tcp/tcp_offload.diff On 12/15/07, Kip Macy wrote: > The updated patch is at: > http://www.fsmware.com/tcp/tcp_offload.diff > > I've only had structural feedback from one person. Please let me know > if you intend to provide feedback I'd like to get this in without much > further delay. > > -Kip > > > On 12/12/07, Kip Macy wrote: > > After review by Mike Silbersack I've committed the hooks that provide > > a driver independent interface to TCP offload. > > > > I would like to commit the changes to tcp_subr.c and tcp_usrreq.c to > > actually make use of the new interface. Please review the following: > > > > http://www.fsmware.com/freebsd/tcp/tcp_subr.c.diff > > > > http://www.fsmware.com/freebsd/tcp/tcp_usrreq.c.diff > > > > The new KPI is provided by the following 2 files: > > http://www.fsmware.com/freebsd/tcp/tcp_ofld.c > > http://www.fsmware.com/freebsd/tcp/tcp_ofld.h > > > > > > Thank you for taking the time to review and provide feedback. > > > > -Kip > > > From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 10:20:39 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D69AF16A41B for ; Sat, 15 Dec 2007 10:20:39 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8E36B13C465 for ; Sat, 15 Dec 2007 10:20:39 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J3U8F-0003r8-Kt for freebsd-current@freebsd.org; Sat, 15 Dec 2007 10:20:31 +0000 Received: from 78-0-75-218.adsl.net.t-com.hr ([78.0.75.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2007 10:20:31 +0000 Received: from ivoras by 78-0-75-218.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2007 10:20:31 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sat, 15 Dec 2007 11:20:24 +0100 Lines: 29 Message-ID: References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> <476343B4.8080208@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1EC8468AF0DCB38F49DCCA3F" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-75-218.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <476343B4.8080208@FreeBSD.org> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 10:20:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1EC8468AF0DCB38F49DCCA3F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Maxim Sobolev wrote: > That's no longer true. You can't get more than 5-10MB/s from > seek-intensive RAID0 with two 15K drives, while 20-30MB/s is not a > problem for the comparable priced/sized SSD drive. Can you point me at a vendor with SSDs of such characteristics? --------------enig1EC8468AF0DCB38F49DCCA3F 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 iD8DBQFHY6poldnAQVacBcgRAqCyAJ4kwyS2R69WO55QWYrHcgnwbuamqACgmsMn B9ZgMSKEmpWSCmPlEqcgXSc= =225S -----END PGP SIGNATURE----- --------------enig1EC8468AF0DCB38F49DCCA3F-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 10:56:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8D4716A419; Sat, 15 Dec 2007 10:56:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5D18113C45D; Sat, 15 Dec 2007 10:56:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B17DB484F5; Sat, 15 Dec 2007 05:56:46 -0500 (EST) Date: Sat, 15 Dec 2007 10:56:46 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kip Macy In-Reply-To: Message-ID: <20071215100351.Q70617@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 10:56:47 -0000 On Sat, 15 Dec 2007, Kip Macy wrote: > The updated patch is at: http://www.fsmware.com/tcp/tcp_offload.diff > > I've only had structural feedback from one person. Please let me know if you > intend to provide feedback I'd like to get this in without much further > delay. Per our out-of-band communication, I won't have the opportunity to do any serious reviewing of this work until later next week, as I have other personal obligations in the mean time that preclude that. However, skimming the comments, I have a couple of areas where I'd like some clarification to help guide my reading. I've only got fifteen minutes so I'll cut off when I run out. + * A driver publishes that it provides offload services + * by setting IFCAP_TOE in the ifnet. The offload connect + * will bypass any further work if the interface that a + * connection would use does not support TCP offload. My initial feeling is that, even if an interface supports TOE, we shouldn't enable the capability in the enabled vector by default, as TOE bypasses firewall behavior, etc, and would certainly be a surprise if an admin swapped a chelsio card for a non-TOE supporting card. What's your feeling on this? + * The TOE API assumes that the tcp offload engine can offload the + * the entire connection from set up to teardown, with some provision + * being made to allowing the software stack to handle time wait. If + * the device does not meet these criteria, it is the driver's responsibility + * to overload the functions that it needs to in tcp_usrreqs and make + * its own calls to tcp_output if it needs to do so. While I'm familiar with TCP, I'm less familiar with the scope of what cards support for TOE. Do we know of any cards that are less capable than the chelsio card in this respect, or are they all sort of on-par on that front? I.e., do we think the above eventuality is likely? If we don't, then one of the things I'd like to see us do is fairly carefully assert, at least for a few months, that TCP never "slips" into any transmission-related paths that could lead to truly odd and hard-to-diagnose behavior when runnning with TOE. I.e., tcp_output, etc. If we do think it's likely, we don't need to address this immediately, but we should make sure that before we ship TOE in a release, we've thought somewhat more thoroughly about that case. As long as TOE remains un-MFC'd, we don't find ourselves with an obligation to maintain guarantees about the interfaces, and that includes dealing with incompatibility :-). Do we know if any of the current 10gbps vendors other than chelsio are actively looking at TOE on FreeBSD, and could be engaged in discussion? + * The toe_usrreqs structure constitutes the TOE driver's + * interface to the TCP stack for functionality that doesn't + * interact directly with userspace. If one wants to provide + * (optional) functionality to do zero-copy to/from + * userspace one still needs to override soreceive/sosend + * with functions that fault in and pin the user buffers. And this is an issue we also should work out in order to properly fix ZERO_COPY_SOCKETS anyway. I think it might be useful to add a couple of paragraphs here on three topics: (1) Clarify the way in which windows are updated between the device driver and the socket code, both for sending/receiving. You talk a bit about "credit", but introducing it up-front would be useful. (2) One of the issues I've run into in the TCP and socket code generally is that there was significant lack of clarity on the "life cycle" of the set of related data structures. Could you write a bit of text about when drivers will allocate state and when they will free it? I.e., tu_attach allocates state, tu_{abort,detach} free it, and TCP promises not to call anything before attach or anything after abort/detach. (3) Could you talk at a high level about the ways in which TOE drivers will interact with TCP? You do it a bit in each of the sections, but if there's a principle, pulling it out would be useful. Also, you should indicate whether the driver is allowed to drop the inpcb lock or not. Doing this would address a few of the comments I have below also. + * + tu_send + * - tells the driver that new data may have been added to the + * socket's send buffer - the driver should not fail if the + * buffer is in fact unchanged I'm a bit confused by the description of the error condition here. Could you clarify when a driver should return an error, and what the impact of an error returned will be on the connection state? In fact, it probably makes sense to have an up-front comment on conventions for error-handling -- if TOE returns an error will that generally lead to a TCP tear-down? + * - The driver expects the inpcb lock to be held and This comment is truncated -- is there an and? We should specify that drivers are not allowed to drop the inpcb lock if that is the case, FYI. + * + tu_rcvd + * - returns credits to the driver and triggers window updates + * to the peer (a credit is a byte in the user's receive window) Might begin with a sentence defining the notion of credit. Is it possible to use tu_rcvd to reduce credit to the card if the socket buffer size is changed, or just increase it? + * - the driver is expected to determine how many bytes have been + * consumed and credit that back to the card so that it can grow + * the window again Could you provide an example of how it is to do that -- i.e., is it just going to inspect so_rcv in the same way native TCP does? + * - this function needs to correctly handle being called any number of + * times without any bytes being consumed from the receive buffer. + * - the driver expects the inpcb lock to be held + * + * + tu_disconnect + * - tells the driver to send FIN to peer + * - driver is expected to send the remaining data and then do a clean half close + * - disconnect implies at least half-close so only send, abort, and detach + * are legal Could you clarify this a bit? Do you mean that TCP guarangees that only tu_send, tu_abort, and tu_detach will be delivered to the driver in the future? + * - the driver is expected to handle transition through the shutdown + * state machine and allow the stack to support SO_LINGER. Probably worth commenting that the device driver won't detach the toe state. + * + * + tu_abort + * - closes the connection and sends a RST to peer + * - driver is expectd to trigger an RST and detach the toepcb In regular TCP, the pru_abort method is only called on pending connections while still in the listen queues of a listen socket. Is this true of tu_abort, or is tu_abort a more general method to be used to cancel connections? If so, probably worth commenting on that. + * - no further calls are legal after abort + * - the driver expects the inpcb lock to be held + * + * + tu_detach + * - tells driver that the socket is going away so disconnect + * the toepcb and free appropriate resources + * - allows the driver to cleanly handle the case of connection state + * outliving the socket + * - no further calls are legal after detach + * - the driver acquires the tcbinfo lock For this call, you haven't specified whether the inpcb lock is held. If it is, the driver acquiring the tcbinfo lock without first dropping the inpcb lock would be a lock order reversal. Should the caller instead acquire/hold it? For the above calls, what guarantees does the TCP stack make about the presence of the socket, if any? These interfaces all pass the tcpcb, but in our regular TCP stack, the invariant is the existence of the inpcb, not the tcpcb, which may be replaced with a tcptw (or in one edge case, inp_ppcb may be NULL). If there will be drivers in the future that implement timewait, perhaps we should be passing in the inpcb? + * + tu_syncache_event + * - even if it is not actually needed, the driver is expected to + * call syncache_add for the initial SYN and then syncache_expand + * for the SYN,ACK + * - tells driver that a connection either has not been added or has + * been dropped from the syncache + * - the driver is expected to maintain state that lives outside the + * software stack so the syncache needs to be able to notify the + * toe driver that the software stack is not going to create a connection + * for a received SYN + * - the driver is responsible for any synchronization required Presumably tu_syncache_event is called from the syncache and locks will be held when that happens...? How will the race between the syncache deciding to drop a connection of its own accord and the hardware/driver deciding to accept be addressed, generally speaking? + +extern struct toe_usrreqs tcp_offload_usrreqs; What is the purpose of this global? Presumably we can have two drivers that both implement offload at once? More comments to follow. Robert N M Watson Computer Laboratory University of Cambridge > > -Kip > > > On 12/12/07, Kip Macy wrote: >> After review by Mike Silbersack I've committed the hooks that provide >> a driver independent interface to TCP offload. >> >> I would like to commit the changes to tcp_subr.c and tcp_usrreq.c to >> actually make use of the new interface. Please review the following: >> >> http://www.fsmware.com/freebsd/tcp/tcp_subr.c.diff >> >> http://www.fsmware.com/freebsd/tcp/tcp_usrreq.c.diff >> >> The new KPI is provided by the following 2 files: >> http://www.fsmware.com/freebsd/tcp/tcp_ofld.c >> http://www.fsmware.com/freebsd/tcp/tcp_ofld.h >> >> >> Thank you for taking the time to review and provide feedback. >> >> -Kip >> > From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 13:28:47 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4C9416A41B for ; Sat, 15 Dec 2007 13:28:47 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5177613C448 for ; Sat, 15 Dec 2007 13:28:47 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.2/8.14.2) with ESMTP id lBFDAnMH054756 for ; Sat, 15 Dec 2007 16:10:49 +0300 (MSK) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1197724249; bh=B6ukGbTdqLExCezBVfqNTVdG7alTlXI6klYz0tH H+m0=; l=1114; h=Date:From:To:Subject:Message-ID:Mail-Followup-To: MIME-Version:Content-Type:Content-Disposition:User-Agent; b=JBRv2D uriB65JkmqyarHi9aWt0ch6JZgiwlXJrp4sF3sv7NoFfMKxiDFGnWAmfXIfyf+F9roY RCphALllKF6k85xvNyC1guWtpSiZacaQkfYx8DoSx8AX+mTTgC/H1rDhbc32ILjrNSB s2u7Wsr8IkNIZtpFW89bPW2kCVSIWSo= Received: (from ache@localhost) by nagual.pp.ru (8.14.2/8.14.2/Submit) id lBFDAmDc054754 for current@freebsd.org; Sat, 15 Dec 2007 16:10:48 +0300 (MSK) (envelope-from ache) Date: Sat, 15 Dec 2007 16:10:47 +0300 From: Andrey Chernov To: current@freebsd.org Message-ID: <20071215131047.GA54581@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: New nsdispatch.c __fallback errors, any clues? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 13:28:48 -0000 With new nsdispatch.c v1.15 I constantly get this errors from procmail, sendmail, etc: Dec 14 21:35:41 xxxxxxxx procmail[5897]: NSSWITCH(nss_method_lookup): __fallback, passwd, getpwuid_r, not found Dec 14 21:35:41 xxxxxxxx procmail[5897]: NSSWITCH(nss_method_lookup): __fallback, group, endgrent, not found Dec 14 21:35:41 xxxxxxxx procmail[5897]: NSSWITCH(nss_method_lookup): __fallback, passwd, getpwnam_r, not found Dec 14 21:35:41 xxxxxxxx procmail[5897]: NSSWITCH(nss_method_lookup): files, group, getgroupmembership, not found Dec 14 21:35:41 xxxxxxxx procmail[5897]: NSSWITCH(nss_method_lookup): __fallback, group, endgrent, not found Dec 14 21:35:41 xxxxxxxx procmail[5897]: NSSWITCH(nss_method_lookup): __fallback, passwd, endpwent, not found Here is my /etc/nsswitch.conf: group: files hosts: files dns networks: files passwd: files shells: files services: files protocols: files rpc: files I use WITHOUT_NIS option in src.conf What those errors ever means, what is wrong and how it can be fixed? Everything works Ok with nsdispatch.c v1.14 -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 15:57:12 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0689B16A420; Sat, 15 Dec 2007 15:57:12 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id AC71013C45D; Sat, 15 Dec 2007 15:57:11 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id D61FE20A0; Sat, 15 Dec 2007 16:57:02 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.1/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id C98202099; Sat, 15 Dec 2007 16:57:02 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id BEE5D84492; Sat, 15 Dec 2007 16:57:02 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ivan Voras References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> <476343B4.8080208@FreeBSD.org> Date: Sat, 15 Dec 2007 16:57:02 +0100 In-Reply-To: (Ivan Voras's message of "Sat\, 15 Dec 2007 11\:20\:24 +0100") Message-ID: <86tzmk54tt.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 15:57:12 -0000 Ivan Voras writes: > Maxim Sobolev wrote: > > That's no longer true. You can't get more than 5-10MB/s from > > seek-intensive RAID0 with two 15K drives, while 20-30MB/s is not a > > problem for the comparable priced/sized SSD drive. > Can you point me at a vendor with SSDs of such characteristics? Kingston CF Elite, 20 / 25 MBps write / read Kingston CF Ultimate, 40 / 45 MBps write / read SanDisk Extreme III CF, 20 MBps SanDisk Extreme IV CF, 45 MBps Sony CF 300X, 45 MBps These are just a few of those available from my regular supplier. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 16:19:24 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6227F16A417 for ; Sat, 15 Dec 2007 16:19:24 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D253B13C465 for ; Sat, 15 Dec 2007 16:19:23 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J3ZfH-00042h-5g for freebsd-current@freebsd.org; Sat, 15 Dec 2007 16:14:59 +0000 Received: from 78-0-75-218.adsl.net.t-com.hr ([78.0.75.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2007 16:14:59 +0000 Received: from ivoras by 78-0-75-218.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2007 16:14:59 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sat, 15 Dec 2007 17:12:54 +0100 Lines: 48 Message-ID: References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> <476343B4.8080208@FreeBSD.org> <86tzmk54tt.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig45592461C08CDE7CD3665A24" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-75-218.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <86tzmk54tt.fsf@ds4.des.no> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 16:19:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45592461C08CDE7CD3665A24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dag-Erling Sm=C3=B8rgrav wrote: > Ivan Voras writes: >> Maxim Sobolev wrote: >>> That's no longer true. You can't get more than 5-10MB/s from >>> seek-intensive RAID0 with two 15K drives, while 20-30MB/s is not a >>> problem for the comparable priced/sized SSD drive. >> Can you point me at a vendor with SSDs of such characteristics? >=20 > Kingston CF Elite, 20 / 25 MBps write / read > Kingston CF Ultimate, 40 / 45 MBps write / read >=20 > SanDisk Extreme III CF, 20 MBps > SanDisk Extreme IV CF, 45 MBps >=20 > Sony CF 300X, 45 MBps >=20 > These are just a few of those available from my regular supplier. These are all "normal" CompactFlash cards, for which the widely available size seems to be 16 GB max, right? I was thinking about something more like this: http://gizmodo.com/gadgets/peripherals/adatas-128gb-solid-state-drive-see= s-the-light-of-day-231693.php or this: http://www.mtron.net/English/Product/pc_msd1000.asp Did you (or anyone) deploy CF drives for production servers? --------------enig45592461C08CDE7CD3665A24 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 iD8DBQFHY/0GldnAQVacBcgRAlXjAJ9qUpn4QkNeG+GJpvssaG8fQhZXowCgmn6y 0ZF2lWBgaCoUWlhQ3aOQ4K8= =sAGu -----END PGP SIGNATURE----- --------------enig45592461C08CDE7CD3665A24-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 16:23:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB4AA16A418; Sat, 15 Dec 2007 16:23:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3D113C467; Sat, 15 Dec 2007 16:23:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id EECC947E90; Sat, 15 Dec 2007 11:23:45 -0500 (EST) Date: Sat, 15 Dec 2007 16:23:45 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kip Macy In-Reply-To: <20071215100351.Q70617@fledge.watson.org> Message-ID: <20071215152959.V85668@fledge.watson.org> References: <20071215100351.Q70617@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 16:23:46 -0000 On Sat, 15 Dec 2007, Robert Watson wrote: > More comments to follow. Some more, back to tcp_offload.c which I didn't look at last time around: + ifp = rt->rt_ifp; + tdev = TOEDEV(ifp); + if (tdev == NULL) + return (EINVAL); + + if (tdev->tod_can_offload(tdev, so) == 0) + return (EINVAL); I sort of expected to see a if_capenable check for TOE here, but I guess it doesn't make much difference if the flag is going to be checked at the lower level. However, in the case of things like TCP checksum offload, we do do the check at the higher level, so it wouldn't be inconsistent to do that. BTW, could you prepare similar comments for toedev.h? +struct toe_usrreqs tcp_offload_usrreqs = { + .tu_send = tcp_output, + .tu_rcvd = tcp_output, + .tu_disconnect = tcp_output, + .tu_abort = tcp_output, + .tu_detach = tcp_offload_detach_noop, + .tu_syncache_event = tcp_offload_syncache_event_noop, +}; This structure seems to introduce quite a bit more indirection for non-offloaded cases than before, especially to do things like this: +static void +tcp_offload_syncache_event_noop(int event, void *toepcb) +{ +} The compiler can't compile these out because it likely doesn't do much in the way of function pointer analysis, and probably shouldn't. However, it leaves quite a few code paths heavier weight than before. I think I'd prefer a model in which a TF_OFFLOAD flag is set on the tcpcb and then we conditionally invoke tu_foo as a result. I.e.,: static __inline int tcp_gen_send(struct tcpcb *tp) { #ifndef TCP_OFFLOAD_DISABLE if (tcp->f_flag & TF_OFFLOADED) return (tp->t_tu->tu_send(tp)); else #endif return (tcp_output(tp)); } This would compile to a straight call to tcp_output() when offloading isn't compiled in, and when it is compiled in and offloading isn't enabled, we do a simple flag check rather than invoking a function via a series of pointers. Back to tcp_offload.h: +#define SC_ENTRY_PRESENT 1 /* 4-tuple already present */ +#define SC_DROP 2 /* connection was timed out */ I think you should give these a different prefix, since they're part of the interface between the syncache and offload, and SC_ generally are flags used internal to the syncache. Later you use TCP_OFFLOAD_ as the prefix, so that may be appropriate here also. +#define TCP_OFFLOAD_LISTEN_OPEN 1 +#define TCP_OFFLOAD_LISTEN_CLOSE 2 + +typedef void (*tcp_offload_listen_fn)(void *, int, struct tcpcb *); +EVENTHANDLER_DECLARE(tcp_offload_listen, tcp_offload_listen_fn); Here and with the syncache interface, it seems like you're adding new operations as modes to functions, whereas elsewhere you're adding multiple functions. There isn't too much difference, but I think I'd rather see a slightly wider interface (i.e., more functions) and avoid flags that change the semantics of particular functions. That is to say: tu_syncache_add and tu_syncache_drop, and likewise tcp_offload_listen and tcp_offload_unlisten (or something similar). +int tcp_offload_connect(struct socket *so, struct sockaddr *nam); This prototype appear not to be documented. +/* + * The tcp_gen_* routines are wrappers around the toe_usrreqs calls, + * in the non-offloaded case they translate to tcp_output. Not really sure about the _gen_ naming, but not sure I have a better suggestion in mind just yet -- maybe _output_ since they control output. I'm not entirely thrilled that all of these become inline functions in include files, although since a couple are used in multiple tcp*.c files, it may be the least bad of the options. My comments above about possibly restructuring this to avoid lots of indirection for non-offloaded case strengthen the argument for inlining, however. +#ifndef TCP_OFFLOAD_DISABLE I notice you've renamed the option, and I like the new name a lot better. However, I also notice that it doesn't seem to appear in conf/options or conf/files. Could you make sure to add it? +/* + * The socket has not been marked as "do not offload" + */ +#define SO_OFFLOADABLE(so) ((so->so_options & SO_NO_OFFLOAD) == 0) I find myself wondering if the offload option should be a TCP socket option rather than a socket-layer option, but don't have strong feelings about this. What do you intend the policy model to be for enabling TOE, in general? That if the TOE capability is available and the TOE capability is enabled, all TCP sockets via the enabled interface will be offloaded unless SO_NO_OFFLOAD is set? Are you currently anticipating enabling the capability by default? Nitpick on style: + /* disconnect offload device, if any */ Comments that are sentences should begin with an upper case letter and end with a period. :-) And another one: +#ifdef TCP_OFFLOAD_DISABLE +#define TOEPCB_SET(sc) (0) +#else +#define TOEPCB_SET(sc) ((sc)->sc_toepcb != NULL) +#endif + + Too many blank lines there. I've noticed that in quite a few places, we prefer X_ISSET() to test for a set flag or other condition, in order to prevent confusion with X_SET() assigning a value. I think that's pretty sensible, and should do it more myself, so encourage you to do the same Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 18:10:22 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62ED416A417 for ; Sat, 15 Dec 2007 18:10:22 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 24B6A13C4EB for ; Sat, 15 Dec 2007 18:10:22 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2244226waf.3 for ; Sat, 15 Dec 2007 10:10:21 -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=z7Iw+pvwm5uxTOJW2rs+OaFu4bUSZ2tC9EURox+qH9U=; b=aR37tjXjQLeS9mgZ4qbDN9IuhmzbwIAAQ+p/DTgmy+9/Odt91up2cRUbJLInubkMLjBewzQB2eiaRMJVnJ/QQZeSAJliWWuLq+n5yz5UEzsE0mZUMxRIaMfzJvd4jAFrOJZACpSPn/JZHetBQnSLStbFAAL/J+UibkkQQmKxeXU= 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=rz8/jCZ9cVEJubQLAdBIYl9HjbmnykfpfGV7ItsAWUaaNm3itA7gHS7ULhFhracF/BAdYr5Mna59QhSpgA19Eh0V/40d3++aKVp70IntzfNbvxIQrGvcSMqf/+lw2E/uGMJZr5QiNwJyQn3bbYicUuw6W/9sd3citUmM/zBTVqU= Received: by 10.114.78.1 with SMTP id a1mr324244wab.102.1197742221471; Sat, 15 Dec 2007 10:10:21 -0800 (PST) Received: by 10.114.255.11 with HTTP; Sat, 15 Dec 2007 10:10:21 -0800 (PST) Message-ID: Date: Sat, 15 Dec 2007 10:10:21 -0800 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20071215152959.V85668@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071215100351.Q70617@fledge.watson.org> <20071215152959.V85668@fledge.watson.org> Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 18:10:22 -0000 On Dec 15, 2007 8:23 AM, Robert Watson wrote: > > On Sat, 15 Dec 2007, Robert Watson wrote: > > > More comments to follow. > > Some more, back to tcp_offload.c which I didn't look at last time around: > > + ifp = rt->rt_ifp; > + tdev = TOEDEV(ifp); > + if (tdev == NULL) > + return (EINVAL); > + > + if (tdev->tod_can_offload(tdev, so) == 0) > + return (EINVAL); > > I sort of expected to see a if_capenable check for TOE here, but I guess it > doesn't make much difference if the flag is going to be checked at the lower > level. However, in the case of things like TCP checksum offload, we do do the > check at the higher level, so it wouldn't be inconsistent to do that. Yes, IFCAP_TOE should be checked here. > > BTW, could you prepare similar comments for toedev.h? Ok, toedev.h isn't actually originally from me. However, it is a part of the API and so should be documented. > > +struct toe_usrreqs tcp_offload_usrreqs = { > + .tu_send = tcp_output, > + .tu_rcvd = tcp_output, > + .tu_disconnect = tcp_output, > + .tu_abort = tcp_output, > + .tu_detach = tcp_offload_detach_noop, > + .tu_syncache_event = tcp_offload_syncache_event_noop, > +}; > > This structure seems to introduce quite a bit more indirection for > non-offloaded cases than before, especially to do things like this: > > +static void > +tcp_offload_syncache_event_noop(int event, void *toepcb) > +{ > +} This should never be called as sc_tu will only be set by the TOE interface to the syncache. Also bear in mind that this and detach are only called once per connection The real overhead is in calling tcp_output via an indirect function call versus a direct function call. Considering the level of gratuitous overhead in the output path I would be surprised if this were measurable. > > The compiler can't compile these out because it likely doesn't do much in the > way of function pointer analysis, and probably shouldn't. However, it leaves > quite a few code paths heavier weight than before. I think I'd prefer a model > in which a TF_OFFLOAD flag is set on the tcpcb and then we conditionally > invoke tu_foo as a result. I.e.,: > > static __inline int > tcp_gen_send(struct tcpcb *tp) > { > > #ifndef TCP_OFFLOAD_DISABLE > if (tcp->f_flag & TF_OFFLOADED) > return (tp->t_tu->tu_send(tp)); > else > #endif > return (tcp_output(tp)); > } > > This would compile to a straight call to tcp_output() when offloading isn't > compiled in, and when it is compiled in and offloading isn't enabled, we do a > simple flag check rather than invoking a function via a series of pointers. This is what the current code does. See tcp_ofld.h in CVS. The indirection was suggested by Sam as a cleaner abstraction. > > Back to tcp_offload.h: > > +#define SC_ENTRY_PRESENT 1 /* 4-tuple already > present */ > +#define SC_DROP 2 /* connection was > timed out */ > > I think you should give these a different prefix, since they're part of the > interface between the syncache and offload, and SC_ generally are flags used > internal to the syncache. Later you use TCP_OFFLOAD_ as the prefix, so that > may be appropriate here also. > > +#define TCP_OFFLOAD_LISTEN_OPEN 1 > +#define TCP_OFFLOAD_LISTEN_CLOSE 2 > + > +typedef void (*tcp_offload_listen_fn)(void *, int, struct tcpcb *); > +EVENTHANDLER_DECLARE(tcp_offload_listen, tcp_offload_listen_fn); > > Here and with the syncache interface, it seems like you're adding new > operations as modes to functions, whereas elsewhere you're adding multiple > functions. There isn't too much difference, but I think I'd rather see a > slightly wider interface (i.e., more functions) and avoid flags that change > the semantics of particular functions. That is to say: tu_syncache_add and > tu_syncache_drop, and likewise tcp_offload_listen and tcp_offload_unlisten (or > something similar). I've kept the interface to as few functions as possible. I've expanded tcp_output to 4 functions because it was necessary semantically. I'll widen the interface if Sam agrees. > > +int tcp_offload_connect(struct socket *so, struct sockaddr *nam); > > This prototype appear not to be documented. Ok, it appears fairly self-documenting to me =-D > > +/* > + * The tcp_gen_* routines are wrappers around the toe_usrreqs calls, > + * in the non-offloaded case they translate to tcp_output. > > Not really sure about the _gen_ naming, but not sure I have a better > suggestion in mind just yet -- maybe _output_ since they control output. I'm > not entirely thrilled that all of these become inline functions in include > files, although since a couple are used in multiple tcp*.c files, it may be > the least bad of the options. My comments above about possibly restructuring > this to avoid lots of indirection for non-offloaded case strengthen the > argument for inlining, however. > > +#ifndef TCP_OFFLOAD_DISABLE > > I notice you've renamed the option, and I like the new name a lot better. > However, I also notice that it doesn't seem to appear in conf/options or > conf/files. Could you make sure to add it? > > +/* > + * The socket has not been marked as "do not offload" > + */ > +#define SO_OFFLOADABLE(so) ((so->so_options & SO_NO_OFFLOAD) == 0) > > I find myself wondering if the offload option should be a TCP socket option > rather than a socket-layer option, but don't have strong feelings about this. The assumption is that, if you a) pay the extra for a version of the card that supports TOE and b) you load the toe module (it isn't part of the NIC driver) that you want your existing software to have its connections offloaded. I don't know of any customers that want to modify their user applications to selectively enable TOE. > > What do you intend the policy model to be for enabling TOE, in general? That > if the TOE capability is available and the TOE capability is enabled, all TCP > sockets via the enabled interface will be offloaded unless SO_NO_OFFLOAD is > set? That is the current usage model. At some point we may tie it into pf/ipf/ipfw to provide for offload policy. However, currently we offload all connections on an interface until we run out of TCAM entries. >Are you currently anticipating enabling the capability by default? Yes, *if the TOE driver is loaded*. > > Nitpick on style: > > + /* disconnect offload device, if any */ > > Comments that are sentences should begin with an upper case letter and end > with a period. :-) And another one: > > +#ifdef TCP_OFFLOAD_DISABLE > +#define TOEPCB_SET(sc) (0) > +#else > +#define TOEPCB_SET(sc) ((sc)->sc_toepcb != NULL) > +#endif > + > + > > Too many blank lines there. > > I've noticed that in quite a few places, we prefer X_ISSET() to test for a set > flag or other condition, in order to prevent confusion with X_SET() assigning > a value. I think that's pretty sensible, and should do it more myself, so > encourage you to do the same That sounds reasonable. -Kip From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 18:15:42 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9236B16A418 for ; Sat, 15 Dec 2007 18:15:42 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from tog.net (tog.net [216.89.226.5]) by mx1.freebsd.org (Postfix) with ESMTP id 66EED13C447 for ; Sat, 15 Dec 2007 18:15:42 +0000 (UTC) (envelope-from bofh@terranova.net) Received: from [216.89.228.170] (host-216-89-228-170.wireless.terranova.net [216.89.228.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tog.net (Postfix) with ESMTP id A914429B5FB for ; Sat, 15 Dec 2007 13:15:41 -0500 (EST) Message-ID: <476419CD.9070401@terranova.net> Date: Sat, 15 Dec 2007 13:15:41 -0500 From: Travis Mikalson Organization: TerraNovaNet Internet Services User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> <476343B4.8080208@FreeBSD.org> <86tzmk54tt.fsf@ds4.des.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 18:15:42 -0000 Ivan Voras wrote: > Dag-Erling SmÞrgrav wrote: >> Ivan Voras writes: >>> Maxim Sobolev wrote: >>>> That's no longer true. You can't get more than 5-10MB/s from >>>> seek-intensive RAID0 with two 15K drives, while 20-30MB/s is not a >>>> problem for the comparable priced/sized SSD drive. >>> Can you point me at a vendor with SSDs of such characteristics? >> Kingston CF Elite, 20 / 25 MBps write / read >> Kingston CF Ultimate, 40 / 45 MBps write / read >> >> SanDisk Extreme III CF, 20 MBps >> SanDisk Extreme IV CF, 45 MBps >> >> Sony CF 300X, 45 MBps >> >> These are just a few of those available from my regular supplier. > > These are all "normal" CompactFlash cards, for which the widely > available size seems to be 16 GB max, right? I was thinking about > something more like this: > http://gizmodo.com/gadgets/peripherals/adatas-128gb-solid-state-drive-sees-the-light-of-day-231693.php > or this: http://www.mtron.net/English/Product/pc_msd1000.asp > > Did you (or anyone) deploy CF drives for production servers? If you're using compact flash for something that's constantly updated like a ZIL, wouldn't your CF card die real quick? I've deployed CF in production, but as a read-only medium with occasional writes only for configuration updates. From what I understand the specialized expensive solid-state drives that you guys are discussing are better designed for this type of write duty whereas CF would probably not last very long. Since a ZIL is not really seek-intensive, why not just offload it to its own standard hard disk that has its write caching and all other similar data-corrupting technologies disabled? From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 18:17:53 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5957616A41B; Sat, 15 Dec 2007 18:17:53 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id D56F113C461; Sat, 15 Dec 2007 18:17:52 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id lBFIHoEO083518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2007 10:17:50 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47641A4E.5050106@errno.com> Date: Sat, 15 Dec 2007 10:17:50 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Robert Watson References: <20071215100351.Q70617@fledge.watson.org> <20071215152959.V85668@fledge.watson.org> In-Reply-To: <20071215152959.V85668@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-dcc-servers-Metrics: om; whitelist Cc: Kip Macy , FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 18:17:53 -0000 Robert Watson wrote: > > On Sat, 15 Dec 2007, Robert Watson wrote: > >> More comments to follow. > > Some more, back to tcp_offload.c which I didn't look at last time around: > > + ifp = rt->rt_ifp; > + tdev = TOEDEV(ifp); > + if (tdev == NULL) > + return (EINVAL); > + > + if (tdev->tod_can_offload(tdev, so) == 0) > + return (EINVAL); > > I sort of expected to see a if_capenable check for TOE here, but I > guess it doesn't make much difference if the flag is going to be > checked at the lower level. However, in the case of things like TCP > checksum offload, we do do the check at the higher level, so it > wouldn't be inconsistent to do that. > > BTW, could you prepare similar comments for toedev.h? > > +struct toe_usrreqs tcp_offload_usrreqs = { > + .tu_send = tcp_output, > + .tu_rcvd = tcp_output, > + .tu_disconnect = tcp_output, > + .tu_abort = tcp_output, > + .tu_detach = tcp_offload_detach_noop, > + .tu_syncache_event = tcp_offload_syncache_event_noop, > +}; > > This structure seems to introduce quite a bit more indirection for > non-offloaded cases than before, especially to do things like this: > > +static void > +tcp_offload_syncache_event_noop(int event, void *toepcb) > +{ > +} > > The compiler can't compile these out because it likely doesn't do much > in the way of function pointer analysis, and probably shouldn't. > However, it leaves quite a few code paths heavier weight than before. > I think I'd prefer a model in which a TF_OFFLOAD flag is set on the > tcpcb and then we conditionally invoke tu_foo as a result. I.e.,: > > static __inline int > tcp_gen_send(struct tcpcb *tp) > { > > #ifndef TCP_OFFLOAD_DISABLE > if (tcp->f_flag & TF_OFFLOADED) > return (tp->t_tu->tu_send(tp)); > else > #endif > return (tcp_output(tp)); > } > > This would compile to a straight call to tcp_output() when offloading > isn't compiled in, and when it is compiled in and offloading isn't > enabled, we do a simple flag check rather than invoking a function via > a series of pointers. I suggested Kip explore this technique as an alternative to having the inlines that check whether a socket is marked for offload or not (tradeoff indirect function call vs conditionals). My comment to him was that I find it can make code more intuitive. But with the common case being empty functions it's probably not a great option as the compiler cannot optimize it out. > > Back to tcp_offload.h: > > +#define SC_ENTRY_PRESENT 1 /* 4-tuple already present */ > +#define SC_DROP 2 /* connection was timed out */ > > I think you should give these a different prefix, since they're part > of the interface between the syncache and offload, and SC_ generally > are flags used internal to the syncache. Later you use TCP_OFFLOAD_ > as the prefix, so that may be appropriate here also. > > +#define TCP_OFFLOAD_LISTEN_OPEN 1 > +#define TCP_OFFLOAD_LISTEN_CLOSE 2 > + > +typedef void (*tcp_offload_listen_fn)(void *, int, struct tcpcb > *); > +EVENTHANDLER_DECLARE(tcp_offload_listen, tcp_offload_listen_fn); > > Here and with the syncache interface, it seems like you're adding new > operations as modes to functions, whereas elsewhere you're adding > multiple functions. There isn't too much difference, but I think I'd > rather see a slightly wider interface (i.e., more functions) and avoid > flags that change the semantics of particular functions. That is to > say: tu_syncache_add and tu_syncache_drop, and likewise > tcp_offload_listen and tcp_offload_unlisten (or something similar). > > +int tcp_offload_connect(struct socket *so, struct sockaddr *nam); > > This prototype appear not to be documented. > > +/* > + * The tcp_gen_* routines are wrappers around the toe_usrreqs calls, > + * in the non-offloaded case they translate to tcp_output. > > Not really sure about the _gen_ naming, but not sure I have a better > suggestion in mind just yet -- maybe _output_ since they control > output. I'm not entirely thrilled that all of these become inline > functions in include files, although since a couple are used in > multiple tcp*.c files, it may be the least bad of the options. My > comments above about possibly restructuring this to avoid lots of > indirection for non-offloaded case strengthen the argument for > inlining, however. > > +#ifndef TCP_OFFLOAD_DISABLE > > I notice you've renamed the option, and I like the new name a lot > better. However, I also notice that it doesn't seem to appear in > conf/options or conf/files. Could you make sure to add it? > > +/* > + * The socket has not been marked as "do not offload" > + */ > +#define SO_OFFLOADABLE(so) ((so->so_options & SO_NO_OFFLOAD) == 0) > > I find myself wondering if the offload option should be a TCP socket > option rather than a socket-layer option, but don't have strong > feelings about this. > > What do you intend the policy model to be for enabling TOE, in > general? That if the TOE capability is available and the TOE > capability is enabled, all TCP sockets via the enabled interface will > be offloaded unless SO_NO_OFFLOAD is set? Are you currently > anticipating enabling the capability by default? > > Nitpick on style: > > + /* disconnect offload device, if any */ > > Comments that are sentences should begin with an upper case letter and > end with a period. :-) And another one: > > +#ifdef TCP_OFFLOAD_DISABLE > +#define TOEPCB_SET(sc) (0) > +#else > +#define TOEPCB_SET(sc) ((sc)->sc_toepcb != NULL) > +#endif > + > + > > Too many blank lines there. > > I've noticed that in quite a few places, we prefer X_ISSET() to test > for a set flag or other condition, in order to prevent confusion with > X_SET() assigning a value. I think that's pretty sensible, and should > do it more myself, so encourage you to do the same > From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 18:19:46 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C672216A5C2 for ; Sat, 15 Dec 2007 18:19:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id 7B83213C467 for ; Sat, 15 Dec 2007 18:19:46 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2248979waf.3 for ; Sat, 15 Dec 2007 10:19:46 -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=m9RV1o99QgVaGtoRcEeT0SezTSp5AN5N7JH5VNAJPY4=; b=rq1E3UODOuy2Gr+0EkvZVKHblSVb6g+nTHhtUhsNOZ5IEVIgpK+xwcN9HkvMsrchyNVynnBDsQqMsdBkpp+1Xz5ocR9Yy24Qycikkt1Tku5vjUsBHSOgtxi8esDTAXpZai+/tBrpthilFWOPYh5DPACFeunFYOopv8bW4nG7xSU= 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=lmTscsRcgdIJvX4uMX0qMvV5ZbFVkp8OGdrE7qu761PATOVEFQ0u4PevGt5lo0JuaREPvNgA+Y0gPY7uiKeUXrZ5dpIWZxuTK+gDLQduJOBGay+LBXssbMaLRK8idoaTiSdbjge91ltW1wOafb2cBGytTj3uUqUiB2WAfNVNkYc= Received: by 10.115.92.2 with SMTP id u2mr930461wal.139.1197742785662; Sat, 15 Dec 2007 10:19:45 -0800 (PST) Received: by 10.114.255.11 with HTTP; Sat, 15 Dec 2007 10:19:45 -0800 (PST) Message-ID: Date: Sat, 15 Dec 2007 10:19:45 -0800 From: "Kip Macy" To: "Sam Leffler" In-Reply-To: <47641A4E.5050106@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071215100351.Q70617@fledge.watson.org> <20071215152959.V85668@fledge.watson.org> <47641A4E.5050106@errno.com> Cc: FreeBSD Current , Robert Watson , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 18:19:46 -0000 On Dec 15, 2007 10:17 AM, Sam Leffler wrote: > > Robert Watson wrote: > > > > On Sat, 15 Dec 2007, Robert Watson wrote: > > > >> More comments to follow. > > > > Some more, back to tcp_offload.c which I didn't look at last time around: > > > > + ifp = rt->rt_ifp; > > + tdev = TOEDEV(ifp); > > + if (tdev == NULL) > > + return (EINVAL); > > + > > + if (tdev->tod_can_offload(tdev, so) == 0) > > + return (EINVAL); > > > > I sort of expected to see a if_capenable check for TOE here, but I > > guess it doesn't make much difference if the flag is going to be > > checked at the lower level. However, in the case of things like TCP > > checksum offload, we do do the check at the higher level, so it > > wouldn't be inconsistent to do that. > > > > BTW, could you prepare similar comments for toedev.h? > > > > +struct toe_usrreqs tcp_offload_usrreqs = { > > + .tu_send = tcp_output, > > + .tu_rcvd = tcp_output, > > + .tu_disconnect = tcp_output, > > + .tu_abort = tcp_output, > > + .tu_detach = tcp_offload_detach_noop, > > + .tu_syncache_event = tcp_offload_syncache_event_noop, > > +}; > > > > This structure seems to introduce quite a bit more indirection for > > non-offloaded cases than before, especially to do things like this: > > > > +static void > > +tcp_offload_syncache_event_noop(int event, void *toepcb) > > +{ > > +} > > > > The compiler can't compile these out because it likely doesn't do much > > in the way of function pointer analysis, and probably shouldn't. > > However, it leaves quite a few code paths heavier weight than before. > > I think I'd prefer a model in which a TF_OFFLOAD flag is set on the > > tcpcb and then we conditionally invoke tu_foo as a result. I.e.,: > > > > static __inline int > > tcp_gen_send(struct tcpcb *tp) > > { > > > > #ifndef TCP_OFFLOAD_DISABLE > > if (tcp->f_flag & TF_OFFLOADED) > > return (tp->t_tu->tu_send(tp)); > > else > > #endif > > return (tcp_output(tp)); > > } > > > > This would compile to a straight call to tcp_output() when offloading > > isn't compiled in, and when it is compiled in and offloading isn't > > enabled, we do a simple flag check rather than invoking a function via > > a series of pointers. > > I suggested Kip explore this technique as an alternative to having the > inlines that check whether a socket is marked for offload or not > (tradeoff indirect function call vs conditionals). My comment to him > was that I find it can make code more intuitive. But with the common > case being empty functions it's probably not a great option as the > compiler cannot optimize it out. Actually, in the datapath the common case is an indirect call to tcp_output. The only empty function that is called is detach, and that is only called once on shutdown. -Kip From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 18:40:40 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A870316A469 for ; Sat, 15 Dec 2007 18:40:40 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 69A1213C467 for ; Sat, 15 Dec 2007 18:40:40 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2258856waf.3 for ; Sat, 15 Dec 2007 10:40:39 -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=O9fG3Ze5eAT0KUU5+5gwDTc7eXjVf3bY9kTVjyuyXbE=; b=mTaOajIJBxbVIjVcXl4m7dDH3f7mR/G25Z8OYmck5MXx/TuRKEwGr8Z/Vl0eyAVQg0t4/P5dpx+RM03eYEut05phNuDgyei7uSdCMag9zL1LHf/jPVQ5kSWKIKv5kVFF1hDa+jCNRnSFdFO5wW/nK9VCfkiyzXOxKNm2bW3QJbE= 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=jcblXZlFNzb0cCt+U7X1tc9EaWA4GrPebkXpiCAy1Cg8uldMoeOtEIkISknA0ueclcJfU8VNyKuFJ//CN14PGk4ueAYxCWTbryFk3i8/w7kO28s4pijEgcSRmRP/Y1bcVXKAGdzH535OPfV+HPsyhTh4+J27U1Cchm4DwlYcA8M= Received: by 10.115.78.1 with SMTP id f1mr978726wal.100.1197744039662; Sat, 15 Dec 2007 10:40:39 -0800 (PST) Received: by 10.114.255.11 with HTTP; Sat, 15 Dec 2007 10:40:39 -0800 (PST) Message-ID: Date: Sat, 15 Dec 2007 10:40:39 -0800 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20071215100351.Q70617@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071215100351.Q70617@fledge.watson.org> Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 18:40:40 -0000 > My initial feeling is that, even if an interface supports TOE, we shouldn't > enable the capability in the enabled vector by default, as TOE bypasses > firewall behavior, etc, and would certainly be a surprise if an admin swapped > a chelsio card for a non-TOE supporting card. What's your feeling on this? The current implementation bypasses the firewall. This and likely other hardware has extensive filtering support so it isn't neccessarily intrinsic. The usage model at this moment is that the customer makes a conscious decision to load the TOE driver and understands the implications. I think this is quite adequate for 10GigE cards currently. However, this will need to be revisited when these chips start showing up on mainstream motherboards. > + * The TOE API assumes that the tcp offload engine can offload the > + * the entire connection from set up to teardown, with some provision > + * being made to allowing the software stack to handle time wait. If > + * the device does not meet these criteria, it is the driver's responsibility > + * to overload the functions that it needs to in tcp_usrreqs and make > + * its own calls to tcp_output if it needs to do so. > > While I'm familiar with TCP, I'm less familiar with the scope of what cards > support for TOE. Do we know of any cards that are less capable than the > chelsio card in this respect, or are they all sort of on-par on that front? > I.e., do we think the above eventuality is likely? I don't have any way of knowing. I think it is probably safe to say that any vendors that don't meet that criteria now will in the future as transistor density increases. > > If we don't, then one of the things I'd like to see us do is fairly carefully > assert, at least for a few months, that TCP never "slips" into any > transmission-related paths that could lead to truly odd and hard-to-diagnose > behavior when runnning with TOE. I.e., tcp_output, etc. I'm happy to do that. However, I see problems introduced by offloading connections as being driver bugs much the same as problems caused by the driver's TCP segmentation offload or checksum offload. The problems will be isolated to connections using a specific interface. > > If we do think it's likely, we don't need to address this immediately, but we > should make sure that before we ship TOE in a release, we've thought somewhat > more thoroughly about that case. As long as TOE remains un-MFC'd, we don't > find ourselves with an obligation to maintain guarantees about the interfaces, > and that includes dealing with incompatibility :-). Do we know if any of the > current 10gbps vendors other than chelsio are actively looking at TOE on > FreeBSD, and could be engaged in discussion? As with most vendors and FreeBSD, I suspect that the two that I know of will have zero interest until they have a prospective customer. At which point they'll want it done yesterday. > I think it might be useful to add a couple of paragraphs here on three topics: > > (1) Clarify the way in which windows are updated between the device driver and > the socket code, both for sending/receiving. You talk a bit about > "credit", but introducing it up-front would be useful. I didn't realize a definition was necessary. To the best of my knowledge this is the common term used when discussing flow control. I've seen it used for Fibre Channel and IB. The one ambiguity that arises is whether or not it refers to bytes or segments. > (2) One of the issues I've run into in the TCP and socket code generally is > that there was significant lack of clarity on the "life cycle" of the set > of related data structures. Could you write a bit of text about when > drivers will allocate state and when they will free it? I.e., tu_attach > allocates state, tu_{abort,detach} free it, and TCP promises not to call > anything before attach or anything after abort/detach. > > (3) Could you talk at a high level about the ways in which TOE drivers will > interact with TCP? You do it a bit in each of the sections, but if > there's a principle, pulling it out would be useful. Also, you should > indicate whether the driver is allowed to drop the inpcb lock or not. I've done my best to minimize changes to TCP. It is safe to assume that the invariants are the same as those for tcp_output. I think we should ask the author of tcp_output to document the interface, expected state transitions, and its invariants (joke). > > Doing this would address a few of the comments I have below also. > > + * + tu_send > + * - tells the driver that new data may have been added to the > + * socket's send buffer - the driver should not fail if the > + * buffer is in fact unchanged > > I'm a bit confused by the description of the error condition here. Could you > clarify when a driver should return an error, and what the impact of an error > returned will be on the connection state? In fact, it probably makes sense to > have an up-front comment on conventions for error-handling -- if TOE returns > an error will that generally lead to a TCP tear-down? The offload routines are substituted for tcp_output and thus should interact with the stack in the same way. By extension they should have the same failure modes and invariants. > > + * - The driver expects the inpcb lock to be held and > > This comment is truncated -- is there an and? > > We should specify that drivers are not allowed to drop the inpcb lock if that > is the case, FYI. > > + * + tu_rcvd > + * - returns credits to the driver and triggers window updates > + * to the peer (a credit is a byte in the user's receive window) > > Might begin with a sentence defining the notion of credit. Is it possible to > use tu_rcvd to reduce credit to the card if the socket buffer size is changed, > or just increase it? > > + * - the driver is expected to determine how many bytes have been > + * consumed and credit that back to the card so that it can grow > + * the window again > > Could you provide an example of how it is to do that -- i.e., is it just going > to inspect so_rcv in the same way native TCP does? Correct. It is up to the driver to maintain any ancillary state needed to determine that. > > + * - this function needs to correctly handle being called any number of > + * times without any bytes being consumed from the receive buffer. > + * - the driver expects the inpcb lock to be held > + * > + * + tu_disconnect > + * - tells the driver to send FIN to peer > + * - driver is expected to send the remaining data and then do a clean half > close > + * - disconnect implies at least half-close so only send, abort, and detach > + * are legal > > Could you clarify this a bit? Do you mean that TCP guarangees that only > tu_send, tu_abort, and tu_detach will be delivered to the driver in the > future? Those are the only things that make sense, but the driver is not expected to break if TCP does. > > + * - the driver is expected to handle transition through the shutdown > + * state machine and allow the stack to support SO_LINGER. > > Probably worth commenting that the device driver won't detach the toe state. > > + * > + * + tu_abort > + * - closes the connection and sends a RST to peer > + * - driver is expectd to trigger an RST and detach the toepcb > > In regular TCP, the pru_abort method is only called on pending connections > while still in the listen queues of a listen socket. Is this true of > tu_abort, or is tu_abort a more general method to be used to cancel > connections? If so, probably worth commenting on that. tu_abort is called in place of tcp_output in pru_abort. > + * - no further calls are legal after abort > + * - the driver expects the inpcb lock to be held > + * > + * + tu_detach > + * - tells driver that the socket is going away so disconnect > + * the toepcb and free appropriate resources > + * - allows the driver to cleanly handle the case of connection state > + * outliving the socket > + * - no further calls are legal after detach > + * - the driver acquires the tcbinfo lock > > For this call, you haven't specified whether the inpcb lock is held. If it > is, the driver acquiring the tcbinfo lock without first dropping the inpcb > lock would be a lock order reversal. Should the caller instead acquire/hold > it? The inpcb lock no longer exists at this point. > For the above calls, what guarantees does the TCP stack make about the > presence of the socket, if any? The assumptions are the same as those of tcp_output except for syncache_event and detach, at which points the socket does not yet exist or no longer exists. > These interfaces all pass the tcpcb, but in our regular TCP stack, the > invariant is the existence of the inpcb, not the tcpcb, which may be replaced > with a tcptw (or in one edge case, inp_ppcb may be NULL). If there will be > drivers in the future that implement timewait, perhaps we should be passing in > the inpcb? The interface is intended to drop in the place of tcp_output. > > + * + tu_syncache_event > + * - even if it is not actually needed, the driver is expected to > + * call syncache_add for the initial SYN and then syncache_expand > + * for the SYN,ACK > + * - tells driver that a connection either has not been added or has > + * been dropped from the syncache > + * - the driver is expected to maintain state that lives outside the > + * software stack so the syncache needs to be able to notify the > + * toe driver that the software stack is not going to create a connection > + * for a received SYN > + * - the driver is responsible for any synchronization required > > Presumably tu_syncache_event is called from the syncache and locks will be > held when that happens...? The driver doesn't care what locks the syncache holds. The syncache event handler is responsible for acquiring any locks necessary to synchronize with the rest of the driver for the transition from SYN_RCVD -> ESTABLISHED. > > How will the race between the syncache deciding to drop a connection of its > own accord and the hardware/driver deciding to accept be addressed, generally > speaking? That is a driver implementation issue. The one case to avoid is a deadlock between the driver calling syncache_expand and the syncache calling syncache_event. > > +8 > +extern struct toe_usrreqs tcp_offload_usrreqs; > > What is the purpose of this global? Presumably we can have two drivers that > both implement offload at once? I think you're follow on reading of tcp_offload.c answers that question. -Kip From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 19:01:10 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46C8616A41B; Sat, 15 Dec 2007 19:01:10 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 126A913C447; Sat, 15 Dec 2007 19:01:09 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 98DF2481B2; Sat, 15 Dec 2007 14:01:09 -0500 (EST) Date: Sat, 15 Dec 2007 19:01:09 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kip Macy In-Reply-To: Message-ID: <20071215184737.A85668@fledge.watson.org> References: <20071215100351.Q70617@fledge.watson.org> <20071215152959.V85668@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 19:01:10 -0000 On Sat, 15 Dec 2007, Kip Macy wrote: >> BTW, could you prepare similar comments for toedev.h? > > Ok, toedev.h isn't actually originally from me. However, it is a part of the > API and so should be documented. Thanks -- when designing a KPI, it's important to keep in mind that the goal of the author using it will not be to understand our TCP code, but instead, to implement the driver as quickly and cheaply as possible. Therefore we should make it as easy as possible for the authors of drivers to get it right. This comes out a few other places in my requests for clarification or additions -- imagine you weren't familiar with our TCP, what could you get wrong? >> This structure seems to introduce quite a bit more indirection for >> non-offloaded cases than before, especially to do things like this: > > This should never be called as sc_tu will only be set by the TOE interface > to the syncache. Also bear in mind that this and detach are only called once > per connection The real overhead is in calling tcp_output via an indirect > function call versus a direct function call. Considering the level of > gratuitous overhead in the output path I would be surprised if this were > measurable. Undoubtably this is true for high-end systems sporting PCIe interfaces with 10gbps cards, but we also run in other configurations. A complaint we've had a fair amount in the last few years is that our work has increasingly targeted high-end systems where overhead is in cache misses, and decreasingly targeted low-end systems where overhead is in instruction count. While you offer the opportunity to compile out some of this, I think we should try to make these things capable of being fast in both circumstances without multiple compile paths where it's easy. >> This would compile to a straight call to tcp_output() when offloading isn't >> compiled in, and when it is compiled in and offloading isn't enabled, we do >> a simple flag check rather than invoking a function via a series of >> pointers. > > This is what the current code does. See tcp_ofld.h in CVS. The indirection > was suggested by Sam as a cleaner abstraction. I think I prefer the CVS version of the two, although I would like to collapse the two ifdef parts per my example, so that ifdef and non-ifdef cases are side-by-side, and so that function headers are shared by the two cases. Ideally, we'd make the ifdef very, very small, as it's well-known that when we have two mutually exclusive code paths and one isn't compiled or used frequently, it rots. >> +int tcp_offload_connect(struct socket *so, struct sockaddr *nam); >> >> This prototype appear not to be documented. > > Ok, it appears fairly self-documenting to me =-D I'm sure you can find some insight to express that's not self-obvious in the code :-). >> I find myself wondering if the offload option should be a TCP socket option >> rather than a socket-layer option, but don't have strong feelings about >> this. > > The assumption is that, if you a) pay the extra for a version of the card > that supports TOE and b) you load the toe module (it isn't part of the NIC > driver) that you want your existing software to have its connections > offloaded. I don't know of any customers that want to modify their user > applications to selectively enable TOE. I think you mis-understood my question -- I was wondering whether it should be selectively disabled by an IP-layer socket option rather than a socket-layer socket option. >> What do you intend the policy model to be for enabling TOE, in general? >> That if the TOE capability is available and the TOE capability is enabled, >> all TCP sockets via the enabled interface will be offloaded unless >> SO_NO_OFFLOAD is set? > > That is the current usage model. At some point we may tie it into > pf/ipf/ipfw to provide for offload policy. However, currently we offload all > connections on an interface until we run out of TCAM entries. > >> Are you currently anticipating enabling the capability by default? > > Yes, *if the TOE driver is loaded*. I have somewhat mixed feelings about this, and feel like there should be something eloquent to say about having functionality administratively enabled rather than a default when compiled in, but can't quite figure out a nice expression of that. I think it might have something to do with expecting vendors of 10gbps cards to like shipping two modules for every device rather than one, and having the right behavior out of the box if they do ship just one. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 19:11:26 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8299C16A41A for ; Sat, 15 Dec 2007 19:11:26 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 4D08113C45A for ; Sat, 15 Dec 2007 19:11:26 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2274373waf.3 for ; Sat, 15 Dec 2007 11:11:25 -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=woJZIPW/sJEZpIYU2RnPVUN9MHnCMSQBsV531Gd5S4o=; b=p2cAWTN4c2BkQ3tv1slPyMb3HqAwxyJ4/cmSvCjg5DJsvlWKAOo0Ee4ytPu/lFOAAy6J1A+Mig6jcC6hJtr4v+RgHxuL3xVI5kK94onWZ6Xq77JtLL74DpPLJ/EUDcZbQJXdqhC2dvTU73qB/vgijPLKn4GUP07a1nvMWwBfwSA= 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=HG3zMnfHAQx5aLX2Qvdg3xRBLoHfKX4OfX5akEijahvszDrtaESGiCymez512aU8+jj/xQfANYG09Z/g91XJKWnH0n3IWx2CiGO2zrD4Mv6tFz2AGA7a8GD/2c0VQK3xWEtuWAaw+k7ztxmIsVnKnD9JRoGIEjIMaMVXzJDNrdI= Received: by 10.114.146.1 with SMTP id t1mr813439wad.20.1197745885372; Sat, 15 Dec 2007 11:11:25 -0800 (PST) Received: by 10.114.255.11 with HTTP; Sat, 15 Dec 2007 11:11:20 -0800 (PST) Message-ID: Date: Sat, 15 Dec 2007 11:11:20 -0800 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20071215184737.A85668@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071215100351.Q70617@fledge.watson.org> <20071215152959.V85668@fledge.watson.org> <20071215184737.A85668@fledge.watson.org> Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 19:11:26 -0000 > > Undoubtably this is true for high-end systems sporting PCIe interfaces with > 10gbps cards, but we also run in other configurations. A complaint we've had > a fair amount in the last few years is that our work has increasingly targeted > high-end systems where overhead is in cache misses, and decreasingly targeted > low-end systems where overhead is in instruction count. While you offer the > opportunity to compile out some of this, I think we should try to make these > things capable of being fast in both circumstances without multiple compile > paths where it's easy. Ok. That was the intent of the initial design. The design intent, however, was that it would be compiled out on slower platforms - sparc64, arm, mips etc. > Ideally, we'd make the ifdef very, very small, as it's well-known that when we > have two mutually exclusive code paths and one isn't compiled or used > frequently, it rots. Good point. > > >> I find myself wondering if the offload option should be a TCP socket option > >> rather than a socket-layer option, but don't have strong feelings about > >> this. > > > > The assumption is that, if you a) pay the extra for a version of the card > > that supports TOE and b) you load the toe module (it isn't part of the NIC > > driver) that you want your existing software to have its connections > > offloaded. I don't know of any customers that want to modify their user > > applications to selectively enable TOE. > > I think you mis-understood my question -- I was wondering whether it should be > selectively disabled by an IP-layer socket option rather than a socket-layer > socket option. I did misunderstand, and yes a TCP_ socket option would probably be more appropriate.. > > That is the current usage model. At some point we may tie it into > > pf/ipf/ipfw to provide for offload policy. However, currently we offload all > > connections on an interface until we run out of TCAM entries. > > > >> Are you currently anticipating enabling the capability by default? > > > > Yes, *if the TOE driver is loaded*. > > I have somewhat mixed feelings about this, and feel like there should be > something eloquent to say about having functionality administratively enabled > rather than a default when compiled in, but can't quite figure out a nice > expression of that. I think it might have something to do with expecting > vendors of 10gbps cards to like shipping two modules for every device rather > than one, and having the right behavior out of the box if they do ship just > one. This is easy enough to arrange, just as we have TSO and jumbo frames that some drivers default to on and others default to off, we can have the TOE capability enabled or disabled by default by the driver. I think that if vendors left TOE disabled by default in the single module case that this would address your concerns, would it not? -Kip From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 19:16:23 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69DD016A469; Sat, 15 Dec 2007 19:16:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 34E2213C4E8; Sat, 15 Dec 2007 19:16:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B08814700F; Sat, 15 Dec 2007 14:16:22 -0500 (EST) Date: Sat, 15 Dec 2007 19:16:22 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kip Macy In-Reply-To: Message-ID: <20071215190252.I85668@fledge.watson.org> References: <20071215100351.Q70617@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 19:16:23 -0000 On Sat, 15 Dec 2007, Kip Macy wrote: > The current implementation bypasses the firewall. This and likely other > hardware has extensive filtering support so it isn't neccessarily intrinsic. I'm not sure I agree when it comes to features like DUMMYNET, NAT, BPF, etc. TCP offload completely bypasses, by its very intent, most of the network stack. > The usage model at this moment is that the customer makes a conscious > decision to load the TOE driver and understands the implications. I think > this is quite adequate for 10GigE cards currently. However, this will need > to be revisited when these chips start showing up on mainstream > motherboards. I think I would prefer that our policy switch be the capenable flag, so that compiling things in or out (or loading, which is the logical equivilent) doesn't change functional behavior for existing interfaces. >> While I'm familiar with TCP, I'm less familiar with the scope of what cards >> support for TOE. Do we know of any cards that are less capable than the >> chelsio card in this respect, or are they all sort of on-par on that front? >> I.e., do we think the above eventuality is likely? > > I don't have any way of knowing. I think it is probably safe to say that any > vendors that don't meet that criteria now will in the future as transistor > density increases. I think it behooves us to find out, given that we're designing a KPI for those cards also. I agree with the transistor argument, and given that TOE is a fairly undeployed technology at this point, it may quickly resolve itself if it hasn't. >> If we don't, then one of the things I'd like to see us do is fairly >> carefully assert, at least for a few months, that TCP never "slips" into >> any transmission-related paths that could lead to truly odd and >> hard-to-diagnose behavior when runnning with TOE. I.e., tcp_output, etc. > > I'm happy to do that. However, I see problems introduced by offloading > connections as being driver bugs much the same as problems caused by the > driver's TCP segmentation offload or checksum offload. The problems will be > isolated to connections using a specific interface. Interesting point -- it's amazing how broken checksum processing in, and TCP is many orders of magnitude more complex. >> the socket code, both for sending/receiving. You talk a bit about >> "credit", but introducing it up-front would be useful. > > I didn't realize a definition was necessary. To the best of my knowledge > this is the common term used when discussing flow control. I've seen it used > for Fibre Channel and IB. The one ambiguity that arises is whether or not it > refers to bytes or segments. I think a phrase wouldn't hurt; also, I notice you did only address flow control in one direction in the comments, which is why I mentioned both sending and receiving. The clearer we make this, the happier we'll be. I suspect we'll actually want to move a lot of this text from the include file to the man page for the TOE interface... >> (3) Could you talk at a high level about the ways in which TOE drivers will >> interact with TCP? You do it a bit in each of the sections, but if >> there's a principle, pulling it out would be useful. Also, you should >> indicate whether the driver is allowed to drop the inpcb lock or not. > > I've done my best to minimize changes to TCP. It is safe to assume that the > invariants are the same as those for tcp_output. I think we should ask the > author of tcp_output to document the interface, expected state transitions, > and its invariants (joke). :-P Documenting locking semantics such as "You can rely on lock X being held, but do not drop it" takes an extra phrase and can save someone a lot of time. >> I'm a bit confused by the description of the error condition here. Could >> you clarify when a driver should return an error, and what the impact of an >> error returned will be on the connection state? In fact, it probably makes >> sense to have an up-front comment on conventions for error-handling -- if >> TOE returns an error will that generally lead to a TCP tear-down? > > The offload routines are substituted for tcp_output and thus should interact > with the stack in the same way. By extension they should have the same > failure modes and invariants. Most driver authors will not be intimately familiar with tcp_output()'s subleties, and documenting error-handling for a KPI is always a good idea. > The interface is intended to drop in the place of tcp_output. <"see what tcp_output does" repeated many times> tcp_output() was previously an internal function of the TCP code, and now the semantics are being exposed to device drivers. Let's not perpetuate poorly documented driver interfaces by adding another one. I think it would be a reasonable expectation of a driver author to have consistent documentation of the life cycle of data structures and objects, locking expectations and requirements, and the semantics for error values from functions. Certainly, they need to look at TCP a fair amount because they'll be pulling things out of inpcb, tcpcb, etc, but I'd rather we limit that requirement to simple things (addresses, socket options) that are relatively static and avoid it being for complex things (locking, error handling) that tend to be more subject to change. Also, if you document what you think the behavior is or should be, we can then check to see if we agree. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 19:44:37 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B00F016A420 for ; Sat, 15 Dec 2007 19:44:37 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 741AE13C455 for ; Sat, 15 Dec 2007 19:44:37 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2290153waf.3 for ; Sat, 15 Dec 2007 11:44:36 -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=7yysAaCrdon/nvxft4lKcfyuoNhIspPYfuMhAc3I8Dc=; b=rb0iT2CsvdhWeHg91kdvpqz0ObwDSqlhzqazwzO94yba5gvWWvk/z5RVfjE4Rz8EK6Wl0MMzbnArHyNecuGHqBuyLlTzUC/BCrsTpKlUN+IN3wqz0GnLtQ2mu7LxaFUG+AZRVw1BclwGP/X+gRndpvyzMh1iMZRQiABw7UEIw0Q= 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=aKBBwWFoa8v72VqSZVLi/WWlrpHqVICruKNIdMyytV0RwiuJqMl6xdcDdzjnrgHZcue+STOMBNYrhT/agdTmpkPzHsIpb4Tes3DR0VOo1qWWCrQJU6LoDei87XaL2J5W7MvbEVhI3GHWNrmyU344ah7Xs1OVS/0SRFFMqoK7Y7s= Received: by 10.114.60.19 with SMTP id i19mr1003839waa.142.1197747876704; Sat, 15 Dec 2007 11:44:36 -0800 (PST) Received: by 10.114.255.11 with HTTP; Sat, 15 Dec 2007 11:44:36 -0800 (PST) Message-ID: Date: Sat, 15 Dec 2007 11:44:36 -0800 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20071215190252.I85668@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071215100351.Q70617@fledge.watson.org> <20071215190252.I85668@fledge.watson.org> Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 19:44:37 -0000 On Dec 15, 2007 11:16 AM, Robert Watson wrote: > I think I would prefer that our policy switch be the capenable flag, so that > compiling things in or out (or loading, which is the logical equivilent) > doesn't change functional behavior for existing interfaces. I believe I said something similar to that in my recent mail. > I think it behooves us to find out, given that we're designing a KPI for those > cards also. I agree with the transistor argument, and given that TOE is a > fairly undeployed technology at this point, it may quickly resolve itself if > it hasn't. I certainly agree. However, where do you stand if they are unwilling to cooperate? > Interesting point -- it's amazing how broken checksum processing in, and TCP > is many orders of magnitude more complex. Correct, it isn't a given that a vendor's TCP implementation will work correctly. > I think a phrase wouldn't hurt; also, I notice you did only address flow > control in one direction in the comments, which is why I mentioned both > sending and receiving. It is fairly implicit for the sending case. There the driver returns credits to the stack via sbdrop(). I'll have to think about how to describe the two in a uniform fashion. > Documenting locking semantics such as "You can rely on lock X being held, but > do not drop it" takes an extra phrase and can save someone a lot of time. I *think* I've done that, I guess I could be clearer and say that the inpcb lock is held and expected not to be dropped. > > Most driver authors will not be intimately familiar with tcp_output()'s > subleties, and documenting error-handling for a KPI is always a good idea. I'll do my best. However, the TCP stack as it exists now really isn't very modular at all. This is intended to allow developers to skip duplicating large swaths of tcp code with small local changes the way they do on Linux. > > The interface is intended to drop in the place of tcp_output. > <"see what tcp_output does" repeated many times> > > tcp_output() was previously an internal function of the TCP code, and now the > semantics are being exposed to device drivers. Let's not perpetuate poorly > documented driver interfaces by adding another one. I think it would be a > reasonable expectation of a driver author to have consistent documentation of > the life cycle of data structures and objects, locking expectations and > requirements, and the semantics for error values from functions. Certainly, > they need to look at TCP a fair amount because they'll be pulling things out > of inpcb, tcpcb, etc, but I'd rather we limit that requirement to simple > things (addresses, socket options) that are relatively static and avoid it > being for complex things (locking, error handling) that tend to be more > subject to change. Also, if you document what you think the behavior is or > should be, we can then check to see if we agree. To the extent possible, yes. I'm not convinced that anyone person knows what all the existing invariants are in the stack as it is now. Do you feel that a Stevens'-esque understanding of the environment around the calls is necessary? I know it sounds like "other people beat their wives so I can too", but even something as well documented as ifnet gives no indication of what the locking conventions - e.g. you can't sleep or acquire sx locks in if_ioctl. The demands placed should be no greater than those placed on existing subsystems and should take into account the hitherto somewhat black box nature of TCP. -Kip From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 21:50:13 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 635B716A468; Sat, 15 Dec 2007 21:50:13 +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 38F6D13C4CC; Sat, 15 Dec 2007 21:50:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.8/8.13.8) with ESMTP id lBFLoCQO011717; Sat, 15 Dec 2007 16:50:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id lBFLoBQ1018503; Sat, 15 Dec 2007 16:50:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DF8A873039; Sat, 15 Dec 2007 16:50:10 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071215215010.DF8A873039@freebsd-current.sentex.ca> Date: Sat, 15 Dec 2007 16:50:10 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 21:50:13 -0000 TB --- 2007-12-15 21:37:38 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-12-15 21:37:38 - starting HEAD tinderbox run for i386/i386 TB --- 2007-12-15 21:37:38 - cleaning the object tree TB --- 2007-12-15 21:38:02 - cvsupping the source tree TB --- 2007-12-15 21:38:02 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2007-12-15 21:38:08 - building world (CFLAGS=-O -pipe) TB --- 2007-12-15 21:38:08 - cd /src TB --- 2007-12-15 21:38:08 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 15 21:38:09 UTC 2007 >>> 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 [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/base64.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/ether_addr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/eui64.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gai_strerror.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/getaddrinfo.c In file included from /src/lib/libc/net/getaddrinfo.c:63: /obj/src/tmp/usr/include/net/if.h:221:1: error: "IFCAP_TSO" redefined /obj/src/tmp/usr/include/net/if.h:219:1: error: this is the location of the previous definition *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-12-15 21:50:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-12-15 21:50:10 - ERROR: failed to build world TB --- 2007-12-15 21:50:10 - tinderbox aborted TB --- 526.06 user 61.17 system 752.35 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 21:51:36 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D652316A417; Sat, 15 Dec 2007 21:51:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7A113C455; Sat, 15 Dec 2007 21:51:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6D36548C2A; Sat, 15 Dec 2007 16:51:35 -0500 (EST) Date: Sat, 15 Dec 2007 21:51:35 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kip Macy In-Reply-To: Message-ID: <20071215214253.N85668@fledge.watson.org> References: <20071215100351.Q70617@fledge.watson.org> <20071215190252.I85668@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 21:51:36 -0000 On Sat, 15 Dec 2007, Kip Macy wrote: >> I think it behooves us to find out, given that we're designing a KPI for >> those cards also. I agree with the transistor argument, and given that TOE >> is a fairly undeployed technology at this point, it may quickly resolve >> itself if it hasn't. > > I certainly agree. However, where do you stand if they are unwilling to > cooperate? I think we should make a best faith effort to figure out how to do the right thing. Employing harsh interrogation tactics is probably not called for, but we have several vendors who are regularly involved in the FreeBSD community and may be willing to lend their insight as to their requirements, even if an implementation isn't immediately forthcoming. >> tcp_output() was previously an internal function of the TCP code, and now >> the semantics are being exposed to device drivers. Let's not perpetuate >> poorly documented driver interfaces by adding another one. I think it >> would be a reasonable expectation of a driver author to have consistent >> documentation of the life cycle of data structures and objects, locking >> expectations and requirements, and the semantics for error values from >> functions. Certainly, they need to look at TCP a fair amount because >> they'll be pulling things out of inpcb, tcpcb, etc, but I'd rather we limit >> that requirement to simple things (addresses, socket options) that are >> relatively static and avoid it being for complex things (locking, error >> handling) that tend to be more subject to change. Also, if you document >> what you think the behavior is or should be, we can then check to see if we >> agree. > > To the extent possible, yes. I'm not convinced that anyone person knows what > all the existing invariants are in the stack as it is now. Do you feel that > a Stevens'-esque understanding of the environment around the calls is > necessary? I know it sounds like "other people beat their wives so I can > too", but even something as well documented as ifnet gives no indication of > what the locking conventions - e.g. you can't sleep or acquire sx locks in > if_ioctl. The demands placed should be no greater than those placed on > existing subsystems and should take into account the hitherto somewhat black > box nature of TCP. Actually, what I was asking for in the omitted context above was something along the lines of the following, adapted for whatever the reality may be: Returning a non-zero value will lead to the software stack beginning a disconnect. Or, say, Non-zero return values will be ignored. (*) This is not intended as a contrarian point. I'm not looking for a complete exposition of the behavior of the stack -- rather, basic information that we should be documenting about a KPI, such as what an error being returned will do. Robert N M Watson Computer Laboratory University of Cambridge (*) In which case perhaps it should return void. From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 22:02:16 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 873B716A417; Sat, 15 Dec 2007 22:02:16 +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 5E63213C46A; Sat, 15 Dec 2007 22:02:15 +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.1/8.13.8) with ESMTP id lBFM2FQw029421; Sat, 15 Dec 2007 17:02:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id lBFM2Evd061977; Sat, 15 Dec 2007 17:02:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B03ED73039; Sat, 15 Dec 2007 17:02:14 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071215220214.B03ED73039@freebsd-current.sentex.ca> Date: Sat, 15 Dec 2007 17:02:14 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:02:16 -0000 TB --- 2007-12-15 21:50:10 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-12-15 21:50:10 - starting HEAD tinderbox run for i386/pc98 TB --- 2007-12-15 21:50:10 - cleaning the object tree TB --- 2007-12-15 21:50:34 - cvsupping the source tree TB --- 2007-12-15 21:50:34 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2007-12-15 21:50:40 - building world (CFLAGS=-O -pipe) TB --- 2007-12-15 21:50:40 - cd /src TB --- 2007-12-15 21:50:40 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 15 21:50:41 UTC 2007 >>> 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 [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/base64.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/ether_addr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/eui64.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gai_strerror.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/pc98/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/getaddrinfo.c In file included from /src/lib/libc/net/getaddrinfo.c:63: /obj/pc98/src/tmp/usr/include/net/if.h:221:1: error: "IFCAP_TSO" redefined /obj/pc98/src/tmp/usr/include/net/if.h:219:1: error: this is the location of the previous definition *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-12-15 22:02:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-12-15 22:02:14 - ERROR: failed to build world TB --- 2007-12-15 22:02:14 - tinderbox aborted TB --- 525.45 user 61.88 system 723.23 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 22:02:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CA0216A4D4 for ; Sat, 15 Dec 2007 22:02:29 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id AC03E13C45A for ; Sat, 15 Dec 2007 22:02:28 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2357988waf.3 for ; Sat, 15 Dec 2007 14:02:28 -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=GJ80xv4ybbGGM2jFPYOWs0MttisbZ6W6ea2OH9I8h08=; b=su269A67sQ31FcV7k8jvjE1Bftek9Ppp8wrX+Fswi1ckLskwtP+Kk0wOdqM/hG3KrMWiJpfljfuY2brAvccEkygnf5WWpdZBHRSKmDQeqBACxPhpQhC6UFENE7zWOQyt2cT6VGtqKzbujpwbLDGP31gMbUzOahhwTK7DxKojW4w= 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=rOCYY1vN5VXTd3LHU+Rnd7xzkO6FNLK7fat8o25Rb5EksHf+31asZ6xbn+bdcnW4TUgNjaEwpTcmNmLoHdhOitfsg/rfyrxxeoQqj1EpRlrAz/3jr+9htKCYXvzWqYnlmDShns85QfvTsTHf3IwWEDZok2AbJZ/oyTCeMvuaJPE= Received: by 10.115.48.12 with SMTP id a12mr838011wak.149.1197756148165; Sat, 15 Dec 2007 14:02:28 -0800 (PST) Received: by 10.114.255.11 with HTTP; Sat, 15 Dec 2007 14:02:28 -0800 (PST) Message-ID: Date: Sat, 15 Dec 2007 14:02:28 -0800 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20071215214253.N85668@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071215100351.Q70617@fledge.watson.org> <20071215190252.I85668@fledge.watson.org> <20071215214253.N85668@fledge.watson.org> Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:02:29 -0000 > I think we should make a best faith effort to figure out how to do the right > thing. Employing harsh interrogation tactics is probably not called for, but > we have several vendors who are regularly involved in the FreeBSD community > and may be willing to lend their insight as to their requirements, even if an > implementation isn't immediately forthcoming. :-) - the two vendors that I know of have not been active in the community. Sam has initiated contact on my behalf with the one vendor that might be willing to talk to us. The other vendor has an established pattern of ignoring all requests. > > >> tcp_output() was previously an internal function of the TCP code, and now > >> the semantics are being exposed to device drivers. Let's not perpetuate > >> poorly documented driver interfaces by adding another one. I think it > >> would be a reasonable expectation of a driver author to have consistent > >> documentation of the life cycle of data structures and objects, locking > >> expectations and requirements, and the semantics for error values from > >> functions. Certainly, they need to look at TCP a fair amount because > >> they'll be pulling things out of inpcb, tcpcb, etc, but I'd rather we limit > >> that requirement to simple things (addresses, socket options) that are > >> relatively static and avoid it being for complex things (locking, error > >> handling) that tend to be more subject to change. Also, if you document > >> what you think the behavior is or should be, we can then check to see if we > >> agree. > > > > To the extent possible, yes. I'm not convinced that anyone person knows what > > all the existing invariants are in the stack as it is now. Do you feel that > > a Stevens'-esque understanding of the environment around the calls is > > necessary? I know it sounds like "other people beat their wives so I can > > too", but even something as well documented as ifnet gives no indication of > > what the locking conventions - e.g. you can't sleep or acquire sx locks in > > if_ioctl. The demands placed should be no greater than those placed on > > existing subsystems and should take into account the hitherto somewhat black > > box nature of TCP. > > Actually, what I was asking for in the omitted context above was something > along the lines of the following, adapted for whatever the reality may be: > > Returning a non-zero value will lead to the software stack beginning a > disconnect. > > Or, say, > > Non-zero return values will be ignored. (*) > > This is not intended as a contrarian point. I'm not looking for a complete > exposition of the behavior of the stack -- rather, basic information that we > should be documenting about a KPI, such as what an error being returned will > do. That is quite reasonable. I perceived your initial request as being entirely too open-ended. -Kip From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 22:04:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48EBC16A418 for ; Sat, 15 Dec 2007 22:04:29 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C72B113C45D for ; Sat, 15 Dec 2007 22:04:28 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1J3f7L-0004H5-Nc for freebsd-current@freebsd.org; Sat, 15 Dec 2007 22:04:19 +0000 Received: from 78-0-75-218.adsl.net.t-com.hr ([78.0.75.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2007 22:04:19 +0000 Received: from ivoras by 78-0-75-218.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2007 22:04:19 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sat, 15 Dec 2007 23:04:04 +0100 Lines: 38 Message-ID: References: <47606C09.2070209@isc.org> <47609F0A.7010805@clearchain.com> <47609FE3.8040606@barafranca.com> <4760B444.1080604@clearchain.com> <06CAC7FC-DB58-441D-A6E0-76D1D8133393@tamu.edu> <86ir31xwlu.fsf@ds4.des.no> <476343B4.8080208@FreeBSD.org> <86tzmk54tt.fsf@ds4.des.no> <476419CD.9070401@terranova.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE571A66D14994A69A6948C4D" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-75-218.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <476419CD.9070401@terranova.net> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: ZFS melting under postgres... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:04:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE571A66D14994A69A6948C4D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Travis Mikalson wrote: > If you're using compact flash for something that's constantly updated > like a ZIL, wouldn't your CF card die real quick? Probably, for constant updates to the same areas. But as you say: > Since a ZIL is not really seek-intensive, why not just offload it to it= s > own standard hard disk that has its write caching and all other similar= > data-corrupting technologies disabled? Yes. I don't see a point writing a log that's mostly sequantially accessed on a SSD, and which probably wears the same areas on the drive. I'm more interested in loads like databases. --------------enigE571A66D14994A69A6948C4D 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 iD8DBQFHZE9UldnAQVacBcgRAttjAKCi57CQrhxt+0dheuDutvtorBvkRQCfSdvS IvAmoqkHHD5u/Y7JLeIv4yY= =vdYd -----END PGP SIGNATURE----- --------------enigE571A66D14994A69A6948C4D-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 22:10:02 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1379416A417 for ; Sat, 15 Dec 2007 22:10:02 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id E57DB13C4E7 for ; Sat, 15 Dec 2007 22:10:01 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2361625waf.3 for ; Sat, 15 Dec 2007 14:10:01 -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=h+24Fg3c9LzeiFqvFgU/0Azrdk1zydAlDo9kmTVcRCE=; b=cuIHIf5bb8UkslZhmbj8btL5MrxGaAjVdBBvrDTHkLGG/iK4KwKvc6lLi8cDr7O6ix3YsfBPObWp4yegZd0dbgx+CK2MrocpPS7xNKbJXTYtFBLYVbsEC6GI8p6g1AX0hEroGgP9O0oBJrO2ul91GaXFk6uD1w7rDC2Qkl3dy44= 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=xl0n3MQTJ+YY6Rz6zwr1f6q29eJMrdwUNjFJLpekPXnbpabhy7WRy8mIZUjBcneXdh//C3r92CizzJoRACi1spkXQ3+31Mv0qCKneAXK/np5wh0dHu8YHE35qrBthFgHfhk/hnuW/FtBMEMlK9S2vts9FU97pRRO36qA19BTJDM= Received: by 10.114.60.19 with SMTP id i19mr1141485waa.142.1197756601250; Sat, 15 Dec 2007 14:10:01 -0800 (PST) Received: by 10.114.255.11 with HTTP; Sat, 15 Dec 2007 14:10:01 -0800 (PST) Message-ID: Date: Sat, 15 Dec 2007 14:10:01 -0800 From: "Kip Macy" To: "FreeBSD Tinderbox" In-Reply-To: <20071215215010.DF8A873039@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071215215010.DF8A873039@freebsd-current.sentex.ca> Cc: current@freebsd.org, i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:10:02 -0000 Sorry. Should be fixed. On Dec 15, 2007 1:50 PM, FreeBSD Tinderbox wrote: > TB --- 2007-12-15 21:37:38 - tinderbox 2.3 running on freebsd-current.sentex.ca > TB --- 2007-12-15 21:37:38 - starting HEAD tinderbox run for i386/i386 > TB --- 2007-12-15 21:37:38 - cleaning the object tree > TB --- 2007-12-15 21:38:02 - cvsupping the source tree > TB --- 2007-12-15 21:38:02 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile > TB --- 2007-12-15 21:38:08 - building world (CFLAGS=-O -pipe) > TB --- 2007-12-15 21:38:08 - cd /src > TB --- 2007-12-15 21:38:08 - /usr/bin/make -B buildworld > >>> World build started on Sat Dec 15 21:38:09 UTC 2007 > >>> 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 > [...] > cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/base64.c > cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/ether_addr.c > cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/eui64.c > cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gai_strerror.c > cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/getaddrinfo.c > In file included from /src/lib/libc/net/getaddrinfo.c:63: > /obj/src/tmp/usr/include/net/if.h:221:1: error: "IFCAP_TSO" redefined > /obj/src/tmp/usr/include/net/if.h:219:1: error: this is the location of the previous definition > *** Error code 1 > > Stop in /src/lib/libc. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2007-12-15 21:50:10 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2007-12-15 21:50:10 - ERROR: failed to build world > TB --- 2007-12-15 21:50:10 - tinderbox aborted > TB --- 526.06 user 61.17 system 752.35 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 22:10:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55FB716A476 for ; Sat, 15 Dec 2007 22:10:13 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1185D13C447 for ; Sat, 15 Dec 2007 22:10:13 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1J3fCs-0005L5-SZ for freebsd-current@freebsd.org; Sat, 15 Dec 2007 22:10:02 +0000 Received: from 78-0-75-218.adsl.net.t-com.hr ([78.0.75.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2007 22:10:02 +0000 Received: from ivoras by 78-0-75-218.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 Dec 2007 22:10:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sat, 15 Dec 2007 23:05:11 +0100 Lines: 28 Message-ID: References: <200711292024.lATKOq5R000769@freefall.freebsd.org> <20071129233842.GA57951@ace.netcins.ceid.upatras.gr> <200711292024.lATKOq5R000769@freefall.freebsd.org> <20071130013826.GA66484@kobe.laptop> <20071204175541.GC47398@dragon.NUXI.org> <20071204181317.GA62240@kobe.laptop> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B4D360A14D2B5A8290FCE2C" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-75-218.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) In-Reply-To: <20071204181317.GA62240@kobe.laptop> X-Enigmail-Version: 0.95.5 Sender: news Subject: Re: [PATCH] gprof's broken in 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:10:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B4D360A14D2B5A8290FCE2C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >>> On 2007-11-29 20:24, Luoqi Chen wrote: >>>> Garrett, would you like to try out my fix? It's actually quite simpl= e, I'm wondering - has this been solved / committed to HEAD and RELENG_7? --------------enig3B4D360A14D2B5A8290FCE2C 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 iD8DBQFHZE+XldnAQVacBcgRAvagAKDl8KtHH9diFJkbV3jx4KFQBExImQCfS+jV e/QjLJAK8bm3mIn34Szm0o8= =IPob -----END PGP SIGNATURE----- --------------enig3B4D360A14D2B5A8290FCE2C-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 22:14:17 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE78416A420; Sat, 15 Dec 2007 22:14:17 +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 85FEE13C46B; Sat, 15 Dec 2007 22:14:17 +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.1/8.13.8) with ESMTP id lBFMEGDl030021; Sat, 15 Dec 2007 17:14:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.1/8.14.1) with ESMTP id lBFMEGpo078010; Sat, 15 Dec 2007 17:14:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4E8C073039; Sat, 15 Dec 2007 17:14:16 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071215221416.4E8C073039@freebsd-current.sentex.ca> Date: Sat, 15 Dec 2007 17:14:16 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:14:17 -0000 TB --- 2007-12-15 22:02:14 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-12-15 22:02:14 - starting HEAD tinderbox run for ia64/ia64 TB --- 2007-12-15 22:02:14 - cleaning the object tree TB --- 2007-12-15 22:02:40 - cvsupping the source tree TB --- 2007-12-15 22:02:40 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2007-12-15 22:02:46 - building world (CFLAGS=-O -pipe) TB --- 2007-12-15 22:02:46 - cd /src TB --- 2007-12-15 22:02:46 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 15 22:02:48 UTC 2007 >>> 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 [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/base64.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/ether_addr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/eui64.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gai_strerror.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/ia64/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/getaddrinfo.c In file included from /src/lib/libc/net/getaddrinfo.c:63: /obj/ia64/src/tmp/usr/include/net/if.h:221:1: error: "IFCAP_TSO" redefined /obj/ia64/src/tmp/usr/include/net/if.h:219:1: error: this is the location of the previous definition *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-12-15 22:14:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-12-15 22:14:16 - ERROR: failed to build world TB --- 2007-12-15 22:14:16 - tinderbox aborted TB --- 515.00 user 59.98 system 721.41 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 22:27:02 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7052A16A469; Sat, 15 Dec 2007 22:27:02 +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 4900313C4CE; Sat, 15 Dec 2007 22:27:02 +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.1/8.13.8) with ESMTP id lBFMR1Xt030640; Sat, 15 Dec 2007 17:27:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.1/8.14.1) with ESMTP id lBFMR1GV001131; Sat, 15 Dec 2007 17:27:01 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 597E173039; Sat, 15 Dec 2007 17:27:01 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20071215222701.597E173039@freebsd-current.sentex.ca> Date: Sat, 15 Dec 2007 17:27:01 -0500 (EST) X-Virus-Scanned: ClamAV version 0.91.1, clamav-milter version 0.91.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:27:02 -0000 TB --- 2007-12-15 22:14:16 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2007-12-15 22:14:16 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2007-12-15 22:14:16 - cleaning the object tree TB --- 2007-12-15 22:14:44 - cvsupping the source tree TB --- 2007-12-15 22:14:44 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2007-12-15 22:14:50 - building world (CFLAGS=-O -pipe) TB --- 2007-12-15 22:14:50 - cd /src TB --- 2007-12-15 22:14:50 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 15 22:14:51 UTC 2007 >>> 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 [...] cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/base64.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/ether_addr.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/eui64.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/gai_strerror.c cc -O -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -DINET6 -I/obj/powerpc/src/lib/libc -I/src/lib/libc/resolv -DPOSIX_MISTAKE -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libc/net/getaddrinfo.c In file included from /src/lib/libc/net/getaddrinfo.c:63: /obj/powerpc/src/tmp/usr/include/net/if.h:221:1: error: "IFCAP_TSO" redefined /obj/powerpc/src/tmp/usr/include/net/if.h:219:1: error: this is the location of the previous definition *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-12-15 22:27:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-12-15 22:27:01 - ERROR: failed to build world TB --- 2007-12-15 22:27:01 - tinderbox aborted TB --- 534.29 user 62.32 system 764.82 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 22:41:04 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F21F016A418; Sat, 15 Dec 2007 22:41:03 +0000 (UTC) (envelope-from SRS0=175ffd958ccf631e3f50bc84e4580880c9a9c317=550=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 437A213C44B; Sat, 15 Dec 2007 22:41:03 +0000 (UTC) (envelope-from SRS0=175ffd958ccf631e3f50bc84e4580880c9a9c317=550=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id UIE67201; Sat, 15 Dec 2007 14:41:01 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 6D1A045013; Sat, 15 Dec 2007 14:41:01 -0800 (PST) To: "Kip Macy" In-Reply-To: Your message of "Sat, 15 Dec 2007 14:02:28 PST." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1197758461_12041P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sat, 15 Dec 2007 14:41:01 -0800 From: "Kevin Oberman" Message-Id: <20071215224101.6D1A045013@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; ; X-Sender: X-To_Name: Kip Macy X-To_Domain: gmail.com X-To: "Kip Macy" X-To_Email: kip.macy@gmail.com X-To_Alias: kip.macy Cc: FreeBSD Current , Robert Watson , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:41:04 -0000 --==_Exmh_1197758461_12041P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sat, 15 Dec 2007 14:02:28 -0800 > From: "Kip Macy" > Sender: owner-freebsd-current@freebsd.org > > > I think we should make a best faith effort to figure out how to do the right > > thing. Employing harsh interrogation tactics is probably not called for, but > > we have several vendors who are regularly involved in the FreeBSD community > > and may be willing to lend their insight as to their requirements, even if an > > implementation isn't immediately forthcoming. > > :-) - the two vendors that I know of have not been active in the > community. Sam has initiated contact on my behalf with the one vendor > that might be willing to talk to us. The other vendor has an > established pattern of ignoring all requests. > > > > > >> tcp_output() was previously an internal function of the TCP code, and now > > >> the semantics are being exposed to device drivers. Let's not perpetuate > > >> poorly documented driver interfaces by adding another one. I think it > > >> would be a reasonable expectation of a driver author to have consistent > > >> documentation of the life cycle of data structures and objects, locking > > >> expectations and requirements, and the semantics for error values from > > >> functions. Certainly, they need to look at TCP a fair amount because > > >> they'll be pulling things out of inpcb, tcpcb, etc, but I'd rather we limit > > >> that requirement to simple things (addresses, socket options) that are > > >> relatively static and avoid it being for complex things (locking, error > > >> handling) that tend to be more subject to change. Also, if you document > > >> what you think the behavior is or should be, we can then check to see if we > > >> agree. > > > > > > To the extent possible, yes. I'm not convinced that anyone person knows what > > > all the existing invariants are in the stack as it is now. Do you feel that > > > a Stevens'-esque understanding of the environment around the calls is > > > necessary? I know it sounds like "other people beat their wives so I can > > > too", but even something as well documented as ifnet gives no indication of > > > what the locking conventions - e.g. you can't sleep or acquire sx locks in > > > if_ioctl. The demands placed should be no greater than those placed on > > > existing subsystems and should take into account the hitherto somewhat black > > > box nature of TCP. > > > > Actually, what I was asking for in the omitted context above was something > > along the lines of the following, adapted for whatever the reality may be: > > > > Returning a non-zero value will lead to the software stack beginning a > > disconnect. > > > > Or, say, > > > > Non-zero return values will be ignored. (*) > > > > This is not intended as a contrarian point. I'm not looking for a complete > > exposition of the behavior of the stack -- rather, basic information that we > > should be documenting about a KPI, such as what an error being returned will > > do. > > That is quite reasonable. I perceived your initial request as being > entirely too open-ended. We certainly know who provides support for Intel and Myricom cards (unless there has been a recent change of which I am unaware) and I happen to work across the hall from the guy who has been upgrading the Neterion drivers for them and I suspect provided the recent new versions to them. Am I missing anyone? If they are contacted and express disinterest or don't respond, I think Kip has to proceed as best he can. We use three of the vendors I know of with FreeBSD, so can push as a customer, too. We will be ordering more 10GE cards from someone soon and support for TOE could be a significant issue in selection. Until now it has not been mentioned since there was no prospect of near-term FreeBSD support, but that is clearly no longer the case. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1197758461_12041P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHZFf9kn3rs5h7N1ERAitpAJ9mP+hrmQPP71rmVJe+Hd4b22hkWgCgh7Lm zAZZ2t/fF9qf42P9u8mz3j0= =qjFn -----END PGP SIGNATURE----- --==_Exmh_1197758461_12041P-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 22:44:59 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6994716A419; Sat, 15 Dec 2007 22:44:59 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166]) by mx1.freebsd.org (Postfix) with ESMTP id 4A60F13C459; Sat, 15 Dec 2007 22:44:59 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBFMiwKN015922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Dec 2007 14:44:58 -0800 X-Auth-Received: from [128.208.7.246] (shiina.dyn.cs.washington.edu [128.208.7.246]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.09) with ESMTP id lBFMiwfs010517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 15 Dec 2007 14:44:58 -0800 In-Reply-To: References: <200711292024.lATKOq5R000769@freefall.freebsd.org> <20071129233842.GA57951@ace.netcins.ceid.upatras.gr> <200711292024.lATKOq5R000769@freefall.freebsd.org> <20071130013826.GA66484@kobe.laptop> <20071204175541.GC47398@dragon.NUXI.org> <20071204181317.GA62240@kobe.laptop> Mime-Version: 1.0 (Apple Message framework v752.2) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Garrett Cooper Date: Sat, 15 Dec 2007 14:44:58 -0800 To: Ivan Voras X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.3.3.310218, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.15.142235 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_600_699 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] gprof's broken in 7-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:44:59 -0000 On Dec 15, 2007, at 2:05 PM, Ivan Voras wrote: > >>>> On 2007-11-29 20:24, Luoqi Chen wrote: >>>>> Garrett, would you like to try out my fix? It's actually quite >>>>> simple, > > I'm wondering - has this been solved / committed to HEAD and RELENG_7? The MFC to RELENG_7 is in progress I believe.. There's been a good deal of discussion off-list, so I'll need to check eventually to make sure that the change is ok. I've just gotten side-tracked with a few other things in my life and haven't had an opportunity to sit down and properly review the change. HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Dec 15 22:47:13 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6613116A479; Sat, 15 Dec 2007 22:47:13 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E719813C4F0; Sat, 15 Dec 2007 22:47:12 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id lBFMl0Z7085175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Dec 2007 14:47:00 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <47645963.40301@errno.com> Date: Sat, 15 Dec 2007 14:46:59 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Kevin Oberman References: <20071215224101.6D1A045013@ptavv.es.net> In-Reply-To: <20071215224101.6D1A045013@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-dcc-servers-Metrics: om; whitelist Cc: FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: pending changes for TOE support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2007 22:47:13 -0000 Kevin Oberman wrote: >> Date: Sat, 15 Dec 2007 14:02:28 -0800 >> From: "Kip Macy" >> Sender: owner-freebsd-current@freebsd.org >> >> >>> I think we should make a best faith effort to figure out how to do the right >>> thing. Employing harsh interrogation tactics is probably not called for, but >>> we have several vendors who are regularly involved in the FreeBSD community >>> and may be willing to lend their insight as to their requirements, even if an >>> implementation isn't immediately forthcoming. >>> >> :-) - the two vendors that I know of have not been active in the >> community. Sam has initiated contact on my behalf with the one vendor >> that might be willing to talk to us. The other vendor has an >> established pattern of ignoring all requests. >> >> >>>>> tcp_output() was previously an internal function of the TCP code, and now >>>>> the semantics are being exposed to device drivers. Let's not perpetuate >>>>> poorly documented driver interfaces by adding another one. I think it >>>>> would be a reasonable expectation of a driver author to have consistent >>>>> documentation of the life cycle of data structures and objects, locking >>>>> expectations and requirements, and the semantics for error values from >>>>> functions. Certainly, they need to look at TCP a fair amount because >>>>> they'll be pulling things out of inpcb, tcpcb, etc, but I'd rather we limit >>>>> that requirement to simple things (addresses, socket options) that are >>>>> relatively static and avoid it being for complex things (locking, error >>>>> handling) that tend to be more subject to change. Also, if you document >>>>> what you think the behavior is or should be, we can then check to see if we >>>>> agree. >>>>> >>>> To the extent possible, yes. I'm not convinced that anyone person knows what >>>> all the existing invariants are in the stack as it is now. Do you feel that >>>> a Stevens'-esque understanding of the environment around the calls is >>>> necessary? I know it sounds like "other people beat their wives so I can >>>> too", but even something as well documented as ifnet gives no indication of >>>> what the locking conventions - e.g. you can't sleep or acquire sx locks in >>>> if_ioctl. The demands placed should be no greater than those placed on >>>> existing subsystems and should take into account the hitherto somewhat black >>>> box nature of TCP. >>>> >>> Actually, what I was asking for in the omitted context above was something >>> along the lines of the following, adapted for whatever the reality may be: >>> >>> Returning a non-zero value will lead to the software stack beginning a >>> disconnect. >>> >>> Or, say, >>> >>> Non-zero return values will be ignored. (*) >>> >>> This is not intended as a contrarian point. I'm not looking for a complete >>> exposition of the behavior of the stack -- rather, basic information that we >>> should be documenting about a KPI, such as what an error being returned will >>> do. >>> >> That is quite reasonable. I perceived your initial request as being >> entirely too open-ended. >> > > We certainly know who provides support for Intel and Myricom cards > (unless there has been a recent change of which I am unaware) and I > happen to work across the hall from the guy who has been upgrading the > Neterion drivers for them and I suspect provided the recent new versions > to them. > > Am I missing anyone? > > If they are contacted and express disinterest or don't respond, I think > Kip has to proceed as best he can. > > We use three of the vendors I know of with FreeBSD, so can push as a > customer, too. We will be ordering more 10GE cards from someone soon and > support for TOE could be a significant issue in selection. Until now it > has not been mentioned since there was no prospect of near-term FreeBSD > support, but that is clearly no longer the case. > So far as I know none of Intel, Myricom, and Neterion support TOE. Sam