From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 10:15:50 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50C8016A41A for ; Tue, 30 Oct 2007 10:15:50 +0000 (UTC) (envelope-from lukasz@salag.com) Received: from salag.com (sbssrv.salag.com [212.244.141.162]) by mx1.freebsd.org (Postfix) with ESMTP id C89E813C49D for ; Tue, 30 Oct 2007 10:15:49 +0000 (UTC) (envelope-from lukasz@salag.com) MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Oct 2007 10:52:22 +0100 Message-ID: <0862634D7E37134986CB15DF2E4542BA1C1EE5@sbssrv.SALAG.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ``Stopping RAM access'' Thread-Index: Acga2o773wdITdr3SiqebC10bTXLVg== From: =?iso-8859-2?Q?Jaroszewski_=A3ukasz?= To: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ``Stopping RAM access'' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2007 10:15:50 -0000 Hi, Can anyone give me a clue, how one can ``stop'' system from accessing = RAM, and then allow it again? What I want to manage is ``RAM test on demand''.=20 I just need a point where should I start, or rather in general terms how = can I freeze system for a while to make that test. I am very new into kernel programming, so sorry if it is lame question.=20 =20 =20 =20 Best Regards/Pozdrawiam LVJ =20 _______ _______ _______ ______ |______ |_____| | |_____| | ____ ______| | | |_____ | | |_____| =20 person: Lukasz Jaroszewski address: ul. Szafirowa 5, 16-400 Suwalki, POLAND phone: +48503008710 nic-hdl: LJ890-RIPE source: RIPE # Filtered=20 =20 =20 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 10:51:22 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F70616A47C for ; Tue, 30 Oct 2007 10:51:22 +0000 (UTC) (envelope-from lukasz@salag.com) Received: from salag.com (sbssrv.salag.com [212.244.141.162]) by mx1.freebsd.org (Postfix) with ESMTP id 8785613C4B8 for ; Tue, 30 Oct 2007 10:51:21 +0000 (UTC) (envelope-from lukasz@salag.com) MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 30 Oct 2007 11:48:26 +0100 Message-ID: <0862634D7E37134986CB15DF2E4542BA1C1EEF@sbssrv.SALAG.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ``Stopping RAM access'' Thread-Index: Acga2o773wdITdr3SiqebC10bTXLVgAB8nqw From: =?iso-8859-2?Q?Jaroszewski_=A3ukasz?= To: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ``Stopping RAM access'' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2007 10:51:22 -0000 Hi, Can anyone give me a clue, how one can ``stop'' system from accessing = RAM, and then allow it again? What I want to manage is ``RAM test on demand''.=20 I just need a point where should I start, or rather in general terms how = can I freeze system for a while to make that test. I am very new into kernel programming, so sorry if it is lame question.=20 =20 =20 =20 Best Regards/Pozdrawiam LVJ =20 _______ _______ _______ ______ |______ |_____| | |_____| | ____ ______| | | |_____ | | |_____| =20 person: Lukasz Jaroszewski address: ul. Szafirowa 5, 16-400 Suwalki, POLAND phone: +48503008710 nic-hdl: LJ890-RIPE source: RIPE # Filtered=20 =20 =20 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 16:22:55 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBE7116A4A9 for ; Tue, 30 Oct 2007 16:22:55 +0000 (UTC) (envelope-from xistence@0x58.com) Received: from mailexchange.osnn.net (1e.66.5646.static.theplanet.com [70.86.102.30]) by mx1.freebsd.org (Postfix) with SMTP id 9089F13C4BE for ; Tue, 30 Oct 2007 16:22:55 +0000 (UTC) (envelope-from xistence@0x58.com) Received: (qmail 67979 invoked by uid 0); 30 Oct 2007 15:52:28 -0000 Received: from unknown (HELO ?10.10.10.22?) (xistence@0x58.com@68.228.228.224) by mailexchange.osnn.net with SMTP; 30 Oct 2007 15:52:28 -0000 Mime-Version: 1.0 (Apple Message framework v752.3) To: hackers@freebsd.org Message-Id: <0A1CE06A-D2EC-4975-AE4B-EDDCBABE7F50@0x58.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-704209065; protocol="application/pkcs7-signature" From: Bert JW Regeer Date: Tue, 30 Oct 2007 08:56:13 -0700 X-Mailer: Apple Mail (2.752.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: MacBook Pro 2.4 Ghz Santa Rosa X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2007 16:22:55 -0000 --Apple-Mail-3-704209065 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hey, As I had recently purchased a new MacBook Pro, I have one of the brand new shiny ones with the Santa Rosa chipset. I have been trying to run FreeBSD 7.0-BETA1.5 and 8.0-SURPRISE on it, and everything goes well except the following issues: 1. Sometimes it will hang for ever on the ACPI initialisation. Sometimes it will come out of it and continue booting, and other times it will require a hard power down. Really hit and miss. I first downloaded 7.0-BETA1.0, or 8.0-SURPRISE, and recompiled a new kernel on it with the latest source from -HEAD and that caused it to die with a failure to start the second core in my machine. FreeBSD 6.2 will sometimes boot and sometimes not boot, same as 7.0 hanging on ACPI. For FreeBSD 6.2 I am able to fix it by hitting the power button a few times. 2. The Marvell Gigbit NIC is not yet supported. I can provide output from pciconf -lv if need be, let me know. Have not yet tried the if_myk driver from Marvell themselves. 3. The Atheros chipset 5424 card is not yet supported either. Output Mac OS X has in it's dmesg for this wireless card: ath_attach: devid 0x24 Override HT40 CTL Powers. EEPROM Version is 14.4, Device Type 5 ath_descdma_setup: tx dd_desc_paddr = 0x76475000, length 0x46500 (288000) bytes ath_descdma_setup: beacon dd_desc_paddr = 0x65b6e000, length 0x90 (144) bytes mac 12.10 phy 8.1 radio 12.0 AirPort_Athr5424ab: Ethernet address 00:1c:b3:c0:82:cb I am looking forward to the day that I may run FreeBSD with xfce on this laptop, side by side with Mac OS X. Bert JW Regeer --Apple-Mail-3-704209065-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 21:29:59 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64FF316A4D5 for ; Tue, 30 Oct 2007 21:29:59 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.235]) by mx1.freebsd.org (Postfix) with ESMTP id 216ED13C4A8 for ; Tue, 30 Oct 2007 21:29:58 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1412526nzf for ; Tue, 30 Oct 2007 14:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=tIZB4+AIiUyB83tRQ7nzA0NoIyCmToTixTqWCyLUe1Y=; b=Hzuh2rqQU91vV1bcXlc72jqYwrCb1BQsNjuUvvlk5fKtOBhm/JFFJjCHl5jIfxWtigEPGM+GXwxj6qpYdXsnNNnov/HY92VFLPBBTzYJPvqINtRKiev9dMxM7C7LzP1w9BHVXoAGTCvZVP852b5oSOEiTa0Y/l76uoM0K9outPk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h6hrQR7PkyEWDx8HMIL4L7FY7UfY/J2bCkobiDItpdBl/5oIvp3csraUPSwVBX8gJeONEkO3l/xWhVQWvX20BIwIIqHccfBAhBQVdKNWvbi7lSX+bHdrOGcyBLXjEArhkRk/7WoWD+OHjqkUmXZbpO2lcog4bKpH0tKZEen2zmg= Received: by 10.142.52.9 with SMTP id z9mr1900809wfz.1193778145476; Tue, 30 Oct 2007 14:02:25 -0700 (PDT) Received: by 10.143.33.14 with HTTP; Tue, 30 Oct 2007 14:02:25 -0700 (PDT) Message-ID: <319cceca0710301402j48355b54gc572f9c76a39d5a8@mail.gmail.com> Date: Tue, 30 Oct 2007 21:02:25 +0000 From: Maslan To: "=?ISO-8859-2?Q?Jaroszewski_=A3ukasz?=" In-Reply-To: <0862634D7E37134986CB15DF2E4542BA1C1EE5@sbssrv.SALAG.local> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0862634D7E37134986CB15DF2E4542BA1C1EE5@sbssrv.SALAG.local> Cc: freebsd-hackers@freebsd.org Subject: Re: ``Stopping RAM access'' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2007 21:29:59 -0000 > Can anyone give me a clue, how one can ``stop'' system from accessing RAM, and then allow it again? I think this has no aim, RAM tests should be done during booting, but u could try to disable interrupts while in kernel mode 'cli' which will prevent any further context switching, then try to do whatever you want, finally enable interrupts back 'sti'. That's my two cents. I don't whether it will work or not. -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 30 19:13:40 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 198EE16A473 for ; Tue, 30 Oct 2007 19:13:40 +0000 (UTC) (envelope-from ndenev@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 DB26313C4BD for ; Tue, 30 Oct 2007 19:13:39 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1736862rvb for ; Tue, 30 Oct 2007 12:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=lyv0iUpwYYhRsTjTQVkZDJWbZnAzN/oAvuqYpC8LLjg=; b=mKZOYgDi6ChMlXxGcrvlCEQxmKzawALgH72FdxtK4DGNF+JRyeBmFJW+46qU5QFkaObP9QWPB9cpbdZ01OcHIY3lM3cZUR+kHGdTsDLubm5GzQ/fw90Q3QMITilHp0JFPSmne71SpXqe7QNXmoEG34ZaUKH5jSWjNBJFgaFPAPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TK+SY7ZHumtd5B2f2S+SqFtQXKg/dRg+PQ0YNpaP035OooORltT03QRTQUlMky28o8qiMb8RpvfL+LE1JdLMEotgRTbYLbGmn4nr9QZi5m3Zdl+if/TqVrPKTOL88jlT4Wq1u6tGJS8t8lb+x2iV172qf7rZGDag7qHcl/+ky/E= Received: by 10.141.2.19 with SMTP id e19mr3523193rvi.1193769951989; Tue, 30 Oct 2007 11:45:51 -0700 (PDT) Received: by 10.141.170.18 with HTTP; Tue, 30 Oct 2007 11:45:51 -0700 (PDT) Message-ID: <2e77fc10710301145yf6441es948fd3a02e5dd35a@mail.gmail.com> Date: Tue, 30 Oct 2007 20:45:51 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: "Patrick Dung" In-Reply-To: <238725.26120.qm@web54304.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <238725.26120.qm@web54304.mail.re2.yahoo.com> X-Google-Sender-Auth: a63ffc96ebfa7b2a X-Mailman-Approved-At: Wed, 31 Oct 2007 03:58:26 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: kernel panic at shutdown with freebsd 7.0 current snapshot (oct-2007) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2007 19:13:40 -0000 On 10/24/07, Patrick Dung wrote: > Hi > > I have ZFS (and snapshot) mounted. > Then shutdown by `shutdown -p now`. > > There is the dump: > > # kgdb /boot/kernel/kernel.symbols vmcore.0 > [GDB will not be able to debug user-mode threads: > /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: vrele: negative ref cnt > cpuid = 0 > KDB: enter: panic > panic: from debugger > cpuid = 0 > Uptime: 8h44m12s > Physical memory: 507 MB > Dumping 120 MB: 105 89 73 57 41 25 9 > > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump () at pcpu.h:195 > #1 0xc074d98e in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc074dc4b in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc048cab7 in db_panic (addr=Could not find the frame base for > "db_panic". > ) at /usr/src/sys/ddb/db_command.c:433 > #4 0xc048d4a5 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:401 > #5 0xc048ec15 in db_trap (type=3, code=0) at > /usr/src/sys/ddb/db_main.c:222 > #6 0xc07748e6 in kdb_trap (type=3, code=0, tf=0xd53d7984) at > /usr/src/sys/kern/subr_kdb.c:502 > #7 0xc0a02dfb in trap (frame=0xd53d7984) at > /usr/src/sys/i386/i386/trap.c:621 > #8 0xc09e87eb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #9 0xc0774a62 in kdb_enter (msg=0xc0a996bc "panic") at cpufunc.h:60 > #10 0xc074dc34 in panic (fmt=0xc0aa528a "vrele: negative ref cnt") at > /usr/src/sys/kern/kern_shutdown.c:547 > #11 0xc07cb0a1 in vrele (vp=0xc2fccaa0) at > /usr/src/sys/kern/vfs_subr.c:2117 > #12 0xc0725905 in fdfree (td=0xc2f29a50) at > /usr/src/sys/kern/kern_descrip.c:1694 > #13 0xc072ea53 in exit1 (td=0xc2f29a50, rv=1) at > /usr/src/sys/kern/kern_exit.c:272 > #14 0xc07508bf in sigexit (td=Variable "td" is not available. > ) at /usr/src/sys/kern/kern_sig.c:2876 > #15 0xc0750c99 in postsig (sig=1) at /usr/src/sys/kern/kern_sig.c:2748 > #16 0xc077eb78 in ast (framep=0xd53d7d38) at > /usr/src/sys/kern/subr_trap.c:250 > #17 0xc09e910d in doreti_ast () at > /usr/src/sys/i386/i386/exception.s:290 > #18 0xd53d7d38 in ?? () > #19 0x0000003b in ?? () > #20 0x0000003b in ?? () > #21 0x0000003b in ?? () > #22 0x00000000 in ?? () > #23 0xffffffff in ?? () > #24 0xbfbfee58 in ?? () > #25 0xd53d7d64 in ?? () > #26 0x00000000 in ?? () > #27 0x0804fb20 in ?? () > #28 0x00000000 in ?? () > #29 0x00000004 in ?? () > #30 0x0000000c in ?? () > #31 0x00000002 in ?? () > #32 0x28167553 in ?? () > #33 0x00000033 in ?? () > #34 0x00000247 in ?? () > #35 0xbfbfee1c in ?? () > #36 0x0000003b in ?? () > #37 0x00000000 in ?? () > #38 0x00000000 in ?? () > #39 0x00000000 in ?? () > #40 0x00000000 in ?? () > #41 0x0116c000 in ?? () > #42 0xc2f5bd48 in ?? () > ---Type to continue, or q to quit--- > #43 0xc31e1000 in ?? () > #44 0xd53d7878 in ?? () > #45 0xd53d7854 in ?? () > #46 0xc2f29a50 in ?? () > #47 0xc076a756 in sched_switch (td=0x0, newtd=0xffffffff, flags=Cannot > access memory at address 0xbfbfee68 > ) at /usr/src/sys/kern/sched_4bsd.c:907 > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > Regards > Patrick > I got exactly the same panic today. --niki From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 01:45:26 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6EB016A418 for ; Wed, 31 Oct 2007 01:45:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id A693F13C447 for ; Wed, 31 Oct 2007 01:45:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1804425rvb for ; Tue, 30 Oct 2007 18:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=S7Rjyi7umA5klQnPf/fjTL9f1S04CltQALDbXVu6iPA=; b=mqprmmYZzNNcpjNTc8xLMytYhWASgHfJnh3k8TCLY6mOmfXEMZkdmKITL20Qpjmng5tHu/O2hr7VHy1ThMieIlnOmBNUSXVBYhZETBIClVh03ioVwdJQfXw+TbMFJP+ljhZaPAe95oj5EkKGAfExGCzjZ3BK7Gz5Q81Kuom/VV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=GQY6gpBFSC4eZoFtbEo1cqjGtZIMNzl3ltmxwCZdA+1wtm7SYja4vwlxQvdteTSZ5VuRa/wiWFCWYXpNGCjfakLBm0JqiGD8l1nJkNwN08pJD/rOhePmBfNr/TeaRazK2ewjp8QWcdog/azXv75kcNNniu19YjLMEG5vfeKeRIY= Received: by 10.115.60.1 with SMTP id n1mr2339688wak.1193793417075; Tue, 30 Oct 2007 18:16:57 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id j6sm16639452wah.2007.10.30.18.16.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2007 18:16:55 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l9V1GnWK042659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2007 10:16:49 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l9V1GmPh042658; Wed, 31 Oct 2007 10:16:48 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 31 Oct 2007 10:16:48 +0900 From: Pyun YongHyeon To: Bert JW Regeer Message-ID: <20071031011648.GB42371@cdnetworks.co.kr> References: <0A1CE06A-D2EC-4975-AE4B-EDDCBABE7F50@0x58.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0A1CE06A-D2EC-4975-AE4B-EDDCBABE7F50@0x58.com> User-Agent: Mutt/1.4.2.1i Cc: hackers@freebsd.org Subject: Re: MacBook Pro 2.4 Ghz Santa Rosa X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 01:45:26 -0000 On Tue, Oct 30, 2007 at 08:56:13AM -0700, Bert JW Regeer wrote: [...] > > 2. The Marvell Gigbit NIC is not yet supported. I can provide output > from pciconf -lv if need be, let me know. Have not yet tried the > if_myk driver from Marvell themselves. > I'm interested in adding support for the NIC. Would you show me the "pciconf -lcv" output? -- Regards, Pyun YongHyeon From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 08:18:39 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FAB616A418 for ; Wed, 31 Oct 2007 08:18:39 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (pool-71-182-89-93.ptldor.fios.verizon.net [71.182.89.93]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7C913C4B3 for ; Wed, 31 Oct 2007 08:18:38 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (localhost.home.localnet [127.0.0.1]) by schitzo.solgatos.com (8.14.1/8.13.8) with ESMTP id l9V31Eaj001763 for ; Tue, 30 Oct 2007 20:01:14 -0700 Received: from sopwith.solgatos.com (uucp@localhost) by schitzo.solgatos.com (8.14.1/8.13.4/Submit) with UUCP id l9V31EVQ001760 for freebsd-hackers@FreeBSD.org; Tue, 30 Oct 2007 20:01:14 -0700 Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id CAA19011; Wed, 31 Oct 2007 02:54:00 GMT Message-Id: <200710310254.CAA19011@sopwith.solgatos.com> To: freebsd-hackers@FreeBSD.org Date: Tue, 30 Oct 2007 19:54:00 +0100 From: Dieter X-Mailman-Approved-At: Wed, 31 Oct 2007 11:54:21 +0000 Cc: Subject: Re: boot loader X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@sopwith.solgatos.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 08:18:39 -0000 > You also can't dual boot without console access. You can, I have a system triple booting without using the console. Method 1: boot through grub. Create shell scripts that edit grub's menu.lst file. Method 2: use fdisk(8) to change active partition. With or without dual booting, if the least little thing goes wrong you will need the console, and maybe the reset button, and maybe the hard power switch to recover. Even rebooting without changing anything can be dangerous since fsck might decide to be unhappy. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 13:52:49 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3098116A418; Wed, 31 Oct 2007 13:52:49 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id EE26413C4B2; Wed, 31 Oct 2007 13:52:47 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 197371779; Wed, 31 Oct 2007 14:56:05 +0300 Message-ID: <47286CF2.4090804@chistydom.ru> Date: Wed, 31 Oct 2007 14:54:26 +0300 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> <4723BF87.20302@FreeBSD.org> In-Reply-To: <4723BF87.20302@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 31 Oct 2007 14:46:07 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 13:52:49 -0000 Hi Kris Kennaway wrote: >>>>>> So I can conclude that FreeBSD has a long standing bug in VM that >>>>>> could be triggered when serving large amount of static data (much >>>>>> bigger than memory size) on high rates. Possibly this only applies >>>>>> to large files like mp3 or video. >>>>> It is possible, we have further work to do to conclude this though. >>>> I forgot to mention I have pmc and kgmon profiling for good and bad >>>> times. But I have not enough knowledge to interpret it right and not >>>> sure if it can help. >>> pmc would be useful. >> pmc profiling attached. > OK, the pmc traces do seem to show that it's not a lock contention > issue. That being the case I don't think the fact that different > servers perform better is directly related. But it was evidence of mbuf lock contention in mutex profiling, wasn't it? As far as I understand, mutex problems can exist without increasing CPU load in pmc stats, right? > There is also no evidence of a VM problem. What your vmstat and pmc > traces show is that your system really isn't doing much work at all, > relatively speaking. > There is also still no evidence of a disk problem. In fact your disk > seems to be almost idle in both cases you provided, only doing between 1 > and 10 operations per second, which is trivial. vmstat and network output graphs shows that the problem exists. If it is not a disk or network or VM problem, what else could be wrong? > In the "good" case you are getting a much higher interrupt rate but with > the data you provided I can't tell where from. You need to run vmstat > -i at regular intervals (e.g. every 10 seconds for a minute) during the > "good" and "bad" times, since it only provides counters and an average > rate over the uptime of the system. I'll try this, but AFAIR there was no strangeness with interrupts. I believe the reason of high interrupt rate in "good" cases is that server sends much traffic. > What there is evidence of is an interrupt aliasing problem between em > and USB: > irq16: uhci0 1464547796 1870 > irq64: em0 1463513610 1869 I tried disabling USB in kernel, this ussie was gone, but the main problem was left. Also I have this issue with interrupt aliasing on many servers without problems. With best regards, Alexey Popov From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 16:53:20 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 147AF16A421 for ; Wed, 31 Oct 2007 16:53:20 +0000 (UTC) (envelope-from deathjestr@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 B6EA613C4B7 for ; Wed, 31 Oct 2007 16:53:19 +0000 (UTC) (envelope-from deathjestr@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so414729pyb for ; Wed, 31 Oct 2007 09:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; 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=7Y4iQHdWpjll8nmTyxoaXbPKxU2weB7VvIUAMMr2A0M=; b=AXE0cUJTzxrUUuLgX7UkLwVTZTDS+dU2joGvtwZ0C/wq1K1o6lVcWU/obRbuBlt40trnQ9NUEPV9yarirLwRm7Brp8x6os4pfzFS7vGx1r2N84/7AYqhcRXONwasG8+tybr2MUUiW5X6yRYSBP7WHQiZIk+K5b6H2OiOojWmE9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aIVgzkhuEAxZKtBd5+NSvt410/IY6yzMmOjjmfJ/dNyYjfIIaEYRMwiBmK/z8m2NkFQO22uGLs/2blnFjY44TuTtiZZ6CTKiG4urDU/daqAsoBxVUtDMEa9P/NKYMjajx4ql27fZHQiqAK1uP72OR//t6NsBjt2DzKfsdlNMVwQ= Received: by 10.35.115.18 with SMTP id s18mr10336327pym.1193847991424; Wed, 31 Oct 2007 09:26:31 -0700 (PDT) Received: by 10.35.12.15 with HTTP; Wed, 31 Oct 2007 09:26:31 -0700 (PDT) Message-ID: <44b564930710310926m54f74566s104d12808ed5c9cb@mail.gmail.com> Date: Wed, 31 Oct 2007 12:26:31 -0400 From: "Michael M. Press" To: "=?ISO-8859-2?Q?Jaroszewski_=A3ukasz?=" , Maslan In-Reply-To: <319cceca0710301402j48355b54gc572f9c76a39d5a8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0862634D7E37134986CB15DF2E4542BA1C1EE5@sbssrv.SALAG.local> <319cceca0710301402j48355b54gc572f9c76a39d5a8@mail.gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: ``Stopping RAM access'' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 16:53:20 -0000 >> Can anyone give me a clue, how one can ``stop'' system from accessing RAM, and then allow it again? > > I think this has no aim, RAM tests should be done during booting, but > u could try to disable interrupts while in kernel mode 'cli' which > will prevent any further context switching, then try to do whatever > you want, finally enable interrupts back 'sti'. > > That's my two cents. I don't whether it will work or not. > Also, keep in mind that 'cli/sti' is just a starting point. You can't just go playing with memory anywhere you want because interrupts are disabled. What if a DMA transfer is in progress? Mike From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 17:12:48 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37DC016A420 for ; Wed, 31 Oct 2007 17:12:48 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by mx1.freebsd.org (Postfix) with ESMTP id DD5AE13C48E for ; Wed, 31 Oct 2007 17:12:47 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from source ([66.129.224.36]) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP; Wed, 31 Oct 2007 10:12:29 PDT Received: from pi-smtp.jnpr.net ([10.10.2.36]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Oct 2007 06:07:23 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 31 Oct 2007 09:07:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Oct 2007 09:00:38 -0400 Message-ID: <0FCFCF6165E968449991746EB91D614DB13F64@antipi.jnpr.net> In-Reply-To: <319cceca0710301402j48355b54gc572f9c76a39d5a8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ``Stopping RAM access'' Thread-Index: Acgbc0OdkdXvOKs8QLOMiCSW8Wl/rAASlFog References: <0862634D7E37134986CB15DF2E4542BA1C1EE5@sbssrv.SALAG.local> <319cceca0710301402j48355b54gc572f9c76a39d5a8@mail.gmail.com> From: "Andrew Duane" To: X-OriginalArrivalTime: 31 Oct 2007 13:07:04.0959 (UTC) FILETIME=[EF1F20F0:01C81BBE] Subject: RE: ``Stopping RAM access'' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 17:12:48 -0000 Well, if the system stops accessing RAM, you had better make sure that = *all* the instructions you need are already loaded into the L1 and L2 = caches. Otherwise you won't be able to turn RAM back on. That would = involve carefully preloading everything through use of the system's = appropriate PREFETCH calls, locking down the cache lines to make sure = nothing else disturbs them, turning off interrupts, and probably more. To actually turn off RAM, you'd have to power down or otherwise disable = the memory controller interface on your board. The procedures for that = would be highly platform dependent. /Andrew =20 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Maslan > Sent: Tuesday, October 30, 2007 5:02 PM > To: Jaroszewski =A3ukasz > Cc: freebsd-hackers@freebsd.org > Subject: Re: ``Stopping RAM access'' >=20 > > Can anyone give me a clue, how one can ``stop'' system from = accessing > > RAM, and then allow it again? From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 31 21:38:22 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2956216A419; Wed, 31 Oct 2007 21:38:22 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 245E913C49D; Wed, 31 Oct 2007 21:38:20 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4728F5D0.5020906@FreeBSD.org> Date: Wed, 31 Oct 2007 22:38:24 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <471EE4D9.5080307@chistydom.ru> <4723BF87.20302@FreeBSD.org> <47286CF2.4090804@chistydom.ru> In-Reply-To: <47286CF2.4090804@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 21:38:22 -0000 Alexey Popov wrote: > Hi > > Kris Kennaway wrote: >>>>>>> So I can conclude that FreeBSD has a long standing bug in VM that >>>>>>> could be triggered when serving large amount of static data (much >>>>>>> bigger than memory size) on high rates. Possibly this only >>>>>>> applies to large files like mp3 or video. >>>>>> It is possible, we have further work to do to conclude this though. >>>>> I forgot to mention I have pmc and kgmon profiling for good and bad >>>>> times. But I have not enough knowledge to interpret it right and >>>>> not sure if it can help. >>>> pmc would be useful. >>> pmc profiling attached. >> OK, the pmc traces do seem to show that it's not a lock contention >> issue. That being the case I don't think the fact that different >> servers perform better is directly related. > But it was evidence of mbuf lock contention in mutex profiling, wasn't > it? As far as I understand, mutex problems can exist without increasing > CPU load in pmc stats, right? No, the lock functions will show up as using a lot of CPU. I guess the lock profiling trace showed high numbers because you ran it for a long time. >> There is also no evidence of a VM problem. What your vmstat and pmc >> traces show is that your system really isn't doing much work at all, >> relatively speaking. >> There is also still no evidence of a disk problem. In fact your disk >> seems to be almost idle in both cases you provided, only doing between >> 1 and 10 operations per second, which is trivial. > vmstat and network output graphs shows that the problem exists. If it is > not a disk or network or VM problem, what else could be wrong? The vmstat output you provided so far doesn't show anything specific. >> In the "good" case you are getting a much higher interrupt rate but >> with the data you provided I can't tell where from. You need to run >> vmstat -i at regular intervals (e.g. every 10 seconds for a minute) >> during the "good" and "bad" times, since it only provides counters and >> an average rate over the uptime of the system. > I'll try this, but AFAIR there was no strangeness with interrupts. > > I believe the reason of high interrupt rate in "good" cases is that > server sends much traffic. > >> What there is evidence of is an interrupt aliasing problem between em >> and USB: >> irq16: uhci0 1464547796 1870 >> irq64: em0 1463513610 1869 > I tried disabling USB in kernel, this ussie was gone, but the main > problem was left. Also I have this issue with interrupt aliasing on many > servers without problems. OK. Kris From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 00:31:42 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C237816A468 for ; Thu, 1 Nov 2007 00:31:42 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from mailmonitor.cc.swin.edu.au (mailmonitor.cc.swin.edu.au [136.186.1.65]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA6B13C481 for ; Thu, 1 Nov 2007 00:31:42 +0000 (UTC) (envelope-from jhealy@swin.edu.au) Received: from groupwise.swin.edu.au (Not Verified[136.186.3.197]) by mailmonitor.cc.swin.edu.au with MailMarshal (v6, 1, 4, 441) id ; Thu, 01 Nov 2007 10:40:12 +1100 Received: from [136.186.229.102] (jhealy.caia.swin.edu.au [136.186.229.102]) by groupwise.swin.edu.au with ESMTP; Thu, 01 Nov 2007 10:40:08 +1100 Message-ID: <47291254.9030909@swin.edu.au> Date: Thu, 01 Nov 2007 10:40:04 +1100 From: James Healy User-Agent: Thunderbird 2.0.0.0 (X11/20070423) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart Subject: floating point operations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 00:31:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hackers, We've been making experimental changes to FreeBSD's TCP congestion control code, and we used a few floating point operations initially in our prototype. We've since gone back and converted all but one of the operations to fixed point maths in following the no-flops-in-kernel mantra. The remaining op is not easily converted to fixed point math, and we're wondering what impact a single flop on the receipt of each ACK will have. We don't have a strong understanding of the amount of overhead involved in executing a flop instead of an int op on modern hardware. regards James Healy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKRJU4oawkrbYo/kRAnhtAJwJOzBh9LhT3cQkRp6hYze2w44pcgCfSbLj irZWz4qHd6lw0zjVaH/6d3s= =3eLF -----END PGP SIGNATURE----- Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Please consider the environment before printing this email. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 01:01:09 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB43216A41A for ; Thu, 1 Nov 2007 01:01:09 +0000 (UTC) (envelope-from nec556@retena.com) Received: from resmaa07.ono.com (mta.auna.com [62.42.230.187]) by mx1.freebsd.org (Postfix) with ESMTP id 9B66313C48A for ; Thu, 1 Nov 2007 01:01:08 +0000 (UTC) (envelope-from nec556@retena.com) Received: from argente-2005.retena.com (83.173.188.82) by resmaa07.ono.com (7.3.118.8) (authenticated as nec556@retena.com) id 4727D3B2000A88A6 for freebsd-hackers@freebsd.org; Thu, 1 Nov 2007 01:05:57 +0100 Message-ID: <4727D3B2000A88A6@> (added by postmaster@resmaa07.ono.com) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Nov 2007 01:05:54 +0100 To: freebsd-hackers@freebsd.org From: Eduardo Morras Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: memory pool, rfc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 01:01:09 -0000 Hello: I have some free time and want to do an memory pool. The idea is to have a memory zone of N KB (or several MB) compressed in memory. I have fast compression algorithms now that can release under BSD licence that are faster than hd i/o, so it take less compress/decompress a memory zone than read/write it to disk. I don't know if it already exist for FreeBSD, so if it's already done i'll try to improve it. - Each memory chunk is compressed separately, so i can decompress and use one without decompress anyother one. - In 4KB chunks of text i get 50-60 % compression (avg 2 - 1.6 KB result) - In 4KB chunks of binary (application code) i get 30-40 % compression (avg 2.8 - 2.4 KB result) - In both cases, results may vary depending on data type and chunk size, greater implies better compression - Speed once implemented will be very fast. Current speed hogs a PATA 133 disk. For what can be used? - Memory pools in applications (like malloc) - Ram disks - Disk Cache (permit bigger disk cache) - 'On the fly' filesystem compression (and it takes less read/write compressed data than non-compressed) - Perhaps add it as Virtual Memory swap cache? - Other Don't point me to zlib or libbzip2, they are on another league and are much slower than my code. Thanks From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 02:23:25 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F14116A420 for ; Thu, 1 Nov 2007 02:23:25 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 28CF713C494 for ; Thu, 1 Nov 2007 02:23:25 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.14.1) id lA121E48029901; Wed, 31 Oct 2007 21:01:14 -0500 (CDT) (envelope-from dan) Date: Wed, 31 Oct 2007 21:01:14 -0500 From: Dan Nelson To: Eduardo Morras Message-ID: <20071101020113.GF3109@dan.emsphone.com> References: <4727D3B2000A88A6@> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4727D3B2000A88A6@> X-OS: FreeBSD 7.0-BETA1 User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org Subject: Re: memory pool, rfc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 02:23:25 -0000 In the last episode (Nov 01), Eduardo Morras said: > I have some free time and want to do an memory pool. The idea is to > have a memory zone of N KB (or several MB) compressed in memory. I > have fast compression algorithms now that can release under BSD > licence that are faster than hd i/o, so it take less > compress/decompress a memory zone than read/write it to disk. I don't > know if it already exist for FreeBSD, so if it's already done i'll > try to improve it. [...] > For what can be used? > > - Memory pools in applications (like malloc) > - Ram disks > - Disk Cache (permit bigger disk cache) > - 'On the fly' filesystem compression (and it takes less read/write > compressed data than non-compressed) zfs already has modular compression algorithms; it would be rather easy to add a mozule for your method and compare it to the existing gzip and lzjb algorithms. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 09:28:38 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63EBD16A417 for ; Thu, 1 Nov 2007 09:28:38 +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 29D6D13C480 for ; Thu, 1 Nov 2007 09:28:38 +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 A6FA32095; Thu, 1 Nov 2007 10:18:38 +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 27BF62092; Thu, 1 Nov 2007 10:18:38 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 06D0484479; Thu, 1 Nov 2007 10:18:38 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: James Healy References: <47291254.9030909@swin.edu.au> Date: Thu, 01 Nov 2007 10:18:37 +0100 In-Reply-To: <47291254.9030909@swin.edu.au> (James Healy's message of "Thu\, 01 Nov 2007 10\:40\:04 +1100") Message-ID: <86odeewcgi.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-hackers@freebsd.org, Lawrence Stewart Subject: Re: floating point operations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 09:28:38 -0000 James Healy writes: > The remaining op is not easily converted to fixed point math, and we're > wondering what impact a single flop on the receipt of each ACK will > have. We don't have a strong understanding of the amount of overhead > involved in executing a flop instead of an int op on modern hardware. Search the archives before posting. This precise topic was discussed here earlier this week. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 10:13:37 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1A1516A41B for ; Thu, 1 Nov 2007 10:13:37 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from www.pkgsrc-box.org (www.ostsee-abc.de [62.206.222.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6836D13C4B2 for ; Thu, 1 Nov 2007 10:13:37 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from britannica.bec.de (www.pkgsrc-box.org [127.0.0.1]) by www.pkgsrc-box.org (Postfix) with ESMTP id C12EBE7A3EC for ; Thu, 1 Nov 2007 01:05:01 +0000 (UTC) Received: by britannica.bec.de (Postfix, from userid 1000) id 9C0AF175AE; Thu, 1 Nov 2007 01:57:24 +0100 (CET) Date: Thu, 1 Nov 2007 01:57:24 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20071101005724.GA3538@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <4727D3B2000A88A6@> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4727D3B2000A88A6@> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: memory pool, rfc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 10:13:37 -0000 On Thu, Nov 01, 2007 at 01:05:54AM +0100, Eduardo Morras wrote: > Don't point me to zlib or libbzip2, they are on another league and are much > slower than my code. Have you looked at liblzo? Joerg From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 11:45:42 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AC8B16A468 for ; Thu, 1 Nov 2007 11:45:42 +0000 (UTC) (envelope-from nec556@retena.com) Received: from resmaa08.ono.com (mta.auna.com [62.42.230.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4CD8413C491 for ; Thu, 1 Nov 2007 11:45:41 +0000 (UTC) (envelope-from nec556@retena.com) Received: from argente-2005.retena.com (83.173.188.82) by resmaa08.ono.com (7.3.118.8) (authenticated as nec556@retena.com) id 4727D40B000DF505 for freebsd-hackers@freebsd.org; Thu, 1 Nov 2007 12:45:05 +0100 Message-ID: <4727D40B000DF505@> (added by postmaster@resmaa08.ono.com) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 Nov 2007 12:45:02 +0100 To: freebsd-hackers@freebsd.org From: Eduardo Morras Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: memory pool, rfc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 11:45:42 -0000 At 01:57 01/11/2007, you wrote: >On Thu, Nov 01, 2007 at 01:05:54AM +0100, Eduardo Morras wrote: > > Don't point me to zlib or libbzip2, they are on another league > and are much > > slower than my code. > >Have you looked at liblzo? Yes, i know lzo, i'm working with compression since '99. My code has similar compression efficience but is low size block oriented and faster on compression/decompression. Giorgios Keramidas suggested on freebsd-question to prepare a paper and code about it >Joerg From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 17:44:06 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A32516A41B for ; Thu, 1 Nov 2007 17:44:06 +0000 (UTC) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web32708.mail.mud.yahoo.com (web32708.mail.mud.yahoo.com [68.142.207.252]) by mx1.freebsd.org (Postfix) with SMTP id 45D6C13C447 for ; Thu, 1 Nov 2007 17:44:06 +0000 (UTC) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 27217 invoked by uid 60001); 1 Nov 2007 15:57:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=oEPukab2U7ygfUq61qFfZ89koqP5Exxozm6q0Z9+9XNvcozQ3iquHYYoOPs/hchkj+DC5QTJFnEJIfha9hLcfjdWfVbJPSk6mVNPe1XY7BHVOG9yfNc3Tcnj5EgaOly9SDUpne0aSk+PUshRIpWQgBLpq8ntGcr5/z4pOGeMeko=; X-YMail-OSG: 88MX_FIVM1kIA7qWzDOjYzVme8ejE29nvWH75X81cf6zMsGtOxh1o5XVvJkCUc1K45WoBUkkSTntUrL18gTRdwxsnI5PRgJyK4vW42T_fonuaz3eB.Y- Received: from [200.118.171.108] by web32708.mail.mud.yahoo.com via HTTP; Thu, 01 Nov 2007 10:57:00 CDT Date: Thu, 1 Nov 2007 10:57:00 -0500 (CDT) From: To: Eduardo Morras MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <309673.27170.qm@web32708.mail.mud.yahoo.com> X-Mailman-Approved-At: Thu, 01 Nov 2007 17:53:14 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: memory pool, rfc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 17:44:06 -0000 Hello; You might want to compare your code with archivers/lzo, which is meant to be faster that the other archivers but is GPLd. Just to mention .. NetBSD has a pool(9) that you might want to check out. I think it was used in the original tmpfs: http://www.freebsd.org/cgi/man.cgi?query=pool&apropos=0&sektion=0&manpath=NetBSD+3.0&format=html Also ... if you're way too enterprising you might want to look at Heidemann's Ph. D. thesis http://www.isi.edu/~johnh/PAPERS/Heidemann95a.html A compression fs layer has always been a greatly desired feature (I think). cheers, Pedro. Comparte video en la ventana de tus mensajes (y también tus fotos de Flickr). Usa el nuevo Yahoo! Messenger versión Beta. http://e1.beta.messenger.yahoo.com/ From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 18:35:29 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D888B16A46B for ; Thu, 1 Nov 2007 18:35:29 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id BF58613C494 for ; Thu, 1 Nov 2007 18:35:28 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.1/8.14.1) with ESMTP id lA1FrdRY006610; Thu, 1 Nov 2007 08:53:39 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.1/8.14.1/Submit) id lA1FrdFV006609; Thu, 1 Nov 2007 08:53:39 -0700 (PDT) (envelope-from obrien) Date: Thu, 1 Nov 2007 08:53:39 -0700 From: "David O'Brien" To: Yar Tikhiy Message-ID: <20071101155339.GA6490@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Yar Tikhiy , freebsd-hackers@freebsd.org References: <20070901073440.GL85633@comp.chem.msu.su> <46DAFE5C.6070806@freebsd.org> <20070903120353.GH30502@comp.chem.msu.su> <200709261028.43378.jhb@freebsd.org> <20071004022344.GA60878@dragon.NUXI.org> <20071013060138.GA14388@comp.chem.msu.su> <20071015173826.GA88628@dragon.NUXI.org> <20071017220421.GD25575@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071017220421.GD25575@comp.chem.msu.su> X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@FreeBSD.org Subject: Re: Useful tools missing from /rescue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 18:35:29 -0000 On Thu, Oct 18, 2007 at 02:04:21AM +0400, Yar Tikhiy wrote: > On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote: > > I guess I'm not creative enough in the ways I've screwed up my systems > > and needed tools from /rescue. 8-) > > Just try to installworld FreeBSD/amd64 over a running FreeBSD/i386. ;-) I strongly feel that shouldn't be supported on a live system. So to me it shouldn't be an excuse to put a duplicated copy of /usr/[s]bin into /rescue. It is a delicate thing to get right - and there are easy ways to do it today: Boot from disc1; mount / and /usr; mv /mnt/etc /mnt/etc.hold; rm -rf the bits in bin,sbin,libexec; then run the install.sh from the disc1; mv /mnt/etc /mnt/etc.new ; mv /mnt/etc.hold /mnt/etc -- -- David (obrien@FreeBSD.org) From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 18:36:59 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD7C916A418 for ; Thu, 1 Nov 2007 18:36:59 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3E113C4A7 for ; Thu, 1 Nov 2007 18:36:59 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so461108nfb for ; Thu, 01 Nov 2007 11:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=eUy5c187q5XiBcBQGOYG8Oea3305EXoPPgowQQkBtmU=; b=KI+Lvu7zYM+B1Z35wCcyRGk850kEQlGLN+UYL0mAFNWvMP7QL50RmPkAlZASAoeS31xLqQVWrstC0nhljzVcX8N3YyeqXzlEMESUNCXPNJ2CP3j6hRLOiV/9i+DZUsngyI99TF3rX0ZYHNMWz7cIleI8hfK/hOqZhQC7zavUM7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ddNM6R5T5ZK/KuEHaZK324NNxCWxSb5EbAHSob8g7SuyP+Dcc21uowXG+kScsVztP2RIyBqfteJ3rRvobjBqXRFvrcjyeO35/fqk8jHNeYMdL+Dh84V8T7oqogpSsKlk5LI804VPei6YuMpzVnuAmhBOMzQC63gNUuZpYpcnYAs= Received: by 10.142.114.15 with SMTP id m15mr255706wfc.1193938870326; Thu, 01 Nov 2007 10:41:10 -0700 (PDT) Received: by 10.142.164.5 with HTTP; Thu, 1 Nov 2007 10:41:10 -0700 (PDT) Message-ID: <78c6bd860711011041o6d10753an663f19389737f84b@mail.gmail.com> Date: Thu, 1 Nov 2007 13:41:10 -0400 From: "Michael B Allen" To: freebsd-hackers MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: timers and semtimedop(2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 18:36:59 -0000 Hi, I need semtimedop(2). I'm thinking I can just do a semop with a SIGINT maybe. Can someone suggest a good method for setting up a timer to deliver the signal? What sort of timers does FreeBSD offer? Thanks, Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 20:43:35 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0A9F16A41A for ; Thu, 1 Nov 2007 20:43:35 +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 7C75213C481 for ; Thu, 1 Nov 2007 20:43:35 +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 9804A209D; Thu, 1 Nov 2007 21:36:34 +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 7E2ED209B; Thu, 1 Nov 2007 21:36:34 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 66CA584479; Thu, 1 Nov 2007 21:36:34 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Michael B Allen" References: <78c6bd860711011041o6d10753an663f19389737f84b@mail.gmail.com> Date: Thu, 01 Nov 2007 21:36:34 +0100 In-Reply-To: <78c6bd860711011041o6d10753an663f19389737f84b@mail.gmail.com> (Michael B. Allen's message of "Thu\, 1 Nov 2007 13\:41\:10 -0400") Message-ID: <86ejf9u2i5.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-hackers Subject: Re: timers and semtimedop(2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 20:43:35 -0000 "Michael B Allen" writes: > I need semtimedop(2). I'm thinking I can just do a semop with a SIGINT > maybe. > > Can someone suggest a good method for setting up a timer to deliver > the signal? What sort of timers does FreeBSD offer? man alarm DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 20:43:42 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 993C316A4BF for ; Thu, 1 Nov 2007 20:43:42 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id 55E0713C4B3 for ; Thu, 1 Nov 2007 20:43:42 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.1/8.14.1) with ESMTP id lA1K8B8p060970; Thu, 1 Nov 2007 16:08:11 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.1/8.14.1/Submit) id lA1K8AjQ060969; Thu, 1 Nov 2007 16:08:10 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 1 Nov 2007 16:08:10 -0400 From: David Schultz To: "Dag-Erling =?us-ascii:iso-8859-1?B?U23DuHJncmF2?=" Message-ID: <20071101200810.GA60893@VARK.MIT.EDU> Mail-Followup-To: "Dag-Erling =?us-ascii:iso-8859-1?B?U23DuHJncmF2?=" , James Healy , freebsd-hackers@FreeBSD.ORG, Lawrence Stewart References: <47291254.9030909@swin.edu.au> <86odeewcgi.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii:iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86odeewcgi.fsf@ds4.des.no> Cc: James Healy , freebsd-hackers@FreeBSD.ORG, Lawrence Stewart Subject: Re: floating point operations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 20:43:42 -0000 On Thu, Nov 01, 2007, Dag-Erling Smørgrav wrote: > James Healy writes: > > The remaining op is not easily converted to fixed point math, and we're > > wondering what impact a single flop on the receipt of each ACK will > > have. We don't have a strong understanding of the amount of overhead > > involved in executing a flop instead of an int op on modern hardware. > > Search the archives before posting. This precise topic was discussed > here earlier this week. The earlier thread was about a special-purpose variant of FreeBSD where user applications didn't use floating point, so don't assume that just because they got it to work it's a good idea in general. Floating point is often faster if it would take a lot more work to express the equivalent computation in terms of integers. On many processors, multiplying by 0.01 is faster than dividing by 100. HOWEVER, in the kernel all of this is likely to be dwarfed by the overhead of saving and restoring the FPU state. See the earlier thread for details. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 21:09:34 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0037616A41A for ; Thu, 1 Nov 2007 21:09:33 +0000 (UTC) (envelope-from rlh@online247.force9.co.uk) Received: from duron.hesketh.homeip.net (online247.force9.co.uk [84.92.137.126]) by mx1.freebsd.org (Postfix) with ESMTP id 995FA13C481 for ; Thu, 1 Nov 2007 21:09:32 +0000 (UTC) (envelope-from rlh@online247.force9.co.uk) Received: from [127.0.0.1] (localhost.hesketh.homeip.net [127.0.0.1]) by duron.hesketh.homeip.net (Postfix) with ESMTP id 7085010E4C9 for ; Thu, 1 Nov 2007 20:34:48 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <4340500C-AA75-46B8-B1F8-434DD4F1882C@online247.force9.co.uk> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-hackers@freebsd.org From: Richard Hesketh Date: Thu, 1 Nov 2007 20:34:42 +0000 X-Mailer: Apple Mail (2.752.3) Subject: Re: Attansic L1 Gigabit LAN Controller X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 21:09:34 -0000 Hi, I'm looking for a FreeBSD driver for the Attansic L1 Gigabit LAN Controller (used by ASUS and to my eternal shame I did not check the FreeBSD compatible hardware list before buying the P5L-VM 1394 motherboard .. silly really as I've been using FreeBSD as my server OS since 8-). According to the archives, Alex Lukin has been working on porting one and I'd love to get hold of the latest version and help out with development. So if Alex is around could you contact me and let me have the patch(es)? Thanks very much. Cheers, Richard From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 21:15:52 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3500616A417 for ; Thu, 1 Nov 2007 21:15:52 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 951F313C48A for ; Thu, 1 Nov 2007 21:15:51 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id lA1KKiQD000817 for ; Thu, 1 Nov 2007 21:20:44 +0100 (CET) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id lA1KKgWn014715 for ; Thu, 1 Nov 2007 21:20:42 +0100 (MET) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id lA1KKgc7014712; Thu, 1 Nov 2007 21:20:42 +0100 (MET) (envelope-from arno) To: freebsd-hackers@freebsd.org From: "Arno J. Klaassen" Date: 01 Nov 2007 21:20:42 +0100 Message-ID: Lines: 90 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.164]); Thu, 01 Nov 2007 21:20:44 +0100 (CET) X-Virus-Scanned: ClamAV 0.88.7/4659/Thu Nov 1 17:24:40 2007 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 472A351C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Subject: "indefinite" wait buffer patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 21:15:52 -0000 --=-=-= Hello, while slowly testing releng_7, I remembered I have since about two years the attached diff in my releng_6 sources (patch recreated against releng_7 with low timeouts for debugging) : it addresses the situation when one creates a huge swap-space on a (relatively) slow disk-subsystem : e.g. for scientific computing it sometimes makes sense to have, e.g. 8G swap for 2G main memory if you know you're treating N less then 2G matrices and process is CPU-bound for quite a while for 1 matrix before switching to the other. But then, when switching from one matrix to another, dmesg gets flooded by : "indefinite wait buffer" messages. The attached patch shows in fact that the wait buffer is never "indefinite" (unless a real HW-problem probably) and linearly increases timeout to match with reality. The last chunk is just to prevent for a panic at reboot when there is so much data swapped out that is doesn't get treated before 'reboot-finish-time-out'. With this patch, dmesg lookes like following (with low timeout values, on production systems I use TIMO_CHUNK 20 TIMO_START 1O ) : Nov 1 20:09:52 install kernel: swap_pager: wait buffer timeout 1 (1 secs): bufobj: 0, blkno: 1649, size: 28672 Nov 1 20:09:52 install kernel: swap_pager: wait buffer timeout 2 (2 secs): bufobj: 0, blkno: 1649, size: 28672 Nov 1 20:09:52 install kernel: swap_pager: wait buffer completed (2 retry): bufobj: 0, blkno: 1649, size: 28672 Nov 1 20:37:09 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 329073, size: 32768 Nov 1 20:37:10 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 329073, size: 32768 Nov 1 20:39:06 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 381137, size: 32768 Nov 1 20:39:07 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 381137, size: 32768 Nov 1 20:39:11 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 381161, size: 32768 Nov 1 20:39:14 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 381161, size: 32768 Nov 1 20:39:19 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 381209, size: 32768 Nov 1 20:39:20 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 381209, size: 32768 Nov 1 20:43:18 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 300329, size: 32768 Nov 1 20:43:18 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 300329, size: 32768 Nov 1 20:44:23 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 330617, size: 32768 Nov 1 20:44:24 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 330617, size: 32768 Nov 1 20:44:28 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 330649, size: 32768 Nov 1 20:44:28 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 330649, size: 32768 Nov 1 20:44:33 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 330665, size: 32768 Nov 1 20:44:36 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 330665, size: 32768 Nov 1 20:45:18 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 356481, size: 32768 Nov 1 20:45:18 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 356481, size: 32768 Nov 1 20:45:23 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 356521, size: 32768 Nov 1 20:45:27 install kernel: swap_pager: wait buffer timeout 2 (4 secs): bufobj: 0, blkno: 356521, size: 32768 Nov 1 20:45:31 install kernel: swap_pager: wait buffer completed (2 retry): bufobj: 0, blkno: 356521, size: 32768 Nov 1 20:46:37 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 391113, size: 32768 Nov 1 20:46:37 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 391113, size: 32768 Nov 1 20:46:42 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 391129, size: 32768 Nov 1 20:46:45 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 391129, size: 32768 Nov 1 20:48:18 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 432249, size: 32768 Nov 1 20:48:18 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 432249, size: 32768 Nov 1 20:48:25 install kernel: swap_pager: wait buffer timeout 1 (4 secs): bufobj: 0, blkno: 432273, size: 32768 Nov 1 20:48:25 install kernel: swap_pager: wait buffer completed (1 retry): bufobj: 0, blkno: 432273, size: 32768 (And then the timeout of 8 secs apperently is enough for this test setup). Any thoughts? Regards, Arno --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=swap.patch Index: sys/vm/swap_pager.c =================================================================== RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v retrieving revision 1.295 diff -u -r1.295 swap_pager.c --- sys/vm/swap_pager.c 5 Aug 2007 21:04:32 -0000 1.295 +++ sys/vm/swap_pager.c 1 Nov 2007 18:59:18 -0000 @@ -941,6 +941,10 @@ vm_page_t mreq; int i; int j; + int retry = 0; +#define TIMO_CHUNK 2 +#define TIMO_START 1 /* set low to force quick first timeout */ + static int timo_secs = TIMO_START; daddr_t blk; mreq = m[reqpage]; @@ -1066,16 +1070,28 @@ */ VM_OBJECT_LOCK(object); while ((mreq->oflags & VPO_SWAPINPROG) != 0) { + if (retry == 0) { mreq->oflags |= VPO_WANTED; vm_page_lock_queues(); vm_page_flag_set(mreq, PG_REFERENCED); vm_page_unlock_queues(); PCPU_INC(cnt.v_intrans); - if (msleep(mreq, VM_OBJECT_MTX(object), PSWP, "swread", hz*20)) { + } + if (msleep(mreq, VM_OBJECT_MTX(object), PSWP, "swread", hz*timo_secs)) { printf( -"swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: %ld\n", - bp->b_bufobj, (intmax_t)bp->b_blkno, bp->b_bcount); +"swap_pager: wait buffer timeout %d (%d secs): bufobj: %p, blkno: %jd, size: %ld\n", + ++retry, timo_secs, bp->b_bufobj, (intmax_t)bp->b_blkno, bp->b_bcount); + if (retry*TIMO_CHUNK > timo_secs) { + timo_secs = retry*TIMO_CHUNK; + } + } else { + if (retry > 0) { + printf( +"swap_pager: wait buffer completed (%d retry): bufobj: %p, blkno: %jd, size: %ld\n", + retry, bp->b_bufobj, (intmax_t)bp->b_blkno, bp->b_bcount); + } } + } /* @@ -1553,6 +1569,7 @@ swp_pager_force_pagein(vm_object_t object, vm_pindex_t pindex) { vm_page_t m; + int ret; vm_object_pip_add(object, 1); m = vm_page_grab(object, pindex, VM_ALLOC_NORMAL|VM_ALLOC_RETRY); @@ -1567,8 +1584,18 @@ return; } - if (swap_pager_getpages(object, &m, 1, 0) != VM_PAGER_OK) - panic("swap_pager_force_pagein: read from swap failed");/*XXX*/ + if ((ret=swap_pager_getpages(object, &m, 1, 0)) != VM_PAGER_OK) { + if (ret == VM_PAGER_FAIL) { + printf("swp_pager_force_pagein: VM_PAGER_FAIL\n"); + } + else { + if (ret == VM_PAGER_ERROR) { + printf("swp_pager_force_pagein: VM_PAGER_ERROR\n"); + } + else + panic("swap_pager_force_pagein: read from swap failed");/*XXX*/ + } + } vm_object_pip_subtract(object, 1); vm_page_lock_queues(); vm_page_dirty(m); --=-=-= -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 1 23:07:18 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AEFC16A417; Thu, 1 Nov 2007 23:07:18 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from mail.lxnt.info (mail.lxnt.info [217.23.143.142]) by mx1.freebsd.org (Postfix) with ESMTP id 2313213C4A5; Thu, 1 Nov 2007 23:07:18 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from [84.23.55.127] (helo=[192.168.1.100]) by mail.lxnt.info with esmtpa (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Inhq9-000Cos-Gb; Fri, 02 Nov 2007 00:44:37 +0300 Message-ID: <472A548B.50406@lxnt.info> Date: Fri, 02 Nov 2007 01:34:51 +0300 From: Alexander Sabourenkov User-Agent: Thunderbird 1.5.0.7 (X11/20061030) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, sos@FreeBSD.org, "Matthew D. Fuller" , Thierry Herbelot Subject: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2007 23:07:18 -0000 Hello. I have ported the workaround for the hardware bug that causes data corruption on Promise SATA300 TX4 cards to RELENG_7. Bug description: SATA300 TX4 hardware chokes if last PRD entry (in a dma transfer) is larger than 164 bytes. This was found while analysing vendor-supplied linux driver. Workaround: Split trailing PRD entry if it's larger that 164 bytes. Two supplied patches do fix problem on my machine. There is, however, a style problem with them. It seems like PRD entry count is limited at 256. I have not found a good way to guarantee that one entry is always available to do the split, thus the ugly solution of patching ata-dma.c. Patches, patched and original files are at http://lxnt.info/tx4/freebsd/. --- ata-chipset.c.orig 2007-11-02 01:05:49.000000000 +0300 +++ ata-chipset.c 2007-11-02 01:05:49.000000000 +0300 @@ -142,6 +142,7 @@ static int ata_promise_mio_command(struct ata_request *request); static void ata_promise_mio_reset(device_t dev); static void ata_promise_mio_dmainit(device_t dev); +static void ata_promise_mio_dmasetprd(void *xsc, bus_dma_segment_t *segs, int nsegs, int error); static void ata_promise_mio_setmode(device_t dev, int mode); static void ata_promise_sx4_intr(void *data); static int ata_promise_sx4_command(struct ata_request *request); @@ -185,7 +186,6 @@ static int ata_check_80pin(device_t dev, int mode); static int ata_mode2idx(int mode); - /* * generic ATA support functions */ @@ -3759,8 +3759,44 @@ static void ata_promise_mio_dmainit(device_t dev) { + struct ata_channel *ch = device_get_softc(dev); + /* note start and stop are not used here */ ata_dmainit(dev); + + if (ch->dma) + ch->dma->setprd = ata_promise_mio_dmasetprd; +} + +static void +ata_promise_mio_dmasetprd(void *xsc, bus_dma_segment_t *segs, int nsegs, int error) +{ + #define PDC_MAXLASTSGSIZE 41*4 + struct ata_dmasetprd_args *args = xsc; + struct ata_dma_prdentry *prd = args->dmatab; + int i; + + if ((args->error = error)) + return; + + for (i = 0; i < nsegs; i++) { + prd[i].addr = htole32(segs[i].ds_addr); + prd[i].count = htole32(segs[i].ds_len); + } + + if (segs[i - 1].ds_len > PDC_MAXLASTSGSIZE) { + /* + printf("splitting trailing PRD of %ld (limit %d)\n", segs[i - 1].ds_len, PDC_MAXLASTSGSIZE); + */ + prd[i - 1].count = htole32(segs[i - 1].ds_len - PDC_MAXLASTSGSIZE); + prd[i].count = htole32(PDC_MAXLASTSGSIZE); + prd[i].addr = htole32(segs[i - 1].ds_addr + PDC_MAXLASTSGSIZE); + i ++; + nsegs ++; + } + + prd[i - 1].count |= htole32(ATA_DMA_EOT); + args->nsegs = nsegs; } static void --- ata-dma.c.orig 2007-11-02 01:05:53.000000000 +0300 +++ ata-dma.c 2007-11-02 01:05:53.000000000 +0300 @@ -113,7 +113,7 @@ if (bus_dma_tag_create(ch->dma->dmatag,ch->dma->alignment,ch->dma->boundary, ch->dma->max_address, BUS_SPACE_MAXADDR, NULL, NULL, ch->dma->max_iosize, - ATA_DMA_ENTRIES, ch->dma->segsize, + ATA_DMA_ENTRIES - 1, ch->dma->segsize, 0, NULL, NULL, &ch->dma->data_tag)) goto error; -- ./lxnt From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 02:26:40 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 874F316A417 for ; Fri, 2 Nov 2007 02:26:40 +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 D9DE913C4A7 for ; Fri, 2 Nov 2007 02:26:39 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup229.ach.sch.gr [81.186.70.229]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id lA225Zkb026269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Nov 2007 04:05:57 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id lA225Yon003807; Fri, 2 Nov 2007 04:05:34 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id lA225WJJ003806; Fri, 2 Nov 2007 04:05:33 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Fri, 2 Nov 2007 04:05:32 +0200 From: Giorgos Keramidas To: Eduardo Morras Message-ID: <20071102020532.GF3205@kobe.laptop> References: <4727D40B000DF505@> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4727D40B000DF505@> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.139, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.26, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-hackers@freebsd.org Subject: Re: memory pool, rfc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 02:26:40 -0000 On 2007-11-01 12:45, Eduardo Morras wrote: > At 01:57 01/11/2007, you wrote: >> On Thu, Nov 01, 2007 at 01:05:54AM +0100, Eduardo Morras wrote: >> > Don't point me to zlib or libbzip2, they are on another league and are >> much >> > slower than my code. >> >> Have you looked at liblzo? > > Yes, i know lzo, i'm working with compression since '99. My code has > similar compression efficience but is low size block oriented and faster on > compression/decompression. > > Giorgios Keramidas suggested on freebsd-question to prepare a paper and > code about it Yep. Thank you for actually *posting* about it on -hackers. I'll be glad to see this actually hit the tree with some useful and well-implemented feature in the future :-) From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 02:49:22 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3761216A417 for ; Fri, 2 Nov 2007 02:49:22 +0000 (UTC) (envelope-from binto@triplegate.net.id) Received: from outgoing16.3gate.net (outgoing16.3gate.net [202.127.97.16]) by mx1.freebsd.org (Postfix) with SMTP id 551BE13C481 for ; Fri, 2 Nov 2007 02:49:21 +0000 (UTC) (envelope-from binto@triplegate.net.id) Received: (qmail 59364 invoked by uid 1011); 2 Nov 2007 02:28:44 -0000 Received: from 202.127.97.100 by mx2.3gate.net (envelope-from , uid 1009) with qmail-scanner-1.25-st-qms (clamdscan: 0.86.2/1034. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:1(202.127.97.100):. Processed in 0.043495 secs); 02 Nov 2007 02:28:44 -0000 X-Antivirus-3GATE-NET-Mail-From: binto@triplegate.net.id via mx2.3gate.net X-Antivirus-3GATE-NET: 1.25-st-qms (Clear:RC:1(202.127.97.100):. Processed in 0.043495 secs Process 59358) Received: from smtp.triplegate.net.id (HELO webmail.triplegate.net.id) (202.127.97.100) by outgoing16.3gate.net with SMTP; 2 Nov 2007 02:28:44 -0000 Received: from 202.127.98.144 (SquirrelMail authenticated user binto@triplegate.net.id) by webmail.triplegate.net.id with HTTP; Fri, 2 Nov 2007 09:39:19 +0700 (WIT) Message-ID: <1240.202.127.98.144.1193971159.squirrel@webmail.triplegate.net.id> Date: Fri, 2 Nov 2007 09:39:19 +0700 (WIT) From: "binto" To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 02:49:22 -0000 I try to compile MYKERNEL to set zero_copy & tigon driver in my machine with: device ti options TI_PRIVATE_JUMBOS options TI_JUMBO_HDRSPLIT but got: #error "options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive" what's up....? thx From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 04:10:24 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFAED16A41A for ; Fri, 2 Nov 2007 04:10:23 +0000 (UTC) (envelope-from pyunyh@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 9A90913C465 for ; Fri, 2 Nov 2007 04:10:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so882470waf for ; Thu, 01 Nov 2007 21:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=uyy3xIkyKJTCaJ5ajKzCmXJybFCwadvkNxIjvKhHECc=; b=qNTr4CMspw4yjfRYnIoMvxXGCnuzGD1DmTmHk0ACzqB6hsj6qZ3vqpbJuToNNiRt1zjATw1yd3FugOyzaW/02RsrA1hC619GAQMOwaRZaJCXwbl+hNEHwim+7RXv45SIyfGVc0KD5ZU6F0wEfWr1yc7KozvUoXx36cf3v2RNeF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=VtDiqJGjUheM07WfZI2fFW9CGmq07YbgBlRnrwsTTjVPZ4/HvJp6b9FGCvPZiYu31hBkzsVyLKjnhu6m93Ws2WZVXn1LaNIxti2CRvVD64iBANXy6ffd4IQv4NPbhB+PY8X8QD5JfZ5Mo5SDCtZwsjywmCwLPMtj0yCDRkD+dog= Received: by 10.114.93.17 with SMTP id q17mr1392302wab.1193975154739; Thu, 01 Nov 2007 20:45:54 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id j7sm5163241wah.2007.11.01.20.45.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2007 20:45:53 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id lA23jlI5052492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2007 12:45:47 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id lA23jjwI052491; Fri, 2 Nov 2007 12:45:45 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 2 Nov 2007 12:45:45 +0900 From: Pyun YongHyeon To: binto Message-ID: <20071102034545.GA51855@cdnetworks.co.kr> References: <1240.202.127.98.144.1193971159.squirrel@webmail.triplegate.net.id> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1240.202.127.98.144.1193971159.squirrel@webmail.triplegate.net.id> User-Agent: Mutt/1.4.2.1i Cc: freebsd-hackers@freebsd.org Subject: Re: options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 04:10:24 -0000 On Fri, Nov 02, 2007 at 09:39:19AM +0700, binto wrote: > I try to compile MYKERNEL to set zero_copy & tigon driver in my machine > with: > > device ti > options TI_PRIVATE_JUMBOS > options TI_JUMBO_HDRSPLIT > > but got: > #error "options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually > exclusive" > > what's up....? > %vi +/TI_JUMBO_HDRSPLIT /usr/src/sys/conf/NOTES -- Regards, Pyun YongHyeon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 04:34:21 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 660F916A419 for ; Fri, 2 Nov 2007 04:34:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 3260413C48E for ; Fri, 2 Nov 2007 04:34:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so888615waf for ; Thu, 01 Nov 2007 21:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=9pvF7Xm+sWCluQbWR3P82I0pST2TtlDnAC+krR8YEc4=; b=g2xJP4i9z6Sz4s48DSe4zvLkor15OtMBQ/LqzcYHbycqvCuV47zK3l+UtOf3F9bBwf0v/ICJTRHrFI/P0zmA/RLmTMp4+RNHc1LZmR+LaGQD6DCUbki12hdAz0ka1x9cCNQ7aQaSPGjnpzLfuhWKVrW3ZKAU7HrqWPAjCSRKK2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=WlHI1+oUEef16+qNXy2yW6slGJihTc8o0FfMdfbc15qvzbKvWSdqTjWx13cNWx9DV0pYAXqqVjP09ACJ4xlEtUCTuPqL2FRst/ftlUzm1S7d3ZtUlRsp6TMqt9qNBihHXWrEynCdBVBnNsy6to9oUnVUQbeWFs3iXKqDTGaBZYw= Received: by 10.115.54.1 with SMTP id g1mr1407314wak.1193978037826; Thu, 01 Nov 2007 21:33:57 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id l22sm5269304waf.2007.11.01.21.33.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2007 21:33:56 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id lA24Xodv052645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2007 13:33:50 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id lA24Xot5052644; Fri, 2 Nov 2007 13:33:50 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 2 Nov 2007 13:33:49 +0900 From: Pyun YongHyeon To: binto Message-ID: <20071102043349.GB51855@cdnetworks.co.kr> References: <1240.202.127.98.144.1193971159.squirrel@webmail.triplegate.net.id> <20071102034545.GA51855@cdnetworks.co.kr> <1648.202.127.98.144.1193976026.squirrel@webmail.triplegate.net.id> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1648.202.127.98.144.1193976026.squirrel@webmail.triplegate.net.id> User-Agent: Mutt/1.4.2.1i Cc: jfv@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually exclusive X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 04:34:21 -0000 On Fri, Nov 02, 2007 at 11:00:26AM +0700, binto wrote: > another question..... > in my 'dmesg' i have NIC - em0 Version - 6.6.6>...is it support Tigon driver that need to set > ZERO_COPY_SOCKETS ? > em(4) supports zero copy for Tx side. zero copy for receiver side requires header splitting assistance from hardware which is not available in em(4). I guess ti(4) on Tigon II would be the only driver that supports header splitting. However it seems newer Intel NICs and Sun Cassini+ seems to have header splitting feature. Jack Vogel, maintainer of em(4), may have more information for header splitting support on em(4).(CCed) > thx > > > On Fri, Nov 02, 2007 at 09:39:19AM +0700, binto wrote: > > > I try to compile MYKERNEL to set zero_copy & tigon driver in my machine > > > with: > > > > > > device ti > > > options TI_PRIVATE_JUMBOS > > > options TI_JUMBO_HDRSPLIT > > > > > > but got: > > > #error "options TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS are mutually > > > exclusive" > > > > > > what's up....? > > > > > > > %vi +/TI_JUMBO_HDRSPLIT /usr/src/sys/conf/NOTES > > > > -- > > Regards, > > Pyun YongHyeon > > > > -- Regards, Pyun YongHyeon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 05:14:17 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A2DF16A417 for ; Fri, 2 Nov 2007 05:14:17 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id 28BDD13C4B0 for ; Fri, 2 Nov 2007 05:14:17 +0000 (UTC) (envelope-from ioplex@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so575604rvb for ; Thu, 01 Nov 2007 22:13:46 -0700 (PDT) Received: by 10.143.16.9 with SMTP id t9mr365009wfi.1193961747982; Thu, 01 Nov 2007 17:02:27 -0700 (PDT) Received: by 10.142.164.5 with HTTP; Thu, 1 Nov 2007 17:02:27 -0700 (PDT) Message-ID: <78c6bd860711011702k78e0aa3dy725c1a2d9c690c1b@mail.gmail.com> Date: Thu, 1 Nov 2007 20:02:27 -0400 From: "Michael B Allen" To: "Peter Jeremy" In-Reply-To: <20071101195123.GJ25671@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <78c6bd860711011041o6d10753an663f19389737f84b@mail.gmail.com> <20071101195123.GJ25671@server.vk2pj.dyndns.org> Cc: freebsd-hackers Subject: Re: timers and semtimedop(2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 05:14:17 -0000 On 11/1/07, Peter Jeremy wrote: > On Thu, Nov 01, 2007 at 01:41:10PM -0400, Michael B Allen wrote: > >I need semtimedop(2). I'm thinking I can just do a semop with a SIGINT maybe. > > I presume you mean SIGALRM. > > >Can someone suggest a good method for setting up a timer to deliver > >the signal? What sort of timers does FreeBSD offer? > > Assuming you aren't planning on creating a new syscall: man setitimer > There's also kqueue EVFILT_TIMER but that is probably only useful if > you are already using kqueue for other purposes. Hi Peter, On second thought I decided to use the application's existing event loop to call semop and notify the waiter. It's not a self contained solution and it won't work if the event loop itself is the waiter but it it almost always pays not to use signals if you don't absolutely have to. Thanks, Mike From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 07:56:10 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDF7716A418 for ; Fri, 2 Nov 2007 07:56:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from gnome.kiev.sovam.com (gnome.kiev.sovam.com [212.109.32.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8648E13C447 for ; Fri, 2 Nov 2007 07:56:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com ([62.64.120.197]) by gnome.kiev.sovam.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Inhc4-000EWE-9S for freebsd-hackers@freebsd.org; Thu, 01 Nov 2007 23:30:04 +0200 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 1Inhc1-0003Nw-Gs for freebsd-hackers@freebsd.org; Thu, 01 Nov 2007 23:30:03 +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 lA1LTvho087278; Thu, 1 Nov 2007 23:29:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id lA1LTvf3087277; Thu, 1 Nov 2007 23:29: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: Thu, 1 Nov 2007 23:29:57 +0200 From: Kostik Belousov To: "Arno J. Klaassen" Message-ID: <20071101212957.GZ37471@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yTwVabqJa5IUz21H" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 962db39f35b00980c0b011075312dce6 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1727 [Nov 01 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-hackers@freebsd.org Subject: Re: "indefinite" wait buffer patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 07:56:10 -0000 --yTwVabqJa5IUz21H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 01, 2007 at 09:20:42PM +0100, Arno J. Klaassen wrote: > Hello, >=20 >=20 > while slowly testing releng_7, I remembered I have since about > two years the attached diff in my releng_6 sources (patch > recreated against releng_7 with low timeouts for debugging) : >=20 > it addresses the situation when one creates a huge swap-space on=20 > a (relatively) slow disk-subsystem : e.g. for scientific computing > it sometimes makes sense to have, e.g. 8G swap for 2G main memory > if you know you're treating N less then 2G matrices and process > is CPU-bound for quite a while for 1 matrix before switching to=20 > the other. > But then, when switching from one matrix to another, dmesg gets > flooded by : >=20 > "indefinite wait buffer"=20 >=20 > messages. >=20 > The attached patch shows in fact that the wait buffer is never > "indefinite" (unless a real HW-problem probably) and linearly > increases timeout to match with reality. I think this is mostly good. See below. >=20 > The last chunk is just to prevent for a panic at reboot when > there is so much data swapped out that is doesn't get treated > before 'reboot-finish-time-out'. This chunk would cause (non-silent) data corruption. Besides reboot, the code is used when swap is turned off on live system. Index: sys/vm/swap_pager.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v retrieving revision 1.295 diff -u -r1.295 swap_pager.c --- sys/vm/swap_pager.c 5 Aug 2007 21:04:32 -0000 1.295 +++ sys/vm/swap_pager.c 1 Nov 2007 18:59:18 -0000 @@ -941,6 +941,10 @@ =2E.. + static int timo_secs =3D TIMO_START; =2E.. + if (retry*TIMO_CHUNK > timo_secs) { + timo_secs =3D retry*TIMO_CHUNK; Imagine that two buffers got the timeout on swap-in simultaneously. I think that, instead, making timo_secs local variable would be right. Also, timeout reading one buffer shall not increase the timeout swapping in another one. --yTwVabqJa5IUz21H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHKkVUC3+MBN1Mb4gRAgjWAKDJrXg8thPMtMTC8wHGbSsYjsWXLgCguYBd s4RAJQ+rNiAF7Qh9apE/qz0= =c0cx -----END PGP SIGNATURE----- --yTwVabqJa5IUz21H-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 10:27:37 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81CCD16A417; Fri, 2 Nov 2007 10:27:37 +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 0307D13C4A8; Fri, 2 Nov 2007 10:27:36 +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 lA2AR1sA063797; Fri, 2 Nov 2007 11:27:01 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <472AFB75.1070207@deepcore.dk> Date: Fri, 02 Nov 2007 11:27:01 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexander Sabourenkov References: <472A548B.50406@lxnt.info> In-Reply-To: <472A548B.50406@lxnt.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.ORG, sos@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, "Matthew D. Fuller" , Thierry Herbelot Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 10:27:37 -0000 Alexander Sabourenkov wrote: > Hello. > > I have ported the workaround for the hardware bug that causes data > corruption on Promise SATA300 TX4 cards to RELENG_7. > > Bug description: > SATA300 TX4 hardware chokes if last PRD entry (in a dma transfer) is > larger than 164 bytes. This was found while analysing vendor-supplied > linux driver. > > Workaround: > Split trailing PRD entry if it's larger that 164 bytes. > > Two supplied patches do fix problem on my machine. > > There is, however, a style problem with them. It seems like PRD entry > count is limited at 256. I have not found a good way to guarantee that > one entry is always available to do the split, thus the ugly solution o= f > patching ata-dma.c. > =20 Good catch! However from my quick glimpse at the Promise sources the limit seems to=20 be 32 Dwords ie 32*4 =3D 128bytes. I'll investigate further and ask Promise for the gory details, stay tuned= =2E.. I dont think the PRD count limitation is a real problem, I've newer seen = that long a list and IIRC we newer do more than 64K transfers in one go=20 (yet). Anyhow I need to get checks in for that not just here... Give me a few days and I'll get this figured out for 7-rel... -S=F8ren > > Patches, patched and original files are at http://lxnt.info/tx4/freebsd= /. > > > --- ata-chipset.c.orig 2007-11-02 01:05:49.000000000 +0300 > +++ ata-chipset.c 2007-11-02 01:05:49.000000000 +0300 > @@ -142,6 +142,7 @@ > static int ata_promise_mio_command(struct ata_request *request); > static void ata_promise_mio_reset(device_t dev); > static void ata_promise_mio_dmainit(device_t dev); > +static void ata_promise_mio_dmasetprd(void *xsc, bus_dma_segment_t > *segs, int nsegs, int error); > static void ata_promise_mio_setmode(device_t dev, int mode); > static void ata_promise_sx4_intr(void *data); > static int ata_promise_sx4_command(struct ata_request *request); > @@ -185,7 +186,6 @@ > static int ata_check_80pin(device_t dev, int mode); > static int ata_mode2idx(int mode); > > - > /* > * generic ATA support functions > */ > @@ -3759,8 +3759,44 @@ > static void > ata_promise_mio_dmainit(device_t dev) > { > + struct ata_channel *ch =3D device_get_softc(dev); > +=09 > /* note start and stop are not used here */ > ata_dmainit(dev); > + > + if (ch->dma) > + ch->dma->setprd =3D ata_promise_mio_dmasetprd; > +} > + > +static void > +ata_promise_mio_dmasetprd(void *xsc, bus_dma_segment_t *segs, int > nsegs, int error) > +{ > + #define PDC_MAXLASTSGSIZE 41*4 > + struct ata_dmasetprd_args *args =3D xsc; > + struct ata_dma_prdentry *prd =3D args->dmatab; > + int i; > + > + if ((args->error =3D error)) > + return; > + > + for (i =3D 0; i < nsegs; i++) { > + prd[i].addr =3D htole32(segs[i].ds_addr); > + prd[i].count =3D htole32(segs[i].ds_len); > + } > + > + if (segs[i - 1].ds_len > PDC_MAXLASTSGSIZE) { > + /* > + printf("splitting trailing PRD of %ld (limit %d)\n", segs[i - > 1].ds_len, PDC_MAXLASTSGSIZE); > + */ > + prd[i - 1].count =3D htole32(segs[i - 1].ds_len - PDC_MAXLASTSGSIZE);= > + prd[i].count =3D htole32(PDC_MAXLASTSGSIZE); > + prd[i].addr =3D htole32(segs[i - 1].ds_addr + PDC_MAXLASTSGSIZE); > + i ++; > + nsegs ++; > + } > + > + prd[i - 1].count |=3D htole32(ATA_DMA_EOT); > + args->nsegs =3D nsegs; > } > > static void > > --- ata-dma.c.orig 2007-11-02 01:05:53.000000000 +0300 > +++ ata-dma.c 2007-11-02 01:05:53.000000000 +0300 > @@ -113,7 +113,7 @@ > if > (bus_dma_tag_create(ch->dma->dmatag,ch->dma->alignment,ch->dma->boundar= y, > ch->dma->max_address, BUS_SPACE_MAXADDR, > NULL, NULL, ch->dma->max_iosize, > - ATA_DMA_ENTRIES, ch->dma->segsize, > + ATA_DMA_ENTRIES - 1, ch->dma->segsize, > 0, NULL, NULL, &ch->dma->data_tag)) > goto error; > > > =20 From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 10:42:07 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7565B16A417; Fri, 2 Nov 2007 10:42:07 +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 0C6AE13C447; Fri, 2 Nov 2007 10:42:06 +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 lA2Af7Ij063961; Fri, 2 Nov 2007 11:41:07 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <472AFEC3.7090001@deepcore.dk> Date: Fri, 02 Nov 2007 11:41:07 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexander Sabourenkov References: <472A548B.50406@lxnt.info> <472AFB75.1070207@deepcore.dk> In-Reply-To: <472AFB75.1070207@deepcore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.ORG, sos@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, "Matthew D. Fuller" , Thierry Herbelot Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 10:42:07 -0000 S=F8ren Schmidt wrote: > Good catch! > > However from my quick glimpse at the Promise sources the limit seems=20 > to be 32 Dwords ie 32*4 =3D 128bytes. > I'll investigate further and ask Promise for the gory details, stay=20 > tuned... > I dont think the PRD count limitation is a real problem, I've newer=20 > seen that long a list and IIRC we newer do more than 64K transfers in=20 > one go (yet). > Anyhow I need to get checks in for that not just here... > > Give me a few days and I'll get this figured out for 7-rel... Oh, and I forgot, do you have a surefire way to reproduce the problem so = the fix can be tested ? I've newer been able to trigger this problem myself so far. -S=F8ren From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 10:57:53 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86D7416A417; Fri, 2 Nov 2007 10:57:53 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from mail.lxnt.info (mail.lxnt.info [217.23.143.142]) by mx1.freebsd.org (Postfix) with ESMTP id 426D813C4A5; Fri, 2 Nov 2007 10:57:53 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from [217.23.131.8] (helo=lxnt.inside.caravan.ru) by mail.lxnt.info with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1InuDX-000OY8-2f; Fri, 02 Nov 2007 13:57:35 +0300 Message-ID: <472B02B5.9020502@lxnt.info> Date: Fri, 02 Nov 2007 13:57:57 +0300 From: Alexander Sabourenkov User-Agent: Thunderbird 2.0.0.6 (X11/20071024) MIME-Version: 1.0 To: =?UTF-8?B?U8O4cmVuIFNjaG1pZHQ=?= References: <472A548B.50406@lxnt.info> <472AFB75.1070207@deepcore.dk> <472AFEC3.7090001@deepcore.dk> In-Reply-To: <472AFEC3.7090001@deepcore.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@FreeBSD.ORG, sos@FreeBSD.ORG, freebsd-current@FreeBSD.ORG, "Matthew D. Fuller" , Thierry Herbelot Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 10:57:53 -0000 Søren Schmidt wrote: > Søren Schmidt wrote: >> Good catch! >> >> However from my quick glimpse at the Promise sources the limit seems >> to be 32 Dwords ie 32*4 = 128bytes. Please see driver named 4_sataii150-300_linux2.6-src_x86-64_v1.01.0.23 >> I'll investigate further and ask Promise for the gory details, stay >> tuned... >> I dont think the PRD count limitation is a real problem, I've newer >> seen that long a list and IIRC we newer do more than 64K transfers in >> one go (yet). In (current) practice, yes, but check should be there even if only to document the limit. >> Anyhow I need to get checks in for that not just here... >> >> Give me a few days and I'll get this figured out for 7-rel... > Oh, and I forgot, do you have a surefire way to reproduce the problem so > the fix can be tested ? dd if=/dev/ad8 of=/dev/null bs=1048576 count=1000 works every time. I have tested it on my home machine: without the patch first timeouts and errors appear about 10 seconds into the read. with the patch a read of entire disk (320G) completed without errors. Previous tests of analogous linux driver fix shown no errors and no data corruption on two write-whole-drive, read-whole-drive cycles. > > I've newer been able to trigger this problem myself so far. > Seems like the bug is highly configuration-dependent, or pci-chiset-depended, or just present in some production runs and not other. -- ./lxnt From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 11:09:46 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E36B116A417; Fri, 2 Nov 2007 11:09:46 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 5B62E13C49D; Fri, 2 Nov 2007 11:09:46 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id lA29vu1X036459; Fri, 2 Nov 2007 12:57:56 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id lA29vtEd036453; Fri, 2 Nov 2007 12:57:56 +0300 (MSK) (envelope-from yar) Date: Fri, 2 Nov 2007 12:57:55 +0300 From: Yar Tikhiy To: obrien@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20071102095754.GA84814@comp.chem.msu.su> References: <20070901073440.GL85633@comp.chem.msu.su> <46DAFE5C.6070806@freebsd.org> <20070903120353.GH30502@comp.chem.msu.su> <200709261028.43378.jhb@freebsd.org> <20071004022344.GA60878@dragon.NUXI.org> <20071013060138.GA14388@comp.chem.msu.su> <20071015173826.GA88628@dragon.NUXI.org> <20071017220421.GD25575@comp.chem.msu.su> <20071101155339.GA6490@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071101155339.GA6490@dragon.NUXI.org> User-Agent: Mutt/1.5.9i Cc: Subject: Re: Useful tools missing from /rescue X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 11:09:47 -0000 On Thu, Nov 01, 2007 at 08:53:39AM -0700, David O'Brien wrote: > On Thu, Oct 18, 2007 at 02:04:21AM +0400, Yar Tikhiy wrote: > > On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote: > > > I guess I'm not creative enough in the ways I've screwed up my systems > > > and needed tools from /rescue. 8-) > > > > Just try to installworld FreeBSD/amd64 over a running FreeBSD/i386. ;-) > > I strongly feel that shouldn't be supported on a live system. So to me We already got that possibility for free along with src/Makefile.inc1#1.590, so no particular efforts are needed to support it. > it shouldn't be an excuse to put a duplicated copy of /usr/[s]bin into > /rescue. It's an exaggeration. The most of /usr/[s]bin aren't in /rescue yet. :-) > It is a delicate thing to get right - and there are easy ways to do it > today: > > Boot from disc1; mount / and /usr; mv /mnt/etc /mnt/etc.hold; rm -rf the > bits in bin,sbin,libexec; then run the install.sh from the disc1; mv > /mnt/etc /mnt/etc.new ; mv /mnt/etc.hold /mnt/etc One of the things I love FreeBSD for is being able to do things in different ways and to choose such a way depending on the case. :-) E.g., one may want to go from CURRENT/arch1 to CURRENT/arch2 without having to install a binary release or snapshot for arch2 first. -- Yar From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 11:29:39 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3A4816A41A for ; Fri, 2 Nov 2007 11:29:39 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx02.syd.optusnet.com.au (fallbackmx02.syd.optusnet.com.au [211.29.133.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5100613C4CC for ; Fri, 2 Nov 2007 11:29:33 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by fallbackmx02.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id lA16I9wm023661 for ; Thu, 1 Nov 2007 17:18:09 +1100 Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lA16H7dZ011840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2007 17:17:08 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id lA16H75R024389; Thu, 1 Nov 2007 17:17:07 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id lA16H7om024388; Thu, 1 Nov 2007 17:17:07 +1100 (EST) (envelope-from peter) Date: Thu, 1 Nov 2007 17:17:07 +1100 From: Peter Jeremy To: James Healy Message-ID: <20071101061707.GL22890@server.vk2pj.dyndns.org> References: <47291254.9030909@swin.edu.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <47291254.9030909@swin.edu.au> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers@freebsd.org, Lawrence Stewart Subject: Re: floating point operations X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 11:29:39 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 01, 2007 at 10:40:04AM +1100, James Healy wrote: >The remaining op is not easily converted to fixed point math, and we're >wondering what impact a single flop on the receipt of each ACK will >have. We don't have a strong understanding of the amount of overhead >involved in executing a flop instead of an int op on modern hardware. A single floating point operation in the kernel means that the kernel must be adapted to allow floating point within it - saving userland FP state somewhere between kernel entry and the FLOP, handling pesky exceptions etc. The problem is not the number of FLOPs in the kernel, the problem is that the kernel is not currently setup to allow any floating point within it. This topic came up last week and I suggest you have a look at the thread starting: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-October/022037.html That said, I'm intrigued as to what operation you are stuck on. I'm having trouble visualising what you might be doing that gets stuck on a single FP instruction. --=20 Peter --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHKW9j/opHv/APuIcRAof3AJ91cyYop+qtihvLY8wp97/H6q8qRgCgjxuZ pC8Lqf0pZWsbW9BR0H2+qHw= =fXdh -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 20:08:45 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0C3416A417 for ; Fri, 2 Nov 2007 20:08:45 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 4543913C4B6 for ; Fri, 2 Nov 2007 20:08:44 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id lA2K89VD096226 ; Fri, 2 Nov 2007 21:08:09 +0100 (CET) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id lA2K88iD020508 ; Fri, 2 Nov 2007 21:08:08 +0100 (MET) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id lA2K82rb020505; Fri, 2 Nov 2007 21:08:02 +0100 (MET) (envelope-from arno) To: Alexander Sabourenkov References: <472A548B.50406@lxnt.info> From: "Arno J. Klaassen" Date: 02 Nov 2007 21:08:02 +0100 In-Reply-To: <472A548B.50406@lxnt.info> Message-ID: Lines: 79 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.168]); Fri, 02 Nov 2007 21:08:10 +0100 (CET) X-Virus-Scanned: ClamAV 0.88.7/4662/Fri Nov 2 18:28:34 2007 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 472B83A9.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: freebsd-hackers@freebsd.org, Thierry Herbelot , "Matthew D. Fuller" , sos@freebsd.org Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 20:08:45 -0000 Hello, Alexander Sabourenkov writes: > Hello. > > I have ported the workaround for the hardware bug that causes data > corruption on Promise SATA300 TX4 cards to RELENG_7. > > Bug description: > SATA300 TX4 hardware chokes if last PRD entry (in a dma transfer) is > larger than 164 bytes. This was found while analysing vendor-supplied > linux driver. > > Workaround: > Split trailing PRD entry if it's larger that 164 bytes. > > Two supplied patches do fix problem on my machine. definitely an improvement, but not sufficient (for my setup ) : amd64-releng_6 on an ASUS A8V UP (box ran rock-stable for years i386-releng_5 with same hardware apart TX4 and drives) from dmesg : atapci0: port 0xe000-0xe07f,0xd800-0xd8ff mem 0xfbb00000-0xfbb00fff,0xfba00000-0xfba1ffff irq 18 at device 13.0 on pci0 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 ata5: on atapci0 atapci1: port 0xd400-0xd407,0xd000-0xd003,0xc800-0xc807,0xc400-0xc403,0xc000-0xc00f,0xb800-0xb8ff irq 20 at device 15.0 on pci0 ata6: on atapci1 ata7: on atapci1 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: on atapci2 ata1: on atapci2 [ ... ] ad0: 38166MB at ata0-master UDMA100 ad6: 476940MB at ata3-master SATA300 ad12: 305245MB at ata6-master SATA150 booting from ad0 and simple gconcat over ad6 and ad12. Improvement : I now can fsck /dev/concat/data without ad6 being detached Persistent problem : when I rsync an nfs-mounted disk to /dev/concat/data, I get after about some Gigs of data have been transfered : Nov 2 16:39:55 charlotte kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=268435392 Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435392 Nov 2 16:40:50 charlotte kernel: ad6: FAILURE - WRITE_DMA status=ff error=ff LBA=268435392 Nov 2 16:40:50 charlotte kernel: g_vfs_done():concat/data[WRITE(offset=137438920704, length=131072)]error = 5 Nov 2 16:40:50 charlotte kernel: ad6: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=268435648 Nov 2 16:40:50 charlotte kernel: ad6: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=268435648 Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: FAILURE - WRITE_DMA48 timed out LBA=268435648 Nov 2 16:40:50 charlotte kernel: g_vfs_done():concat/data[WRITE(offset=137439051776, length=131072)]error = 5 ... I will test again with "#define PDC_MAXLASTSGSIZE 32*4" (just to see if that makes a difference) Regards, Arno From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 20:35:55 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDE5616A41A for ; Fri, 2 Nov 2007 20:35:55 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 335B813C4BC for ; Fri, 2 Nov 2007 20:35:54 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.13.8/8.13.8) with ESMTP id lA2HxVJf085539; Fri, 2 Nov 2007 12:59:31 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1194026371; bh=3kf1alMjGfuqdc34n18eHNAfGgF0cieRC3b0/zv 9VgY=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=KLQ5uZ2s zqKXp7FQJfv2rnKkDZsJ+Cqg+8dMQO7QLxBePVUcwAUzA8az25gUGEVgvvPL+SalwlZ NvqwgjONIgjO8Vhbr+bPgzeKIYUhB6TxljkNbrqGuuJoS5PQbOKSbsfn1DbAOtzaXq7 UkkS2Hy7EBJTcejpadCp9fn5eq7Ck= Received: (from tinguely@localhost) by casselton.net (8.13.8/8.13.8/Submit) id lA2HxVIv085535; Fri, 2 Nov 2007 12:59:31 -0500 (CDT) (envelope-from tinguely) Date: Fri, 2 Nov 2007 12:59:31 -0500 (CDT) From: Mark Tinguely Message-Id: <200711021759.lA2HxVIv085535@casselton.net> To: arno@heho.snv.jussieu.fr, kostikbel@gmail.com In-Reply-To: <20071101212957.GZ37471@deviant.kiev.zoral.com.ua> X-Mailman-Approved-At: Fri, 02 Nov 2007 20:37:59 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: "indefinite" wait buffer patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 20:35:55 -0000 Since eyeballs are in swap_page.c - is the putpages panic string mislabeled: swap_pager_putpages(vm_object_t object, vm_page_t *m, int count, boolean_t sync, int *rtvals) { int i; int n = 0; if (count && m[0]->object != object) { panic("swap_pager_getpages: object mismatch %p/%p", ^^^^^^^^ putpages --Mark Tinguely. From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 21:16:42 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD61316A468; Fri, 2 Nov 2007 21:16:42 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from mail.lxnt.info (mail.lxnt.info [217.23.143.142]) by mx1.freebsd.org (Postfix) with ESMTP id 79CC413C4A6; Fri, 2 Nov 2007 21:16:42 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from [84.23.55.127] (helo=[192.168.1.100]) by mail.lxnt.info with esmtpa (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Io3BH-0006KL-MQ; Fri, 02 Nov 2007 23:31:51 +0300 Message-ID: <472B94FB.7070409@lxnt.info> Date: Sat, 03 Nov 2007 00:22:03 +0300 From: Alexander Sabourenkov User-Agent: Thunderbird 1.5.0.7 (X11/20061030) MIME-Version: 1.0 To: "Arno J. Klaassen" References: <472A548B.50406@lxnt.info> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Thierry Herbelot , "Matthew D. Fuller" , sos@freebsd.org Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 21:16:42 -0000 Arno J. Klaassen wrote: > definitely an improvement, but not sufficient (for my setup ) : > > amd64-releng_6 on an ASUS A8V UP (box ran rock-stable > for years i386-releng_5 with same hardware apart TX4 and > drives) > > from dmesg : > Setup is identical to mine, except for the drives. http://lxnt.info/tx4/freebsd/dmesg.text > > Improvement : I now can fsck /dev/concat/data without > ad6 being detached It was that bad? wow. > Persistent problem : when I rsync an nfs-mounted disk to /dev/concat/data, > I get after about some Gigs of data have been transfered : > That's strange. Are you sure cables, PSU and line power are ok? Back in October upgrading PSU halved the error count for me (under linux). > > I will test again with "#define PDC_MAXLASTSGSIZE 32*4" (just to see > if that makes a difference) > Please do. -- ./lxnt From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 21:24:50 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1332516A419 for ; Fri, 2 Nov 2007 21:24:50 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id 6922613C4AA for ; Fri, 2 Nov 2007 21:24:48 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost.int.ru [127.0.0.1] (may be forged)) by mp2.macomnet.net (8.13.7/8.13.8) with ESMTP id lA2KmKdt053746; Fri, 2 Nov 2007 23:48:20 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Fri, 2 Nov 2007 23:48:20 +0300 (MSK) From: Maxim Konovalov To: Mark Tinguely In-Reply-To: <200711021759.lA2HxVIv085535@casselton.net> Message-ID: <20071102234808.H24106@mp2.macomnet.net> References: <200711021759.lA2HxVIv085535@casselton.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: kostikbel@gmail.com, freebsd-hackers@freebsd.org Subject: Re: "indefinite" wait buffer patch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 21:24:50 -0000 On Fri, 2 Nov 2007, 12:59-0500, Mark Tinguely wrote: > > Since eyeballs are in swap_page.c - is the putpages panic string mislabeled: > > swap_pager_putpages(vm_object_t object, vm_page_t *m, int count, > boolean_t sync, int *rtvals) > { > int i; > int n = 0; > > if (count && m[0]->object != object) { > panic("swap_pager_getpages: object mismatch %p/%p", > ^^^^^^^^ > putpages > Just fixed. Thanks. -- Maxim Konovalov From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 22:18:42 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE86E16A468; Fri, 2 Nov 2007 22:18:42 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id B4E7A13C4BE; Fri, 2 Nov 2007 22:18:40 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id lA2MHvc6040767 ; Fri, 2 Nov 2007 23:17:57 +0100 (CET) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id lA2MHuau020975 ; Fri, 2 Nov 2007 23:17:56 +0100 (MET) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id lA2MHtgJ020972; Fri, 2 Nov 2007 23:17:55 +0100 (MET) (envelope-from arno) To: Alexander Sabourenkov References: <472A548B.50406@lxnt.info> <472B94FB.7070409@lxnt.info> From: "Arno J. Klaassen" Date: 02 Nov 2007 23:17:55 +0100 In-Reply-To: <472B94FB.7070409@lxnt.info> Message-ID: Lines: 129 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.165]); Fri, 02 Nov 2007 23:17:58 +0100 (CET) X-Virus-Scanned: ClamAV 0.88.7/4664/Fri Nov 2 21:55:38 2007 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 472BA215.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: freebsd-hackers@freebsd.org, Thierry Herbelot , "Matthew D. Fuller" , sos@freebsd.org Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 22:18:42 -0000 Alexander Sabourenkov writes: > Arno J. Klaassen wrote: > > definitely an improvement, but not sufficient (for my setup ) : > > > > amd64-releng_6 on an ASUS A8V UP (box ran rock-stable > > for years i386-releng_5 with same hardware apart TX4 and > > drives) > > > > from dmesg : > > > > Setup is identical to mine, except for the drives. > http://lxnt.info/tx4/freebsd/dmesg.text > > > > > Improvement : I now can fsck /dev/concat/data without > > ad6 being detached > > It was that bad? wow. yop (often even beyond repair ... ) > > Persistent problem : when I rsync an nfs-mounted disk to /dev/concat/data, > > I get after about some Gigs of data have been transfered : > > > > That's strange. Are you sure cables, PSU and line power are ok? > Back in October upgrading PSU halved the error count for me (under linux). I could try, but don't believe in it : just three disks and an extra controller iso the two disks it used to run with ... > > > > I will test again with "#define PDC_MAXLASTSGSIZE 32*4" (just to see > > if that makes a difference) > > > > Please do. bon, it does : no more scaring messages about DMA SETFEATURES etc, though it now ends in a panic ... the end of my /var/log/messages (I turned on your printf as well ) : Nov 2 22:59:11 charlotte kernel: splitting trailing PRD of 2048 (limit 128) Nov 2 22:59:11 charlotte last message repeated 15 times Nov 2 22:59:11 charlotte kernel: splitting trailing PRD of 4096 (limit 128) Nov 2 22:59:11 charlotte kernel: splitting trailing PRD of 2048 (limit 128) Nov 2 22:59:11 charlotte kernel: splitting trailing PRD of 2048 (limit 128) Nov 2 22:59:11 charlotte kernel: splitting trailing PRD of 4096 (limit 128) Nov 2 22:59:11 charlotte last message repeated 11 times Nov 2 22:59:11 charlotte kernel: splitting trailing PRD of 2048 (limit 128) Nov 2 22:59:11 charlotte kernel: splitting trailing PRD of 4096 (limit 128) Nov 2 23:01:18 charlotte syslogd: kernel boot file is /boot/kernel/kernel Nov 2 23:01:18 charlotte kernel: splitting trailing PRD of 4096 (limit 128) Nov 2 23:01:18 charlotte last message repeated 17 times Nov 2 23:01:18 charlotte kernel: Copyright (c) 1992-2007 The FreeBSD Project. Nov 2 23:01:18 charlotte kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 And for the panic : panic: ffs_clusteralloc: map mismatch Uptime: 35m27s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261808 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 #0 doadump () at pcpu.h:172 172 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:172 #1 0x0000000000000004 in ?? () #2 0xffffffff8025e233 in boot (howto=260) at /files/bsd/src6/sys/kern/kern_shutdown.c:409 #3 0xffffffff8025e836 in panic (fmt=0xffffff00305bebe0 "") at /files/bsd/src6/sys/kern/kern_shutdown.c:565 #4 0xffffffff8037ab26 in ffs_clusteralloc (ip=0xffffff00241ae900, cg=9425, bpref=0, len=5) at /files/bsd/src6/sys/ufs/ffs/ffs_alloc.c:1663 #5 0xffffffff803769a8 in ffs_hashalloc (ip=0xffffff00241ae900, cg=395, pref=0, size=5, allocator=0xffffffff8037a650 ) at /files/bsd/src6/sys/ufs/ffs/ffs_alloc.c:1281 #6 0xffffffff8037841a in ffs_reallocblks (ap=0x0) at /files/bsd/src6/sys/ufs/ffs/ffs_alloc.c:778 #7 0xffffffff8042496d in VOP_REALLOCBLKS_APV (vop=0x0, a=0x0) at vnode_if.c:2056 #8 0xffffffff802bd70c in cluster_write (vp=0xffffff0015904ba0, bp=0xffffffff9e74ea10, filesize=81920, seqcount=17) at vnode_if.h:1052 #9 0xffffffff8039662f in ffs_write (ap=0xffffffffad243a30) at /files/bsd/src6/sys/ufs/ffs/ffs_vnops.c:763 #10 0xffffffff804251fb in VOP_WRITE_APV (vop=0xffffffff805ad880, a=0xffffffffad243a30) at vnode_if.c:698 #11 0xffffffff802d9bca in vn_write (fp=0xffffff002e86da50, uio=0xffffffffad243b50, active_cred=0x0, flags=0, td=0xffffff00305bebe0) at vnode_if.h:372 #12 0xffffffff802894d7 in dofilewrite (td=0xffffff00305bebe0, fd=1, fp=0xffffff002e86da50, auio=0xffffffffad243b50, offset=0, flags=0) at file.h:253 #13 0xffffffff80289840 in kern_writev (td=0xffffff00305bebe0, fd=1, auio=0xffffffffad243b50) at /files/bsd/src6/sys/kern/sys_generic.c:402 #14 0xffffffff80289938 in write (td=0x0, uap=0x0) at /files/bsd/src6/sys/kern/sys_generic.c:326 #15 0xffffffff803e0b21 in syscall (frame= {tf_rdi = 1, tf_rsi = 277012480, tf_rdx = 262144, tf_rcx = 262144, tf_r8 = 262144, tf_r9 = 3219503195, tf_rax = 4, tf_rbx = 277012480, tf_rbp = 32768, tf_r10 = 1669914800, tf_r11 = 2860306816, tf_r12 = 0, tf_r13 = 1, tf_r14 = 6326848, tf_r15 = 0, tf_trapno = 12, tf_addr = 277270528, tf_flags = 12, tf_err = 2, tf_rip = 34367373196, tf_cs = 43, tf_rflags = 518, tf_rsp = 140737488337304, tf_ss = 35}) at /files/bsd/src6/sys/amd64/amd64/trap.c:804 #16 0xffffffff803cae08 in Xfast_syscall () at /files/bsd/src6/sys/amd64/amd64/exception.S:270 #17 0x0000000800747f8c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) (I did a "newfs -m 5 /dev/concat/data" just before running this test) Might be another bug just triggered by this Promise (sic) thing, or just another bug "tout court" ...) Anyway, I quit for today. More tommorrow. Regards, Arno -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 2 23:57:51 2007 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FD2D16A417; Fri, 2 Nov 2007 23:57:51 +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 04EC913C48E; Fri, 2 Nov 2007 23:57:45 +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 lA2M3DJf075881; Fri, 2 Nov 2007 23:03:13 +0100 (CET) (envelope-from sos@deepcore.dk) Message-ID: <472B9EA1.6060205@deepcore.dk> Date: Fri, 02 Nov 2007 23:03:13 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Arno J. Klaassen" References: <472A548B.50406@lxnt.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Thierry Herbelot , freebsd-hackers@FreeBSD.ORG, Alexander Sabourenkov , "Matthew D. Fuller" , sos@FreeBSD.ORG Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2007 23:57:51 -0000 Arno J. Klaassen wrote: > definitely an improvement, but not sufficient (for my setup ) : > > amd64-releng_6 on an ASUS A8V UP (box ran rock-stable > for years i386-releng_5 with same hardware apart TX4 and > drives) > > from dmesg : > > atapci0: port 0xe000-0xe07f,0xd80= 0-0xd8ff mem 0xfbb00000-0xfbb00fff,0xfba00000-0xfba1ffff irq 18 at device= 13.0 on pci0 > ata2: on atapci0 > ata3: on atapci0 > ata4: on atapci0 > ata5: on atapci0 > atapci1: port 0xd400-0xd407,0xd000-0xd003= ,0xc800-0xc807,0xc400-0xc403,0xc000-0xc00f,0xb800-0xb8ff irq 20 at device= 15.0 on pci0 > ata6: on atapci1 > ata7: on atapci1 > atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x1= 77,0x376,0xfc00-0xfc0f at device 15.1 on pci0 > ata0: on atapci2 > ata1: on atapci2 > > [ ... ] > > ad0: 38166MB at ata0-master UDMA100 > ad6: 476940MB at ata3-master SATA300 > ad12: 305245MB at ata6-master SATA150 > > booting from ad0 and simple gconcat over ad6 and ad12. > > Improvement : I now can fsck /dev/concat/data without > ad6 being detached > > Persistent problem : when I rsync an nfs-mounted disk to /dev/concat/da= ta, > I get after about some Gigs of data have been transfered : > > Nov 2 16:39:55 charlotte kernel: ad6: WARNING - WRITE_DMA UDMA ICRC er= ror (retrying request) LBA=3D268435392 > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSF= ER MODE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSF= ER MODE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE RCA= CHE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE WCA= CHE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SET_MULTI taskqueue ti= meout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: TIMEOUT - WRITE_DMA retrying (0 = retries left) LBA=3D268435392 > Nov 2 16:40:50 charlotte kernel: ad6: FAILURE - WRITE_DMA status=3Dff<= BUSY,READY,DMA_READY,DSC,DRQ,CORRECTABLE,INDEX,ERROR> error=3Dff LBA=3D268435392 > Nov 2 16:40:50 charlotte kernel: g_vfs_done():concat/data[WRITE(offset= =3D137438920704, length=3D131072)]error =3D 5 > Nov 2 16:40:50 charlotte kernel: ad6: TIMEOUT - WRITE_DMA48 retrying (= 1 retry left) LBA=3D268435648 > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - WRITE_DMA48 UDMA ICRC = error (retrying request) LBA=3D268435648 > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSF= ER MODE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSF= ER MODE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE RCA= CHE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE WCA= CHE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SET_MULTI taskqueue ti= meout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: FAILURE - WRITE_DMA48 timed out = LBA=3D268435648 > Nov 2 16:40:50 charlotte kernel: g_vfs_done():concat/data[WRITE(offset= =3D137439051776, length=3D131072)]error =3D 5 > > ... > > I will test again with "#define PDC_MAXLASTSGSIZE 32*4" (just to see > if that makes a difference) > =20 One thing to try is to loose any geom raid, if raid needed use ataraid=20 instead. I'm shuffeling boards and controllers here to try to reproduce, so far=20 no luck it "just works(tm)", it seems to depend quite heavily on the=20 "right" combination of possibly marginal HW.... -S=F8ren From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 03:09:03 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A64D216A46D; Sat, 3 Nov 2007 03:09:03 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 7D48813C4B0; Sat, 3 Nov 2007 03:09:01 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.13.8/jtpda-5.4) with ESMTP id lA338UUh093582 ; Sat, 3 Nov 2007 04:08:30 +0100 (CET) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id lA338Stj021983 ; Sat, 3 Nov 2007 04:08:28 +0100 (MET) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id lA338StZ021980; Sat, 3 Nov 2007 04:08:28 +0100 (MET) (envelope-from arno) To: =?iso-8859-1?q?S=F8ren_Schmidt?= References: <472A548B.50406@lxnt.info> <472B9EA1.6060205@deepcore.dk> From: "Arno J. Klaassen" Date: 03 Nov 2007 04:08:28 +0100 In-Reply-To: <472B9EA1.6060205@deepcore.dk> Message-ID: Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (shiva.jussieu.fr [134.157.0.165]); Sat, 03 Nov 2007 04:08:30 +0100 (CET) X-Virus-Scanned: ClamAV 0.88.7/4666/Sat Nov 3 01:42:08 2007 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at shiva.jussieu.fr with ID 472BE62E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Cc: Thierry Herbelot , freebsd-hackers@freebsd.org, Alexander Sabourenkov , "Matthew D. Fuller" , sos@freebsd.org Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2007 03:09:03 -0000 Hello, > [ ... ] > > I will test again with "#define PDC_MAXLASTSGSIZE 32*4" (just to see > > if that makes a difference) > > > One thing to try is to loose any geom raid, if raid needed use ataraid > instead. Nope : i did a "newfs ad6" (the disk at the Promise TX4) and then an rsync on it panics the same way as the geom_concat case did. > I'm shuffeling boards and controllers here to try to reproduce, so far > no luck it "just works(tm)", it seems to depend quite heavily on the > "right" combination of possibly marginal HW.... Rather than the marginal HW part, it seems, for me, closely related to MB/BIOS (as well (Alexander apperently has about the same setup as I have for this test)): a while ago (using releng_6) i tried the same setup on three different MBs: ahd-controller + scsi-boot-disk and TX4 and three disks in geom_mirror; results : - on ASUS A8? board (I use plenty of them without the sligthest problem for years; not really expensive but not marginal IMHO) : just look at it and it would crash (g_vfs_done) - on Tyan S28?? : rock stable, unable to crash however hard I tried - on some MSI K8 (I usually run Vista on for testing; this one I really bought "as cheap as possible" ) : would run OK, even under rather heavy load, but when pushing really hard it finaly deliveres the lovely g_vfs_done ... I vaguely remember from another PR that the Promise card does something with PCI-bursting which fbsd does not detect and/or handle correctly (and beyond my simple skills as dumb tester, but maybe the linux-sources contain a clue about that as well). Regards and thanx for your efforts Arno From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 09:23:36 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44F8016A417 for ; Sat, 3 Nov 2007 09:23:36 +0000 (UTC) (envelope-from ender@enderzone.com) Received: from www.ksdhost.com (www.ksdhost.com [75.126.66.82]) by mx1.freebsd.org (Postfix) with ESMTP id 0804213C48D for ; Sat, 3 Nov 2007 09:23:35 +0000 (UTC) (envelope-from ender@enderzone.com) Received: (qmail 56698 invoked from network); 2 Nov 2007 17:16:25 -0500 Received: from buff-broadband-ws-86.dsl.pwrtc.com (HELO ?192.168.5.100?) (64.184.124.87) by www.ksdhost.com with SMTP; 2 Nov 2007 17:16:22 -0500 Message-ID: <472BA1AD.6050408@enderzone.com> Date: Fri, 02 Nov 2007 18:16:13 -0400 From: Ender User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Arno J. Klaassen" References: <472A548B.50406@lxnt.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Alexander Sabourenkov , sos@freebsd.org, "Matthew D. Fuller" , Thierry Herbelot Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2007 09:23:36 -0000 Arno J. Klaassen wrote: > Hello, > > Alexander Sabourenkov writes: > > >> Hello. >> >> I have ported the workaround for the hardware bug that causes data >> corruption on Promise SATA300 TX4 cards to RELENG_7. >> >> Bug description: >> SATA300 TX4 hardware chokes if last PRD entry (in a dma transfer) is >> larger than 164 bytes. This was found while analysing vendor-supplied >> linux driver. >> >> Workaround: >> Split trailing PRD entry if it's larger that 164 bytes. >> >> Two supplied patches do fix problem on my machine. >> > > > definitely an improvement, but not sufficient (for my setup ) : > > amd64-releng_6 on an ASUS A8V UP (box ran rock-stable > for years i386-releng_5 with same hardware apart TX4 and > drives) > > from dmesg : > > atapci0: port 0xe000-0xe07f,0xd800-0xd8ff mem 0xfbb00000-0xfbb00fff,0xfba00000-0xfba1ffff irq 18 at device 13.0 on pci0 > ata2: on atapci0 > ata3: on atapci0 > ata4: on atapci0 > ata5: on atapci0 > atapci1: port 0xd400-0xd407,0xd000-0xd003,0xc800-0xc807,0xc400-0xc403,0xc000-0xc00f,0xb800-0xb8ff irq 20 at device 15.0 on pci0 > ata6: on atapci1 > ata7: on atapci1 > atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 > ata0: on atapci2 > ata1: on atapci2 > > [ ... ] > > ad0: 38166MB at ata0-master UDMA100 > ad6: 476940MB at ata3-master SATA300 > ad12: 305245MB at ata6-master SATA150 > > booting from ad0 and simple gconcat over ad6 and ad12. > > Improvement : I now can fsck /dev/concat/data without > ad6 being detached > > Persistent problem : when I rsync an nfs-mounted disk to /dev/concat/data, > I get after about some Gigs of data have been transfered : > > Nov 2 16:39:55 charlotte kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=268435392 > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435392 > Nov 2 16:40:50 charlotte kernel: ad6: FAILURE - WRITE_DMA status=ff error=ff LBA=268435392 > Nov 2 16:40:50 charlotte kernel: g_vfs_done():concat/data[WRITE(offset=137438920704, length=131072)]error = 5 > Nov 2 16:40:50 charlotte kernel: ad6: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=268435648 > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=268435648 > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly > Nov 2 16:40:50 charlotte kernel: ad6: FAILURE - WRITE_DMA48 timed out LBA=268435648 > Nov 2 16:40:50 charlotte kernel: g_vfs_done():concat/data[WRITE(offset=137439051776, length=131072)]error = 5 > > ... > > I will test again with "#define PDC_MAXLASTSGSIZE 32*4" (just to see > if that makes a difference) > > Regards, Arno > > Just a guess here, I bet that patch helped, but there are compound problems reguarding SATA on amd64 in 7.x Do a quick search for [sata] (especially g_vfs_done) in the PR database. Hopefully this removed a layer of bugs so the other ones are easyer to fix. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 10:50:44 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1EC916A420 for ; Sat, 3 Nov 2007 10:50:44 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx02.syd.optusnet.com.au (fallbackmx02.syd.optusnet.com.au [211.29.133.72]) by mx1.freebsd.org (Postfix) with ESMTP id 301D613C4BA for ; Sat, 3 Nov 2007 10:50:44 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by fallbackmx02.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id lA1JqOLX010699 for ; Fri, 2 Nov 2007 06:52:24 +1100 Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lA1JpNaU005579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Nov 2007 06:51:24 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id lA1JpNg8006048; Fri, 2 Nov 2007 06:51:23 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id lA1JpNUB006047; Fri, 2 Nov 2007 06:51:23 +1100 (EST) (envelope-from peter) Date: Fri, 2 Nov 2007 06:51:23 +1100 From: Peter Jeremy To: Michael B Allen Message-ID: <20071101195123.GJ25671@server.vk2pj.dyndns.org> References: <78c6bd860711011041o6d10753an663f19389737f84b@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <78c6bd860711011041o6d10753an663f19389737f84b@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-hackers Subject: Re: timers and semtimedop(2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2007 10:50:44 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 01, 2007 at 01:41:10PM -0400, Michael B Allen wrote: >I need semtimedop(2). I'm thinking I can just do a semop with a SIGINT may= be. I presume you mean SIGALRM. >Can someone suggest a good method for setting up a timer to deliver >the signal? What sort of timers does FreeBSD offer? Assuming you aren't planning on creating a new syscall: man setitimer There's also kqueue EVFILT_TIMER but that is probably only useful if you are already using kqueue for other purposes. --=20 Peter --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHKi47/opHv/APuIcRAmE4AKCLuMMYwTJIxxSdk/CmHQaCJa7pMACgthfB o48IF6ruGWzCEqcdWsnGFKo= =1umR -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 13:05:33 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7E9216A46C for ; Sat, 3 Nov 2007 13:05:33 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id 96D2513C4DB for ; Sat, 3 Nov 2007 13:05:33 +0000 (UTC) (envelope-from maslanbsd@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so733642nzf for ; Sat, 03 Nov 2007 06:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=ve0BuLzIbzFPjXlzFxnmAp3xJrzINTl0YrLF4I3/srY=; b=d9YQPAWVFe1cA55fodxz3xLrv6Di/ojFj+GzL/IpN+N0v523e8+34EXvIoK57JV8Npdj3kFjLmeGXulEUNiauke+3TOXOc9djfWs+tva52LU81bqaS7pxFnS66XXo0r8sThFYC/p3dAhjQfTNu4ru7xaMJKIdBcALiZgqiwl04o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SDznDdSJNKYbvbWlx3tRUQCPOU3CN74oRmXlQdNo0g41AhQt1qjI88u9a5NVZnZVW9FkNijuULKqyoFZrAA4QWZiROc8VekTFUKVBsbs3sxcjKQWSNCWQlqk7bOu+A/bu0mt4oCR3vu5HBx5C5fbcfCkIE5eGJqUDSo4nMB7nLM= Received: by 10.142.231.7 with SMTP id d7mr758391wfh.1194095110539; Sat, 03 Nov 2007 06:05:10 -0700 (PDT) Received: by 10.143.33.14 with HTTP; Sat, 3 Nov 2007 06:05:10 -0700 (PDT) Message-ID: <319cceca0711030605m370709d1ua0c694d12dbb1766@mail.gmail.com> Date: Sat, 3 Nov 2007 13:05:10 +0000 From: Maslan To: "FreeBSD Hackers" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: pkg_add doesn't keep dependent pkgs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2007 13:05:33 -0000 Hi, pkg_add -rK seems not to keep the packages dependencies so as the package itself. i found this: http://lists.freebsd.org/pipermail/freebsd-bugbusters/2006-August/000178.html but no answer since then. I don't if this is a bug, or not even implemented feature? Thanks alot -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 18:31:54 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E24C16A418 for ; Sat, 3 Nov 2007 18:31:54 +0000 (UTC) (envelope-from stsp@stsp.name) Received: from fallback-mx.in-berlin.de (fallback-mx.in-berlin.de [192.109.42.17]) by mx1.freebsd.org (Postfix) with ESMTP id CE67013C4AC for ; Sat, 3 Nov 2007 18:31:53 +0000 (UTC) (envelope-from stsp@stsp.name) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by fallback-mx.in-berlin.de (8.14.1/8.13.6/Debian-1) with ESMTP id lA3FlRYo023740 for ; Sat, 3 Nov 2007 16:47:27 +0100 X-Envelope-From: stsp@stsp.name Received: from stsp.lan (stsp.in-vpn.de [217.197.85.96]) (authenticated bits=128) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id lA3Fl6iQ004062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Nov 2007 16:47:07 +0100 Received: from ted.stsp.lan (localhost [127.0.0.1]) by stsp.lan (8.13.8/8.13.8) with ESMTP id lA3Fl6tN005769; Sat, 3 Nov 2007 16:47:06 +0100 (CET) (envelope-from stsp@ted.stsp.lan) Received: (from stsp@localhost) by ted.stsp.lan (8.13.8/8.13.8/Submit) id lA3Fl5xl005768; Sat, 3 Nov 2007 16:47:05 +0100 (CET) (envelope-from stsp) Date: Sat, 3 Nov 2007 16:47:05 +0100 From: Stefan Sperling To: M E Message-ID: <20071103154705.GA5370@ted.stsp.lan> References: <7c78e14d0711021916u1b07aad6lebb16afadc3faac@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <7c78e14d0711021916u1b07aad6lebb16afadc3faac@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Cc: hackers@freebsd.org Subject: Re: WOL not working with 3Com NIC X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2007 18:31:54 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 02, 2007 at 09:16:59PM -0500, M E wrote: > Hello Stefan, Hello, I'm Cc'ing hackers@ in my reply to your mail so people can overhear this conversation. It would be great to get some help. > I am able to get "will wake on: magic", when typing "ifconfig" in > FreeNAS (built on FreeBSD); however, I am still unable to wake up the > box. I know that xl does not work yet. The driver hears you requesting WOL and internally makes a note to configure WOL at shutdown time. But configuring the device for WOL does not work correctly for some reason. I haven't yet figured out what exactly the problem is, even with looking at the specs. > The NIC is a 3Com EtherLink > XL 10/100 PCI For Complete PC Management NIC (3C905C-TX). I've found 3 spare ones of those at uni I could bring home to test with. There have been requests for fxp (Intel) support, too, and by accident I also found one of those cards at uni in a spare server no one was using. But the hard disk in my development box is dying, I have to get it replaced. And my desktop got a new motherboard a while ago. The old one had bad capacitors, it was totally unstable so I returned it. I only later realised that the new one has no WOL connector! Doh! So now I finally have some cards, but no hardware to use them with. It used to be the other way around for like a year or more. Meh :-/ I need to find some time to buy a disk and set up my dev box again before I can continue working on this. > Do you have any sugestions? My free time is scarce at the moment. More eyes and brains to throw at the problem would really, really help. There are data sheets for 3com cards at http://people.freebsd.org/~wpaul/3C= om/ If someone found something obviously wrong in the xl_enable_wol() routine it would help an awful lot. I already went over it twice but I cannot find the error. It could also be something else the driver is doing behind my back that prevents WOL from working. I'm not experienced enough in device drivers to really understand all the subtleties of the whole thing. For those who don't know, the WOL patch is here: http://stsp.name/wol/ --=20 stefan http://stsp.name PGP Key: 0xF59D25F0 --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHLJf55dMCc/WdJfARAgbPAKCPRbpoNqVSZ5t+XaOLzaLyQQH+9gCg8RL3 Tvr1/GIma2bsFufg4CyZ+Cw= =Sizg -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 3 21:12:44 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6839216A468; Sat, 3 Nov 2007 21:12:44 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from mail.lxnt.info (mail.lxnt.info [217.23.143.142]) by mx1.freebsd.org (Postfix) with ESMTP id 4820013C4A6; Sat, 3 Nov 2007 21:12:21 +0000 (UTC) (envelope-from screwdriver@lxnt.info) Received: from [84.23.52.8] (helo=[192.168.1.100]) by mail.lxnt.info with esmtpa (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IoQHa-000Pwo-MC; Sun, 04 Nov 2007 00:11:54 +0300 Message-ID: <472CEFDD.2020103@lxnt.info> Date: Sun, 04 Nov 2007 01:02:05 +0300 From: Alexander Sabourenkov User-Agent: Thunderbird 1.5.0.7 (X11/20061030) MIME-Version: 1.0 To: "Arno J. Klaassen" References: <472A548B.50406@lxnt.info> <472B9EA1.6060205@deepcore.dk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Thierry Herbelot , "Matthew D. Fuller" , =?UTF-8?B?U8O4cmVuIFNjaG1pZHQ=?= , sos@freebsd.org Subject: Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2007 21:12:44 -0000 Arno J. Klaassen wrote: > > Rather than the marginal HW part, it seems, for me, closely related to > MB/BIOS (as well (Alexander apperently has about the same setup as I > have for this test)): > [...] > > I vaguely remember from another PR that the Promise card does > something with PCI-bursting which fbsd does not detect and/or > handle correctly (and beyond my simple skills as dumb tester, but > maybe the linux-sources contain a clue about that as well). > Analysis of chip initialization in vendor-supplied, Linux and FreeBSD drivers shows that FreeBSD's one: - does not enable something called 'BMR_BURST', - performs hotplug init in one write (instead of two read-modify-writes ), - does an extra write (offset 0x54) which is not done in other drivers. Analysis text: http://lxnt.info/tx4/chipinit.text Patch with ported chipinit (dangerous to use with anything from Promise other than sata300 tx4 !!): http://lxnt.info/tx4/freebsd/chipinit.patch (cumulative) http://lxnt.info/tx4/freebsd/ata-chipset.c+chipinit (patched source) Note two things: 1. I have not compiled or tested this patch. Please do. 2. I may have missed this bug because I'm frequently rebooting between Linux and FreeBSD, and what Linux driver initialized may have lasted the reboots. -- ./lxnt